From: Graham Klyne (Graham.Klyne@MIMEsweeper.com)
Date: Mon Dec 31 2001 - 16:01:07 CST
At 08:02 PM 12/31/01 +0000, Charles Lindsey wrote:
> On Mon, 31 Dec 2001 11:29:05 +0000
> Graham Klyne <Graham.Klyne@MIMEsweeper.com> said...
>
> > I had some discussions at the last IETF meeting about this draft [1], and
> > have been encouraged (in addition to Charles' helpful review comments) to
> > proceed along the lines of a two-part registry:
> >
> > - "standard" headers for which some degree of uniqueness is required,
> > defined under something like "IETF consensus" rules, and
> >
> > - other headers, for which there is no uniqueness requirement and a
> > prominent health warning that says something like "entries in this
> registry
> > are for information only, and don't constitute any kind of standard; use
> > them at your own risk".
>
>Yes, that makes some kind of sense. The exact nature of the boundary
>between them may be tricky to define, but that is for the discussion.
Hmmm... that boundary bit seems quite straightforward to me: RFC 2434
contains a fairly clear-cut description of "IETF Consensus" as a criterion
for registration.
> > One of the issues that has been stalling me from making progress is the
> > extent to which the header namespaces are protocol-specific (mail, news,
> > web, SIP, etc.) and the extent to which they can be regarded as a common
> > namespace (the common MIME elements). Following some recent discussions I
> > have come (reluctantly) to the view that the namespaces must be
> regarded as
> > separate, but sharing many common elements (notably the MIME headers, but
> > others. Thus, I think the "standard" part of the header registry will
> need
> > to indicate the protocol(s) for which the header is defined, where one
> > option would be "common" or "all"; thus the same header name may appear
> > separately for different protocols, and the combination of protocol+name
> > must be unique in the registry.
>
>I think that is exactly right. For each header, the registry says
>something about each protocol for which it is to be considered
>appropriate. But then it has to refer to some defining RFC (or
>whatever). However, I think you actually need both a "primary"
>definition and a "secondary" definition in some cases.
Hmmm... I don't see it in terms of "primary" and "secondary".
Rather, for any header that is registered as a "standard" header, the
specification must indicate the protocol(s) for which it is considered a
standard. For any combination of header-name and protocol, there can be at
most one registration. It may be that the defining document is different
for a given header in different protocols...
>For example, copnsider the From header, as used in news.
>
>The primary definition is RFC 2822. But you need USEFOR as a secondary
>definition, since it makes some slight syntactic changes (the "obsolete"
>syntax from RFC 2822 is no longer REQUIRED, but there is extra provision
>for some parts of it - comments and phrases, but not addresses - to use
>characters from UTF-8, and there are also some additional exhortations
>about munging addresses). The same applies to MIME, where USEFOR
>adopts it en bloc, but then goes on to mention a few extra details and
>conventions. So a persopn who consults the registry needs to be directed
>to both sources if he wants the full story.
... in this case, I would say that the specification for From: in email is
per RFC 2822, but for use in news, RFC 2822 as modified by USEFOR must be
considered. This approach seems more clear-cut to me.
> > PS: I'm not subscribed to the USEFOR list, so can you please cc me on any
> > direct responses. Thanks.
>
>OK, I shall try and remember to do that. But you are welcome to join our
>list. All you have to do is email usenet-format-request@landfield.com.
Well, at a time when I'm trying to reduce rather than increase my mailing
list subscriptions, I'm hoping this will not be a long-running exchange in
this forum ;-) I think IETF-822 is the appropriate list for discussion of
the registry draft.
#g
------------------------------------------------------------
Graham Klyne MIMEsweeper Group
Strategic Research <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
__
/\ \
/ \ \
/ /\ \ \
/ / /\ \ \
/ / /__\_\ \
/ / /________\
\/___________/