W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 21 Sep 2004 18:10:13 -0700
Message-Id: <282BCC5A-0C34-11D9-BE81-000393753936@gbiv.com>
Cc: HTTP working group <ietf-http-wg@w3.org>, Graham Klyne <GK@NineByNine.org>, Webdav WG <w3c-dist-auth@w3c.org>
To: Mark Nottingham <mnot@mnot.net>

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

....Roy
Received on Wednesday, 22 September 2004 01:13:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT