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.
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.
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
