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
