Subject: [sipcore] Accept in 18x

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Oct 2011 12:22:51 +0200

Hi,

At the ongoing 3GPP meeting, the question has came up why RFC 3261 does not allow the Accept header field in 18x provisional responses (for INVITEs, 3261 only allows it for 2xx and 415).

Is there a technical reason for not allowing it in 18x, or is it just because nobody seemed a need for it at the time?

Regards,

Christer

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 11 Oct 2011 10:41:41 -0400

> From: Christer Holmberg [[email-masked]]
> 
> At the ongoing 3GPP meeting, the question has came up why RFC 3261
> does not allow the Accept header field in 18x provisional responses
> (for INVITEs, 3261 only allows it for 2xx and 415).
> 
> Is there a technical reason for not allowing it in 18x, or is it just
> because nobody seemed a need for it at the time?

My guess is that Accept in 1xx was not seen as useful because (1) 1xx
isn't reliable, and (2) the UAC won't send any further requests
until 2xx is sent by the UAS (and the 2xx can carry Accept).

Dale

---

From: Bob Penfield <[email-masked]>
Date: Tue, 11 Oct 2011 15:55:12 +0000

A UAC is allowed to send a BYE on an early dialog created by an unreliable 1xx. I think it might just be an oversight.

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Worley, Dale R (Dale)
Sent: Tuesday, October 11, 2011 10:42 AM
To: Christer Holmberg; SIPCORE
Subject: Re: [sipcore] Accept in 18x

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 11 Oct 2011 10:57:54 -0500

> A UAC is allowed to send a BYE on an early dialog created by an unreliable 1xx. I think it might just be an oversight.

Also UPDATE requests are allowed, IIRC.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Oct 2011 18:59:33 +0200

Hi,

Note that the Accept header field is used to indciate the supported message body MIME types, not the supported SIP methods.

So, if there are no technical reasons, and 3GPP would like to specify the usage of Accept in a provisional response, would an errata to 3261 be needed (in order to be alligned with 3261)?

However, 

Regards,

Christer 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kevin P. Fleming
> Sent: 11. lokakuuta 2011 18:58
> To: [email-masked]
> > A UAC is allowed to send a BYE on an early dialog created 
> by an unreliable 1xx. I think it might just be an oversight.
> 
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us 
> out at www.digium.com & www.asterisk.org

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 11 Oct 2011 16:14:04 -0400

> So, if there are no technical reasons, and 3GPP would like to specify
> the usage of Accept in a provisional response, would an errata to 3261
> be needed (in order to be alligned with 3261)?

It looks like Accept was not specified for 1xx because there was no
practical use for it at the time 3261 was written.

As far as I can tell, the only place where 3261 says that Accept isn't
allowed in 1xx responses is in the giant table of "which headers are
allowed in which messages".  But I believe we've agreed to discontinue
the normative status of that table, which would mean that wouldn't
need to amend 3261 to maintain formal compliance.

In practice, no UA should malfunction due to the unexpected presence
of Accept in a 1xx response.

So it seems to me that 3GPP can go ahead with using Accept in 1xx
without worrying about updating 3261.

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 12 Oct 2011 06:40:49 +0200

Its fine saying that, but that means you have to work out what the semantics are when it is included in a 18x.

A 18x only creates an early dialog. So does sending Accept in a 18x only apply for an early dialog, or does it apply for the remainder of the full dialog. 

Also note there are other headers specified the same way. If this understanding applies to Accept, does it also apply to other headers.

Keith

> Sent: 11 October 2011 21:14
> To: Christer Holmberg; Kevin P. Fleming; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2011 16:24:25 -0400

I'm inclined to agree that this was an error in 3261, and that Accept-* 
should be ok in all 1xx responses.

The argument that the result won't be useful until after a 2xx is 
generally negated when reliable provisionals are used.

> A 18x only creates an early dialog. So does sending Accept in a 18x only apply for an early dialog, or does it apply for the remainder of the full dialog.

Well, pretty much everything that is established in an early dialog 
still holds if the dialog becomes a final one.

OTOH, the exact scope of applicability of Accept-* is pretty much 
undefined. It can change arbitrarily at almost any time.

IMO it would be good to file an errata on this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 16 Oct 2011 15:35:33 +0200

Hi,

Do we have text explicitly saying that a Contact received in a provisional response is valid after 200 OK (unless you receive a Contact in the 200 OK, of course)?

Regards,

Christer 

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 13. lokakuuta 2011 23:24
> To: [email-masked]
> I'm inclined to agree that this was an error in 3261, and 
> that Accept-* should be ok in all 1xx responses.
> 
> The argument that the result won't be useful until after a 
> 2xx is generally negated when reliable provisionals are used.
> 
> > Its fine saying that, but that means you have to work out 
> what the semantics are when it is included in a 18x.
> >
> > A 18x only creates an early dialog. So does sending Accept 
> in a 18x only apply for an early dialog, or does it apply for 
> the remainder of the full dialog.
> 
> Well, pretty much everything that is established in an early 
> dialog still holds if the dialog becomes a final one.
> 
> OTOH, the exact scope of applicability of Accept-* is pretty 
> much undefined. It can change arbitrarily at almost any time.
> 
> > Also note there are other headers specified the same way. 
> If this understanding applies to Accept, does it also apply 
> to other headers.
> >
> >
> >
> > Keith
> >
> [mailto:[email-masked]] On 
> >> Behalf Of Worley, Dale R (Dale)
> >>> So, if there are no technical reasons, and 3GPP would like to 
> >>> specify the usage of Accept in a provisional response, would an 
> >>> errata to 3261 be needed (in order to be alligned with 3261)?
> >>
> >> As far as I can tell, the only place where 3261 says that Accept 
> >> isn't allowed in 1xx responses is in the giant table of "which 
> >> headers are allowed in which messages".  But I believe 
> we've agreed 
> >> to discontinue the normative status of that table, which 
> would mean 
> >> that wouldn't need to amend 3261 to maintain formal compliance.
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 16 Oct 2011 11:52:05 -0400

> Do we have text explicitly saying that a Contact received in a provisional response is valid after 200 OK (unless you receive a Contact in the 200 OK, of course)?

This is a change in subject from the original question.

What are you looking for? Valid for *what*?

Obviously its impossible to send a PRACK or an UPDATE on an early dialog 
without having received a contact. In fact, I think we have agreed that 
you don't have an early dialog unless you got a contact in a provisional.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Oct 2011 09:04:37 +0200

Hi, 

>> Do we have text explicitly saying that a Contact received 
>> in a provisional response is valid after 200 OK (unless you 
>> receive a Contact in the 200 OK, of course)?
> 
> Obviously its impossible to send a PRACK or an UPDATE on an 
> early dialog without having received a contact. In fact, I 
> think we have agreed that you don't have an early dialog 
> unless you got a contact in a provisional.

That's not what I meant.

The question was: if I receive a Contact in a 18x, is the Contact VALUE also valid after I have received the 200 OK?

Obviously, if it's not, I can't send any in-dialog requests (including the ACK) after I've received the 200 OK. 

Regards,

Christer

> >> I'm inclined to agree that this was an error in 3261, and that 
> >> Accept-* should be ok in all 1xx responses.
> >>
> >> in a 18x only apply for an early dialog, or does it apply for the 
> >> remainder of the full dialog.
> >>
> >> If this understanding applies to Accept, does it also 
> apply to other 
> >> headers.
> >>>
> >>>
> >>>
> >>> Keith
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Oct 2011 10:04:41 -0400

> Obviously, if it's not, I can't send any in-dialog requests (including the ACK) after I've received the 200 OK.

Well, there should also be a Contact in the 2xx, and typically it would 
have the same value as the one in the 1xx for the same dialog. Your 
question is only interesting if the two values are different.

IIRC, 3261 specifies that the remote contact address is part of the 
dialog state. And the remote contact is allowed to change. So each time 
you get a new value it should supersede the prior value in the dialog 
state, and then be used for subsequent in-dialog requests.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 20:32:29 +0200

Hi,

>question is only interesting if the two values are different.

They could even be different in two different 1xx responses.

>state, and then be used for subsequent in-dialog requests.

Could we simply say the same thing for Accept - that it is part of the dialog state?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Oct 2011 15:01:39 -0400

Comment at end

> Could we simply say the same thing for Accept - that it is part of the dialog state?

There is no such requirement now, so that would be a change that isn't 
backward compatible.

Accept, and its definition, was inherited from HTTP. In HTTP I believe 
the scope of validity of ACCEPT is limited to the response to the message.

In the past I have commented that we have a number of properties such as 
this whose scope is not well defined. In general I think you must treat 
these as *hints*, while being prepared to discover that they 
subsequently cease to be valid.

Like many things, its hard for a 3pcc controller to assure the 
preservation of such state on one of its dialogs, because there may be a 
transfer on the "other side" to a device with different properties.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 20 Oct 2011 01:52:18 +0200

I am fast coming to the conclusion that rather than an errata, this issue would be best dealt with by a quick internet draft. I see it not as intended original functionality that somehow failed to get documented, but more as an extension.

An i-d would help us sort out what the procedures are really meant to be.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: 19 October 2011 20:02
> To: Christer Holmberg
> Cc: [email-masked]
> >>> The question was: if I receive a Contact in a 18x, is the Contact
> VALUE also valid after I have received the 200 OK?
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 10:44:03 -0400

> An i-d would help us sort out what the procedures are really meant to be.

Keith,

Are you talking about "Accept in 18x"? Or are you talking about Accept 
as dialog state?

We could handle Accept in 18x either as an errata or as a draft issued 
as a clarification/extension. I expect there is more controversy over 
how to document it than there is about the legitimacy of doing so. IMO 
its unlikely that this would cause any backward compatibility issues.

Accept as dialog state is more controversial. It could cause backward 
compatibility problems if some UAs started considering a previously 
received Accept as a *contract* that had to be honored until changed.

Can someone explain to me what is driving this inquiry? Is there some 
specific usage that needs this?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2011 21:50:15 +0200

Hi, 

>>> I am fast coming to the conclusion that rather than an errata, this issue would 
>>> be best dealt with by a quick internet draft. I see it not as intended original 
>>> functionality that somehow failed to get documented, but more as an extension.
>>
> Are you talking about "Accept in 18x"? Or are you talking about Accept as dialog state?
>
> We could handle Accept in 18x either as an errata or as a draft issued as a clarification/extension. 
> I expect there is more controversy over how to document it than there is about the legitimacy of 
> doing so. IMO its unlikely that this would cause any backward compatibility issues.
>
> Accept as dialog state is more controversial. It could cause backward compatibility problems if some 
> UAs started considering a previously received Accept as a *contract* that had to be honored until changed.
>
> Can someone explain to me what is driving this inquiry? Is there some specific usage that needs this?

I believe the issue was raised for a use-case where an Info Package (with an associated MIME) is used during the early dialog.

Now, with Info Packages you will of course receive the Recv-Info header field, which indirectly indicates that the receiver supports any MIME associated with the Info Package. However, the INFO RFC does say that one must also explicitly indicate the supported MIMEs in Accept.

But, in theory this applies to any MIME that one wants to use during the early dialog.

...including SDP, I guess. Because, eventhough no-Accept means support of SDP, one could say that you can't claim no-Accept for an 18x since Accept is not even defined for 18x :)

But, the SDP case is not a real-life problem, as far as I know.

Regards,

Christer

>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Paul Kyzivat
>>>>>>> Do we have text explicitly saying that a Contact received in a 
>>>>>>> provisional response is valid after 200 OK (unless you receive a 
>>>>>>> Contact in the 200 OK, of course)?
>>>>>>
>>>>>> Obviously its impossible to send a PRACK or an UPDATE on an early 
>>>>>> dialog without having received a contact. In fact, I think we 
>>>>>> have agreed that you don't have an early dialog unless you got a 
>>>>>> contact in a provisional.
>>>>>
>>>>> That's not what I meant.
>>>>>
>>>>> Obviously, if it's not, I can't send any in-dialog requests 
>>>>> (including
>> the ACK) after I've received the 200 OK.
>>>>
>>>> Well, there should also be a Contact in the 2xx, and typically it 
>>>> would have the same value as the one in the 1xx for the same 
>>>> dialog. Your question is only interesting if the two values are different.
>>>
>>>> dialog state. And the remote contact is allowed to change. So each 
>>>> time you get a new value it should supersede the prior value in the 
>>>> dialog state, and then be used for subsequent in-dialog requests.
>>>
>>> Could we simply say the same thing for Accept - that it is part of 
>>> the
>> dialog state?
>>
>> There is no such requirement now, so that would be a change that 
>> isn't backward compatible.
>>
>> Accept, and its definition, was inherited from HTTP. In HTTP I 
>> believe the scope of validity of ACCEPT is limited to the response to the message.
>>
>> In the past I have commented that we have a number of properties such 
>> as this whose scope is not well defined. In general I think you must 
>> treat these as *hints*, while being prepared to discover that they 
>> preservation of such state on one of its dialogs, because there may 
>> be a transfer on the "other side" to a device with different properties.
>>
>> 	Thanks,
>> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 16:32:53 -0400

> Now, with Info Packages you will of course receive the Recv-Info header field, which indirectly indicates that the receiver supports any MIME associated with the Info Package. However, the INFO RFC…

It is allowed to send a mime-type for which no Accept has been received. 
And of course it is also allowed to reject one you receive but don't accept.

The critical usage is just in a transaction, to indicate in a request 
what you can take in a response, since you can't reject a response. All 
the other usages are just optimizations.

> But, the SDP case is not a real-life problem, as far as I know.

Same comments above apply. I guess this would become a real issue if the 
UAS for the INVITE wanted to say Accept:application/SDPng to encourage 
the UAC to send offers using SDPng rather than SDP.
But we don't have to worry about that.

	Thanks,
	Paul