Re: X-* header fields (Was: Getting 2822 to Draft)
2004-01-06 00:19:13
Pete Resnick wrote:
On 1/4/04 at 2:54 AM -0500, Bruce Lilly wrote:
Pete Resnick wrote:
The only difference then between 822 and 2822 in this respect is
that 822 gives publication guidelines for extensions where 2822 does
not. This has absolutely *no* effect on implementations of the
protocol.
There is a minor effect. A user-defined field (per 822 definition)
can be recognized as such by examining the first two octets of the
field name, which is quite efficient.
But *why* would an implementation care about the publication
guidelines for the field? That's the *only* thing "X-" tells you.
An implementation *might* be written so as to hand off parsing of X-
fields to a separate
procedure, or ignore them entirely. And the ability to efficiently
bypass checking against
the 100+ standardized field names *might* be considered important.
[my implementation does hand off most X- fields (one notable exception
being X-Accept-Language)
and unrecognized (in this case anything not standardized in an RFC or an
Internet Draft that
seems likely to become an RFC) to optional user-supplied functions.
Separate functions may
be specified for unrecognized X- (user-defined) fields and for
unrecognized extension fields
(or the application can point to a single function). Were it not for
handling X-Accept-Language,
I might have elected to bypass lookup for standard field names (via
gperf) in the case of user-
defined fields.]
"X-" serves to differentiate user-defined fields from non-defined
fields (i.e. those field names for which there is no IETF published
definition or which the implementation does not recognize).
Again, what use is there in making that distinction? Do you think the
fact that "X-Priority" and "X-Face" start with "X-" means that you
shouldn't support them in your implementation or they don't have
well-defined syntax? What about "X-Sender"?
I don't support them because I haven't found a specification for them in
any RFC.
Is "List-ID" a non-defined field if your implementation doesn't
recognize it? What useful purpose is there in differentiating fields
which start with "X-"?
I do recognize and support List-ID (RFC 2919). Flexibility is one
reason to differentiate;
because RFC 822 made the distinction, it is conceivable that some
message-processing
application may wish to treat user-defined and non-standard extension
fields differently.
By providing for separate function pointers for the two cases, an
application using the mparse
library can either treat them differently (using distinct function
pointers) or treat them
identically (by providing two pointers to a single function).
In order to be at all useful to implementors, registration would have
to be contingent upon the existence of a stable, formal, public
definition of the proposed field's syntax (with ABNF) and semantics.
Nonsense. It is useful to an implementation (especially an
implementation that generates fields) to know that a field exists for
a particular purpose even if its syntax and semantics have not
undergone extensive review and comment or are still under development.
It is by implementation that fields get stable and then they can be
documented as standards.
Example:
somebody registers a "Foo" field, but provides no public syntax or
semantics. As an implementor,
what am I supposed to do about "Foo"?
It's difficult to see how such problems are either unique to X- or
are more of a hindrance to interoperability than for other fields. As
an example, consider "Status" which was in "private" use (I believe)
by BSD "mailx" decades ago, and which is currently in use by several
other MUAs, and which *does* leak out; there is also a formal
definition of a "Status" field -- incompatible with the private usage
-- defined as one of the delivery status notification fields (RFC
3464). So neither leakage nor incompatibility seem to be unique to X-
fields. Note that if BSD mailx' author(s) had used X-Status for
private use, there would be no conflict with the formal DSN Status
field.
First of all, the "Status" field of DSN is not defined to appear in a
top-level header of a [2]822 message, so there is no "incompatibility"
between the two. But let's talk about the leakage: Yes, the "Status"
field leaks. Now, what can be done about that? Well, it could be
documented in an RFC so that everyone could know what it means. And if
turned out useful, it could be a standardized top-level header field.
But what if mailx's author had instead used "X-Status"? In that case,
it's DOA, because by definition it could not be documented in a
standard way. So there is no way for an implementor to figure out what
"X-Status" means other than by word of mouth. That invites
incompatibility. So what exactly would that "X-" have gained you?
My implementation -- and I believe that it is not unique in this respect
-- parses a field with
a given name depending on that name and not specifically on its
context. The incompatibility
is that the DSN Status field has a specific syntax for the field body
(viz. three dot-separated
numbers) which is not matched by the BSD et al usage of Status (a string
of alphabetic characters).
A single field name with two different syntax definitions (and different
semantics) would IMO
be a bad thing, even if theoretically they could be differentiated by
context; header fields do
occasionally end up in message bodies due to some software inserting an
empty line, and that
empty line may cause top-level message headers moved into the body to
appear to be MIME-part
fields (i.e. if the message header still contains an appropriate
Content-Type field). Mailx uses
Status to store state metadata about the mail store, which is a private
use. X-Status could be
documented (e.g. via an Informative RFC), but not registered with IANA
as an extension field,
though *as* private use, there would be no reason to document it (given
that X- guarantees no
collision with any future registered extension field). The only reason
for an implementor to care
about a hypothetical X-Status field is if said implementor had reason to
interact with a message
store on a system that also used mailx with that message store -- that's
a storage issue, not a message
format or transmission issue and therefore an issue outside of the scope
of IETF. So X-Status would
not "invite incompatibility" in any sense in which it matters to IETF.
There is one very good reason to use X- for private or experimental
use, viz. interoperability. Use of X- as a field name prefix for
private or experimental use guarantees that there will be no conflict
with a formal field name. Use of other names can lead to conflicts
No it doesn't. Some "X-" field names are now just as formal as some
non-"X-" field names.[...]
"[J]ust as formal"? Really? Which X- field names are defined in
Standards-track RFCs? For that
matter which X- field names are defined in *any* RFC? Or by "non-'X-'
field names" do you
mean something other than registered extension field names?
An issue not mentioned above is migration of X- fields to a formal
definition following successful experimental use. That obviously
entails a name change. However name changes are not uncommon, e.g.
refer to the MIXER RFCs, which define a number of fields whose names
have changed. That merely means that parsers need to recognize one
name as a synonym for another.
But what about generators? Because there will be parsers out there
that will only interpret the "X-" form of the field, the generators
must continue to send the "X-" form. Furthermore, updating some
parsers is non-trivial.
By the same argument, generators will have to generate multiple versions
with a single non-X- name
as syntax changes during experimentation. Presumably those
participating in an experiment have a
vested interest in moving forward with an official implementation at the
end of the period of experimentation.
Whether or not some parsers are difficult to update is irrelevant to the
issue; if a parser can be updated to
handle Obsoletes/Supersedes, Expiry-Date/Expires,
Content-Identifier/X400-Content-Identifier, etc., then
it can be updated to handle X-Accept-Language/Accept-Language.
Conversely if it cannot be updated
to handle X-Accept-Language/Accept-Language, then presumably it cannot
handle the other (standard)
fields whose field names have been changed.
pr
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: X-* header fields (Was: Getting 2822 to Draft), (continued)
- Re: X-* header fields (Was: Getting 2822 to Draft), Bruce Lilly
- Re: X-* header fields (Was: Getting 2822 to Draft), Pete Resnick
- Re: X-* header fields (Was: Getting 2822 to Draft), Keith Moore
- Re: X-* header fields, Kai Henningsen
- Re: X-* header fields, Keith Moore
- Re: X-* header fields, Russ Allbery
- Re: X-* header fields, Keith Moore
- Re: X-* header fields, ned+ietf-822
- Re: X-* header fields (Was: Getting 2822 to Draft),
Bruce Lilly <=
- Re: X-* header fields (Was: Getting 2822 to Draft), Paul Smith
- Re: X-* header fields, Kai Henningsen
- Re: X-* header fields, Bruce Lilly
- Re: X-* header fields (Was: Getting 2822 to Draft), Adam M. Costello
- Re: X-* header fields (Was: Getting 2822 to Draft), Keith Moore
- Re: X-* header fields, Bruce Lilly
- Re: X-* header fields, Charles Lindsey
- Re: X-* header fields, Russ Allbery
- Re: X-* header fields, Bruce Lilly
- Re: X-* header fields, ned+ietf-822
|
|
|