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 typesc. 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.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
