Subject: [Sip] Location Conveyance and Content-Disposition header

From: "James M. Polk" <[email-masked]>
Date: Wed, 08 Nov 2006 15:21:39 -0600

I'm looking for feedback on the idea of adding text to the SIP Location 
Conveyance -06 ID discussing the use of a Content-Disposition header for a 
location received.

Should this header be in a SIP message that contains location intended for 
the user recipient (verses a proxy that will route on the location value, 
in which "render" doesn't apply)?

If not, the default value for the Content-Disposition header is "render" I 
believe.

Does this need to be explicitly stated in this next rev of the doc?

If "render" is not the (or an) appropriate action (meaning there may be 
multiple actions to take by default), which other Content-Disposition 
header-values should be mentioned in this doc?

I've had one request for "attachment" to be offered for use if location is 
included in a MESSAGE request, offering the UAS user the choice not to have 
the received location automatically displayed, but have them have to take 
an action to display hte location received.

Is this a valid use of the Content-Disposition header here (meaning, does 
it make sense to offer this scenario in the ID)?

And, are there any other Content-Disposition header-values that make sense 
to articulate in this doc?

Comments are requested

James

_______________________________________________
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: Scott Lawrence <[email-masked]>
Date: Fri, 10 Nov 2006 09:45:08 -0800

> to articulate in this doc?

Whether or not to display location or anything else from the headers is
completely up to the UA; it is a user interface decision.  

I don't think that there is any reason to include Content-Disposition at
all, or say anything about it in the document.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Nov 2006 14:45:25 -0500

Scott,

The existence of the Content-Disposition header implies that it has some 
significance. Unfortunately 3261 is quite light on explanation of what 
that significance it. The header was originally defined for mail, and 
its clearer what the significance is there. For now we are groping along 
trying to figure this out for sip.

Consider a MESSAGE that contains a geoloc body. Should the recipient 
render that? Absent any indication otherwise, I suppose it probably should.

Then consider a MESSAGE that contains a multipart mixed containing two 
text/plain bodies. Should it display both of them? If not, which one?

What about a MESSAGE with a multipart with a geoloc body and a 
text/plain body? Display one or both?

Now suppose the MESSAGE has a multipart with geoloc and text/plain, and 
a GeoLocation header with cid referencing the geoloc body? Does the 
answer depend on whether the UAS understands the GeoLocation header?

There need to be some rules about how this works so that we get 
consistent results. Content-Disposition helps with this. In the above, 
the answers could all be resolved by rendering only those body parts 
that have a content-disposition of "render".

	Paul

---

From: [email-masked]
Date: Sat, 11 Nov 2006 08:17:41 -0500

> in which "render" doesn't apply)?

I think you're losing focus here.  The question is not to prescibe how
the receiving UA will process the message -- as Scott says, that's a
UA design issue.  The question is to ensure that the *intention* of
the *sending* UA is mutually understood.

An explicit or implied "Content-Disposition: render" implies that the
sender wants the contained location is to be shown to the recipient.
In practice, the receiving UA might not actually show it in the most
default mode of operation, but that will be its decision based on its
uderstanding of the recipient and the display situation.

Etc.

What becomes interesting is if the sending UA intends for the location
not to be information to be delivered to the recipient, but to be some
sort of metadata that is attached to the information to be delivered.
But the text of section 20.11 of RFC 3261 makes it clear that
Content-Disposition may be applied to body parts as well as to whole
bodies.

   > an action to display hte location received.

"Content-Disposition: attachment" is already defined, isn't it?

   From: Paul Kyzivat <[email-masked]>

Given that the default is "Content-Disposition: render" (except for
application/sdp), yes.

Given that the default is "Content-Disposition: render", and the type
is "multipart/mixed" rather than "multipart/alternative", yes.

Given that the default is "Content-Disposition: render", and the type
is "multipart/mixed" rather than "multipart/alternative", yes.

Would it be surprising if the processing of the message depends on
whether the recipient understands the GeoLocation header?

Given that the default is "Content-Disposition: render", and the type
is "multipart/mixed" rather than "multipart/alternative", yes.

All of the above follow directly from the pre-existing meanings of
Content-Disposition and Content-Type.  Or am I totally missing the
point?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Nov 2006 11:35:12 -0500

Dale,

I think you and I are in agreement about what all of this means.

Regarding "attachment": yes, it is currently defined for email. I think 
it might be suitable for reuse in this context, but that is certainly 
still subject to debate.

An alternative might be to define a special content-disposition for body 
parts that have their significance determined in some other way than via 
their mere presence in the body. Notably, when a body part is referenced 
  via a CID uri, the significance is determined by the reference, and 
typically shouldn't also be interpreted otherwise. A recipient that 
doesn't understand the header containing the CID should ignore the body 
part.

	Paul