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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 21 Mar 2009 11:07:23 -0400

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.
-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 22 Mar 2009 09:11:07 -0700

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.

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 22 Mar 2009 23:20:44 +0000

Part of the complexity is in the indexing mechanism. Do we really need
this?

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Francois Audet
> Sent: 22 March 2009 16:11
> To: Jonathan Rosenberg; SIP IETF; Mary BARNES; 
> "B601:EXCH]"@zcars04e.nortel.com
> Subject: Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt
> 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>