Re: [Sip] Re: SIP WGLC Draft draft-ietf-sip-acr-code-02.txt

[Jonathan Rosenberg <[e-mail]>]

Thanks for the comments. Replies inline.

Paul Kyzivat wrote:

> Here are some comments based on a fresh read of this draft.
> 
>     Paul
> 
> * Intro, second paragraph - typo:
> 
> s/to explicitly to indicate/to explicitly indicate/

fixed.

> 
> * Section 3:
> 
>    "A server acting on behalf of the called party, such as the UAS or a
>    proxy in their domain, MAY generate a 433 ..."
> 
> Is there any reason this is restricted to servers acting on behalf of 
> the called party? While that is where is is likely to be most useful, I 
> can see no reason to prevent a server acting for the calling party, or 
> for an intermediary, from using this.

I suppose a proxy in the originating domain could have a policy which 
prohibits its users from making anonymous calls, in which case 433 is 
appropriate. I've reworded to:

<t> A server (generally acting on behalf of the called party, though
this need not be the case) MAY generate a 433 (Anonymity Disallowed)
response when it receives an anonymous request, and the server
refuses to fulfill the request because the requestor is anonymous. A
request is considered anonymous when the identity of the originator of
the request has been explicitly withheld by the originator. This occurs
in any one of the following cases: </t>


> 
> Regarding the controversy over what values of the privacy header might 
> justify this response: Why don't we just say that any value in the 
> Privacy header other than "none" or "critical" *may* be considered 
> grounds for returning this response?

I've just removed the bit about session and header. Its clear that user 
and id do imply anonymity so let us state what we do know.

> 
>   "It is important to note that lack of a P-Asserted-Identity header
>    field, in and of itself, is not an indication of anonymity.  Even
>    though a Privacy header field value of 'id' will cause the removal of
>    the P-Asserted-Identity header field, there is no way to
>    differentiate this case from one in which P-Asserted-Identity was not
>    supported by the originating domain.  As a consequence, a request
>    without a P-Asserted-Identity is considered anonymous only when there
>    is some other indication of this, such as a From header field with a
>    display name of 'Anonymous'."
> 
> I'm not clear whether this is intended to have normative strength or 
> not. I think not. 

I think so; we're making statements (at SHOULD strength, I think) about 
what constitutes 'anonymous'. So, I added a statement up front that says 
a request SHOULD be anonymous when explicitly indicated as such, and 
that includes the cases listed. Then, in the text you cite above, I said 
that lack of p-asserted-id by itself SHOULD NOT be considered anonymous.


If so, it would be better to make that explicit by
> making it a note or something. I think there is good logic here, but it 
> may not suit everyone's policy. And I can see no reason to require this 
> policy. If someone has the misfortune to be calling on a path that can't 
> deliver the identity then they will not be able to successfully complete 
> the call even if they are not overtly blocking their identity. But that 
> is life - it is what the callee desires.

We write SHOULD for these reasons; you can override with good raeson but 
based on our expertise this is the right thing to do. I think its clear 
that as currently specified, lack of P-aseerted-id alone is NOT an 
anonymous request.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip