Re: [sipcore] Content-Disposition questions

[Christer Holmberg <[e-mail]>]

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:[e-mail]] 
Sent: 10. maaliskuuta 2015 18:04
To: Christer Holmberg; [e-mail]
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.

> 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

> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ----------------------------------------------------------------------
> --
> From: Paul Kyzivat <mailto:[e-mail]>
> Sent: ‎10/‎03/‎2015 16:58
> To: [e-mail] <mailto:[e-mail]>
> Subject: Re: [sipcore] Content-Disposition questions
>
> On 3/10/15 5:45 AM, Stach, Thomas wrote:
>
>>> 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?
>
> 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
>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore