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
