Graham, given that RFC 1700 was obsoleted by RFC 3232, I question the
whole need for an archival RFC, that is by definition almost instantly
out of date.
I think your time would be much better spent improving the HTML-based
reference [1] that could then handed over to IANA. Of course, you would
probably want to get IANA's permission/agreement before you got too far
along, to make sure it's in a form they would be willing to administer
going forward. Specifically, is IANA going to want to use the same
underlying database you do and then compile the HTML, or do they just
want the HTML and will make changes manually?
However, I can never imagine a situation in which I would check the RFC
rather than the up-to-date IANA registry, so I would skip the former
entirely.
[1]
http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanent
Registry.html
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com/> <tel:+1-650-327-2600>
Randomly generated quote:
If you're afraid of criticism, don't say anything, don't do anything,
and don't be anything. - Marian Wright Edelman
-----Original Message-----
From: Graham Klyne [mailto:GK-lists(_at_)ninebynine(_dot_)org]
Sent: Wednesday, November 13, 2002 06:21
To: Charles Lindsey
Cc: ietf-822(_at_)imc(_dot_)org
Subject: Re: Fwd: Last Call: Registration procedures for message header
fields to BCP
OK, I see your point. (-01 is not really different in this respect.)
I'll look into updating the tools in some way. I think it calls for
rethinking the overall form of presentation: cross-referencing from one
entry to another is likely to get messy.
I'll note that I don't expect the registration document to be used as a
common reference, rather that it contains some information that goes
into a
registry. For an online registry, I think the duplication is not a
problem
(there is a summary table of
header fields, each linked to a registry page). Though, if it's felt to
be
a significant improvement, I could look into separating the change
controller information and linking through to it. (Needless to say, the
duplication doesn't occur in the original source data!)
As for draft-palme-mailext-headers-08.txt, I've been in touch with
Jacob. I just haven't found time to follow through, yet.
#g
--
At 11:45 AM 11/12/02 +0000, Charles Lindsey wrote:
In
<5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20021111161503(_dot_)03e75360(_at_)127(_dot_)0(_dot_)0(_dot_)1>
Graham Klyne
<GK-lists(_at_)ninebynine(_dot_)org> writes:
I assume you refer to [1] [2]. See also [3] for an example of
possible
registry data on the Web.
[1]
http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-01.txt
(whose content is set to be updated, with input from Jacob
Palme)
[2]
http://www.ietf.org/internet-drafts/draft-nottingham-hdrreg-http-00.txt
[3]
http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanen
tR
egistry.html
http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderProvision
alRegistry.html
The last one I saw was draft-klyne-hdrreg-mail-00.txt, so I need to
look
at the others. But here is an example from that document:
2.1.3 Sender: header
Header name:
Sender
Description:
Mailbox of message sender
Applicable protocol:
mail (http://www.rfc-editor.org/rfc/rfc2822.txt)
Status:
standards-track
Author/change controller:
Peter W. Resnick (mailto:presnick(_at_)qualcomm(_dot_)com)
QUALCOMM Incorporated, 5775 Morehouse Drive,
San Diego, CA 92121-1714, USA.
Tel: +1 858 651 4478
Fax: +1 858 651 1102
Specification document(s):
http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)
Related information:
Specifies the mailbox of the agent responsible for the actual
transmission of the message.
2.1.4 Reply-To: header
Header name:
Reply-To
Description:
Mailbox for replies to message
Applicable protocol:
mail (http://www.rfc-editor.org/rfc/rfc2822.txt)
Status:
standards-track
Author/change controller:
Peter W. Resnick (mailto:presnick(_at_)qualcomm(_dot_)com)
QUALCOMM Incorporated, 5775 Morehouse Drive,
San Diego, CA 92121-1714, USA.
Tel: +1 858 651 4478
Fax: +1 858 651 1102
Specification document(s):
http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)
Related information:
When the R"eply-To: "field is present, it indicates the
mailbox(es) to which the author of the message suggests that
replies be sent.
All in all, Peter Resnick's full address appears 22 times in that
document. It shouldn't require any rocket science to include it once,
with
suitable pointers when required. Indeed, when there is an RFC mentioned
(as there usually is), then it should suffice to assume that the RFC
author is the responsible controller, except in special cases where he
isn't.
Again, it should not be necessary to give a full URL for an RFC. They
are
well known documents (and that URL is not the only place from which
they
can be retrieved). It should suffice for a preamble to the Registry to
explain the notation and how to obtain RFCs. And maybe a separate
references section containing the usual Bibliographic details for all
RFCs
mentioned in the registry.
But as it stands, there is so much wood that it is difficult to discern
the trees.
BTW, please note that there is now a new draft of Jacob Palme's list of
headers as draft-palme-mailext-headers-08.txt.
--
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_)clw(_dot_)cs(_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
<GK(_at_)NineByNine(_dot_)org>