Subject: [Sip] Options for P- header standardization

From: Rohan Mahy <[email-masked]>
Date: Sat, 23 Mar 2002 12:55:29 -0800 (Pacific Standard Time)

Hi,

A lot of people seemed to be concerned about the prospect of standardizing
headers that had once been P- headers.  I'd like to outline *all* the
possibilites here, and then cover what I think are the pros and cons of
each possibility.

I'd also like to re-emphasize what I said at the microphone during the
SIP session Wednesday.  We expect that 99% of P- headers will never
be standardized, so this problem is not so large as I think many have
feared.

Lets talk about standardization options for a "preliminary" header: P-Foo

1) Just register P-Foo as a Proposed Standard
2) Register Foo as a Proposed Standard and always send/receive both
headers
3) Register Foo as a Proposed Standard with a new option tag
4) Register Bar as a Proposed Standard and always send/receive both
headers
5) Register Bar as a Proposed Standard with a new option tag
6) Just send/receive Foo or Bar, immediately deprecate P-Foo

1) Defeats the point of P- headers in the first place, because the whole
point in having the P- header space is to allow folks to easily identify
which headers are not "standard".

2) and 4) may provide some duplicate some information (wastes bandwidth)
but insures the correct behavior.  You just need to be sure to ignore
P-Foo if you support and receive Foo or Bar.

3) and 5) present the same problem that we have with any new standard
header.

6) Is only reasonable if the implementation and deployment of P-Foo was
limited.

hope this helps.
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: Henning Schulzrinne <[email-masked]>
Date: Sat, 23 Mar 2002 15:57:26 -0600

Rohan, thanks for the first summary.

I think there are two separable issues:

(1) Label registrations (with IANA) with their type (e.g., Informational
or modifying)

(2) Make the header label reflect this fact (i.e., using the P- prefix).

My basic thesis is that option (1) is sufficient and architecturally
cleaner. Since option (2) has a number of problems, it would seem that
the proponents of such approach (2) have to identify its merits. The
current SIP change draft does not provide any such reasoning that I
could find.

Some points to consider:

- We should be very careful to distinguish option tags and header names.
This can get a bit confusing, since some of the proposed (but, I
believe, never standardized) mechanisms for HTTP extensions made a very
different choice.

The important part is that there is *absolutely no* fixed relationship
between option tags and header field names. Option tags identify
behavior, not field names. Thus, there can be option tags that rely on
zero new header fields, or on some combination of existing headers. It
is quite possible that a standards-track feature (with an option tag)
defined later may want to rely on some informational header, possibly in
combination with a new non-P header, thus forcing renaming or
duplication.

In the latter case, renaming P-Foo to Foo is not appropriate, since the
original behavior is still valid. Thus, only duplication of information
is possible.

- In case there's a doubt about the difference between header names and
feature names, remember that only feature names can be used for
negotiation. SIP has no mechanism to say "Dear UAC, I don't support
header H", only "Dear UAC, I don't support feature F". Thus, any design
that relies on the presence of new headers (beyond the basic mandatory
headers like To/From/Call-ID/CSeq, etc.) without a feature tag is plain
a broken design and cannot work in practice.

- I think there was agreement in the discussion that an implementation
could not and MUST NOT derive any useful knowledge from the fact that a
header started with the two characters "P-". It seems architecturally
unsound to include information that should never appear in code. We
don't include in the header which methods it can appear with, either...

There doesn't seem to be a precedent for such a labeling mechanism, as
far as I can tell. The closest I can think of is the early Fortran IV
convention of labeling integers with variable names starting with I
through N (?), but from all I've heard, that's not exactly considered
state-of-the-art any more.

- If we were to decide to include both P- and non-P versions in a header
could be extremely expensive. Header fields can have unbounded length.
This is particularly true for "informational" headers since they often
contain information generated by or for humans.

- There are a number of existing headers that behave like P- headers,
yet don't have the name. Thus, in practice, one has to look at the
relevant spec in any event to figure out what behavior is triggered by
the header.

- If we don't rename a P- header when it becomes part of a named
feature, the whole notion of identifying headers has been lost.

I'm afraid I just don't understand what technical problem we're trying
to solve by including information that implementations cannot use in the
name of a field. We can solve the problem of preventing
non-standards-track header fields causing protocol behavior changes by
ruling out the use of option tags in any such documents. That is simple
and easily verifiable. In addition, with or without the P- prefix,
somebody has to look at the document and verify that the specification
doesn't call for substantial behavioral changes in SIP behavior. The
prefix doesn't help at all in that analysis.

My suggestion:

(1) Label any SIP change drafts clearly, possibly in the title (as in,
e.g., "SIP Feature for ..." vs. "SIP Informational Enhancement for
..."). Include some kind of reference text template in the draft to
alert the reader. ("This draft follows Section 5 of sip-change-rfc and
defines behavior and headers that are ...").

The naming convention for RTP payload type definitions is a precedence
for such a draft naming convention.

(2) The IANA registration should clearly identify the type of behavior.

(3) Make sure that the presence of option tags in each extension is
defined by the change spec. (I think it is reasonably clear, but some
additional motivation wouldn't hurt.)

Henning

---

From: "Ben Campbell" <[email-masked]>
Date: Sat, 23 Mar 2002 16:38:02 -0600

I have to agree with Henning.

All the options that Rohan listed result in one of three things:

1) You can't really know that a header is non-standard unless you look up
the RFC/IANA registration.
2) All implementations must support 2 possible header names for the same
thing
3) No backwards compatibility to pre-standard implementations.

Of these 3, the least damaging appears to be result #1.

This is identical to the result of not bothering with the "p" prefix in the
first place.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Henning
> Schulzrinne
> Sent: Saturday, March 23, 2002 3:57 PM
> To: [email-masked]
> Cc: Rohan Mahy
> Subject: Re: [Sip] Options for P- header standardization
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 23 Mar 2002 17:21:21 -0600

To add to this, it seems experience teaches us that the standardization
status of a draft is subject to changes very late in the game, for any
number of reasons. A non-exhaustive list includes:

- IPR issues that pop up at any point and then argue for "demotion" to
informational; as participants of this working group know, this isn't
exactly a theoretical case.

- IESG concerns that only appear after last call;

- external reference issues ("organization X needs a standards-track RFC
for a normative reference").

Depending on the direction, suddenly a P- header needs to drop the
prefix or a non-P header needs to acquire it, leading to the duplication
of headers or breaking of existing implementations.

SIP itself saw a fair bit of implementation before the RFC came out,
with the first bake-off tests with dozens of implementations being done
weeks after the RFC. Unless we want to switch to an ITU model ("thou
must not implement before the spec has been stenciled on parchment"), we
need to provide some good-faith protection to implementors. Obviously,
there can be no guarantee of backwards-compatibility if the reason has
sufficient technical merit, but I find it hard to tell an implementor
with a straight face that their shipping product is broken because of
some unpredictable external forces, not because of any technical flaws.

Unless we are becoming completely legalistic, expediency and good-faith
protection will lead us to make exceptions, which then further erodes
any significance of the designator.

To add another reason why duplicate headers are bad: Logging becomes a
pain. The logging logic now needs to know that it should log only one of
the header instances, as otherwise any searching or sorting gets even
more painful.

Yet another one: sip-cgi, SIP servlet and CPL logic gets bloated, since
I now need to check two header names in all comparisons. People will
forget to do this, and suddenly scripts go erratic in subtle ways.

Also, as soon as you have two headers with the same function but
different names, any headers where proxies add instances (as in Via)
require elaborate logic and become extremely brittle. Let's say a proxy
only knows about the non-P header and adds an instance to it. It doesn't
know about the P-header. (Doesn't really matter which way the proxy
tends.) Suddenly, the UAS gets two headers that are supposed to be the
same, but aren't. Duh.

Another brittleness: Headers that are included in both the
S/MIME-protected body and the outer header. Again, elaborate logic is
needed to reconcile the P-/non-P headers.

I suspect that there any number of other things that could break. People
have suggested getting rid of the compact headers; all of the reasons
offered apply in spades here. Indeed, if we allow headers to acquire or
drop prefixes, most of the same arguments would lead one to think that
adding compact forms later on would be a good idea.

I grant that any of these problems identified can be fixed individually,
at significant spec bloat. (Plus, it seems a little late to do this now
that the RFC has shipped. Thus, suddenly 'bis' implementations are all
broken.)

This, I think, is an example of "aliasing", which is always a rather
dangerous concept, starting from Fortran COMMONs in the 1960s to pointer
aliasing in C/C++.

Thus, I suggest that people proposing duplicating header fields have a
fairly high standard of proof that they need to meet as to why there is
no other solution and what the benefits might be.

Henning

---

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 24 Mar 2002 20:18:27 -0800

I want all the people who think it is ok to change the p-foo header to foo
as it becomes standard to go and change the MESSAGE message to some less
messy message name for a message. Seriously, please make it clear why this
is significantly different.

Ben and Henning are making sense to me. A few points about Ben's 3 options
below. In option 1, I am fine having to look it up in a RFC or IANA to find
out what type of standard it is. I am going to have to do this anyway. I see
no requirement to code the type of the standard on the wire. Option 2 is
more of a bummer than it might seem at first glance. It's fine for everyone
to receive both, but what should I send? In practice I will probably just
send the p- version because it has better odds of working during the
transition phase (which could last a *long* time). Considering the track
record of SIP having significant deployed equipment running stuff that is
not RFC yet, option 3 is not that appealing when it can be so easily
avoided.

Why make interoperability any harder than it needs to be?

Cullen

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ben
> Campbell
> Sent: Saturday, March 23, 2002 2:38 PM
> To: Henning Schulzrinne; [email-masked]
> Cc: Rohan Mahy
> Subject: RE: [Sip] Options for P- header standardization
>
>

---

From: Allison Mankin <[email-masked]>
Date: Mon, 25 Mar 2002 09:34:36 -0500

> be standardized, so this problem is not so large as I think many have

Given the barriers to P-headers, there should be relatively few
all around.  People should read the list of conditions for an acceptable
P-header in 6.1.  The discussions that have followed Rohan's mail seem not
always to have digested those, which limit the functions of a header
to be proposed as P- to information provision and which require that
no change in behavior or security properties results from the header in
use.  

This process will not support designing a header like Replaces, which
changes the behavior and significant properties of the dialog, and
starting it as a P-header and eventually taking it to a non P- header.

> 1) Just register P-Foo as a Proposed Standard

This first case reduces the discussion to a bad mismatch with Section 6.1
in the draft.

A header should go through the standards process as Foo if it is envisioned 
as a general use header extension.  The P- process is not there to 
facilitate a trial.

> which headers are not "standard".

No, the point in the "P-" being there is what Rohan says.
but, the whole point of the P- space and procedures is for there to
be a limited exception to the rule that SIP header extensions must meet
all criteria for being standards track and make it to a standards track
RFC.  The circumstances in which they do not include that they carry
non-behavioral altering information that is significant to a non-general 
community (one consortium, one deployment) or non-behavior altering
information that cannot be an RFC - for instance information in law
enforcement that RFC 2804 and current IESG policy would not permit on the
standards track.

Do not ignore the 99% statement Rohan made first.  I'd bet it to be even 
less.  Maybe we need to eliminate the string reservation feature and
maybe we've erred by including "preliminary" among the glosses of P.