Re: Content negotiation, features, and related items

Ted Hardie:
>
[....]
>Koen,
>	In some talks with Andy Mutz and Larry Masinter I mentioned
>that I thought that it would be easier to get IANA support if we kept
>the registration procedures draft to just those things which IANA
>would need to check off when they got a feature to register.  This was
>based on feedback I got from Jon Postel and Joyce Reynolds when I was
>writing up registration procedures for SOIF template types (part of
>the CIP working going on in the FIND working group).  My take on it is
>that they prefer the registration procedures documents to be revisable
>without forcing a revision of the technical specification.  This means
>paring down the draft to just the procedures and putting the other
>sections somewhere else.  That led me to volunteer to Andy and Larry
>that I would try to split the draft up, so that we could see which
>bits fell where.  I have not yet had the chance to sit down and really
>write up the result, but my current sense is that Section 1, Section
>2.4, Section 3.1.*, and Sections 3.[5,6,8] are the ones containing the
>procedural elements.  I meant to send off a note with the results
>as soon as I had gotten the drafts written, but that has taken longer
>than I anticipated.  My apologies if the delay has caused any confusion.
>		regards,
>			Ted Hardie
>			NASA NIC

Hi Ted,

Before you start editing, here is the reasoning behind the current
structure of the draft.  

For section 3, the entire structure, and much of the wording, was
lifted from the MIME registration document (RFC 2048), and you should
definately look at that document before you start taking section 3
apart.  

Sections 2.[123] explain feature tags to end users, and give some
guidelines on the appropriate use of feature tags by negotiation
protocols.  Note that there is no reference to a specific negotiation
protocol in the draft.  If there were, that reference could replace
the explanations in sections 2.[123], but there is no such reference.
The draft creates a shared namespace for potentially many
protocols/mechanisms without mentioning a single specific protocol or
mechanism.  This is a strange thing to do, but it certainly guarantees
the desired decoupling between revising registration procedures and
revising specific protocols. 

Koen.

Received on Wednesday, 22 October 1997 12:45:57 UTC