Subject: RE: [Sip] Mismatch in registry policy requirements of RFC 3969

From: "Burger, Eric" <[email-masked]>
Date: Fri, 23 Jun 2006 16:18:35 -0400

I agree we need something "in the middle."  I would offer that very
tight control on URI parameters will land us in the same place as too
tight control on headers.  That is, we end up with a ton of X-mumble
with no documentation.  Worse yet, we end up with P-mumble with little
review.  The problem is sometimes X-mumble actually does useful stuff.

For example, the RFC 2822 message I'm responding to right now has 33
non-routing (Received:) headers.  Of those 33 headers, 15, or almost
half, are X-mumble.  A good bit of those are put in by the IETF list
server, so don't whine about people using proprietary e-mail systems.

I would much rather have an easy-to-publish/document method for whacky
URI parameters than to force the drug users underground :)

-----Original Message-----
From: Aki Niemi [mailto:[email-masked]] 
Sent: Monday, May 29, 2006 3:06 AM
To: ext Gonzalo Camarillo
Cc: Cullen Jennings; SIP IETF; Dean Willis
Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969

ext Gonzalo Camarillo wrote:
> Hi,
> 
> the conclusion was the IETF wanted to have tighter control on SIP URI
> parameters than on header field parameters. Therefore, one would need
a
> standards-track RFC in order to create new SIP URI parameters... that
> was the intent.

Believing this gives the WG tighter control is a delusion. Similarly,
one could set the speedlimit on highways to 2 miles or 5 kilometers an
hour, and sit and watch everyone breaking it.

I think all this does is it makes people who need URI parameters go
underground. And that makes interop worse, not better. It also all but
guarantees the SIP* working groups will be flooded with trivial
specifications of extension parameters, over which we will be able to
have many entertaining but utterly useless debates.

I'll also note that in the end, the only people who will even attempt to
abide by these types of policies are other SDOs because they sort of
have to; everyone else in the industry won't pay any attention.

I was of the opinion way back when this was discussed the last time, but
remember being in the minority.

Cheers,
Aki

_______________________________________________
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

_______________________________________________
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