RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: ietf-languages-bounces@xxxxxxxxxxxxx [mailto:ietf-languages-
> bounces@xxxxxxxxxxxxx] On Behalf Of John C Klensin


> > This reflects a fundamental misunderstanding of what the draft
> > does compared to what RFC 3066 does.  It imposes *more*
> > restraints on language tags, not fewer.
> 
> It also very explicitly permits talking about scripts, not just
> languages and countries.    That, to me, is an extension,
> regardless of the additional constraints.

There may be a disagreement here due to a difference of perspective: one
could say that the grammar is more extensive, but that makes the formal
language less extensive. So, I suppose whether one considers such a
revision "an extension" depends on one's perspective. 

Note that while the draft permits "talking about" scripts, RFC 3066
permits "talking about" *anything*. More extensive grammar, less
extensive language (and vice versa). 


> And, as Ned as
> pointed out repeatedly, there are things that can be done in
> 3066 parsers/interpreters in practice that have to be done
> differently in this new system.

I think this claim can only be made on the basis of assumptions not
found in RFC 3066. Ned has most recently said, 

"3066bis provides a reliable way to locate country codes in all cases,
but the algorithm is different. And this is a non-backwards-compatible
change."

The fact that it can identify country codes in all cases but requires a
different algorithm does not imply a non-backwards-compatible change
since it is a new functionality -- it is doing something that wasn't
even possible in RFC 3066. 

Backwards compatibility cannot be measured in terms of whether new
processors require different algorithms to achieve new functionality. It
can only be measured in terms of whether new processors can perform
correct operations (correct according to the specification for those
processors -- the proposed draft) on existing tags, and whether existing
processors can perform correct operations (correct according to the
specification of those processors -- RFC 3066) on new tags. This draft
permits this.



Peter Constable

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]