Hi, >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.
Of course not. But, unless there are good reasons I don't think we should forbid it - in case there will be future use-cases where it could be useful. >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. Correct. So, this would only be used if it fulfills all those requirements. >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? Well, that brings up a good question: assuming it is allowed to send multiple info packages in a single INFO, does that automatically mean that there must be a desirable relationship? I don't think so. If there is a relationship that should be described in the application logic itself. Regards, Christer > -----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
