I generally agree with many of the observations about what the IETF process
should probably be.
I also observe that there is a process for individual submissions, which Mark
and I have scrupulously followed. We ask that the IETF community consider our
work on its merits, not just on its
The characterization of this draft as controversial because two or three
people object to *any* change of RFC 3066, regardless of any evidence presented
of evolving needs and careful consideration thereof, is incorrect. Let's let
the IESG decide on that.
Asking the IESG to abandon the Last
Which is what 3066 does. So the questions remain as to what
real problems we have in internetworking that 3066 does not
solve and, if there are such problems, whether they can be fixed
by a less radical and complex change to the 3066 framework.
There are real problems with the
I'm not going to respond to most of Jefsey's comments. However, wearing my W3C
hat for a moment
Jefsey wrote:
- RFC 3066bis wants to fix some of the W3C needs, in a way which would
make these patches Internet standards. This is not the appropriate way.
(There is a W3C document on its way,
Hi Bruce,
Even if by some oversight or lapse of judgment the tag
en-US were to be registered, its interpretation by a
parser would be as an ISO 639 language code followed by
an ISO 3166 country code. SUch a registration would
therefore be pointless. In practice, therfore, it
simply
Bruce wrote:
---
No, you seem to have missed the point; there exist RFC 3066
implementations. Such implementations, using the RFC 3066 rules,
could match something like sr-CS-Latn to sr-CS, but could
not match sr-Latn-CS to sr-CS. By changing the definition of
the interpretation of the second
-phillips-langtags-08, process, specifications,
stability,and extensions (Was Language Identifier List Comments,
updated)
RE: Language Identifier List Comments, updated
Date: 2004-12-28 18:22
From: Addison Phillips [wM] [EMAIL PROTECTED]
To: JFC (Jefsey) Morfin [EMAIL PROTECTED], John
Bruce opined:
--
I also (i.e. in addition to JFC) find that characterization
offensive. I am responding to an IETF New Last Call in
accordance with established procedures, and within the time
period established. I had at one time entertained an
informal approach to addressing the procedural
We (Mark and I) welcome the last call process and timelines and the feedback
these generate. That's the whole point of having a Last Call.
The -CS subtag issue doesn't strike me as a technical issue with the draft. The
draft stabilizes the meaning of subtags. There is a process in the draft for
.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Addison
Phillips [wM]
Sent: 20041218 16:49
To: [EMAIL PROTECTED]; Bruce Lilly
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: New Last Call: 'Tags for Identifying Languages' to BCP
We (Mark
Mark and I have both worked extensively with time zone issues, so we're aware
of the potential problems.
RFC 3339 would be an appropriate substitute: its full-date production
describes the ISO 8601 profile used by the draft.
I would also tend to agree that lack of a timezone would be ambiguous
Vernon opined:
---
Besides, I didn't say that one should ignore the English, but that
implementors give precedence to the ABNF. When you are writing an RFC
that you hope will be implemented, you MUST remember that programmers
are lazy. We transliterate the ABNF to build the parser and so
On the contrary, what the authors of a standard intend is not normative.
As much as possible, every standard must say what it means, because
what a standard says *is* its technical content. For example, I'm
unhappy about an apparent sentiment that would put ABNF on a lower
13 matches
Mail list logo
