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, "The
HTTP 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 been
saying, "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:
-----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...
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.
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/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
_______________________________________________
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
_______________________________________________
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
