Subject: Re: [BLISS] TR: New Version Notification for draft-mohali-diversion-history-info-01

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 12 Mar 2009 14:48:58 -0400

Hi Marianne and BLISS Chairs,
Why was this submitted as an individual-draft again and not a Working-Group draft?

Didn't we have consensus in Dublin to make this a BLISS WG Item?

If we want to make History-Info the new white meat, we have to provide a transition mechanism.  That transition mechanism can either be done differently by every system, or be done the same way. 

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Sunday, November 02, 2008 7:38 AM
> To: [email-masked]
> 
> A new version of the draft-mohali-diversion-history-info is available at
> the following URL :
> http://www.ietf.org/internet-drafts/draft-mohali-diversion-history-info-
> 01.txt
> 
> Note that interworking between Diversion header and Voicemail URI has been
> added in addition to interworking from Diversion header to History-Info
> header.
> 
> Regards,
> 
> Marianne.

---

From: Shida Schubert <[email-masked]>
Date: Fri, 13 Mar 2009 09:00:31 +0900

Hi Hadriel;

  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

On 13-Mar-09, at 3:48 AM, Hadriel Kaplan wrote:

> If we want to make History-Info the new white meat, we have to  
> provide a transition mechanism.  That transition mechanism can  
> either be done differently by every system, or be done the same way.
>
> -hadriel
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 12 Mar 2009 20:24:55 -0700

I think with the 4244bis+target-URI, it will be a  lot easier to fulfill
what this draft is trying to do.

Provided that we are capable of "marking" the URIs in the target-URI draft
that correspond to a retargeting by mapping the URIs to a different URI.

On Mar12 2009 17:00 , "Shida Schubert" <[email-masked]> wrote:

> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 12 Mar 2009 23:53:20 -0400

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

> From: Shida Schubert [mailto:[email-masked]]
> Sent: Thursday, March 12, 2009 8:01 PM
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 12 Mar 2009 20:56:30 -0700

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-masked]>  
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. :)
>
> 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.
> 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.
>
> 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.
>
> 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
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 13 Mar 2009 00:06:25 -0400

Then we will once again fail our customers in delivering a timely solution to their problems.

-hadriel

> From: Francois Audet [mailto:[email-masked]]
> Sent: Thursday, March 12, 2009 11:57 PM
>

---

From: <[email-masked]>
Date: Fri, 13 Mar 2009 10:52:52 +0100

Hi all,

I can just say that it is true that in Dublin there was not a clear consensus but it is not fair to say "there was as much of an opposition as there was support to work on this." The opposition was on the fact that Diversion was not an IETF draft (as expired) but many people was saying that this argument was not valid because there is still the possibility to edit the draft as historical.

Regards
Marianne

-----Message d'origine-----
De : Shida Schubert [mailto:[email-masked]] 
Envoyé : vendredi 13 mars 2009 01:01
À : Hadriel Kaplan
Cc : MOHALI Marianne RD-CORE-ISS; Jason Fischl; [email-masked]
Objet : Re: [BLISS] TR: New Version Notification for draft-mohali-diversion-history-info-01

Hi Hadriel;

  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

On 13-Mar-09, at 3:48 AM, Hadriel Kaplan wrote:

> If we want to make History-Info the new white meat, we have to provide 
> a transition mechanism.  That transition mechanism can either be done 
> differently by every system, or be done the same way.
>
> -hadriel

---

From: <[email-masked]>
Date: Fri, 13 Mar 2009 11:12:38 +0100

Hi,
 
I don't understand why this is premature. On the contrary, this is late.
It is long time that Diversion header is implemented and now there are
implementations based on History-Info header (RFC4244)(Here I'm just
talking about call frowarding service). RFC4244 will still be as it is
and making the History-info header interwork with the Diversion header
will still be needed as RFC4244 is implemented. 
In the other hand, the work in progress on 4244bis/targetURI could takes
time and interworking with Diversion header will may be also needed with
the "new History-Info". 

Regards
Marianne

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 13 Mar 2009 09:19:23 -0500

If you go through the minutes, you can count the number of statements for and those against, and it was fairly evenly divided, so it is totally fair and indeed accurate to say so. 
Here's my lists of Pros and cons.

Pros:
=====
1) Provides a single document (rather than vendor, SP or other SDO specific documents) for something that is fairly widely deployed.

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. 
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. 
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. 
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.
5) This puts the burden of inter-working on the vendors that have gone the standards route
6) Successfully implementing inter-working is likely more work than implementing HI (i.e., carriers are wanting vendors to implement a standard that's yet to be clearly defined rather than implementing an existing RFC).
7) Interworking has a negative impact on capacity - i.e., overall it's more work to do the interworking than implement 4244 (although perhaps in this day and age this isn't so much an issue - in the old days, capacity was an important consideration). 
 
And, I'm not sure if this is a PRO or a CON, but this is a fine example of the ineffectiveness of RAI in some areas -  Those of us that worked on History-Info would honestly have been perfectly happy had Diversion been accepted almost a decade ago, as we could have built upon that.  It wasn't, so we orginally went in with a proposal that used a header that was planned to be standardized (remote-party-id). That idea was soundly rejected and the WG consensus was to develop a very general building block.  So, the WG spent the usual several long and painful years developing RFC 4244. The most interesting aspect of this is that some of the folks most vehemently opposed to History-Info in the WG because it could be used for all these legacy services, now believe we should progress this document. Certainly, this based on the current business environment, but it's also an example of the philosophical split in the RAI area - some folks are here (as already noted) based on corporate objectives, others might be here to support corporate objectives, but they also believe in the fundamental e2e principles and still others have no corporate affiliation and thus may not need to compromise.  So, it seems in the end, we're getting the worst of both worlds and it's exemplified with this document IMHO.   

That all said, if this document were written from a more general perspective of how to interwork legacy protocol information into History-Info, then I would support the work. But, interworking a proprietary SIP header with a standardized SIP header sets a horrible precendent IMHO.  If another SDO wants to do so, then that's fine - I don't have any say in other SDOs and there's seems far more inline what many of them do regularly anyways. 

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 13, 2009 4:53 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [BLISS] TR: New Version Notification fordraft-mohali-diversion-history-info-01

Hi all,

Regards
Marianne

-----Message d'origine-----
De : Shida Schubert [mailto:[email-masked]] Envoyé : vendredi 13 mars 2009 01:01 À : Hadriel Kaplan Cc : MOHALI Marianne RD-CORE-ISS; Jason Fischl; [email-masked] Objet : Re: [BLISS] TR: New Version Notification for draft-mohali-diversion-history-info-01

Hi Hadriel;

  Regards
   Shida

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 13 Mar 2009 09:21:12 -0500

Hi Marianne,

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. 

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, March 13, 2009 5:13 AM
To: [email-masked]; Audet, Francois (SC100:3055)
Cc: [email-masked]
Subject: Re: [BLISS] TR: New Version
Notificationfordraft-mohali-diversion-history-info-01

Hi,

Regards
Marianne

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 13 Mar 2009 10:57:15 -0400

> From: Mary Barnes [mailto:[email-masked]]
> 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

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

---

From: <[email-masked]>
Date: Fri, 13 Mar 2009 16:20:41 +0100

Hi Mary,

I am not comparing Diversion header and History-Info header. In fact, I don't care if Diversion header is not standartized. The problem is that it has been implemented and not only by one implementor. I just try to recommend a solution to a real issue towards the standardized solution (like for other cases as H323 interworking).
History-Info header has been standardized for many reasons, after many time and discussions. It is the normalized solution and this is not the subject of the draft. The work on 4244bis/target-uri is necessary and good but a separate topic.

Regards,
Marianne 

-----Message d'origine-----
De : Mary Barnes [mailto:[email-masked]] 
Envoyé : vendredi 13 mars 2009 15:21
À : MOHALI Marianne RD-CORE-ISS; [email-masked]; Francois Audet
Cc : [email-masked]
Objet : RE: [BLISS] TR: New Version Notificationfordraft-mohali-diversion-history-info-01

Hi Marianne,

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. 

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 13, 2009 5:13 AM
To: [email-masked]; Audet, Francois (SC100:3055)
Cc: [email-masked]
Subject: Re: [BLISS] TR: New Version

Hi,
 
I don't understand why this is premature. On the contrary, this is late.
It is long time that Diversion header is implemented and now there are implementations based on History-Info header (RFC4244)(Here I'm just talking about call frowarding service). RFC4244 will still be as it is and making the History-info header interwork with the Diversion header will still be needed as RFC4244 is implemented. 
In the other hand, the work in progress on 4244bis/targetURI could takes time and interworking with Diversion header will may be also needed with the "new History-Info". 

Regards
Marianne

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 13 Mar 2009 10:26:10 -0500

Responses below [MB]. 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, March 13, 2009 9:57 AM
To: Barnes, Mary (RICH2:AR00); [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [BLISS] TR: New Version Notification
fordraft-mohali-diversion-history-info-01

> 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.
[MB] I agree that they have indeed published proprietary protocols, but
I am not at all aware of a case where they have published a new header
for a protocol that provides the same functionality as a standardized
header.  Why will it not work for another SDO to describe Diversion and
then just register the header?  This doc could reference the other SDO
document (there is a precendent for that). Indeed, even when docs are
published by the RFC editor, the expert review requires consideration as
to whether the work duplicates existing IETF work. Now, proprietary
protocols can be considered okay, but this isn't a protocol we're
talking about - it's a header.  And, even with independent submissions,
the IESG (per BCP 92) still  checks  for conflicts between the work of
the IETF and the documents submitted. And, as far as I understand it (at
least per today's process) "Historic" is not appropriate for this header
- that's used for things that are obsolete. [/MB]

> 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*.
[MB] In this case, I'm not blaming other SDOs. The fault in my opinion
is with the vendors that chose not to implement the standards and SPs
that don't expect vendors to implement the standards. And, that's fine -
if we want to say we messed up, then let's obsolete 4244 and jump back
on the Diversion band wagon and extend it to do the other things we want
to do. I just cannot see how having two ways to do the same thing
enhances interoperability or maintainability in the long run. [/MB]

> 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.
[MB] It was a trickle down thing - if vendor x wanted to I/W with vendor
y that only implemented diversion, then vendor X had to implement it as
well as did any other vendor that wanted to I/W with vendor Y, who for
whatever reason didn't implement History-Info. IMHO, 4 or 5 years ago,
this wouldn't have been a problem, but when a specs been out for 4+
years, then I think it's a different issue. I still can't fathom that
none of these vendors have made any changes to their products in the
past 4+ years, that they couldn't have added History-Info.[/MB]

That won't work, and we discussed why that won't work in Dublin.
[MB] The only reason I can see (as I don't recall the Dublin discussion)
is that vendor y from my example doesn't want to change a line of code
to do anything new. [/MB]

> 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.
[MB] I don't agree - History-Info has been out for quite some time and
again, I can't fathom that folks haven't made some enhancements to their
products. Now, perhaps, no one told them, but then that's not the IETF's
fault. [/MB]

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 18 Mar 2009 18:03:53 -0400

> 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.

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.

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.

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.

Dale

---

From: <[email-masked]>
Date: Thu, 19 Mar 2009 11:57:52 +0100

Hi Dale,
My answer in your text.

Regards,
Marianne 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 19 Mar 2009 23:47:40 +0100

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

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Thursday, March 19, 2009 10:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [BLISS] TR: NewVersion 
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Dale Worley Envoyé : mercredi 18 mars 2009 
> 23:04 À : BLISS Objet : Re: [BLISS] TR: NewVersion 
> 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
> [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
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 20 Mar 2009 08:21:12 +0000

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

> On Behalf Of DRAGE, Keith (Keith)
> Sent: 19 March 2009 22:48
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [BLISS] TR: 
> NewVersionNotificationfordraft-mohali-diversion-history-info-01
> 
> 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.
>

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 10:03:30 +0100

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-masked]] 
Envoyé : vendredi 20 mars 2009 09:21
À : DRAGE, Keith (Keith); MOHALI Marianne RD-CORE-ISS; [email-masked]
Cc : [email-masked]
Objet : RE: [BLISS] TR:NewVersionNotificationfordraft-mohali-diversion-history-info-01

John

> Of DRAGE, Keith (Keith)
> 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.
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of [email-masked]
> > De : [email-masked] [mailto:[email-masked]] De la 
> > part de Dale Worley Envoyé : mercredi 18 mars 2009
> > 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]
> >  
> > [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]
> > 
> > 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
> > 
> >

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 20 Mar 2009 10:15:59 +0100

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-masked]>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
>

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 23 Mar 2009 10:28:06 +0100

John,

The ECMA work is interesting but works well as the interworking can be done at a definitive point in the network where Diversion exists on one side but not on another.

If you have design your SIP network in a similar manner with a Diversion island and a History-Info island with a definitive interworking point(s) then you can take the same approach.

The complexity arises if you have a mixed network where there are some nodes which add and use Diversion headers and some H-I. Unfortunately this is the type of deployment which is being seen.

In this latter case as a node which converts from H-I <-> Diversion it is necessary to try and keep the information in both headers in step. This is the difficult part as H-I and Diversion are not used for the same purposes then it can be difficult to align the two different headers.

The ECNA work, Diversion <-> QSIG, and the 3GPP work, H-I <-> ISUP, provide input and mechanisms which can be used in the direct mapping but consideration needs to be given for the network topology.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 20 March 2009 08:21
To: DRAGE, Keith (Keith); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [BLISS]TR: NewVersionNotificationfordraft-mohali-diversion-history-info-01

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Mar 2009 06:05:33 -0400

> DRAGE, Keith (Keith)
> Sent: Thursday, March 19, 2009 6:48 PM
> document exactly what they do, and nothing else, I have no problem with
> proceeding with this work.

Sounds fine by me.  Document what you've done for H-I <-> Div.  If we don't all agree with it, we can argue about it before it becomes an RFC and potentially make changes.  You can ignore those changes, as you can for any RFC, but my guess is your customers will force/demand you to change your implementation to comply with an RFC over your current proprietary interworking.

If we don't define and publish an RFC, the customers will have no reference document to point to, to make you comply with, and you and everyone else will continue to have proprietary interworking implementations.

One of the reasons I come to the IETF is to avoid that latter scenario.  I'm not quite sure why others come, but my guess is it's something similar.

-hadriel