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

[Jon Peterson <jon.peterson at neustar.biz>]

Catching up on more LC comments inline:

On 3/24/09 12:42 PM, "Dan York" <dyork at voxeo.com> wrote:

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

The document does say today:

    Existing "P-" headers are
   to be handled by user agents and proxy servers as the "P-" header
   specifications describe; the deprecation of the change process
   mechanism entails no change in protocol behavior.  New proposals to
   document SIP headers of an experimental or private nature, however,
   shall not use the "P-" prefix.

Is that good enough? I read that as addressing your questions. I suppose
there may be some race-condition window where a proposal in its final stages
(in IESG processing, say) still uses a P- header after rfc3427bis has been
approved, but I don't think that's a huge cause for concern - nothing about
the handling of that header will change because rfc3427bis has been
published, as the text above suggests.

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

Do remember that rfc3427bis is a proposal, and as such it will go into
effect at a given time, and at the time we will have the opportunity to
figure out what we want to do with any balls that are up in the air. In your
case it really wouldn't make sense to remove the 'P-' precisely because of
the existing deployments. Do remember that rfc3427bis is deprecating a
process and not any existing or proposed mechanism.
 
> 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."

This is what we intended for the document to communicate, and we do want to
stamp out any ambiguity on this point.
 
> 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.

The point of this sentence is to say "our feelings about header name
prefixes intended to designate maturity are not limited to the letter 'P' -
please don't repeat this mistake by doing it with 'X' or 'Q' or something."
Is that reading especially unclear?

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

I'm not sure that "need not" entails MAY, but I agree there should be a
greater consistency in policy language.

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

This is a more subtle point, certainly. We do not want to force changes in
any existing deployments due to this change in policy. I think though that
your suggestion below, merely saying that we "discourage" it, is
unnecessarily opaque. I'd prefer that we're explicit about the legitimate
reasons why a P- header proposal might still arise and make special
allowances for those reasons. So, more like "New proposals to document SIP
headers of an experimental or private nature, however, shall not using the
'P-" prefix unless existing deployments or standards use the prefix
already."

Reasonable?

Good comments, and thanks.

Jon Peterson
NeuStar, Inc.

> 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