Subject: [Sip] RE: [Sip-implementors] Re: draft-olson-sip-content-indirect-mech-01.txt

From: [email-masked]
Date: Tue, 20 Aug 2002 10:18:15 +0300

Redirected to sip.

I don't think this sentence needs to be there at all. UAs should be able to perform content indirection on any MIME type.

Regards,
Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, August 19, 2002 10:42 PM
> To: [email-masked]
> Subject: [Sip-implementors] Re:
> draft-olson-sip-content-indirect-mech-01.txt
> 
> 
> Sean - one comment about your draft:
> 
> "3.4 ... User-Agents supporting content indirection MUST 
> support content indirection of the application/sdp MIME type."
> 
> IMHO this is a bad special case. It is very easy to imagine 
> wanting to support indirection for something like PIDF, while 
> not wanting to support it for SDP. While in general this 
> could be handled by altering the Accept header on a 
> message-by-message basis, it could be a problem for 
> formulating a response to OPTIONS. It isn't much of a burden 
> to require application/sdp to be explicitly specified if intended.
> 
> 	Paul
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

_______________________________________________
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, 21 Aug 2002 11:10:27 -0400

Hisham,

Are you saying that if a user agent wishes to support content indirection for one purpose (say for presence notifications) that it must be prepared to support content indirection for all other kinds of content as well?

That seems like a very bad thing. Content is used for different purposes, in a variety of contexts. It may require very different implementation techniques to handle these. In some UAs the code that processes the body for an INVITE may be entirely distinct from the code that processes the body for a NOTIFY.

In a particular request, perhaps support for content indirection should support its use for any Content-Type that is accepted in that request. Then the Supports header can be tuned on a message-by-message basis. But that raises the question of what support to claim in an OPTIONS response.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Wed, 21 Aug 2002 10:27:10 -0700 (PDT)

We should not do less with content indirection
than we can do with the existing SIP mechanisms.
That is, we cannot remove content negotiation
just because you support content indirection.

This is not a question of what MIME types you
support over content indirection, but rather what
MIME types you support in general. The two are meant
to be orthogonal.

/sean

--- Paul Kyzivat <[email-masked]> wrote:
> Hisham,
> 
> Are you saying that if a user agent wishes to
> support content indirection for one purpose (say for
> presence notifications) that it must be prepared to
> support content indirection for all other kinds of
> content as well?
> 
> That seems like a very bad thing. Content is used
> for different purposes, in a variety of contexts. It
> may require very different implementation techniques
> to handle these. In some UAs the code that processes
> the body for an INVITE may be entirely distinct from
> the code that processes the body for a NOTIFY.
> 
> In a particular request, perhaps support for content
> indirection should support its use for any
> Content-Type that is accepted in that request. Then
> the Supports header can be tuned on a
> message-by-message basis. But that raises the
> question of what support to claim in an OPTIONS
> response.
> 
> 	Paul
> 
> > I don't think this sentence needs to be there at
> all. UAs should be able to perform content
> indirection on any MIME type.
> > 
> > Regards,
> > Hisham
> > 
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.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: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Aug 2002 16:01:20 -0400

I generally agree. But there is another aspect that isn't discussed much:

In the real world the support of content types is related to the context in which they are used. So I may support application/sdp in an INVITE, but not in a MESSAGE. And even within an INVITE, I can support application/sdp with content disposition of "session" but not with content disposition of "render".

We don't have good ways to express these restrictions, or even to report that they have been violated.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Wed, 21 Aug 2002 15:00:18 -0700 (PDT)

I completely agree. We have a somewhat blunt tool
which is Accept:. Should we invent something new?
Perhaps. I don't think the content indirection 
draft is a good place to do this. The two problems
are separable as I mentioned. If in the future
we come up with something better than Accept: as
it is today, then it should be trivial to make that
work with content indirection. The problem you mention
should probably be addressed in a separate I-D on
capabilities/feature negotiation. This reminds me 
a lot of the SDPng stuff. For the time being, we
can deal with the klunky Accept-X headers and in
the future we could replace it with a more elegant
solution perhaps along the lines of the feature
set work that Jonathan has put into caller-prefs.

/sean

--- Paul Kyzivat <[email-masked]> wrote:
> In the real world the support of content types is
> related to the context in which they are used. So I
> may support application/sdp in an INVITE, but not in
> a MESSAGE. And even within an INVITE, I can support
> application/sdp with content disposition of
> "session" but not with content disposition of
> "render".
> 
> We don't have good ways to express these
> restrictions, or even to report that they have been
> violated.
> 
> 	Paul
> 
> Sean Olson wrote:
> >