Part of the complexity is in the indexing mechanism. Do we really need this?
John > -----Original Message----- > From: [email protected] [mailto:[email protected]] 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 > > 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" <[email protected]> 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. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [email protected] for questions on current sip > Use [email protected] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
