Subject: AW: RE : [Sip] draft-ietf-sip-history-info-01.txt

From: "Jesske, R" <[email-masked]>
Date: Wed, 11 Feb 2004 14:22:39 +0100

Hi Mary,

Yes your last paragraph is the correct interpretation of my email.

I think a  specific privacy tag enables the domain more flexibility with regard to the information shown to the next domain or the user.

E.g. a forwarding entity does not allow the presentation of the URI but the originating do. With a general privacy tag all information will not be forwarded to the UAS, but if you have an explicit tag for the history info only the history info will be not shown and the originating URI will be shown.

Also information that is only needed for domain/local purposes will be hidden but not the information of the originating of the SIP session.

From my understanding a specific privacy tag will help in such kind of use.

Best Regards

Roland

-----Ursprungliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Mittwoch, 4. Februar 2004 23:13
An: 'PROUVOST S?bastien FTRD/DAC/ISS'; Jesske, Roland
Cc: [email-masked]
Betreff: RE: RE : [Sip] draft-ietf-sip-history-info-01.txt

Sebastien and Roland,

I apologize for the delay in responding.  

You are correct in that one privacy aspect currently addressed for
History-Info is around the UA's ability to require privacy for elements of a
message that can somehow divulge information about the end client's
identity. In some ways, History-Info could be considered in the category of
Record Route,  Via, etc.  However, HI is an optional header and per the
recommendation in RFC 3323, the decision was made that if Header privacy was
requested, then History-Info SHOULD not be included.   In addition, if
through local policy or some other local information available wrt the
retargeted URIs, there is knowledge that there should be privacy applied to
these URIs, then as discussed in RFC 3323, the intermediary processing that
request can also add the Privacy header to ensure that History-Info is also
not captured by subsequent intermediaries.  This latter point perhaps is not
so clearly or explicitly spelled out in the current document in the privacy
sections, but there is discussion in the detailed proxy processing behaviour
in 2.3.3 that the local policy can define whether the History-Info captured
would leave a specific domain (this is of course for optionality, as well,
which is another issue that I'll address in a separate email).      

It seems that what's being discussed in these emails is introducing a
specific privacy tag against those entries that local policy defines should
not be forwarded outside a specific domain,  so that they can be removed
(and don't need to be kept persistent by a privacy service).  Right now,
there's an asumption that these entries are somehow known by the proxy, but
perhaps an explicit tag would be useful.  OR are you talking about extending
the current model in RFC 3323 to specifically address the use of a privacy
service for History-Info headers?  

Regards,
Mary H. Barnes
[email-masked]
972-684-5432

-----Original Message-----
From: PROUVOST Sebastien FTRD/DAC/ISS
[mailto:[email-masked]]
Sent: Thursday, January 22, 2004 4:32 AM
To: Jesske, R; [email-masked]; Barnes, Mary [NGC:B622:EXCH]; Watson, Mark
[MOP:EP10:EXCH]; [email-masked]
Subject: RE : [Sip] draft-ietf-sip-history-info-01.txt

I fully support this proposal. 

The privacy regarding the history-info header relates to the privacy policy
accorded to the target of the request (before it is retargeted). Therefore
it shall not depend on the privacy policy accorded to the calling UA. The
history-info header shall have its own privacy value. 
Moreover in case the request is retargeted more than once (particularly if
the targets represent different users), it shall be possible to request
privacy for a target independently of the others.  

Regards,
Sebastien Prouvost
France Telecom R&D/DAC/CAR

-----Message d'origine-----
De : Jesske, R [mailto:[email-masked]] 
Envoye : vendredi 16 janvier 2004 10:29
A : [email-masked]
Cc : Poetzl, Joachim; Alexeitsev, D
Objet : [Sip] draft-ietf-sip-history-info-01.txt

Dear all,
in 1.3 Ensuring the Privacy of History_Info it is proposed to use a
priv-value of Session or Header level privacy. I would like to propose a own
privacy level for the history info, because the Information shows also
information about the network. With regard to the provider operating a
network some of the providers don't like to transmit information about call
history. Or a redirecting party don't like to show the redirecting address.
Therefore it should be possible to delete the history info at domain
boundaries based on the privacy-value.

I propose the priv-value   =   "history_info"  for the whole History-Info
header.

In addition a option would be useful where only parts (e.g Indes1.1) of the
history info are restricted. That could be done with a privacy statement
within the History-Info .

Best Regards

Roland

Deutsche Telekom AG
T Com Zentrale
Roland Jesske, T332-2
Section T33; Signalling, Gateways and Switching Systems 
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:      +49 6151 83-4577 
email:   [email-masked]

_______________________________________________
Sip mailing list  https://www1.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://www1.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://www1.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