Subject: [sipcore] SIP OPTIONS: Shall we work on this?

From: Adam Roach <[email-masked]>
Date: Tue, 30 Mar 2010 14:05:37 -0500

[as chair]

One of the topics of discussion at the recent face-to-face meeting in 
Anaheim was the SIP OPTIONS method. We have had significant discussion 
of some specific technical topics on the SIPCORE mailing list, such that 
all participants should have a reasonable overview of the scope that any 
related work may entail. Participants may also benefit from reading 
through the minutes of the corresponding conversation in Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTIONS%20Method

Rather than continue discussion of the specific technical topics related 
to OPTIONS, the chairs would encourage the working group to engage in a 
discussion around whether we should, as a group, work on addressing some 
of the issues that have been identified.

In particular, we would direct the group to consider the nature of such 
work:

    * Are we proposing to introduce new features, or fix existing bugs?
    * If we are adding new features: is OPTIONS the best way to
      introduce these features, or would other mechanisms (presence,
      callee-caps) produce superior results?
    * If we are fixing bugs: are the bugs theoretical, or can we cite
      actual interoperability issues in the field?
    * If there are identified interoperability issues: is the level of
      effort involved in fixing them commensurate with the impact of the
      problems?

Finally, keep in mind that work does not happen unless participants are 
willing to invest time. If you speak out in favor of pursuing this work, 
please indicate the level of time commitment that you will personally 
invest in bringing such work to a successful conclusion (e.g., will 
author drafts; will perform dedicated reviews; etc).

Thanks.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Mar 2010 07:56:05 +0200

Hi,

Adam, thanks for sending out the the e-mail!

First, a clarification regarding "new features":

When we say "new features", I assume (based on Hadriel's comment in the meeting) it means the possibility to, with a single OPTIONS request, retrieve the capabilities from ALL UAS(s) behind a forking proxy - instead of only one UAS (whoever sends the 200 OK to the forking proxy first).

The message I got from the meeting, and also previous e-mail discussions, was that the "OPTIONS 3xx" solution already provideds this feature, and that it can be used (without defining new protocol elements etc).

So, in my opinion the "adding" word is a little missleading. Instead I think the question is whether we want to DOCUMENT that existing feature.

Second, regarding bugs and interoperability issues in the field. Personally I am not sure of any major ones at the moment, but that is probably because OPTIONS haven't been very much deployed in the first place (it has been used for some keep-alive/ping purposes, but in those cases it really doesn't matter what comes in the response etc). Now, however, at least I am starting to get questions regarding the usage of OPTIONS, so I guess we need to ask ourselves whether we think the bugs WILL create interoperability issues.

And, the issue you raised regarding using the re-INVITE to re-create dialogs ("[sipcore] Mea Culpa: Dialog Necromancy in RFC 3261") also affects OPTIONS, eventhough you want to keep them separate (which is ok).

Obviously I am in favor of pursuing the work, and will be willing to author drafts :)

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 30. maaliskuuta 2010 22:06
To: SIPCORE
Subject: [sipcore] SIP OPTIONS: Shall we work on this?

[as chair]

One of the topics of discussion at the recent face-to-face meeting in Anaheim was the SIP OPTIONS method. We have had significant discussion of some specific technical topics on the SIPCORE mailing list, such that all participants should have a reasonable overview of the scope that any related work may entail. Participants may also benefit from reading through the minutes of the corresponding conversation in Anaheim:

Rather than continue discussion of the specific technical topics related to OPTIONS, the chairs would encourage the working group to engage in a discussion around whether we should, as a group, work on addressing some of the issues that have been identified.

In particular, we would direct the group to consider the nature of such work:

 *   Are we proposing to introduce new features, or fix existing bugs?
 *   If we are adding new features: is OPTIONS the best way to introduce these features, or would other mechanisms (presence, callee-caps) produce superior results?
 *   If we are fixing bugs: are the bugs theoretical, or can we cite actual interoperability issues in the field?
 *   If there are identified interoperability issues: is the level of effort involved in fixing them commensurate with the impact of the problems?

Finally, keep in mind that work does not happen unless participants are willing to invest time. If you speak out in favor of pursuing this work, please indicate the level of time commitment that you will personally invest in bringing such work to a successful conclusion (e.g., will author drafts; will perform dedicated reviews; etc).

Thanks.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Mar 2010 09:44:26 -0400

Christer,

[as chair]

By accepting the 3xx solution to handling multiple UAs, you have removed 
the most obvious "new feature". There may or may not be other less 
obvious ones lurking in there. For instance, you (and I) have suggested 
using Request-Disposition:redirect to "ensure" the 3xx is returned. But 
honoring R-D is optional by the proxy. So at the moment there is no way 
to be certain that you are getting info for all the available UAs. 
Anything that somehow made honoring R-D mandatory for OPTIONS would be a 
new feature.

Also, there are other cases where the behavior is currently 
optional/ambiguous. "Fixing" those to be unambiguous/non-optional can 
also be construed as a *change*. (There is a fine line here about what 
is intended by the current texts.)

It will certainly be easier if no normative changes are required.

In any case, having you willing to do the work is a good thing. But 
there had better also be others that are interested in the work enough 
to review and comment on it, and to justify spending list and meeting 
time on.

[As individual]

I have "mild" interest in this from an academic perspective, but I don't 
see it as necessary work. I'm waiting to see how much other interest 
there is.

	Thanks,
	Paul

Christer Holmberg wrote:
> When we say "new features", I assume (based on Hadriel's comment in the 
> meeting) it means the possibility to, with a single OPTIONS 
> request, retrieve the capabilities from ALL UAS(s) behind a forking 
> proxy - instead of only one UAS (whoever sends the 200 OK to the forking 
> proxy first).
>  
> The message I got from the meeting, and also previous e-mail 
> discussions, was that the "OPTIONS 3xx" solution already provideds this 
> feature, and that it can be used (without defining new protocol elements 
> etc).
>  
> So, in my opinion the "adding" word is a little missleading. Instead I 
> think the question is whether we want to DOCUMENT that existing feature.
>  
>  
> Second, regarding bugs and interoperability issues in the field. 
> Personally I am not sure of any major ones at the moment, but that is 
> probably because OPTIONS haven't been very much deployed in the first 
> place (it has been used for some keep-alive/ping purposes, but in those 
> cases it really doesn't matter what comes in the response etc). Now, 
> however, at least I am starting to get questions regarding the usage of 
> OPTIONS, so I guess we need to ask ourselves whether we think the bugs 
> WILL create interoperability issues.
>  
> And, the issue you raised regarding using the re-INVITE to re-create 
> dialogs ("[sipcore] Mea Culpa: Dialog Necromancy in RFC 3261") also 
> affects OPTIONS, eventhough you want to keep them separate (which is ok).
>  
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Adam Roach
> *Sent:* 30. maaliskuuta 2010 22:06
> *To:* SIPCORE
> *Subject:* [sipcore] SIP OPTIONS: Shall we work on this?
> 
> [as chair]
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Mar 2010 22:16:39 +0200

Hi, 

>[as chair]
>
>By accepting the 3xx solution to handling multiple UAs, you have removed the most obvious "new feature". There may or may not be other less obvious ones lurking in there. For instance, you (and I) have 
>suggested using Request-Disposition:redirect to "ensure" the 3xx is returned. But honoring R-D is optional by the proxy. So at the moment there is no way to be certain that you are getting info for all 
>the available UAs. 
>Anything that somehow made honoring R-D mandatory for OPTIONS would be a new feature.

I agree.

To clarify, I have not suggested anything that would make honoring R-D mandatory. I am fully aware that proxies may not do that (due to policy rules, or the fact that they don't support R-D in the first place). That is true for the 3841 mechanism in general. So, if the proxy does not honor R-D, things will work as today.

I am not even sure how we could mandate the proxy to honor R-D. Proxy-Require is bad, since it affects all proxies, and we don't have a Proxy-Require-If-You-Intend-To-Fork header field :)

>Also, there are other cases where the behavior is currently optional/ambiguous. "Fixing" those to be unambiguous/non-optional can also be construed as a *change*. (There is a fine line here about what is 
>intended by the current texts.)
>

I agree.

Personally, based on the studies and discussions so far, I think a BCP would be enough. Yes, people can claim that the RFC still allows this and that, but I think that most people do take BCPs into considerations when they design their implementations.

>In any case, having you willing to do the work is a good thing. But there had better also be others that are interested in the work enough to review and comment on it, and to justify spending list and 
>meeting time on.

Sure. For me the main issue was to find a solution for the forking issue, and the 3xx solution should probably be ok (even if it can't be mandated). 

I DO think it would be good to document it, and also to document/clarify the unambiguous stuff, but if people object I am not going to fight for it, eventhough I think that it generally is very bad to have that kind of unambiguous stuff in our protocol speicifcations :)

Regards,

Christer

Christer Holmberg wrote:
> meeting) it means the possibility to, with a single OPTIONS request, 
> retrieve the capabilities from ALL UAS(s) behind a forking proxy - 
> instead of only one UAS (whoever sends the 200 OK to the forking proxy 
> first).
>  
> discussions, was that the "OPTIONS 3xx" solution already provideds 
> this feature, and that it can be used (without defining new protocol 
> elements etc).
>  
> place (it has been used for some keep-alive/ping purposes, but in 
> those cases it really doesn't matter what comes in the response etc). 
> Now, however, at least I am starting to get questions regarding the 
> usage of OPTIONS, so I guess we need to ask ourselves whether we think 
> the bugs WILL create interoperability issues.
>  
> of some specific technical topics on the SIPCORE mailing list, such 
> that all participants should have a reasonable overview of the scope 
> that any related work may entail. Participants may also benefit from 
> reading through the minutes of the corresponding conversation in Anaheim:
> 
> Rather than continue discussion of the specific technical topics 
> related to OPTIONS, the chairs would encourage the working group to 
> engage in a discussion around whether we should, as a group, work on 
> addressing some of the issues that have been identified.
> 
> Finally, keep in mind that work does not happen unless participants 
> are willing to invest time. If you speak out in favor of pursuing this 
> work, please indicate the level of time commitment that you will 
> personally invest in bringing such work to a successful conclusion 
> (e.g., will author drafts; will perform dedicated reviews; etc).
> 
> Thanks.
> 
> /a
> 
>