> -----Original Message----- > From: Mary Barnes [mailto:[email protected]] > Sent: Friday, March 13, 2009 10:19 AM > > Cons: > ====== > 1) In order for the document to be useful and accurate, it effectively is > standarizing the Diversion header. Diversion would need to be registered, > normative "i"s dotted and "t"s crossed, etc. You can't get around that.
Of course you can. The Diversion draft can be submitted as historical for information only. I believe there's even precedence for this in the IETF, where proprietary protocols or extensions were documented simply so that people could figure out how to interwork away from them. > 2) Re-enforces the idea that what we do in standards isn't translating to > the real world - History-Info was there quite some time ago, but folks > chose not to implement. We need to be honest with ourselves about this. We screwed up. We took a really long time, making a more extensible/flexible/pretty mechanism, in a more general way, instead of solving the specific problem at hand. I think we've all expressed our frustration recently about this type of problem, and hopefully the re-org and new model will improve things. But that doesn't absolve us of responsibility for Diversion's prevalence. We can't go blame 3GPP or OMA or whatever for this - it was *us*. > 3) Leading to my next point, that as Hadriel noted, this sets the > precendent for documenting all sorts of proprietary interworking (and > there's a lot of that). In my mind, this is just reverse engineering the > standards from product implementations, which is more the purview of > groups like SIP Forum or one of the Service Provider focused organizations > to provide guidelines on the Industry standards vs IETF standards - > there's already lots of cross-pollination amongst the various > organizations. If we want to do this (in IETF) we need to acknowledge > this is what we're doing, but it certainly doesn't seem to be the charter > of any of the current RAI WGs. If it were just one vendor that implemented it, I would find it a lot more troublesome in terms of precedence setting. But it wasn't one vendor. Many vendors implemented it. It's effectively a defacto standard. > 4) From a technical perspective, there is the potential for loss of > information when mapping from History-Info -> Diversion -> History-Info. > My suggestion would be to just carry both headers through the network. That won't work, and we discussed why that won't work in Dublin. > 5) This puts the burden of inter-working on the vendors that have gone the > standards route They already have that burden, because of how long it took us. The incumbent deployed legacy gear almost always has the upper hand in this regard. -hadriel _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
