That's why the draft is needed but only informational. I know implementors waiting for this draft to implement the interwroking. For those who have yet implemented the interworking, what are they afraid of ? They don't care. It is obviously possible that everyone do it on his side, but the consequence is that bad mapping will introduce wrong information in History-Info header. To avoid various interpretations, a guidline is useful.
Regards, Marianne -----Message d'origine----- De : Elwell, John [mailto:[email protected]] Envoyé : vendredi 20 mars 2009 09:21 À : DRAGE, Keith (Keith); MOHALI Marianne RD-CORE-ISS; [email protected] Cc : [email protected] Objet : 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
