Subject: RE: [Sip] Last Call comments on 2543bis-07

From: William Marshall <[email-masked]>
Date: Tue, 5 Feb 2002 10:54:20 -0500 (EST)

Brian,

As I understand the procedures and concerns, a normative
references to draft-tsvarea-sipchange would hold
bis in the RFC Editor's queue, which would delay the actual
publication of bis as an RFC.  It would not delay the assigning 
of an RFC number, which is what 3GPP wants on March 7.

I'm not at all clear on how the RFC Editor will handle
non-normative references to internet-drafts, like [30]
SIP telephony call flow examples.  If publication as an
RFC "freezes" the text, then they may hold it in the queue
for this, too.  But again, it won't delay the assignment
of an RFC number for 3GPP.

The specific text in bis-07 leading to this discussion is
regarding option tags that MUST be defined in standards-
track RFCs.  There is no reason that needs to be a normative
reference.  It actually falls into the category of "untestable"
uses of spec language.  It would best be left out.

Bill Marshall
[email-masked]

-----original message-----
From: "Rosen, Brian" <[email-masked]>
To: "'Robert Sparks'" <[email-masked]>,
        William Marshall <[email-masked]>
Cc: [email-masked]
Subject: RE: [Sip] Last Call comments on 2543bis-07
Date: Tue, 5 Feb 2002 10:32:03 -0500 

> > 2) Carriers are unfortunately obliged to meet regulatory 
> requirements.
> > At least some of these, related to Electronic Surveillance, will not
> > be standardized by IETF (see RFC 2804), though publication is 
> > encouraged (presumably as informational RFCs).  However, 
> they may require
> > extensions to SIP, and definition of additional headers and 
> option tags.  
> > It would be unfortunate if this resulting protocol could 
> not be called 
> > SIP.  This is an ugly subject, granted, and I do not want 
> it to delay 
> > publication of bis as an RFC.  My proposed resolution of this is
> > to have bis make reference to draft-tsvarea-sipchange-xx for the
> > guidelines of extensions being standard-track RFCs, and have the 
> > discussion when that draft is re-issued and last-called.
> > Affects lines 1094-7, 1103-4, 1306-7
> 
> 
> I'll let the chairs comment on this.
> 
This chair wouldn't allow bis to be held because of a normative reference
to tsvarea-sipchange, but wouldn't object if that was not a problem.

Brian

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Allison Mankin <[email-masked]>
Date: Tue, 05 Feb 2002 11:27:40 -0500

Folks,

> of an RFC number for 3GPP.

The early RFC number procedure from RFC Editor is a favor, and
we would not like to push it by having normative references to i-ds
in there when we send them the approved bis i-d.

This is something that I'm planning to review with the chairs and
editors before 08.

As Scott says, we can* probably word a reference to the tsvarea-
sipchange draft to be non-normative.  

> uses of spec language.  It would best be left out.

I have some trouble agreeing that option tag extensibility rules
can't be made testable. 

What would your reaction be to registering headers that IETF has 
not published in standard track or will not publish (such as the
Electronic Surveillance ones you mention) in an x- category?

Allison

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Feb 2002 11:47:20 -0500

> Electronic Surveillance ones you mention) in an x- category?

From my vantage point, designating headers with a special prefix has
been an unmitigated disaster in the past twenty years. Witness email.
People pick random names, without registration, which then partially end
up being folded into standards, yet maintain the X- designation or get
documented (see Palme's documents). In addition, since there's no
coordination, we get collisions and have to deal with things like
whether X-Foo and Foo are the same thing. (Again, see email, if you need
examples.)

What's wrong with having IANA register regular header names, with no
more normative strength or endorsement of their moral or technical value
than having IANA register port numbers for random commercial
applications or enterprise IDs or any of the other myriad non-standard
protocol parts that IANA deals with? There are only 65,000 port numbers,
there is an almost infinite supply of header names, so this is not a
resource that is likely to become extremely scarce, as long as people
don't get the idea that they need to register vanity header names.

Thus, Bill can register "Monitored-By" to satisfy his favorite
three-letter agency RFP, but all i would say is in the IANA table

Monitored-By   William Marshall

plus suitable contact information.

What is the advantage of bypassing a well-established entity like IANA?

Henning