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
