Subject: [Sip] WGLC for URI and Header Parameter Registries

From: Rohan Mahy <[email-masked]>
Date: Sat, 11 Oct 2003 10:54:07 -0700

Hello Everyone,

I'd like to begin Working Group Last Call on:

http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry- 
00.txt

	and

http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-parameter-reg- 
00.txt

As agreed at IETF57, the draft will contain a registry of the standard  
parameters.  The group could not come to consensus on whether to  
register non-standard parameters, so we will address this issue at a  
later date.  Please send your comments to the list.

This WGLC ends Oct 31, 2003.

many thanks,
-rohan

_______________________________________________
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: Aki Niemi <[email-masked]>
Date: Mon, 13 Oct 2003 19:03:01 +0300

Hi,

I have a couple of comments to these drafts. I'm not at all against a 
registry for header/URI parameters, I think they are an excellent idea. 
I just think these drafts are incomplete. You can't set up a registry 
without specifying the policy by which the names and numbers in that 
registry get assigned.

For example, the below drafts currently seem to state that header/URI 
parameters are allocated as Specification Required (as per policies in 
RFC2343), i.e., you need an RFC. However, it doesn't state that 
explicitly. It might also be saying that they are allocated based on 
IETF Consensus, or even Standards Action. Simply stating "RFC" isn't enough.

Then to the question of what would be proper policy.

I think a proper policy here would be First Come First Served, or 
something like that. I don't think it's a good idea to require a 
published RFC for all parameters. For example, event package names are 
allocated as First Come First Served and don't require an RFC. Event 
packages can also define event header parameters - why should they 
require an RFC when the package itself didn't?

Also, a nit: the "id" Event header parameter is missing from the initial 
list of header params.

	-- Aki Niemi

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 16 Oct 2003 16:15:38 +0300

Aki,

the policy you are talking about is exactly what the WG could not agree 
on. The conclusion was that, for the time being, we will start keeping 
track of RFC-defined parameters (the two drafts under WGLC). Meanwhile, 
we will work on the proper policy to use in the future. For example, if 
someone defines a SIP parameter in a Nokia technical report, it is OK to 
register it or not... we will count with you for those discussions ;o)

 > Also, a nit: the "id" Event header parameter is missing from the initial

Thanks for pointing this out.

Gonzalo

Aki Niemi wrote:

>> As agreed at IETF57, the draft will contain a registry of the 
>> standard  parameters.  The group could not come to consensus on 
>> whether to  register non-standard parameters, so we will address this 
>> issue at a  later date.  Please send your comments to the list.
>>

-- 
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: Dean Willis <[email-masked]>
Date: Thu, 16 Oct 2003 12:36:18 -0500

> register it or not... we will count with you for those discussions ;o)

I think, though, that we have to have some statement of policy in the
draft before sending this up to IESG. We can, of course, change the
policy later, so I'd suggest starting with the most restrictive langauge
and loosening up later if it seems important.

I would not now object to to a policy that says roughly "IANA registered
paramters must be defined by an IETF specification" but retains the
ability to use non-registered parameters without being "in violation of
the specification." The logic is "If a parameter is IANA registered, it
is a reserved word and has special meanings that we expect to be
globally relevant. If a parameter is NOT registered, it's a personal
matter."

I think we want the barrier somewhat high for the declaration of a new
"reserved word" in our vocabulary.

--
Dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 16 Oct 2003 23:01:34 +0300

Dean,

It sounds good to me. Could you provide a paragraph that summarizes what 
you just proposed? I will add it into the draft.

Thanks,

Gonzalo

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Oct 2003 18:20:44 -0500

> you just proposed? I will add it into the draft.

Citing RFC 2434:

       "Specification Required - Values and their meaning must be
       documented in an RFC or other permanent and readily available
       reference, in sufficient detail so that interoperability
       between independent implementations is possible."

Ok -- mightconsider applying it to both reg drafts.

Revise and extend "Use of the Registry"

3 Use of the Registry

    SIP and SIPS URI Parameters must be documented in an RFC in order to
    be registered by IANA. This documentation MUST fully explain the
    syntax, intended usage and semantics of the parameter. The intent of
    this requirement is to assure inetroperability between independent
    implementations, and to prevent accidental namespace collisions
    between implementations of dissimialr features.

    RFCs defining SIP URI or SIPS URI parameters MUST register them with
    IANA as described below.

    Registered SIP or SIPS URI parameters are to be considered "reserved
    words".  In order to preserve interoperability, registered parameters
    MUST be used in a manner consistent with that described in their
    defining RFC. Implementations MUST NOT utilize "private" or "locally
    defined" URI parameters that conflict with registered parameters.

    Note that although unregistered SIP and SIPS URI parameters may be
    used in implementations, developers are cautioned that usage of such
    parameters is risky. New SIP and SIPS URI parameters may be
    registered at any time, and there is no assurance that these
    new registered URI parameters will not conflict with unregistered
    parameters currently in use.

In IANA Considerations Section, add new section (4.2?)

4.2 Registration Policy for SIP Request-URI Parameters

    As per the terminology in RFC 2434, 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 an RFC. There is no
    requirement that this RFC be standards-track.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Oct 2003 22:11:07 -0700

Should we make a recommendation that non RFC stuff uses x- to avoid name
conflicts later? 

Cullen

I won't even mention the logical next things to bring up :-)

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 19 Oct 2003 09:13:15 -0400

> I won't even mention the logical next things to bring up :-)

I'm not sure if this is in jest, so pardon my standard rant. The X- 
convention solves no problem and simply makes it more difficult to 
eventually migrate non-RFC stuff to RFC stuff.

Any X- name space would avoid collision with RFC-documented names only, 
but not with other non-RFC names. However, the former is not a problem 
since those names are publically documented and, according to the 
proposal, registered. Collision is much more likely between two 
companies or non-IETF standardization groups developing extensions, as 
they don't have an easy way to find out what others are up to. They 
would typically only find out once a product ships or a spec is 
published, when it is often too late to make changes without large costs.

Thus, separate, global namespaces for non-RFC/non-IANA extensions have 
no benefit whatsoever, in my opinion.

Henning