Subject: [sipcore] Content-Disposition questions

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Mar 2015 12:26:21 +0000

Hi,

Section 20.11 of RFC 3261 says:

        "For backward-compatibility, if the Content-Disposition header field

        is missing, the server SHOULD assume bodies of Content-Type

        application/sdp are the disposition "session", while other content

        types are "render"."

Section 20.11 also says:

        "The handling parameter, handling-param, describes how the UAS should

        react if it receives a message body whose content type or disposition

        type it does not understand. The parameter has defined values of

        "optional" and "required". If the handling parameter is missing, the

        value "required" SHOULD be assumed. The handling parameter is

        described in RFC 3204 [19].

QUESTION_1: If the C-D header field is missing, and the default disposition type value ("render") is assumed, shall then the default handling value ("required") also be assumed?

RFC 3204, which RFC 3261 refers to, says that the default disposition type value for ISUP and QSIG bodies are "signal".

QUESTION_2: If, for a specific message body, the "render" default type can be overwritten, shouldn't that be mentioned in 3261?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Mar 2015 09:54:27 -0400

On 3/9/15 8:26 AM, Christer Holmberg wrote:
>          “For backward-compatibility, if the Content-Disposition header field
>
>          types are "render".”
>          “The handling parameter, handling-param, describes how the UAS should
>
> *QUESTION_1*: If the C-D header field is missing, and the default disposition type value (“render”) is assumed, shall then the default handling value (“required”) also be assumed?

My personal opinion is that yes "required" is what it *should* be.
It is less clear whether an implementation that treats it as "optional" 
can be accused of being non-compliant.

> RFC 3204, which RFC 3261 refers to, says that the default disposition type value for ISUP and QSIG bodies are “signal”.
>
> *QUESTION_2*: If, for a specific message body, the “render” default type can be overwritten, shouldn’t that be mentioned in 3261?

Yes. It is quite evident that 3261 didn't give enough thought to 
Content-Disposition.

You didn't mention RFC5621. It has a section on C-D and it updates 3261.
But it doesn't totally address the issues you mention here.

IMO it would be reasonable to file an erratum on this. I don't know that 
it needs another 3261 update at this time.

	Thanks,
	Paul

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

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 9 Mar 2015 15:53:57 +0000

Christer,

I don't know if that helps with your question, but if you tunnel QSIG over SIP it would most likely done using ECMA-355 
or the ISO's equivalent IS 22535

Here, the handling parameter would be set to "required".

- http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-355.pdf 
- http://standards.iso.org/ittf/PubliclyAvailableStandards/c052060_ISO_IEC_22535_2009(E).zip  

Regards
Thomas

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Montag, 9. März 2015 13:26
To: [email-masked]
Subject: [sipcore] Content-Disposition questions

Hi,

Section 20.11 also says:

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Mar 2015 08:19:58 +0000

Hi Thomas,

My issue is not so much related to specific usages of the handling parameter - but what the default value is when not present in the message.

Regards,

Christer

-----Original Message-----
From: Stach, Thomas [mailto:[email-masked]] 
Sent: 09 March 2015 17:54
To: Christer Holmberg; [email-masked]
Subject: RE: Content-Disposition questions

Christer,

I don't know if that helps with your question, but if you tunnel QSIG over SIP it would most likely done using ECMA-355 or the ISO's equivalent IS 22535

Regards
Thomas

Hi,

Section 20.11 also says:

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Mar 2015 08:28:15 +0000

Hi,

>>          "For backward-compatibility, if the Content-Disposition 
>>          header field is missing, the server SHOULD assume bodies of Content-Type
>>          "The handling parameter, handling-param, describes how the 
>>         UAS should react if it receives a message body whose content type or 
>>         disposition type it does not understand. The parameter has defined values 
>>         of "optional" and "required". If the handling parameter is missing, the
>> *QUESTION_1*: If the C-D header field is missing, and the default disposition 
>> type value ("render") is assumed, shall then the default handling value ("required") also be assumed?
>
> It is less clear whether an implementation that treats it as "optional" can be accused of being non-compliant.

I don't think there should be a "should" - either there is a default value, or there isn't.

Then, if you want to allow different processing when "require" is used, that is a separate issue. But, that does not depend on whether "require" is indicated implicitly or explicitly.

For example, if you receive a body with C-D type "render" and "handling=required", are you still allowed to process the request even if you aren't able to handle the body?

>> *QUESTION_2*: If, for a specific message body, the "render" default type can be 
>> overwritten, shouldn't that be >> mentioned in 3261?
>
> Yes. It is quite evident that 3261 didn't give enough thought to Content-Disposition.
>

I did have a look, but unless I missed something the focus seems to be mostly related to multipart bodies.

> IMO it would be reasonable to file an erratum on this. I don't know that it needs another 3261 update at this time.

My suggestion for such erratum would be:

1. Define that, if no C-D header field is present, "require" is the default handling value.
2. Define that, for specific message bodies, the default type value can be overwritten. BUT, in such cases, do we need to mandate "require" handling? Otherwise an entity that does not understand ISUP could treat it as "render", which is not the 
expected behaviour.

Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 10 Mar 2015 09:45:50 +0000

Christer,

> 
> Hi Thomas,
> 
> My issue is not so much related to specific usages of the handling parameter -
Understood. 
More inline

> but what the default value is when not present in the message.
> 
> Regards,
> 
> Christer
> 
> I don't know if that helps with your question, but if you tunnel QSIG over SIP
> it would most likely done using ECMA-355 or the ISO's equivalent IS 22535
> 
> -
> http://standards.iso.org/ittf/PubliclyAvailableStandards/c052060_ISO_IEC_22535
> _2009(E).zip
> 
> 
> Regards
> Thomas
> 
> QUESTION_1: If the C-D header field is missing, and the default disposition

Yes, for unknown message bodies with the following exception.
Since RFC3204 is a normative reference, "qsig" and "isup" are not "unknown" and 
treated as specified there, 
i.e. Content-Disposition: signal; handling=optional

> 
> 
> 
> RFC 3204, which RFC 3261 refers to, says that the default disposition type
> value for ISUP and QSIG bodies are "signal".
> 
> QUESTION_2: If, for a specific message body, the "render" default type can be
> overwritten, shouldn't that be mentioned in 3261?

I think this is already written down. The last sentence in section 20.11 reads
"   If this header field is missing, the MIME type determines the default
   content disposition.  If there is none, "render" is assumed."

So, if the MIME type is understood, the default disposition from the 
corresponding MIME definition applies. Of course, this default disposition 
can be overwritten by sending a corresponding C-D header field, as e.g. ECMA-355 does for "qsig".
"render" kicks in, only if the MIME type is not understood and if C-D is omitted.
Does this make sense?

Regards
Thomas

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Mar 2015 10:51:05 -0400

> "render" kicks in, only if the MIME type is not understood and if C-D is omitted.

That has a problem. It makes no sense to define a default handling 
parameter value for a specific mime type that applies when the C-D isn't 
present. Suppose you define a mime type where the default handling is 
"optional".

Then a receiver that does understand the mime type will treat the 
handling as optional, but that is irrelevant because this only applies 
if the mime type is not understood.

A receiver that does not understand the mime type will use the global 
default handling value "required".

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Mar 2015 15:27:13 +0000

Hi Paul,

It is not the default handling value that is different for the qsig/isup bodies - it is the default type value ("signal", rather than "render").

I am not sure I agree with Thomas that a SIP client must support the qsig/isup bodies. Yes, 3261 does reference the CR, but mostly for information regarding the C-D header field itself.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎10/‎03/‎2015 16:58
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Content-Disposition questions

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Mar 2015 12:04:04 -0400

On 3/10/15 11:27 AM, Christer Holmberg wrote:
> Hi Paul,
>
> It is not the default handling value that is different for the qsig/isup
> bodies - it is the default type value ("signal", rather than "render").

I know they define the default disposition type for those mime types.
But I thought Thomas was also saying that they change the default 
handling to "optional", and I was commenting on the relevance of that 
part. If you include a qsig mime body, and don't include a C-D with 
handling="optional" then a recipient that doesn't know the mime type 
should treat it as "required" and reject the request, regardless of what 
defaults are defined for that mime type.

> I am not sure I agree with Thomas that a SIP client must support the
> qsig/isup bodies. Yes, 3261 does reference the CR, but mostly for
> information regarding the C-D header field itself.

I agree with you. Classifying a reference as normative doesn't mean that 
every aspect of that draft is required. And the only body reference in 
3261 is wrt the definition of the handling parameter. And 3204 goes out 
of its way to say:

    The Content-Disposition header [5] may be included to describe how
    the encapsulated ISUP is to be processed, and in particular what the
    handling should be if the received Content-Type is not recognized.

That would make no sense if all SIP UA were required to recognize ISUP.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 10 Mar 2015 16:48:07 +0000

Paul, Christer,

all of this is just a corner case, including C-D with handling=optional 
would avoid any confusion, but ...

> From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Dienstag, 10. März 2015 17:04
No, my point was about the different handling.

> defaults are defined for that mime type.
Correct, 
If the UAS doesn't know about the different default handling from RFC3204, 
it rejects the request.

> > qsig/isup bodies. 
That's not what I meant. Support for qsig/isup is not needed.
However, if the UAS implemented an exception for the _handling_ 
of these 2 bodies (i.e. optional), it would just have to 
recognize application/qsig, could ignore the bodies and 
would not have to reject an INVITE with a 415.
As said above, it is just a corner case.

> Yes, 3261 does reference the CR, but mostly for
> every aspect of that draft is required. 
Agree

> And the only body reference in
Completely agree.

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Mar 2015 11:18:20 +0000

Hi,

Related to this, I see that Content-Disposition is not mentioned in RFC 6442 (Location Conveyance for the Session Initiation Protocol). 

(This was also mentioned in ECRIT at one point: http://www.ietf.org/mail-archive/web/ecrit/current/msg08517.html).

So, that basically means that the default disposition type for the XML body is "render", which I don't think fits very well.

In addition, assuming the default handling value is "required", it also means that endpoints must support the XML body. But, perhaps that's ok.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 10. maaliskuuta 2015 18:04
To: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] Content-Disposition questions

On 3/10/15 11:27 AM, Christer Holmberg wrote:
> Hi Paul,
>
> It is not the default handling value that is different for the 
> qsig/isup bodies - it is the default type value ("signal", rather than "render").

I know they define the default disposition type for those mime types.
But I thought Thomas was also saying that they change the default handling to "optional", and I was commenting on the relevance of that part. If you include a qsig mime body, and don't include a C-D with handling="optional" then a recipient that doesn't know the mime type should treat it as "required" and reject the request, regardless of what defaults are defined for that mime type.

> information regarding the C-D header field itself.

I agree with you. Classifying a reference as normative doesn't mean that every aspect of that draft is required. And the only body reference in
3261 is wrt the definition of the handling parameter. And 3204 goes out of its way to say:

	Thanks,
	Paul

>>> QUESTION_2: If, for a specific message body, the "render" default 
>>> type can be overwritten, shouldn't that be mentioned in 3261?
>>
>> corresponding MIME definition applies. Of course, this default 
>> disposition can be overwritten by sending a corresponding C-D header field, as e.g. ECMA-355 does for "qsig".
> parameter value for a specific mime type that applies when the C-D 
> isn't present. Suppose you define a mime type where the default 
> handling is "optional".
>