Re: Multiple body-parts in one INFO

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,  
> "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