Re: [Sipping] Working Group Last Call -- draft-ietf-sipping-nai-r eqs

[Jonathan Rosenberg <[e-mail]>]

inline.

Mark Watson wrote:
> Jonathan, 

>>>An Identity, for the purposes of this draft, is a URI, and 
>>
>>optionally 
>>
>>>                  a Display Name. The URI MUST be 
>>
>>meaningful to the domain identified 
>>
>>>                  in the URI when used as a SIP Request-URI. 
>>
>>This is a vague definition. What is meaningful? That it routes to the 
>>user? That it is resolvable based on draft-ietf-sip-srv? 
>>
> 
> 
> Less vague suggestions gratefully accepted! The intention was to rule
> out URIs which the domain identified in the URI would not recognise -
> i.e. to rule out use of URIs which if used as a request-URI in a request
> and sent to that domain would just result in some default rejection. The
> problem with stating it formally is that the process that the domain
> uses to process the request is a local policy/service/implentation
> matter - it may be that the first proxy in the domian obtains some
> called-user-specific script based on the URI and runs this, possibly
> still resulting in a rejection.
> 
> At the end of the day, what it means for a domain to 'recognise' a URI
> is probably not something we can define completely formally, so this is
> a 'soft' requirement.
> 
> Would it make sense to talk about 'routing to the user/user's service
> logic' ? 

Yes, I think thats OK for the purposes here. SOmething even a big vague 
like "The URI, when used in a SIP request, would cause the request to be 
delivered to the user that is associated with the identity, or a 
automata that runs on their behalf."

>>>If a node, A, within the Trust Domain, is trusted by a node, B, 
>>>                  outside the Trust Domain, then it shall 
>>
>>be possible for A to securely 
>>
>>>                  send a Network Asserted Identity to B. 
>>
>>I'd like to temper this with the qualifier "if allowed by the privacy 
>>policies of the user that has been identified, and the trust domain". 
>>
> 
> 
> Your proposed qualifier is correct, but I had tried to separate the
> requirements for the capability to transfer the NAI from those for the
> (privacy-related) cicumstances in which it is allowed to do this.

I saw the requirement later on, but felt it was important enough to be 
worth repeating.

>>>It shall be possible to indicate that the user has 
>>
>>requested that the 
>>
>>>                  Network Asserted Identity be not passed 
>>
>>to other users. 
>>
>>If there is some subtle difference between this and the previous one I
> 
> 
>>have missed it. 
> 
> 
> The semantics of the first indication (1) are that the NAI cannot be
> passed outside the Trust Domain, but there is no information about
> *why*, it is just an instruction to the subsequent node.
> 
> The semantics of the second indication (2) are that the user has
> requested privacy. *One* consequence of this is that the NAI cannot be
> passed outside the Trust Domain, but there are others (you requested an
> example in your next comment - see below).
> 
> So, certainly (2) implies (1), but *in principle* (1) could be present
> due to some local Trust Domain policies, without (2). There are some
> words in Cullen's draft which strongly discourage this case, and in
> particular point out that if you know the user's privacy preference
> (either way) then you MUST NOT override this. Further, knowing the
> user's privacy preference is a GOOD THING, so Trust Domains should
> ensure that all their users have the ability to express this (e.g. in
> the form of the 'id' privacy service).
> 
> In these circumstances we get (1) iff (2), and this is where we want to
> be. 
> 
> Nevertheless, I know of Trust Domains which will need cases where (1)
> does not imply (2). The distinction can be implemented without
> additional protocol elements, by appropriate Trust Domain policies (in
> Spec(T)), as described in Cullen's draft.

All of that needs to be much clearer in the draft.

>>you need to explicitly define spec(T). You never actually state that 
>>spec(T) is a specification compliant to the requirements in this 
>>document, and you need to. 
>>
> 
> 
> OK, I will check this. The definition of a Trust Domain (in general)
> does not need to define Spec(T). 

I mean something much simpler. I mean that your document does not define 
what "Spec(T)" means. It needs to define it, like it defines trust domain.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[e-mail]                 FAX: [phone]
http://www.jdrosen.net                  PH:  [phone]
http://www.dynamicsoft.com


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