Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt

["Francois Audet" <audet at nortel.com>]

Jonathan, you are correct, we have not done too many changes so far.
In part because we are waiting on target-URI, in part because we didn't have
enough time. And mostly, because we'd like to get agreement on how to
proceed before. I'd like to discuss in the meeting.

The problems with HI today, IMHO, are the following:

- In order to make it work, today, people make "assumptions" about HI to
  be able to use it. Specifically, it is assumed that the first
  retargeting is listed, and so are the 2 last ones. This is then
  used by implementations as part of service logic and/or mapping to
  PSTN information (Original Called Number, Redirecting Number, Last
  Called Number). Unfortunately, HI (the spec) makes no such garantee:
  current usage however does. Furthermore, it is assumed that there are
  no recorded "routing" entries before the first one or between the last
  retarget and the final contact. One "simplification" that I would like
  to see is rules that makes the outcome predictable. First, I would like
  to mandate that at a minimum those entries (first, last two) are NEVER
  removed by proxies, and second, that retargets proper are labeled as
  such (as per target-URI discussion). That would greatly simplify
  History-Info.

- There is a bug in ABNF. Corrected in current draft.

- There is a gratuitous requirement that TLS be used on each hop for
  HI. I'd like to revisit that. Nobody enforces that, and I see no reason
  why HI would be treated differently than other similar headers (Via,
  Record-Route).

- The examples are all wrong... They are all using Strict Routing. The
  chances of having an implementation using HI and Strict Routing in real
  life are close to zero. It makes the reading more complex, and makes
  HI look like some form of Record-Routing.

- There have been some editorial comments on text being repetitive and
  wordy, and some proposals for simplification.

- Finally, and importantly, the idea would be to integrate all the
  changes from target-URI, including the mid-path retarget (as per point
  one above), and the last-Contact replacement.



On Mar21 2009 08:07 , "Jonathan Rosenberg" <jdrosen at cisco.com> wrote:

> My main comment at this time, is that this bis document doesn't seem
> much different from the original. Section 10 calls out a bunch of things
> that I would put in the 'minor' category - certainly not worth a
> wholesale bis document if this is all we do.
> 
> I think it'd be worth having a high level discussion on the changes we'd
> like to make to this document, and assess whether there are enough to
> warrant a bis. For example, many have complained about the complexity of
> HI; are there changes meant to help that? So far, frankly, the few
> comments on this draft have been suggestions for additions for the most
> part, and NOT simplifications. Is this meant as an omnibus for a bunch
> of extensions to HI?
> 
> Thanks,
> Jonathan R.