-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:mary.barnes at nortelnetworks.com]
Gesendet: Mittwoch, 17. November 2004 18:50
An: 'PROUVOST Sebastien RD-CORE-ISS'; GARCIN Sebastien RD-CORE-ISS; Jesske, Roland; sip at ietf.org
Betreff: RE: [Sip] Privacy statements and History(draft-ietf-sip-history-i nfo-04.txt)Hi all,I've again snipped the thread, but did want to propose the change that I think will satisfy the concerns raised.The change proposed is to change the last statement in the first paragraph in section 4.3.3.1.1 from:"...the proxy MUST remove any hi-entry(s) prior to forwarding."to:"...the proxy SHOULD remove any hi-entry(s) prior to forwarding, depending upon local policy and whether the proxy might know apriori that it can rely on a downstream privacy service to apply the requested privacy."So, unless further concerns are raised on this proposed change, I'll plan on incorporating that with any other last call comments in the -05 version.Mary-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of PROUVOST Sebastien RD-CORE-ISS
Sent: Thursday, November 11, 2004 8:44 AM
To: Barnes, Mary [NGC:B601:EXCH]; GARCIN Sebastien RD-CORE-ISS; Jesske, R; sip at ietf.org
Subject: RE: [Sip] Privacy statements and History(draft-ietf-sip-history-info-04.txt)Mary, Sebastien, Roland,I agree that we should let the possibility for a proxy not to remove the hi-entry even if privacy is requested and even if the request is forwarded to a Request-URI associated with a domain for which the proxy is not responsible (if there is an agreement between the domains that ensures the proxy that privacy will be applied to the request).I suggest a text that would look like (in case privacy is requested): "the hi-entry SHOULD be removed by the proxy unless it knows that it can rely on a downstream privacy service to apply the requested privacy ".Sebastien.
De : sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] De la part de Mary Barnes
Envoyé : mercredi 10 novembre 2004 19:54
À : GARCIN Sebastien RD-CORE-ISS; Jesske, R; sip at ietf.org
Objet : RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)I still contend that the SHOULD is sufficient. SHOULD means that in general processing, if the hi-entry has a privacy header, then the usual processing would be that it would be removed (i.e it was added for a specific reason and in general should be used to remove the entries based on well defined criteria). If there are reasons, such as local policy, that would allow the forwarding in specific cases, then it's okay that it is forwarded. I think the use of MAY results in less precision and I think the value and critera for associating and removing the privacy header with the hi-entry becomes much less clear.
I'd like to hear more opinions on this topic, prior to agreeing to making the change (from the MUST to MAY rather than MUST to SHOULD).
Regards,
Mary
-----Original Message-----
From: GARCIN Sebastien RD-CORE-ISS [mailto:sebastien.garcin at francetelecom.com]
Sent: Wednesday, November 10, 2004 12:28 PM
To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R; sip at ietf.org
Cc: VL-T-Com-T-TE332 at vli.telekom.de
Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)
Mary and roland,
Actually, the statement regarding the forwarding of hi-entries beyond the domain for which the proxy is responsible should rather be a matter of local policy and thus a MAY should be used instead of SHOULD. We are potentially dealing with network boundaries where agreements for forwarding such kind information can be reached.
Section 4.3.3.1.1
This section should be re-reworded in accordance with the statement above (I can provide some text is we can agree).Section 4.3.3.1 is ok (apologies for not being explicit)
Best regards,
sébastien
------Remainder of thread has been deleted by Mary------------------
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip