Subject: [sipcore] help with UAC vs. UAS response in Allow field

From: Chris Wendt <[email-masked]>
Date: Thu, 9 Jul 2015 12:29:11 -0400

We are having a debate over interpretation of what a UAS should provide in the Allow header.

In [Section 20.5] All methods, including ACK and CANCEL, understood by the UA MUST be
> included in the list of methods in the Allow header field, when
> present.

Should the interpretation be that UA implies both UAS and UAC should respond in it’s Allow header with it’s own supported methods, or 
Should a UAS provide an Allow with only with the UAC supported methods in the context of a session?

Any opinions or pointers to more explicit text to clarify the interpretation would be appreciated.

Thanks!

-Chris

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Jul 2015 15:06:14 -0400

On 7/9/15 12:29 PM, Chris Wendt wrote:
> Should the interpretation be that UA implies both UAS and UAC should
> respond in it’s Allow header with it’s own supported methods, or

AFAIK each end should indicate independently - this is not a 
negotiation. Also, it need not be symmetric.

But also be aware that this mechanism, along with related ones such as 
Accept* are limited and imprecise, so don't count too much on what you 
can infer from them being the last word. Better to consider these as hints.

To elaborate, for Allow the definition isn't entirely clear whether this 
means methods that can be handled when received, methods that might be 
sent, or both. IMO it makes most sense for it to mean those that can be 
processed when received. For instance this makes quite a difference of 
REGISTER, SUBSCRIBE, and PUBLISH, that many UAs aren't prepared to 
receive but may well send.

Furthermore, you may only accept a method in certain contexts. Even 
though you announce that you allow SUBSCRIBE, you probably only allow 
subscriptions to certain event types and resources, and perhaps only 
from certain subscribers.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Fri, 10 Jul 2015 13:49:12 -0400

Hi,

In addition to Paul's response, there is an Allow ambiguity concerning
dialog/context versus all understood methods.

Sections 13.2.1, 13.2.2.1, and 13.3.1.4 indicate (non-normative) being
dialog/context specific.  However, section 20.5 normatively indicates "All
methods" which definitely conflicts with section 13.2.2.1.

Section 20.5:

"All methods, including ACK and CANCEL, understood by the UA MUST be
included in the list of methods in the Allow header field, when
present."

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
> Sent: Thursday, July 09, 2015 3:06 PM
> To: [email-masked]
> Subject: Re: [sipcore] help with UAC vs. UAS response in Allow field
>
> > respond in it's Allow header with it's own supported methods, or
negotiation.
> Also, it need not be symmetric.
>
can
> infer from them being the last word. Better to consider these as hints.
>
sent,
> or both. IMO it makes most sense for it to mean those that can be
processed
> when received. For instance this makes quite a difference of REGISTER,
> SUBSCRIBE, and PUBLISH, that many UAs aren't prepared to receive but may
well
> send.
though
> you announce that you allow SUBSCRIBE, you probably only allow
subscriptions
> to certain event types and resources, and perhaps only from certain
> subscribers.
>
> 	Thanks,
> 	Paul

---

From: Chris Wendt <[email-masked]>
Date: Wed, 15 Jul 2015 21:15:51 -0400

Hi Paul,

Thanks.  I would agree, purely from the perspective of 20.5 and in general practice that a UA (either UAS or UAC) should report their allowed methods independent of other UA in the chain.

Also agree that this shouldn’t be any sense of a contractual agreement what will happen depending on the context.  And probably isn’t a straight forward way to capture all of the cases to provide normative behavior.

-Chris

> On Jul 9, 2015, at 3:06 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> AFAIK each end should indicate independently - this is not a negotiation. Also, it need not be symmetric.
> 
> But also be aware that this mechanism, along with related ones such as Accept* are limited and imprecise, so don't count too much on what you can infer from them being the last word. Better to consider these as hints.
> 
> To elaborate, for Allow the definition isn't entirely clear whether this means methods that can be handled when received, methods that might be sent, or both. IMO it makes most sense for it to mean those that can be processed when received. For instance this makes quite a difference of REGISTER, SUBSCRIBE, and PUBLISH, that many UAs aren't prepared to receive but may well send.
> 
> Furthermore, you may only accept a method in certain contexts. Even though you announce that you allow SUBSCRIBE, you probably only allow subscriptions to certain event types and resources, and perhaps only from certain subscribers.
> 
> 	Thanks,
> 	Paul
> 
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore