Christer said in reply to me: > >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.
That was not an answer to my question. What I was trying to get to was whether providing two INFOs each containing one package provided the same solution as one INFO containing two packages (and assuming anyone has a use case for two packages on the same dialog - something I don't believe I have yet seen presented to the list - did I miss it somewhere). If the answer is yes, then it becomes a matter of deciding whether we want one solution or two to be documented, and if one, then which one. If the answer is no, then we need to understand the why and wherefore of those differences before deciding what documentation to provide. Regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2008 6:20 PM > To: DRAGE, Keith (Keith); Paul Kyzivat; SIP IETF; Eric Burger > Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple > packages per INFO > > 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
