| | 411 | |
| | 412 | ----- |
| | 413 | |
| | 414 | = Deferred: Change Set O3: Allow unicode values = |
| | 415 | Many 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 | |
| | 419 | This 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 | |
| | 423 | This 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 | |
| | 425 | Specifically, 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 = |
| | 433 | Tools 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 | |
| | 435 | This 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 | |
