Subject: Re: [sipcore] Question on Require in responses

From: "Elwell, John" <[email-masked]>
Date: Fri, 01 May 2009 08:10:54 +0100

Paul,

I am not disagreeing with you, but a consequence of this analysis is
that many option tags, or the way they are intended to be used,
guarantee very little when they appear in Supported. The only time an
option tag has real meaning in Supported is when it appears in a request
to mean that the UAS can safely use that capability when responding.
Examples of option tags used differently from this:
- norefersub - its use in one request means that the UA is capable of
accepting a subsequent REFER request without implicit subscription;
- join/replaces - use of either of these in one request indicates that
the UA would support the respective header field if received in another
request;
- from-change - use in one request indicates support for this feature in
subsequent requests on that dialog;
- eventlist - use in a SUBSCRIBE request indicates support for this
feature in received NOTIFY requests on dialogs created from that
SUBSCRIBE request;
- answermode - use in a REGISTER request indicates support for this
feature in a received INVITE request.

Even if there are no absolute guarantees, there is a general expectation
that things will work if used in the way described in the RFC where the
option tag is defined. For example, if receipt of a replaces option tag
does not mean that the Replaces header field is likely to be supported
if received in future request from outside the dialog, things like
attended call transfer would not work with any degree of reliability.

So I think the scope of an option tag is defined by the RFC where the
option tag is defined.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 01 May 2009 00:23
> To: Hans Erik van Elburg
> Cc: SIPCORE
> Subject: Re: [sipcore] Question on Require in responses
> 
> 
> 
> Hans Erik van Elburg wrote:
> > 
> > Dean Willis wrote:
> >> The option tag is a means of 1) discovering whether or not 
> the far-end 
> >> supports a specific extension and of 2) declaring the 
> criticality of 
> >> understanding that extension relative to satisfying a 
> request and 3) 
> >> informing the UAC of what extensions were applied to the 
> request in 
> >> order to generate the response. This is purely a function of 
> >> capability negotiation, not one of invocation.
> >>
> >> The extension itself (typically, an extension header 
> field, although 
> >> there are other types of extensions) is what causes the 
> extension to 
> >> be invoked.
> > Depends a bit how you define extension, but I would argue that if I 
> > require an extension to be supported on a 
> transaction/dialog by the UAS 
> > and the UAS accepts the request that this means that for 
> this call the 
> > UAS behaves as it should according to the extensions specification.
> 
> There are several issues in what you say above:
> 
> "if I require an extension to be supported on a 
> transaction/*dialog* by 
> the UAS"
> 
> supported for a transaction, and supported for a dialog are two very 
> different things. We certainly don't have a way to say 
> whether you want 
> one or the other.
> 
> These headers were derived from http, and there they really 
> only apply 
> for one transaction. Nominally that is all they mean for sip too.
> 
> In practice, particular features really have a broader scope 
> than that, 
> but there is little/no formality about that.
> 
> "if... and the UAS accepts the request that means that *for 
> this call* 
> the UAS behaves as it should according to the extensions 
> specification"
> 
> There you have assumed that the scope is, depending on your 
> terminology,
> - the call
> - the session
> - the dialog
> - the dialog usage
> 
> But in general you cannot assume that. The support may cease 
> on the next 
> transaction, explicitly or implicitly. It is far from clear that 
> support, or requirements to support, continue if not restated 
> in every 
> transaction. Nor is there any guarantee that support, if indicated in 
> the response to a transaction, will continue even momentarily 
> before the 
> next transaction.
> 
> And of course there is no guarantee that features that are 
> indicated as 
> supported in response to an OPTIONS will continue to be 
> supported when a 
> call is made to the same address.
> 
> 	Thanks,
> 	Paul
> 
> > Saying that an extensions invokes itself is meaningless to me.
> > 
> > A UAS may choose to only invoke the extension behaviour if 
> it finds that 
> > the extension is required. That comes close to saying that the 
> > require:extension invokes the behaviour in the UAS, but it 
> is not at all 
> > the same.
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 May 2009 08:53:00 -0400

John,

I'm not trying to assert that the situation is a good one. But I have 
been trying to achieve a general understanding that you cannot, 
currently, infer too much from these headers. Do so and you will set 
yourself up for disappointment.

Perhaps we should work define the scope for these things, and where 
appropriate specify that it is more extensive than a single transaction. 
But I think it will be impossible to make any commitments that much of 
anything has dialog scope. I think the most we can hope for is: this 
remains true until a change is signaled.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 1 May 2009 16:46:15 +0200

Yes.

/Hans Erik van Elburg

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 3 May 2009 20:25:05 +0200

Hi, 

>>The option tag is a means of 1) discovering whether or not the far- 
>>end supports a specific extension and of 2) declaring the criticality 
>>of understanding that extension relative to satisfying a request and 
>>3) informing the UAC of what extensions were applied to the request 
>>in order to generate the response. This is purely a function of 
>>The extension itself (typically, an extension header field, although 
>>there are other types of extensions) is what causes the extension to 
>>be invoked.
>require an extension to be supported on a transaction/dialog by the 
>UAS and the UAS accepts the request that this means that for this call 
>specification.
>A UAS may choose to only invoke the extension behaviour if it finds 
>that the extension is required. That comes close to saying that the 
>require:extension invokes the behaviour in the UAS, but it is not at 
>all the same.
>
>
>The Require doesn't control whether the UAS invokes the extension. The
UAS may invoke the extension on its own recognizance.  Most likely, it
chooses to do so based on 1) the presence of a Supported 
>indicator for the extension in a request as evidence that the UAC
supports the extension or the presence of an extension header in the
request that also indicates support in the UAC and 2) support for 
>that extension in the UAS. Other extensions may not require support in
the UAC, so may be enacted by this UAS purely on local policy.

100rel does not carry any extension headers in the request, nor does
RFC3262 say that the UAC must insert Supported in addition to Require.

But, RFC3262 DOES say:

"The UAS MUST send any non-100 provisional response reliably if the
initial request contained a Require header field with the option tag
100rel."

So, in my opinion Require:100rel means:

1. The UAC supports 100rel (no Suppored needed)
2. The UAS MUST use the extension (if sending non-100 provisional
responses).

I have nothing against saying that the definition of each option-tag
should specify how it is used, and what Require really means as far as
the UAS is concerned, but I don't think the generic definition of
Supported and Require that you are proposing fits all cases.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 May 2009 08:53:14 -0400

Christer,

I haven't gone back to 3262 to verify that the words are consistent with 
what you say, but I trust you and my memory on that.

IMO it is not a good thing that there is such variation of meaning of 
Supported and Require. It would be much better if it was consistent 
across all options, in the way that Dean has been saying. But I guess 
that horse is out of the barn. Maybe we can try to enforce a consistent 
meaning across all *new* uses, but the old ones will have to remain as 
they are, which makes it more difficult to create a generic mechanism in 
an implementation.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 4 May 2009 22:11:26 +0200

Hi,

I don't think there is an issue with Supported. Supported:foo means "I
support foo" - nothing more, nothing less.

When it comes to Require:foo, it of course means "I require you to
support foo".

BUT, whether Require:foo also means "I require you to always use foo",
"I require you to use foo in specific situations", or "I require you to
support foo, but you don't have to use it" I think depends very much on
the extension, and choosing one of the above meanings for all future
extensions could be very restrictive.

In addition, there also seems to be different opinions on whehter
Require:foo also indicates that the sender supports it or not, or only
requires the receiver to support it. In most cases I think it can be
assumed that the sender also supports the extension, because the sender
would somehow be involved in the procedures associated with the
extension. But, there COULD of course be an extension which is only
affects the receiver, and does not require any kind of support by the
sender.

And, I think we have more or less the same issues/questions with
Proxy-Require as we have for Require.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 3:53 PM
To: Christer Holmberg
Cc: Dean Willis; Hans Erik van Elburg; SIPCORE
Subject: Re: [sipcore] Question on Require in responses

Christer,

	Thanks,
	Paul

Christer Holmberg wrote:
>>> end supports a specific extension and of 2) declaring the 
>>> criticality of understanding that extension relative to satisfying a

>>> request and

>> UAS and the UAS accepts the request that this means that for this 
>> call the UAS behaves as it should according to the extensions 
>> specification.
>>

> 1. The UAC supports 100rel (no Suppored needed) 2. The UAS MUST use 
> the extension (if sending non-100 provisional responses).
>

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 04 May 2009 18:02:43 -0400

> So I think the scope of an option tag is defined by the RFC where the

This is an exceedingly good description of the state of practice.  But
the RFCs aren't written particularly well with this concept in mind.
Consider "eventlist".  You describe its scope quite cleanly:

        - eventlist - use in [Supported in] a SUBSCRIBE request
        indicates support for this feature in received NOTIFY requests
        on dialogs created from that SUBSCRIBE request;

But the text of the RFC doesn't seem to *say* that.  As far as I can
tell (without reading all of it), (normatively) the RFC says that it
creates the "eventlist" tag, and then says (explicitly non-normatively):

      Any client that supports the event list extension will include an
      option tag of "eventlist" in a "Supported" header field of every
      SUBSCRIBE message for a subscription for which it is willing to
      process a list.  If the subscription is made to a URI that
      represents a list, the RLS will include "eventlist" in a "Require"
      header field of the response to the SUBSCRIBE, and in all NOTIFY
      messages within that subscription.

The first sentence is close to what you have written, but as you note,
that fact needs to be stated normatively.  The second sentence talks
about "Require" in a response, which is far as I can tell, has no
defined meaning.

We've not been at all good about defining the scope of meaning of option
tags, and beyond that, we haven't been careful to regularize and
standardize the scopes, so that each usage doesn't need custom code to
be handled.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 04 May 2009 18:08:02 -0400

> affects the receiver, and does not require any kind of support by the

I think it would be best, and also safe, to *not* have "Require: foo"
imply "Supported: foo".  Of course, in most cases, the first without the
second would be useless. as the response to the request would include
information that the UAC could not process usefully.  But there is no
reason that an extension need be symmetric between the UAC and UAS sides
of a transaction, or that in an ongoing dialog, that using an extension
for requests going in one direction requires using the extension for
requests going in the other direction.

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 4 May 2009 20:57:45 -0500

> support foo" - nothing more, nothing less.

I agree 100%.

> When it comes to Require:foo, it of course means "I require you to

Right so far.

> extensions could be very restrictive.

How about the authorization question: Christer requires the UAS to  
support and use the Foo: extension, but Christer is not authorized to  
use the Foo: extension at this UAS. UAS would be willing to process  
the request for Christer without using Foo:, but SIP provides no  
mechanism for UAS to tell Christer not to use Foo:.

Consequently, we need that "very restrictive" model, or we need new  
feature-authorization-negotiation capabilities.

> affects the receiver, and does not require any kind of support by the

Bingo. That's why it should also be in the sender's uipported:, and  
any extension that triggers on the REQUIRE to indicate support in the  
UAC is just badly written.

And yes, we have erroneous RFCs. Just because we wrote it that way  
doesn't make it right -- either something has to change in RFC 3261,  
or something has to change in the RFCs that misuse Require.

> Proxy-Require as we have for Require.

Perhaps not quite so much, as we have written so few proxy-extensions,  
but probably true.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 4 May 2009 21:06:19 -0500

> about "Require" in a response, which is far as I can tell, has no

"Require" in a response has a defined meaning: It means that the  
referenced extension was applied in formulating the response.  Of  
course, we have erroneous RFCs (including some I edited, dang it!)  
that don't do this right.

To quote RFC 3261  8.2.4 Applying Extensions:
> Any extensions applied to a non-421 response MUST be listed in a  
> Require header field included in the response.

Note that the following sentence, also from that section, is under  
debate -- I think it is not justifiable and should allow informational- 
track RFCs.
> Of course, the server MUST NOT apply extensions not listed in the  
> Supported header field in the request. As a result of this, the  
> Require header field in a response will only ever contain option  
> tags defined in standards- track RFCs.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 4 May 2009 21:07:44 -0500

On May 4, 2009, at 8:57 PM, Dean Willis wrote:

> support and use the Foo: extension, but Christer is not authorized  
> to use the Foo: extension at this UAS. UAS would be willing to  
> process the request for Christer without using Foo:, but SIP  
> provides no mechanism for UAS to tell Christer not to use Foo:.
>
> any extension that triggers on the REQUIRE to indicate support in  
> the UAC is just badly written.
>

Oops - it should be in the senders "Supported". If I could just type,  
I would only look half as stupid. Okay, maybe 3/4.

> Perhaps not quite so much, as we have written so few proxy- 
> extensions, but probably true.
>
> --
> Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 May 2009 22:38:52 -0400

>> support foo" - nothing more, nothing less.

What about those cases where a UAC and UAS must both "support" it for it 
to be used, but where the roles are asymmetric?

There are lots of those. For instance, eventlist. Do you only advertise 
support if you can *receive* an eventlist in a NOTIFY?

What do you say if you are capable of sending eventlist in a NOTIFY, but 
not of receiving it. (Perhaps because you never subscribe to anything.)

	Thanks,
	Paul

> use the Foo: extension at this UAS. UAS would be willing to process the 
> request for Christer without using Foo:, but SIP provides no mechanism 
> for UAS to tell Christer not to use Foo:.
> 
> Bingo. That's why it should also be in the sender's uipported:, and any 
> extension that triggers on the REQUIRE to indicate support in the UAC is 
> just badly written.
> 
> doesn't make it right -- either something has to change in RFC 3261, or 
> something has to change in the RFCs that misuse Require.
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 May 2009 07:40:02 +0200

Hi, 

>>Require:foo also indicates that the sender supports it or 
>>not, or only requires the receiver to support it. In most cases I
think 
>>it can be assumed that the sender also supports the extension, because
the 
>>sender would somehow be involved in the procedures associated with the

>imply "Supported: foo".  Of course, in most cases, the first 
>without the second would be useless. as the response to the 
>request would include information that the UAC could not 
>process usefully.  But there is no reason that an extension 
>need be symmetric between the UAC and UAS sides of a 
>transaction, or that in an ongoing dialog, that using an 
>extension for requests going in one direction requires using 
>the extension for requests going in the other direction.

Currently I wonder if there is a single extension which requires the UAC
to send Supported:foo in addition to Require:foo to indicate that the
UAC also supports the extension. The reason is probably that most (all?)
extensions do require some kind of support from both the UAC and UAS.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 May 2009 08:10:32 +0200

Hi, 

>>>Require:foo also indicates that the sender supports it or not, or 
>>>only requires the receiver to support it. In most cases I think it 
>>>can be assumed that the sender also supports the extension, because 
>>>the sender would somehow be involved in the procedures associated 
>>>with the extension. But, there COULD of course be an extension which 
>>>is only affects the receiver, and does not require any kind of 
>>>support by the sender.
>>
>Oops - it should be in the senders "Supported". If I could 
>just type, I would only look half as stupid. Okay, maybe 3/4.

Doesn't that mean that most extensions are badly written?
 
>>or something has to change in the RFCs that misuse Require.

Some extensions are already widely deployed, so I don't think we can do
very much about those. 

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 May 2009 11:37:03 -0500

On May 4, 2009, at 9:38 PM, Paul Kyzivat wrote:

> What about those cases where a UAC and UAS must both "support" it  
> for it to be used, but where the roles are asymmetric?

What about them? Sending a "Supported" in a request or response means  
the UAC supports the extension. Sending a "Require" in a request means  
the UAS must support the extension. Whether or not the extension  
actually gets used is dependent on policy, authorization, and the  
extension itself.

>
>
> There are lots of those. For instance, eventlist. Do you only  
> advertise support if you can *receive* an eventlist in a NOTIFY?

Yes.

>
>
> What do you say if you are capable of sending eventlist in a NOTIFY,  
> but not of receiving it. (Perhaps because you never subscribe to  
> anything.)

Nothing (at least from the current spec, AFAIK).

If we need asymmetric negotiation, we need to define two different  
option tags, for example "event-list-receive" and "eventlist-send".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 May 2009 11:40:27 -0500

> Doesn't that mean that most extensions are badly written?

Most of our documents could stand improvement. Perfection keeps  
eluding me. Please let me know when you feel you've achieved it, as I  
enjoy comedy.

> Some extensions are already widely deployed, so I don't think we can  

Other than fixing the specification, there's not much we can do.

Backward compatibility can be assured through Postel's maxim.  
Specification fixes should explain how this applies to the  
specification in question.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 May 2009 13:29:46 -0400

Dean Willis wrote:
>> What about those cases where a UAC and UAS must both "support" it for 
>> it to be used, but where the roles are asymmetric?
> 
> the UAC supports the extension.

Which role does it mean it supports? Assuming the asymmetric roles can 
be ascribed to the UAC and UAS, then perhaps a Supported:foo in a 
request means that the sender supports the UAC role for foo, and a 
Supported:foo in a response means that the sender supports the UAS role 
for foo?

But what if I want to know if you support the UAC role for foo? How can 
I find that out? I could send you an OPTIONS request, but then your 
answer would be telling me if you support the UAS role, not the UAC role.

> Sending a "Require" in a request means 
> the UAS must support the extension.

Again, does that mean it must support the UAS role. What if I send a 
Require as part of a REFER in expectation that the option will be used 
in the referred request? In that case it will be the UAC role that it 
must use.

> Whether or not the extension 

I agree that is the way it should have been.

> option tags, for example "event-list-receive" and "eventlist-send".

I think many of the options are asymmetric, so perhaps many of them 
really need pairs of options.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 May 2009 13:22:00 -0500

On May 5, 2009, at 12:29 PM, Paul Kyzivat wrote:

>> What about them? Sending a "Supported" in a request or response  
>> means the UAC supports the extension.
>
> Which role does it mean it supports? Assuming the asymmetric roles  
> can be ascribed to the UAC and UAS, then perhaps a Supported:foo in  
> a request means that the sender supports the UAC role for foo, and a  
> Supported:foo in a response means that the sender supports the UAS  
> role for foo?

Whichever role the assigning RFC defines for the option tag. By  
default, this is a symmetric negotiation, unless the RFC says otherwise.

> But what if I want to know if you support the UAC role for foo? How  
> can I find that out? I could send you an OPTIONS request, but then  
> your answer would be telling me if you support the UAS role, not the  
> UAC role.

That depends on the RFC. Most if not all currently only define one  
role for negotiation.

>
>
>> Sending a "Require" in a request means the UAS must support the  
>> extension.
>
> Require as part of a REFER in expectation that the option will be  
> used in the referred request? In that case it will be the UAC role  
> that it must use.

Perhaps I should have said "the node that was acting as a UAS in the  
handling of the receipt of the request, even if it becomes a UAC in  
some future transaction wherein the extension applies".

But sending a Require in the body of a REFER says very little or  
nothing about whether or not the extension will be applied in the  
transaction induced by the REFER; in general, if you want that to  
apply, you have to encode it as part of the Refer-To URI, because  
that's what gets applied to the induced request.

Require in a body never really "induces" behavior. For example, you  
might Require me to support a feature that I support don't allow you  
to use. I don't fail the request with a 420 -- instead, I just ignore  
your Require.

>
>
>> Whether or not the extension actually gets used is dependent on  
>> policy, authorization, and the extension itself.
>

No, really it's that way. See the above example on not using an  
extension  . . . It's just the the discussion in some of the RFCs is  
misleading or downright wrong.

>>> What do you say if you are capable of sending eventlist in a  
>>> NOTIFY, but not of receiving it. (Perhaps because you never  
>>> subscribe to anything.)

I agree with that conclusion.

--
Dean Willis

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 May 2009 23:26:52 +0200

Hi, 

>Most of our documents could stand improvement. 

I couldn't agree more, but in this case you are talking about a rule
which may NEVER have been used for our specifications.

>Perfection keeps eluding me. Please let me know when you feel you've
achieved it, as I enjoy comedy.

There is no such thing as perfection in standards.

>>Some extensions are already widely deployed, so I don't think we can 
>>do very much about those.
>

Yes.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 May 2009 19:03:54 -0500

> which may NEVER have been used for our specifications.

Yet it is written that way in RFC 3261.

So, where is the error? To achieve consistency, SOMETHING has to change.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 May 2009 08:04:08 +0200

>So, where is the error? To achieve consistency, SOMETHING has 

Yes, and in this case LOTS of stuff would have to be changed. There
would be essential correction drafts to a number of specs :)

Regards,

Christer

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 13 May 2009 17:06:00 -0400

> > Require header field included in the response.

Very good point.  And now that you mention it, I have the annoying
feeling that I knew that at some point.  But this passage does mean that
the meaning of Requires in responses is quite a bit different than the
meaning in requests.

There is some subtlety to the phrase "extension applied to a response":
I believe that what is meant is not "the operations defined by the
extension were applied when processing this request" but "this response
cannot be properly understood by a UAC that does not support the
extension [whatever that means]".  That is, there are times when an
extension is *used* by the UAS when processing a request but the UAS
does not put a Requires header in the response.

The obvious example is a registrar that constructs a GRUU for a
registration of a UA, but the UA does not support GRUU, so the registrar
does not add "Require: gruu" to the response, nor put the GRUU
field-parameters in the Contact headers of the response.  (Though
ironically, if the UA ignores unknown field parameters correctly, the UA
would *not* need to support GRUU to handle the GRUU field-parameters
correctly.)

Intriguingly, the only time such a Require is useful is if the UAC needs
to know whether the extension was applied or not, and that fact is not
indicated by any other information in the response.  Do we have any
extensions for which that can happen?

> > tags defined in standards- track RFCs.

I'm not so worried about where the tags are defined, as a UAC can only
see tags in responses that it understands.  The central point is that
the UAC can only receive "Requires: foo" in a response if it has
declared "Supported: foo" in the request, so there can never be the
problem of "receiving a response that contains a Requires tag that it
does not understand".

> mechanism for UAS to tell Christer not to use Foo:.

Although "Require: foo" in responses (or other indication of whether the
foo extension was applied) does tell Christer whether his request to use
foo was acted upon.

> extensions do require some kind of support from both the UAC and UAS.

Currently, I think the extensions fall into two categories, neither of
which require such sophistication:

1) Extensions where the processing by each end is very similar, so that
we expect that the "UAS implementation" and the "UAC implementation" can
only be done together.  I suspect that session-timers are like this
(although I could be wrong, as I haven't studied session-timers).

2) Extensions where the relationship between the two UAs is inherently
asymmetrical, and the respective roles are fixed with the first request.
gruu and eventlist are like this.

In the long run, there might be cases that fall into neither of these
cases.  In that case, the "obvious" logic is that a Requires demands
that the UAS support the UAS-side of the extension.

What Supported means is less obvious.  Thinking about what has been said
above, the one thing that Supported in a request *must* mean is that the
UAC tolerates any extension-specific features in the response,
equivalently, that Requires will be tolerated in the response.  That
means that Supported in a request says that the UAC supports the
UAC-side of the extension.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 May 2009 09:17:26 -0400

> UAC-side of the extension.

Mostly I think Dale is right here. But even in these kinds of cases 
there remains a level of ambiguity. Take for instance eventlist:

If I am subscribing to some event, and include Supported:eventlist, then 
it does at least mean I can handle event lists in notifications I receive.

But does it also mean that I could provide an event list if somebody 
sent a subscription to me?

I guess you could say: try the subscribe and see what I say. That would 
be entirely appropriate if we can conclude that the significance of the 
Supported is bounded to the context in which it is used - the 
subscription in this case.

But Supported in OPTIONS makes hash of that. Including 
Supported:eventlist in an OPTIONS could mean most anything.

IMO, presence of almost anything in an OPTIONS is a very weak promise of 
support. At most I think it means: "I may support this feature in *some* 
context - your mileage may vary."

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Sun, 17 May 2009 16:42:46 -0500

> sent a subscription to me?

eventlist as written seems to suffer from modal ambiguity. I suggest it
requires two different option tags to resolve this ambiguity.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 May 2009 18:26:01 -0500

[as an individual]

> requires two different option tags to resolve this ambiguity.

Almost every use of option tags specific to subscriptions is going to 
suffer from the same "ambiguity" to varying degrees. With 
INVITE-initiated dialogs, the behavior is symmetrical: both participants 
serve the same role in the dialog. With SUBSCRIBE/NOTIFY-initiated 
dialogs, the roles are inherently asymmetrical -- one party is a 
subscriber, while the other is a notifier.

So, if we plan to come up with some "Grand Unified Theory" of option tag 
semantics and publish it as an RFC or part of an RFC, we should probably 
include this as a base principle. I would suggest one of the 
participants in this discussion take the arguments so far and summarize 
them in an internet-draft, taking this into account.

On the other hand, if we're just grousing to pass the time, I'd prefer 
to do that on idle Friday afternoons over beer rather than on the list. ;-)

/a

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 May 2009 13:36:08 -0500

> to do that on idle Friday afternoons over beer rather than on the list. ;-)

Why would we want to interfere with something important like Friday
afternoon beer time by talking about option tags that everybody has
already gotten wrong?

--
Dean