Changes between Version 1 and Version 2 of GAPI_AM_API_DRAFT/Archive


Ignore:
Timestamp:
03/31/14 16:07:36 (6 years ago)
Author:
Aaron Helsinger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GAPI_AM_API_DRAFT/Archive

    v1 v2  
    55This page documents archived older DRAFT revisions to the GENI Aggregate Manager API, previously proposed for the API, but then withdrawn, superseded, or postponed.
    66
    7 The current officially adopted version of the API is '''2''' and is documented on [wiki:GAPI_AM_API the main API page].
     7The current officially adopted version of the API is '''3''' and is documented on [wiki:GAPI_AM_API the main API page].
    88
    99Current proposals for the next version of the AM API are on the [GAPI_AM_API_DRAFT AM API Draft wiki page].
     
    1818 - ''Withdrawn'': [#Withdrawn:ChangeSetJ Change Set J]: Support proxy aggregates with 1 new option and 1 new !GetVersion entry
    1919 - ''Postponed'': [#ChangeSetL:ChangeSFAcredentialsprivileges Change Set L]: Standardize slice credential privileges
    20 
     20 - [#Deferred:ChangeSetO3:Allowunicodevalues Change Set O3]: Allow unicode values
     21 - [#Declined:NoReservationAllocate No Reservation Allocate]
    2122
    2223-----
     
    408409
    409410Note also that some current AMs do not require any particular privileges to do !ListResources, even with a {{{slice_urn}}}. This change suggests that aggregates require a valid slice credential with {{{CanRead}}} privileges to authorize this operation using current slice credentials.
     411
     412-----
     413
     414= Deferred: Change Set O3: Allow unicode values =
     415Many values defined by this API appear to be limited to ASCII characters - both arguments and returns. We would like to support internationalization. Some values in this API (e.g. those defined as URLs) implicitly support unicode. Currently, a well behaved aggregate should be able to handle unicode values in at least some arguments. Similarly, a well behaved client should be able to handle unicode returns.
     416
     417''This change set was discussed and deferred at GEC19''. We do not yet have sufficient motivation, and there are questions about this proposal.
     418
     419This change would clarify the support for internationalization in this API, and allow aggregates to specify unicode support. This change should not require any clients or aggregates to make changes. This change would specify:
     420
     421  Aggregates are encouraged to support non-ASCII letters as input. Clients are encouraged to support non-ASCII returns from aggregates. However, this change set does not require that either aggregates or clients support non-ASCII strings, and aggregates should not require clients to accept non-ASCII results where the API does not explicitly require it.
     422
     423This change would allow an aggregate to explicitly specify that arguments may be unicode, and returns may be unicode if the content demands it. By default, aggregates are expected to use the ASCII only regular expressions that the rest of this API specification uses, and to limit returns to ASCII characters where possible. This change would add an optional return from `GetVersion` that allows an aggregate to specify that unicode arguments are acceptable (ASCII strings must still be accepted), and that all returns may be unicode. When the aggregate specifies this option, it shall still attempt to support ASCII inputs to allow clients to operate only in ASCII where possible.
     424
     425Specifically, this change adds `geni_unicode_compliant` to the return from `GetVersion`.
     426 - This field is optional.
     427 - Default is `false`. All strings specified in this API are to be treated as ASCII unless otherwise specified, (e.g. the format explicitly references a standard that supports unicode). This includes both arguments and returns.
     428 - When `true`, all strings specified in this API may be unicode. In particular, regular expressions that limit to ASCII characters shall be interpreted to include the unicode equivalents. The aggregate will still accept ASCII input. Returns will remain ASCII where the API defines ASCII constants or content allows it.
     429
     430-----
     431
     432= Declined: No Reservation Allocate =
     433Tools should be able to do complex topology embedding to figure out where a particular request can be instantiated. Aggregates know best what they can do. This proposal provides a cheap way to ask "could you satisfy this request, and if so what would I get?"
     434
     435This proposal is ''declined'': `Allocate` itself is pretty cheap.
     436
     437 - Add a new option to `Allocate` named `geni_no_reservation`. If supplied with a non-empty value (not null or an empty string), the request is not asking for the resources to actually be reserved. Instead, the aggregate should calculate what it ''would'' reserve, and return the usual `allocate` return structure, but without actually making the reservation. As such, `geni_expires` should be set to the current time, and the status should remain `geni_unallocated`, and the `geni_sliver_urn` element should be empty (no sliver is created or assigned). Since there is no sliver URN, no calls to other methods should return any information on this sliver.
     438