Subject: Re: [RAI] Option-tag registration

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Apr 2010 01:53:20 -0400

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: [email-masked] [mailto:[email-masked]] 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.
> 
> -hadriel

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 09 Apr 2010 09:02:52 -0400

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

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.

---

From: Dan York <[email-masked]>
Date: Fri, 9 Apr 2010 11:47:32 -0400

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:

> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-407-455-5859    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

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 9 Apr 2010 12:10:30 -0400

Well needless to say I' +++++ 1 for this proposal. Expert review for Option
Tags is a very sensible idea that would solve a host of problems, including
some we are dealing with right now.

Expert review is what we did in ENUM for new ENUM services and it's the hope
we have for E2MD tags as well. Full RFC requirements here are an excuse for
some to stall, delay and/or kill perfectly good proposals that enhance the
interoperability of SIP. 

The larger problem in the RAI area IMHO is that even the DISPATCH process
had done nothing to reverse the increasing problem in the IETF of demanding
unanimous consent vs rough consensus. From a process perspective we have
become what we always feared and ridiculed...the ITU of the 1980-90's. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
York
Sent: Friday, April 09, 2010 11:48 AM
To: Scott Lawrence
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [RAI] Option-tag registration

Hadriel,

My 2 cents,
Dan

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Apr 2010 16:18:01 -0500

> become what we always feared and ridiculed...the ITU of the 1980-90's.

But even this illustrates the bigger problem in RAI:

By developing a protocol model that violates layering at almost every  
decision point, we've created a situation in which every new  
application seems to require fundamental changes to the SIP protocol.  
This is a really unfortunate situation.

Think about it: How often does a new web application require changing  
HTTP? We might not like X-over-HTTP applications much, but at least we  
don't require a standards-track operation on the protocol every time  
somebody wants to add another image-type to their web page.

The requirement for standards-track changes to the core protocol is  
supposed to be there to get people to either use the protocol in a way  
that doesn't require extending or to develop a new protocol that  
doesn't have to be extended twice a week.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 9 Apr 2010 21:03:50 -0400

RS> That is a very very broad statement that is not supported by actual
fact. How does a option tag that says this registration procedure is "foo"
violate SIP. This is the problem here. The SIP dare I say it 'mafia' thinks
SIP is one thing when the reality of SIP needs to make things actually work
in the field. I would argue here is a simple divergence from theory and
practice. It is not unreasonable to align theory with observed practice.
That is my point. And that alignment shouldn't take 3 years to achieve. 

RS> OK Its out of the lab in the field. What we thought SIP was at one point
in time is not what is actually deploying. OH I'm shocked shocked ( pun
intended ) global service providers want to preserve the structure of hop by
hop routing structure since that still represents 60% of their revenue. End
to End is certainly the goal but I've personally given up on Nirvana but
still willing to accommodate reasonable structures that rid the planet of
the pestilence of POTS.

RS> Poor analogy IMHO but a reasonable point taken.

RS> Option Tags IMHO are not core protocol. But in some minds reasonable
extensions that solve real world problems. Dean it's a reasonable thread and
a discussion that the RAI directorate needs to have. 

RS> Best wishes as always .. 

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Apr 2010 23:21:06 -0500

On Apr 9, 2010, at 8:03 PM, Richard Shockey wrote:
> .

The HTTP equivalent IS a core protocol change. Options tags should  
never have been used for "do you support this application?"; rather  
they say "do you support this extension to the core protocol?". But  
we've had far too many intimate relations with that particularly  
unlovely canine to do anything but bark afterwards and maybe hope for  
a thighbone or two.

SIP/2.0 is unsalvageable and totally at odds with "The Internet" in  
how it is developing. I've long though we should just tie a bow on it  
and give it to the ITU as a prank birthday gift, then get back to  
designing stuff that actually works on the Internet.

That said, until we decide to do so, we either have to 1) try to  
maintain some level of design aesthetic that preserves a vestige of  
our pride and principles, or 2) just give up and let the barbarians  
have their way with Rome. Adam Roach holds with the first course, but  
you, sir, are an absolute Visigoth in this context.

Of course, astute scholars of Boethius have often said that Rome fell  
not because the Goths and Visigoths and Ostrogoths were particularly  
warlike, but that they were easier to do business with than the  
increasingly decadent and effete Romans. Perhaps, as you say, it does  
come down to  simple expediency. But if so, I'd rather somebody else  
oversaw the administration thereof. Please be so kind as to pass me my  
lyre and a plate of figs, whilst I sit back and enjoy the fiery  
spectacle below. SIP may have been built with a thousand hacks, but it  
can obviously be burned with a single option-tag.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 10:38:15 -0400

Hi Nero,
Comments inline...

> From: Dean Willis [mailto:[email-masked]]
> Sent: Saturday, April 10, 2010 12:21 AM
> 

I'm with (1), but to do that and make it *relevant*, we need to accommodate differing business models and requirements.  Just saying "your way is evil" or "this isn't how HTTP works" doesn't help.  SIP *isn't* HTTP.  If it were, we wouldn't need SIP.  Really it's much closer to an Email model than HTTP.

> can obviously be burned with a single option-tag.

Sure, so would you rather have the info on what the Goths are doing and want, or would you rather bury your head in the sand and pretend there are no Goths?

-hadriel
p.s., one man's utopian Rome, is another man's oppressive throw-them-to-the-lions oligarchy. ;)

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 11:11:28 -0400

> Sent: Friday, April 09, 2010 5:18 PM
> 

I agree in some ways, but I don't see how it's avoidable.  It is what it is.

> somebody wants to add another image-type to their web page.

That's a bad analogy.  Option-tags aren't used for requiring a new codec, for example.  And if it is by someone, that's the someone we should want to submit a draft so we can point out their error.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 11:15:56 -0400

> doesn't have to be extended twice a week.

The thing is, to do that latter part we actually need to see what people are doing.

Also, ultimately the require/supported/proxy-require fields are there for a reason: to indicate or require support for an extension.  The text says 3261 changed 2543's leniency in that regard, to try to "improve multi-vendor interoperability" and "prevent servers from insisting that clients implement non-standard, vendor-defined features in order to receive service".  But it hasn't done either, and really it *can't*.

If someone wants to require some extension, and doesn't care about other vendors, there's simply no way to stop them.

What *does* improve interoperability is getting private extensions documented publicly.  And what also improves interoperability is explicitly indicating in the request/response what extensions a device implements, instead of relying on manual configuration or guessing.  That's what those fields are for, after all.  And we need to let them do their job.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 21:36:30 -0400

> [snipped lots]
> By developing a protocol model that violates layering...

BTW, why do you say SIP violates layering?

SIP has a very clean layering model, I just think you're confused as to what it is.

This is what it looks like, in an ISO-OSI/IETF layer model drawing: 

  +--------------+   +--------------+
  |  Religious   |   |              |
  +--------------+   |              |
  |  Political   |   |              |
  +--------------+   |              |
  | Application  |   |              |
  +--------------+   |              |
  | Presentation |   |     SIP      |
  +--------------+   |              |
  |   Session    |   |              |
  +--------------+   |              |
  |  Transport   |   |              |
  +--------------+   |              |
  |   Network    |   |              |
  +--------------+   +--------------+
  |  Data Link   |   |  Data Link   |
  +--------------+   +--------------+
  |   Physical   |   |   Physical   |
  +--------------+   +--------------+

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 11 Apr 2010 10:26:01 -0600

I've spend a fair amount of time looking at the things people have proposed for new option tags.  The ones that people complain about "taking long time" were issue where it mostly there was not wide spread agreement that the underlying proposal was a good idea and that it did need the wider review to not cause problems - one of the gals of the current registration process is simply to require wider review. Because of this, I think the current registration procedures around options tags can be shown to working exactly as people had hoped and actually improving interoperability of of real world equipment.

I know that at first glance this optioning sounds pretty controversial but I think if you go look at the examples, more people might come to this point of view. Keep in mind that the overall goal here is to have a wide range of equipment for different environments that actually works together so tags that amount to "require deployment constraints of market X" are not something that help interoperability. They might help equipment deploy in market X, but they do not help that equipment work with or be reusable in markets outside of X. 

I regularly hear the problem is the IETF is too slow - I'm totally willing to try and make it faster, though I note that things people point to as "faster" or not looking necessarily faster to me. However, I don't think changing this registration procedures would help speed things up and from reviewing the past examples, I think it would harm interoperability. I do think things can be done faster and glad to help in every way to make that happen. 

Cullen

> > to avoid creating/using one when they really should.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Apr 2010 13:19:30 -0400

I knew this argument would be raised, so I'm ready for it. :)

Let's take the most recent example: Martini.  

You are absolutely right that going through the full process has been "keeping us honest".  But it misses the point.

Look at what *did* happen *instead*.  Instead, we now have numerous implementations of bulk-Registration, many of which don't interoperate, and none of which explicitly indicate what variant they are/expect.  We have two SDO's and one Industry Association with deployed solutions, and no SIP device can tell them apart on the wire.

In short, we have an interoperability mess!

The point of it is that making option-tags harder to get doesn't stop people from doing the thing they want to do.  They're going to do it *anyway*.  They just may not use an option-tag to negotiate/indicate they're doing it.  By making it hard to get options-tags we simply make it harder to interoperate.  Is that really good for SIP??

The more we tighten our grip, the more SIP systems slip through our fingers. ;)

And had there been only an expert-review or spec-required level for options-tags, SIP-Forum would have submitted a draft well over a year ago!  The main reason we didn't was the concern over how long it takes. (the mail I re-posted which I had sent over a year ago was in fact instigated from our unwillingness in SIP-Forum to go for an option-tag due to this reason)

Had we done that, do you not think it would have been scrutinized, and the concerns raised anyway?  I think it would, but just sooner. 

-hadriel

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Sunday, April 11, 2010 12:26 PM
> To: Hadriel Kaplan
> 
> I've spend a fair amount of time looking at the things people have
> proposed for new option tags.  The ones that people complain about "taking
> long time" were issue where it mostly there was not wide spread agreement
> that the underlying proposal was a good idea and that it did need the
> wider review to not cause problems - one of the gals of the current
> registration process is simply to require wider review. Because of this, I
> think the current registration procedures around options tags can be shown
> to working exactly as people had hoped and actually improving
> interoperability of of real world equipment.
> 
> I know that at first glance this optioning sounds pretty controversial but
> I think if you go look at the examples, more people might come to this
> point of view. Keep in mind that the overall goal here is to have a wide
> range of equipment for different environments that actually works together
> so tags that amount to "require deployment constraints of market X" are
> not something that help interoperability. They might help equipment deploy
> in market X, but they do not help that equipment work with or be reusable
> in markets outside of X.
> 
> I regularly hear the problem is the IETF is too slow - I'm totally willing
> to try and make it faster, though I note that things people point to as
> "faster" or not looking necessarily faster to me. However, I don't think
> changing this registration procedures would help speed things up and from
> reviewing the past examples, I think it would harm interoperability. I do
> think things can be done faster and glad to help in every way to make that
> happen.
> 
> Cullen

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Apr 2010 21:37:30 +0200

I agree with Hadriel.

The situation is very similar to the one we have with INFO, which we are now trying to solve with the Info Events mechanism.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]
Sent: Sunday, April 11, 2010 8:19 PM
To: Cullen Jennings
Cc: [email-masked]; [email-masked]
Subject: Re: [RAI] Option-tag registration

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Apr 2010 21:45:33 +0200

XML is the new P- header :)

Regards,

Christer

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

Hadriel,

My 2 cents,
Dan

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 12 Apr 2010 01:17:08 +0200

It is not the same as with INFO.

The problems with option tags is not specifically its use with Supported header fields (except for imprecision with the semantics of what it means in a number of cases).

The issue is with the use with Require and Proxy-Require, where use of option-tags with those headers becomes the lazy way of dealing with compatibility issues which could otherwise be sorted out. Use of option-tags with these headers means automatically that two equipments will not interwork unless they both implement, rather than some means of degrading gracefully.

The Info-Event header field is only equivalent to the Supported: variant of this. It doesn't involve proxies, and it doesn't stop things working (except by means of the Content-Disposition header field.

In any case, to resolve this, you need an update to RFC 5727. And I suspect no one is going to agree on first come first served, so we are going to end up with "Specification Required" as the minimum. And that requires expert review. So as someone already said, rather than just moaning about the inflexibility, start thinking about what a good set of expert review guidelines would be for new option-tag proposals.

regards

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> Sent: Sunday, April 11, 2010 8:38 PM
> To: Hadriel Kaplan; Cullen Jennings
> Cc: [email-masked]; [email-masked]
> The situation is very similar to the one we have with INFO, 
> which we are now trying to solve with the Info Events mechanism.
> 
> Regards,
> 
> Christer
> 
> From: [email-masked] [[email-masked]] On Behalf 
> Of Hadriel Kaplan [[email-masked]]
> You are absolutely right that going through the full process 
> has been "keeping us honest".  But it misses the point.
> 
> Look at what *did* happen *instead*.  Instead, we now have 
> numerous implementations of bulk-Registration, many of which 
> don't interoperate, and none of which explicitly indicate 
> what variant they are/expect.  We have two SDO's and one 
> Industry Association with deployed solutions, and no SIP 
> device can tell them apart on the wire.
> 
> The point of it is that making option-tags harder to get 
> doesn't stop people from doing the thing they want to do.  
> They're going to do it *anyway*.  They just may not use an 
> option-tag to negotiate/indicate they're doing it.  By making 
> it hard to get options-tags we simply make it harder to 
> interoperate.  Is that really good for SIP??
> 
> And had there been only an expert-review or spec-required 
> level for options-tags, SIP-Forum would have submitted a 
> draft well over a year ago!  The main reason we didn't was 
> the concern over how long it takes. (the mail I re-posted 
> which I had sent over a year ago was in fact instigated from 
> our unwillingness in SIP-Forum to go for an option-tag due to 
> this reason)
> 
> Had we done that, do you not think it would have been 
> scrutinized, and the concerns raised anyway?  I think it 
> would, but just sooner.
> 
> -hadriel
> 
> 
> > proposed for new option tags.  The ones that people complain about 
> > "taking long time" were issue where it mostly there was not wide 
> > spread agreement that the underlying proposal was a good 
> idea and that 
> > it did need the wider review to not cause problems - one of 
> the gals 
> > of the current registration process is simply to require 
> wider review. 
> > Because of this, I think the current registration procedures around 
> > options tags can be shown to working exactly as people had 
> hoped and 
> > actually improving interoperability of of real world equipment.
> >
> > I know that at first glance this optioning sounds pretty 
> controversial 
> > but I think if you go look at the examples, more people 
> might come to 
> > this point of view. Keep in mind that the overall goal here 
> is to have 
> > a wide range of equipment for different environments that actually 
> > works together so tags that amount to "require deployment 
> constraints 
> > of market X" are not something that help interoperability. 
> They might 
> > help equipment deploy in market X, but they do not help 
> that equipment 
> > work with or be reusable in markets outside of X.
> >
> > I regularly hear the problem is the IETF is too slow - I'm totally 
> > willing to try and make it faster, though I note that things people 
> > point to as "faster" or not looking necessarily faster to 
> me. However, 
> > I don't think changing this registration procedures would 
> help speed 
> > things up and from reviewing the past examples, I think it 
> would harm 
> > interoperability. I do think things can be done faster and glad to 
> > help in every way to make that happen.
> >
> > Cullen

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Apr 2010 09:27:03 +0200

Hi Keith,

Of course option-tags and Info Packages are different things.

The problem I was referring to was that people did not bring their INFO usages to IETF, and in the same way as they don't bring their usages which could benefit from having an option-tag.

Regards,

Christer

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 12. huhtikuuta 2010 2:17
> To: Christer Holmberg; Hadriel Kaplan; Cullen Jennings
> Subject: RE: [RAI] Option-tag registration
> 
> The problems with option tags is not specifically its use 
> with Supported header fields (except for imprecision with the 
> semantics of what it means in a number of cases).
> 
> The issue is with the use with Require and Proxy-Require, 
> where use of option-tags with those headers becomes the lazy 
> way of dealing with compatibility issues which could 
> otherwise be sorted out. Use of option-tags with these 
> headers means automatically that two equipments will not 
> interwork unless they both implement, rather than some means 
> of degrading gracefully.
> 
> The Info-Event header field is only equivalent to the 
> Supported: variant of this. It doesn't involve proxies, and 
> it doesn't stop things working (except by means of the 
> Content-Disposition header field.
> 
> In any case, to resolve this, you need an update to RFC 5727. 
> And I suspect no one is going to agree on first come first 
> served, so we are going to end up with "Specification 
> Required" as the minimum. And that requires expert review. So 
> as someone already said, rather than just moaning about the 
> inflexibility, start thinking about what a good set of expert 
> review guidelines would be for new option-tag proposals.
> 
> regards
> 
> Keith
> 
> which we 
> > are now trying to solve with the Info Events mechanism.
> > 
> > Regards,
> > 
> > Christer
> > 
> > You are absolutely right that going through the full 
> process has been 
> > "keeping us honest".  But it misses the point.
> > 
> > Look at what *did* happen *instead*.  Instead, we now have numerous 
> > implementations of bulk-Registration, many of which don't 
> > interoperate, and none of which explicitly indicate what 
> variant they 
> > are/expect.  We have two SDO's and one Industry Association with 
> > deployed solutions, and no SIP device can tell them apart 
> on the wire.
> > 
> doesn't stop 
> > people from doing the thing they want to do.
> option-tag 
> > to negotiate/indicate they're doing it.  By making it hard to get 
> > options-tags we simply make it harder to interoperate.  Is 
> that really 
> > good for SIP??
> > 
> > And had there been only an expert-review or spec-required level for 
> > options-tags, SIP-Forum would have submitted a draft well 
> over a year 
> > ago!  The main reason we didn't was the concern over how long it 
> > takes. (the mail I re-posted which I had sent over a year 
> ago was in 
> > fact instigated from our unwillingness in SIP-Forum to go for an 
> > option-tag due to this reason)
> > 
> scrutinized, and 
> > the concerns raised anyway?  I think it would, but just sooner.
> > 
> > -hadriel
> > 
> >

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 12 Apr 2010 09:45:27 -0400

On Fri, 2010-04-09 at 23:21 -0500, Dean Willis wrote:

> they say "do you support this extension to the core protocol?". 

If (as you seem to believe and I said was the problem) that sending an
option tag means that you've changed the underlying protocol rather than
that you're supporting or requiring a particular extension, then what is
the mechanism for the latter?   I think it's clear that one is needed
(and think that properly used, the option tag mechanism suffices).

Keith Drage says:

> The issue is with the use with Require and Proxy-Require, where use of
> option-tags with those headers becomes the lazy way of dealing with
> compatibility issues which could otherwise be sorted out. Use of
> option-tags with these headers means automatically that two equipments
> will not interwork unless they both implement, rather than some means
> of degrading gracefully.

Whether an error returned because of a Require or Proxy-Require problem
(either 420 or 421) represents a failure to 'degrade gracefully' or not
depends on what the recipient does next.  Sending an error response is
not in and of itself a problem - it's a normal part of the negotiation
process.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 12 Apr 2010 15:54:42 +0200

> where use of 
> Whether an error returned because of a Require or 
> Proxy-Require problem (either 420 or 421) represents a 
> failure to 'degrade gracefully' or not depends on what the 
> recipient does next.  Sending an error response is not in and 
> of itself a problem - it's a normal part of the negotiation process.

What I was trying to say here was not that Require and Proxy-Require usages were invalid. It was that too often, people do not think through the compatibility scenarios when they are designing the extension, and end up thinking that use of the option-tag in Require and Proxy-Require solve all their problems. In many cases, there are other more sensible designs that only need the use in a Supported header field.

regards

Keith

> Behalf Of Scott Lawrence
> Sent: Monday, April 12, 2010 2:45 PM
> To: [email-masked]
> If (as you seem to believe and I said was the problem) that 
> sending an option tag means that you've changed the 
> underlying protocol rather than that you're supporting or 
> requiring a particular extension, then what is
> where use of 
> Whether an error returned because of a Require or 
> Proxy-Require problem (either 420 or 421) represents a 
> failure to 'degrade gracefully' or not depends on what the 
> recipient does next.  Sending an error response is not in and 
> of itself a problem - it's a normal part of the negotiation process.
> 
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 14:10:42 -0400

Actually, I'd be fine with just allowing them to be FCFS for Supported cases ONLY.  One of my gripes with option-tags (including standard ones) are when people put them in Require and seem to have no idea what foolishness they've wrought.
One of my hopes for accepting informational uses of option-tags would be to point that out explicitly.

-hadriel

> Sent: Sunday, April 11, 2010 7:17 PM
> 
> The problems with option tags is not specifically its use with Supported
> header fields (except for imprecision with the semantics of what it means
> in a number of cases).
> 
> compatibility issues which could otherwise be sorted out. Use of option-
> tags with these headers means automatically that two equipments will not
> interwork unless they both implement, rather than some means of degrading
> gracefully.
> 
> The Info-Event header field is only equivalent to the Supported: variant
> of this. It doesn't involve proxies, and it doesn't stop things working
> (except by means of the Content-Disposition header field.
> 
> In any case, to resolve this, you need an update to RFC 5727. And I
> suspect no one is going to agree on first come first served, so we are
> going to end up with "Specification Required" as the minimum. And that
> requires expert review. So as someone already said, rather than just
> moaning about the inflexibility, start thinking about what a good set of
> expert review guidelines would be for new option-tag proposals.
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 12 Apr 2010 21:14:56 +0200

Agree with Hadriel.

This is exactly what happened in other SDO's as well.

/Hans Erik van Elburg

On Sun, Apr 11, 2010 at 7:19 PM, Hadriel Kaplan <[email-masked]>wrote:

> The point of it is that making option-tags harder to get doesn't stop
> people from doing the thing they want to do.  They're going to do it
> *anyway*.  They just may not use an option-tag to negotiate/indicate they're
> doing it.  By making it hard to get options-tags we simply make it harder to

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 13 Apr 2010 11:38:11 +0200

But unfortunately, given that the defining standards only define one type of option-tag that can be used in all these header fields, it is not as simple as that.

While I guess RFC 5727 could be updated to split the table into two, and write some requirements that option tags in the FCFS table MUST only be used in Supported headers, is this likely to happen.

regards

Keith

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Monday, April 12, 2010 7:11 PM
> To: DRAGE, Keith (Keith); Christer Holmberg; Cullen Jennings
> Actually, I'd be fine with just allowing them to be FCFS for 
> Supported cases ONLY.  One of my gripes with option-tags 
> (including standard ones) are when people put them in Require 
> and seem to have no idea what foolishness they've wrought.
> One of my hopes for accepting informational uses of 
> option-tags would be to point that out explicitly.
> 
> -hadriel
> 
> > The problems with option tags is not specifically its use with 
> > Supported header fields (except for imprecision with the 
> semantics of 
> > option- tags with these headers means automatically that two 
> > equipments will not interwork unless they both implement, 
> rather than 
> > some means of degrading gracefully.
> > 
> > The Info-Event header field is only equivalent to the Supported: 
> > variant of this. It doesn't involve proxies, and it doesn't stop 
> > things working (except by means of the Content-Disposition 
> header field.
> > 
> > moaning about the inflexibility, start thinking about what 
> a good set 
> > of expert review guidelines would be for new option-tag proposals.
> > 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 13 Apr 2010 18:20:50 -0400

I'm not sure why this discussion comes back to RFC5727, as neither it nor its predecessor specifies the IANA procedures for option-tags - the brief mention of option-tags in RFC5727 is there simply to defer to RFC3261. That much said, during the work on RFC5727 several people raised the question of loosening the IANA policies for option-tags; I argued this should be deferred for separate consideration from the P- header deprecation and related fixes.

Personally, I think we probably should have this discussion - in fact, in Anaheim I suggested to Adam and Paul that this might be a good sipcore topic for Maastricht. A number of people have expressed interest in trying to create a separate class of option-tags which could only appear in the Supported field of requests, and I suspect that approach is technically feasible, though not without some wrinkles we'd need to iron out. The other issue is whether we can feasibly render the IANA registration requirements loose enough to satisfy the people asking for change.

Against the benefits of more open registration we must weigh the risks that these option-tags will migrate from Supported to Required regardless of the standard. I certainly understand that people out in the world can invent non-standard option-tags and use them in whatever manner they'd like. The question is, by implementing looser registration policies like FCFS, will we really entice any of those parties to bring their option-tags to the standard world, or are they really more interested in using them for Require? And by legitimizing looser policies for IANA registration, will we create a class of "standard" tags with non-public specifications that are used only to wall off islands of non-interoperability? That is, really, the heart of the question - to what degree are standard tags required to designate areas of non-standard behavior in the world? If you don't expect anyone other than a closed group with access to that private implementation logic to use the features in question, how does a standard option-tag really benefit you? These are the questions that motivated the original IANA policy for option-tags, and the ones we need to answer in this discussion.

While FCFS has its merits, I think Keith is probably correct that the right question to ask is what a looser, expert review procedure would look like. For example, a review might check that the specification for the option-tags actually proposes to use them in a manner consisted with them appearing only in the Supported header in requests. Perhaps that's the only substantive review criteria, or perhaps there are others we need.

Jon Peterson
NeuStar, Inc.

On 4/13/10 2:38 AM, "DRAGE, Keith (Keith)" <[email-masked]> wrote:

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 14 Apr 2010 15:07:08 +0200

While I agree that RFC 3261 makes the first requirement of standards track for option tags, it is restated in RFC 5727 in the following text (section 7):

   RFC 3261 directs the Internet Assigned Numbers Authority (IANA) to
   establish a registry for SIP method names, a registry for SIP option
   tags, and a registry for SIP response codes, and to amend the
   practices used for the existing registry for SIP header fields.
   Reiterating the guidance of RFC 3261, method names, option tags, and
   SIP response codes require a Standards Action for inclusion in the
   IANA registry.  Authors of specifications should also be aware that
   the SIP parameter registry is further elaborated in [RFC3968].

So RFC 5727 would need to be updated - at least for that text.

Keith

________________________________

	From: Peterson, Jon [mailto:[email-masked]] 
	Sent: Tuesday, April 13, 2010 11:21 PM
	To: DRAGE, Keith (Keith); Hadriel Kaplan; Christer Holmberg; Cullen Jennings
	Cc: [email-masked]; [email-masked]
	Subject: Re: [RAI] Option-tag registration

	I’m not sure why this discussion comes back to RFC5727, as neither it nor its predecessor specifies the IANA procedures for option-tags – the brief mention of option-tags in RFC5727 is there simply to defer to RFC3261. That much said, during the work on RFC5727 several people raised the question of loosening the IANA policies for option-tags; I argued this should be deferred for separate consideration from the P- header deprecation and related fixes.
	
	Personally, I think we probably should have this discussion – in fact, in Anaheim I suggested to Adam and Paul that this might be a good sipcore topic for Maastricht. A number of people have expressed interest in trying to create a separate class of option-tags which could only appear in the Supported field of requests, and I suspect that approach is technically feasible, though not without some wrinkles we’d need to iron out. The other issue is whether we can feasibly render the IANA registration requirements loose enough to satisfy the people asking for change. 
	
	Against the benefits of more open registration we must weigh the risks that these option-tags will migrate from Supported to Required regardless of the standard. I certainly understand that people out in the world can invent non-standard option-tags and use them in whatever manner they’d like. The question is, by implementing looser registration policies like FCFS, will we really entice any of those parties to bring their option-tags to the standard world, or are they really more interested in using them for Require? And by legitimizing looser policies for IANA registration, will we create a class of “standard” tags with non-public specifications that are used only to wall off islands of non-interoperability? That is, really, the heart of the question – to what degree are standard tags required to designate areas of non-standard behavior in the world? If you don’t expect anyone other than a closed group with access to that private implementation logic to use the features in question, how does a standard option-tag really benefit you? These are the questions that motivated the original IANA policy for option-tags, and the ones we need to answer in this discussion.
	
	While FCFS has its merits, I think Keith is probably correct that the right question to ask is what a looser, expert review procedure would look like. For example, a review might check that the specification for the option-tags actually proposes to use them in a manner consisted with them appearing only in the Supported header in requests. Perhaps that’s the only substantive review criteria, or perhaps there are others we need.
	
	Jon Peterson
	NeuStar, Inc.

		
		
		regards
		
		Keith

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 14 Apr 2010 09:24:10 -0400

On Tue, 2010-04-13 at 18:20 -0400, Peterson, Jon wrote:

> Personally, I think we probably should have this discussion – in fact,
> in Anaheim I suggested to Adam and Paul that this might be a good
> sipcore topic for Maastricht. A number of people have expressed
> interest in trying to create a separate class of option-tags which
> could only appear in the Supported field of requests, and I suspect
> that approach is technically feasible, though not without some
> wrinkles we’d need to iron out. The other issue is whether we can
> feasibly render the IANA registration requirements loose enough to
> satisfy the people asking for change. 
> 
> Against the benefits of more open registration we must weigh the risks
> that these option-tags will migrate from Supported to Required
> regardless of the standard. I certainly understand that people out in
> the world can invent non-standard option-tags and use them in whatever
> manner they’d like. The question is, by implementing looser
> registration policies like FCFS, will we really entice any of those
> parties to bring their option-tags to the standard world, or are they
> really more interested in using them for Require? And by legitimizing
> looser policies for IANA registration, will we create a class of
> “standard” tags with non-public specifications that are used only to
> wall off islands of non-interoperability? That is, really, the heart
> of the question – to what degree are standard tags required to
> designate areas of non-standard behavior in the world? If you don’t
> expect anyone other than a closed group with access to that private
> implementation logic to use the features in question, how does a
> standard option-tag really benefit you? These are the questions that
> motivated the original IANA policy for option-tags, and the ones we
> need to answer in this discussion.

I think that boat sailed a long time ago and pretending otherwise does
no one any good.   Does anyone out there not believe that we already
have 'islands of non-interoperability' whether they are explicitly
signaled with option tags or not?  If that were not true, we'd all spend
a lot less time looking at traces and fiddling with arcane configuration
options.

I don't accept the premise that somehow there is a problem with putting
an option tag in a {Proxy-,}Require header whether there's an RFC for it
or not (prohibitions in 3261 not withstanding).  It's a perfectly
acceptable way of ensuring that either the request is handled the way
that the sender expects it to be, or that the request fails.  If the
extension designer needs that behavior, then they do - and if there's a
graceful fallback, then the 42{0,1} response is a perfectly good
indication that it's time to use it.

Extension designers who want what they come up with to be widely adopted
and supported will still have plenty of motivation to produce a
standards track document whether we change the registry rules or not.
It might even be useful in that regard to have the registry include an
indication of whether a particular option tag is Standards Track or not.

I think that the bar should be lowered to expert review and that there
be some public specification - an Individual Informational RFC should be
more than enough, but I'd be happy to leave IANA the latitude to accept
that a specification is available in a reasonably stable publicly
accessible archive.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 14 Apr 2010 15:43:39 +0200

1) 	When assigning levels of review, please stick to those defined in RFC 5226 rather than some potentially new category.

2) 	RFC 4485 talks at length about the compatibility problems caused by option tags, and makes some requirements on authors on the usage. Are you planning to update RFC 4485? I believe all option tag usages should follow this text, no matter how they are prepared.

regards

Keith

> From: Scott Lawrence [mailto:[email-masked]] 
> Sent: Wednesday, April 14, 2010 2:24 PM
> To: Peterson, Jon
> Cc: DRAGE, Keith (Keith); Hadriel Kaplan; Christer Holmberg; 
> Cullen Jennings; [email-masked]; [email-masked]
> have 'islands of non-interoperability' whether they are 
> explicitly signaled with option tags or not?  If that were 
> not true, we'd all spend a lot less time looking at traces 
> and fiddling with arcane configuration options.
> 
> I don't accept the premise that somehow there is a problem 
> with putting an option tag in a {Proxy-,}Require header 
> whether there's an RFC for it or not (prohibitions in 3261 
> not withstanding).  It's a perfectly acceptable way of 
> ensuring that either the request is handled the way that the 
> sender expects it to be, or that the request fails.  If the 
> extension designer needs that behavior, then they do - and if 
> there's a graceful fallback, then the 42{0,1} response is a 
> perfectly good indication that it's time to use it.
> 
> Extension designers who want what they come up with to be 
> widely adopted and supported will still have plenty of 
> motivation to produce a standards track document whether we 
> change the registry rules or not.
> It might even be useful in that regard to have the registry 
> include an indication of whether a particular option tag is 
> Standards Track or not.
> 
> I think that the bar should be lowered to expert review and 
> that there be some public specification - an Individual 
> Informational RFC should be more than enough, but I'd be 
> happy to leave IANA the latitude to accept that a 
> specification is available in a reasonably stable publicly 
> accessible archive.
> 
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Apr 2010 08:54:28 -0500

Hi, Keith,

> 1) When assigning levels of review, please stick to those defined in RFC 
> 5226 rather than some potentially new category.

I'm guessing/hoping that you're referring to the "well-known IANA policy 
definitions" in Section 4.1, right?

If so - I echo Keith's request. Although we can ask IANA to do lots of 
things, my experience is that most people who use a term that sounds 
something like a section 4.1 term really meant to use that term, which is 
already reviewed by the community and understood by IANA, rather than 
introducing a new policy (which then has to be defined, agreed with IANA, 
etc).

Thanks,

Spencer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 14 Apr 2010 15:59:14 +0200

Correct.

The wording being suggested was suggesting something subtly different from one of the existing categories.

Keith 

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: Wednesday, April 14, 2010 2:54 PM
> To: DRAGE, Keith (Keith); Scott Lawrence; Peterson, Jon
> Cc: [email-masked]; [email-masked]; Hadriel Kaplan
> > 1) When assigning levels of review, please stick to those 
> defined in 
> > RFC
> I'm guessing/hoping that you're referring to the "well-known 
> IANA policy definitions" in Section 4.1, right?
> 
> If so - I echo Keith's request. Although we can ask IANA to 
> do lots of things, my experience is that most people who use 
> a term that sounds something like a section 4.1 term really 
> meant to use that term, which is already reviewed by the 
> community and understood by IANA, rather than introducing a 
> new policy (which then has to be defined, agreed with IANA, etc).
> 
> Thanks,
> 
> Spencer 
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Apr 2010 11:51:08 -0400

> Sent: Wednesday, April 14, 2010 9:44 AM
> 
> 1) 	When assigning levels of review, please stick to those defined in
> RFC 5226 rather than some potentially new category.

Excellent point.  And re-reading that I take back the "FCFS" level for Supported option-tags and suggest Expert Review would be the minimum we consider, if not Specification Required. 

> 2) 	RFC 4485 talks at length about the compatibility problems caused by
> option tags, and makes some requirements on authors on the usage. Are you
> planning to update RFC 4485? I believe all option tag usages should follow
> this text, no matter how they are prepared.

+1.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Apr 2010 11:58:03 -0400

Yeah,
The on-the-wire piece I think is trivial relative to the other issues.  We just create a namespace tag like "P-" (sound familiar?), so it's "P-foo" and "P-bar", and "P-" cannot be in anything but Supported.  But of course that won't prevent someone from just rejecting the request if it doesn't have "P-bar" in Supported.

If we're worried about islands of non-interoperable SIP, well... that's already the case - we've got an archipelago. 

I know it's risky.  I just dunno what to do about that. :(

The folks that don't want to interop won't submit one, agreed.  I don't care about them. 

The folks that want to interop but also want to know if a device can do Foo so they can do Foo too/instead, and want Foo to interop, those I want.

The folks that want to abuse it to mandate their way or the highway, well... that sounds like us. :)

-hadriel

> Sent: Tuesday, April 13, 2010 6:21 PM
> 
> I'm not sure why this discussion comes back to RFC5727, as neither it nor
> its predecessor specifies the IANA procedures for option-tags - the brief
> mention of option-tags in RFC5727 is there simply to defer to RFC3261.
> That much said, during the work on RFC5727 several people raised the
> question of loosening the IANA policies for option-tags; I argued this
> should be deferred for separate consideration from the P- header
> deprecation and related fixes.
> 
> Personally, I think we probably should have this discussion - in fact, in
> Anaheim I suggested to Adam and Paul that this might be a good sipcore
> topic for Maastricht. A number of people have expressed interest in trying
> to create a separate class of option-tags which could only appear in the
> Supported field of requests, and I suspect that approach is technically
> feasible, though not without some wrinkles we'd need to iron out. The
> other issue is whether we can feasibly render the IANA registration
> requirements loose enough to satisfy the people asking for change.
> 
> that these option-tags will migrate from Supported to Required regardless
> of the standard. I certainly understand that people out in the world can
> invent non-standard option-tags and use them in whatever manner they'd
> like. The question is, by implementing looser registration policies like
> FCFS, will we really entice any of those parties to bring their option-
> tags to the standard world, or are they really more interested in using
> them for Require? And by legitimizing looser policies for IANA
> registration, will we create a class of "standard" tags with non-public
> specifications that are used only to wall off islands of non-
> interoperability? That is, really, the heart of the question - to what
> degree are standard tags required to designate areas of non-standard
> behavior in the world? If you don't expect anyone other than a closed
> group with access to that private implementation logic to use the features
> in question, how does a standard option-tag really benefit you? These are
> the questions that motivated the original IANA policy for option-tags, and
> the ones we need to answer in this discussion.
> 
> While FCFS has its merits, I think Keith is probably correct that the
> right question to ask is what a looser, expert review procedure would look
> like. For example, a review might check that the specification for the
> option-tags actually proposes to use them in a manner consisted with them
> appearing only in the Supported header in requests. Perhaps that's the
> only substantive review criteria, or perhaps there are others we need.
> 
> Jon Peterson
> NeuStar, Inc.
>

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 14 Apr 2010 18:32:58 -0400

------- Original message -------
> From: Christer Holmberg <[email-masked]>
> Cc: [email-masked], [email-masked]
> Sent: 11.4.'10,  15:37
>
> I agree with Hadriel.
>
> The situation is very similar to the one we have with INFO, which we are 
> now trying to solve with the Info Events mechanism.
>
And making INFO usages FCFS would have helped how?

The problem is that the extensibility model of "anything that can be 
negotiated with an option-tag" is just too broad. When we have tightly 
specced well-scoped extension models like Events (or like INFO is becoming) 
we can be liberal in what extensions we register. But letting just anybody 
turn the protocol inside out is NOT a recipe for interop.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Apr 2010 19:10:39 -0400

> Sent: Wednesday, April 14, 2010 6:33 PM
> 

We wouldn't have done info-events, we would have just done "info-dtmf" option-tag.  It would have been quick, easy, and simple.  And if someone else had needed INFO to carry their "events", they could have defined "info-foobar".

Sure it would have made more option-tag names instead of event names, and it would have been a specific solution to a specific problem, but incrementalism for specific needs is sometimes a better solution than a new framework.  It's often simpler, more interoperable, faster to market, and more widely adopted. 

Cases in point: Diversion vs. Hist-Info, sdp-cap-neg vs. best-effort-srtp et al, KPML vs. anything else.

> turn the protocol inside out is NOT a recipe for interop.

INFO didn't _really_ have those problems.  Not in practice.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 09:43:23 +0200

Hi,

Normally, when we define an option-tag, we also define SIP extensions and/or modify core SIP concepts.

For example, with "100rel" we have the PRACK method, the Rseq/Rack header fields, and it makes it possible to make 1xx responses reliable.

And, such SIP extensions etc require a standard track document.

So, when we now talk about these easier-to-register option-tags, what kind of features and use-cases do people have in mind, that for other reasons, would not contain anything that would anyway require a standards track document? Examples?

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 15. huhtikuuta 2010 2:11
To: Dean Willis; Christer Holmberg
Cc: Cullen Jennings; [email-masked]; [email-masked]
Subject: RE: [RAI] Option-tag registration

> > The situation is very similar to the one we have with INFO, which we 

> we can be liberal in what extensions we register. But letting just 
> anybody turn the protocol inside out is NOT a recipe for interop.

-hadriel

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 15 Apr 2010 17:10:00 -0400

------- Original message -------
> From: Hadriel Kaplan <[email-masked]>
> To: [email-masked], [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> We wouldn't have done info-events, we would have just done "info-dtmf" 
> option-tag.  It would have been quick, easy, and simple.  And if someone 
> else had needed INFO to carry their "events", they could have defined 
> "info-foobar".

You realize that every request you send is supposed to carry a list of 
every option tag yiu support, right? What do we do when we have more option 
tags than can fit into one UDP packet?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Apr 2010 17:28:15 -0400

> Sent: Thursday, April 15, 2010 5:10 PM
> To: Hadriel Kaplan
> 

The same thing we do when we have more media capabilities, headers, etc. than can fit in one UDP packet.

I don't know what that thing is, but it would be the same.
:)

-hadriel

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 15 Apr 2010 17:12:17 -0500

> I don't know what that thing is, but it would be the same.

RFC 3261 says you switch to TCP :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Apr 2010 18:17:31 -0400

> From: Kevin P. Fleming [mailto:[email-masked]]
> Sent: Thursday, April 15, 2010 6:12 PM
> To: Hadriel Kaplan
> 

Good luck with that. Especially in a response. :)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Apr 2010 17:21:10 -0500

> RFC 3261 says you switch to TCP :-)

Oh, c'mon. Everyone knows TCP doesn't work. That's why email, http, ftp, 
xmpp, and just about every other widely deployed protocol uses an 
unreliable datagram service, like UDP. It takes some really clever 
programmers to figure out all this arcane in-order, reliable, 
connection-oriented stuff. Sure, your smarter SBC vendors can do it -- 
but what about your average telecom vendor? I think we'll have to see 
TCP built into just about every operating system before we can expect to 
see any widespread deployment.

:-P

/a

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Apr 2010 09:45:10 +0200

Which is another stupid rule, which I don't think is observed so much in practice. For example, what is the benefit of 100rel in BYE, answermode in SUBSCRIBE to presence, early-session in PUBISH, outbound in REFER, etc.? In particular, some specifications have used option tags in Supported in a way not intended (i.e., to indicate an option is being used, as opposed to just support for an option), so clearly such option tags cannot be included in all requests. Any relaxation of rules on specifying option tags would also need to consider clarifying the situation on when to include option tags.

John 

> Behalf Of Dean Willis
> Sent: 15 April 2010 22:10
> To: Hadriel Kaplan

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 09:50:01 +0200

Hi,

I agree with John, and option-tag specifications should define for which methods they are applicable.

However, I would even go one step further.

Even if an option-tag makes perfectly sense for a method (e.g. 100rel for INVITE), I see no reason for the UAC to include it if it does not wish to use it.

100rel may be a bad example, but if there an option-tag for some "feature" (whatever that feature is), the UAC should only have to include it if it is interested in using the feature.

Regards,

Christer

> Behalf Of Elwell, John
> Sent: 16. huhtikuuta 2010 10:45
> To: Dean Willis; Hadriel Kaplan
> Which is another stupid rule, which I don't think is observed 
> so much in practice. For example, what is the benefit of 
> 100rel in BYE, answermode in SUBSCRIBE to presence, 
> early-session in PUBISH, outbound in REFER, etc.? In 
> particular, some specifications have used option tags in 
> Supported in a way not intended (i.e., to indicate an option 
> is being used, as opposed to just support for an option), so 
> clearly such option tags cannot be included in all requests. 
> Any relaxation of rules on specifying option tags would also 
> need to consider clarifying the situation on when to include 
> option tags.
> 
> John 
> 
> Behalf Of 
> > Dean Willis
> > > Cc: [email-masked], [email-masked], [email-masked] We 
> > > wouldn't have done info-events, we would have just done
> > "info-dtmf" 
> > every option tag yiu support, right? What do we do when we 
> have more 
> > option tags than can fit into one UDP packet?
> > 
> > --
> > Dean

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 16 Apr 2010 11:30:20 +0200

One of those was the new option tag to say the implementation didn't support TCP (this one is a special character string that is 300 characters long).

Keith 

> Behalf Of Hadriel Kaplan
> Sent: Thursday, April 15, 2010 11:18 PM
> To: Kevin P. Fleming

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 20 Apr 2010 21:17:29 +0300

Hi,

> Which is another stupid rule, which I don't think is observed so much
> in practice. For example, what is the benefit of 100rel in BYE,
> answermode in SUBSCRIBE to presence, early-session in PUBISH,
> outbound in REFER, etc.? In particular, some specifications have used
> option tags in Supported in a way not intended (i.e., to indicate an
> option is being used, as opposed to just support for an option), so
> clearly such option tags cannot be included in all requests. Any
> relaxation of rules on specifying option tags would also need to
> consider clarifying the situation on when to include option tags.

the situation regarding disposition types is similar. As described in
Section 8.1 of RFC 5621, they are supported within a context:

http://tools.ietf.org/html/rfc5621#section-8.1

When we discussed that, we concluded that it was not worthwhile
designing a new mechanism that would be able to report the different
combinations supported by a given UA (e.g., a UA supporting the 'render'
disposition type only for 'text/plain' and 'text/html' body parts only
in MESSAGE requests). Let's keep in this tradeoff in mind (simplicity
vs. expressiveness) when talking about extensions and option tags as well.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 20 Apr 2010 21:27:22 +0300

Hi,

related to the INFO analogy, the design of the INFO events framework has
involved a great deal of mailing list discussion. There has been a
significant amount of energy spent on it. Surprisingly, not many people
have shown interest (so far at least) in registering new INFO packages
(this has been explicitly asked a couple of times during our
face-to-face meetings) now that the framework is (mostly) done. So, when
talking about option tags, let's make sure we have concrete rather than
abstract discussions. Getting a few examples of option tags people would
like to register using the simpler registration method that has been
proposed would help focus this discussion.

I fully agree we need to spend our (limited amount of) energy on
relevant issues. Having a sense of how relevant this issue is in
practice would be useful, IMHO.

Thanks,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 21:58:16 +0200

Hi,

I was the one who brought up INFO, so I'll blame myself for that.

What I wanted to say was that the Info Events framework provides a mechanism for people to register their INFO usages, instead of doing proprietary stuff that doesn't interop.

In a similar way, people seems to be doing things that would benefit from an option-tag, and my understanding is that Hadriel is proposing a mechanism which would make it easier for people to register option-tags.

That was the only reason for comparing it with INFO. Technically they are different things, since an option-tag may relate to more things than what information is carried in an INFO request.

Whether it's useful or not is another question.

>Surprisingly, not many people have shown interest (so far at least) in registering new INFO packages (this has been explicitly asked a couple of times during our face-to-face meetings) now that the framework is (mostly) done. 

At least 3GPP has defined an Info Package, and my understanding is that it will be brought to IANA as soon as it has been agreed at the 3GPP CT plenary.

I know that some SDO has also been discussing an Info Package for IPTV, but I'd need to check the status on that.

Some people may think that the draft must become RFC before they can start registering their packages, but I assume that is not true, so it is maybe something that these people should be informed about.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Apr 2010 01:10:00 -0500

On Apr 21, 2010, at 2:58 PM, Christer Holmberg wrote:

> What I wanted to say was that the Info Events framework provides a  
> mechanism for people to register their INFO usages, instead of doing  
> proprietary stuff that doesn't interop.
>
> In a similar way, people seems to be doing things that would benefit  
> from an option-tag, and my understanding is that Hadriel is  
> proposing a mechanism which would make it easier for people to  
> register option-tags.

Sorry for the late response. I just saw this in the queue -- I must  
have missed it initially.

I think you're tickling a fundamental distinction between uses of an  
existing user-extensible mechanism (INFO, Events, user-URI parameters)  
and something very different -- fundamentally changing the SIP  
protocol itself.

You can't break the SIP protocol with a new event or INFO package. You  
CAN break the protocol with a badly-designed extension to the core  
protocol. An option tag theoretically represents such a fundamental  
extension.  For example, an option-tag grade extension can add new  
request types, new response codes, and new states in the machine. It  
can even change existing specifications, for example changing the  
meaning of a 200 OK (while we try to avoid doing that, the protocol- 
extension mechanism allows it). This is not a power to be used lightly.

True, we have some badly designed extensions that shouldn't have had  
option tags and probably should have used some other extension  
mechanism. But that doesn't suggest that we should make it easy to  
change the core protocol.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Apr 2010 09:39:08 +0200

Hi,

I totally agree that, if we would move forward with this "option-tag lite" proposal, there would have to be some clear restrictions on what one is allowed to do.

Of course, due to the restrictions option-tag may then not be a feasible solution.

So, I think it would be good to first have some input on exactly one should be able to do - and then figure out whether option-tags, or some other mechanism, is the best solution to implement it.

Regards,

Christer

> Sent: 26. huhtikuuta 2010 9:10
> To: Christer Holmberg
> Cc: Gonzalo Camarillo; Hadriel Kaplan; 
> [email-masked]; [email-masked]
> proposing 
> > a mechanism which would make it easier for people to register 
> > option-tags.
> 
> 
> Sorry for the late response. I just saw this in the queue -- 
> I must have missed it initially.
> 
> I think you're tickling a fundamental distinction between 
> uses of an existing user-extensible mechanism (INFO, Events, 
> user-URI parameters) and something very different -- 
> fundamentally changing the SIP protocol itself.
> 
> You can't break the SIP protocol with a new event or INFO 
> package. You CAN break the protocol with a badly-designed 
> extension to the core protocol. An option tag theoretically 
> represents such a fundamental extension.  For example, an 
> option-tag grade extension can add new request types, new 
> response codes, and new states in the machine. It can even 
> change existing specifications, for example changing the 
> meaning of a 200 OK (while we try to avoid doing that, the 
> protocol- extension mechanism allows it). This is not a power 
> to be used lightly.
> 
> True, we have some badly designed extensions that shouldn't 
> have had option tags and probably should have used some other 
> extension mechanism. But that doesn't suggest that we should 
> make it easy to change the core protocol.
> 
> --
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Apr 2010 11:15:35 -0500

On Apr 26, 2010, at 2:39 AM, Christer Holmberg wrote:

>
> So, I think it would be good to first have some input on exactly one  
> should be able to do - and then figure out whether option-tags, or  
> some other mechanism, is the best solution to implement it.
>

Excellent point.

So far, many of the proposals for "options-lite" that sounded  
reasonable to me were requirements not to change the protocol, but to  
convey some additional piece of supplementary information in the  
forward direction, and to assure understanding of the supplemental  
information by the receiver.

Otherwise said, the UAC wants to add some parameters and it wants the  
UAS to inform it if the UAS does not understand those parameters.  
Oddly enough, this is pretty much the use case for Require given in  
RFC 3261. URI parameters were supposed to allow for this, but don't  
work. I'd be willing to consider some dedicated header field for  
arbitrary application parameters, perhaps with a capability  
negotiation built into it.

But let's think about the use case that led us here (I think). PaulJ's  
options-ping.

If the ping flag is present, the UAS MAY respond to an OPTIONS request  
differently than it would under RFC 3261. We're actually changing the  
protocol operation, possibly with unexplored side effects. For  
example, somebody might have built an SBC (B2BUA or Proxy)  that  
watches OPTIONS requests go by and stores the result -- and if that  
SBCs sees an option-tag-free response, it might (reasonably?)  assume  
that the UAS doesn't actually have any capabilities whatsoever.

This would probably be a fairly broken SBC, but it's behavior isn't  
strictly against the rules of prior RFCs, so we'd be introducing a  
backward compatibility problem. In fact's it's not any weirder than  
what the P-CSCF does with p-identity headers. This is subtle. It's a  
measured tradeoff as to whether the risk of the extension failing in  
an unexpected way is worth the optimization.

And this sort of risky tradeoff requires thorough review and  
discussion. Getting thorough review and discussion pretty much means  
having standards-level consensus, and it's why RFC 3261 requires  
standards track for new option tags.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Apr 2010 15:51:28 -0400

> Sent: Monday, April 26, 2010 12:16 PM
> To: Christer Holmberg
> 

Right, that's basically all I was proposing we allow for non-standards-track option-tags.  Just because we open up registration of option-tags, doesn't mean any and all uses of them would be allowed.  There would still be restrictions on what such a tag could or could not do.

> But let's think about the use case that led us here (I think). PaulJ's

Actually that wasn't the one, afaik.  But it too was one that could reasonably expect to go that way, imo.  If we decide it's a type that *shouldn't* be able to get a non-standards-track option-tag, then if we can nail down why not, the reason why-not should be part of the guidance language for an expert reviewer to reject it.

> that the UAS doesn't actually have any capabilities whatsoever.

In the ping case it wouldn't do that - because the SBC would be the one responding to the ping (it is the next-hop).

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Apr 2010 20:48:25 -0500

On Apr 26, 2010, at 2:51 PM, Hadriel Kaplan wrote:

> Right, that's basically all I was proposing we allow for non- 
> standards-track option-tags.  Just because we open up registration  
> of option-tags, doesn't mean any and all uses of them would be  
> allowed.  There would still be restrictions on what such a tag could  
> or could not do.
>
>
> Actually that wasn't the one, afaik.  But it too was one that could  
> reasonably expect to go that way, imo.  If we decide it's a type  
> that *shouldn't* be able to get a non-standards-track option-tag,  
> then if we can nail down why not, the reason why-not should be part  
> of the guidance language for an expert reviewer to reject it.
>
>
> In the ping case it wouldn't do that - because the SBC would be the  
> one responding to the ping (it is the next-hop).

What if somebody pings the wrong thing? Do we need a proxy-require to  
not forward the ping?

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Apr 2010 21:01:20 -0500

On 4/27/10 20:48, Apr 27, Dean Willis wrote:
>> Right, that's basically all I was proposing we allow for 
>> non-standards-track option-tags.  Just because we open up 
>> registration of option-tags, doesn't mean any and all uses of them 
>> would be allowed.  There would still be restrictions on what such a 
>> tag could or could not do.
>>
>>
>> reasonably expect to go that way, imo.  If we decide it's a type that 
>> *shouldn't* be able to get a non-standards-track option-tag, then if 
>> we can nail down why not, the reason why-not should be part of the 
>> guidance language for an expert reviewer to reject it.
>>
>>

This is really, really starting to sound like a new method.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 22:12:13 -0400

> Sent: Tuesday, April 27, 2010 9:48 PM
> To: Hadriel Kaplan
> 

No, the max-forwards is 1 to prevent that.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 22:30:23 -0400

> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, April 27, 2010 10:01 PM
> To: Dean Willis
> 

Why?  Creating a new method doesn't avoid the issue of intended target routing. (a legacy proxy would forward it like any other unknown method)

The only thing about the options-ping which could lead to a new method would be if it doesn't actually retrieve the UA's/Proxy's capabilities.  There has been discussion about doing exactly that (not returning the capabilities), but that's a discussion topic for the sipcore thread on the draft I guess.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Apr 2010 22:21:11 -0500

On 4/27/10 21:30, Apr 27, Hadriel Kaplan wrote:
> ...but that's a discussion topic for the sipcore thread on the draft I 
> guess.

Good point. I've replied regarding this topic on the SIPCORE list.

/a