OASIS eXtensible Access Control Markup Language (XACML) TC

This appears to be what the IETF defines in this area:

/*

If a definition is "deprecated" then it simply means that it's no  
longer of major importance...and need not be implemented except for  
backwards compatibility with older agents that do implement them.  It  
also means that at some point in the future those definitions may have  
replacements and the old definitions will be made "obsolete".

If it's "obsolete" then it usually means that are new definitions that  
replace the old ones and the new ones should be used in any new  
implementation (and, if possible, old implementations should be  
brought in line with the new definitions).

*/

...my thinking is that whichever way we go we will need to have  
explicit definition within our spec that defines those things being  
teed up for replacement and those that are no longer valid.

b

I think that we should not go with any of these for this release, but just note that we plan to deprecate these in next release and that these are still required algorithms for this release along with the new ones


Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122


Bill Parducci ---01/29/2009 11:17:08 AM---This appears to be what the IETF defines in this area:






From:


Bill Parducci <bill@parducci.net>



To:


XACML TC <xacml@lists.oasis-open.org>



Date:


01/29/2009 11:17 AM



Subject:


[xacml] deprecation





This appears to be what the IETF defines in this area:


/*


If a definition is "deprecated" then it simply means that it's no  

longer of major importance...and need not be implemented except for  

backwards compatibility with older agents that do implement them.  It  

also means that at some point in the future those definitions may have  

replacements and the old definitions will be made "obsolete".


If it's "obsolete" then it usually means that are new definitions that  

replace the old ones and the new ones should be used in any new  

implementation (and, if possible, old implementations should be  

brought in line with the new definitions).


*/


...my thinking is that whichever way we go we will need to have  

explicit definition within our spec that defines those things being  

teed up for replacement and those that are no longer valid.


b


---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

On Jan 29, 2009, at 12:15 PM, Anthony Nadalin wrote:
> I think that we should not go with any of these for this release,  
> but just note that we plan to deprecate these in next release and  
> that these are still required algorithms for this release along with  
> the new ones
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>

I think the consensus on the call was along those lines. Both versions  
are required, however the v3 set was to be noted as preferred for new  
implementations. I suggested that for clarity of intent we note in the  
spec that the v2 set be notated with something like "marked for  
deprecation in future versions" so that implementers can be forewarned  
(of something that may happen in subsequent versions).

Again, whatever we do in this instance I think we should consider  
creating the syntax for defining those things that are being replaced  
with those that have been. I don't see a downside to providing intent  
of the TC.

b

Maybe we can use the term "Planned for future deprecation"? Meaning that 
they are still required, but users should avoid using them for new policies.

Regards,
Erik

Bill Parducci wrote:
>
> On Jan 29, 2009, at 12:15 PM, Anthony Nadalin wrote:
>> I think that we should not go with any of these for this release, but 
>> just note that we plan to deprecate these in next release and that 
>> these are still required algorithms for this release along with the 
>> new ones
>>
>> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>>
>
> I think the consensus on the call was along those lines. Both versions 
> are required, however the v3 set was to be noted as preferred for new 
> implementations. I suggested that for clarity of intent we note in the 
> spec that the v2 set be notated with something like "marked for 
> deprecation in future versions" so that implementers can be forewarned 
> (of something that may happen in subsequent versions).
>
> Again, whatever we do in this instance I think we should consider 
> creating the syntax for defining those things that are being replaced 
> with those that have been. I don't see a downside to providing intent 
> of the TC.
>
> b
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php