Re: draft-ietf-sip-info-events-00: multiple packages per INFO

Christer Holmberg wrote:
> Hi,
> 
> Doesn't the body handling draft say that one MUST be able to parse
> multipart message bodies?
> 
> So, I don't think we should forbid the usage of multiple packages. There
> MAY be use-cases where it is useful, so...
> 
> I also think that the negotiation of multipart support is more generic,
> so such mechanism should not be bound to INFO packages.

My thinking was:

If multipart is used to convey multiple info packages, then each part 
that contains an info package should contain an Info-Package header 
stating which package it is. That was an alternative to Eric's proposal 
that all the packages be listed at the outer level.

Then the question remained: in this case should there be an Info-Package 
header at the outer level, and if so, what should it contain?

Answering that question is what led to my proposing the "multipart" package.

I guess an alternative would be for the Info-Package header at the outer 
level to list all the packages contained, in no particular order, and 
then for the individual parts to contain an Info-Package describing that 
part.

I do think it is necessary for there to be an Info-Package header at the 
outer level, to distinguish this from a legacy use of Info.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> 
> 
>  
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Paul Kyzivat
> Sent: 21. lokakuuta 2008 17:45
> To: SIP IETF; Eric Burger
> Subject: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO
> 
> Re the question about multiple packages per INFO:
> 
>     There MUST be exactly one Info Package type listed per Info-Package
>     header.  Multiple Info-Packages per INFO message are disallowed.
> 
>     [EDITOR NOTE: Really?  Why not multiple Info-Packages, in a
>     multipart/mime?  Well, I thought of one: it is hard to disambiguate.
>     For example, take an INFO message with an Info-Package: key_image,
>     caller_picture.  I then have a multipart/mime with, you guessed it,
>     an image/jpeg and an image/jpeg.  I would offer we do allow this and
>     require the MIME parse order of the body match the order of the
> Info-
>     Package enumerations; if you have too many packages or body parts or
>     they do not align, you barf.  However, I timed out on this and thus
>     we will have to wait for the next version for me to flesh this out.
>     If we do do this, then we'll reference RFC 3261 as updated by
>     draft-ietf-sip-body-handling to require multipart MIME handling.]
> 
> How about defining an initial package type of "multipart". It allows
> only content-type multipart/mixed. Then each contained type must have
> its own Info-Package header. If you want to allow multiple packages per
> INFO then you need to negotiate support for "multipart". Or maybe we
> require support of multipart if you support any other package type.
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> 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