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
