--On Thursday, 06 January, 2005 06:35 -0800
ned.freed@xxxxxxxxxxx wrote:
>...
>> Extended language tags will neither help nor harm you, then.
>
> This actually may be true, because as I have said before, the
> likely outcome if this draft is adopted in its present form
> will be that it will simply be ignored in its entirety. But is
> this what we want?
Actually, Ned, my concern goes a little beyond "ignored in its
entirety". If this thing were adopted as a separate standard,
with some scope of applicability, and it were completely
ignored, that would not really be harmful except on the great
scoreboard of standards issued versus standards used. But, if,
in the process, it succeeds in identifying 3066 as Obsolete
without replacing it with anything that is usable and
compatible, that could cause a serious reduction in
interoperability in the areas where 3066, today, is good enough
or just about good enough.
That brings me back to what I've tried to suggest several times
but which, as you observe, the authors of this draft seem to
dismiss either as "noise" or as a "no change to 3066 under any
circumstances" position. If the purpose is to get this model
out there, rather than replacing 3066 because it is generally
offensive, there is a fairly quick way to get this document
unstuck:
(1) Remove the notion and statements about obsoleting 3066.
This would probably require a change of title and some
introductory material, but that shouldn't be a big deal if the
real goal is to get it finished and published.
(2) Create a new section, called "applicability" that contains
at least one example of how and where this system would be used.
I'm not wild about it but, personally, I'd settle for some vague
handwaving like "places where more comprehensive identification
is needed than is provided by 3066".
(3) Ask the IESG to approve publication of the thing as either a
Proposed Standard or an Experimental document, as they believe
best matches the needs and consensus of the community. The
document is not a good candidate for BCP for three reasons: (i)
as you and I have commented, it contains algorithmic and
protocol specifications, rather than just specifying a
registration procedure. 3066 was, IMO, marginal in that regard;
this is well over the line. (ii) As Jefsey has pointed out,
this is not yet a "current practice", "best" or otherwise.
(iii) Two BCP documents covering the same space would be certain
to create confusion unless the applicability differences were
much more clearly stated than I think anyone is prepared to do.
Then we let the market sort the situation out. If the proposers
of this specification are right about how important the
additional detail are, I'd expect to see
Content-language: <3066-tag>
X-Extended-Content-language: <new-tag>
and its equivalents show up all over the email environment and
the web. The interpretation and matching issues would either
sort themselves out or they wouldn't. If it became clear, in
practice, that this was the right way to go for a broader range
of applications, writing a short RFC to update the applicability
statement (and to move the thing from Experimental to Proposed
Standard if the IETF went the "experimental" route), would be
pretty trivial. If that range appeared to the community to be
subsuming all of the applications of 3066, the same document
could provide the "obsoletes 3066" decision.
You've probably got a prediction about how likely the broadest
form of outcome is, and it probably matches mine. But the IETF
does not, and should not try, to impose technologies by
replacing working standards, and, despite my biases about
experience and processes, our predictions should ultimately be
no more determinative than that of the authors. Let's separate
this from "replaces 3066", get it out there, see how important
and useful the marketplace thinks it is, and let the marketplace
(and the experimental/ proposed standard models) sort of the
implementability and usability problems.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf