3066bis, however; but it is not
insurmountable, and not a new problem.
Peter Constable
Microsoft Corporation
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
of the forms that seem to concern you.
Peter Constable
Microsoft Corporation
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
From: [EMAIL PROTECTED] [mailto:ietf-languages-
[EMAIL PROTECTED] On Behalf Of Bruce Lilly
The point is that under RFC 3066,
the bilingual ISO language and country code lists are
considered definitive.
That is nowhere stated or even suggested in RFC 3066.
Peter Constable
Microsoft
a longer tag is registered in
the interim) would apply for all time.
And so that limit would be a constraint applying for all time to the
'grandfathered' production which concerned you so much.
Peter Constable
Microsoft Corporation
___
Ietf mailing list
found in the standard ISO 639...
I.e. the definition is provided in the registry on the basis of what is
defined in ISO 639; hence if what is indicated in the registry is for
any reason insufficient for your purposes, you consult the definitive
source, the ISO standard.
Peter Constable
Microsoft
of non-private
tags that affect both protocol design and implementations
from a worst case maximum of 11 octets under RFC 3066...
Worst case at present; a month from now it could be unlimitedly larger. But
I've accepted that it would be an improvement to add constraints on overall
length.
Peter
which concerned you so much.
And so it can easily be incorporated into that ABNF production.
The productive thing would be for you to provide a suggested revision of
the ABNF to the authors.
Peter Constable
Microsoft Corporation
___
Ietf mailing list
it was added to the registry, and
that the descriptions are not replacements for content of the source
standards themselves
- that we do not need to change the proposed format of the registry to
include descriptions in multiple languages
Peter Constable
Microsoft Corporation
are enumerated.
Peter Constable
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
be at most 8 chars long, so Michael would ask for it to be
changed to something like
en-the-dialect-spoken-on-the-bowery-between-1933-and-1945-by-alcoholc-dr
ug-users-who-live-in-flophses. :-)
Peter Constable
Microsoft Corporation
___
Ietf mailing list
to that data. Perhaps I
misunderstood you, but whether or not, the relevant facts are that RFC
3066 referred to ISO source standards to establish the denotation of
identifiers drawn from those standards, and the proposed revision does
the same.
Peter Constable
Microsoft Corporation
. (No changes affecting the
set of valid tags have been made.)
Thanks.
Peter Constable
GIFT | GPTS | MICROSOFT
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
that the proposal is compatible with existing
implementations, at least one of which does make use
of the descriptions currently provided in both
languages in the ISO lists specified by RFC 3066.
Incorrect; you are making false claims about what is specified in RFC 3066.
Peter Constable
Microsoft
had been discussing definitions.)
Peter Constable
Microsoft Corporation
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
and available. I do not see how you say they are being
removed?
Peter Constable
Microsoft Corporation
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
that.
Peter Constable
Microsoft Corporation
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
react if a bogus charset or language tag
that's 2k octets long is encountered? The encoded-word spec already
allows for segmenting long strings; could it not also be revised to
allow segmenting for the parameters, which would also make it more
robust?)
Peter Constable
Microsoft Corporation
, but that did not involve establishment of a working
group; I don't understand what should prevent the same thing happening in this
case.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
it was
submitted for last call and subsequent IESG action.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
for its specific applications. This is OK as long as this is clearly
stated.
The goals for the proposed revision in enhancing RFC 3066 are clearly stated in
the draft.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman
more constrained in terms of the language variety in use. It is
simply coincidental that the more constrained usage in this case doesn't
coincide with a single dialect used by some identifiable speaker community.
Peter Constable
___
Ietf mailing list
are not valid for use in language tags used on the Internet.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
with
sr-Latn or sr-Latn-CS, and sr-Latn with sr-Latn-CS.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
W3C has consistently referenced RFC
1766/3066, however, this no more than a purely hypothetical question -- I have
no expectation of such a thing ever happening.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman
.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
see no problems with it from a TC 37 or ISO
639-RA/JAC perspective.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
in
technical discussion by being precise in use of terminology.
I was being precise. Note that ISO 639 uses application of language
identifiers in exactly the same sense in which I have used application of RFC
3066.
Peter Constable
___
Ietf mailing list
Ietf
From: Peter Constable
I'd also like to observe that various members of TC 37 and the ISO
639-
RA/JAC have observed or participated in the development of this draft.
For
my part, it is not the draft I would have developed if I had
undertaken it,
but I see no problems with it from a TC 37
not speak to other changes proposed by the draft.)
That situation almost invites
profiling of how this specification should be used in different
circumstances...
I have no particular counter to the opinions you expressed in your
remaining comments.
Peter Constable
that stability be ensured in language tags, however, and if
this is the only way to ensure it I can accept it.
Of course, your point is that it probably is neither the only nor the
best way to ensure this. I have no comments to counter that opinion.
Regards,
Peter Constable
that have been given some thought. No time to delve
into it at the moment, however.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
is a language.) I'm afraid I don't have time at the moment to elaborate
further.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
was not last to leave the room. Obviously I have
ideas on those issues.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
would be documented by an ad hoc authoritative
source. Otherwise it could not be the standard you wish.
The objective of RFC 3066 or any successor is not language documentation
(which I understand to mean more or less language description). Perhaps
I misunderstand what you're saying here.
Peter
generally matter more to users.
not on a Quixotic quest for stability
of nations.
The draft doesn't try to achieve stability of nations. Only stability in the
semantics of metadata elements.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https
of a BCP that doesn't specify any specific
matching algorithms.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
to
oppose the draft, since opposing the draft (or at least opposing any
revision that introduces a richer internal structure) leaves us in a
situation that must be characterized either as a worse problem or as
turning our backs on increased functionality to meet real user needs.
Peter Constable
of decision making that goes well beyond any
algorithm that simply uses truncation of tags, which is the only case in
which the ordering of sub-tags matters.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
is completely wrong: the reason for
supporting that order of subtags has everything to do with matching
behaviour in certain widely-deployed algorithms.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
because it followed the
example of the development of RFC 3066, which to my knowledge (as a
member of the IETF-languages list at that time) happened in the same
way. It was certainly done with a good-faith impression that appropriate
procedures were being followed.
Peter Constable
believe it increases the number of grandfathered codes that
won't
conform
to the new format.
If I'm not mistaken, I think there would be no difference in this
regard.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman
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
that point of view, it is nothing
more or less than an individual submission (or the output of a
self-defined design team) and the comments Dave and I have been
making apply.
I don't think I have questioned the applicability of your comments in
this regard at any point.
Peter Constable
their position at all.
For my part, I won't say I'm frustrated by the analysis you gave; just
disappointed that I haven't been able to get us closer to the place
where we agree on what the dichotomies are, which I had hoped to do.
Peter Constable
.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
question.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
to think that some principle has been abandoned, but it has
not.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
difference is that this draft imposes significant structural
constraints on tags.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
.
Nice to see that ISO 11179 is accepted now. Peter Constable and the
WG-ltru have opposed the reference to ISO 11179 model. This model
permits to conceptualise languages and to include in their
description an unlimited number of additional elements.
This is in no way implied by ISO 11179. The model
that
the language subtag registry proposed by this draft will change with a
frequency approaching anything close to daily. Indeed, it is entirely
likely that it will change rather less frequently than the RFC 3066
registry was likely to change.
Peter Constable
vague sense of the
scope of ISO 639-4.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
of conflation and of negotiation issues were taken into
consideration, and were discussed in an open and professional manner.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
, but at
first glance this is the very kind of thing that *should* be in a
distinct attribute.
Just in case: the langtag is not supposed to only support the
written-form attributes, but to be multimodal (cf. Peter Constable).
Please quote the voice, signs, icons, mood, etc. subtags.
For any question
of TC37/SC2/WG1. I cannot
rule out the possibility that you have submitted suggestions that found
their way to WG1.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
have no reason to comment further on this list.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
be ignored, but rather
in knowing that they *will* be ignored by others. People can form their
own opinions of his comments very quickly, but it takes a while to
discover what others' opinions might be.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
but not for
script IDs. And that is not so by explicit design; is resulted simply because
we weren't yet sure how script IDs should be integrated into the tags and the
fact that ISO 15924 wasn't yet published.
Peter Constable
___
Ietf mailing list
there will some, perhaps
many, that would be benefit from revision to the new specs.
If that was your intent, it would have been clearer to me had you asked
people to identify libraries they feel should be revised if the new spec
is adopted.
Peter Constable
Harald and Doug have described.
It *has* hindered the WG, and repeated requests for change in behaviour
have been of no avail.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
would expect that several others
monitoring the WG discussions would be providing that confirmation. I
have not seen any indication of that happening.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
personal dislike;
the accuracy or sincerity of Doug's comment was questioned, and so I have
offered my testimony supporting what he said.
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
using some
notational system. Thus, change to:
the other uses the octets of ... in some representation.
(This gives parallel wording for the two kinds of reference.)
Finally:
the Unicode code point forms
Drop forms:
the Unicode code points
Peter Constable
glyph, reference can
be made using one of those three things. It appears to me that this document
focuses on references based in some way on the code point: is not the key
distinction between the code point itself and some encoded representation of
the code point?
Peter Constable
uses the octets of ... in some representation.
(This gives parallel wording for the two kinds of reference.)
Finally:
the Unicode code point forms
Drop forms:
the Unicode code points
Peter Constable
___
Ietf mailing list
Ietf@ietf.org
https
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Randy Presuhn wrote:
However, the vocabulary, style, content, and peculiar world-view of
this latest missive leave me more convinced than ever that LB
is indeed JFC Morphin, and that under the terms of RFC 3683
a cloak
of anonymity. Expressing an anonymous voice? No problem. Influencing
determination of a consensus with public impact? That should not be allowed,
IMO.
Peter Constable
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
From: Simon Josefsson [mailto:[EMAIL PROTECTED]
Frankly, it strikes me as somewhat odd that a body acting as a
standards-setting organization with public impact might allow any
technical decision on its specifications to be driven by people
operating under a cloak of anonymity.
68 matches
Mail list logo
