John, The ECMA work is interesting but works well as the interworking can be done at a definitive point in the network where Diversion exists on one side but not on another.
If you have design your SIP network in a similar manner with a Diversion island and a History-Info island with a definitive interworking point(s) then you can take the same approach. The complexity arises if you have a mixed network where there are some nodes which add and use Diversion headers and some H-I. Unfortunately this is the type of deployment which is being seen. In this latter case as a node which converts from H-I <-> Diversion it is necessary to try and keep the information in both headers in step. This is the difficult part as H-I and Diversion are not used for the same purposes then it can be difficult to align the two different headers. The ECNA work, Diversion <-> QSIG, and the 3GPP work, H-I <-> ISUP, provide input and mechanisms which can be used in the direct mapping but consideration needs to be given for the network topology. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Elwell, John Sent: 20 March 2009 08:21 To: DRAGE, Keith (Keith); [email protected]; [email protected] Cc: [email protected] Subject: Re: [BLISS]TR: NewVersionNotificationfordraft-mohali-diversion-history-info-01 And I can chime in with work that Ecma-International did a few years ago, published as Standard ECMA-360, on mapping between History-Info (in draft form) and QSIG. I expect that mapping to/from QSIG has many similarities to mapping to/from the Diversion header field. At the time the SIPPING group was not interested in taking this up, so I don't see why 5 years later it suddenly becomes important. As Keith says, people are already doing it. John > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of DRAGE, Keith (Keith) > Sent: 19 March 2009 22:48 > To: [email protected]; [email protected] > Cc: [email protected] > Subject: Re: [BLISS] TR: > NewVersionNotificationfordraft-mohali-diversion-history-info-01 > > I believe my implementors have implemented History-Info. > > I believe my implementors have implemented Diversion. > > They have implemented interworking between the two. > > Assuming you use my implementations as reference > implementations and document exactly what they do, and > nothing else, I have no problem with proceeding with this work. > > Other people may however have a problem with that approach, > but I am quite happy to ignore them. > > regards > > Keith > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > On Behalf Of [email protected] > > Sent: Thursday, March 19, 2009 10:58 AM > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [BLISS] TR: NewVersion > > Notificationfordraft-mohali-diversion-history-info-01 > > > > Hi Dale, > > My answer in your text. > > > > Regards, > > Marianne > > > > -----Message d'origine----- > > De : [email protected] [mailto:[email protected]] > > De la part de Dale Worley Envoyé : mercredi 18 mars 2009 > > 23:04 À : BLISS Objet : Re: [BLISS] TR: NewVersion > > Notificationfordraft-mohali-diversion-history-info-01 > > > > On Fri, 2009-03-13 at 09:21 -0500, Mary Barnes wrote: > > > And, the standardization of this document could well take > > longer than > > > it will take to complete 4244bis. Per my list of pros/cons, to be > > > correct and useful, this document is effectively standardizing > > > Diversion header, which is actually more work than what's > > being done > > > in the 4244bis and target-uri docs. So, you're waiting either way. > > > > The wretched reality is that you can't solidify > > interoperation between Diversion and History-Info until you > > get *both* headers defined, and everyone agrees that > > Diversion is not fully defined and the definition of > > History-Info needs to be revised. > > [MM] The matter is not to say if Diversion is fully defined, > > it is that the Diversion header is fully implemented. So, it > > could defined in 5 minutes as it has not to be updated. An > > historical document is enough. About History-Info, I think it > > is yet late to revise History-Info but better late than > > never. The fact is that implementors are yet working on its > > implementation (and it is yet implemented for some of them) > > and they need this interworking today (if not yesterday). If > > the RFC4244bis is backward compatible, there is no issue > > standardizing the interworking from now and the interworking > > could be udated easily to be in line with the new History-Info.[/MM] > > > > As for which header occupied the promised land first, it's > > not immediately clear: draft-levy-sip-diversion-08 existed > > in 2004, and > > draft-barnes-sipping-history-info-02 existed in 2003. > > [MM]First, I AM NOT COMPARING THOSE HEADERS. You are raising > > an useless point. We want to move forward and not to say if > > v08 of one was before v02 of the other (but for your > > information, first Diversion draft existed in oct 2000 and > > first History-Info draft existed in oct 2002 and becames > > RFC4244 in 2005). Both headers are differents and > > History-Info has a larger scope than Diversion, that's why it > > has been standardized. Because discussions were too long, > > Diversion header was widely implemented. That is the facts > > and it is the only reason why we need an interworking > > guideline if we want that H-I header becomes the only > > implemented solution.[/MM] > > > > Any even slight official blessing of conversion between the > > two will lead people to consider that SIP supports both > > headers equally, which increase the complexity of the > > protocol and implementations. > > [MM]If it is "necessary" to standardize Diversion header, it > > is recommended to make an historical document.[/MM] > > > > On the other hand, there is no reason that the *work* can't > > go on, even if it receives no support from the IETF. Indeed, > > it's clear that there are market support for doing the work, > > which means that the work *will* go on. > > > > We can exploit that -- Let us delay *official* recognition > > until it's clear whether the interoperation will work well or > > badly. Since operators *will* get experience defining and > > using interoperation, we can make the big decisions when we > > know better what the consequences are. > > [MM] This work has yet been done with operators and > > implementors. Since the draft was available, everybody could > > do comments. The only thing to do if we have to wait is to > > update the document according to RFC4244bis but in my > > opinion, it will be late.[/MM] > > > > Dale > > > > > > _______________________________________________ > > BLISS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/bliss > > _______________________________________________ > > BLISS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
