Mary, Thanks.
RFC4244 was always considered a little fuzzy in some areas but the intent was generally understood. We may be able to use this opportunity to clarify some additional parts. I will read through the full draft with this purpose to see what may need clarification. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 [email protected] -----Original Message----- From: Mary Barnes [mailto:[email protected]] Sent: 12 March 2009 15:53 To: Ian Elz Cc: [email protected]; Francois Audet Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Ian, I do see your point now - the text does need clarification. Detailed comments are below [MB]. Thanks, Mary. ________________________________ From: Ian Elz [mailto:[email protected]] Sent: Thursday, March 12, 2009 10:12 AM To: Barnes, Mary (RICH2:AR00) Cc: [email protected]; Audet, Francois (SC100:3055) Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Mary, I was only considering the specific domain case as included in paragraph 2 of section 3.3 in the draft: Thus, local policy MAY also be used to determine whether to include the History-Info header at all, whether to capture a specific Request-URI in the header, or whether it be included only in the Request as it is retargeted within a specific domain (PRIV-req-3). In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether any or a specific History-Info header(s) SHOULD be forwarded. [MB] Yes, this is a little fuzzy. It is trying to make a very general statement that we are adding this new "priv-value" to the Privacy header so that we can control whether the entries are sent outside the proxy. I think that sentence is okay if we remove the normative (SHOULD) and just add a note that the details of the use of the privacy header are provided in section 4.1., something like the following: In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether or not any or a specific History-Info header(s) are forwarded outside a specific domain for which the proxy is responsible. The details as to the use of the new priv-value with the Privacy header are provided in section 4.1. [/MB] o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi- targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The use of the Privacy Header with a priv-value of "history" indicates whether a specific or all History-Info headers should not be forwarded. (There appears to be an inconsistency here as sections 3.3 and 4.1 appear to contradict. [Perhaps it just needs clarification that section 3.3 allows forwarding within the domain and 4.1 prohibits forwarding outside the domain?]) [MB] Yes, this is also fuzzy. It should really read (and the SHOULD NOT ought to be caps): Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi- targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The latter case indicates that none of the History-Info headers should be forwarded , whereas the use of the Privacy header escaped in the hi-targeted-to-uri means that a specific hi-entry SHOULD NOT be forwarded. [/MB] Assuming that the value 'history' means that presentation and forwarding should not occur. In this case the inclusion of the value 'history' in the Privacy header impacts all H-I entries. If one node includes the value 'history' in the Privacy header then there is no way for another node to specifically allow the uri included in the hi-targeted-to-uri to not be restricted. To allow forwarding of a specific H-I entry there needs to be another value which can be included in the Privacy header parameter of for the hi-targeted-to-uri. [MB] Exactly - that's why I had suggested earlier that we perhaps RECOMMEND that the Privacy header only be used in the escaped form associated with a specific hi-entry. There is text elsewhere explaining that you do have potential loss of functionality when you use the Privacy header. Perhaps, we need a stronger warning. [/MB] If the value "none" has specific meanings which will cause confusion then another value should be used. More comments in-line Nit in A.3 In both the sequence and the text you indicate that the INVITE to UA-B will retransmit. This should not occur if a 100 Trying has been received from UA-B. This means that the retransmit timer cannot be used to determine if UA-B does not respond. There will be a separate timer specified for determining no answer after the 180 has been received. [MB] You are correct - that flow is buggy and there are bugs in the flows and we will rework these and/or remove some of them.[/MB] Ian Elz Office: + 44 24 764 35256 [email protected] -----Original Message----- From: Mary Barnes [mailto:[email protected]] Sent: 12 March 2009 13:55 To: Ian Elz Cc: [email protected]; Francois Audet Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Ian, Okay, so I think I might understand now - you want to use the "none" to override the Privacy header that would be (in current 4244/4244bis) applied to the whole message as it traverses across the n/w from the UAC to the UAS. Is that correct? [ige] Yes - currently a Privacy header with value 'history' will prevent any H-I entries from being passed. If the Privacy header does not contain the value 'history' then individual H-I entries may have privacy associated. Those which do will not be forwarded but those with no privacy will be forwarded. That then though changes the meaning of the Privacy header, as I understand it - i.e., the "none" I thought had to do with specifying that an intermediary MUST NOT change the value of the Privacy header. But, I guess you are saying we specify a slightly different usage in 4244bis such that when we add it to an hi-entry, it specifies that that hi-entry MUST NOT be dropped by an intermediary. That might work, although, we would need verbage about the "risks" of doing so. [ige] I would not be as strong as MUST NOT. There may be local policy which will override what is included. I would prefer the words NEED NOT be removed {Scott B will hate me for that.} or perhaps MAY be forwarded based upon local policy. Thanks, Mary. -----Original Message----- From: Ian Elz [mailto:[email protected]] Sent: Thursday, March 12, 2009 8:43 AM To: Barnes, Mary (RICH2:AR00) Cc: [email protected]; Audet, Francois (SC100:3055) Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Mary, (Written after reading your discussion with Hans Erik.) First an apology for not making it clear in my original email that a value of "none" in a Privacy header parameter in a History-Info entry was only applicable to the uri contained in the hi-targeted-to-uri. I only suggested using the value "none" as this is a value defined for the Privacy header which explicitly indicates that privacy is not required. Any other value with the meaning of explicitly indicating that there is no privacy required for the specific uri could be used. With regard to your second paragraph below I understand that the SIP and PSTN models do not align. You are correct in your assumption that this problem is not unique for History-Info. The problem also arises with the Referred-By header. I have raised this for History-Info at this time as your new draft presents an opportunity to correct this problem for the H-I case. The general SIP privacy issue arises as when the Privacy header was defined the concept of carrying third party identities in the SIP messages was not defined. This came later with the REFER Request and the associated Referred-By header and the History-Info header. We should take what opportunities arise to discuss and correct this if there is a will to make these changes. Ian Elz Office: + 44 24 764 35256 [email protected] -----Original Message----- From: Mary Barnes [mailto:[email protected]] Sent: 11 March 2009 16:53 To: Ian Elz; Francois Audet Cc: [email protected] Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Ian, This is an interesting question. I need to think about it some more, but I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain. My initial thought is that we can't overrule the overall Privacy header. The thing is that the Privacy header doesn't preclude gathering the information and using within a domain AND if it were to not include an hi-entry when the request leaves the domain for which the proxy is responsible, the recipient can add the hi-entry for the current request-uri before it adds the new hi-entry. Your PSTN example doesn't strictly map obviously to a SIP model and I would think you might consider the PSTN hop to be within the same domain for which the proxy (or gw, I guess) is responsible OR consider this a walled garden whereby the Privacy header doesn't apply. Which brings me to a more general question as to how you all deal with other headers when you do your mapping to the PSTN when there is a Privacy header? It would seem this problem isn't unique to History-Info, although I know little about the details of PSTN I/W. Regards, Mary. -----Original Message----- From: Ian Elz [mailto:[email protected]] Sent: Wednesday, March 11, 2009 4:54 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: [email protected] Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 04 March 2009 15:15 To: [email protected] Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ 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
