It is premature to make this a working group draft or publishing it
until we have progressed on 4244bis/targetURI.
On Mar 12, 2009, at 20:53, "Hadriel Kaplan" <[email protected]>
wrote:
Right someone pointed out to me offline that the minutes had no
consensus or any action. I guess I remembered what I wanted to
remember. :)
So then, to get such a discussion going...
Here are the Pro's to making it a WG doc as I see it:
1) It's Informational, not a Standards Track document.
2) Diversion is widely deployed, and if we want H-I to be widely
deployed in its place with fewer interop problems, discussing and
agreeing on the right conversion for a transition would be good.
3) We can make sure the semantics follows H-I as much as possible.
4) If we discuss it in a WG, and we find we need to add something to
H-I, we can discuss doing that.
5) Documenting interworking of non-IETF mechanisms to SIP is not
without precedent in the IETF, for example H.323 and PSTN/ISUP
interworking.
6) If we don't document this, people will do it differently, and
cause even more interop or operational issues.
7) There is clear market demand for this function, since the main
authors of the draft are users of SIP. If they want it, it's
because they want a transition to H-I to go smoothly, and it's
within our purview to make that possible.
8) One could argue we all are to blame for them needing this,
because we took a long time to come up with a standards-track
solution and the market was forced to implement something, and
Diversion had running code and solved their immediate need.
The Con's, as I see them:
1) From a procedural aspect, we would need to actually document
Diversion in something reference-able.
2) Documenting this may lead people to think Diversion is a
standard, or that it's fine to use instead of H-I, which could
prolong a transition.
3) Diversion is a proprietary header and mechanism, and was not the
path we chose to go, and this sets a bad precedent.
4) This could lead us down a slippery-slope of documenting
interworking to/from other proprietary mechanisms, which is waste of
the WG's time.
Is that a fair and complete list?
Proposed action:
1) We can ask the RFC Editor to publish the Diversion draft as an
informational individual-submission, and add lots of warning text
(and perhaps Skull and Cross-bones acii art ;)
2) We take draft-mohali-diversion-history-info-01 as a WG Item, and
again make sure the text clearly articulates that Diversion is
proprietary.
-hadriel
-----Original Message-----
From: Shida Schubert [mailto:[email protected]]
Sent: Thursday, March 12, 2009 8:01 PM
As far as I know there was no clear consensus on the way forward of
this draft,
and as you may recall, there was as much of an opposition as there
was
support
to work on this.
Only thing I believe we agreed on was that, if we were to discuss
the draft,
we were to use BLISS mailing list until we know what we are doing.
Regards
Shida
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
