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
