> You wrote: > > (Personally I feel one might as well then only make RFC4474 > > work for SIPS URIs with S/MIME bodies, but that's just > > personal opinion) > > [JRE] The purpose of RFC 4474 was to provide authentication without > requiring a certificate at the UA - S/MIME requires a certificate!
S/MIME requires a separate body part, too. But SIP neglected to clearly require support for multipart MIME and many implmentations neglect to include support for multipart MIME. Robert Sparks collected information on multipart MIME support a SIPit or two ago, <http://www.sipforum.org/content/view/294/171>: " This is how the endpoints answered how they supported multipart/mime: 7% I break if someone sends me multipart/mime 30% I pretend multipart mime doesn't exist if someone sends it to me 20% I ignore multipart/mime, but will proxy it or hand it to my application if it shows up 17% I try to do something useful with multipart/mime I receive, but I never send it 3% I ignore multipart/mime I receive, but I try to send it to do something useful 20% I try to do something useful with multipart/mime I send and receive " I expect any SIP functionality that relied on multipart MIME would have disappointing results in the field unless these numbers vastly improve. But without multipart MIME messages, implementors have little reason to code or test it. -d _______________________________________________ Sip mailing list http://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
