Eric Burger wrote:
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?
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.)
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.
[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
[ ] 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.)
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
_______________________________________________
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
