Hi, I think that the packages should have no dependency at all - and it's an implementation issue in which order they are processed, etc.
So, IF the UAC really wants to ensure that package X is processed before package Y, the UAC should send them in SEPARATE INFOs, and wait for the X package INFO response before sending the Y package INFO. Regards, Christer -----Original Message----- From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] Sent: 23. lokakuuta 2008 0:46 To: Paul Kyzivat Cc: Christer Holmberg; SIP IETF; Eric Burger Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO Thanks for the direct answer to my question. > IMO sending two info packages in separate INFO messages should produce > the same behavior as sending them in one. > Except perhaps for order of processing. If we choose to define sending > two in one INFO, then I think we need to specify how the ordering is > supposed to work. (E.g. that they should be processed in the same > order as they appear in the multipart, and that in such case the > behavior MUST be the same as if they were sent in separate messages in > that order.) Surely here you are implying that the two packages have a dependency. That's two steps of use cases, i.e. that there is a requirement for more than one use case in the first place, and then the use case for the two packages being interdependent in terms of data content. If there is not such dependency, but the two packages both require in order delivery for their own data, then surely each package not sending the next INFO until it has received the response for the previous one within its package is a sufficient mechanism at the level of INFO and the body packaging. Regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2008 7:19 PM > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; SIP IETF; Eric Burger > Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple packages > per INFO > > Keith, > > IMO sending two info packages in separate INFO messages should produce > the same behavior as sending them in one. > Except perhaps for order of processing. If we choose to define sending > two in one INFO, then I think we need to specify how the ordering is > supposed to work. (E.g. that they should be processed in the same > order as they appear in the multipart, and that in such case the > behavior MUST be the same as if they were sent in separate messages in > that order.) > > The one advantage that comes to mind is that if you can't do this, > then you really need to wait for the round trip of one info before > sending another, which could be inconvenient and delay inducing if you > get the data for more than one at the same time. > > But we could certainly just decide not to define that now, and leave > it till later to decide if sending multiple packages is useful. > > An problem with defining this is that it introduces another sort of > error to handle if one package can be dealt with but another cannot. > > I guess I'd be inclined not to define it for now. > > Thanks, > Paul > > > > DRAGE, Keith (Keith) wrote: > > 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
