I agree with Hadriel and Jonathan. I don't think we need to send INFO with multiple packages.
If you have an application that needs to send multiple body parts, then define an Info-Package that contains multiple body parts and describe what each of those are. Then multiple part would only be required for UAs that need to support that package. cheers, (-:bob ________________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Hadriel Kaplan [EMAIL PROTECTED] Sent: Monday, November 17, 2008 11:50 AM To: DRAGE, Keith (Keith); Jonathan Rosenberg Cc: IETF SIP List Subject: Re: [Sip] comments on draft-ietf-sip-info-events-01 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
