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

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Mar 2005 14:59:34 -0500

inline.

Cullen Jennings wrote:

> 
>>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.
> 
> 
> I think we should consider if we need this at all or if we are trying to do
> something with disposition that just should not be done in the MIME level
> but should be done in the SIP level

I agree with Cullen on this assessment. I don't understand the specific 
use case that is being addressed here. I understand the problem in 
theory, but in practice, I suspect that a particular extension (which 
would have assocaited types and dispositions) will be supported in its 
entirety or not at all. As a result, the Supported header field would 
suffice.

A new MIME header is needed only when it seems like there is some new 
disposition defined that is sensible to be used outside of support for a 
particular extension and its associated types. I don't know of such a case.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 07 Mar 2005 04:45:08 +0200

Hi,

I am thinking of URI-list services that support the "recipient-list" 
disposition type. Servers need a way to signal support for this 
disposition type and report errors when they do not understand it.

We have several options to do that. One is to do it at the SIP level, 
defining option tags that would imply support for this disposition type 
for different methods. Something like an invite-uri-list-service option 
tag, a message-uri-list-service option tag, etc...

Another alternative would be to use a similar mechanism as the one 
defined in the draft. I would like to explore this possibility... we may 
decide that it is not the way to go, but disposition types are currently 
under-defined in SIP, and it is good to spend some time thinking about 
their implications...

In any event, my main concern is to resolve the URI-list problem, one 
way or another.

Thanks,

Gonzalo

Jonathan Rosenberg wrote:
>>>supported and Accept which MIME types, but there is no info about
> 
> which
> 
>>I think we should consider if we need this at all or if we are trying
> 
> to do
> 
>>something with disposition that just should not be done in the MIME
> 
> level
> 

-- 
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: Sun, 06 Mar 2005 23:51:51 -0500

I think there are two related problems here:

1) A UAS receives a request. That request is of message type M and 
contains a body part with content-type T and content-disposition D. The 
UAS can't do the combination of [M,T,D] but it can handle [M,T,D'] and 
[M,T',D]. What kind of response should it return? (There are of course 
lots of permutations of this. There is currently no response that 
accurately reflects the situation.

I'm not sure how detailed it needs to be, but it would be good if the 
response made sense. Note that the problem already exists with 
content-type: a UA may report in options that it supports type 
application/sdp. But what if you send it a MESSAGE with a body of type 
application/sdp? Does it report back that it no longer supports that type?

2) A UAC wants to know in advance what a UAS is capable of in order to 
plan out the features it will enable, or the kinds of call flows it will 
attempt to implement a feature. (Perhaps it is a feature like list 
exploding, or specifying how to alert, that can be controlled via body 
parts with specific dispositions.) It may want to send an OPTIONS and 
get something back in the response that helps.

The larger problem is that content-disposition is underspecified in 
3261. Were we to specify it more completely there may be less of a 
problem to deal with here.

	Paul