Re: [xacml] deprecation

[Erik Rissanen <erik@axiomatics.com>]

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