On Tue, Jul 3, 2012 at 12:46 PM, Martin Stiemerling <[email protected]> wrote: > > > On 07/02/2012 08:35 PM, Richard Alimi wrote: >> >> On Mon, Jul 2, 2012 at 8:05 AM, Martin Stiemerling >> <[email protected]> wrote: >>> >>> [writing with no Area Director hat on, i.e., as a random community >>> member] >> >> >> Good to have you back :) > > > Thanks, finally there is time again for ALTO :) > > >> >>> Hi Richard, all, >>> >>> On 07/02/2012 08:38 AM, Richard Alimi wrote: >>> [...] >>> >>> >>>>> REQ. ARv14-4: Full compliant : 7.5.3.3.1., 7.5.3.3.2. >>>>> >>>>>> REQ. ARv14-5: An ALTO client protocol MUST be extensible to >>>>>> enable >>>>>> support of other host group descriptor types in future. An ALTO >>>>>> client protocol specification MUST define an appropriate >>>>>> procedure >>>>>> for adding new host group descriptor types, e.g., by establishing >>>>>> an >>>>>> IANA registry. >>>>> >>>>> >>>>> >>>>> REQ. ARv14-5: Partially compliant : 7.5.3.1 says: "Extension >>>>> documents >>>>> may define additional Address Types." but it does not define what >>>>> kind of document is required (just an Internet-Draft, or >>>>> Informational RFC, ...) >>>> >>>> >>>> >>>> It needs something more than just an I-D since that is a pretty low bar. >>> >>> >>> >>> You can specify 'protocol specification' or 'expert review' as the bar >>> for >>> an extension. >>> See also RFC 5226 for a discussion of this: >>> http://tools.ietf.org/html/rfc5226 >>> >>> >>>> >>>> Do people think a registry is needed for this? If not, perhaps we can >>>> just make this more explicit that it needs to be a standards-track >>>> RFC. >>> >>> >>> >>> There should be a registry where you can add additional address types. >>> Otherwise it is really hard to get new address types in a clean way into >>> the >>> protocol. >>> A registry allows also to keep track about all existing address types >>> (out >>> of the ALTO protocol and what comes later on). >> >> >> Right - okay. We'll add an Address Type registry. That said, it'd be >> really nice to point to an existing registry. I think we'd need the >> following for such a registry: >> (1) A textual string for an address type itself >> (2) A specification (preferably a pointer to one) for how to serialize >> and deserialize a textual address of that type. >> (3) (maybe, depending on the result of the discussion below) a >> statement of how an address type can be mapped into IPv4/v6 addresses. >> >> However, when browsing through the available IANA registries I didn't >> see one that really matched those requirements. Does anyone have a >> better option before we go about defining our own? > > > We need to create our own registry for this, which isn't a big deal. Just > write this up in the IANA considerations section.
Sounds good to me. > > >> >>>> >>>>>> REQ. ARv14-6: For host group descriptor types other than "IPv4 >>>>>> address prefix" and "IPv6 address prefix", the host group >>>>>> descriptor >>>>>> type identification MUST be supplemented by a reference to a >>>>>> facility, which can be used to translate host group descriptors >>>>>> of >>>>>> that type to IPv4/IPv6 address prefixes, e.g., by means of a >>>>>> mapping >>>>>> table or an algorithm. >>>>> >>>>> >>>>> > [...] > > >>>> >>>> >>>> The use of JSON and Section 7.2.7 also helps with extensions. >>>> >>>>>> REQ. ARv14-27: An ALTO client protocol MUST include protocol >>>>>> versioning support, in order to clearly distinguish between >>>>>> incompatible versions of the protocol. >>>>> >>>>> >>>>> >>>>> REQ. ARv14-27: NOT compliant. There is no version field. >>>>> 7.6. states: "Future extensions or >>>>> versions of the ALTO Protocol SHOULD be accomplished by extending >>>>> existing media types or adding new media types, but retaining the >>>>> same format for the Information Resource Directory." >>>>> >>>>> As workaround, one could define new media types such as >>>>> alto-directory_v2_0+json or >>>>> alto2-directory+json >>>> >>>> >>>> >>>> Yeah. There was a discussion when going to the REST-ful approach >>>> about whether we wanted any explicit version numbers or not. The idea >>>> was that we didn't need an ALTO version number exposed to applications >>>> if we used media types appropriately. Using media types like you >>>> suggested is certainly one approach. >>> >>> >>> >>> Irrespectively of what mechanisms is being used, this protocol needs >>> versioning support. However, I'm not sure that media-types are the best >>> way >>> forward for this. >>> What would be a different approach when using media types? >> >> >> Do you mean a different approach *than* using media types? One other >> option would be to revert revert back to what we had before, which is >> have an explicit field in each and every response. >> >> Here's one pointer to mailing list discussions about protocol >> versioning and media types: >> http://www.mail-archive.com/[email protected]/msg00609.html >> I'll note that our AD at the time (Lisa) was one of the people >> suggesting we use content negotiation to provide protocol versioning. >> >> My preference would be to not re-hash the merits of protocol >> versioning unless we think there is a clear technical advantage over >> what we have now. > > > Let me go through the old email thread to see what happened back then. > > >> >>>> >>>>>> 3.1.6. Error Handling and Overload Protection >>>>>> >>>>>> REQ. ARv14-28: An ALTO client protocol MUST use TCP based >>>>>> transport. >>>>> >>>>> >>>>> >>>>> REQ. ARv14-28: Full compliant. Protocol is based on HTTP (6.), which >>>>> does not neccessarily run on top of TCP (see 1.4. of RFC 2616), >>>>> but >>>>> de-facto always does. >>>>> >>>>> >>>>> side note: IESG evaluation of the requirements document likely will >>>>> result in this requirement being changed to something like: >>>>> >>>>> REQ. ARv15-28 An ALTO client protocol MUST use a congestion-aware >>>>> transport protocol, e.g., TCP. >>>>> >>>>> but this will not cause any problem here. > > [...] > > >>>>> >>>>> REQ. ARv14-29..34: Partially compliant: The protocol is based on >>>>> HTTP, >>>>> which features various appropriate protocol mechanisms (R-A >>>>> header, >>>>> 3xx and 503 replies, etc.), but no specific guidance is provided >>>>> when and how to use them in conjunction with the ALTO protocol. >>>> >>>> >>>> >>>> We also had a discussion about this in the protocol overhaul for >>>> making it REST-ful. The guidance we received there was to not repeat >>>> details from RFC2616. I'm not sure I see much utility in adding >>>> specifics in the ALTO protocol document, since it would basically >>>> amount to saying "If you think you are overloaded, you are free to >>>> return a 503." Then, if we were to add that, people would ask "you >>>> gave me guidance on using 503, but you didn't tell me when I should or >>>> should not use chunked transfer encoding.. how about that??" The idea >>>> was that the statements in Section 7.2, as well as some intelligence >>>> on behalf of implementers on how to apply RFC2616, would answer all of >>>> these questions. >>> >>> >>> >>> That is not a good way of specifying things. There is no need to say how >>> a >>> 503 response looks like, but it is definitely good to say when an ALTO >>> protocol must reply with such a code. "intelligence ...of implementers" >>> will >>> cause ALTO protocol implementations that do not interoperate. >> >> >> If we want to make revisions here, can you give some guidance on where >> we should recommend certain usage of HTTP and where we shouldn't? >> Should it be just additional text to ensure that we satisfy the >> requirements on overload control, or additional guidance on how to to >> employ other parts of HTTP such as transfer encoding, caching, when to >> use redirects, etc? > > > I would describe only mechanisms which are required by the protocol (or by > the requirements). The protocol spec must say: return a 503 if overloaded, > for instance. I do not see the need to specify how ALTO is using each and > every feature of HTTP, but it should be clear how functionality required by > the ALTO protocol is mapped to the underlying HTTP protocol. Okay - we'll add some text for overload control. Thanks, Rich > > Thanks, > > Martin > > -- > IETF Transport Area Director > > > [email protected] > > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
