Whoopsie :-) I stand (sort of, but not really) corrected.
On Nov 30, 2008, at 5:18 PM, Anders Kristensen wrote:
Actually, Content-Id is defined for MIME in RFC 2045 as: id := "Content-ID" ":" msg-id where msg-id is defined in RFC 2822 as: msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]RFC 4228 registers Content-Id for HTTP. The actual definition of Content-Id for HTTP is in[20] Hoff, A., Payne, J., Hapner, M., Carter, S., and M. Medin, "TheHTTP Distribution and Replication Protocol", W3C NOTE NOTE- drp-19970825, August 1997. Content-Id is not defined for SIP ;) http://www.iana.org/assignments/sip-parameters Anders Christer Holmberg wrote:Hi,Don't forget, a Content-ID is a TOKEN, not a URI. One may use a URI,because a URI is a token.Does anyone read the draft before they comment? Folks have beensaying, "What would an INFO with multiple body parts look like?"READ PAGES 31-32!!!The example there uses a Content-ID of abcd9999qq and abcd1234zz. Does not look like a URI to me...According to RFC2392, the ABNF of content-id is: content-id = url-addr-spec url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec Doesn't anyone read RFC2392 before they start using content-id?...or, are you talking about a content-id specified somewhere else? ;)Regards, Christer On Nov 30, 2008, at 12:28 PM, Hadriel Kaplan wrote:Agreed. But I don't think we need to. Legacy INFO is already deployed. Subscribe/Notify is already deployed. UPDATE is already deployed. MESSAGE is already deployed. None of them use a CID for the body part that is germane to their method's context, AFAIK. It is up to the piggy-backer uses that want to add other body-parts to use CID for their parts. For example, if you wanted to add a body part for geo-loc to a Notify message that was sent for a presence package, the Geolocation header would contain a CID, not the Event header.-----Original Message----- From: Christer Holmberg [mailto:[EMAIL PROTECTED] Sent: Sunday, November 30, 2008 7:12 AM Hi, This is what I was afraid of...I think that having to use URIs in order to recognize the info package is anything but simple...This "problem" already exists for current SIP messages, and it's up to the new extensions that add body-parts to solve it in a backward- compatible way for all message methods. We don't need to solve it specifically for INFO.-hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sipThis 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_______________________________________________ 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
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
