I had some email outage and only saw this after today's IESG
Evaluation, sorry.
I didn't see consensus for a particular change as a result of this
conversation. There was widespread agreement that X-headers are
messy, but not what to say about them.
Lisa
On May 21, 2008, at 7:22 PM, Brian E Carpenter wrote:
Lisa,
Could you let us see your summary of the discussion about
(not) documenting the X-headers? I haven't seen any further
comments since Dave's message below, and it appears that the
IESG is ballotting on the document now.
Regards
Brian
On 2008-04-08 06:34, Dave Crocker wrote:
Pete Resnick wrote:
(1) Partially restore the 822 text, stressing "private use", rather
than "experiental".
I don't think we'll be able to do this; see (3) below.
...
(3) Encourage X-headers for strictly private use, i.e., they SHOULD
NOT be used in any context in which interchange or communication
about independent systems is anticipated and therefore SHOULD NOT
be
registered under 3683.
I think this is DOA. There are many folks (myself included) who
think
this should not be encouraged in any way, shape, or form.
Folks,
One of the lessons of the community's 30+ years of protocol work is
that
specification details which are actually usage guidance, rather
than concrete
interoperability details, often have little impact on a global
community. The
community formulates its own preferences.
When X- as original proposed, I thought it was marvelously clever.
I still do.
But it doesn't work.
While it does protect a privately-developed header field label from
being
preempted by a standards process, it creates a much more serious
problem of
moving from private-use to public standards and having to (try to)
re-label the
field. This is a highly disruptive impact./
In other words, if the model is true that existing practices get
standardized --
and in this realm they often are, I think -- then we need to design
things to
make the transition from private-to-public be comfortable.
Defining a
private-use naming space runs counter to that goal.
Valuable lesson. We should learn it.
d/
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf