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

["Drage, Keith (Keith)" <[e-mail]>]

I think there is a good case for keeping normative statements in the bis
draft to SIP implementations (i.e. UAs, proxies, registrars, etc.).

If there is really a need for normative statements on SIP designers, then I
consider this should be in a separate RFC with a separate scope. 

I see no need for one document to normatively reference the other.

Therefore we do not need a reference in bis to the tsvar document, nor to
guidelines, nor do we need statements on publishing option-tags in standards
track RFCs.

Of course, it is not quite as simple as this. We do need some statements
about what an implementor implements when he hits token in the BNF, for
example.

Keith

Keith Drage
Lucent Technologies
Tel: [phone]
Email: [e-mail]

> ----------
> From: 	Allison Mankin[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	05 February 2002 16:27
> To: 	William Marshall
> Cc: 	[e-mail]; [e-mail]; [e-mail]
> Subject: 	Re: [Sip] Last Call comments on 2543bis-07 
> 
> 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