Subject: RE: [Sip] Default value for Accept:

From: [email-masked]
Date: Mon, 20 Oct 2003 14:28:02 +0300

The specification could be modified to be S/MIME friendly.  Making a multipart a SHOULD or a MUST to receive, as Cullen suggests, is one way. The other is to specify that if Accept-header is missing in the request, then the sender MUST be able to receive application/sdp or multipart bodies.

Regards,
Hisham

> -----Original Message-----
> From: ext Robert Sparks [mailto:[email-masked]]
> Sent: Friday, October 17, 2003 6:52 PM
> To: [email-masked]
> Subject: [Sip] Default value for Accept:
> 
> 
> 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
> 

_______________________________________________
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: Ben Campbell <[email-masked]>
Date: Tue, 21 Oct 2003 10:31:33 -0500

> The specification could be modified to be S/MIME friendly.  Making a multipart a SHOULD or a MUST to receive, as Cullen suggests, is one way. The other is to specify that if Accept-header is missin…

I would agree with both making multipart (at least) a SHOULD, and making 
it part of the default Accept value. But that would create backwards 
compatability issues, and the try multipart-fail-try again use case the 
Cullen mentions would become common. Is this something we can live with?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Oct 2003 23:03:54 -0400

I am hesitant to make such a substantial change as to now mandate 
support for multipart.

In practice, I think that the send/fail/retry will not be so common. I 
would be surprised if UA's, by *default* sign everything they send. I 
believe a more common case will be that users will dial from their 
phone books, which will have additional info on whether or not that 
recipient has, in the past, indicated that it can accept multipart and 
signed bodies. Thats no guarantee about support for future calls, but 
its a good bet.

Also, note that we already have a bug with regards to default Accept 
values. RFC 3261 says that the default is application/sdp. But rfc3265 
says something quite different:

> 3.1.3. Additional SUBSCRIBE Header Values
> 
>    Because SUBSCRIBE requests create a dialog as defined in SIP [1],
>    they MAY contain an "Accept" header.  This header, if present,
>    indicates the body formats allowed in subsequent NOTIFY requests.
>    Event packages MUST define the behavior for SUBSCRIBE requests
>    without "Accept" headers; usually, this will connote a single,
>    default body type.

which says that each package defines the default value of Accept.

-Jonathan R.

Ben Campbell wrote:

>> The specification could be modified to be S/MIME friendly.  Making a 
>> multipart a SHOULD or a MUST to receive, as Cullen suggests, is one 
>> way. The other is to specify that if Accept-header is missing in the 
>> request, then the sender MUST be able to receive application/sdp or 
>> multipart bodies.
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com