Subject: [Geopriv] Re: [Simple] substitution groups vs. any elements

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Feb 2005 10:39:50 -0500

Let me give a use case to motivate the "any" approach.

I service provider foo.com has deployed presence services. They have 
soft clients from vendor X, presence servers from vendor Y, and xcap 
servers from vendor Z. Xcap servers are provided as part of the database 
infrastructure and thus separate from the presence server itself.

The service provider wishes to roll out a new type of presence 
permission, proprietary to the service provider, that gives three levels 
of clearance - <very-private/>, <somewhat-private/> and <open/>. The 
client and presence server are upgraded to allow these new permissions 
to be understood. But, since the xcap server is from a different vendor, 
it is not yet upgraded. As such, it doesn't understand these namespaces.

With substitution groups, the xcap server will reject any permissions 
documents that contain these new permissions. With the "any" approach, 
they will be accepted, and then properly understood by the presence 
server. In the event that a client places the wrong permission name into 
the document (for example, the client places <super-private/> into the 
document), the xcap server will still allow this. However, the 
permission will be ignored by the presence server and thus the system 
remains privacy safe.

The argument made in the threads to date on this topic were that xcap 
provided sufficient negotiation techniques that the client could 
discover that the new permissions were not supported, and then retry the 
request without them. The use case above highlights that in its role as 
middleman to the actual application, there are cases where we may not 
want the xcap server to be the bottleneck.

I do hope that permissions is an area of innovation and differentiation 
amongst providers; this is one of the reasons we have developed the 
common policy capabilities usages, to allow for dynamic discovery of 
supported permissions:

http://www.jdrosen.net/papers/draft-rosenberg-simple-common-policy-caps-01.txt
http://www.jdrosen.net/papers/draft-rosenberg-simple-pres-policy-caps-01.txt

Using substitution groups, imho, makes the system less flexible in 
exactly this area where we want to be flexible.

Thanks,
Jonathan R.

Andrew Newton wrote:

> All,
> 
> There remains one last, unresolved issue with 
> draft-ietf-geopriv-common-policy, and that is with regard to the usage 
> of substitution groups (requiring derivation of elements) vs. any 
> element.  Many excellent points have been made for both cases, which 
> leads Allison and I to believe that we are not all on the same page with 
> respect to usage scenarios.
> 
> Perhaps it would be best if we had some use cases for voice, IM, and 
> emergency call routing to illustrate the need for one approach vs. the 
> other.  In each use case we should look to see if the using protocol 
> gives us proper protocol/namespace/schema negotiation as to allow a 
> sender to understand the capabilities of the receiver (which XML Schemas 
> the receiver knows about) and if any privacy is compromised should the 
> sender use elements not understood by the receiver.
> 
> -andy
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Mon, 7 Feb 2005 11:01:57 -0500

For clarification, questions in-line:

On Feb 7, 2005, at 10:39 AM, Jonathan Rosenberg wrote:
> server. In the event that a client places the wrong permission name 
> into the document (for example, the client places <super-private/> 
> into the document), the xcap server will still allow this. However, 
> the permission will be ignored by the presence server and thus the 
> system remains privacy safe.

To be it differently, the client would have sent the data anyway so no 
loss of privacy.  Correct?

> discover that the new permissions were not supported, and then retry 
> the request without them. The use case above highlights that in its 
> role as middleman to the actual application, there are cases where we 
> may not want the xcap server to be the bottleneck.

Or in other words, the negotiation is point-to-point not end-to-end.  
Correct?

-andy

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Feb 2005 18:18:15 -0500

inline.

> loss of privacy.  Correct?

Yes. The error case I am talking about here is where a mis-configured or 
erroneous client tries to set a permission, but they have used the wrong 
name for the permission. If the xcap server was aware of the permission 
namespace, it would have rejected the clients request as invalid. But, 
here, it won't. As such, it will go to the presence server, where it 
will be ignored.

The net result is that, in both cases, the same information gets sent.

> Or in other words, the negotiation is point-to-point not end-to-end.  

I'm suggesting that there is a use case for that, yes. The end-to-end 
case isn't really "negotiation", in that the presence server never gets 
a chance to tell the client that the permission it tried to use is 
unknown. But, the argument is effectively that the permissions may need 
to be interpreted end-to-end, so to speak.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 07 Feb 2005 22:36:30 -0500

To add in agreement:

The notion that a submitter of a policy will inspect the response from 
XCAP and then clean up the document by removing bits and pieces, for no 
particularly good reason, seems rather optimistic. Doing this requires a 
fair amount of DOM manipulation. Many clients will probably have XML 
templates that they fill with values based on user input, rather than 
doing a full-bore DOM implementation. I certainly could imagine better 
places to spend my development resources than document trimming. Since 
the capabilities of the XCAP server can change at any time, particularly 
in the situation you describe, the client would have to re-discover 
these capabilities, i.e., retry and fail each time.

There's an additional wrinkle: There may well be other means of getting 
policy on a server, beyond XCAP. Thus, you could easily wind up with a 
situation where the same document gets rejected one way and accepted the 
other. Not a good situation if you're doing customer support...

A more general design principle lurks here: with two entities looking at 
an XML document, having the entity that only knows syntax check for 
extensions is asking for trouble. I suppose another version of the 
end-to-end principle :-)

Henning

Jonathan Rosenberg wrote:
>> leads Allison and I to believe that we are not all on the same page 
>> with respect to usage scenarios.
>>
>> sender to understand the capabilities of the receiver (which XML 
>> Schemas the receiver knows about) and if any privacy is compromised 
>> should the sender use elements not understood by the receiver.
>>
>> -andy
>>
>>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 10 Feb 2005 18:12:26 -0500

Are there any more comments regarding this issue?  I'd really like to 
move this draft forward.

-andy