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

From: "Shekar, Nagesh Soma (Shekar)** CTR **" <[email-masked]>
Date: Wed, 19 Jan 2005 11:28:32 -0500

A formal specification of the Acceptable Disposition types is
useful. I do not necessarily agree that the proposed way is the 
best way to do it.

The Accept-Disposition needs to be associated with the corresponding 
Acceped Content Types. A Accept-Disposition header by itself will not 
be effective unless there is an associated Content Type specififed. 

I think that an effective way to specify the  Disposition is to 
Change the Accept Header to also specify a required implicit/explicit
Disposition Type.

Example: 

Accept:application/sdp;session

Thanks,
Shekar

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2005 6:24 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Sip] Draft defining the Accept-Disposition header field
> 
> 
> 
> 
> I'm not really sure what the problem is that this solves.
> 
> Ignoring that, it seems that the dispositions need to be mime 
> specific. For
> example, I may be able to have a session with SDP but I doubt 
> that just
> because a UA support render means I can render SDP.
> 
> Do we have any MIME types where the UA could support that 
> MIME type and more
> than one disposition would be useful for that MIME type?
> 
> 
> Cullen
> 
> 
> On 1/12/05 4:36 AM, "Gonzalo Camarillo" 
> <[email-masked]>
> wrote:
> 
> > Folks,
> > 
> > I have submitted a draft that defines the Accept-Disposition header
> > field. The usage of this header field would be similar to 
> the usage of
> > Accept, Accept-Encoding, or Accept-Language, but it would indicate
> > support for disposition types.
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept
-disposition-00.
> txt
> 
> Your comments are welcome.
> 
> Thanks,
> 
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jan 2005 15:14:02 -0500

> Accept:application/sdp;session

Seems somewhat appealing. Because parameters are already accepted, I 
don't think the above way of using parameters is ideal - its confusing 
about the role of the parameter, and runs risk of conflicting with other 
parameter usages, and would need to be updated every time a new 
disposition was invented. Instead, perhaps:

	Accept:application/sdp;disposition="session,early-session"
         Accept:multipart/mixed;disposition="*"

It might also be necessary to allow:

	Accept:text/*;disposition="render",
	       text/plain;disposition="alert"

For backward compatibility, probably need to say that default for 
disposition parameter is "*".

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Jan 2005 23:16:33 +0200

Hi,

yes, there is a trade-off here. On the one hand, we can just list the 
disposition types supported by the client, as defined in the draft. This 
has the advantage of efficiency (each disposition type is listed only 
once). On the other hand, we can associate each disposition type with 
the content type it applies to. This is not so efficient (disposition 
types that apply to more than one content type will be listed more than 
one), but it provides more accurate information.

If folks feel that having better accuracy is important, we should 
definitively go for the second option.

Regards,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jan 2005 16:56:14 -0500

> definitively go for the second option.

For some purposes the less accurate approach might be sufficient to give 
a hint of what is possible and what isn't.

But I am concerned about one of the key uses of these headers - 
reporting what is accepted as part of a response saying that something 
isn't accepted. It is not good form to reject a message and yet say that 
you support the content type and disposition it contained.

Getting both accuracy and efficiency seems difficult. I think the key 
may be in defining the scope over which these declarations apply, and 
what is meant when something has not been specified. Then perhaps it 
would only be necessary to be precise in the error response to an 
unsupported usage.

BTW, now that I think about it more, the notation problem is more 
complex - really need to specify the supported triples of 
type,disposition,message. And even that leaves out responses. Its harder 
to cram all of that into a parameter syntax.

Part of this could be dealt with by a new error code that means the 
particular combination of types and dispositions in the request was not 
supported. However that only works for requests. It doesn't give a way 
to indicate what combinations can/can't be used in *responses*.

	Paul

>>> useful. I do not necessarily agree that the proposed way is the best 
>>> way to do it.
>>>
>>>> example, I may be able to have a session with SDP but I doubt that just
>>>> Do we have any MIME types where the UA could support that MIME type 
>>>> and more