At 09:40 07/04/04 +0000, Charles Lindsey wrote:
This raises a more general problem regarding headers that migrate from one
medium to another.
I see no great difficulty here. Header fields can be listed under multiple
protocols so that these subtleties can be captured faithfully. The
registration document also notes that an entry may refer to multiple
specifications in cases like this:
[[
In some cases, the same field name may be specified differently (by
different documents) for use with different application protocols;
e.g. The Date: header field used with HTTP has a different syntax
than the Date: used with Internet mail. In other cases, a field name
may have a common specification across multiple protocols (ignoring
protocol-specific lexical and character set conventions); e.g. this
is generally the case for MIME header fields with names of the form
'Content-*'.
Thus, we need to accommodate application-specific fields, while
wishing to recognize and promote (where appropriate) commonality of
other fields across multiple applications. Common repositories are
used for all applications, and each registered header field specifies
the application protocol for which the corresponding definition
applies. A given field name may have multiple registry entries for
different protocols; in the Permanent Message Header Field registry,
a given header field name may be registered only once for any given
protocol. (In some cases, the registration may reference several
defining documents.)
]]
-- http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-07.txt
section 2.2.1
In the case of Accept-Language, it is defined generically in RFC 3282, but
it wasn't clear to me that it is defined for use specifically with email,
hence my question here. It is defined for use with HTTP, and I had
originally anticipated that it would be included in the registry for use
with HTTP.
In summary, the registry gives us an opportunity to record the use of
common headers with several protocols with which they are applicable.
As for the designated expert mechanism: you are correct. But that should
not be seen as displacing discussion on the mailing lists appropriate for
the protocol(s) concerned, which is why I raised the matter of
Accept-Language *for email* on this list.
For netnews-defined header fields that are also used in email, I think it
is appropriate for the registration *as an email header field* to be
discussed by the email community. Personally, in this case, I think it
appropriate that the mail use registration be contained in a separate
document for which review by the email community is sought, said document
referencing Usefor for the technical specification.
#g
--
PS: while talking about the registry in general, I have recently revived
some report generation software I adapted for generating
registration-template XML2RFC source code and browseable HTML pages from
header field descriptions in RDF/N3. The most recent version of the
software is not yet documented, but the Python source code is on the web
[1]. An earlier version of the software is described [2], et link. I have
recently implemented a program to compile a more friendly form of "report
definition" (the current definition for header field registry generation is
[3]) into RDF/N3 (e.g. see [4]) for interpretation by the report
generator; the Haskell [8] source code of this compiler is at
[5][6][7]. More information about RDF/N3 (aka Notation3) can be found at
[9]. All this software is work-in-progress.
[1] http://www.ninebynine.org/Software/PythonN3/
(The main module is N3GenReport.py)
[2] http://www.ninebynine.org/Software/Intro.html#RDFReportGenerator
http://www.ninebynine.org/RDFNotes/RDFForLittleLanguages.htm
[3] Source of header registry report definition:
http://www.ninebynine.org/Software/HdrRegistry/GenHeaderRegistry.rep
Directory with related data:
http://www.ninebynine.org/Software/HdrRegistry/
[4] Compiled to Notation3 (not for human consumption [dogfood only?]):
http://www.ninebynine.org/Software/HdrRegistry/GenHeaderRegistry.n3
[5] http://www.ninebynine.org/Software/CompileRDF/
(Main program is RepToRDF.hs)
[6] http://www.ninebynine.org/Software/HaskellRDF/
[7] http://www.ninebynine.org/Software/HaskellUtils/
[8] Info about Haskell:
http://www.haskell.org/
[9] More info about RDF/Notation3:
http://www.w3.org/DesignIssues/Notation3.html
http://www.w3.org/2000/10/swap/Primer.html
http://infomesh.net/2002/notation3/
See also:
http://www.w3.org/2000/10/swap/doc/cwm.html
At 09:40 07/04/04 +0000, Charles Lindsey wrote:
In <5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20040406210213(_dot_)02e82d98(_at_)127(_dot_)0(_dot_)0(_dot_)1> Graham Klyne
<gk(_at_)ninebynine(_dot_)org> writes:
>Notwithstanding the operational problems you mention, this suggests to me
>that Accept-language should be included in the initial (permanent) registry
>of email message headers, possibly carrying a warning about the operational
>issues you note?
This raises a more general problem regarding headers that migrate from one
medium to another.
AIUI, Accept-Language is already an official HTTP header. Therefore it
will appear in the registry already, which itself should act as a strong
hint that it is the preferred header-name for a similar feature in other
media.
But if you want to go further and list it under those other media, then
you are required to refer to a defining document, and in such a case the
defining document will say nothing about those other media. So is that
allowed? I think the answer has to be that you go through the mechanism
defined in Graham's RFC-to-be which is to ask the IESG (via their
"designated expert"), following discussion in the "desginated email
discussion list". Well, none of that machinery is set up yet, so I suppose
discussing it on this list is the next best thing (BTW, could this list be
designated for that purpose? I doubt the suggested somelist(_at_)iana(_dot_)org
will
receive many subscriptions.)
A similar problem arises with the User-Agent header. Currently, this is
defined for use in HTTP, but is quite widely used in email and news. In
this case, the USEFOR WG has taken it on board and is defining it as an
official News header, with a throwaway remark that "It is also intended
that this header be suitable for use in Email".
Now I have just been writing the registration templates for the USEFOR
IANA Considerations section, so naturally the User-Agent header appears in
it. But also, on the stregth of that throwaway remark, I have tentatively
included is for both netnews and email. Opinions welcomed on that.
--
Charles H. Lindsey ---------At Home, doing my own
thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web:
http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU,
U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4
AB A5
------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact