Re: [sipcore] Content-Disposition questions

Paul, Christer,

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

> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Dienstag, 10. März 2015 17:04
> To: Christer Holmberg; sipcore@ietf.org
> 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").
No, my point was about the different handling.

> 
> 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.
Correct, 
If the UAS doesn't know about the different default handling from RFC3204, 
it rejects the request.

> 
> > I am not sure I agree with Thomas that a SIP client must support the
> > 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
> > 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. 
Agree

> 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.
Completely agree.

Regards
Thomas

> 
> 	Thanks,
> 	Paul
> 
> > Regards,
> >
> > Christer
> >
> > Sent from my Windows Phone
> > ------------------------------------------------------------------------
> > From: Paul Kyzivat <mailto:pkyzivat@alum.mit.edu>
> > Sent: ‎10/‎03/‎2015 16:58
> > To: sipcore@ietf.org <mailto:sipcore@ietf.org>
> > 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
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore