Re: [Ltru] extlang & deprecation (was draft updated

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

As a technical contributor...

> From: "Shawn Steele" <Shawn.Steele at microsoft.com>
> To: "John Cowan" <cowan at ccil.org>
> Cc: "LTRU Working Group" <ltru at ietf.org>
> Sent: Tuesday, July 01, 2008 12:20 PM
> Subject: Re: [Ltru] extlang & deprecation (was draft updated
>
> It's the "and should be avoided" part that trips me up.
...

I have the same difficulty.  In the world of MIBs, RFC 2578 says:
   The value "current" means that the definition is current and valid.
   The value "obsolete" means the definition is obsolete and should not
   be implemented and/or can be removed if previously implemented.
   While the value "deprecated" also indicates an obsolete definition,
   it permits new/continued implementation in order to foster
   interoperability with older/existing implementations.

In that universe, "deprecated" has different implications for "agent"
and "manager" application developers, but translating that thinking
to the world of language tags, it would mean: "if something is deprecated,
you should be prepared to process it, but, to the extent it is practical, 
should avoid generating it."  The use of the term "deprecated" was
deliberate in MIB land, because we did indeed want to maintain the
"please don't do this" semantic.  Stuff there gets deprecated because
it has proven to be problematic or inadequate, but is too entrenched
to permit an outright declaration of "obsolete."

My reason for saying "SHOULD  be prepared to process it" is that
in my experience folks balk at putting tests for "deprecated" bits
into conformance test suites or acceptance criteria.

Randy

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru