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

From: "Rosen, Brian" <[email-masked]>
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

*********This message is definitely not confidential and it does not matter
in practice who sees it and whether or not it goes astray. No harm whatever
would come to anyone even if it were published in a national newspaper. I
apologies therefore for the unnecessary and irritating message that may or
may not follow (I don't know because it is invisible to me)!!!!******

This e-mail and any attachments are confidential. If you are not the
intended recipient, please notify us immediately by reply e-mail and then
delete this message from your system. Do not copy this e-mail or any
attachment, use the contents for any purposes, or disclose the contents to
any other person: to do so could be a breach of confidence.

_______________________________________________
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: Scott Bradner <[email-masked]>
Date: Tue, 5 Feb 2002 11:04:35 -0500 (EST)

> to tsvarea-sipchange, but wouldn't object if that was not a problem.

I expect things could be worded so it was not a normative reference

Scott

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 5 Feb 2002 12:48:18 -0500

We have a provision for private package registration in Megaco.  All this
does is reserve the package name -- no details have to be provided about the
package itself.  Our rules also tend to separate the name spaces for the
public and private packages respectively.

-----Original Message-----
From: Allison Mankin [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 5:28 PM
To: William Marshall
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip] Last Call comments on 2543bis-07 

snip ...

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: Scott Bradner <[email-masked]>
Date: Tue, 5 Feb 2002 14:06:07 -0500 (EST)

> I'm not at all clear on how the RFC Editor will handle
> non-normative references to internet-drafts,

they publish the document - the reference would be to a "work in progress"

Scott

---

From: William Marshall <[email-masked]>
Date: Tue, 5 Feb 2002 23:01:13 -0500 (EST)

> 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
[email-masked]

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

Folks,

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.
> 
> 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. 

Allison

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 7 Feb 2002 18:22:54 -0000

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: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Allison Mankin[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	05 February 2002 16:27
> To: 	William Marshall

---

From: William Marshall <[email-masked]>
Date: Fri, 8 Feb 2002 14:59:11 -0500 (EST)

Jonathan wrote (complete email message attached below):
> I suspect the right thing might be to move such things [requirements
> on future specifications, not on implementations] into
> draft-ietf-sip-guidelines. Indeed, the particular bit about generic
> header formats is already in there. That document would serve as the SIP
> working groups measuring stick when reviewing drafts (preferably in
> advance of wglc). 
> 
> Anyone object to moving these types of references there? We'll need a
> volunteer to do a clean sweep of bis to find them all.
> 

Since I didn't hear any objections, I made another clean sweep of bis-07
looking for them.  Following are my recommended changes for bis-08.
These change avoid any references to tsvarea-sipchange.

line 777-8, on page 20 in pdf file, section 7.1:
	SIP extensions, documented in standards track RFCs, may define
	additional methods.
  change to:
	SIP extensions may define additional methods.

line 889-890, on page 23 in pdf file, section 7.3.1
	All new header fields MUST follow this generic format unless they
	have been inherited from other RFC 2822-like specifications.
  change to:
	All new header fields follow this generic format unless they
	have been inherited from other RFC 2822-like specifications.

line 1094-97, on page 29 in pdf file, section 8.1.1.9
	The option-tags listed MUST only refer to extensions defined in
	standards-track RFCs. 
  delete entire paragraph

line 1103-4, on page 29 in pdf file, section 8.1.1.9
	As with the Supported header, the option-tags in the Require header
	MUST only refer to extensions defined instandards-track RFCs.
  delete this single-sentence paragraph

line 1298, on page 34 of pdf file, section 8.2.4
	To ensure that the SHOULD can be fulfilled, any specification of 
	a new extension MUST include discussion of how to return gracefully 
	to baseline SIP when the extension is not present.
  change to:
	To ensure that the SHOULD can be fulfilled, any specification of 
	a new extension includes a discussion of how to return gracefully 
	to baseline SIP when the extension is not present.

line 1306, on page 34 of pdf file, section 8.2.4
	As a result of this, the Require header in a response will only ever
	contain option tags defined in standards-track RFCs.
  delete the sentence

line 1468, on page 38 of pdf file, section 9.2
	Extensions to this specification that define new methods MUST define
	the behavior of a UAS upon reception of a CANCEL for those methods.
  change to:
	Extensions to this specification that define new methods define
	the behavior of a UAS upon reception of a CANCEL for those methods.

line 2040-1, on page 53 of pdf file, section 13.2
	However, those extensions MUST adhere to the protocol rules specified
	in [2], and MUST adhere to the additional constraints in the list 
	above.
  change to:
	However, those extensions adhere to the protocol rules specified
	in [2], and adhere to the additional constraints in the list 
	above.

line 3141-2, on page 83 of pdf file, section 17.1
	Protocol extensions which require longer durations for generation of 
	a response (such as a new method that does require human interaction) 
	SHOULD instead use two transactions - one to send the request, and 
	another in the reverse direction to convey the results of the request.
  change to:
	Protocol extensions which require longer durations for generation of 
	a response (such as a new method that does require human interaction) 
	will instead use two transactions - one to send the request, and 
	another in the reverse direction to convey the results of the request.

line 5284-5, on page 144 of pdf file, section 24.33
	A UAC compliant to this specification MUST only include option tags 
	corresponding to standards-track RFCs.
  delete this sentence

line 5328, on page 145 of pdf file, section 24.39
	A UA compliant to this specification MUST only include option tags 
	corresponding to standards-track RFCs.
  delete this sentence

line 6056-7, on page 178 of pdf file, section 28.1
	The name MAY be of any length, but SHOULD be no more than twenty 
	characters long.  The name MUST consist of alphanum (Section 27) 
	characters only.
  change to:
	The name may be of any length, but should be no more than twenty 
	characters long.  The name consists of alphanum (Section 27) 
	characters only.

line 6059, on page 178 of pdf file, section 28.1
	A SIP option MUST NOT redefine header fields or parameters defined 
	in either RFC2543, any standards-track extensions to RFC2543, or 
	other extensions registered through IANA.
  change to:
	A SIP option cannot redefine header fields or parameters defined 
	in either RFC2543, any standards-track extensions to RFC2543, or 
	other extensions registered through IANA.

Bill Marshall
[email-masked]

-----original message-----
Date: Tue, 05 Feb 2002 12:25:41 -0500
From: Jonathan Rosenberg <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Sip] Last Call comments on 2543bis-07

William Marshall wrote:
> 
> Henning Schulzrinne wrote:
> > Robert Sparks wrote:
> > > This class of requirement is obviously on future specifications, not
> > > implementations. As such, you could argue that they belong in the
> > > guidelines draft. I would have no problem moving the three examples
> you
> > > present here, but I get the feeling that this isn't a complete list.
> Is
> > > requirements on future extensions the _only_ class of requirements
> > > giving you trouble?
> >
> > My suggestion is that all of them should move into or close to the
> IANA
> > sections, since they are needed by things that need IANA registration
> in
> > any event. The section can then be prefixed by a "this is for
> specifying
> > compliancy of protocol designers, not implementations" (obviously, not
> > worded that way...)
> 
> This suggestion works fine for me.  I'd then re-word the lines where
> the spec words now appear as simple statements of fact, e.g.. "All
> new header fields follow this generic format..."

IANA is not going to look at this, I suspect. I dont think it is their
job to check that extensions follow particular BNF patterns.

I suspect the right thing might be to move such things into
draft-ietf-sip-guidelines. Indeed, the particular bit about generic
header formats is already in there. That document would serve as the SIP
working groups measuring stick when reviewing drafts (preferably in
advance of wglc). 

Anyone object to moving these types of references there? We'll need a
volunteer to do a clean sweep of bis to find them all.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com