Subject: Re: [Simple] RE: question about Presence XDMS AUID

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Oct 2006 22:29:32 -0400

I don't think that external references are in any way antithetical to 
the design of common policy. Common policy readily specifies how rules 
are combined, and due to the additive nature of the grants, you end up 
with a privacy safe system if the references cannot be fetched.

-Jonathan R.

[email-masked] wrote:

> Hi,
> 
> I think David is on the right track here. As Jonathan says, it would be possible just do extensions and keep the AUID. However, extensions such as <other-identity> and <external-list> were quite contrary to the design of common policy, so at least I thought it safer to go with a separate AUID. I think common policy has some expectation on what should happen when rules from different sources are combined, and it becomes quite difficult if an extension breaks that logic.
> 
> Markus
>  
> 
> ________________________________
> 
> 	From: ext David Viamonte [mailto:[email-masked]] 
> 	Sent: 15 September, 2006 19:16
> 	To: Jonathan Rosenberg
> 	Cc: [email-masked]
> 	Subject: Re: [Simple] RE: question about Presence XDMS AUID
> 	
> 	
> 	As I said, I do not judge OMA's decision. I just explained the differences. In general I agree it would have been possible to keep the AUID and define a new namespace with OMA extensions. This is similar -although not in the XCAP area- to what OMA has done to define new Presence elements. Perhaps there is space in OMA v2 to go that way.
> 	
> 	Just one minor comment: usage of external references is explicitly discouraged in section 5 of IETF Common Policies. Although it mentions that this feature could be added as an extension in a future version, perhaps the "strong" statement made someone think it made sense to define a new AUID?
> 	
> 	Cheers,
> 	
> 	David
> 	
> 	
> 	
> 	Jonathan Rosenberg escribió: 
> 
> 		I'll note that it is possible to define extensions WITHOUT having to define a new AUID. 
> 		
> 		By defining a new AUID, the OMA presence-rules is not backwards compatible or interoperable with the generic IETF version. Servers would need to support both, and clients at least one. 
> 		
> 		Instead, had these just beed defined as extensions within a different namespace, you would have a single AUID, a single mechanism, and backwards compatibility based on the defined extensibility rules in common policy. 
> 		
> 		-Jonathan R. 
> 		
> 		David Viamonte wrote: 
> 		
> 		
> 
> 			Hi, 
> 			
> 			Observe that the <other-identity> element is not the only difference. 
> 			
> 			Actually, if you have a look at the reference I provided earlier (section 6.6.2 in the XDM core spec) the differences between Common Policy and OMA Presence Rules are supposed to be the following ones: 
> 			
> 			- <external-list> 
> 			- <other-identity> 
> 			- <anonymous-request> 
> 			
> 			Thus, even if the <except> element could potentially cover the <other- 
> 			identity> functionality, there are still OMA elements which are not addressed (anonymous requests and external URI lists). You can refer to my previous post about why an <external-list> element may be useful from the OMA point of view. The <anonymous-request> is self-explanatory. 
> 			
> 			I do not judge pros (IETF spec compliancy) and cons (standardization delay) of not having raised these elements as generic requirements into IETF. 
> 			
> 			I agree with your considerations about IOP. 
> 			
> 			Hope this helps. 
> 			
> 			Cheers, 
> 			
> 			David 
> 			
> 			------------------------------------------------- 
> 			This mail sent through IMP: http://horde.org/imp/ 
> 			
> 			
> 			_______________________________________________ 
> 			Simple mailing list 
> 			[email-masked] 
> 			https://www1.ietf.org/mailman/listinfo/simple 
> 			
> 			
> 

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

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