ietf-822
[Top] [All Lists]

RE: Fwd: Last Call: Registration procedures for message header fields to BCP

2002-11-14 12:33:24

This is a fair observation. I would certainly agree to the extent that it would be more productive to focus efforts on improving the registry pages presentation.

I had been proceeding on the basis that the *formal* document to IANA to create the initial registrations would be an RFC, and that we would work with IANA "behind the scenes" to get that information into the initial registry set up in a way that IANA are comfortable with maintaining. Ultimately, I think the appropriate course is to do what is best for IANA.

#g
--

At 09:47 AM 11/14/02 -0800, Dan Kohn wrote:
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>

-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>


<Prev in Thread] Current Thread [Next in Thread>
  • RE: Fwd: Last Call: Registration procedures for message header fields to BCP, Graham Klyne <=