Re: [Ltru] Last open item

Hi -

As a technical contributor..

> From: "John Cowan" <cowan@ccil.org>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Monday, April 14, 2008 8:11 PM
> Subject: Re: [Ltru] Last open item
...
> All too "merely".    What, in such circumstances, would a naive reader
> of the registry conclude was the un-deprecated value, and by what process?

MM, since the only other possibility would have a Preferred-value pointing to it.
However, I agree that this would be suboptimal, since a validating processor
would be prohibited from generating it.

> > No, if the Preferred-Value in BU refers to MM, then the logical thing to
> > do is to *not* add a preferred-value to MM if it is ever deprecated in
> > favor of something that would, for purposes of language tagging,
> > identify the same thing. 
> 
> So then BU would be deprecated with a P-V of MM, and MM would be
> deprecated without a P-V, leading the user to conclude that there is no
> current value at all.

That would not be good.  Perhaps it would make sense to avail ourselves of
RFC 4646 3.1:  "The field 'Deprecated' MAY be added to any record via the
maintenance process described in Section 3.3 or via the registration process
described in Section 3.5."  That is, in a pathological situation like the hypothetical
withdrawal of MM in favor of BU, the LSR could simply NOT add a "Deprecated"
to MM.

I think the heart of the problem here is attempting to blindly adopt changes originating
from the source standards.  Doing so works counter to one of our key goals, that
of ensuring a reasonable level of stability.    What happened with BU -> MM is
in my opinion an example of what we'd like to avoid, so if we're twiddling the
procedures, we should do so in a way which makes such cases less likely, not
more so.

Randy

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