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

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 12 Jan 2005 14:36:08 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Jan 2005 09:25:35 -0500

Gonzalo,

I think work on this general subject area is long overdue. The whole 
notion of content disposition is significantly underspecified in sip. I 
would like to see it go further, in several respects:

- define the meaning when no Accept-Disposition is present.
   Are there any disposition types that are required to be
   supported by default? (E.g. is support for 'render' a default?)

- Define how to report the following situation:
   A request as been received containing a body part with
   content type T and content disposition D. Type T is
   supported with some dispositions, but not with disp D,
   and disposition D is supported, but not with type T.
   (E.g. if a MESSAGE was received containing body with
   c-t:application/sdp and c-d:render.)

- We really need better specification of specific content
   dispositions. E.g. I don't know how to decide if I support
   'render', because I don't know what that means. And what
   do I do if I can support 'render' for MESSAGE, but not for
   SUBSCRIBE?

- There is a real need for further specification of how
   content dispostion is used with multipart bodies. The
   contained body parts may have independent dispositions.
   Is the content type of the container related to that of
   the contents, or independent of it? If independent, then
   what should it be. (Most examples just don't include a
   c-d in multiparts, which means they default to 'render'.
   What does it mean to 'render' a multipart that contains
   parts with dispostions other than 'render'?)

- There is need for specification of what c-d to use with
   the distinguished parts of special multipart containers.
   E.g. the signature part of a multipart/signed.

- What should the disposition be for body parts that contain
   content-id and are then referenced from elsewhere in the
   message using a cid: uri? If such body parts have a dispostion
   and type that implies processing independent of the reference,
   are they to be processed both ways?
   (Strained example: message has an Alert-Info header with a
   cid: uri referencing a body part with c-d of 'render'. Should
   it be used to alert *and* also be rendered as part of the
   session?)

It seems likely that resolving all of the above would require more than 
one draft. But I think we should recognize that there is a program of 
required work, and adjust the charter accordingly, with the needed 
deliverables being scheduled. I would be willing to work on this.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Jan 2005 13:24:27 -1000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jan 2005 19:23:46 -0500

> than one disposition would be useful for that MIME type?

application/sdp: session & early-session

application/sipfrag: render? (for refer notifies), ??? (for smime)

text/plain: render (for MESSAGE), alert, ...

image/*: render (for MESSAGE), icon

multipart/*: what disposition are these supposed to get???

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Jan 2005 17:32:28 -1000

> I'm not really sure what the problem is that this solves.

I like how the discussion is going on *how* to do this but I'm still missing
the *why* to do it. I'm failing to imagine when this problem comes up.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jan 2005 00:15:42 -0500

> the *why* to do it. I'm failing to imagine when this problem comes up.

Well, I think most of this ultimately is just debugging info. In 
principle a UA could change its behavior based on what it learns from 
these kinds of headers. But how much of that really happens.

While I think this kind of info is useful to fill in the logical holes 
in the protocol, I am more interested in carefully defining all the 
currently underdefined behaviors wrt disposition.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 20 Jan 2005 08:43:34 +0200

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

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 20 Jan 2005 14:39:15 +0100

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:

> application/sdp, my UA assumes that the remote UA supports the 
> 'session' disposition type... but what about 'early-session'?
>
> '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.
>
>
> 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
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Jan 2005 11:00:08 -1000

> disposition type... but what about 'early-session'?

Seems like Supported header is a better way to solve this particular issue

> uri-list bodies and may be more in the future.)

I guess I am wondering if using the MIME dispositions is really the right
way to basically tell the UA what you want it to do with a given SIP command
- what does recipient-list mean in the context of email or other users of
MIME?
 
> URI-list service but does not support the 'recipient-list' disposition

I agree with this observation

> 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