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

From: "Mary Barnes" <[email-masked]>
Date: Wed, 1 Apr 2009 10:48:35 -0500

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-masked] [mailto:[email-masked]] 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-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
> 
> 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-masked]> 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-masked] for questions on current sip Use 
> [email-masked] 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-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip