Subject: [Sip] Default value for Accept:

From: Robert Sparks <[email-masked]>
Date: Fri, 17 Oct 2003 10:51:49 -0500

If a request contains no Accept header field, the
application processing that request is instructed
by 3261 to use a default value of "application/sdp".

Thus, if a client issues an OPTIONS or an INVITE with
no Accept header field, the response body, if present,
MUST be application/sdp. In particular, it cannot be
multipart/<whatever>.

This has interesting ramifications for the S/MIME
security tools we've been trying to focus towards.
A server cannot use them to secure a message unless
the client explicitly declares support for multipart/mime
in any request it sends?

Is this OK? Do we want to try to adjust the default
value of Accept (and what endpoints are required to
understand)? Or do we just rely on pressuring the
endpoints to always provide an Accept header with a
whole bunch of stuff listed?

RjS

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Sat, 18 Oct 2003 22:07:20 -0700

3261 has multipart as a MAY. A call flow that looks like send a multipart
INVITE, get back and error with an Accept header, then send a non multipart
is sort of disgusting but it sounds like that is what you have to do.

Practically speaking, how would folks feel about making multipart a MUST or
at least a SHOULD be able to receive.

Cullen