Subject: [Sip] Mismatch in registry policy requirements of RFC 3969

From: Dean Willis <[email-masked]>
Date: Tue, 9 May 2006 13:54:08 -0500

RFC 3969 defines the registry for SIP/SIPS URI parameters.

It currently says:

4.2.  Registration Policy for SIP and SIPS URI Parameters

    As per the terminology in RFC 2434 [4], the registration policy for
    SIP and SIPS URI parameters shall be "Specification Required".

    For the purposes of this registry, the parameter for which IANA
    registration is requested MUST be defined by a standards-track RFC.

Note that the above two paragraphs seem to be self contradictory.  
"Specification Required" means 3GPP and recognized bodies can define  
parameters by publishing specifications. But"Standards Track RFC"  
means only IETF can do so, and it has to be done with an IETF- 
consensus standards-track document.

Note that the IANA registry currently says:

	SIP/SIPS URI Parameters RFC3969 Specification Required

	SIP/SIPS URI Parameters - per [RFC3969]
	(New registrations are via Specification Required)

This means that the current IANA policy for this registry is  
"Specification Required".

Which did we mean?

Personally, I lean toward the current interpretation, "Specification  
required", but I think we need to get this clarified (assuming we  
haven't already and I just forgot it, which happens).

--
Dean

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Mon, 15 May 2006 16:09:42 +0200

On May 9, 2006, at 8:54 PM, Dean Willis wrote:

> "Specification Required" means 3GPP and recognized bodies can  
> define parameters by publishing specifications. But"Standards Track  
> RFC" means only IETF can do so, and it has to be done with an IETF- 

We might want to check with Allison on history of this but my vague  
recollection was last time we discussed this, we decided we meant  
"Standards Track". I forget the details and may be totally wrong.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 May 2006 16:02:57 -0400

I'd suggest that it probably should be standards track. URI parameters 
are a bigger deal than headers, I think, since they are really making 
changes to the fundamental SIP addressing architecture. I don't think 
that is something we want everyone doing.

-Jonathan R.

Cullen Jennings wrote:

>>    FFrom [email-masked] Wed May 17 02:51:23 2006
Date: Tue, 16 May 2006 16:02:57 -0400
From: Jonathan Rosenberg <[email-masked]>
To: Cullen Jennings <[email-masked]>
Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969
Cc: SIP IETF <[email-masked]>, Dean Willis <[email-masked]>

I'd suggest that it probably should be standards track. URI parameters 
are a bigger deal than headers, I think, since they are really making 
changes to the fundamental SIP addressing architecture. I don't think 
that is something we want everyone doing.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 12:17:15 -0700

This is clearly a bug in the spec. Would it be possible for the  
chairs to drive this to WG consensus before or during next meeting,  
get someone to file an errata, and then I will ask for IESG to review  
and get IANA updated to match the errata. Sounds like a reasonable plan?

Cullen

On May 16, 2006, at 1:02 PM, Jonathan Rosenberg wrote:

> I'd suggest that it probably should be standards track. URI  
> parameters are a bigger deal than headers, I think, since they are  
> really making changes to the fundamental SIP addressing  
> architecture. I don't think that is something we want everyone doing.
>
> -Jonathan R.
>
> Cullen Jennings wrote:
>
>>> Note that the above two paragraphs seem to be self  
>>> contradictory.  "Specification Required" means 3GPP and  
>>> recognized bodies can  define parameters by publishing  
>>> specifications. But"Standards Track  RFC" means only IETF can do  
>>> so, and it has to be done with an IETF- consensus standards-track  
>>> document.
>>>
>> We might want to check with Allison on history of this but my  
>> vague  recollection was last time we discussed this, we decided we  
>> meant  "Standards Track". I forget the details and may be totally  
>> wrong.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 15:46:14 -0700

I'm glad to do that if the intent was relatively clear - if no one  
can remember what it was, then I would like to ask the WG what it  
should have been. I have not really tried to track down the history  
of this and find out if the intent was clear. If you want me to do  
that first, or have pointers to that, I will do that.

On May 22, 2006, at 3:26 PM, Dean Willis wrote:

>
> Normally all it takes is a note from the AD saying "The IESG's  
> intent was as specified by the second paragraph, standards-track  
> RFC required".
>
> But we'll be happy to drive to WG Consensus if you want. Shall we  
> document this in the form of an internet-draft?
>
> --
> Dean
>
>
> On May 22, 2006, at 2:17 PM, Cullen Jennings wrote:
>
>>
>> chairs to drive this to WG consensus before or during next  
>> meeting, get someone to file an errata, and then I will ask for  
>> IESG to review and get IANA updated to match the errata. Sounds  
>> like a reasonable plan?
>>
>> Cullen
>>
>>
>>> parameters are a bigger deal than headers, I think, since they  
>>> are really making changes to the fundamental SIP addressing  
>>>>> specifications. But"Standards Track  RFC" means only IETF can  
>>>>> do so, and it has to be done with an IETF- consensus standards- 
>>>>> track document.
>>>>>
>>>> vague  recollection was last time we discussed this, we decided  
>>>> we meant  "Standards Track". I forget the details and may be  
>>>> totally wrong.

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 May 2006 17:26:33 -0500

Normally all it takes is a note from the AD saying "The IESG's intent  
was as specified by the second paragraph, standards-track RFC required".

--
Dean

On May 22, 2006, at 2:17 PM, Cullen Jennings wrote:

> get someone to file an errata, and then I will ask for IESG to  
> review and get IANA updated to match the errata. Sounds like a  
> reasonable plan?
>
> Cullen
>
>
>>>> so, and it has to be done with an IETF- consensus standards- 
>>>> track document.
>>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 26 May 2006 16:00:45 +0300

Hi,

the conclusion was the IETF wanted to have tighter control on SIP URI 
parameters than on header field parameters. Therefore, one would need a 
standards-track RFC in order to create new SIP URI parameters... that 
was the intent.

Cheers,

Gonzalo

Cullen Jennings wrote:
> 
> I'm glad to do that if the intent was relatively clear - if no one can 
> remember what it was, then I would like to ask the WG what it should 
> have been. I have not really tried to track down the history of this and 
> find out if the intent was clear. If you want me to do that first, or 
> have pointers to that, I will do that.
> 
> 
>>>>>> define parameters by publishing specifications. But"Standards 
>>>>>> Track  RFC" means only IETF can do so, and it has to be done with 
>>>>>> an IETF- consensus standards-track document.
>>>>>>
>>>> --Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Aki Niemi <[email-masked]>
Date: Mon, 29 May 2006 10:05:41 +0300

> standards-track RFC in order to create new SIP URI parameters... that

Believing this gives the WG tighter control is a delusion. Similarly,
one could set the speedlimit on highways to 2 miles or 5 kilometers an
hour, and sit and watch everyone breaking it.

I think all this does is it makes people who need URI parameters go
underground. And that makes interop worse, not better. It also all but
guarantees the SIP* working groups will be flooded with trivial
specifications of extension parameters, over which we will be able to
have many entertaining but utterly useless debates.

I'll also note that in the end, the only people who will even attempt to
abide by these types of policies are other SDOs because they sort of
have to; everyone else in the industry won't pay any attention.

I was of the opinion way back when this was discussed the last time, but
remember being in the minority.

Cheers,
Aki

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 May 2006 06:20:04 -0700

Sorry, I did not mean to imply an I-D get created. I was just hoping  
that the chairs could figure out what the WG thinks about this. This  
could be based either on some new email or old email. It's not clear  
to me if the WG ever did decide this or not and if they did, I'm not  
trying to overturn some previous decision. I don't really see this as  
an IESG decision as much as something the WG should have rough  
consensus on and the IESG can check for sanity and approve.

A single paragraph in email that said what the WG wanted supported  
why this was the decision would be great. I will pass that by the  
IESG and make sure no one objects and then get IANA to make the  
change. If someone wanted to bother to file an errata on the RFC that  
would be a bonus.

Cullen