Subject: Re: [Sip] Options for P- header standardization

From: William Marshall <[email-masked]>
Date: Mon, 25 Mar 2002 08:09:21 -0500 (EST)

For the sake of interoperability, it seems that every receiver must
immediately strip the "P-" prefix from every header received in a message
before processing it.  Senders then use "best available information"
at the time of shipping to decide whether to convert "Foo" to "P-Foo".
(General rule: Be strict in what you send, generous in what you accept).
This is the only way of solving the messy problem of keeping the P-Via
headers combined and in order with the Via headers.

So if those two rules are followed, (1) we get interoperability, and
(2) the P- prefix is meaningless.  I think these two go together.

Changing the header name midway through the standardization process
is a deliberate attempt to break early implementations.  This tactic is
seen in other standards bodies; hopefully IETF won't go that route.

Since the whole point of the IANA registration is to avoid name
clashes, waiting until publication as an RFC is way too late.  The
registration needs to happen with the individual's -00 I-D.  And
thus _every_ non-P- header will start out as a P- header.  I therefore
disagree with Rohan's claim that it is 99% a non-problem.

Bill Marshall
[email-masked]

-----original message-----
Date: Sat, 23 Mar 2002 17:21:21 -0600
From: Henning Schulzrinne <[email-masked]>
To: Ben Campbell <[email-masked]>
Cc: [email-masked], Rohan Mahy <[email-masked]>
Subject: Re: [Sip] Options for P- header standardization

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

Ben Campbell wrote:
> 
> 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.

_______________________________________________
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: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 25 Mar 2002 14:25:52 -0000

All this discussion seems to be trying to identify that some semantic
meaning should be attached to P-headers within the implementation, rather
than just in the status of the header within the IETF.

For Rohan's original post, his statement about this most candidates for
P-headers always staying as P-headers applies once they reach RFC status.
There are 3 meanings of P - preliminary, private and proprietary. We should
not regard "preliminary" as being "fast track" for a more generic solution.
We should only regard "preliminary" as a quick solution where the
requirements for a full generic solution are not yet known, and the
"preliminary" solution will therefore not be one and the same as the full
generic solution.

It is possible that in all these cases, the mechanism specified is later
realised to be so useful that it becomes defacto the generic solution.
However in most cases, this is not meant to happen.

If it does happen, and the mechanism is essentially unchanged, i.e. the
processing of the header is identical, then I believe it should remain a
P-header. For the recognition of the validity of the original mechanism to
occur, then there will already be implementations out there, and there is no
point in arguing for a name change merely for the sake of keeping the
documentation pretty. Therefore in this case I support (1) in Rohan's
original posting.

If the mechanism does change, then obviously a new header name is required
as the semantics associated with the processing of the header are different.

Keith

-----Original Message-----
From: William Marshall [mailto:[email-masked]]
Sent: 25 March 2002 13:09
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip] Options for P- header standardization

Bill Marshall
[email-masked]

-----original message-----
Date: Sat, 23 Mar 2002 17:21:21 -0600
From: Henning Schulzrinne <[email-masked]>
To: Ben Campbell <[email-masked]>
Cc: [email-masked], Rohan Mahy <[email-masked]>
Subject: Re: [Sip] Options for P- header standardization

Henning