Re: FYI: draft-nottingham-hdrreg-http-01

At 18:10 21/09/04 -0700, Roy T. Fielding wrote:
>>Keep in mind that these are seeds for the registries, which is AFAIK why 
>>there are the textual summaries in addition to the ToCs. Graham Klyne 
>>(cc:ed) wrote the software that helps me generate the listings, and is 
>>also the mastermind behind the registry itself (now RFC3864), so he may 
>>be able to shed additional light.
>>
>>Registry entries aren't distinguished by type of standard; remember that 
>>non-IETF registrations (e.g., W3C) are allowed. They're only 
>>differentiated by whether they were specified by a recognised standards 
>>process (the permanent registry) or something more ad hoc (the 
>>provisional repository).
>
>No, that would be quite worthless.  Provisional just means they haven't
>been used extensively yet and may disappear from the registry if they
>are never used.  Provisional versus Permanent is a separate, orthogonal
>axis from status.
>
>Historic means they shouldn't be used -- the registry simply reserves
>the name to avoid collisions.  About 1/3 of the header fields in that list
>should be marked historic or informational, which are distinctly different
>categories from standard.  Standard means it is defined by a standards
>track document, either within or outside the IETF, not just any document.
>Old hypertext specs, W3C notes, discontinued Internet drafts, and
>IETF Informational or Historic RFCs do not qualify as standards-track.
>Standards-track IETF documents (draft or RFC), W3C REC track, ISO WG
>items, and such should be marked as standard.
>
>My suggested reorganization was to make it easier to review the fields
>and identify discrepancies in the templates -- right now my eyes just
>go blurry.  Alternatively, make the summary useful by including more of
>the template content (status and spec reference), not "http".
>IANA can generate their own summary from the templates *after*
>they are entered within the IANA database.

I don't entirely understand your concern here, so it's difficult to respond 
in detail.  It seems you're finding it harder than it should be to review 
the status categorization for each header field, or is there more?

At the end of the day, the specific document format is quite mutable -- the 
raw data is all in RDF/N3, and I can change the software's output 
moderately easily, within limits.  My original plan was that the summary 
consists of name + 1-line summary, because that's what seemed useful to 
me.  The current format results from some feedback, and I'm open to 
constructive suggestions if the present format is problematic.

>Oh, bugger, never mind -- I was looking at the wrong section
>of RFC 3864.  Status and provisional are not orthogonal at all.
>Why the heck was it written that way?  Oh well...

Well, your first take looked closer.  From the PoV of the registration, 
they are largely orthogonal, except that the status has some bearing on 
which sub-registry is applicable.

As for why it was written that way... it's a couple of years ago now that 
this was being reviewed and debated, so the details are now fuzzy, but I do 
remember there were a number of conflicting concerns to be navigated.  It 
reflected the balance of consensus at the time.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Sunday, 26 September 2004 07:53:49 UTC