Subject: [RAI] RFC 3427bis - grandfathering in existing P-headers that are in the IETF process?

From: Dan York <[email-masked]>
Date: Tue, 24 Mar 2009 15:42:48 -0400

In RFC 3427bis ( http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-01 
  ), it states very clearly that P-headers are deprecated and NOT to  
be registered.  For instance, section 4 makes this VERY clear statement:

   New proposals to document SIP headers of an experimental or private  
nature, however,
    shall not use the "P-" prefix.

While I am fine with that for new headers being created, what about  
those headers that are already deployed in actual usage and are being  
documented in the existing RFC 3427 process?  And what about existing  
headers in usage that have never been documented but might be under  
this simpler process?

For instance, for about the past year I have been working P-Charge- 
Info through the process and am at the point in RFC 3427 where I need  
to "request expert review" from the SIPPING chairs after having gone  
through multiple rounds of review on the SIPPING mailing list:

   http://tools.ietf.org/html/draft-york-sipping-p-charge-info-06

Under a literal reading of RFC 3427bis, I would not be able to  
register this header.  Yet this header has been in common usage for at  
this point 3 or 4 years and is already in usage in various equipment  
and applications.  I do not see the vendors of the equipment nor the  
carriers using it changing their software/firmware at this point  
purely because we are changing course on the use of "P-".

I would note that RFC 3427 is not 100% consistent on this point.  
Section 4 states clearly "New proposals... shall not use the P- prefix."

However, in the very next paragraph, the usage is "discouraged" but by  
implication would seem to be permitted:

    The use of any
    header field name prefix ("P-" or "X-" or what have you) to  
designate
    headers of limited applicability is discouraged.

And in Section 6, IANA Considerations, it says that "new registrations  
of Informational headers **need not** begin..." :

    Standard headers and messages MUST NOT begin with the leading
    characters "P-".  Existing "P-" header registrations are considered
    grandfathered, but new registrations of Informational headers need
    not begin with the leading characters "P-".  Short forms of headers
    MUST only be assigned to standards track headers.

Personally, I think the guidance in Section 6 is appropriate.  For  
*Informational* headers, the leading "P-" prefix should be allowed,  
although discouraged, to accommodate existing P-headers that may be in  
common usage but may perhaps have never been documented because of the  
steps involved with the existing RFC 3427 process.

My suggestion would be to ease the text in section 4 to be something  
more like:

    New proposals to document SIP headers of an experimental or  
private nature, however,
    are discouraged from using the "P-" prefix.

My 2 cents,
Dan

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-407-455-5859    Skype: danyork
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build powerful voice applications quickly
Find out how at http://www.voxeo.com/free

---

From: Dan York <[email-masked]>
Date: Tue, 24 Mar 2009 15:44:18 -0400

Dan

On Mar 24, 2009, at 3:42 PM, Dan York wrote:

> those headers that are already deployed in actual usage and are  
> being documented in the existing RFC 3427 process?  And what about  
> existing headers in usage that have never been documented but might  
> be under this simpler process?
>
> Info through the process and am at the point in RFC 3427 where I  
> need to "request expert review" from the SIPPING chairs after having  
> gone through multiple rounds of review on the SIPPING mailing list:
>
> register this header.  Yet this header has been in common usage for  
> at this point 3 or 4 years and is already in usage in various  
> equipment and applications.  I do not see the vendors of the  
> equipment nor the carriers using it changing their software/firmware  
> at this point purely because we are changing course on the use of  
> "P-".
>
> However, in the very next paragraph, the usage is "discouraged" but  
> by implication would seem to be permitted:
>
>   The use of any
> And in Section 6, IANA Considerations, it says that "new  
> registrations of Informational headers **need not** begin..." :
>
> although discouraged, to accommodate existing P-headers that may be  
> in common usage but may perhaps have never been documented because  
> of the steps involved with the existing RFC 3427 process.
>
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 24 Mar 2009 15:30:21 -0500

As I said at the mike in SIP - I like the DISPATCH idea as stated because it 
meets a need for a RAI Open Area meeting, but I'd also like to see some way 
of producing a small standards-track specification without having to spin up 
a working group - that's a lot of overhead that may not be required.

Any thoughts about where that work might find a home? I'm thinking DISPATCH 
handing off to a RAI-WG - a RAI Area Working Group...

Thanks,

Spencer

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Mar 2009 16:43:28 -0400

+1

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Spencer Dawkins
> Sent: Tuesday, March 24, 2009 4:30 PM
> To: [email-masked]
> Subject: [RAI] Places for small standards-track specifications
>

---

From: Dan York <[email-masked]>
Date: Tue, 24 Mar 2009 16:45:42 -0400

+1

On Mar 24, 2009, at 4:43 PM, Hadriel Kaplan wrote:

>> As I said at the mike in SIP - I like the DISPATCH idea as stated  
>> because
>> it
>> meets a need for a RAI Open Area meeting, but I'd also like to see  
>> some
>> way
>> of producing a small standards-track specification without having  
>> to spin
>> up

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 25 Mar 2009 11:17:44 -0500

+1 -- under the belief that any of these new efforts don't fit into 
another RAI WG already...

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 25 Mar 2009 16:19:41 +0000

On Tue, Mar 24, 2009 at 8:30 PM, Spencer Dawkins
<[email-masked]> wrote:

> I'd also like to see some way of producing a small standards-track
> specification without having to spin up a working group

an excellent idea.

 ~ theo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Mar 2009 13:36:46 -0400

Well, now I have to ask the question then.

In what way is this different from sipping?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Mar 2009 18:42:05 +0100

I am with Jonathan on this one. I believe that the dispatch =! sipping but rather dispatch + raiarea wg = sipping. 

Dan

-----Original Message-----
From: [email-masked] on behalf of Jonathan Rosenberg
Sent: Wed 3/25/2009 7:36 PM
To: Theo Zourzouvillys
Cc: [email-masked]
Subject: Re: [RAI] Places for small standards-track specifications

-Jonathan R.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Mar 2009 12:53:28 -0500

Hi, Jonathan,

>>> specification without having to spin up a working group

I'm probably not explaining this well, because my thinking is evolving as 
the week drags on (and I get less and less sleep), BUT ...

My understanding of SIPPING-as-practiced is that it combined what will 
become DISPATCH, PLUS requirements for SIP - do I have this right so far? 
(checking http://www.ietf.org/html.charters/sipping-charter.html for my own 
sanity).

I'm asking for something separate from DISPATCH... and not doing 
requirements for SIPCORE.

(Please permit me to call this "thing" "RAI-WG" for short)

So I wasn't seeing RAI-WG as the resurrection of SIPPING, and proposing that 
wasn't my intention.

Thanks,

Spencer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Mar 2009 14:29:40 -0400

I think currently SIPPING is the set of {DISPATCH, new-WG's, RAI-WG}.

For some things SIPPING currently does, they really should have been small, short-lived, separate WG's.  For example all the conferencing work, the cc-docs, ua-config framework and data set, and overload-docs - those would be new WG's, imho.  But rtcp-summary and policy-package, for example, would be handled in an RAI-WG.

-hadriel

> Jonathan Rosenberg
> Sent: Wednesday, March 25, 2009 1:37 PM
> To: Theo Zourzouvillys
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Mar 2009 14:08:02 -0500

Hadriel,

> I think currently SIPPING is the set of {DISPATCH, new-WG's, RAI-WG}.

A very succinct summary of what I'm mumbling. Thanks for translating into 
English :-)

Spencer