Diversion Indication in SIP
draft-levy-sip-diversion-11

[Ballot comment]
I converted my Discuss issues to an email to the RFC Editor as follows:

Hi,

During IESG review I had the following comments on this document.

I don't object to the publication of this material as a Historic RFC, but I agree with the point made by Robert in his initial email to you about the "voice" used in the draft. Starting from the first line of the Abstract, this document reads like a current proposal for a protocol solution.

Although the Historic classification should make it clear that there is no intention for implementation or standardisation, I regret that some people might not notice this "subtlety".

If considerable updates to the text are not feasible (effort, time, etc.) I would suggest:
- a minor rework of the Abstract
  - include the note that is present at the start of
    the Introduction
- consider Jari's suggestion to move the substance of the IESG note
  into the Introduction

Would certainly appreciate it if you could take this into consideration as you advance the document.

Thanks,
Adrian

[Ballot discuss]
I don't object to the publication of this material as a Historic RFC, but I agree with the point made by Robert in his initial email to the RFC Editor about the "voice" used in the draft. Starting from the first line of the Abstract, this document reads like a current proposal for a protocol solution.

Although the Historic classificaiton should make it clear that there is no intention for implementation or standardisation, I regret that some people might not notice this "subtlty".

If considerable updates to the text are not feasible (effort, time, etc.) I would suggest:
- a minor rework of the Abstract
  - include the note that is present at the start of
    the Introduction
- consider Jari's suggestion to move the substance of the IESG note
  into the Introduction

[Ballot discuss]
I think we need to talk about this one a bunch. The IESG note about 4244 does not seem right quite right - 3325 was the primary work that came out of this thought I agree that later 4244 also covers this.

Let me provide a bit of background. Cisco was doing work with cable labs and came up with something close to this draft. Cisco then submitted it to the IETF and in the mean time Cisco implemented it their gateways. The draft was very controversial at IETF for a variety of reasons largely technical. In the meantime, if you wanted call-id to work (which everyone did want) and you were using cisco gateways (which had the bulk of the market share at that time) you pretty much needed to do this to work. So lots of vendors implemented. As the discussion continued at IETF, effectively 3325 was formed by taking the parts of this draft that people could agree on and adding a security section that we could sneak past the IESG on some sort of bogus private used in walled gardens pretext. As you can imagine that pretext turned out to be a disaster in the long run. After 3325 was published, many people felt folks that had done the pre standard implementation of this draft should migrate to 33245 and we would have interoperability - many did migrate and some did not. Later 4244 added in more functionality that 3325 did not have and had been in this draft. The IETF also defined 4474 for call-id which is the only solutions of these that is usable on the internet. (as a side note I am author of some of the text in this draft, 3325, 4244, and 4474). At this point in time, the sheer number of different solutions to the caller-id problem is a significant interoperability problem. The IETF is working on a 4244bis draft as a WG item and discussing work on calling and called part id in WG meetings. My understanding of Cisco position on this topic is that thought Cisco is still the primary user of this approach, Cisco does not believe it would be helpful to the internet, or even Cisco, to publish this even as an historic RFC. It has generated much discussion for many years inside Cisco.  People from multiple other vendors, such as Microsoft, have strongly suggested that this draft should be updated with a version of this draft roughly says whatever you do don't use this - go do what the IETF standards track recommends.  I'd like to note that the reason the author sent this is to the RFC Ed is that Joel Halpern asked him to submit it and somehow between Steve and Joel, Steve was under the impression that Joel was the Chair of the IETF so did it.

I also note this draft has changed the syntax from earlier version that were widely implemented so I'm not sure how much it does reflect the historic code base. The draft is in pretty sad state and I wonder at things like two of the original authors being removed and the spelling mistakes that are hard to imagine anyone other than me making - my favorite being "Inended status".

In summary, I believe publishing an RFC that is an alternative to the standards track RFCs for the caller-id problem is harmful to interoperability and this should not be published.

[Ballot discuss]
Could we get the RFC editor and authors to agree to put the IESG note
to the body of the document, in which case no note would be needed?

[Ballot comment]
Current IESG note says:

  This RFC contains an early alternate proposal that was not chosen
  by the SIP working group when creating the solution specified
  in RFC 4244 "An Extension to the Session Initiation Protocol (SIP)
  for Request History Information".

I suggest some edits:

  This document contains an early proposal to the IETF SIP Working
  Group that was not chosen; the solution that was chosen can be
  found in RFC 4244 "An Extension to the Session Initiation Protocol
  (SIP) for Request History Information".

This document was submitted to the RFC Editor to be published as a
Historic Independent Submission: draft-levy-sip-diversion-10.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.

Four week timeout expires on 12 October 2009.


Diversion Indication in SIP

Note: This draft is being published as an RFC for the historical
record and to provide a reference for later Informational RFCs.

This document proposes an extension to the Session Initiation
Protocol (SIP). This extension provides the ability for
the called SIP user agent to identify from whom the call
was diverted and why the call was diverted.

The extension defines a general header, Diversion, which
conveys the diversion information from other SIP user agents
and proxies to the called user agent.

This extension allows enhanced support for various features,
including Unified Messaging, Third-Party Voicemail, and Automatic
Call Distribution (ACD). SIP user agents and SIP proxies which
receive diversion information may use this as supplemental
information for feature invocation decisions.