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

From: [email-masked]
Date: Thu, 22 Aug 2002 09:34:37 +0300

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, August 21, 2002 6:10 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]
> Subject: [Sip] Re: [Sip-implementors] Re:
> draft-olson-sip-content-indirect-mech-01.txt
> 
> 
> 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?

No, content-indirection support is just another MIME type. Your implementation can support message/external-body as well as application/sdp.

If content-type: message/external-body is supported, then you go download the message. After you download, you examine the new content-type that you have now and make a decision on support for that MIME type then.

/Hisham

> 
> 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
> 
> [email-masked] wrote:
> > 
> > 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
> 
_______________________________________________
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