Re: comments on draft-ietf-sip-info-events-01

SUBSCRIBE/NOTIFY didn't specify it because (1) the Event: header as  
specifies ensures only a single payload and (2) implementations may  
find themselves hopelessly broken when a legal, RFC 3261, multipart  
payload shows up.

INFO has to specify it so we do not barf.

The "what" the INFO document is doing that SUBSCRIBE/NOTIFY did not  
have to do is explain why we have INFO at all.

On Nov 17, 2008, at 10:50 AM, Hadriel Kaplan wrote:

>
> I'm with Jonathan - the latest INFO draft is 41 pages long.  RFC  
> 3428 for MESSAGE method was 18 pages long.  The entire Subscribe/ 
> Notify RFC 3265 was only 38 pages long.
> Something ain't right.
>
> Of course a SIP message can have multiple bodies.  That doesn't mean  
> we have to define the whole thing or make it explicit in this doc.   
> If Sub/not didn't specify it, why does INFO have to?
>
> -hadriel
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> DRAGE, Keith (Keith)
>> Sent: Monday, November 17, 2008 10:47 AM
>> To: Jonathan Rosenberg
>> Cc: IETF SIP List
>> Subject: Re: [Sip] comments on draft-ietf-sip-info-events-01
>>
>> Is this a concern just for legacy usage or is there a wider concern.
>>
>> draft-ietf-sip-body handling updates RFC 3261:
>>
>> ------------------------------------------------------------------------
>> SIP Working Group                                           G.  
>> Camarillo
>> Internet-Draft                                                   
>> Ericsson
>> Updates: 3261, 3204, 3459                               October 29,  
>> 2008
>> (if approved)
>> Intended status: Standards Track
>> Expires: May 2, 2009
>>
>>
>>     Message Body Handling in the Session Initiation Protocol (SIP)
>>                  draft-ietf-sip-body-handling-04.txt
>> ------------------------------------------------------------------------
>>
>> 4.2.  Mandatory Support for 'multipart' Message Bodies
>>
>>   For all MIME-based extensions to work, the recipient needs to be  
>> able
>>   to decode the multipart bodies.  Therefore, SIP UAs MUST support
>>   parsing 'multipart' MIME bodies, including nested body parts.  In
>>   particular, UAs MUST support the 'multipart/mixed' and 'multipart/
>>   alternative' MIME types.
>> -------------------------------------------------------------------------
>>
>> As this draft is hopefully going to get published before or at the  
>> same
>> time as info-events, I would expect all new info package  
>> implementations
>> to support - afterall, it is mandatory.
>>
>> regards
>>
>> Keith
>>
>>
>>> -----Original Message-----
>>> From: Jonathan Rosenberg [mailto:[email protected]]
>>> Sent: Monday, November 17, 2008 3:35 PM
>>> To: DRAGE, Keith (Keith)
>>> Cc: IETF SIP List
>>> Subject: Re: [Sip] comments on draft-ietf-sip-info-events-01
>>>
>>>
>>>
>>> DRAGE, Keith (Keith) wrote:
>>>> To comment on the multipart body question below, my
>>> understanding of
>>>> the requirement from the previous discussion is that it
>>> does not come
>>>> from the need to send two info packages at the same time.
>>>>
>>>> Rather it comes from the need to send an info package plus
>>> some other
>>>> associated but yet to be described message body that happens to be
>>>> needed to be sent at the same time (e.g. info package containing a
>>>> Geolocation header pointing to a geolocation body in the
>>> same message).
>>>> If we could eliminate this, we could get rid of it, but I
>>> suspect we
>>>> cannot.
>>>>
>>>> Given this, the support of multiple packages comes for free, so why
>>>> eliminate it.
>>>
>>> Free? Certainly not.
>>>
>>> If, as an implementor, all I care about is INFO, and I don't
>>> have any other use case for multipart (which, as of now, are
>>> mostly niche uses and are not common), I'll now NEED to
>>> implement multipart for INFO.
>>>
>>> So, I don't have a problem saying that INFO can contain
>>> multiple bodies as any message can, but I do have a problem
>>> with the idea that the INFO framework ITSELF allows multiple
>>> packages per INFO.
>>>
>>> -Jonathan R.
>>>
>>>
>>> --
>>> Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
>>> Cisco Fellow                                   Iselin, NJ 08830
>>> Cisco, Voice Technology Group
>>> [email protected]
>>> http://www.jdrosen.net                         PHONE: (408) 902-3084
>>> http://www.cisco.com
>>>
>> _______________________________________________
>> 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