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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf