I was not passing judgement on the guidance presented in draft-tsvarea-sipchange. I was pointing out that a document cited as a reference in draft-iab-considerations is effectively contradicted. (My proposed solution was not intended as an endorsement; it was based on what appeared to be the most expedient way to address the inconsistency, giving precedence to the more established document). I also am not going to make a statement about your comments themselves; however, I suggest that they would be most productively directed to the authors of the draft-tsvarea-sipchange document. In any case, I assert that there is an inconsistency, and that a prudent course of action would involve reaching consensus on these issues before either document is published as an RFC. /a > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Friday, September 06, 2002 11:39 > To: Adam Roach > Cc: 'floyd@icir.org'; 'ietf@ietf.org' > Subject: Re: Impending publication: draft-iab-considerations-02.txt > > > Date: Fri, 6 Sep 2002 10:11:01 -0500 > From: Adam Roach <adam@dynamicsoft.com> > Message-ID: > <9BF66EBF6BEFD942915B4D4D45C051F3A640ED@DYN-TX-EXCH-001.dynami > csoft.com> > > | On the topic of "P-" headers, however, there is still > guidance that > | such extensions require, at a minimum, publication as an RFC: > | > | "[A]ny P-header used outside of a very restricted > research or teaching > | environment (such as a student lab on implementing > extensions) MUST > | meet those requirements and MUST be documented in an > RFC and be IANA > | registered." > > This kind of text in any RFC (or other publication) is no more than an > attempt at extortion. Nothing published in an RFC can > possibly constrain > what anyone else does, anywhere. Believing otherwise is ludicrous. > > We can constrain our own behaviour, since that's what we > control, so we > could (assuming that we believe IANA is part of "us") specify > that IANA > must not register a header unless it is documented in an RFC. But we > cannot tell people that they're not allowed to use such > things. Or more > correctly, of course we can tell them that, but without any > expectation > that many of them will take us seriously. > > Whether or not the IETF decides that it should adopt work > done by others > (even just as much as re-publishing it for information) will > be something > that should get decided on a case by case basis (or as agreed > with other > bodies in appropriate circumstances), but pretending that the > IETF is the > supreme lord of the universe, and everyone else must bow down to the > pronouncements in RFCs (even in cases where IETF created technology is > under discussion) is laughable. > > kre >