Resending to include SIP WG mailing list.
-----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Fri 3/20/2009 12:32 AM To: Hans Erik van Elburg Subject: RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Hi Hans Erick, Responses below [MB]. Thanks, Mary. -----Original Message----- From: Hans Erik van Elburg [mailto:[email protected]] Sent: Thu 3/19/2009 5:51 AM To: Barnes, Mary (RICH2:AR00) Cc: [email protected] Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Hi Mary, Other discussion on the list triggered the following question when looking at how Request-URI's are recorded in 4244. Assume: A UAS that receiving the History-Info in a request. The UAS needs the original parameters that where present on a particular recorded Request-URI. Q1: Does the current 4244 text ensure that the Request-URI parameters are recorded? [MB] The current text doesn't specifically discuss Request-URI parameters, but per the general rule that information is not removed from messages, the parameters should be left intact. I can add something to that affect to the next version to clarify that point. [/MB] Q2: Assuming they are recorded, how to distinguish parameters that where originally present and those that where added in the History-Info recording process? [MB] History-Info doesn't add any new Request-URI parameters. The Reason header is escaped in the Request-URI, but it's not something that would be part of any SIP Request and would only appear in a Request-URI that has been captured in the History-Info header. We could also add a statement clarifying that to RFC 4244. Q3: What was the design objective for not having reason headers etc be recorded as hi-param? I.e. why is the recorded URI modified? [MB] That was just a matter of reusing an existing header versus defining a parameter that had the exact same information. This was an issue discussed at IETF-55 in Nov 22 (Issue 2, chart 5): http://www.ietf.org/proceedings/02nov/slides/sipping-2/index.html You can see in those charts (and older versions of the drafts that you may or may not be able to dig up) that the Reason was originally an hi-param. The escaping also saves a few bytes per hi-entry. The recorded URI is modified because the intent was to capture "why" that URI was retargeted. You can also look at those charts above (specifically chart 4 that has the ABNF) and see that we were originally capturing two entries at each node - old and new. But, again, to make the header more compact we simplified to just record the new and thus have the "old" already captured by the time the request is received by the next node. The Reason header is only added (to the "old" hi-entry) in the case that the retargeted URI is in the domain for which the entity doing the retargeting is responsible. [/MB] Best Regards, /Hans Erik van Elburg
_______________________________________________ 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
