There is is disconnect in the argument here. Just because SIP requires (or now nearly requires) multipart body handling doesn't mean that we have to define the meaning of multiple bodies of the same type for every usage.
And surely there are wider things bound up here. For example is it not still up to the application using INFO to ensure in order delivery if that is what it requires. One way of doing this is to constrain the transport mechanism to not send another INFO until the previous has been acknowledged. If so, then different applications may have different requirements in this respect that interact. Why does putting two different packages in the same INFO work better than two different INFO messages each with their own package usage? Is there a desirable relationship that can be implemented between the two that we would otherwise lose? Regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Christer Holmberg > Sent: Wednesday, October 22, 2008 8:54 AM > To: Paul Kyzivat; SIP IETF; Eric Burger > Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple > packages per INFO > > > 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. > > 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 > _______________________________________________ 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
