I have sent the copy of this e-mail from my personal e-mail address,
so sending it again from the address listed in the draft.
I apologize if people are receiving a duplicate copy.
Brian;
Many thanks for your review.
I have pasted relevant text from your comments and replied to
them inline..
[Brian]
Comments:
---------
Apart from the small point mentioned below, I didn't find any technical
issues with this draft, but it left me feeling a little uncomfortable.
It isn't
a standard, it isn't an experiment, it isn't a description of current
practice,
so what is it?
[Brian]
We had a draft which clarified the use of RFC3323 (Currently in the
AUTH48 state) along with the recommendation to use tools that were
not available at the time of RFC3323. WG decided to take on the
portion which described the toolset that were recently defined to obtain
user's privacy as a BCP, and we progressed the portion that clarified
the use of RFC3323 as a separate draft and submitted as an independent
submission.
As the toolset recommended in this draft aren't widely deployed
and not even an RFCs, the WG agreed to change the status to
informational. (We really believed the referenced specifications
namely GRUU and TURN were to be an RFCs by the time this
draft was to be published.)
There are more and more implementations of GRUU observed at
interop test events and some in deployments and TURN are seeing
tractions as well, so putting this out there will ensure the use of
proper toolsets to obtain privacy in SIP without relying on what is
defined in RFC3323.
[Brian]
Minor issues:
-------------
Referring to section 5.1.2, note that in RFC5364, "sip:[email protected]
"
is a MUST rather than a SHOULD. I don't know whether that interacts
with the
current draft in any way.
[Brian]
Sniplet from the introduction of RFC5364 --
Additionally, we provide the sender with the
capability of indicating in the URI list that one or more resources
should be anonymized, so that some recipients' URIs are not
disclosed
to the other recipients. Instead, these URIs are replaced with
anonymous URIs.
--
So the anonymization is for not the sender itself but for the
recipients
of the copied messages (receivers). The UA-privacy is about obtaining
the privacy of the sender thus there is no interaction that we have to
worry about between this draft and RFC5364. But thanks for bringing
this up anyhow.
As for the reference I will update the reference and resubmit the
version 08 of the draft.
Many Thanks
Regards
Shida
On 5-May-09, at 11:45 AM, Brian E Carpenter wrote:
<draft-ietf-sip-ua-privacy-07-carpenter.txt>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
