Sorry for the delay in responding. You may need the indexing mechanism for some usages - e.g., for diagnostics to know the complete tree of visited nodes, "retargets", etc. Certainly, it's not needed for any of the examples in the target-uri document. And, again, as I stated in the SIP session, if we're going to trim down some of the original requirements (that we spent nearly 3 years debating) and solution (that we spent 2 years debating), we're really talking about something quite different in terms of functionality provided by History-Info. AND, this would introduce a backwards compatibility issue in some cases for folks that have implemented RFC 4244. And, in the end, we really would end up with something looking very much like the Diversion header.
Mary. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Elwell, John Sent: Sunday, March 22, 2009 6:21 PM To: Audet, Francois (SC100:3055); Jonathan Rosenberg; SIP IETF; Mary BARNES; "B601:EXCH]"@zcars04e.nortel.com Subject: Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt 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 _______________________________________________ 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
