Subject: RE: [Sip] Draft defining the Accept-Disposition header field

From: "Shekar, Nagesh Soma (Shekar)** CTR **" <[email-masked]>
Date: Thu, 20 Jan 2005 10:58:00 -0500

This is very much required to accept a Content carried by a SIP
request or a Response. This is a real problem, in that sense that
the nodes trying to accept the Content needs to look at the Content
Type and Content Disposition associated with the Content.

Having incorrect or unsupported comibnations will result in call
failures, which obviously is not desirable.

By specifying the acceptable combinations of Content Type and Content 
Disposition in some form of Accept Header, we can suppose that the 
chance of a call succeeding would increase.

Nagesh Shekar.

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Thursday, January 20, 2005 8:39 AM
> To: Gonzalo Camarillo
> Cc: Cullen Jennings; [email-masked]; Paul Kyzivat
> Subject: Re: [Sip] Draft defining the Accept-Disposition header field
> 
> 
> This sounds like some presence event package related info or 
> some other 
> event package, not something that is carried in a SIP request or 
> response.
> 
> Regards,
> Hisham
> 
> On Jan 20, 2005, at 7:43 AM, Gonzalo Camarillo wrote:
> 
> > Hi,
> >
> >> I'm not really sure what the problem is that this solves.
> >
> > it lets a UA know whether the remote UA supports a particular 
> > disposition type. Right now, UAs guess this information 
> based on the 
> > support for MIME types. For example, if the remote UA supports 
> > application/sdp, my UA assumes that the remote UA supports the 
> > 'session' disposition type... but what about 'early-session'?
> >
> > The same thing with uri-list bodies. A conference server 
> may support 
> > uri-list bodies for some reason, but may not support the 
> > 'recipient-list' disposition type. The disposition type is 
> what tells 
> > me that the conference server supports (or does not support) the 
> > feature I want to use. (So far there are two disposition types 
> > associated with uri-list bodies and may be more in the future.)
> >
> > Regarding debugging, the UAC can know what went wrong when 
> it received 
> > a 415 response from a UAS that supports all the MIME types 
> needed for 
> > the service. In this sense, the draft completes the 
> procedures defined 
> > in RFC 3204 regarding rejection of body parts whose handling is 
> > required.
> >
> >
> > The thing is that, as it has been pointed out in this thread, 
> > disposition types are usually supported in relation with a 
> particular 
> > MIME type and even a particular method (e.g., a server is a message 
> > URI-list service but does not support the 'recipient-list' 
> disposition 
> > type for INVITEs).
> >
> > The solution proposed in the draft follows the definition of the 
> > existing Allow and Accept header fields in the sense that 
> they do not 
> > provide cross header information: Allow tells you which methods are 
> > supported and Accept which MIME types, but there is no info about 
> > which MIME type is acceptable for which method. We need to 
> decide if 
> > this is good enough or if we want to introduce some level of cross 
> > header information in the solution.
> >
> > Regards,
> >
> > Gonzalo
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> >
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip