Re: 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