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

From: "Sean Olson" <[email-masked]>
Date: Wed, 21 Aug 2002 09:26:46 -0700

Sounds reasonable. I will adjust the text accordingly. 
Thanks,
Sean

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, August 21, 2002 9:09 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] RE: [Sip-implementors] Re:
draft-olson-sip-content-indirect-mech-01.txt

Sean,

I think some specific wording may be appropriate. (Not the wording there
now.)

Before figuring out the precise wording, I'd like to see if there is
rough agreement on intent. Here are some implications of the proposal
that I think may need clarification:

1) The semantics of the Accept header are pretty clear. If one is
present, then *only* the types listed are accepted. If none is present
then the default is "Accept: application/sdp". I don't think this should
change so that one type being present (e.g. message/external-body)
implies another type being present (e.g. application/sdp).

2) a corollary to (1) is that to be useful, an Accept header containing
message/external-body will also need to mention at least one other
content type.

3) suppose A sends a request to B, and does not indicate it accepts
message/external-body. It also doesn't use content indirection in its
request. However B has a need to use content indirection in its response
(perhaps because it is too large to return otherwise). Then B must
return 415 Unsupported Media, with an Accept header containing both
message/external-body and the content type to be returned indirectly.

4) when a server responds to an OPTIONS request, it is impossible for
the response to accurately reflect what content types are accepted if
that varies according to request type. Section 11.2 of 3261 says that
the response code be the same as it would have been for an INVITE. The
same probably needs to be true for other parts of the response. In
particular, the Accept header should reflect what would be sent in a
response to an INVITE. 

	Paul

Sean Olson wrote:
> 
> The intent is to allow content indirection for any MIME type. The idea

> is to define a baseline of support. This is similar to the requirement

> that UAs support HTTP URIs. Without such a baseline,
> there is no way to know a priori that the receiving party supports
> content-indirection of the
> application/sdp MIME type. No big issue except that it means an extra
> round trip for negotiation.
> 
> I wanted to define the behavior in the absence of any other Accept: 
> header value. And I wanted to avoid changing the fact that UAs don't 
> have to explicitly list application/sdp
> as a supported Content-Type. However, I agree that this is a huge hack
> and probably not
> what most people want.
> 
> Unless someone objects and feels we need to specify a base set of MIME

> types that all content indirection implementations support, I will 
> remove this from the next version of the draft.
> 
> Thanks for the comments,
> Sean

_______________________________________________
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 12:09:06 -0400

Sean,

I think some specific wording may be appropriate. (Not the wording there now.)

Before figuring out the precise wording, I'd like to see if there is rough agreement on intent. Here are some implications of the proposal that I think may need clarification:

1) The semantics of the Accept header are pretty clear. If one is present, then *only* the types listed are accepted. If none is present then the default is "Accept: application/sdp". I don't think this should change so that one type being present (e.g. message/external-body) implies another type being present (e.g. application/sdp).

2) a corollary to (1) is that to be useful, an Accept header containing message/external-body will also need to mention at least one other content type.

3) suppose A sends a request to B, and does not indicate it accepts message/external-body. It also doesn't use content indirection in its request. However B has a need to use content indirection in its response (perhaps because it is too large to return otherwise). Then B must return 415 Unsupported Media, with an Accept header containing both message/external-body and the content type to be returned indirectly.

4) when a server responds to an OPTIONS request, it is impossible for the response to accurately reflect what content types are accepted if that varies according to request type. Section 11.2 of 3261 says that the response code be the same as it would have been for an INVITE. The same probably needs to be true for other parts of the response. In particular, the Accept header should reflect what would be sent in a response to an INVITE. 

	Paul

Sean Olson wrote:
> is to define a baseline of support.
> This is similar to the requirement that UAs support HTTP URIs. Without
> such a baseline,
> header value.
> And I wanted to avoid changing the fact that UAs don't have to
> explicitly list application/sdp
> types that all
> content indirection implementations support, I will remove this from the
> next version of the draft.
> 
> Thanks for the comments,
> Sean