Subject: [sipcore] Allow semantics

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 13:16:00 +0000

Hi,

Section 13.2.1 of RFC 3261 says:

"An Allow header field (Section 20.5) SHOULD be present in the INVITE.
                It indicates what methods can be invoked within a dialog, on the UA
                sending the INVITE, for the duration of the dialog."

Section 20.5 of RFC 3261 says:

"The Allow header field lists the set of methods supported by the UA
                generating the message.

                ...

                Example:

                                Allow: INVITE, ACK, OPTIONS, CANCEL, BYE"

Section 4.1.1 of RFC 6665 says:

"The presence of "SUBSCRIBE" in the "Allow" header field of any
                request or response indicates support for SIP events;"

It is unclear whether the Allow header field e.g. in an INVITE request indicates the methods supported within that dialog, or whether it indicates the methods supported by the UA in general.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Dec 2014 11:41:45 -0500

On 12/4/14 8:16 AM, Christer Holmberg wrote:
> “An Allow header field (Section 20.5) SHOULD be present in the INVITE.
>
>                  sending the INVITE, for the duration of the dialog.”
>
> “The Allow header field lists the set of methods supported by the UA
>
>                  generating the message.
>
>                  …
>
>                  Example:
>
>                                  Allow: INVITE, ACK, OPTIONS, CANCEL, BYE”
>
> “The presence of "SUBSCRIBE" in the "Allow" header field of any
>
>                  request or response indicates support for SIP events;”
>
> It is unclear whether the Allow header field e.g. in an INVITE request
> indicates the methods supported within that dialog, or whether it
> indicates the methods supported by the UA in general.

This ambiguity exists for a number of similar header fields:
- Accept
- Accept-Encoding
- Accept-Language
- Allow
- Require
- Supported
- Unsupported

For instance, what does Allow mean in out-of-dialog OPTIONS?

In general there can be nuances in support for these things that can't 
be expressed in these header fields. (For instance, supported only 
in-dialog, supported only in particular dialog usages, supported for 
some users but not others, etc.)

Do you think we could find sufficient interest for a task to firm this up?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 16:54:31 +0000

Hi,

>>                  It indicates what methods can be invoked within a 
>>                  dialog, on the UA sending the INVITE, for the duration of the dialog."
>>
> In general there can be nuances in support for these things that can't be expressed in these header 
> fields. (For instance, supported only in-dialog, supported only in particular dialog usages, supported for some users but not others, etc.)

I agree. When it comes to option-tags, I think each option-tag definition needs to define the scope - AND whether the presence in a Require header field means "MUST support" or "MUST support AND enable".

For feature-caps, we did define the scope in the RFC (e.g. a feature-cap carried in an INVITE request only indicate support for a feature within the scope of the dialog).

> Do you think we could find sufficient interest for a task to firm this up?

I would for sure be interested. And, I think we have to do it. I get these kind of questions on a rather frequent basis, and I assume people in other companies do too - and there is no guarantee we give the same answer :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Dec 2014 11:59:43 -0500

> I would for sure be interested. And, I think we have to do it. I get these kind of questions on a rather frequent basis, and I assume people in other companies do too - and there is no guarantee we…

Others who are interested in working on this: please speak up.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 04 Dec 2014 21:26:40 -0500

> This ambiguity exists for a number of similar header fields:

(The Unsupported header is only used in the 420 response to indicate the
Require option-tag that was objected to.)

> Do you think we could find sufficient interest for a task to firm this up?

There was a long discussion of this issue some time ago.  The result of
the discussion was that this sort of specification is inherently
inexact, because "whether XYZ is supported" can vary from request to
request within a dialog -- there is no way to know in advance that each
request will be processed through the same set of proxies, and that the
relevant context for processing each request at the UAS will be the
same.

A UA sending a request must be prepared for any particular aspect of its
request to be not-supported.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Dec 2014 05:09:22 +0000

Hi Dale,

When a UA inserts information in a request, it should be clear what the scope of the information is.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Dale R. Worley<mailto:[email-masked]>
Sent: ‎05/‎12/‎2014 04:26
To: Paul Kyzivat<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Allow semantics

Dale

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

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 15 Dec 2014 18:31:59 -0500

> the scope of the information is.

My memory of the discussion was that it's conclusion is "It isn't clear
what the scope of the information is, and it's probably impossible to
make it so."

Dale