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

[William Marshall <[e-mail]>]

Allison wrote:
> 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?

IANA registration of the option tags and header names is far preferred 
to the haphazard naming of X- headers in email.

So whether the option tags and header names start with X-, or start
with z9hG4bK, or anything else, the important part is the registration
with IANA so that there are no conflicting uses of the same option
name or header name.

Provided the x- category guarantees the same uniqueness as other
category tags, I'd be happy with this resolution.

Simply identifying the headers and options as non-standards-track in
the IANA registration is also fine.  My complaint is with the 
wording which appeared first in bis-05 that the extension MUST be 
defined in a standards-track RFC.  As noted, certain extensions 
can't be defined that way.  Bis-00 through bis-04 did not have 
this restriction.

Bill Marshall
[e-mail]

-----original message-----
To: William Marshall <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [Sip] Last Call comments on 2543bis-07 
Date: Tue, 05 Feb 2002 11:27:40 -0500
From: Allison Mankin <[e-mail]>

Folks,

Brian Rosen wrote:
> > 
> > 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.
> 

Bill Marshall wrote: 
> 
> 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 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.  

Bill continued:
> 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.
> 

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



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


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