But Q.SIG -IS- a standard, so the comparison does not hold. Interesting to see that you regard Q.SIG and Diversion header field equivalent.
/Hans Erik van Elburg On Fri, Mar 20, 2009 at 9:21 AM, Elwell, John <[email protected]>wrote: > 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
