Graham Klyne | 30 Jan 2002 17:23

Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


Further to discussions here on IETF-822 last year, and some continuing 
offline discussions with interested parties, I've joined forces with Mark 
Nottingham and Jeffrey Mogul who had similar ideas for HTTP (see 
http://search.ietf.org/internet-drafts/draft-nottingham-http-header-reg-00.txt).

The result is an updated registry proposal, per the announcement below...

In summary, the proposal is for a pair of cross-protocol registries:  one 
for normative (standardized) message headers, and another for provisional 
(non-standardized) message headers.

#g
--

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Registration procedures for message headers
>         Author(s)       : G. Klyne et al.
>         Filename        : draft-klyne-msghdr-registry-02.txt
>         Pages           : 16
>         Date            : 29-Jan-02
>
>This specification defines registration procedures for the message
>headers used by Internet mail, HTTP, news and other applications.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-02.txt
(Continue reading)

Keith Moore | 30 Jan 2002 19:05
Picon

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


In general, I support the idea of a central (cross-protocol) header
field name registry, but I think it's totally unacceptable to confer 
any more legitimacy on nonstandard header fields, or to define a
procedure which would effectively allow parties to bypass the
established procedures for extending protocols that use these 
header fields. 

To this end, I strongly recommend that no Normative field be 
added to the registry without an IETF consensus process
(fields defined in existing IETF standards could be added with IESG
approval), and no Provisional field be added to the registry without
either IETF consensus or IESG approval.  

That way, we can document existing uses of header fields without 
creating a mechanism to "stake a claim" for new fields that are 
ill-advised, poorly designed, or poorly defined.

Keith

p.s. I'd also prefer "header fields" to "headers".  The header is the
structure at the beginning of an email message (NNTP message, 
HTTP message, whatever), and it is composed of zero or more fields.

Graham Klyne | 30 Jan 2002 19:22

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


At 01:05 PM 1/30/02 -0500, Keith Moore wrote:
>In general, I support the idea of a central (cross-protocol) header
>field name registry, but I think it's totally unacceptable to confer
>any more legitimacy on nonstandard header fields, or to define a
>procedure which would effectively allow parties to bypass the
>established procedures for extending protocols that use these
>header fields.

I accept the concern, and I/we have tried to be sensitive to it.

There is this disclaimer:
[[[
3.2.2 Provisional header template

    Registration as a Provisional Message Header does not imply any kind
    of endorsement by the IETF, IANA or any other body.
]]]

Would you prefer some stronger wording?

>To this end, I strongly recommend that no Normative field be
>added to the registry without an IETF consensus process
>(fields defined in existing IETF standards could be added with IESG
>approval),

Yes, that's the defined intent...

>  and no Provisional field be added to the registry without
>either IETF consensus or IESG approval.
(Continue reading)

Keith Moore | 30 Jan 2002 20:07
Picon

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


> At 01:05 PM 1/30/02 -0500, Keith Moore wrote:
> >In general, I support the idea of a central (cross-protocol) header
> >field name registry, but I think it's totally unacceptable to confer
> >any more legitimacy on nonstandard header fields, or to define a
> >procedure which would effectively allow parties to bypass the
> >established procedures for extending protocols that use these
> >header fields.
> 
> I accept the concern, and I/we have tried to be sensitive to it.
> 
> There is this disclaimer:
> [[[
> 3.2.2 Provisional header template
> 
>     Registration as a Provisional Message Header does not imply any kind
>     of endorsement by the IETF, IANA or any other body.
> ]]]
> 
> Would you prefer some stronger wording?

that's fine regarding the applicability of a field that has made it
into the registry - my concern is about allowing making it too easy
to introduce new fields into the registry.

> >  and no Provisional field be added to the registry without
> >either IETF consensus or IESG approval.
> 
> ... but folks who have expressed an interest in the provisional registry
> aspects have argued that not allowing a reasonably full coverage all
(Continue reading)

Graham Klyne | 30 Jan 2002 20:37

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


At 02:07 PM 1/30/02 -0500, Keith Moore wrote:
> > >  and no Provisional field be added to the registry without
> > >either IETF consensus or IESG approval.
> >
> > ... but folks who have expressed an interest in the provisional registry
> > aspects have argued that not allowing a reasonably full coverage all
> > headers, good and bad, would weaken the informative purpose of the
> > provisional registry.
>
>I am assuming that either IESG or a consensus process will approve
>additions to the registry for the "informative" purpose of documenting
>pre-existing practice. Jacob Palme's documents would make a good
>starting point for this.  The trick is to document existing practice
>without making it too easy to stake a claim for poorly chosen headers
>that don't exist yet.

I guess I'm having difficulty buying into your (apparent) premiss here, 
that the existence of a provisional registry will initiate a land-grab for 
header names.

I really should back off and see what other people think, but there's one 
more viewpoint I'd like to offer:  it could be argued that the existence of 
an open registry would have the opposite effect;  i.e. it could encourage 
developers with half-baked ideas to come together, pool their thoughts and 
come up with something more fully-baked?

To emphasize this, I'd be tempted to add something to the provisional 
registry disclaimer, along the lines of:
[[[
(Continue reading)

Keith Moore | 30 Jan 2002 22:52
Picon

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


At 02:07 PM 1/30/02 -0500, Keith Moore wrote:
> > > >  and no Provisional field be added to the registry without
> > > >either IETF consensus or IESG approval.
> > >
> > > ... but folks who have expressed an interest in the provisional registry
> > > aspects have argued that not allowing a reasonably full coverage all
> > > headers, good and bad, would weaken the informative purpose of the
> > > provisional registry.
> >
> >I am assuming that either IESG or a consensus process will approve
> >additions to the registry for the "informative" purpose of documenting
> >pre-existing practice. Jacob Palme's documents would make a good
> >starting point for this.  The trick is to document existing practice
> >without making it too easy to stake a claim for poorly chosen headers
> >that don't exist yet.
> 
> I guess I'm having difficulty buying into your (apparent) premiss here,
> that the existence of a provisional registry will initiate a land-grab for
> header names.

That's not quite what I'm worried about - it's more that the existence
of such a registry would effectively confer legitimacy on nonstandard
field names (even if the document defining the registry specifically
said otherwise) - both by making such field names more visible and by 
establishing a "claim" to particular field names.

> I really should back off and see what other people think, but there's one
> more viewpoint I'd like to offer:  it could be argued that the existence of
> an open registry would have the opposite effect;  i.e. it could encourage
(Continue reading)

Charles Lindsey | 31 Jan 2002 11:28
Picon
Picon

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


In <200201301805.g0UI51p09720 <at> astro.cs.utk.edu> Keith Moore <moore <at> cs.utk.edu> writes:

>p.s. I'd also prefer "header fields" to "headers".  The header is the
>structure at the beginning of an email message (NNTP message, 
>HTTP message, whatever), and it is composed of zero or more fields.

That is indeed the terminology defined in RFC 2822, but it is NOT the
terminology used in common parlance throughout Usenet and other places.

It is not the terminology used in RFC 1036 (though the actual terminology
there is a random mix of three different conventions :-( ). It is not the
terminology used in Son-of-1036, and it is not the terminology of the
present Usefor draft.

--

-- 
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.cs.man.ac.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

Dave Crocker | 31 Jan 2002 16:05

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


At 10:28 AM 1/31/2002 +0000, Charles Lindsey wrote:
>That is indeed the terminology defined in RFC 2822, but it is NOT the
>terminology used in common parlance throughout Usenet and other places.

other places includes common conversation around the net.  an individual 
"slot" is typically called a 'header'.  The set of them is typically called 
'headers'.

it would be very nice to have a better distinction than that one character, 
but we are not likely to change standard language at this juncture.

d/

----------
Dave Crocker  <mailto:dcrocker <at> brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Keith Moore | 31 Jan 2002 16:26
Picon

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


> >p.s. I'd also prefer "header fields" to "headers".  The header is the
> >structure at the beginning of an email message (NNTP message,
> >HTTP message, whatever), and it is composed of zero or more fields.
> 
> That is indeed the terminology defined in RFC 2822, but it is NOT the
> terminology used in common parlance throughout Usenet and other places.

Since the usefor draft is being revised, perhaps it affords an
opportunity to migrate toward more uniform terminology?

Keith

Arnt Gulbrandsen | 31 Jan 2002 16:50
Picon
Favicon
Gravatar

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt


It would appear that RFC2822 is the only document that uses a single,
well-defined terminology. Following 2822 ought to be a good idea, then.

--Arnt


Gmane