Subject: [Sip] Accept MIME Types

From: Eric Burger <[email-masked]>
Date: Sun, 2 Nov 2008 11:54:08 -0500

The Accept: header field describes the MIME types the UA is willing to  
accept.

RFC 3261 says that if there is no Accept header, then the default is  
application/sdp.

What do we want to do with INFO?

In what follows, I use the terms UAS and UAC with respect to the INFO  
request. That is, the UAC sends the INFO and the UAS receives it.

Do we require a UAS to enumerate every MIME type associated with the  
Info Packages advertised in the UAS' Recv-Info header? I see two  
schools of thought on this one:

1. Follow full RFC 3261: the UAS MUST enumerate every MIME type  
associated with the Info Packages advertised in the UAS' Recv-Info  
header the UA is willing to receive. If a UAC sends a body that  
includes something not enumerated by the UAS, this is a protocol error  
and the UAS should barf appropriately.

2. Follow the text as is, where the specification of an Info Package  
in Recv_Info (and the corresponding advertisement in Send_Info)  
includes an implicit set of MIME types associated with the said package.

Pros of #1:
a. Cannot be wrong following RFC 3261
b. Provides a protocol mechanism for negotiating MIME types
c. Lets a UAC know whether the UAS can process a particular MIME type  
the UAC wishes to send (refinement of (b) above). For example, if the  
package sends images, it would be helpful for the UAC to know it can  
send image/jpeg but it cannot send image/png

Cons of #1:
a. The Accept header can grow to be very, very, very, very, very long.
b. There is no way to associate the MIME type in the Accept header  
with a particular package. That is, the UAC may advertise image/jpeg  
and image/png. The UAS may accept image/png for icons but image/jpeg  
for applications. There is no way to communicate this to the UAC.

Pros of #2:
a. Accept header does not grow without bound
b. No worse from a protocol perspective than Con #1(b).

Cons of #2:
a. Does not strictly follow RFC 3261

So, YAV:
Do we mandate UAS' enumerate the MIME types associated with a given  
package in its capability exchange with the UAC?

[ ] Yes - RFC 3261 is RFC 3261. Not to the Left, not to the Right.

[ ] No - the MIME type enumeration really does not help, so long as  
the MIME types associated with a package are enumerated in a registry  
somewhere

[ ] Maybe - we need to solve the association of the MIME type to the  
package first, then we can do RFC 3261. (This is a solvable problem;  
the question is whether anyone cares and if it is really important in  
the real world.)

_______________________________________________
Sip mailing list  https://www.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: Sun, 02 Nov 2008 18:42:18 -0500

> What do we want to do with INFO?

Such questions always force me to go review the base documents again in 
a different light.

Things I discovered:

- 3261 says the semantics are the same as RFC 2616, except the default 
is application/sdp instead of */*.

- 2616 says that the Accept specifies what is acceptable *in the 
response*! It doesn't say anything about what is acceptable in future 
requests.

However SIP seemingly has a history of assuming this applies to bodies 
sent in future requests as well. (But the scope of that promise is not 
well understood.)

Its also my understanding that, as used in SIP, Accept is rarely 
absolute, except perhaps in 415 responses. Other places, it says "I can 
accept this" but *doesn't* say "I can't accept anything else".

So I think you are free to try sending a body of a type that wasn't 
mentioned in Accept, but might get a 415. If so, and the Accept in the 
415 doesn't include that type then you had better refrain from using it 
again. (At least in a similar context, for awhile.)

> [x] No - the MIME type enumeration really does not help, so long as the 
> MIME types associated with a package are enumerated in a registry somewhere
> 
> package first, then we can do RFC 3261. (This is a solvable problem; the 
> question is whether anyone cares and if it is really important in the 
> real world.)

We are trying to make this simpler, not harder.
I think it would be fine to just ignore Accept, and start out assuming 
that any type that is allowed by a package is accepted. If the sender 
gets a 415 in response to an INFO, and the Accept in the 415 doesn't 
contain the C-T used in the INFO, then it shouldn't try that C-T in that 
package type again for awhile. (3pcc can cause circumstances to change.)

This narrows the scope of Accept, down to a per-package basis. In spite 
of C-T X having been rejected in package type A, it might still be 
accepted in package type B. So I think this all needs to be spelled out 
in the document.

	Thanks for asking the hard questions,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Sun, 2 Nov 2008 22:20:05 -0600

On Nov 2, 2008, at 10:54 AM, Eric Burger wrote:

> the MIME types associated with a package are enumerated in a  
> registry somewhere
>

Further said, Accept is insane as a negotiation mechanism.

--
Dean