Re: [RAI] Option-tag registration

[Christer Holmberg <[e-mail]>]

XML is the new P- header :)

Regards,

Christer

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Dan York [[e-mail]]
Sent: Friday, April 09, 2010 6:47 PM
To: Scott Lawrence
Cc: [e-mail]; Hadriel Kaplan
Subject: Re: [RAI] Option-tag registration

Hadriel,

I also agree with you (and Scott).

I started the process over 2 years ago of simply trying to register a
P-header that was already in usage among various equipment vendors (P-
Charge-Info - http://tools.ietf.org/html/draft-york-sipping-p-charge-info
  ) and found that the RFC 3427 process was incredibly cumbersome.
All I was trying to do was to help prevent the proliferation of P-
headers with multiple people trying to do the same thing.  My hope was
that someone else wanting to pass billing info (in this case) might
more easily find P-Charge-Info through the IANA SIP header list and,
hopefully, choose to use that header if it fit for them rather than
creating yet-another-P-header-that-does-basically-the-same-thing.  The
proliferation of P-headers doesn't help any of us and certainly
doesn't help with interop.

I think we need to make it as easy as possible for people to register
P-headers (and yes, I know that "P-" is deprecated)... and yes, the
new RFC 5727 (i.e. 3427bis) will help with that, although I'm still
not sure if it explains the process easily enough for a newbie to the
IETF to understand what they need to do.  Yes, we need a review
process to help submitters see if there are valid technical points
they aren't considering... the process for P-Charge-Info was very
helpful in identifying a few areas that needed further specification.

But in the end I think we need to remove as much friction as possible
so that people WILL register headers which will help other people FIND
those headers and then hopefully not create new ones.  I agree with
your point, too, Hadriel, about the registration of custom headers
pointing to areas where work needs to be done.  If we find that there
are 7 different custom headers being registered that deal with, say,
the number of buttons on an IP phone... then perhaps there is an area
that needs true standardization work (hopefully this particular
example would never occur).

I agree that option tags are in a similar situation.  People are
creating them anyway. I'm sure there are already duplicates and I'm
sure they are causing interop issues.

So yes, we should make it as easy as possible to register option tags,
too, subject to some basic review process, so that we can help guide
people to option tags that are already existing so that they don't go
off and create even more.

My 2 cents,
Dan

On Apr 9, 2010, at 9:02 AM, Scott Lawrence wrote:

> On Fri, 2010-04-09 at 01:53 -0400, Hadriel Kaplan wrote:
>
>> It's been over a year since I sent this email, so I thought I'd
>> re-send it to see if anyone else cares about this topic yet, since it
>> got not responses last year...
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of
>>> Hadriel Kaplan
>>> Sent: Friday, February 13, 2009 6:53 PM
>>>
>>> If we're considering making new Header registration easier, can we
>>> also
>>> consider relaxing the rules for registering new option tags - to
>>> revert
>>> back to the rfc2543 model?
>>>
>>> It has some of the same properties of the P-header experience.
>>> (1) It
>>> hasn't prevented anyone from adding dozens of option tags, (2) it
>>> has
>>> caused some interop issues because they've been put into the wrong
>>> fields,
>>> and (3) there are some from different vendors which essentially do
>>> the
>>> same thing.
>>>
>>> Problem (2) would be helped if it had an explanation of its
>>> purpose and
>>> expert review, because we'd catch cases where they need to put it in
>>> additional places (in particular, Proxy-Require), or in cases when
>>> they
>>> should not (eg, when they should put it in Supported but not
>>> Require).
>>> Problem (3) would be helped because we'd find some that are actually
>>> useful and drive a standards-track one.
>>>
>>> What's worse is that the current restrictions for option tags, and
>>> the
>>> time it takes to go through standards-track, are making some
>>> groups decide
>>> to avoid creating/using one when they really should.
>
> Having just spent a bunch of time on this question in the context of
> reformulating the BLISS charter and figuring out what to do with
> some of
> its work items, I heartily agree with this (besides, I've been
> spending
> a lot of text disagreeing with Hadriel, so I welcome the opportunity
> to
> agree with him on something).
>
> There appears to be a widely held belief that defining an option tag
> always means making some fundamental change to how SIP works, and
> since
> that's clearly a bad thing then it should be made as difficult as
> possible.  I don't share that belief - sometimes an option tag is
> just a
> method for recognizing or negotiating the use of a feature that's
> being
> used.   Of course, it's important to make sure that one checks which
> is
> being done, so some open review process is needed.
>
>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai

--
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [e-mail]
Phone: [phone]    Skype: danyork

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo








_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai