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

[Graham Klyne <[e-mail]>]

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:[e-mail]>
><http://www.dankohn.com/>  <tel:[phone]>
>
>   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:[e-mail]]
>Sent: Wednesday, November 13, 2002 06:21
>To: Charles Lindsey
>Cc: [e-mail]
>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.1.0.14.2.20021111161503.03e75360@127.0.0.1> Graham Klyne
> ><[e-mail]> 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:[e-mail])
> >       QUALCOMM Incorporated, 5775 Morehouse Drive,
> >       San Diego, CA 92121-1714, USA.
> >       Tel: [phone]
> >       Fax: [phone]
> >
> >    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:[e-mail])
> >       QUALCOMM Incorporated, 5775 Morehouse Drive,
> >       San Diego, CA 92121-1714, USA.
> >       Tel: [phone]
> >       Fax: [phone]
> >
> >    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: [phone] Fax: [phone]   Web:
> >http://www.cs.man.ac.uk/~chl
> >Email: [e-mail]      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
><[e-mail]>

-------------------
Graham Klyne
<[e-mail]>