From ltru-bounces@lists.ietf.org Mon Aug 01 07:01:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzY2x-0006k4-RW; Mon, 01 Aug 2005 07:01:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzY2w-0006jz-PZ for ltru@megatron.ietf.org; Mon, 01 Aug 2005 07:01:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00357 for ; Mon, 1 Aug 2005 07:01:23 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DzYZC-0002dn-9a for ltru@ietf.org; Mon, 01 Aug 2005 07:34:47 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 1 Aug 2005 11:53:04 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Aug 2005 11:53:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text Date: Mon, 1 Aug 2005 11:53:03 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212BC903D@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text Thread-Index: AcWVHMZfJq+YrC2cSVGTQx/jvoPryQBaZe9g From: "L.Gillam" To: ltru X-OriginalArrivalTime: 01 Aug 2005 10:53:03.0422 (UTC) FILETIME=[30D935E0:01C59687] X-Spam-Score: 0.6 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2124558556==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2124558556== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59687.30CCA2FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59687.30CCA2FE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Jefsey, =20 Section 2.2.7 is (was) clear: =20 Private use subtags are used to indicate distinctions in language important in a given context by private agreement. =20 =20 item 5: No source is defined for private use subtags. Use of private use subtags is by private agreement only. item 6: Private use subtags are NOT RECOMMENDED where alternatives exist or for general interchange. See Section 4.5 for more information on private use subtag choice. and section 4.5: Private use subtags, like all other subtags, MUST conform to the format and content constraints in the ABNF. Private use subtags have no meaning outside the private agreement between the parties that intend to use or exchange language tags that employ them. The same subtags could be used with a different meaning under a separate private agreement. They SHOULD NOT be used where alternatives exist and SHOULD NOT be used in content or protocols intended for general use. Now, nobody can prevent you from creating implementations that are going = to be incompatible with others that conform to 3066 past, present, or = future.=20 Similarly, nobody can stop you from using two letters to represent = whatever you want them to, or saying "yes" for "no". On the other hand, if you = distribute code that is not compatible with that of others whose code conforms to = 3066, isn't it at this point that *you* would be breaking the Internet? =20 Besides, why would you want to break compatibility with other = implementations (breaking the Internet?) with:=20 0-ISO.639.6:xxxx when x-ISO-639-6-xxxx would appear to be both conformant and sufficient? =20 -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On = Behalf Of r&d afrac Sent: 30 July 2005 16:33 To: LTRU Working Group Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use = tags - Last Call proposed text [sorry, I mistakenly answered Lee only. Apologies - Last Call text = submitted in this mail] Dear Lee, I think I see your point. You say "x-" permits "private use" like in = "private nets" (intranet). So there is a conflict only if a intranet A = wants to talk to intranet B. This is an interesting point (for which I = would be interested to get an example of use) I never considered.=20 But I do not think that private use is understood this way by the Draft. = It is not the way I want it, not the way it is understood by = applications and users I relate with, nor by the = ietf-languages@alverstrand mailing list. It is understood in a way which = permits to support ISO 639-3 today or ISO 639-5, or ISO 639-6, under RFC = 3066 or bis in using "X-639-3-alpha3" - please look at Draft 2.2.7 final = paragraph.=20 However, your proposition could be an interesting way out for the Draft = to address the issue: - your example documents "x-" as the entrance into closed virtual = namespaces. Since I never met the need, I cannot comment on the demand. = I suppose this could be qualified, among others, as an experimental = namespace. If you say that 8alpha is OK for them, I cannot object. Let = it be! - the following paragraph should then be inserted after 2.2.7: "2.2.8 Escape Sequence For compatibility with other language tags systems the "0-" singleton = escape sequence if provided. It means that the "0-" singleton MUST be = considered as an end of a language tag as documented by this memo. = Everything following the "0-" singleton escape sequence, even after = another singleton, MUST be treated as foreign to the present rules and = documented registry; and as defined by another set of rules and another = registry. To avoid confusion that set of rules and registry SHOULD be = identified by a scheme built in using a unique identifier belonging to = its registry manager, or defined by an RFC." The "0-" escape sequence should be added to the ABNF. But I am not good = enough to say how. This way, "0-ISO.639.6:xxxx" would be an acceptable Language ID. Where = "ISO:" is the scheme and "ISO.639.3:" obeys to the rules of private = schemes - using a ".". Martin can tell if it should be "ISO.639.6" or = "ISO.6396". I suppose the first one is the proper one to respect the ISO = document hierarchy. Does that address your remark? jfc At 20:32 29/07/2005, L.Gillam wrote: Jefsey The point of the analogy is this: say we have two groups A and B A have their x- private use extensions, B have their own x-. =20 Since A and B do not wish to exchange information there is no problem. = Only when A and B want to exchange do might they need to redefine their = use of the x-. At this point, one suspects they might agree to use = x-justa-, x-justb-, x-aandb-. There are no implications for group C who = have their own scheme but don't desire an exchange with either A or B. =20 The same would be true if we combined 2 separate class B networks - we = would be forced into some kind of address reassignment if there were = conflicts. =20 The only constraint being that they must restrict their hyphenated = fields to 8 though the number they can use is effectively unlimited = depending on the application (consider 192.x.x.x). Besides, the 8 = characters are codes, not names. =20 Best Regards. _____ =20 From: r&d afrac [ mailto:rd@afrac.org ] Sent: Fri 29/07/2005 18:58 To: Gillam L Dr (Computing) Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use = tags Dear Lee, I am not sure I understand the question. If you mean tghat it is some similar thinking for the space master, sort of. I only mean that there are many ways to make sure that a private space = does not conflict with another private space (ask Martin about URI). The = point is to designate the namespace of the private user. My point is simply = that with more than one billion of users each having right to one name space, there is a ... lack of room. My point is only that the way the unicity = is organised is either to be defined by this WG or to be permitted by this = WG (there are miryad of possibilities and needs). And that in refusing the necessary space and characters, they condemn = users to oppose their scheme and therefore condemn their scheme. The lack of comment of Doug, shows that he has no proper solution. He = just says that he waits for the EITF LC while he promised that he had a = solution avoiding that. If he had he would only pick the few examples I listed = and would document his response. All the best. jfc On 18:42 29/07/2005, L.Gillam said: > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [ = mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of r&d afrac > >[snip] > > > I > > will take a simple example: Domain Names are private yet they cannot > > conflict. Because we organised the name space for that. As I > > indicated (and > > documented) there are many ways to specify the organisation > > of the "x-" > > name space so it is both private and conflict free. > > > >Jefsey, > >Are you considering, for example, the use of Private IP addresses - >the Class B and Class C networks? >e.g. http://www.michna.com/kb/IpAddressesPrivate.htm > >In this scheme, as I understand it, only consenting "machines" >will be referred to by a specific address - e.g. 192.168.0.54 >and if you're on another network you should not assume that the >same identifier refers to the same machine. > >Similarly, unless you have a private agreement on what follows >the x-, you should not make any assumptions. Elsewhere, this >might be described as the difference between "blind" (we know >what we're getting and don't need to look at it) and "negotiated" >(we need to make our own agreement about it) interchange. > >But, would you willfully ignore the numeric formatting required >for an IPv4 Class B network? It is private use after all. ------_=_NextPart_001_01C59687.30CCA2FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Jefsey,
 
Section 2.2.7 is (was) clear:
 
   Private use subtags = are used to=20 indicate distinctions in language
   important in a given = context=20 by private agreement. 
 
item=20 5:
    No source is defined for = private use=20 subtags.  Use of private use
   subtags is by private agreement=20 only.
item 6:
    = Private use=20 subtags are NOT RECOMMENDED where alternatives=20 exist
    or for general interchange.  See = Section=20 4.5 for more information
    on private use = subtag=20 choice.
and=20 section 4.5:
   Private use subtags, = like all=20 other subtags, MUST conform to the
   format and content=20 constraints in the ABNF.  Private use subtags have
   = no=20 meaning outside the private agreement between the parties = that
  =20 intend to use or exchange language tags that employ them.  The=20 same
   subtags could be used with a different meaning = under a=20 separate
   private agreement.  They SHOULD NOT be = used where=20 alternatives exist
   and SHOULD NOT be used in content or=20 protocols intended for general
   use.
Now,=20 nobody can prevent you from creating implementations that are going=20 to
be=20 incompatible with others that conform to 3066 past, present, or future.=20
Similarly, nobody can stop you from using two letters to = represent=20 whatever
you=20 want them to, or saying "yes" for "no". On the other hand, if you=20 distribute
code=20 that is not compatible with that of others whose code conforms to=20 3066,
isn't=20 it at this point that *you* would be breaking the = Internet?
 
Besides, why would you want to break compatibility with other=20 implementations
(breaking the Internet?) with: 
0-ISO.639.6:xxxx
when
x-ISO-639-6-xxxx
would=20 appear to be both conformant and sufficient?
 
-----Original Message-----
From: = ltru-bounces@lists.ietf.org=20 [mailto:ltru-bounces@lists.ietf.org]On Behalf Of r&d=20 afrac
Sent: 30 July 2005 16:33
To: LTRU Working=20 Group
Subject: RE: [Ltru] Re: [psg.com #1072] compatibility = and=20 private use tags - Last Call proposed text

[sorry, = I=20 mistakenly answered Lee only. Apologies - Last Call text submitted in = this=20 mail]

Dear Lee,
I think I see your point. You say "x-" = permits=20 "private use" like in "private nets" (intranet). So there is a = conflict only=20 if a intranet A wants to talk to intranet B. This is an interesting = point (for=20 which I would be interested to get an example of use) I never = considered.=20

But I do not think that private use is understood this way by = the=20 Draft. It is not the way I want it, not the way it is understood by=20 applications and users I relate with, nor by the = ietf-languages@alverstrand=20 mailing list. It is understood in a way which permits to support ISO = 639-3=20 today or ISO 639-5, or ISO 639-6, under RFC 3066 or bis in using=20 "X-639-3-alpha3" - please look at Draft 2.2.7 final paragraph.=20

However, your proposition could be an interesting way out for = the=20 Draft to address the issue:

- your example documents "x-" as = the=20 entrance into closed virtual namespaces. Since I never met the need, I = cannot=20 comment on the demand. I suppose this could be qualified, among = others, as an=20 experimental namespace. If you say that 8alpha is OK for them, I = cannot=20 object. Let it be!

- the following paragraph should then be = inserted=20 after 2.2.7:

"2.2.8 Escape Sequence

For compatibility = with other=20 language tags systems the "0-" singleton escape sequence if provided. = It means=20 that the "0-" singleton MUST be considered as an end of a language tag = as=20 documented by this memo. Everything following the "0-" singleton = escape=20 sequence, even after another singleton, MUST be treated as foreign to = the=20 present rules and documented registry; and as defined by another set = of rules=20 and another registry. To avoid confusion that set of rules and = registry SHOULD=20 be identified by a scheme built in using a unique identifier belonging = to its=20 registry manager, or defined by an RFC."

The "0-" escape = sequence=20 should be added to the ABNF. But I am not good enough to say = how.

This=20 way, "0-ISO.639.6:xxxx" would be an acceptable Language ID. Where = "ISO:" is=20 the scheme and "ISO.639.3:" obeys to the rules of private schemes - = using a=20 ".". Martin can tell if it should be "ISO.639.6" or "ISO.6396". I = suppose the=20 first one is the proper one to respect the ISO document = hierarchy.

Does=20 that address your remark?
jfc

At 20:32 29/07/2005, L.Gillam=20 wrote:
Jefsey
The point of the analogy is this:
say we have = two groups=20 A and B
 A have their x- = private use=20 extensions, B have their own x-.
 
Since A and B do not wish to exchange information there is = no=20 problem. Only when A and B want to exchange do might they need to = redefine=20 their use of the x-. At this point, one suspects they might agree to = use=20 x-justa-, x-justb-, x-aandb-. There are no implications for group C = who have=20 their own scheme but don't desire an exchange with either A or=20 B.
 
The same would be = true if we=20 combined 2 separate class B networks - we would be forced into some = kind of=20 address reassignment if there were = conflicts.
 
The only constraint being that they must = restrict their=20 hyphenated fields to 8 though the number they can use is effectively = unlimited depending on the application (consider 192.x.x.x). = Besides, the 8=20 characters are codes, not names.
 
Best Regards.

From: r&d afrac [mailto:rd@afrac.org=20 ]
Sent: Fri 29/07/2005 18:58
To: Gillam L Dr=20 (Computing)
Subject: RE: [Ltru] Re: [psg.com #1072] = compatibility=20 and private use tags

Dear Lee,
I am = not sure I=20 understand the question. If you mean tghat it is some
similar = thinking=20 for the space master, sort of.

I only mean that there are = many ways=20 to make sure that a private space does
not conflict with another = private=20 space (ask Martin about URI). The point
is to designate the = namespace of=20 the private user. My point is simply that
with more than one = billion of=20 users each having right to one name space,
there is a ... lack of = room.=20 My point is only that the way the unicity is
organised is either = to be=20 defined by this WG or to be permitted by this WG
(there are = miryad of=20 possibilities and needs).

And that in refusing the necessary = space=20 and characters, they condemn users
to oppose their scheme and = therefore=20 condemn their scheme.
The lack of comment of Doug, shows that he = has no=20 proper solution. He just
says that he waits for the EITF LC while = he=20 promised that he had a solution
avoiding that. If he had he would = only=20 pick the few examples I listed and
would document his=20 response.

All the best.
jfc



On 18:42 = 29/07/2005,=20 L.Gillam said:


> > -----Original = Message-----
> >=20 From: ltru-bounces@lists.ietf.org
> > [=20 mailto:ltru-bounces@lists.ietf.org]On
> > Behalf Of = r&d=20 afrac
>
>[snip]
>
> > I
> > will = take a=20 simple example: Domain Names are private yet they cannot
> = >=20 conflict. Because we organised the name space for that. As I
> = >=20 indicated (and
> > documented) there are many ways to = specify the=20 organisation
> > of the "x-"
> > name space so it = is both=20 private and conflict free.
>=20 >
>
>Jefsey,
>
>Are you considering, for = example,=20 the use of Private IP addresses -
>the Class B and Class C=20 networks?
>e.g. http://www.michn= a.com/kb/IpAddressesPrivate.htm
>
>In=20 this scheme, as I understand it, only consenting = "machines"
>will be=20 referred to by a specific address - e.g. 192.168.0.54
>and if = you're=20 on another network you should not assume that the
>same = identifier=20 refers to the same machine.
>
>Similarly, unless you = have a=20 private agreement on what follows
>the x-, you should not make = any=20 assumptions. Elsewhere, this
>might be described as the = difference=20 between "blind" (we know
>what we're getting and don't need to = look at=20 it) and "negotiated"
>(we need to make our own agreement about = it)=20 interchange.
>
>But, would you willfully ignore the = numeric=20 formatting required
>for an IPv4 Class B network? It is = private use=20 after all.
------_=_NextPart_001_01C59687.30CCA2FE-- --===============2124558556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2124558556==-- From ltru-bounces@lists.ietf.org Mon Aug 01 11:18:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzc3V-0005Pb-V1; Mon, 01 Aug 2005 11:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzc3U-0005PP-5I for ltru@megatron.ietf.org; Mon, 01 Aug 2005 11:18:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15558 for ; Mon, 1 Aug 2005 11:18:13 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzcZm-0005LB-P7 for ltru@ietf.org; Mon, 01 Aug 2005 11:51:39 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dzc3J-0006PL-5q; Mon, 01 Aug 2005 08:18:05 -0700 Message-Id: <6.2.1.2.2.20050801131415.04ab83e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 01 Aug 2005 17:17:50 +0200 To: "L.Gillam" From: r&d afrac Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A212BC903D@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A212BC903D@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1552456100==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1552456100== Content-Type: multipart/alternative; boundary="=====================_26074623==.ALT" --=====================_26074623==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Lee, 1. I have dificulty understanding your comment. You defend a point I agree? and you do not addres the Last Call text I presented? 2. RFC 3066 mixes political, Internet standard process and standard track issues. This WG is chartered to clarify this confusion. 3. instead, the current Draft increases this confusion in adding constraints. This favors commercial dominant interests. On 12:53 01/08/2005, L.Gillam said: >Section 2.2.7 is (was) clear: > Private use subtags are used to indicate distinctions in language > important in a given context by private agreement. I could only understand we would disagree if you wanted to regulated what is the meaning of "private"? Now, nobody can prevent you from creating implementations that are going to >be incompatible with others that conform to 3066 past, present, or future. I do not know what you are talking about. There is only one RFC 3066. I am only interested in addressing the charter in correcting RFC 3066 inadequacies. >Similarly, nobody can stop you from using two letters to represent whatever >you want them to, or saying "yes" for "no". On the other hand, if you >distribute >code that is not compatible with that of others whose code conforms to 3066, ? what are you talking about? Or is it a troll? The only intent here is by the author to authors to abuse from the BCP quality of RFC 3066 to forbide more possibilities than their limitations. >isn't it at this point that *you* would be breaking the Internet? If the Draft is "the Internet" then we do not speak of the same thing. This actually boils down to this: it seems that the Internet the authors presuppose is not the one many want. Question is to know if the IETF, IESG, IAB, GAC, IANA, the WSIS Forum will endorse that. >Besides, why would you want to break compatibility with other >implementations (breaking the Internet?) with: >0-ISO.639.6:xxxx I do not see how 0- breaks compatibility with non existing implementations. >when >x-ISO-639-6-xxxx >would appear to be both conformant and sufficient? This violates the format of schemes. But, mostly this would be totally confuse. I gave examples to Doug: he gave up. You are most welcome to document how this format could support them and avoid "breaking the Internet". I am certainly deeply interested, but I do not see how this format could support the many, many language related issues overlooked by the Draft. jfc --=====================_26074623==.ALT Content-Type: text/html; charset="us-ascii" Dear Lee,
1. I have dificulty understanding your comment. You defend a point I agree? and you do not addres the Last Call text I presented?
2. RFC 3066 mixes political, Internet standard process and standard track issues. This WG is chartered to clarify this confusion.
3. instead, the current Draft increases this confusion in adding constraints. This favors commercial dominant interests.

On 12:53 01/08/2005, L.Gillam said:
Section 2.2.7 is (was) clear:
    Private use subtags are used to indicate distinctions in language
   important in a given context by private agreement. 

I could only understand we would disagree if you wanted to regulated what is the meaning of "private"?

Now, nobody can prevent you from creating implementations that are going to
be incompatible with others that conform to 3066 past, present, or future.

I do not know what you are talking about. There is only one RFC 3066. I am only interested in addressing the charter in correcting RFC 3066 inadequacies.

Similarly, nobody can stop you from using two letters to represent whatever
you want them to, or saying "yes" for "no". On the other hand, if you distribute
code that is not compatible with that of others whose code conforms to 3066,

? what are you talking about? Or is it a troll?
The only intent here is by the author to authors to abuse from the BCP quality of RFC 3066 to forbide more possibilities than their limitations.

isn't it at this point that *you* would be breaking the Internet?

If the Draft is "the Internet" then we do not speak of the same thing. This actually boils down to this: it seems that the Internet the authors  presuppose is not the one many want. Question is to know if the IETF, IESG, IAB, GAC, IANA, the WSIS Forum will endorse that.

Besides, why would you want to break compatibility with other implementations (breaking the Internet?) with:
0-ISO.639.6:xxxx

I do not see how 0- breaks compatibility with non existing implementations.

when
x-ISO-639-6-xxxx
would appear to be both conformant and sufficient?

This violates the format of schemes. But, mostly this would be totally confuse. I gave examples to Doug: he gave up. You are most welcome to document how this format could support them and avoid "breaking the Internet". I am certainly deeply interested, but I do not see how this format could support the many, many language related issues overlooked by the Draft.
jfc
--=====================_26074623==.ALT-- --===============1552456100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1552456100==-- From ltru-bounces@lists.ietf.org Tue Aug 02 05:19:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzsw0-0002Zh-5N; Tue, 02 Aug 2005 05:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzsvy-0002Ry-5K for ltru@megatron.ietf.org; Tue, 02 Aug 2005 05:19:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01988 for ; Tue, 2 Aug 2005 05:19:35 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztSP-0004QX-Ed for ltru@ietf.org; Tue, 02 Aug 2005 05:53:10 -0400 Received: from wamui-blood.atl.sa.earthlink.net ([209.86.224.28]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzsvr-0005mU-00 for ltru@ietf.org; Tue, 02 Aug 2005 05:19:31 -0400 Message-ID: <28014118.1122974371638.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 04:19:31 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: r&d afrac > Sent: Jul 28, 2005 1:05 PM > To: Doug Ewell , LTRU Working Group > Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags ... > This should only help us to find a way to make it a serious example to > illustrate a serious point. Today the only way I found is to remove > limitations on "x-" field, treating it as a normal regular escape sequence > (what does not prevent to say that if one wants to stay compatible with RFC > 3066 old format, 8alphanum MUST be used). Or to chose "0-" as an open > sequence (zero to be script independent). > > I do not see any problem and you should not either with: > > "0-language-tags.x-tags.com:singapourien.jefsey-languages.com:20051203160809A-2001:879:98F6::789C:1236" ... Disallowed by section 3.6 of the registry i-d on extensions: o The specification and all subtags defined by the specification MUST follow the ABNF and other rules for the formation of tags and subtags as defined in this document. In particular it MUST specify that case is not significant and that subtags MUST NOT exceed eight characters in length. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 05:23:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzt02-0006IA-In; Tue, 02 Aug 2005 05:23:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzt01-0006I4-1j for ltru@megatron.ietf.org; Tue, 02 Aug 2005 05:23:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02129 for ; Tue, 2 Aug 2005 05:23:46 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztWT-0004Yg-H1 for ltru@ietf.org; Tue, 02 Aug 2005 05:57:21 -0400 Received: from wamui-blood.atl.sa.earthlink.net ([209.86.224.28]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzt00-00071f-00 for ltru@ietf.org; Tue, 02 Aug 2005 05:23:48 -0400 Message-ID: <23465250.1122974628210.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 04:23:48 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] issue #1072 resolution stands X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - The discussion over the past few days makes it clear that there is still a rough consensus in the ltru WG on the resolution of issue #1072 on compatibility and its consequences for private use and extension tags. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 05:43:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztJ3-00084N-Ps; Tue, 02 Aug 2005 05:43:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztJ2-00084C-Su for ltru@megatron.ietf.org; Tue, 02 Aug 2005 05:43:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03094 for ; Tue, 2 Aug 2005 05:43:26 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztpU-0005Qm-EJ for ltru@ietf.org; Tue, 02 Aug 2005 06:17:01 -0400 Received: from wamui-blood.atl.sa.earthlink.net ([209.86.224.28]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DztJ0-0002He-00 for ltru@ietf.org; Tue, 02 Aug 2005 05:43:26 -0400 Message-ID: <13555426.1122975806439.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 04:43:26 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Minor editor clarification to initial registry abstract X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: r&d afrac > Sent: Jul 28, 2005 3:41 PM > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] Last contribution - was: Action items on draft-initial? ... > But I am afraid the one who confuses registry with "IANA only" is confused. ... To address Jefsey's concern I'd like the editor to make the following change to the initial registry internet draft: Where it currently says: This memo defines the initial contents of the Language Subtag Registry for use in forming tags for the identification of languages. Replace that text with This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. I believe this constitutes no change whatsoever regarding the ltru WG's intent, has no conceivable technical impact, and is purely editorial, intended to address a rather contrived mis-reading of the current text. If anyone objects to this change, please speak up *now* Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 05:49:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztP8-0004sp-4m; Tue, 02 Aug 2005 05:49:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztP5-0004rU-LK for ltru@megatron.ietf.org; Tue, 02 Aug 2005 05:49:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03343 for ; Tue, 2 Aug 2005 05:49:40 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztvX-0005gR-23 for ltru@ietf.org; Tue, 02 Aug 2005 06:23:16 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j729nXpX002566; Tue, 2 Aug 2005 12:49:33 +0300 (EEST) Message-ID: <42EF41AE.50408@kotus.fi> Date: Tue, 02 Aug 2005 12:49:34 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Minor editor clarification to initial registry abstract References: <13555426.1122975806439.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Fine with me, excellent, in fact! Erkki I. Kolehmainen Randy Presuhn wrote: > Hi - > > >>From: r&d afrac >>Sent: Jul 28, 2005 3:41 PM >>To: Randy Presuhn >>Cc: ltru@ietf.org >>Subject: Re: [Ltru] Last contribution - was: Action items on draft-initial? >> > ... > >>But I am afraid the one who confuses registry with "IANA only" is confused. >> > ... > > To address Jefsey's concern I'd like the editor to make the following change > to the initial registry internet draft: > > Where it currently says: > This memo defines the initial contents of the Language Subtag > Registry for use in forming tags for the identification of languages. > > Replace that text with > This memo defines the initial contents of the IANA Language Subtag > Registry for use in forming tags for the identification of languages. > > I believe this constitutes no change whatsoever regarding the ltru WG's > intent, has no conceivable technical impact, and is purely editorial, intended > to address a rather contrived mis-reading of the current text. > > If anyone objects to this change, please speak up *now* > > Randy, ltru co-chair > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 05:51:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztQt-0005oW-KN; Tue, 02 Aug 2005 05:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztQs-0005np-4K for ltru@megatron.ietf.org; Tue, 02 Aug 2005 05:51:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03386 for ; Tue, 2 Aug 2005 05:51:31 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztxK-0005lh-Dl for ltru@ietf.org; Tue, 02 Aug 2005 06:25:06 -0400 Received: from wamui-blood.atl.sa.earthlink.net ([209.86.224.28]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DztQq-0003M4-00 for ltru@ietf.org; Tue, 02 Aug 2005 05:51:32 -0400 Message-ID: <21990298.1122976292398.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 04:51:32 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: ABNF beautification... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: Doug Ewell > Sent: Jul 30, 2005 1:10 PM > To: LTRU Working Group > Subject: [Ltru] Re: ABNF beautification... > > John.Cowan wrote: > > > There remains open, however, the deep question of how (if at all) > > ISO 639-6 tags should be integrated with the RFC 3066 structure. > > Reserving a slot for 639-6's 4-alpha tags does not mean that > > incorporating them into [a successor to] RFC 3066 is necessarily the > > Right Thing. That question cannot be prejudged. > > +1 ... This is just an affirmation of what we've said all along: we can reserve syntax now in a best-guess effort to avoid needing to make any syntactic changes (consistent with what we've agree on issue #1072), so that when 639-6 comes along, *if* we do something tags derived from it, we can do so with minimal pain. Back to the primary topic of this thread, I believe we have a rough consensus in support of the "ABNF beautification", so the editors are directed to include the appropriate changes in the next i-d. I see no one bothered to enter this in the issue tracker; I'll do so just to keep the records straight. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 05:53:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztSN-0007tO-AK; Tue, 02 Aug 2005 05:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztSL-0007sS-6k for ltru@megatron.ietf.org; Tue, 02 Aug 2005 05:53:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03467 for ; Tue, 2 Aug 2005 05:53:00 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dztyl-0005nt-3J for ltru@ietf.org; Tue, 02 Aug 2005 06:26:35 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 2 Aug 2005 10:49:05 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 10:49:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text Date: Tue, 2 Aug 2005 10:49:04 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212BC9069@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text Thread-Index: AcWWrndCCMYHZfcaTI21KGvi9zDhzQAjecVw From: "L.Gillam" To: rd X-OriginalArrivalTime: 02 Aug 2005 09:49:04.0118 (UTC) FILETIME=[6ADBA960:01C59747] X-Spam-Score: 1.9 (+) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: ltru X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1258952791==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1258952791== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59747.6AD1F52E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59747.6AD1F52E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Jefsey, =20 Let us assume that: 1. You want a private set of language identifiers 2. You document this scheme=20 3. You want to remain in conformity with the current document =20 Then let's suppose 1. You use x- 2. You document that your first two fields identify your scheme because = that's what you want to do [jefsey-20050802] 3. You document that your third identifier is a 4-letter field that you = want to take from the future 639-6 standardised set [xxxx] 4. Your system looks like [x-jefsey-20050802-aaaa] 5. Your tags may consist entirely of private use subtags BUT they MUST = conform to format and content constraints defined in the ABNF. These = would seem to be fairly minimal conditions for conformity. 6. You share this document, privately, with those you want to exchange = data with =20 Now, remember that there's more than one way to skin a cat ..... some = may implement a matching algorithm by checking one field at a time and throwing away the hyphen while others split on the hyphen and deal = with the resulting fields expected each to be of max length 8 because that's what the spec says. Anything that does not contain a valid = character is incompatible. Anything that is 9 characters long? Try = putting 9 characters into an 8 character database field or char[8] and see what = happens - recall the Y2K problem. =20 Of course, if you don't care about such things, you are at liberty to do = as you wish. At this point, you are outside the spec and can't expect = existing systems to be compatible with yours.=20 =20 Now consider what a troll does.=20 =20 Please don't conflate the issue by discussing the meaning of "private", = the Charter, or the use of (XML?) schemes. =20 -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On = Behalf Of r&d afrac Sent: 01 August 2005 16:18 To: Gillam L Dr (Computing) Cc: ltru@ietf.org Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use = tags - Last Call proposed text Dear Lee, 1. I have dificulty understanding your comment. You defend a point I = agree? and you do not addres the Last Call text I presented? 2. RFC 3066 mixes political, Internet standard process and standard = track issues. This WG is chartered to clarify this confusion. 3. instead, the current Draft increases this confusion in adding = constraints. This favors commercial dominant interests. On 12:53 01/08/2005, L.Gillam said: Section 2.2.7 is (was) clear: Private use subtags are used to indicate distinctions in language important in a given context by private agreement. =20 I could only understand we would disagree if you wanted to regulated = what is the meaning of "private"? Now, nobody can prevent you from creating implementations that are going = to be incompatible with others that conform to 3066 past, present, or = future.=20 I do not know what you are talking about. There is only one RFC 3066. I = am only interested in addressing the charter in correcting RFC 3066 = inadequacies. Similarly, nobody can stop you from using two letters to represent = whatever you want them to, or saying "yes" for "no". On the other hand, if you = distribute code that is not compatible with that of others whose code conforms to = 3066, ? what are you talking about? Or is it a troll? The only intent here is by the author to authors to abuse from the BCP = quality of RFC 3066 to forbide more possibilities than their = limitations.=20 isn't it at this point that *you* would be breaking the Internet? If the Draft is "the Internet" then we do not speak of the same thing. = This actually boils down to this: it seems that the Internet the authors = presuppose is not the one many want. Question is to know if the IETF, = IESG, IAB, GAC, IANA, the WSIS Forum will endorse that. Besides, why would you want to break compatibility with other = implementations (breaking the Internet?) with:=20 0-ISO.639.6:xxxx I do not see how 0- breaks compatibility with non existing = implementations. when x-ISO-639-6-xxxx would appear to be both conformant and sufficient? This violates the format of schemes. But, mostly this would be totally = confuse. I gave examples to Doug: he gave up. You are most welcome to = document how this format could support them and avoid "breaking the = Internet". I am certainly deeply interested, but I do not see how this = format could support the many, many language related issues overlooked = by the Draft. jfc ------_=_NextPart_001_01C59747.6AD1F52E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Jefsey,
 
Let us=20 assume that:
1. You=20 want a private set of language identifiers
2. You=20 document this scheme
3. You=20 want to remain in conformity with the current = document
 
Then=20 let's suppose
1. You=20 use x-
2. You=20 document that your first two fields identify your scheme because that's = what you=20 want to do [jefsey-20050802]
3. You=20 document that your third identifier is a 4-letter field that you want to = take=20 from the future 639-6 standardised set [xxxx]
4.=20 Your system looks like [x-jefsey-20050802-aaaa]
5.=20 Your tags may consist entirely of private use subtags BUT = they MUST=20 conform to format and content constraints defined in the ABNF. These = would seem=20 to be fairly minimal conditions for conformity.
6. You=20 share this document, privately, with those you want to exchange data=20 with
 
Now,=20 remember that there's more than one way to skin a cat ..... some may = implement a=20 matching algorithm by checking one field at a time
and=20 throwing away the hyphen while others split on the hyphen = and deal with=20 the resulting fields expected each to be of max length 8=20 because
that's=20 what the spec says. Anything that does=20 not contain a valid character=20 is incompatible. Anything that is 9 characters long? Try=20 putting
9=20 characters into an 8 character database field or char[8] and see what = happens -=20 recall the Y2K problem.
 
Of=20 course, if you don't care about such things, you are at liberty to do as = you=20 wish. At this point, you are outside the spec and can't expect = existing=20 systems to be compatible with yours.
 
Now=20 consider what a troll does.
 
Please=20 don't conflate the issue by discussing the meaning of "private", the = Charter, or=20 the use of (XML?) schemes.
 
-----Original Message-----
From: = ltru-bounces@lists.ietf.org=20 [mailto:ltru-bounces@lists.ietf.org]On Behalf Of r&d=20 afrac
Sent: 01 August 2005 16:18
To: Gillam L Dr=20 (Computing)
Cc: ltru@ietf.org
Subject: RE: [Ltru] = Re:=20 [psg.com #1072] compatibility and private use tags - Last Call = proposed=20 text

Dear Lee,
1. I have dificulty = understanding your=20 comment. You defend a point I agree? and you do not addres the Last = Call text=20 I presented?
2. RFC 3066 mixes political, Internet standard process = and=20 standard track issues. This WG is chartered to clarify this = confusion.
3.=20 instead, the current Draft increases this confusion in adding = constraints.=20 This favors commercial dominant interests.

On 12:53 01/08/2005, = L.Gillam said:
Section 2.2.7 is (was) clear:
    = Private=20 use subtags are used to indicate distinctions in = language
  =20 important in a given context by private agreement.  =

I=20 could only understand we would disagree if you wanted to regulated = what is the=20 meaning of "private"?

Now, nobody=20 can prevent you from creating implementations that are going to
be incompatible with = others that=20 conform to 3066 past, present, or future.

I = do not=20 know what you are talking about. There is only one RFC 3066. I am only = interested in addressing the charter in correcting RFC 3066=20 inadequacies.

Similarly, nobody can stop you from using two letters to = represent=20 whatever
you want them to, or saying "yes" for "no". On the other = hand,=20 if you distribute
code that is not compatible with that of others = whose=20 code conforms to 3066,

? what are you talking = about? Or=20 is it a troll?
The only intent here is by the author to authors to = abuse=20 from the BCP quality of RFC 3066 to forbide more possibilities than = their=20 limitations.

isn't it at this point that *you* would be breaking the=20 Internet?

If the Draft is "the Internet" then = we do not=20 speak of the same thing. This actually boils down to this: it seems = that the=20 Internet the authors  presuppose is not the one many want. = Question is to=20 know if the IETF, IESG, IAB, GAC, IANA, the WSIS Forum will endorse=20 that.

Besides, why would you want to break compatibility with = other=20 implementations (breaking the Internet?) with:
0-ISO.639.6:xxxx

I do not see how 0- = breaks=20 compatibility with non existing implementations.

when
x-ISO-639-6-xxxx
would appear to be both conformant and=20 sufficient?

This violates the format of = schemes. But,=20 mostly this would be totally confuse. I gave examples to Doug: he gave = up. You=20 are most welcome to document how this format could support them and = avoid=20 "breaking the Internet". I am certainly deeply interested, but I do = not see=20 how this format could support the many, many language related issues=20 overlooked by the Draft.
jfc
------_=_NextPart_001_01C59747.6AD1F52E-- --===============1258952791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1258952791==-- From ltru-bounces@lists.ietf.org Tue Aug 02 06:08:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzthL-0004Rm-Hc; Tue, 02 Aug 2005 06:08:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzthJ-0004Qv-W7 for ltru@megatron.ietf.org; Tue, 02 Aug 2005 06:08:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04728 for ; Tue, 2 Aug 2005 06:08:31 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuDl-0006Z6-PN for ltru@ietf.org; Tue, 02 Aug 2005 06:42:06 -0400 Received: from wamui-blood.atl.sa.earthlink.net ([209.86.224.28]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DzthG-0005dA-00 for ltru@ietf.org; Tue, 02 Aug 2005 06:08:30 -0400 Message-ID: <16540746.1122977310783.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 05:08:30 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] [psg.com #1091] WGLC registry ABNF cleanup X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Discussion of "cleanup" of the ABNF was triggered by messages > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03032.html > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02980.html > > There was some strong support, some weak support, some > indifference, and no strong opposition, so this item is > marked "resolved". If you believe any further discussion of this topic is needed, please remember to include the issue number in you subject line. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 08:00:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvRw-0001UY-1z; Tue, 02 Aug 2005 08:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvRq-0001UB-OC for ltru@megatron.ietf.org; Tue, 02 Aug 2005 08:00:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13446 for ; Tue, 2 Aug 2005 08:00:41 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzvyK-000486-DU for ltru@ietf.org; Tue, 02 Aug 2005 08:34:16 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DzvRk-00046e-Vo; Tue, 02 Aug 2005 05:00:37 -0700 Message-Id: <6.2.1.2.2.20050802115903.03b5d7d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 Aug 2005 13:58:29 +0200 To: Randy Presuhn , ltru@ietf.org From: r&d afrac In-Reply-To: <23465250.1122974628210.JavaMail.root@wamui-blood.atl.sa.ea rthlink.net> References: <23465250.1122974628210.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Subject: [Ltru] issue #1072 Last Call text alternative over languages and Internet X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 11:23 02/08/2005, Randy Presuhn wrote: >Hi - >The discussion over the past few days makes it clear that there is still a >rough >consensus in the ltru WG on the resolution of issue #1072 on compatibility >and its consequences for private use and extension tags. [for external readers: this an exchange of the WG Last Call debate about an IETF Draft defining languages on the Internet, and by natural extension, for the entire world, starting with the Operating Systems locale files. This would result in a "language tag" only based on ISO tables for languages, script and countries. It would exclude the flexibility of including referent (dictionaries, publishers, etc.), style of usage and individual, community, trade, etc. considerations, etc. This Draft also defines a syntax for this langtag. My repeated demands that other schemes be considered or permitted, such as internationalised domain names and DNS, LDAP, computer languages, OPES, etc. and that lingual and cultural bodies are called upon for an open debate, are opposed by silence. This mail takes advantage of the Last Call where co-Chairs should establish their evaluation of a consensus on actual expressed support. The Chairs use a tracking system where point #1072 refer to a proposition I abandonned (using and extending a reduced private use namespace) after a remark by a Member. I then introduced a more general and simpler proposition (a general escape sequence using none of their format resource end permitting any scheme).] Dear Chairs, The issue #1072 should be replaced by the Last Call text I introduced two days ago. At this stage this text has been very partly commented only once, by the Member who lead to its proposition. Four minutes before your mail you also opposed it (privately or as one of the co-Chair?) on the ground it is ... not in the Draft. Oh! yes: the other co-chair _previously_ published a _private_ final position on the proposition this text replaces. At this rate of we will still be stuck into this two years from now. To go faster I propose two texts summarising both positions, so Members may commit toward a rough consensus, by more than 2 members and 2 co-Chairs. This way, no text can be claimed to be accepted by silent rough consensus. - Text A, wants both (a) to fully respect the current Draft and its enforcement through a ANA registry, (b) to fully permit the empowerment of every human individual, community, nation, Government, on their own language and culture through the schemes they want. - Text B, (a) fully respects the current Draft intent to restrict the lose and incomplete RFC 3066 framework and to provide a fomal, stable and backward compatible syntax to the "end users'" applications'(introducing the "end-user" in the IETF culture) (b) understanding and accepting the cost to pay for it. Text A: "2.2.8 Escape Sequence For compatibility with other language tags systems the "0-" singleton escape sequence if provided. It means that the "0-" singleton MUST be considered as an end of a language tag as documented by this memo. Everything following the "0-" singleton escape sequence, even after another singleton, MUST be treated as foreign to the present rules and documented registry; and as defined by another set of rules and another registry. To avoid confusion that set of rules and registry SHOULD be identified by a scheme built in using a unique identifier belonging to its registry manager, or defined by an RFC." Text B: "As a new version of BCP 47, this memo wants to etablish a final language tagging system for the whole Internet, its protocols and its user applications. It should exclude every confusion of this scheme by non conformant language identification syntax - existing, under development or planed. The private usage area ABNF has been carefully designed to contain this risk and to limit private use to a miminum. Authors understood it was at the cost of excluding every possible global alternative even by open source, competition to dominant market leaders, cultural interest, authority and communities, Governments, grassroots efforts, individuals, etc. , even confoming to or specified by other standard track documents and even if more complete or adequate. They accepted this constraint as the price to pay to warranty applications designers and their end-users the perpetual stability and the lingual identification surety they need to protect archiving retrieval, lingual interoperablity and content control and management processes." It is now to the Members to decide, in front of the Global Internet Community. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 08:16:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvdB-00025k-To; Tue, 02 Aug 2005 08:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvd9-00025d-Iq for ltru@megatron.ietf.org; Tue, 02 Aug 2005 08:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14416 for ; Tue, 2 Aug 2005 08:12:21 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzw9d-0004gW-2M for ltru@ietf.org; Tue, 02 Aug 2005 08:45:57 -0400 Received: from wamui-billy.atl.sa.earthlink.net ([209.86.224.27]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzvd7-0004fS-00 for ltru@ietf.org; Tue, 02 Aug 2005 08:12:21 -0400 Message-ID: <23243768.1122984741307.JavaMail.root@wamui-billy.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 07:12:21 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I'll record this in the tracker, and post a separate message with the assigned number. Randy -----Original Message----- From: r&d afrac Sent: Aug 2, 2005 5:31 AM To: Randy Presuhn Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags On 11:19 02/08/2005, Randy Presuhn said: > > I do not see any problem and you should not either with: > > > > > "0-language-tags.x-tags.com:singapourien.jefsey-languages.com:20051203160809A-2001:879:98F6::789C:1236" >... > >Disallowed by section 3.6 of the registry i-d on extensions: > o The specification and all subtags defined by the specification > MUST follow the ABNF and other rules for the formation of tags and > subtags as defined in this document. In particular it MUST > specify that case is not significant and that subtags MUST NOT > exceed eight characters in length. Is your co-Chair Hat on or off? Fully permitted by my standing proposition (July 30th morning your time) of the following text discussed with Lee. In case you ignore it because co-Chairs refuse to enter it in the tracking system, I repeat it here after. "2.2.8 Escape Sequence For compatibility with other language tags systems the "0-" singleton escape sequence if provided. It means that the "0-" singleton MUST be considered as an end of a language tag as documented by this memo. Everything following the "0-" singleton escape sequence, even after another singleton, MUST be treated as foreign to the present rules and documented registry; and as defined by another set of rules and another registry. To avoid confusion that set of rules and registry SHOULD be identified by a scheme built in using a unique identifier belonging to its registry manager, or defined by an RFC." jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 08:21:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvlx-0008Pw-Qf; Tue, 02 Aug 2005 08:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvlx-0008Pr-8t for ltru@megatron.ietf.org; Tue, 02 Aug 2005 08:21:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15027 for ; Tue, 2 Aug 2005 08:21:27 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzwIQ-00057N-KX for ltru@ietf.org; Tue, 02 Aug 2005 08:55:02 -0400 Received: from wamui-billy.atl.sa.earthlink.net ([209.86.224.27]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzvlv-0006xu-00 for ltru@ietf.org; Tue, 02 Aug 2005 08:21:27 -0400 Message-ID: <24732742.1122985287341.JavaMail.root@wamui-billy.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 07:21:27 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: issue #1072 Last Call text alternative over languages and Internet X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - As a technical contributor, I find both of the changes Jefsey suggests highly objectionable. I strongly prefer that make neither of the changes he proposes below. (A) would clearly contravene syntactic compatibility, and is thus not acceptable. (B) makes claims about applicability ("final language tagging system for the whole Internet") that are patently false. Randy -----Original Message----- From: r&d afrac Sent: Aug 2, 2005 6:58 AM To: Randy Presuhn , ltru@ietf.org Cc: Scott Hollenbeck Subject: issue #1072 Last Call text alternative over languages and Internet At 11:23 02/08/2005, Randy Presuhn wrote: >Hi - >The discussion over the past few days makes it clear that there is still a >rough >consensus in the ltru WG on the resolution of issue #1072 on compatibility >and its consequences for private use and extension tags. [for external readers: this an exchange of the WG Last Call debate about an IETF Draft defining languages on the Internet, and by natural extension, for the entire world, starting with the Operating Systems locale files. This would result in a "language tag" only based on ISO tables for languages, script and countries. It would exclude the flexibility of including referent (dictionaries, publishers, etc.), style of usage and individual, community, trade, etc. considerations, etc. This Draft also defines a syntax for this langtag. My repeated demands that other schemes be considered or permitted, such as internationalised domain names and DNS, LDAP, computer languages, OPES, etc. and that lingual and cultural bodies are called upon for an open debate, are opposed by silence. This mail takes advantage of the Last Call where co-Chairs should establish their evaluation of a consensus on actual expressed support. The Chairs use a tracking system where point #1072 refer to a proposition I abandonned (using and extending a reduced private use namespace) after a remark by a Member. I then introduced a more general and simpler proposition (a general escape sequence using none of their format resource end permitting any scheme).] Dear Chairs, The issue #1072 should be replaced by the Last Call text I introduced two days ago. At this stage this text has been very partly commented only once, by the Member who lead to its proposition. Four minutes before your mail you also opposed it (privately or as one of the co-Chair?) on the ground it is ... not in the Draft. Oh! yes: the other co-chair _previously_ published a _private_ final position on the proposition this text replaces. At this rate of we will still be stuck into this two years from now. To go faster I propose two texts summarising both positions, so Members may commit toward a rough consensus, by more than 2 members and 2 co-Chairs. This way, no text can be claimed to be accepted by silent rough consensus. - Text A, wants both (a) to fully respect the current Draft and its enforcement through a ANA registry, (b) to fully permit the empowerment of every human individual, community, nation, Government, on their own language and culture through the schemes they want. - Text B, (a) fully respects the current Draft intent to restrict the lose and incomplete RFC 3066 framework and to provide a fomal, stable and backward compatible syntax to the "end users'" applications'(introducing the "end-user" in the IETF culture) (b) understanding and accepting the cost to pay for it. Text A: "2.2.8 Escape Sequence For compatibility with other language tags systems the "0-" singleton escape sequence if provided. It means that the "0-" singleton MUST be considered as an end of a language tag as documented by this memo. Everything following the "0-" singleton escape sequence, even after another singleton, MUST be treated as foreign to the present rules and documented registry; and as defined by another set of rules and another registry. To avoid confusion that set of rules and registry SHOULD be identified by a scheme built in using a unique identifier belonging to its registry manager, or defined by an RFC." Text B: "As a new version of BCP 47, this memo wants to etablish a final language tagging system for the whole Internet, its protocols and its user applications. It should exclude every confusion of this scheme by non conformant language identification syntax - existing, under development or planed. The private usage area ABNF has been carefully designed to contain this risk and to limit private use to a miminum. Authors understood it was at the cost of excluding every possible global alternative even by open source, competition to dominant market leaders, cultural interest, authority and communities, Governments, grassroots efforts, individuals, etc. , even confoming to or specified by other standard track documents and even if more complete or adequate. They accepted this constraint as the price to pay to warranty applications designers and their end-users the perpetual stability and the lingual identification surety they need to protect archiving retrieval, lingual interoperablity and content control and management processes." It is now to the Members to decide, in front of the Global Internet Community. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 08:32:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvwl-0007XT-ON; Tue, 02 Aug 2005 08:32:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvwl-0007XO-4N for ltru@megatron.ietf.org; Tue, 02 Aug 2005 08:32:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15522 for ; Tue, 2 Aug 2005 08:32:36 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzwTE-0005XK-J0 for ltru@ietf.org; Tue, 02 Aug 2005 09:06:12 -0400 Received: from wamui-billy.atl.sa.earthlink.net ([209.86.224.27]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzvwj-00027K-00 for ltru@ietf.org; Tue, 02 Aug 2005 08:32:37 -0400 Message-ID: <24864460.1122985957212.JavaMail.root@wamui-billy.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 07:32:37 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - For completeness, I've added this to the tracker. ------------------------------------------------------------------------- > http://www1.ietf.org/mail-archive/web/ltru/current/msg03099.html > requests that the proposal to use 0- as an escape, introduced > in message > http://www1.ietf.org/mail-archive/web/ltru/current/msg03061.html > be given a distinct issue number. > Note that the resolution of other issues, e.g., #1072 > subsumes this issue and precludes the suggested solution. > consequently, this issue is marked as "rejected" Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 08:40:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzw4P-0005OG-74; Tue, 02 Aug 2005 08:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzw4L-0005O6-GQ for ltru@megatron.ietf.org; Tue, 02 Aug 2005 08:40:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15940 for ; Tue, 2 Aug 2005 08:40:27 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzwap-0005rn-L7 for ltru@ietf.org; Tue, 02 Aug 2005 09:14:03 -0400 Received: from wamui-billy.atl.sa.earthlink.net ([209.86.224.27]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzw4K-0004DV-00 for ltru@ietf.org; Tue, 02 Aug 2005 08:40:28 -0400 Message-ID: <28050876.1122986428205.JavaMail.root@wamui-billy.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 07:40:28 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Close of ltru WG last call on registry and initial registry drafts X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I'm happy to announce the end of the WG last call for the registry and initial registry documents. The editors are to submit updated i-ds as soon as possible. I've seen i-d announcements this week, so it looks like the secretariat is processing submissions. When the updated i-ds appear, there will be a *SHORT* second WG last call, limited in scope to ensuring that the changes agreed during the first WG last call are correctly reflected in the i-ds. If the updated i-ds appear this week, then the second WG last call will end Monday, August 8, 2005. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 08:54:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwHg-0004lL-05; Tue, 02 Aug 2005 08:54:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwHd-0004ir-5R for ltru@megatron.ietf.org; Tue, 02 Aug 2005 08:54:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16404 for ; Tue, 2 Aug 2005 08:54:11 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dzwo6-0006KA-3z for ltru@ietf.org; Tue, 02 Aug 2005 09:27:47 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 2 Aug 2005 13:53:43 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 13:53:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags Date: Tue, 2 Aug 2005 13:53:42 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212BC9073@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: [psg.com #1072] compatibility and private use tags Thread-Index: AcWXXMOgcu76ipRfTKePv5KQD366twABQlwg From: "L.Gillam" To: randy_presuhn , ltru X-OriginalArrivalTime: 02 Aug 2005 12:53:42.0254 (UTC) FILETIME=[35F110E0:01C59761] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Randy Presuhn > Sent: 02 August 2005 13:12 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use > tags [snip] > Fully permitted by my standing proposition (July 30th morning=20 > your time) of=20 > the following text discussed with Lee. If this statement is intended to imply that I am in agreement=20 with Jefsey's standing proposition, it should be withdrawn. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 08:58:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwLx-00087d-5b; Tue, 02 Aug 2005 08:58:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwLs-00086F-Fe for ltru@megatron.ietf.org; Tue, 02 Aug 2005 08:58:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16652 for ; Tue, 2 Aug 2005 08:58:32 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzwsK-0006XF-5U for ltru@ietf.org; Tue, 02 Aug 2005 09:32:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 05:58:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] issue #1072 Last Call text alternative over languages and Internet Date: Tue, 2 Aug 2005 05:58:18 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C4AB373@irvmbxw01.quest.com> Thread-Topic: [Ltru] issue #1072 Last Call text alternative over languages and Internet Thread-Index: AcWXWiwL5cXJJP4GTcaJaHrElQDGaAAB58Ww From: "Addison Phillips" To: "r&d afrac" , "Randy Presuhn" , X-OriginalArrivalTime: 02 Aug 2005 12:58:19.0224 (UTC) FILETIME=[DB075580:01C59761] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org -1 Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of r&d afrac > Sent: 2005?8?2? 4:58 > To: Randy Presuhn; ltru@ietf.org > Subject: [Ltru] issue #1072 Last Call text alternative over languages = and > Internet >=20 > At 11:23 02/08/2005, Randy Presuhn wrote: > >Hi - > >The discussion over the past few days makes it clear that there is = still > a > >rough > >consensus in the ltru WG on the resolution of issue #1072 on > compatibility > >and its consequences for private use and extension tags. >=20 > [for external readers: this an exchange of the WG Last Call debate = about > an > IETF Draft defining languages on the Internet, and by natural = extension, > for the entire world, starting with the Operating Systems locale = files. > This would result in a "language tag" only based on ISO tables for > languages, script and countries. It would exclude the flexibility of > including referent (dictionaries, publishers, etc.), style of usage = and > individual, community, trade, etc. considerations, etc. This Draft = also > defines a syntax for this langtag. My repeated demands that other = schemes > be considered or permitted, such as internationalised domain names and = DNS, > LDAP, computer languages, OPES, etc. and that lingual and cultural = bodies > are called upon for an open debate, are opposed by silence. This mail > takes > advantage of the Last Call where co-Chairs should establish their > evaluation of a consensus on actual expressed support. The Chairs use = a > tracking system where point #1072 refer to a proposition I abandonned > (using and extending a reduced private use namespace) after a remark = by a > Member. I then introduced a more general and simpler proposition (a > general > escape sequence using none of their format resource end permitting any > scheme).] >=20 > Dear Chairs, > The issue #1072 should be replaced by the Last Call text I introduced = two > days ago. At this stage this text has been very partly commented only = once, > by the Member who lead to its proposition. Four minutes before your = mail > you also opposed it (privately or as one of the co-Chair?) on the = ground > it > is ... not in the Draft. Oh! yes: the other co-chair _previously_ > published > a _private_ final position on the proposition this text replaces. >=20 > At this rate of we will still be stuck into this two years from now. = To go > faster I propose two texts summarising both positions, so Members may > commit toward a rough consensus, by more than 2 members and 2 = co-Chairs. > This way, no text can be claimed to be accepted by silent rough = consensus. >=20 > - Text A, wants both (a) to fully respect the current Draft and its > enforcement through a ANA registry, (b) to fully permit the = empowerment of > every human individual, community, nation, Government, on their own > language and culture through the schemes they want. >=20 > - Text B, (a) fully respects the current Draft intent to restrict the = lose > and incomplete RFC 3066 framework and to provide a fomal, stable and > backward compatible syntax to the "end users'" = applications'(introducing > the "end-user" in the IETF culture) (b) understanding and accepting = the > cost to pay for it. >=20 > Text A: >=20 > "2.2.8 Escape Sequence >=20 > For compatibility with other language tags systems the "0-" singleton > escape sequence if provided. It means that the "0-" singleton MUST be > considered as an end of a language tag as documented by this memo. > Everything following the "0-" singleton escape sequence, even after > another > singleton, MUST be treated as foreign to the present rules and = documented > registry; and as defined by another set of rules and another registry. = To > avoid confusion that set of rules and registry SHOULD be identified by = a > scheme built in using a unique identifier belonging to its registry > manager, or defined by an RFC." >=20 > Text B: >=20 > "As a new version of BCP 47, this memo wants to etablish a final = language > tagging system for the whole Internet, its protocols and its user > applications. It should exclude every confusion of this scheme by non > conformant language identification syntax - existing, under = development or > planed. The private usage area ABNF has been carefully designed to = contain > this risk and to limit private use to a miminum. Authors understood it = was > at the cost of excluding every possible global alternative even by = open > source, competition to dominant market leaders, cultural interest, > authority and communities, Governments, grassroots efforts, = individuals, > etc. , even confoming to or specified by other standard track = documents > and > even if more complete or adequate. They accepted this constraint as = the > price to pay to warranty applications designers and their end-users = the > perpetual stability and the lingual identification surety they need to > protect archiving retrieval, lingual interoperablity and content = control > and management processes." >=20 > It is now to the Members to decide, in front of the Global Internet > Community. > jfc >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 09:24:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwlF-00018g-7G; Tue, 02 Aug 2005 09:24:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwlD-00017H-6S for ltru@megatron.ietf.org; Tue, 02 Aug 2005 09:24:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18488 for ; Tue, 2 Aug 2005 09:24:45 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxHg-0007qj-8g for ltru@ietf.org; Tue, 02 Aug 2005 09:58:21 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j72DOhpX015594; Tue, 2 Aug 2005 16:24:43 +0300 (EEST) Message-ID: <42EF741E.6080406@kotus.fi> Date: Tue, 02 Aug 2005 16:24:46 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax References: <24864460.1122985957212.JavaMail.root@wamui-billy.atl.sa.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org As this 0- would not be understood by any current implementation to be an absolute escape sequence, which could be followed by any syntax, I'm against its inclusion in the present memo. Erkki I. Kolehmainen Randy Presuhn wrote: > Hi - > > For completeness, I've added this to the tracker. > > ------------------------------------------------------------------------- > >>http://www1.ietf.org/mail-archive/web/ltru/current/msg03099.html >>requests that the proposal to use 0- as an escape, introduced >>in message >>http://www1.ietf.org/mail-archive/web/ltru/current/msg03061.html >>be given a distinct issue number. >>Note that the resolution of other issues, e.g., #1072 >>subsumes this issue and precludes the suggested solution. >>consequently, this issue is marked as "rejected" >> > > Randy, ltru co-chair > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 09:41:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx1c-0008Lp-Gk; Tue, 02 Aug 2005 09:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx1a-0008LY-Pa for ltru@megatron.ietf.org; Tue, 02 Aug 2005 09:41:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19323 for ; Tue, 2 Aug 2005 09:41:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxY4-0008WM-1g for ltru@ietf.org; Tue, 02 Aug 2005 10:15:17 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dzx1X-0000uq-Rb; Tue, 02 Aug 2005 06:41:40 -0700 Message-Id: <6.2.1.2.2.20050802145056.03b7a260@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 Aug 2005 14:59:03 +0200 To: Randy Presuhn , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: issue #1072 Last Call text alternative over languages and Internet In-Reply-To: <24732742.1122985287341.JavaMail.root@wamui-billy.atl.sa.ea rthlink.net> References: <24732742.1122985287341.JavaMail.root@wamui-billy.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 14:21 02/08/2005, Randy Presuhn wrote: >Hi - > >As a technical contributor, I find both of the changes Jefsey suggests highly >objectionable. I strongly prefer that make neither of the changes he proposes >below. (A) would clearly contravene syntactic compatibility, and is thus >not acceptable. (B) makes claims about applicability ("final language >tagging system for the whole Internet") that are patently false. Dear Randy, This is patently untrue. The Draft wants to replace RFC 3066 as BCP 47 and as such established a final language tagging system for the whole Internet. This is the whole point of the debate for eight months now, and the reason why the Draft failed the Last Call. If you truly believe I am wrong (but then many others are wrong): 1. you simply have to have this confirmed by the IESG and IAB or use my text in replacing "wants" by "does not want". 2. I will introduce an RFC for information on the use of "0-". jfc BTW. I love all the confusion you introduced to quickly close the Last Call. Not even leaving Addison the time to oppose. :-) However, with this mail you acknowledged my proposed text before the end of the Last Call. And did not registered it! I also love that you register a Last Call text two days late, to close immediately it because you as a private contributor said you oppose :-) :). This was supposed to be the IETF .... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 09:41:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx1c-0008MD-Lx; Tue, 02 Aug 2005 09:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx1a-0008Lf-Uu for ltru@megatron.ietf.org; Tue, 02 Aug 2005 09:41:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19327 for ; Tue, 2 Aug 2005 09:41:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxY2-0008W8-PH for ltru@ietf.org; Tue, 02 Aug 2005 10:15:17 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dzx1W-0000uq-8f; Tue, 02 Aug 2005 06:41:38 -0700 Message-Id: <6.2.1.2.2.20050802140412.03cd3ca0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 Aug 2005 15:41:28 +0200 To: "L.Gillam" From: r&d afrac Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A212BC9069@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A212BC9069@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: ltru X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1346540799==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1346540799== Content-Type: multipart/alternative; boundary="=====================_25151295==.ALT" --=====================_25151295==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:49 02/08/2005, L.Gillam wrote: > Jefsey, > Let us assume that: Dear Lee, >1. You want a private set of language identifiers >2. You document this scheme >3. You want to remain in conformity with the current document I do not want to stay in conformity with the intent of the authors of the current document. I want the IETF to produce a document in conformity with users needs. Anyway we want to find the best, simplest, most stable solution. Let see if your proposition could do it. >Then let's suppose >1. You use x- You are here outside of the debate since I responded you that your point was well done, that I abandoned the claim on "x-". I introduced a text to support the "0-" escape sequence. You are just pushing for the third time a point you won. >2. You document that your first two fields identify your scheme because >that's what you want to do [jefsey-20050802] We agreed of the feasibility of that in the private use context you documented. We agreed that however that "jefsey" is not an URI and that there would be problem outside of the private context you considered and I accepted. However your point calls for a comment: there is no scalability. "jefsey" happens to be a unique name in history (except a US slave of the XIX century). Everyone cannot use a unique name of less than 8 alphanum. URI are defined by RFCs. They use dots and even @ signs. >3. You document that your third identifier is a 4-letter field that you >want to take from the future 639-6 standardised set [xxxx] >4. Your system looks like [x-jefsey-20050802-aaaa] >5. Your tags may consist entirely of private use subtags BUT they MUST >conform to format and content constraints defined in the ABNF. These would >seem to be fairly minimal conditions for conformity. No. The minimum in an IETF Best Practice is that they refer to user needs and practices. We all know two things: - Microsoft Word uses 5 descriptors for a text (language, script, country, dictionary, style) - the way RFC 3066 is nicknamed. >6. You share this document, privately, with those you want to exchange >data with. The two most important keys to an IETF document IMHO are pertinence and scalability. RFC 3066 and this Draft are for typographers not for network protocols. Do you impose limits to the scalability of my privacy? I know that you do not want to discuss "privacy" :-) >Now, remember that there's more than one way to skin a cat ..... some may >implement a matching algorithm by checking one field at a time >and throwing away the hyphen while others split on the hyphen and deal >with the resulting fields expected each to be of max length 8 because >that's what the spec says. Anything that does not contain a valid >character is incompatible. Anything that is 9 characters long? Try putting >9 characters into an 8 character database field or char[8] and see what >happens - recall the Y2K problem. Can you document why this would be of any inconvenience to me? This is precisely because it would fail that I do not care. An author using a "private" tag, is by nature only interested in those able to read it. Others can even be considered as intruders to him. Even in the case you use "x-" and you just pick the 8 _first_ letters, what is the problem? The authors have said that there could be a problem and to be careful. Let consider I filter spam on "0-jefsey.com:nav-fr" in a Navy related mailing list. If I copy you my mail, and you accept "en fr". it will fail. Great:we were not in tune, you would probably have not understood half of the words. Example: "prend le bout, embarque et tourne-le. Un coup de sifflet bref. La berloque.". > Of course, if you don't care about such things, you are at liberty to do > as you wish. No. Because for historical reasons and Internet standard process oddity, RFC 3066 has been granted the status of BCP 47. >At this point, you are outside the spec and can't expect existing systems >to be compatible with yours. Again, 1. no one I know need other schemes to be compatible with RFC 3066 libraries. 2. the Draft results in making sure that every internet language related system is not compatible with other schemes. >Now consider what a troll does. I do not think trolling is the best way to obtain response between serious people. > Please don't conflate the issue by discussing the meaning of "private", > the Charter, or the use of (XML?) schemes. "private" is necessary. As are necessary languages, script, regions. I would think you know better what a scheme than asking "xml?". The debate is not in this. The debate is in technical exclusion for commercial or political reasons, or not. I respect the commercial reasons but I do not think IETF must be ruled by commercial motivations (RFC 3869 and open competition). I can understand the political reasons, but then all the concerned parties must be consulted. In some other places this is named democracy. In IETF this is named efficiency. All the best. jfc , > >-----Original Message----- >From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On >Behalf Of r&d afrac >Sent: 01 August 2005 16:18 >To: Gillam L Dr (Computing) >Cc: ltru@ietf.org >Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags >- Last Call proposed text > >Dear Lee, >1. I have dificulty understanding your comment. You defend a point I >agree? and you do not addres the Last Call text I presented? >2. RFC 3066 mixes political, Internet standard process and standard track >issues. This WG is chartered to clarify this confusion. >3. instead, the current Draft increases this confusion in adding >constraints. This favors commercial dominant interests. > >On 12:53 01/08/2005, L.Gillam said: >>Section 2.2.7 is (was) clear: >> Private use subtags are used to indicate distinctions in language >> important in a given context by private agreement. > >I could only understand we would disagree if you wanted to regulated what >is the meaning of "private"? > >Now, nobody can prevent you from creating implementations that are going to >>be incompatible with others that conform to 3066 past, present, or future. > >I do not know what you are talking about. There is only one RFC 3066. I am >only interested in addressing the charter in correcting RFC 3066 inadequacies. > >>Similarly, nobody can stop you from using two letters to represent whatever >>you want them to, or saying "yes" for "no". On the other hand, if you >>distribute >>code that is not compatible with that of others whose code conforms to 3066, > >? what are you talking about? Or is it a troll? >The only intent here is by the author to authors to abuse from the BCP >quality of RFC 3066 to forbide more possibilities than their limitations. > >>isn't it at this point that *you* would be breaking the Internet? > >If the Draft is "the Internet" then we do not speak of the same thing. >This actually boils down to this: it seems that the Internet the >authors presuppose is not the one many want. Question is to know if the >IETF, IESG, IAB, GAC, IANA, the WSIS Forum will endorse that. > >>Besides, why would you want to break compatibility with other >>implementations (breaking the Internet?) with: >>0-ISO.639.6:xxxx > >I do not see how 0- breaks compatibility with non existing implementations. > >>when >>x-ISO-639-6-xxxx >>would appear to be both conformant and sufficient? > >This violates the format of schemes. But, mostly this would be totally >confuse. I gave examples to Doug: he gave up. You are most welcome to >document how this format could support them and avoid "breaking the >Internet". I am certainly deeply interested, but I do not see how this >format could support the many, many language related issues overlooked by >the Draft. >jfc --=====================_25151295==.ALT Content-Type: text/html; charset="us-ascii" At 11:49 02/08/2005, L.Gillam wrote:
 Jefsey,
 Let us assume that:

Dear Lee,

1. You want a private set of language identifiers
2. You document this scheme
3. You want to remain in conformity with the current document

I do not want to stay in conformity with the intent of the authors of the current document. I want the IETF to produce a document in conformity with users needs. Anyway we want to find the best, simplest, most stable solution. Let see if your proposition could do it.

Then let's suppose
1. You use x-

You are here outside of the debate since I responded you that your point was well done, that I abandoned the claim on "x-". I introduced a text to support the "0-" escape sequence. You are just pushing for the third time a point you won.

2. You document that your first two fields identify your scheme because that's what you want to do [jefsey-20050802]

We agreed of the feasibility of that in the private use context you documented. We agreed that however that "jefsey" is not an URI and that there would be problem outside of the private context you considered and I accepted.

However your point calls for a comment: there is no scalability. "jefsey" happens to be a unique name in history (except a US slave of the XIX century). Everyone cannot use a unique name of less than 8 alphanum. URI are defined by RFCs. They use dots and even @ signs.

3. You document that your third identifier is a 4-letter field that you want to take from the future 639-6 standardised set [xxxx]
4. Your system looks like [x-jefsey-20050802-aaaa]
5. Your tags may consist entirely of private use subtags BUT they MUST conform to format and content constraints defined in the ABNF. These would seem to be fairly minimal conditions for conformity.

No. The minimum in an IETF Best Practice is that they refer to user needs and practices. We all know two things:
- Microsoft Word uses 5 descriptors for a text (language, script, country, dictionary, style)
- the way RFC 3066 is nicknamed.

6. You share this document, privately, with those you want to exchange data with.

The two most important keys to an IETF document IMHO are pertinence and scalability. RFC 3066 and this Draft are for typographers not for network protocols. Do you impose limits to the scalability of my privacy? I know that you do not want to discuss "privacy" :-)

Now, remember that there's more than one way to skin a cat ..... some may implement a matching algorithm by checking one field at a time
and throwing away the hyphen while others split on the hyphen and deal with the resulting fields expected each to be of max length 8 because
that's what the spec says. Anything that does not contain a valid character is incompatible. Anything that is 9 characters long? Try putting
9 characters into an 8 character database field or char[8] and see what happens - recall the Y2K problem.

Can you document why this would be of any inconvenience to me?

This is precisely because it would fail that I do not care. An author using a "private" tag, is by nature only interested in those able to read it. Others can even be considered as intruders to him. Even in the case you use "x-" and you just pick the 8 _first_ letters, what is the problem? The authors have said that there could be a problem and to be careful.

Let consider I filter spam on "0-jefsey.com:nav-fr" in a Navy related mailing list. If I copy you my mail, and you accept "en fr". it will fail. Great:we were not in tune, you would probably have not understood half of the words. Example: "prend le bout, embarque et tourne-le. Un coup de sifflet bref. La berloque.".

 Of course, if you don't care about such things, you are at liberty to do as you wish.

No. Because for historical reasons and Internet standard process oddity, RFC 3066 has been granted the status of BCP 47.

At this point, you are outside the spec and can't expect existing systems to be compatible with yours.

Again,
1. no one I know need other schemes to be compatible with RFC 3066 libraries.
2. the Draft results in making sure that every internet language related system is not compatible with other schemes.

Now consider what a troll does.

I do not think trolling is the best way to obtain response between serious people.

 Please don't conflate the issue by discussing the meaning of "private", the Charter, or the use of (XML?) schemes.

"private" is necessary. As are necessary languages, script, regions. I would think you know better what a scheme than asking "xml?". The debate is not in this. The debate is in technical exclusion for commercial or political reasons, or not. I respect the commercial reasons but I do not think IETF must be ruled by commercial motivations (RFC 3869 and open competition). I can understand the political reasons, but then all the concerned parties must be consulted. In some other places this is named democracy. In IETF this is named efficiency.

All the best.
jfc












,

 
-----Original Message-----
From: ltru-bounces@lists.ietf.org [ mailto:ltru-bounces@lists.ietf.org]On Behalf Of r&d afrac
Sent: 01 August 2005 16:18
To: Gillam L Dr (Computing)
Cc: ltru@ietf.org
Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text
Dear Lee,
1. I have dificulty understanding your comment. You defend a point I agree? and you do not addres the Last Call text I presented?
2. RFC 3066 mixes political, Internet standard process and standard track issues. This WG is chartered to clarify this confusion.
3. instead, the current Draft increases this confusion in adding constraints. This favors commercial dominant interests.

On 12:53 01/08/2005, L.Gillam said:
Section 2.2.7 is (was) clear:
    Private use subtags are used to indicate distinctions in language
   important in a given context by private agreement. 

I could only understand we would disagree if you wanted to regulated what is the meaning of "private"?

Now, nobody can prevent you from creating implementations that are going to
be incompatible with others that conform to 3066 past, present, or future.

I do not know what you are talking about. There is only one RFC 3066. I am only interested in addressing the charter in correcting RFC 3066 inadequacies.

Similarly, nobody can stop you from using two letters to represent whatever
you want them to, or saying "yes" for "no". On the other hand, if you distribute
code that is not compatible with that of others whose code conforms to 3066,

? what are you talking about? Or is it a troll?
The only intent here is by the author to authors to abuse from the BCP quality of RFC 3066 to forbide more possibilities than their limitations.

isn't it at this point that *you* would be breaking the Internet?

If the Draft is "the Internet" then we do not speak of the same thing. This actually boils down to this: it seems that the Internet the authors  presuppose is not the one many want. Question is to know if the IETF, IESG, IAB, GAC, IANA, the WSIS Forum will endorse that.

Besides, why would you want to break compatibility with other implementations (breaking the Internet?) with:
0-ISO.639.6:xxxx

I do not see how 0- breaks compatibility with non existing implementations.

when
x-ISO-639-6-xxxx
would appear to be both conformant and sufficient?

This violates the format of schemes. But, mostly this would be totally confuse. I gave examples to Doug: he gave up. You are most welcome to document how this format could support them and avoid "breaking the Internet". I am certainly deeply interested, but I do not see how this format could support the many, many language related issues overlooked by the Draft.
jfc
--=====================_25151295==.ALT-- --===============1346540799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1346540799==-- From ltru-bounces@lists.ietf.org Tue Aug 02 10:19:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxUR-0006sW-78; Tue, 02 Aug 2005 10:11:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxUQ-0006sQ-6A for ltru@megatron.ietf.org; Tue, 02 Aug 2005 10:11:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21597 for ; Tue, 2 Aug 2005 10:11:27 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzy0t-0001NO-VW for ltru@ietf.org; Tue, 02 Aug 2005 10:45:05 -0400 Received: from wamui-bichon.atl.sa.earthlink.net ([209.86.224.26]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DzxUB-0004CB-00 for ltru@ietf.org; Tue, 02 Aug 2005 10:11:15 -0400 Message-ID: <22558519.1122991875047.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 09:11:14 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: issue #1072 Last Call text alternative over languages and Internet Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > Sent: Aug 2, 2005 7:59 AM > To: Randy Presuhn , ltru@ietf.org > Cc: scott Hollenbeck > Subject: Re: [Ltru] Re: issue #1072 Last Call text alternative over languages and Internet > > At 14:21 02/08/2005, Randy Presuhn wrote: > >Hi - > > > >As a technical contributor, I find both of the changes Jefsey suggests highly > >objectionable. I strongly prefer that make neither of the changes he proposes > >below. (A) would clearly contravene syntactic compatibility, and is thus > >not acceptable. (B) makes claims about applicability ("final language > >tagging system for the whole Internet") that are patently false. > > Dear Randy, > This is patently untrue. The Draft wants to replace RFC 3066 as BCP 47 and > as such established a final language tagging system for the whole Internet. "a" is ok. "final" is clearly wrong. "for the whole Internet" is both true and false, depending on whether one undestands it as meaning "with potential for application in a wide variety of places" or as "the sole such system permitted anywhere in the internet." Your original wording seemed to be intended in the latter sense. If you meant the former, I don't see why you're spending so much time whining. > This is the whole point of the debate for eight months now, and the reason > why the Draft failed the Last Call. You may have more insight into the IESG's decision than I. > If you truly believe I am wrong (but then many others are wrong): > 1. you simply have to have this confirmed by the IESG and IAB or use my > text in replacing "wants" by "does not want". Even if either version would be a sensible sentence (attributing volition to a document is semantically bizarre), it's not an either-or proposition. > 2. I will introduce an RFC for information on the use of "0-". Cool. This would be a more constructive way to introduce the capabilities you desire. ... > BTW. I love all the confusion you introduced to quickly close the Last > Call. Not even leaving Addison the time to oppose. :-) However, with this > mail you acknowledged my proposed text before the end of the Last Call. And > did not registered it! I also love that you register a Last Call text two > days late, to close immediately it because you as a private contributor > said you oppose :-) :). ... Nothing requires that issues be entered in the tracker, and certainly nothing requires that they be entered there before they can be discussed. It's just a tool to make tracking easier. The fact that some of us have lives outside the IETF means that work sometimes gets "batched". Deal with it. If you think any of your proposals had consensus support in the WG and that this support was not reflected in the i-ds, please bring the specific agreed text to our attention so we can ensure the documents are updated correctly. Fortunately, this WG has been remarkably clear in expressing its preferences, so any items that were overlooked should be easily corrected. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 10:34:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxqw-0006Fl-S5; Tue, 02 Aug 2005 10:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxqt-0006FI-1N for ltru@megatron.ietf.org; Tue, 02 Aug 2005 10:34:43 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24426 for ; Tue, 2 Aug 2005 10:34:40 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050802143401.ZTBN29002.mta9.adelphia.net@DEWELL> for ; Tue, 2 Aug 2005 10:34:01 -0400 Message-ID: <005701c5976f$1153dd40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050802095555.ZMHI3015.mta3.adelphia.net@megatron.ietf.org> Date: Tue, 2 Aug 2005 07:32:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Minor editor clarification to initial registry abstract X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > To address Jefsey's concern I'd like the editor to make the following > change to the initial registry internet draft: > > Where it currently says: > This memo defines the initial contents of the Language Subtag > Registry for use in forming tags for the identification of > languages. > > Replace that text with > This memo defines the initial contents of the IANA Language Subtag > Registry for use in forming tags for the identification of > languages. I've made the requested change, both in the abstract and in the related sentence in the introduction, and will submit draft-initial-03 in a few minutes. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 10:41:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxxJ-0005If-UE; Tue, 02 Aug 2005 10:41:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxxH-0005Du-Ul for ltru@megatron.ietf.org; Tue, 02 Aug 2005 10:41:20 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24966 for ; Tue, 2 Aug 2005 10:41:15 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050802144038.WZAV19267.mta10.adelphia.net@DEWELL>; Tue, 2 Aug 2005 10:40:38 -0400 Message-ID: <006601c5976f$f74fe6e0$030aa8c0@DEWELL> From: "Doug Ewell" To: Date: Tue, 2 Aug 2005 07:39:18 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0063_01C59735.4A27A460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Cc: LTRU Working Group Subject: [Ltru] Submission: LTRU initial-registry draft-03 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C59735.4A27A460 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear Editor, Attached please find the fourth draft of the LTRU initial-registry document, "draft-ietf-ltru-initial-03", in text format. This draft was generated from XML source using xml2rfc, and has been scanned with idnits. Best regards, -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ------=_NextPart_000_0063_01C59735.4A27A460 Content-Type: text/plain; name="draft-ietf-ltru-initial-03.txt" Content-Disposition: attachment; filename="draft-ietf-ltru-initial-03.txt" Content-Transfer-Encoding: quoted-printable LTRU D. Ewell, Ed. Internet-Draft August 2, 2005 Expires: February 3, 2006 Initial Language Subtag Registry draft-ietf-ltru-initial-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 3, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. Ewell Expires February 3, 2006 [Page 1] =0C Internet-Draft Initial Language Subtag Registry August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Initialization of the Registry . . . . . . . . . . . . . . . 4 3. Initial Registry Contents . . . . . . . . . . . . . . . . . 7 4. Omitted Code Elements . . . . . . . . . . . . . . . . . . . 113 5. Security Considerations . . . . . . . . . . . . . . . . . . 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.1 Normative References . . . . . . . . . . . . . . . . . . 116 7.2 Informative References . . . . . . . . . . . . . . . . . 116 Author's Address . . . . . . . . . . . . . . . . . . . . . . 117 Intellectual Property and Copyright Statements . . . . . . . 118 Ewell Expires February 3, 2006 [Page 2] =0C Internet-Draft Initial Language Subtag Registry August 2005 1. Introduction [I-D.ietf-ltru-registry] provides for a Language Subtag Registry and describes its format. This memo defines the initial contents of the IANA Language Subtag Registry, using the criteria described in Section 2. The Language Subtag Registry is formatted in a modified record-jar text format, as described in [record-jar]. The specific format of the registry, and the definition and intended purpose of each of the fields, are described in [I-D.ietf-ltru-registry]. The registry is expected to change over time, as new subtags are registered and existing subtags are modified or deprecated. The process of updating the registry is described in Section 3 of [I-D.ietf-ltru-registry]. This memo does not define the permanent contents of the registry and should not be represented as doing so. Many of the subtags defined in this registry are based on code elements defined in [ISO639-1], [ISO639-2], [ISO15924], [ISO3166-1], and [UN_M.49]. This registry is not a mirror of the code lists defined by these standards, and should not be used as one. Ewell Expires February 3, 2006 [Page 3] =0C Internet-Draft Initial Language Subtag Registry August 2005 2. Initialization of the Registry Section 3.7 of [I-D.ietf-ltru-registry] requires that the LTRU working group create an initial version of the Language Subtag Registry and populate it with the initial set of subtags. This involves converting the entries from the existing IANA language tag registry defined by [RFC3066] to the new format, as well as defining valid subtags from various source standards. This section describes the process that was used to create the initial registry entries. The initial set of records was based on the following standards: [ISO639-1], [ISO639-2], [ISO15924], and [ISO3166-1]. The following criteria were used to select and format the records of the subtags included in the initial Language Subtag Registry (hereafter "ILSR"): 1. For each source standard, the date of the standard referenced in [RFC1766] was selected as the starting date. Code elements that were valid on that date in the selected standard were added to the ILSR. Code elements that were previously assigned, but which were vacated or withdrawn before that date, were not added to the ILSR. 2. For each successive change to the standard, any additional assignments up to the date of the adoption of [I-D.ietf-ltru- registry] were added to the ILSR. Values that have been withdrawn are marked as deprecated, but not removed. Changes in meaning or assignment of a subtag were permitted during this process (for example, the [ISO3166-1] code element 'CS' was originally assigned to Czechoslovakia and is now assigned to Serbia and Montenegro). Code elements from [UN_M.49] were also included in the ILSR using the criteria above, with the following additional rules: 3. UN numeric code elements assigned to "macro-geographical (continental)" regions as of the date of adoption of [I-D.ietf- ltru-registry] were added to the ILSR and thereby made valid for use in language tags. 4. The UN numeric code elements for "economic groupings" or "other groupings," and the alphanumeric code elements in Appendix X of the UN document, were not added to the ILSR. 5. The UN numeric code elements for countries or areas not associated with an assigned [ISO3166-1] alpha-2 code element were not added to the ILSR. These values are listed in Section 4 and may be requested for registration by individuals using the process defined in [I-D.ietf-ltru-registry] and according to the rules described therein. Listing of these code elements in this section Ewell Expires February 3, 2006 [Page 4] =0C Internet-Draft Initial Language Subtag Registry August 2005 is not a guarantee of future registration. 6. Code elements that were withdrawn, vacated, or deprecated from [UN_M.49] as of the date of adoption of [I-D.ietf-ltru-registry] were not added to the ILSR. Using the initial set of subtags described above, the tags in the [RFC3066] registry were evaluated as follows: 7. Tags in the [RFC3066] registry that were not deprecated, consisted entirely of subtags already in this document, and have the correct form and format for tags defined by [I-D.ietf-ltru- registry] were converted to records of type "redundant" in the ILSR. For example, "zh-Hant" is now defined by [I-D.ietf-ltru- registry] because 'zh' is an [ISO639-1] code element and 'Hant' is an [ISO15924] code element, and both are defined as subtags in the ILSR. 8. Tags in the [RFC3066] registry that contained one or more subtags that either did not match the valid registration pattern or were not otherwise defined by [I-D.ietf-ltru-registry] were converted to corresponding records of type "grandfathered" in the ILSR. These records cannot become type "redundant" except by revision of [I-D.ietf-ltru-registry], but may have a "Deprecated" and "Preferred-Value" field added to them if a subsequent subtag assignment or combination of assignments renders the tag obsolete. 9. Tags in the [RFC3066] registry that had a notation that they were deprecated were converted to records of type "grandfathered" in the ILSR. The record for the grandfathered entry contains a "Deprecated" field with the most appropriate date that can be determined for when the [RFC3066] record was deprecated. The "Comments" field may optionally contain a reason for the deprecation. The "Preferred-Value" field contains a tag that replaces the value. For example, the [RFC3066] tag "art-lojban" is deprecated and thus appears as a grandfathered tag in the ILSR. Its "Deprecated" field contains the deprecation date (in this case "2003-09-02") and the "Preferred-Value" field the value "jbo". 10. The remaining tags in the [RFC3066] registry are not deprecated and have a format consistent with language tags as defined by [I-D.ietf-ltru-registry] but contain subtags which are not defined in the ILSR. These subtags are eligible for registration as variants. The ILSR contains appropriate variant records for the following list of subtags, and the registered [RFC3066] tags containing these subtags were entered into the ILSR as type "redundant": Ewell Expires February 3, 2006 [Page 5] =0C Internet-Draft Initial Language Subtag Registry August 2005 1901 (use with Prefix: de) 1996 (use with Prefix: de) nedis (use with Prefix: sl) rozaj (use with Prefix: sl) 11. All remaining [RFC3066] registered tags were converted to records of type "grandfathered" in the ILSR. Interested parties may use the registration process in [I-D.ietf-ltru-registry] to attempt to register the variant subtags not already present in the Language Subtag Registry. If all of the subtags in the original tag become fully defined by the resulting registrations, then the original tag is superseded. Such tags will have their record changed from type "grandfathered" to type "redundant" in the registry. Note that previous approval of a tag under [RFC3066] is not a guarantee of approval of a variant subtag under [I-D.ietf- ltru-registry]. The existing [RFC3066] tag maintains its validity, but the original reason for its registration might have become obsolete. Ewell Expires February 3, 2006 [Page 6] =0C Internet-Draft Initial Language Subtag Registry August 2005 3. Initial Registry Contents The initial Language Subtag Registry follows. The registry begins with the line that starts with the string "File-Date" and continues to the end of this section. Headers, footers, line breaks, and other vertical whitespace introduced by the RFC process are not significant. Leading horizontal whitespace relative to the "File- Date" line indicates a continued line in the record-jar format, and must not be deleted. File-Date: 2005-08-02 %% Type: language Subtag: aa Description: Afar Added: 2005-08-02 %% Type: language Subtag: ab Description: Abkhazian Added: 2005-08-02 Suppress-Script: Cyrl %% Type: language Subtag: ae Description: Avestan Added: 2005-08-02 %% Type: language Subtag: af Description: Afrikaans Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ak Description: Akan Added: 2005-08-02 %% Type: language Subtag: am Description: Amharic Added: 2005-08-02 Suppress-Script: Ethi %% Type: language Subtag: an Description: Aragonese Ewell Expires February 3, 2006 [Page 7] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: language Subtag: ar Description: Arabic Added: 2005-08-02 Suppress-Script: Arab %% Type: language Subtag: as Description: Assamese Added: 2005-08-02 Suppress-Script: Beng %% Type: language Subtag: av Description: Avaric Added: 2005-08-02 %% Type: language Subtag: ay Description: Aymara Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: az Description: Azerbaijani Added: 2005-08-02 %% Type: language Subtag: ba Description: Bashkir Added: 2005-08-02 %% Type: language Subtag: be Description: Belarusian Added: 2005-08-02 Suppress-Script: Cyrl %% Type: language Subtag: bg Description: Bulgarian Added: 2005-08-02 Suppress-Script: Cyrl %% Type: language Ewell Expires February 3, 2006 [Page 8] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: bh Description: Bihari Added: 2005-08-02 %% Type: language Subtag: bi Description: Bislama Added: 2005-08-02 %% Type: language Subtag: bm Description: Bambara Added: 2005-08-02 %% Type: language Subtag: bn Description: Bengali Added: 2005-08-02 Suppress-Script: Beng %% Type: language Subtag: bo Description: Tibetan Added: 2005-08-02 %% Type: language Subtag: br Description: Breton Added: 2005-08-02 %% Type: language Subtag: bs Description: Bosnian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ca Description: Catalan Description: Valencian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ce Description: Chechen Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 9] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: ch Description: Chamorro Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: co Description: Corsican Added: 2005-08-02 %% Type: language Subtag: cr Description: Cree Added: 2005-08-02 %% Type: language Subtag: cs Description: Czech Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: cu Description: Church Slavic Description: Old Slavonic Description: Church Slavonic Description: Old Bulgarian Description: Old Church Slavonic Added: 2005-08-02 %% Type: language Subtag: cv Description: Chuvash Added: 2005-08-02 %% Type: language Subtag: cy Description: Welsh Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: da Description: Danish Added: 2005-08-02 Suppress-Script: Latn %% Ewell Expires February 3, 2006 [Page 10] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: de Description: German Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: dv Description: Divehi Added: 2005-08-02 Suppress-Script: Thaa %% Type: language Subtag: dz Description: Dzongkha Added: 2005-08-02 Suppress-Script: Tibt %% Type: language Subtag: ee Description: Ewe Added: 2005-08-02 %% Type: language Subtag: el Description: Greek, Modern (1453-) Added: 2005-08-02 Suppress-Script: Grek %% Type: language Subtag: en Description: English Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: eo Description: Esperanto Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: es Description: Spanish Description: Castilian Added: 2005-08-02 Suppress-Script: Latn %% Ewell Expires February 3, 2006 [Page 11] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: et Description: Estonian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: eu Description: Basque Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: fa Description: Persian Added: 2005-08-02 Suppress-Script: Arab %% Type: language Subtag: ff Description: Fulah Added: 2005-08-02 %% Type: language Subtag: fi Description: Finnish Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: fj Description: Fijian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: fo Description: Faroese Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: fr Description: French Added: 2005-08-02 Suppress-Script: Latn %% Type: language Ewell Expires February 3, 2006 [Page 12] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: fy Description: Frisian Added: 2005-08-02 %% Type: language Subtag: ga Description: Irish Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: gd Description: Gaelic Description: Scottish Gaelic Added: 2005-08-02 %% Type: language Subtag: gl Description: Galician Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: gn Description: Guarani Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: gu Description: Gujarati Added: 2005-08-02 Suppress-Script: Gujr %% Type: language Subtag: gv Description: Manx Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ha Description: Hausa Added: 2005-08-02 %% Type: language Subtag: he Description: Hebrew Ewell Expires February 3, 2006 [Page 13] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 Suppress-Script: Hebr %% Type: language Subtag: hi Description: Hindi Added: 2005-08-02 Suppress-Script: Deva %% Type: language Subtag: ho Description: Hiri Motu Added: 2005-08-02 %% Type: language Subtag: hr Description: Croatian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ht Description: Haitian Description: Haitian Creole Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: hu Description: Hungarian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: hy Description: Armenian Added: 2005-08-02 Suppress-Script: Armn %% Type: language Subtag: hz Description: Herero Added: 2005-08-02 %% Type: language Subtag: ia Description: Interlingua (International Auxiliary Language Association) Ewell Expires February 3, 2006 [Page 14] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: language Subtag: id Description: Indonesian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ie Description: Interlingue Added: 2005-08-02 %% Type: language Subtag: ig Description: Igbo Added: 2005-08-02 %% Type: language Subtag: ii Description: Sichuan Yi Added: 2005-08-02 %% Type: language Subtag: ik Description: Inupiaq Added: 2005-08-02 %% Type: language Subtag: in Description: Indonesian Added: 2005-08-02 Preferred-Value: id Deprecated: 1989-01-01 Suppress-Script: Latn %% Type: language Subtag: io Description: Ido Added: 2005-08-02 %% Type: language Subtag: is Description: Icelandic Added: 2005-08-02 Suppress-Script: Latn %% Type: language Ewell Expires February 3, 2006 [Page 15] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: it Description: Italian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: iu Description: Inuktitut Added: 2005-08-02 %% Type: language Subtag: iw Description: Hebrew Added: 2005-08-02 Preferred-Value: he Deprecated: 1989-01-01 Suppress-Script: Hebr %% Type: language Subtag: ja Description: Japanese Added: 2005-08-02 %% Type: language Subtag: ji Description: Yiddish Added: 2005-08-02 Preferred-Value: yi Deprecated: 1989-01-01 %% Type: language Subtag: jv Description: Javanese Added: 2005-08-02 %% Type: language Subtag: jw Description: Javanese Added: 2005-08-02 Preferred-Value: jv Deprecated: 2001-08-13 Comments: published by error in Table 1 of ISO 639:1988 %% Type: language Subtag: ka Description: Georgian Added: 2005-08-02 Suppress-Script: Geor Ewell Expires February 3, 2006 [Page 16] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: kg Description: Kongo Added: 2005-08-02 %% Type: language Subtag: ki Description: Kikuyu Description: Gikuyu Added: 2005-08-02 %% Type: language Subtag: kj Description: Kuanyama Description: Kwanyama Added: 2005-08-02 %% Type: language Subtag: kk Description: Kazakh Added: 2005-08-02 Suppress-Script: Cyrl %% Type: language Subtag: kl Description: Kalaallisut Description: Greenlandic Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: km Description: Khmer Added: 2005-08-02 Suppress-Script: Khmr %% Type: language Subtag: kn Description: Kannada Added: 2005-08-02 Suppress-Script: Knda %% Type: language Subtag: ko Description: Korean Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 17] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: kr Description: Kanuri Added: 2005-08-02 %% Type: language Subtag: ks Description: Kashmiri Added: 2005-08-02 %% Type: language Subtag: ku Description: Kurdish Added: 2005-08-02 %% Type: language Subtag: kv Description: Komi Added: 2005-08-02 %% Type: language Subtag: kw Description: Cornish Added: 2005-08-02 %% Type: language Subtag: ky Description: Kirghiz Added: 2005-08-02 %% Type: language Subtag: la Description: Latin Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: lb Description: Luxembourgish Description: Letzeburgesch Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: lg Description: Ganda Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 18] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: li Description: Limburgan Description: Limburger Description: Limburgish Added: 2005-08-02 %% Type: language Subtag: ln Description: Lingala Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: lo Description: Lao Added: 2005-08-02 Suppress-Script: Laoo %% Type: language Subtag: lt Description: Lithuanian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: lu Description: Luba-Katanga Added: 2005-08-02 %% Type: language Subtag: lv Description: Latvian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: mg Description: Malagasy Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: mh Description: Marshallese Added: 2005-08-02 Suppress-Script: Latn %% Ewell Expires February 3, 2006 [Page 19] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: mi Description: Maori Added: 2005-08-02 %% Type: language Subtag: mk Description: Macedonian Added: 2005-08-02 Suppress-Script: Cyrl %% Type: language Subtag: ml Description: Malayalam Added: 2005-08-02 Suppress-Script: Mlym %% Type: language Subtag: mn Description: Mongolian Added: 2005-08-02 %% Type: language Subtag: mo Description: Moldavian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: mr Description: Marathi Added: 2005-08-02 Suppress-Script: Deva %% Type: language Subtag: ms Description: Malay Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: mt Description: Maltese Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: my Ewell Expires February 3, 2006 [Page 20] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Burmese Added: 2005-08-02 Suppress-Script: Mymr %% Type: language Subtag: na Description: Nauru Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: nb Description: Norwegian Bokmål Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: nd Description: Ndebele, North Description: North Ndebele Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ne Description: Nepali Added: 2005-08-02 Suppress-Script: Deva %% Type: language Subtag: ng Description: Ndonga Added: 2005-08-02 %% Type: language Subtag: nl Description: Dutch Description: Flemish Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: nn Description: Norwegian Nynorsk Added: 2005-08-02 Suppress-Script: Latn %% Type: language Ewell Expires February 3, 2006 [Page 21] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: no Description: Norwegian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: nr Description: Ndebele, South Description: South Ndebele Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: nv Description: Navajo Description: Navaho Added: 2005-08-02 %% Type: language Subtag: ny Description: Chichewa Description: Chewa Description: Nyanja Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: oc Description: Occitan (post 1500) Description: Provençal Added: 2005-08-02 %% Type: language Subtag: oj Description: Ojibwa Added: 2005-08-02 %% Type: language Subtag: om Description: Oromo Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: or Description: Oriya Added: 2005-08-02 Suppress-Script: Orya Ewell Expires February 3, 2006 [Page 22] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: os Description: Ossetian Description: Ossetic Added: 2005-08-02 %% Type: language Subtag: pa Description: Panjabi Description: Punjabi Added: 2005-08-02 Suppress-Script: Guru %% Type: language Subtag: pi Description: Pali Added: 2005-08-02 %% Type: language Subtag: pl Description: Polish Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ps Description: Pushto Added: 2005-08-02 Suppress-Script: Arab %% Type: language Subtag: pt Description: Portuguese Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: qu Description: Quechua Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: rm Description: Raeto-Romance Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 23] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: rn Description: Rundi Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ro Description: Romanian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ru Description: Russian Added: 2005-08-02 Suppress-Script: Cyrl %% Type: language Subtag: rw Description: Kinyarwanda Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: sa Description: Sanskrit Added: 2005-08-02 %% Type: language Subtag: sc Description: Sardinian Added: 2005-08-02 %% Type: language Subtag: sd Description: Sindhi Added: 2005-08-02 %% Type: language Subtag: se Description: Northern Sami Added: 2005-08-02 %% Type: language Subtag: sg Description: Sango Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 24] =0C Internet-Draft Initial Language Subtag Registry August 2005 Suppress-Script: Latn %% Type: language Subtag: sh Description: Serbo-Croatian Added: 2005-08-02 Deprecated: 2000-02-18 %% Type: language Subtag: si Description: Sinhala Description: Sinhalese Added: 2005-08-02 Suppress-Script: Sinh %% Type: language Subtag: sk Description: Slovak Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: sl Description: Slovenian Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: sm Description: Samoan Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: sn Description: Shona Added: 2005-08-02 %% Type: language Subtag: so Description: Somali Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: sq Description: Albanian Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 25] =0C Internet-Draft Initial Language Subtag Registry August 2005 Suppress-Script: Latn %% Type: language Subtag: sr Description: Serbian Added: 2005-08-02 %% Type: language Subtag: ss Description: Swati Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: st Description: Sotho, Southern Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: su Description: Sundanese Added: 2005-08-02 %% Type: language Subtag: sv Description: Swedish Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: sw Description: Swahili Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ta Description: Tamil Added: 2005-08-02 Suppress-Script: Taml %% Type: language Subtag: te Description: Telugu Added: 2005-08-02 Suppress-Script: Telu %% Ewell Expires February 3, 2006 [Page 26] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: tg Description: Tajik Added: 2005-08-02 %% Type: language Subtag: th Description: Thai Added: 2005-08-02 Suppress-Script: Thai %% Type: language Subtag: ti Description: Tigrinya Added: 2005-08-02 Suppress-Script: Ethi %% Type: language Subtag: tk Description: Turkmen Added: 2005-08-02 %% Type: language Subtag: tl Description: Tagalog Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: tn Description: Tswana Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: to Description: Tonga (Tonga Islands) Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: tr Description: Turkish Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ts Ewell Expires February 3, 2006 [Page 27] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Tsonga Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: tt Description: Tatar Added: 2005-08-02 %% Type: language Subtag: tw Description: Twi Added: 2005-08-02 %% Type: language Subtag: ty Description: Tahitian Added: 2005-08-02 %% Type: language Subtag: ug Description: Uighur Description: Uyghur Added: 2005-08-02 %% Type: language Subtag: uk Description: Ukrainian Added: 2005-08-02 Suppress-Script: Cyrl %% Type: language Subtag: ur Description: Urdu Added: 2005-08-02 Suppress-Script: Arab %% Type: language Subtag: uz Description: Uzbek Added: 2005-08-02 %% Type: language Subtag: ve Description: Venda Added: 2005-08-02 Suppress-Script: Latn %% Ewell Expires February 3, 2006 [Page 28] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: vi Description: Vietnamese Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: vo Description: Volapük Added: 2005-08-02 %% Type: language Subtag: wa Description: Walloon Added: 2005-08-02 %% Type: language Subtag: wo Description: Wolof Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: xh Description: Xhosa Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: yi Description: Yiddish Added: 2005-08-02 Suppress-Script: Hebr %% Type: language Subtag: yo Description: Yoruba Added: 2005-08-02 %% Type: language Subtag: za Description: Zhuang Description: Chuang Added: 2005-08-02 %% Type: language Subtag: zh Description: Chinese Ewell Expires February 3, 2006 [Page 29] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: language Subtag: zu Description: Zulu Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ace Description: Achinese Added: 2005-08-02 %% Type: language Subtag: ach Description: Acoli Added: 2005-08-02 %% Type: language Subtag: ada Description: Adangme Added: 2005-08-02 %% Type: language Subtag: ady Description: Adyghe Description: Adygei Added: 2005-08-02 %% Type: language Subtag: afa Description: Afro-Asiatic (Other) Added: 2005-08-02 %% Type: language Subtag: afh Description: Afrihili Added: 2005-08-02 %% Type: language Subtag: akk Description: Akkadian Added: 2005-08-02 %% Type: language Subtag: ale Description: Aleut Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 30] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: alg Description: Algonquian languages Added: 2005-08-02 %% Type: language Subtag: alt Description: Southern Altai Added: 2005-08-02 %% Type: language Subtag: ang Description: English, Old (ca. 450-1100) Added: 2005-08-02 %% Type: language Subtag: apa Description: Apache languages Added: 2005-08-02 %% Type: language Subtag: arc Description: Aramaic Added: 2005-08-02 %% Type: language Subtag: arn Description: Araucanian Added: 2005-08-02 %% Type: language Subtag: arp Description: Arapaho Added: 2005-08-02 %% Type: language Subtag: art Description: Artificial (Other) Added: 2005-08-02 %% Type: language Subtag: arw Description: Arawak Added: 2005-08-02 %% Type: language Subtag: ast Ewell Expires February 3, 2006 [Page 31] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Asturian Description: Bable Added: 2005-08-02 %% Type: language Subtag: ath Description: Athapascan languages Added: 2005-08-02 %% Type: language Subtag: aus Description: Australian languages Added: 2005-08-02 %% Type: language Subtag: awa Description: Awadhi Added: 2005-08-02 %% Type: language Subtag: bad Description: Banda Added: 2005-08-02 %% Type: language Subtag: bai Description: Bamileke languages Added: 2005-08-02 %% Type: language Subtag: bal Description: Baluchi Added: 2005-08-02 %% Type: language Subtag: ban Description: Balinese Added: 2005-08-02 %% Type: language Subtag: bas Description: Basa Added: 2005-08-02 %% Type: language Subtag: bat Description: Baltic (Other) Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 32] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: bej Description: Beja Added: 2005-08-02 %% Type: language Subtag: bem Description: Bemba Added: 2005-08-02 %% Type: language Subtag: ber Description: Berber (Other) Added: 2005-08-02 %% Type: language Subtag: bho Description: Bhojpuri Added: 2005-08-02 %% Type: language Subtag: bik Description: Bikol Added: 2005-08-02 %% Type: language Subtag: bin Description: Bini Added: 2005-08-02 %% Type: language Subtag: bla Description: Siksika Added: 2005-08-02 %% Type: language Subtag: bnt Description: Bantu (Other) Added: 2005-08-02 %% Type: language Subtag: bra Description: Braj Added: 2005-08-02 %% Type: language Subtag: btk Ewell Expires February 3, 2006 [Page 33] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Batak (Indonesia) Added: 2005-08-02 %% Type: language Subtag: bua Description: Buriat Added: 2005-08-02 %% Type: language Subtag: bug Description: Buginese Added: 2005-08-02 %% Type: language Subtag: byn Description: Blin Description: Bilin Added: 2005-08-02 %% Type: language Subtag: cad Description: Caddo Added: 2005-08-02 %% Type: language Subtag: cai Description: Central American Indian (Other) Added: 2005-08-02 %% Type: language Subtag: car Description: Carib Added: 2005-08-02 %% Type: language Subtag: cau Description: Caucasian (Other) Added: 2005-08-02 %% Type: language Subtag: ceb Description: Cebuano Added: 2005-08-02 %% Type: language Subtag: cel Description: Celtic (Other) Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 34] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: chb Description: Chibcha Added: 2005-08-02 %% Type: language Subtag: chg Description: Chagatai Added: 2005-08-02 %% Type: language Subtag: chk Description: Chuukese Added: 2005-08-02 %% Type: language Subtag: chm Description: Mari Added: 2005-08-02 %% Type: language Subtag: chn Description: Chinook jargon Added: 2005-08-02 %% Type: language Subtag: cho Description: Choctaw Added: 2005-08-02 %% Type: language Subtag: chp Description: Chipewyan Added: 2005-08-02 %% Type: language Subtag: chr Description: Cherokee Added: 2005-08-02 %% Type: language Subtag: chy Description: Cheyenne Added: 2005-08-02 %% Type: language Subtag: cmc Ewell Expires February 3, 2006 [Page 35] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Chamic languages Added: 2005-08-02 %% Type: language Subtag: cop Description: Coptic Added: 2005-08-02 %% Type: language Subtag: cpe Description: Creoles and pidgins, English-based (Other) Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: cpf Description: Creoles and pidgins, French-based (Other) Added: 2005-08-02 %% Type: language Subtag: cpp Description: Creoles and pidgins, Portuguese-based (Other) Added: 2005-08-02 %% Type: language Subtag: crh Description: Crimean Tatar Description: Crimean Turkish Added: 2005-08-02 %% Type: language Subtag: crp Description: Creoles and pidgins (Other) Added: 2005-08-02 %% Type: language Subtag: csb Description: Kashubian Added: 2005-08-02 %% Type: language Subtag: cus Description: Cushitic (Other) Added: 2005-08-02 %% Type: language Subtag: dak Description: Dakota Ewell Expires February 3, 2006 [Page 36] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: language Subtag: dar Description: Dargwa Added: 2005-08-02 %% Type: language Subtag: day Description: Dayak Added: 2005-08-02 %% Type: language Subtag: del Description: Delaware Added: 2005-08-02 %% Type: language Subtag: den Description: Slave (Athapascan) Added: 2005-08-02 %% Type: language Subtag: dgr Description: Dogrib Added: 2005-08-02 %% Type: language Subtag: din Description: Dinka Added: 2005-08-02 %% Type: language Subtag: doi Description: Dogri Added: 2005-08-02 %% Type: language Subtag: dra Description: Dravidian (Other) Added: 2005-08-02 %% Type: language Subtag: dsb Description: Lower Sorbian Added: 2005-08-02 %% Type: language Ewell Expires February 3, 2006 [Page 37] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: dua Description: Duala Added: 2005-08-02 %% Type: language Subtag: dum Description: Dutch, Middle (ca. 1050-1350) Added: 2005-08-02 %% Type: language Subtag: dyu Description: Dyula Added: 2005-08-02 %% Type: language Subtag: efi Description: Efik Added: 2005-08-02 %% Type: language Subtag: egy Description: Egyptian (Ancient) Added: 2005-08-02 %% Type: language Subtag: eka Description: Ekajuk Added: 2005-08-02 %% Type: language Subtag: elx Description: Elamite Added: 2005-08-02 %% Type: language Subtag: enm Description: English, Middle (1100-1500) Added: 2005-08-02 %% Type: language Subtag: ewo Description: Ewondo Added: 2005-08-02 %% Type: language Subtag: fan Description: Fang Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 38] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: fat Description: Fanti Added: 2005-08-02 %% Type: language Subtag: fil Description: Filipino Description: Pilipino Added: 2005-08-02 %% Type: language Subtag: fiu Description: Finno-Ugrian (Other) Added: 2005-08-02 %% Type: language Subtag: fon Description: Fon Added: 2005-08-02 %% Type: language Subtag: frm Description: French, Middle (ca. 1400-1600) Added: 2005-08-02 %% Type: language Subtag: fro Description: French, Old (842-ca. 1400) Added: 2005-08-02 %% Type: language Subtag: fur Description: Friulian Added: 2005-08-02 %% Type: language Subtag: gaa Description: Ga Added: 2005-08-02 %% Type: language Subtag: gay Description: Gayo Added: 2005-08-02 %% Type: language Ewell Expires February 3, 2006 [Page 39] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: gba Description: Gbaya Added: 2005-08-02 %% Type: language Subtag: gem Description: Germanic (Other) Added: 2005-08-02 %% Type: language Subtag: gez Description: Geez Added: 2005-08-02 %% Type: language Subtag: gil Description: Gilbertese Added: 2005-08-02 %% Type: language Subtag: gmh Description: German, Middle High (ca. 1050-1500) Added: 2005-08-02 %% Type: language Subtag: goh Description: German, Old High (ca. 750-1050) Added: 2005-08-02 %% Type: language Subtag: gon Description: Gondi Added: 2005-08-02 %% Type: language Subtag: gor Description: Gorontalo Added: 2005-08-02 %% Type: language Subtag: got Description: Gothic Added: 2005-08-02 %% Type: language Subtag: grb Description: Grebo Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 40] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: grc Description: Greek, Ancient (to 1453) Added: 2005-08-02 %% Type: language Subtag: gwi Description: Gwich´in Added: 2005-08-02 %% Type: language Subtag: hai Description: Haida Added: 2005-08-02 %% Type: language Subtag: haw Description: Hawaiian Added: 2005-08-02 %% Type: language Subtag: hil Description: Hiligaynon Added: 2005-08-02 %% Type: language Subtag: him Description: Himachali Added: 2005-08-02 %% Type: language Subtag: hit Description: Hittite Added: 2005-08-02 %% Type: language Subtag: hmn Description: Hmong Added: 2005-08-02 %% Type: language Subtag: hsb Description: Upper Sorbian Added: 2005-08-02 %% Type: language Subtag: hup Ewell Expires February 3, 2006 [Page 41] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Hupa Added: 2005-08-02 %% Type: language Subtag: iba Description: Iban Added: 2005-08-02 %% Type: language Subtag: ijo Description: Ijo Added: 2005-08-02 %% Type: language Subtag: ilo Description: Iloko Added: 2005-08-02 %% Type: language Subtag: inc Description: Indic (Other) Added: 2005-08-02 %% Type: language Subtag: ine Description: Indo-European (Other) Added: 2005-08-02 %% Type: language Subtag: inh Description: Ingush Added: 2005-08-02 %% Type: language Subtag: ira Description: Iranian (Other) Added: 2005-08-02 %% Type: language Subtag: iro Description: Iroquoian languages Added: 2005-08-02 %% Type: language Subtag: jbo Description: Lojban Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 42] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: jpr Description: Judeo-Persian Added: 2005-08-02 %% Type: language Subtag: jrb Description: Judeo-Arabic Added: 2005-08-02 %% Type: language Subtag: kaa Description: Kara-Kalpak Added: 2005-08-02 %% Type: language Subtag: kab Description: Kabyle Added: 2005-08-02 %% Type: language Subtag: kac Description: Kachin Added: 2005-08-02 %% Type: language Subtag: kam Description: Kamba Added: 2005-08-02 %% Type: language Subtag: kar Description: Karen Added: 2005-08-02 %% Type: language Subtag: kaw Description: Kawi Added: 2005-08-02 %% Type: language Subtag: kbd Description: Kabardian Added: 2005-08-02 %% Type: language Subtag: kha Description: Khasi Ewell Expires February 3, 2006 [Page 43] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: language Subtag: khi Description: Khoisan (Other) Added: 2005-08-02 %% Type: language Subtag: kho Description: Khotanese Added: 2005-08-02 %% Type: language Subtag: kmb Description: Kimbundu Added: 2005-08-02 %% Type: language Subtag: kok Description: Konkani Added: 2005-08-02 Suppress-Script: Deva %% Type: language Subtag: kos Description: Kosraean Added: 2005-08-02 %% Type: language Subtag: kpe Description: Kpelle Added: 2005-08-02 %% Type: language Subtag: krc Description: Karachay-Balkar Added: 2005-08-02 %% Type: language Subtag: kro Description: Kru Added: 2005-08-02 %% Type: language Subtag: kru Description: Kurukh Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 44] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: kum Description: Kumyk Added: 2005-08-02 %% Type: language Subtag: kut Description: Kutenai Added: 2005-08-02 %% Type: language Subtag: lad Description: Ladino Added: 2005-08-02 %% Type: language Subtag: lah Description: Lahnda Added: 2005-08-02 %% Type: language Subtag: lam Description: Lamba Added: 2005-08-02 %% Type: language Subtag: lez Description: Lezghian Added: 2005-08-02 %% Type: language Subtag: lol Description: Mongo Added: 2005-08-02 %% Type: language Subtag: loz Description: Lozi Added: 2005-08-02 %% Type: language Subtag: lua Description: Luba-Lulua Added: 2005-08-02 %% Type: language Subtag: lui Description: Luiseno Ewell Expires February 3, 2006 [Page 45] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: language Subtag: lun Description: Lunda Added: 2005-08-02 %% Type: language Subtag: luo Description: Luo (Kenya and Tanzania) Added: 2005-08-02 %% Type: language Subtag: lus Description: Lushai Added: 2005-08-02 %% Type: language Subtag: mad Description: Madurese Added: 2005-08-02 %% Type: language Subtag: mag Description: Magahi Added: 2005-08-02 %% Type: language Subtag: mai Description: Maithili Added: 2005-08-02 Suppress-Script: Deva %% Type: language Subtag: mak Description: Makasar Added: 2005-08-02 %% Type: language Subtag: man Description: Mandingo Added: 2005-08-02 %% Type: language Subtag: map Description: Austronesian (Other) Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 46] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: mas Description: Masai Added: 2005-08-02 %% Type: language Subtag: mdf Description: Moksha Added: 2005-08-02 %% Type: language Subtag: mdr Description: Mandar Added: 2005-08-02 %% Type: language Subtag: men Description: Mende Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: mga Description: Irish, Middle (900-1200) Added: 2005-08-02 %% Type: language Subtag: mic Description: Mi'kmaq Description: Micmac Added: 2005-08-02 %% Type: language Subtag: min Description: Minangkabau Added: 2005-08-02 %% Type: language Subtag: mis Description: Miscellaneous languages Added: 2005-08-02 %% Type: language Subtag: mkh Description: Mon-Khmer (Other) Added: 2005-08-02 %% Type: language Ewell Expires February 3, 2006 [Page 47] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: mnc Description: Manchu Added: 2005-08-02 %% Type: language Subtag: mni Description: Manipuri Added: 2005-08-02 %% Type: language Subtag: mno Description: Manobo languages Added: 2005-08-02 %% Type: language Subtag: moh Description: Mohawk Added: 2005-08-02 %% Type: language Subtag: mos Description: Mossi Added: 2005-08-02 %% Type: language Subtag: mul Description: Multiple languages Added: 2005-08-02 %% Type: language Subtag: mun Description: Munda languages Added: 2005-08-02 %% Type: language Subtag: mus Description: Creek Added: 2005-08-02 %% Type: language Subtag: mwl Description: Mirandese Added: 2005-08-02 %% Type: language Subtag: mwr Description: Marwari Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 48] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: myn Description: Mayan languages Added: 2005-08-02 %% Type: language Subtag: myv Description: Erzya Added: 2005-08-02 %% Type: language Subtag: nah Description: Nahuatl Added: 2005-08-02 %% Type: language Subtag: nai Description: North American Indian Added: 2005-08-02 %% Type: language Subtag: nap Description: Neapolitan Added: 2005-08-02 %% Type: language Subtag: nds Description: Low German Description: Low Saxon Description: German, Low Description: Saxon, Low Added: 2005-08-02 %% Type: language Subtag: new Description: Nepal Bhasa Description: Newari Added: 2005-08-02 %% Type: language Subtag: nia Description: Nias Added: 2005-08-02 %% Type: language Subtag: nic Description: Niger-Kordofanian (Other) Ewell Expires February 3, 2006 [Page 49] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: language Subtag: niu Description: Niuean Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: nog Description: Nogai Added: 2005-08-02 %% Type: language Subtag: non Description: Norse, Old Added: 2005-08-02 %% Type: language Subtag: nso Description: Northern Sotho Description: Pedi Description: Sepedi Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: nub Description: Nubian languages Added: 2005-08-02 %% Type: language Subtag: nwc Description: Classical Newari Description: Old Newari Description: Classical Nepal Bhasa Added: 2005-08-02 %% Type: language Subtag: nym Description: Nyamwezi Added: 2005-08-02 %% Type: language Subtag: nyn Description: Nyankole Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 50] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: nyo Description: Nyoro Added: 2005-08-02 %% Type: language Subtag: nzi Description: Nzima Added: 2005-08-02 %% Type: language Subtag: osa Description: Osage Added: 2005-08-02 %% Type: language Subtag: ota Description: Turkish, Ottoman (1500-1928) Added: 2005-08-02 %% Type: language Subtag: oto Description: Otomian languages Added: 2005-08-02 %% Type: language Subtag: paa Description: Papuan (Other) Added: 2005-08-02 %% Type: language Subtag: pag Description: Pangasinan Added: 2005-08-02 %% Type: language Subtag: pal Description: Pahlavi Added: 2005-08-02 %% Type: language Subtag: pam Description: Pampanga Added: 2005-08-02 %% Type: language Subtag: pap Description: Papiamento Ewell Expires February 3, 2006 [Page 51] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: language Subtag: pau Description: Palauan Added: 2005-08-02 %% Type: language Subtag: peo Description: Persian, Old (ca. 600-400 B.C.) Added: 2005-08-02 %% Type: language Subtag: phi Description: Philippine (Other) Added: 2005-08-02 %% Type: language Subtag: phn Description: Phoenician Added: 2005-08-02 %% Type: language Subtag: pon Description: Pohnpeian Added: 2005-08-02 %% Type: language Subtag: pra Description: Prakrit languages Added: 2005-08-02 %% Type: language Subtag: pro Description: Provençal, Old (to 1500) Added: 2005-08-02 %% Type: language Subtag: qaa..qtz Description: PRIVATE USE Added: 2005-08-02 %% Type: language Subtag: raj Description: Rajasthani Added: 2005-08-02 %% Type: language Ewell Expires February 3, 2006 [Page 52] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: rap Description: Rapanui Added: 2005-08-02 %% Type: language Subtag: rar Description: Rarotongan Added: 2005-08-02 %% Type: language Subtag: roa Description: Romance (Other) Added: 2005-08-02 %% Type: language Subtag: rom Description: Romany Added: 2005-08-02 %% Type: language Subtag: sad Description: Sandawe Added: 2005-08-02 %% Type: language Subtag: sah Description: Yakut Added: 2005-08-02 %% Type: language Subtag: sai Description: South American Indian (Other) Added: 2005-08-02 %% Type: language Subtag: sal Description: Salishan languages Added: 2005-08-02 %% Type: language Subtag: sam Description: Samaritan Aramaic Added: 2005-08-02 %% Type: language Subtag: sas Description: Sasak Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 53] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: sat Description: Santali Added: 2005-08-02 %% Type: language Subtag: scn Description: Sicilian Added: 2005-08-02 %% Type: language Subtag: sco Description: Scots Added: 2005-08-02 %% Type: language Subtag: sel Description: Selkup Added: 2005-08-02 %% Type: language Subtag: sem Description: Semitic (Other) Added: 2005-08-02 %% Type: language Subtag: sga Description: Irish, Old (to 900) Added: 2005-08-02 %% Type: language Subtag: sgn Description: Sign Languages Added: 2005-08-02 %% Type: language Subtag: shn Description: Shan Added: 2005-08-02 %% Type: language Subtag: sid Description: Sidamo Added: 2005-08-02 %% Type: language Subtag: sio Ewell Expires February 3, 2006 [Page 54] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Siouan languages Added: 2005-08-02 %% Type: language Subtag: sit Description: Sino-Tibetan (Other) Added: 2005-08-02 %% Type: language Subtag: sla Description: Slavic (Other) Added: 2005-08-02 %% Type: language Subtag: sma Description: Southern Sami Added: 2005-08-02 %% Type: language Subtag: smi Description: Sami languages (Other) Added: 2005-08-02 %% Type: language Subtag: smj Description: Lule Sami Added: 2005-08-02 %% Type: language Subtag: smn Description: Inari Sami Added: 2005-08-02 %% Type: language Subtag: sms Description: Skolt Sami Added: 2005-08-02 %% Type: language Subtag: snk Description: Soninke Added: 2005-08-02 %% Type: language Subtag: sog Description: Sogdian Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 55] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: son Description: Songhai Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: srn Description: Sranan Tongo Added: 2005-08-02 %% Type: language Subtag: srr Description: Serer Added: 2005-08-02 %% Type: language Subtag: ssa Description: Nilo-Saharan (Other) Added: 2005-08-02 %% Type: language Subtag: suk Description: Sukuma Added: 2005-08-02 %% Type: language Subtag: sus Description: Susu Added: 2005-08-02 %% Type: language Subtag: sux Description: Sumerian Added: 2005-08-02 %% Type: language Subtag: syr Description: Syriac Added: 2005-08-02 %% Type: language Subtag: tai Description: Tai (Other) Added: 2005-08-02 %% Type: language Subtag: tem Ewell Expires February 3, 2006 [Page 56] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Timne Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: ter Description: Tereno Added: 2005-08-02 %% Type: language Subtag: tet Description: Tetum Added: 2005-08-02 %% Type: language Subtag: tig Description: Tigre Added: 2005-08-02 %% Type: language Subtag: tiv Description: Tiv Added: 2005-08-02 %% Type: language Subtag: tkl Description: Tokelau Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: tlh Description: Klingon Description: tlhIngan-Hol Added: 2005-08-02 %% Type: language Subtag: tli Description: Tlingit Added: 2005-08-02 %% Type: language Subtag: tmh Description: Tamashek Added: 2005-08-02 Suppress-Script: Latn %% Type: language Ewell Expires February 3, 2006 [Page 57] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: tog Description: Tonga (Nyasa) Added: 2005-08-02 %% Type: language Subtag: tpi Description: Tok Pisin Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: tsi Description: Tsimshian Added: 2005-08-02 %% Type: language Subtag: tum Description: Tumbuka Added: 2005-08-02 %% Type: language Subtag: tup Description: Tupi languages Added: 2005-08-02 %% Type: language Subtag: tut Description: Altaic (Other) Added: 2005-08-02 %% Type: language Subtag: tvl Description: Tuvalu Added: 2005-08-02 Suppress-Script: Latn %% Type: language Subtag: tyv Description: Tuvinian Added: 2005-08-02 %% Type: language Subtag: udm Description: Udmurt Added: 2005-08-02 %% Type: language Subtag: uga Ewell Expires February 3, 2006 [Page 58] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Ugaritic Added: 2005-08-02 %% Type: language Subtag: umb Description: Umbundu Added: 2005-08-02 %% Type: language Subtag: und Description: Undetermined Added: 2005-08-02 %% Type: language Subtag: vai Description: Vai Added: 2005-08-02 %% Type: language Subtag: vot Description: Votic Added: 2005-08-02 %% Type: language Subtag: wak Description: Wakashan languages Added: 2005-08-02 %% Type: language Subtag: wal Description: Walamo Added: 2005-08-02 %% Type: language Subtag: war Description: Waray Added: 2005-08-02 %% Type: language Subtag: was Description: Washo Added: 2005-08-02 %% Type: language Subtag: wen Description: Sorbian languages Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 59] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: xal Description: Kalmyk Description: Oirat Added: 2005-08-02 %% Type: language Subtag: yao Description: Yao Added: 2005-08-02 %% Type: language Subtag: yap Description: Yapese Added: 2005-08-02 %% Type: language Subtag: ypk Description: Yupik languages Added: 2005-08-02 %% Type: language Subtag: zap Description: Zapotec Added: 2005-08-02 %% Type: language Subtag: zen Description: Zenaga Added: 2005-08-02 %% Type: language Subtag: znd Description: Zande Added: 2005-08-02 %% Type: language Subtag: zun Description: Zuni Added: 2005-08-02 %% Type: script Subtag: Arab Description: Arabic Added: 2005-08-02 %% Type: script Subtag: Armn Ewell Expires February 3, 2006 [Page 60] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Armenian Added: 2005-08-02 %% Type: script Subtag: Bali Description: Balinese Added: 2005-08-02 %% Type: script Subtag: Batk Description: Batak Added: 2005-08-02 %% Type: script Subtag: Beng Description: Bengali Added: 2005-08-02 %% Type: script Subtag: Blis Description: Blissymbols Added: 2005-08-02 %% Type: script Subtag: Bopo Description: Bopomofo Added: 2005-08-02 %% Type: script Subtag: Brah Description: Brahmi Added: 2005-08-02 %% Type: script Subtag: Brai Description: Braille Added: 2005-08-02 %% Type: script Subtag: Bugi Description: Buginese Added: 2005-08-02 %% Type: script Subtag: Buhd Description: Buhid Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 61] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: script Subtag: Cans Description: Unified Canadian Aboriginal Syllabics Added: 2005-08-02 %% Type: script Subtag: Cham Description: Cham Added: 2005-08-02 %% Type: script Subtag: Cher Description: Cherokee Added: 2005-08-02 %% Type: script Subtag: Cirt Description: Cirth Added: 2005-08-02 %% Type: script Subtag: Copt Description: Coptic Added: 2005-08-02 %% Type: script Subtag: Cprt Description: Cypriot Added: 2005-08-02 %% Type: script Subtag: Cyrl Description: Cyrillic Added: 2005-08-02 %% Type: script Subtag: Cyrs Description: Cyrillic (Old Church Slavonic variant) Added: 2005-08-02 %% Type: script Subtag: Deva Description: Devanagari (Nagari) Added: 2005-08-02 %% Type: script Subtag: Dsrt Description: Deseret (Mormon) Ewell Expires February 3, 2006 [Page 62] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: script Subtag: Egyd Description: Egyptian demotic Added: 2005-08-02 %% Type: script Subtag: Egyh Description: Egyptian hieratic Added: 2005-08-02 %% Type: script Subtag: Egyp Description: Egyptian hieroglyphs Added: 2005-08-02 %% Type: script Subtag: Ethi Description: Ethiopic (Ge‘ez) Added: 2005-08-02 %% Type: script Subtag: Geok Description: Khutsuri (Asomtavruli and Nuskhuri) Added: 2005-08-02 %% Type: script Subtag: Geor Description: Georgian (Mkhedruli) Added: 2005-08-02 %% Type: script Subtag: Glag Description: Glagolitic Added: 2005-08-02 %% Type: script Subtag: Goth Description: Gothic Added: 2005-08-02 %% Type: script Subtag: Grek Description: Greek Added: 2005-08-02 %% Type: script Ewell Expires February 3, 2006 [Page 63] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: Gujr Description: Gujarati Added: 2005-08-02 %% Type: script Subtag: Guru Description: Gurmukhi Added: 2005-08-02 %% Type: script Subtag: Hang Description: Hangul (Hangŭl, Hangeul) Added: 2005-08-02 %% Type: script Subtag: Hani Description: Han (Hanzi, Kanji, Hanja) Added: 2005-08-02 %% Type: script Subtag: Hano Description: Hanunoo (Hanunóo) Added: 2005-08-02 %% Type: script Subtag: Hans Description: Han (Simplified variant) Added: 2005-08-02 %% Type: script Subtag: Hant Description: Han (Traditional variant) Added: 2005-08-02 %% Type: script Subtag: Hebr Description: Hebrew Added: 2005-08-02 %% Type: script Subtag: Hira Description: Hiragana Added: 2005-08-02 %% Type: script Subtag: Hmng Description: Pahawh Hmong Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 64] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: script Subtag: Hrkt Description: (alias for Hiragana + Katakana) Added: 2005-08-02 %% Type: script Subtag: Hung Description: Old Hungarian Added: 2005-08-02 %% Type: script Subtag: Inds Description: Indus (Harappan) Added: 2005-08-02 %% Type: script Subtag: Ital Description: Old Italic (Etruscan, Oscan, etc.) Added: 2005-08-02 %% Type: script Subtag: Java Description: Javanese Added: 2005-08-02 %% Type: script Subtag: Kali Description: Kayah Li Added: 2005-08-02 %% Type: script Subtag: Kana Description: Katakana Added: 2005-08-02 %% Type: script Subtag: Khar Description: Kharoshthi Added: 2005-08-02 %% Type: script Subtag: Khmr Description: Khmer Added: 2005-08-02 %% Type: script Subtag: Knda Ewell Expires February 3, 2006 [Page 65] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Kannada Added: 2005-08-02 %% Type: script Subtag: Laoo Description: Lao Added: 2005-08-02 %% Type: script Subtag: Latf Description: Latin (Fraktur variant) Added: 2005-08-02 %% Type: script Subtag: Latg Description: Latin (Gaelic variant) Added: 2005-08-02 %% Type: script Subtag: Latn Description: Latin Added: 2005-08-02 %% Type: script Subtag: Lepc Description: Lepcha (Róng) Added: 2005-08-02 %% Type: script Subtag: Limb Description: Limbu Added: 2005-08-02 %% Type: script Subtag: Lina Description: Linear A Added: 2005-08-02 %% Type: script Subtag: Linb Description: Linear B Added: 2005-08-02 %% Type: script Subtag: Mand Description: Mandaean Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 66] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: script Subtag: Maya Description: Mayan hieroglyphs Added: 2005-08-02 %% Type: script Subtag: Mero Description: Meroitic Added: 2005-08-02 %% Type: script Subtag: Mlym Description: Malayalam Added: 2005-08-02 %% Type: script Subtag: Mong Description: Mongolian Added: 2005-08-02 %% Type: script Subtag: Mymr Description: Myanmar (Burmese) Added: 2005-08-02 %% Type: script Subtag: Nkoo Description: N’Ko Added: 2005-08-02 %% Type: script Subtag: Ogam Description: Ogham Added: 2005-08-02 %% Type: script Subtag: Orkh Description: Orkhon Added: 2005-08-02 %% Type: script Subtag: Orya Description: Oriya Added: 2005-08-02 %% Type: script Subtag: Osma Description: Osmanya Ewell Expires February 3, 2006 [Page 67] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: script Subtag: Perm Description: Old Permic Added: 2005-08-02 %% Type: script Subtag: Phag Description: Phags-pa Added: 2005-08-02 %% Type: script Subtag: Phnx Description: Phoenician Added: 2005-08-02 %% Type: script Subtag: Plrd Description: Pollard Phonetic Added: 2005-08-02 %% Type: script Subtag: Qaaa..Qabx Description: PRIVATE USE Added: 2005-08-02 %% Type: script Subtag: Roro Description: Rongorongo Added: 2005-08-02 %% Type: script Subtag: Runr Description: Runic Added: 2005-08-02 %% Type: script Subtag: Sara Description: Sarati Added: 2005-08-02 %% Type: script Subtag: Shaw Description: Shavian (Shaw) Added: 2005-08-02 %% Type: script Ewell Expires February 3, 2006 [Page 68] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: Sinh Description: Sinhala Added: 2005-08-02 %% Type: script Subtag: Sylo Description: Syloti Nagri Added: 2005-08-02 %% Type: script Subtag: Syrc Description: Syriac Added: 2005-08-02 %% Type: script Subtag: Syre Description: Syriac (Estrangelo variant) Added: 2005-08-02 %% Type: script Subtag: Syrj Description: Syriac (Western variant) Added: 2005-08-02 %% Type: script Subtag: Syrn Description: Syriac (Eastern variant) Added: 2005-08-02 %% Type: script Subtag: Tagb Description: Tagbanwa Added: 2005-08-02 %% Type: script Subtag: Tale Description: Tai Le Added: 2005-08-02 %% Type: script Subtag: Talu Description: New Tai Lue Added: 2005-08-02 %% Type: script Subtag: Taml Description: Tamil Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 69] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: script Subtag: Telu Description: Telugu Added: 2005-08-02 %% Type: script Subtag: Teng Description: Tengwar Added: 2005-08-02 %% Type: script Subtag: Tfng Description: Tifinagh (Berber) Added: 2005-08-02 %% Type: script Subtag: Tglg Description: Tagalog Added: 2005-08-02 %% Type: script Subtag: Thaa Description: Thaana Added: 2005-08-02 %% Type: script Subtag: Thai Description: Thai Added: 2005-08-02 %% Type: script Subtag: Tibt Description: Tibetan Added: 2005-08-02 %% Type: script Subtag: Ugar Description: Ugaritic Added: 2005-08-02 %% Type: script Subtag: Vaii Description: Vai Added: 2005-08-02 %% Type: script Subtag: Visp Ewell Expires February 3, 2006 [Page 70] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Visible Speech Added: 2005-08-02 %% Type: script Subtag: Xpeo Description: Old Persian Added: 2005-08-02 %% Type: script Subtag: Xsux Description: Cuneiform, Sumero-Akkadian Added: 2005-08-02 %% Type: script Subtag: Yiii Description: Yi Added: 2005-08-02 %% Type: script Subtag: Zxxx Description: Code for unwritten languages Added: 2005-08-02 %% Type: script Subtag: Zyyy Description: Code for undetermined script Added: 2005-08-02 %% Type: script Subtag: Zzzz Description: Code for uncoded script Added: 2005-08-02 %% Type: region Subtag: AA Description: PRIVATE USE Added: 2005-08-02 %% Type: region Subtag: AD Description: Andorra Added: 2005-08-02 %% Type: region Subtag: AE Description: United Arab Emirates Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 71] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: AF Description: Afghanistan Added: 2005-08-02 %% Type: region Subtag: AG Description: Antigua and Barbuda Added: 2005-08-02 %% Type: region Subtag: AI Description: Anguilla Added: 2005-08-02 %% Type: region Subtag: AL Description: Albania Added: 2005-08-02 %% Type: region Subtag: AM Description: Armenia Added: 2005-08-02 %% Type: region Subtag: AN Description: Netherlands Antilles Added: 2005-08-02 %% Type: region Subtag: AO Description: Angola Added: 2005-08-02 %% Type: region Subtag: AQ Description: Antarctica Added: 2005-08-02 %% Type: region Subtag: AR Description: Argentina Added: 2005-08-02 %% Type: region Subtag: AS Description: American Samoa Ewell Expires February 3, 2006 [Page 72] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: region Subtag: AT Description: Austria Added: 2005-08-02 %% Type: region Subtag: AU Description: Australia Added: 2005-08-02 %% Type: region Subtag: AW Description: Aruba Added: 2005-08-02 %% Type: region Subtag: AX Description: Åland Islands Added: 2005-08-02 %% Type: region Subtag: AZ Description: Azerbaijan Added: 2005-08-02 %% Type: region Subtag: BA Description: Bosnia and Herzegovina Added: 2005-08-02 %% Type: region Subtag: BB Description: Barbados Added: 2005-08-02 %% Type: region Subtag: BD Description: Bangladesh Added: 2005-08-02 %% Type: region Subtag: BE Description: Belgium Added: 2005-08-02 %% Type: region Ewell Expires February 3, 2006 [Page 73] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: BF Description: Burkina Faso Added: 2005-08-02 %% Type: region Subtag: BG Description: Bulgaria Added: 2005-08-02 %% Type: region Subtag: BH Description: Bahrain Added: 2005-08-02 %% Type: region Subtag: BI Description: Burundi Added: 2005-08-02 %% Type: region Subtag: BJ Description: Benin Added: 2005-08-02 %% Type: region Subtag: BM Description: Bermuda Added: 2005-08-02 %% Type: region Subtag: BN Description: Brunei Darussalam Added: 2005-08-02 %% Type: region Subtag: BO Description: Bolivia Added: 2005-08-02 %% Type: region Subtag: BR Description: Brazil Added: 2005-08-02 %% Type: region Subtag: BS Description: Bahamas Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 74] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: BT Description: Bhutan Added: 2005-08-02 %% Type: region Subtag: BU Description: Burma Added: 2005-08-02 Preferred-Value: MM Deprecated: 1989-12-05 %% Type: region Subtag: BV Description: Bouvet Island Added: 2005-08-02 %% Type: region Subtag: BW Description: Botswana Added: 2005-08-02 %% Type: region Subtag: BY Description: Belarus Added: 2005-08-02 %% Type: region Subtag: BZ Description: Belize Added: 2005-08-02 %% Type: region Subtag: CA Description: Canada Added: 2005-08-02 %% Type: region Subtag: CC Description: Cocos (Keeling) Islands Added: 2005-08-02 %% Type: region Subtag: CD Description: Congo, The Democratic Republic of the Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 75] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: CF Description: Central African Republic Added: 2005-08-02 %% Type: region Subtag: CG Description: Congo Added: 2005-08-02 %% Type: region Subtag: CH Description: Switzerland Added: 2005-08-02 %% Type: region Subtag: CI Description: Côte d'Ivoire Added: 2005-08-02 %% Type: region Subtag: CK Description: Cook Islands Added: 2005-08-02 %% Type: region Subtag: CL Description: Chile Added: 2005-08-02 %% Type: region Subtag: CM Description: Cameroon Added: 2005-08-02 %% Type: region Subtag: CN Description: China Added: 2005-08-02 %% Type: region Subtag: CO Description: Colombia Added: 2005-08-02 %% Type: region Subtag: CR Description: Costa Rica Ewell Expires February 3, 2006 [Page 76] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: region Subtag: CS Description: Serbia and Montenegro Added: 2005-08-02 %% Type: region Subtag: CU Description: Cuba Added: 2005-08-02 %% Type: region Subtag: CV Description: Cape Verde Added: 2005-08-02 %% Type: region Subtag: CX Description: Christmas Island Added: 2005-08-02 %% Type: region Subtag: CY Description: Cyprus Added: 2005-08-02 %% Type: region Subtag: CZ Description: Czech Republic Added: 2005-08-02 %% Type: region Subtag: DD Description: German Democratic Republic Added: 2005-08-02 Preferred-Value: DE Deprecated: 1990-10-30 %% Type: region Subtag: DE Description: Germany Added: 2005-08-02 %% Type: region Subtag: DJ Description: Djibouti Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 77] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: DK Description: Denmark Added: 2005-08-02 %% Type: region Subtag: DM Description: Dominica Added: 2005-08-02 %% Type: region Subtag: DO Description: Dominican Republic Added: 2005-08-02 %% Type: region Subtag: DZ Description: Algeria Added: 2005-08-02 %% Type: region Subtag: EC Description: Ecuador Added: 2005-08-02 %% Type: region Subtag: EE Description: Estonia Added: 2005-08-02 %% Type: region Subtag: EG Description: Egypt Added: 2005-08-02 %% Type: region Subtag: EH Description: Western Sahara Added: 2005-08-02 %% Type: region Subtag: ER Description: Eritrea Added: 2005-08-02 %% Type: region Subtag: ES Ewell Expires February 3, 2006 [Page 78] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Spain Added: 2005-08-02 %% Type: region Subtag: ET Description: Ethiopia Added: 2005-08-02 %% Type: region Subtag: FI Description: Finland Added: 2005-08-02 %% Type: region Subtag: FJ Description: Fiji Added: 2005-08-02 %% Type: region Subtag: FK Description: Falkland Islands (Malvinas) Added: 2005-08-02 %% Type: region Subtag: FM Description: Micronesia, Federated States of Added: 2005-08-02 %% Type: region Subtag: FO Description: Faroe Islands Added: 2005-08-02 %% Type: region Subtag: FR Description: France Added: 2005-08-02 %% Type: region Subtag: FX Description: Metropolitan France Added: 2005-08-02 Preferred-Value: FR Deprecated: 1997-07-14 %% Type: region Subtag: GA Description: Gabon Ewell Expires February 3, 2006 [Page 79] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: region Subtag: GB Description: United Kingdom Added: 2005-08-02 %% Type: region Subtag: GD Description: Grenada Added: 2005-08-02 %% Type: region Subtag: GE Description: Georgia Added: 2005-08-02 %% Type: region Subtag: GF Description: French Guiana Added: 2005-08-02 %% Type: region Subtag: GH Description: Ghana Added: 2005-08-02 %% Type: region Subtag: GI Description: Gibraltar Added: 2005-08-02 %% Type: region Subtag: GL Description: Greenland Added: 2005-08-02 %% Type: region Subtag: GM Description: Gambia Added: 2005-08-02 %% Type: region Subtag: GN Description: Guinea Added: 2005-08-02 %% Type: region Ewell Expires February 3, 2006 [Page 80] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: GP Description: Guadeloupe Added: 2005-08-02 %% Type: region Subtag: GQ Description: Equatorial Guinea Added: 2005-08-02 %% Type: region Subtag: GR Description: Greece Added: 2005-08-02 %% Type: region Subtag: GS Description: South Georgia and the South Sandwich Islands Added: 2005-08-02 %% Type: region Subtag: GT Description: Guatemala Added: 2005-08-02 %% Type: region Subtag: GU Description: Guam Added: 2005-08-02 %% Type: region Subtag: GW Description: Guinea-Bissau Added: 2005-08-02 %% Type: region Subtag: GY Description: Guyana Added: 2005-08-02 %% Type: region Subtag: HK Description: Hong Kong Added: 2005-08-02 %% Type: region Subtag: HM Description: Heard Island and McDonald Islands Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 81] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: HN Description: Honduras Added: 2005-08-02 %% Type: region Subtag: HR Description: Croatia Added: 2005-08-02 %% Type: region Subtag: HT Description: Haiti Added: 2005-08-02 %% Type: region Subtag: HU Description: Hungary Added: 2005-08-02 %% Type: region Subtag: ID Description: Indonesia Added: 2005-08-02 %% Type: region Subtag: IE Description: Ireland Added: 2005-08-02 %% Type: region Subtag: IL Description: Israel Added: 2005-08-02 %% Type: region Subtag: IN Description: India Added: 2005-08-02 %% Type: region Subtag: IO Description: British Indian Ocean Territory Added: 2005-08-02 %% Type: region Subtag: IQ Ewell Expires February 3, 2006 [Page 82] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Iraq Added: 2005-08-02 %% Type: region Subtag: IR Description: Iran, Islamic Republic of Added: 2005-08-02 %% Type: region Subtag: IS Description: Iceland Added: 2005-08-02 %% Type: region Subtag: IT Description: Italy Added: 2005-08-02 %% Type: region Subtag: JM Description: Jamaica Added: 2005-08-02 %% Type: region Subtag: JO Description: Jordan Added: 2005-08-02 %% Type: region Subtag: JP Description: Japan Added: 2005-08-02 %% Type: region Subtag: KE Description: Kenya Added: 2005-08-02 %% Type: region Subtag: KG Description: Kyrgyzstan Added: 2005-08-02 %% Type: region Subtag: KH Description: Cambodia Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 83] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: KI Description: Kiribati Added: 2005-08-02 %% Type: region Subtag: KM Description: Comoros Added: 2005-08-02 %% Type: region Subtag: KN Description: Saint Kitts and Nevis Added: 2005-08-02 %% Type: region Subtag: KP Description: Korea, Democratic People's Republic of Added: 2005-08-02 %% Type: region Subtag: KR Description: Korea, Republic of Added: 2005-08-02 %% Type: region Subtag: KW Description: Kuwait Added: 2005-08-02 %% Type: region Subtag: KY Description: Cayman Islands Added: 2005-08-02 %% Type: region Subtag: KZ Description: Kazakhstan Added: 2005-08-02 %% Type: region Subtag: LA Description: Lao People's Democratic Republic Added: 2005-08-02 %% Type: region Subtag: LB Description: Lebanon Ewell Expires February 3, 2006 [Page 84] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: region Subtag: LC Description: Saint Lucia Added: 2005-08-02 %% Type: region Subtag: LI Description: Liechtenstein Added: 2005-08-02 %% Type: region Subtag: LK Description: Sri Lanka Added: 2005-08-02 %% Type: region Subtag: LR Description: Liberia Added: 2005-08-02 %% Type: region Subtag: LS Description: Lesotho Added: 2005-08-02 %% Type: region Subtag: LT Description: Lithuania Added: 2005-08-02 %% Type: region Subtag: LU Description: Luxembourg Added: 2005-08-02 %% Type: region Subtag: LV Description: Latvia Added: 2005-08-02 %% Type: region Subtag: LY Description: Libyan Arab Jamahiriya Added: 2005-08-02 %% Type: region Ewell Expires February 3, 2006 [Page 85] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: MA Description: Morocco Added: 2005-08-02 %% Type: region Subtag: MC Description: Monaco Added: 2005-08-02 %% Type: region Subtag: MD Description: Moldova, Republic of Added: 2005-08-02 %% Type: region Subtag: MG Description: Madagascar Added: 2005-08-02 %% Type: region Subtag: MH Description: Marshall Islands Added: 2005-08-02 %% Type: region Subtag: MK Description: Macedonia, The Former Yugoslav Republic of Added: 2005-08-02 %% Type: region Subtag: ML Description: Mali Added: 2005-08-02 %% Type: region Subtag: MM Description: Myanmar Added: 2005-08-02 %% Type: region Subtag: MN Description: Mongolia Added: 2005-08-02 %% Type: region Subtag: MO Description: Macao Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 86] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: MP Description: Northern Mariana Islands Added: 2005-08-02 %% Type: region Subtag: MQ Description: Martinique Added: 2005-08-02 %% Type: region Subtag: MR Description: Mauritania Added: 2005-08-02 %% Type: region Subtag: MS Description: Montserrat Added: 2005-08-02 %% Type: region Subtag: MT Description: Malta Added: 2005-08-02 %% Type: region Subtag: MU Description: Mauritius Added: 2005-08-02 %% Type: region Subtag: MV Description: Maldives Added: 2005-08-02 %% Type: region Subtag: MW Description: Malawi Added: 2005-08-02 %% Type: region Subtag: MX Description: Mexico Added: 2005-08-02 %% Type: region Subtag: MY Ewell Expires February 3, 2006 [Page 87] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Malaysia Added: 2005-08-02 %% Type: region Subtag: MZ Description: Mozambique Added: 2005-08-02 %% Type: region Subtag: NA Description: Namibia Added: 2005-08-02 %% Type: region Subtag: NC Description: New Caledonia Added: 2005-08-02 %% Type: region Subtag: NE Description: Niger Added: 2005-08-02 %% Type: region Subtag: NF Description: Norfolk Island Added: 2005-08-02 %% Type: region Subtag: NG Description: Nigeria Added: 2005-08-02 %% Type: region Subtag: NI Description: Nicaragua Added: 2005-08-02 %% Type: region Subtag: NL Description: Netherlands Added: 2005-08-02 %% Type: region Subtag: NO Description: Norway Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 88] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: NP Description: Nepal Added: 2005-08-02 %% Type: region Subtag: NR Description: Nauru Added: 2005-08-02 %% Type: region Subtag: NT Description: Neutral Zone Added: 2005-08-02 Deprecated: 1993-07-12 %% Type: region Subtag: NU Description: Niue Added: 2005-08-02 %% Type: region Subtag: NZ Description: New Zealand Added: 2005-08-02 %% Type: region Subtag: OM Description: Oman Added: 2005-08-02 %% Type: region Subtag: PA Description: Panama Added: 2005-08-02 %% Type: region Subtag: PE Description: Peru Added: 2005-08-02 %% Type: region Subtag: PF Description: French Polynesia Added: 2005-08-02 %% Type: region Subtag: PG Ewell Expires February 3, 2006 [Page 89] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Papua New Guinea Added: 2005-08-02 %% Type: region Subtag: PH Description: Philippines Added: 2005-08-02 %% Type: region Subtag: PK Description: Pakistan Added: 2005-08-02 %% Type: region Subtag: PL Description: Poland Added: 2005-08-02 %% Type: region Subtag: PM Description: Saint Pierre and Miquelon Added: 2005-08-02 %% Type: region Subtag: PN Description: Pitcairn Added: 2005-08-02 %% Type: region Subtag: PR Description: Puerto Rico Added: 2005-08-02 %% Type: region Subtag: PS Description: Palestinian Territory, Occupied Added: 2005-08-02 %% Type: region Subtag: PT Description: Portugal Added: 2005-08-02 %% Type: region Subtag: PW Description: Palau Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 90] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: PY Description: Paraguay Added: 2005-08-02 %% Type: region Subtag: QA Description: Qatar Added: 2005-08-02 %% Type: region Subtag: QM..QZ Description: PRIVATE USE Added: 2005-08-02 %% Type: region Subtag: RE Description: Réunion Added: 2005-08-02 %% Type: region Subtag: RO Description: Romania Added: 2005-08-02 %% Type: region Subtag: RU Description: Russian Federation Added: 2005-08-02 %% Type: region Subtag: RW Description: Rwanda Added: 2005-08-02 %% Type: region Subtag: SA Description: Saudi Arabia Added: 2005-08-02 %% Type: region Subtag: SB Description: Solomon Islands Added: 2005-08-02 %% Type: region Subtag: SC Description: Seychelles Ewell Expires February 3, 2006 [Page 91] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: region Subtag: SD Description: Sudan Added: 2005-08-02 %% Type: region Subtag: SE Description: Sweden Added: 2005-08-02 %% Type: region Subtag: SG Description: Singapore Added: 2005-08-02 %% Type: region Subtag: SH Description: Saint Helena Added: 2005-08-02 %% Type: region Subtag: SI Description: Slovenia Added: 2005-08-02 %% Type: region Subtag: SJ Description: Svalbard and Jan Mayen Added: 2005-08-02 %% Type: region Subtag: SK Description: Slovakia Added: 2005-08-02 %% Type: region Subtag: SL Description: Sierra Leone Added: 2005-08-02 %% Type: region Subtag: SM Description: San Marino Added: 2005-08-02 %% Type: region Ewell Expires February 3, 2006 [Page 92] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: SN Description: Senegal Added: 2005-08-02 %% Type: region Subtag: SO Description: Somalia Added: 2005-08-02 %% Type: region Subtag: SR Description: Suriname Added: 2005-08-02 %% Type: region Subtag: ST Description: Sao Tome and Principe Added: 2005-08-02 %% Type: region Subtag: SU Description: Union of Soviet Socialist Republics Added: 2005-08-02 Deprecated: 1992-08-30 %% Type: region Subtag: SV Description: El Salvador Added: 2005-08-02 %% Type: region Subtag: SY Description: Syrian Arab Republic Added: 2005-08-02 %% Type: region Subtag: SZ Description: Swaziland Added: 2005-08-02 %% Type: region Subtag: TC Description: Turks and Caicos Islands Added: 2005-08-02 %% Type: region Subtag: TD Description: Chad Ewell Expires February 3, 2006 [Page 93] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: region Subtag: TF Description: French Southern Territories Added: 2005-08-02 %% Type: region Subtag: TG Description: Togo Added: 2005-08-02 %% Type: region Subtag: TH Description: Thailand Added: 2005-08-02 %% Type: region Subtag: TJ Description: Tajikistan Added: 2005-08-02 %% Type: region Subtag: TK Description: Tokelau Added: 2005-08-02 %% Type: region Subtag: TL Description: Timor-Leste Added: 2005-08-02 %% Type: region Subtag: TM Description: Turkmenistan Added: 2005-08-02 %% Type: region Subtag: TN Description: Tunisia Added: 2005-08-02 %% Type: region Subtag: TO Description: Tonga Added: 2005-08-02 %% Type: region Ewell Expires February 3, 2006 [Page 94] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: TP Description: East Timor Added: 2005-08-02 Preferred-Value: TL Deprecated: 2002-11-15 %% Type: region Subtag: TR Description: Turkey Added: 2005-08-02 %% Type: region Subtag: TT Description: Trinidad and Tobago Added: 2005-08-02 %% Type: region Subtag: TV Description: Tuvalu Added: 2005-08-02 %% Type: region Subtag: TW Description: Taiwan, Province of China Added: 2005-08-02 %% Type: region Subtag: TZ Description: Tanzania, United Republic of Added: 2005-08-02 %% Type: region Subtag: UA Description: Ukraine Added: 2005-08-02 %% Type: region Subtag: UG Description: Uganda Added: 2005-08-02 %% Type: region Subtag: UM Description: United States Minor Outlying Islands Added: 2005-08-02 %% Type: region Subtag: US Ewell Expires February 3, 2006 [Page 95] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: United States Added: 2005-08-02 %% Type: region Subtag: UY Description: Uruguay Added: 2005-08-02 %% Type: region Subtag: UZ Description: Uzbekistan Added: 2005-08-02 %% Type: region Subtag: VA Description: Holy See (Vatican City State) Added: 2005-08-02 %% Type: region Subtag: VC Description: Saint Vincent and the Grenadines Added: 2005-08-02 %% Type: region Subtag: VE Description: Venezuela Added: 2005-08-02 %% Type: region Subtag: VG Description: Virgin Islands, British Added: 2005-08-02 %% Type: region Subtag: VI Description: Virgin Islands, U.S. Added: 2005-08-02 %% Type: region Subtag: VN Description: Viet Nam Added: 2005-08-02 %% Type: region Subtag: VU Description: Vanuatu Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 96] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: WF Description: Wallis and Futuna Added: 2005-08-02 %% Type: region Subtag: WS Description: Samoa Added: 2005-08-02 %% Type: region Subtag: XA..XZ Description: PRIVATE USE Added: 2005-08-02 %% Type: region Subtag: YD Description: Yemen, Democratic Added: 2005-08-02 Preferred-Value: YE Deprecated: 1990-08-14 %% Type: region Subtag: YE Description: Yemen Added: 2005-08-02 %% Type: region Subtag: YT Description: Mayotte Added: 2005-08-02 %% Type: region Subtag: YU Description: Yugoslavia Added: 2005-08-02 Preferred-Value: CS Deprecated: 2003-07-23 %% Type: region Subtag: ZA Description: South Africa Added: 2005-08-02 %% Type: region Subtag: ZM Description: Zambia Added: 2005-08-02 Ewell Expires February 3, 2006 [Page 97] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: ZR Description: Zaire Added: 2005-08-02 Preferred-Value: CD Deprecated: 1997-07-14 %% Type: region Subtag: ZW Description: Zimbabwe Added: 2005-08-02 %% Type: region Subtag: ZZ Description: PRIVATE USE Added: 2005-08-02 %% Type: region Subtag: 001 Description: World Added: 2005-08-02 %% Type: region Subtag: 002 Description: Africa Added: 2005-08-02 %% Type: region Subtag: 005 Description: South America Added: 2005-08-02 %% Type: region Subtag: 009 Description: Oceania Added: 2005-08-02 %% Type: region Subtag: 011 Description: Western Africa Added: 2005-08-02 %% Type: region Subtag: 013 Description: Central America Added: 2005-08-02 %% Ewell Expires February 3, 2006 [Page 98] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: 014 Description: Eastern Africa Added: 2005-08-02 %% Type: region Subtag: 015 Description: Northern Africa Added: 2005-08-02 %% Type: region Subtag: 017 Description: Middle Africa Added: 2005-08-02 %% Type: region Subtag: 018 Description: Southern Africa Added: 2005-08-02 %% Type: region Subtag: 019 Description: Americas Added: 2005-08-02 %% Type: region Subtag: 021 Description: Northern America Added: 2005-08-02 %% Type: region Subtag: 029 Description: Caribbean Added: 2005-08-02 %% Type: region Subtag: 030 Description: Eastern Asia Added: 2005-08-02 %% Type: region Subtag: 034 Description: Southern Asia Added: 2005-08-02 %% Type: region Subtag: 035 Description: South-Eastern Asia Ewell Expires February 3, 2006 [Page 99] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-02 %% Type: region Subtag: 039 Description: Southern Europe Added: 2005-08-02 %% Type: region Subtag: 053 Description: Australia and New Zealand Added: 2005-08-02 %% Type: region Subtag: 054 Description: Melanesia Added: 2005-08-02 %% Type: region Subtag: 057 Description: Micronesia Added: 2005-08-02 %% Type: region Subtag: 061 Description: Polynesia Added: 2005-08-02 %% Type: region Subtag: 142 Description: Asia Added: 2005-08-02 %% Type: region Subtag: 143 Description: Central Asia Added: 2005-08-02 %% Type: region Subtag: 145 Description: Western Asia Added: 2005-08-02 %% Type: region Subtag: 150 Description: Europe Added: 2005-08-02 %% Type: region Ewell Expires February 3, 2006 [Page 100] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: 151 Description: Eastern Europe Added: 2005-08-02 %% Type: region Subtag: 154 Description: Northern Europe Added: 2005-08-02 %% Type: region Subtag: 155 Description: Western Europe Added: 2005-08-02 %% Type: region Subtag: 419 Description: Latin America and the Caribbean Added: 2005-08-02 %% Type: variant Subtag: 1901 Description: Traditional German orthography Added: 2005-08-02 Prefix: de %% Type: variant Subtag: 1996 Description: German orthography of 1996 Added: 2005-08-02 Prefix: de %% Type: variant Subtag: nedis Description: Natisone dialect Description: Nadiza dialect Added: 2005-08-02 Prefix: sl %% Type: variant Subtag: rozaj Description: Resian Description: Resianic Description: Rezijan Added: 2005-08-02 Prefix: sl %% Type: grandfathered Tag: art-lojban Ewell Expires February 3, 2006 [Page 101] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Lojban Added: 2001-11-11 Preferred-Value: jbo Deprecated: 2003-09-02 Comments: replaced by ISO code jbo %% Type: grandfathered Tag: cel-gaulish Description: Gaulish Added: 2001-05-25 %% Type: grandfathered Tag: en-boont Description: Boontling Added: 2003-02-14 %% Type: grandfathered Tag: en-GB-oed Description: English, Oxford English Dictionary spelling Added: 2003-07-09 %% Type: grandfathered Tag: en-scouse Description: Scouse Added: 2000-05-25 %% Type: grandfathered Tag: i-ami Description: 'Amis Added: 1999-05-25 %% Type: grandfathered Tag: i-bnn Description: Bunun Added: 1999-05-25 %% Type: grandfathered Tag: i-default Description: Default Language Added: 1998-03-10 %% Type: grandfathered Tag: i-enochian Description: Enochian Added: 2002-07-03 %% Type: grandfathered Tag: i-hak Ewell Expires February 3, 2006 [Page 102] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Hakka Added: 1999-01-31 Preferred-Value: zh-hakka Deprecated: 2000-01-10 %% Type: grandfathered Tag: i-klingon Description: Klingon Added: 1999-05-26 Preferred-Value: tlh Deprecated: 2004-02-24 Comments: replaced by ISO code tlh %% Type: grandfathered Tag: i-lux Description: Luxembourgish Added: 1997-09-19 Preferred-Value: lb Deprecated: 1998-09-09 Comments: replaced by ISO code lb %% Type: grandfathered Tag: i-mingo Description: Mingo Added: 1997-09-19 %% Type: grandfathered Tag: i-navajo Description: Navajo Added: 1997-09-19 Preferred-Value: nv Deprecated: 2000-02-18 Comments: replaced by ISO code nv %% Type: grandfathered Tag: i-pwn Description: Paiwan Added: 1999-05-25 %% Type: grandfathered Tag: i-tao Description: Tao Added: 1999-05-25 %% Type: grandfathered Tag: i-tay Description: Tayal Added: 1999-05-25 Ewell Expires February 3, 2006 [Page 103] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: grandfathered Tag: i-tsu Description: Tsou Added: 1999-05-25 %% Type: grandfathered Tag: no-bok Description: Norwegian Bokmal Added: 1995-08-23 Preferred-Value: nb Deprecated: 2000-02-18 Comments: replaced by ISO code nb %% Type: grandfathered Tag: no-nyn Description: Norwegian Nynorsk Added: 1995-08-23 Preferred-Value: nn Deprecated: 2000-02-18 Comments: replaced by ISO code nn %% Type: grandfathered Tag: sgn-BE-fr Description: Belgian-French Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: sgn-BE-nl Description: Belgian-Flemish Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: sgn-CH-de Description: Swiss German Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: zh-cmn Description: Mandarin Chinese Added: 2005-07-15 %% Type: grandfathered Tag: zh-cmn-Hans Description: Mandarin Chinese (Simplified) Added: 2005-07-15 %% Type: grandfathered Ewell Expires February 3, 2006 [Page 104] =0C Internet-Draft Initial Language Subtag Registry August 2005 Tag: zh-cmn-Hant Description: Mandarin Chinese (Traditional) Added: 2005-07-15 %% Type: grandfathered Tag: zh-gan Description: Kan or Gan Added: 1999-12-18 %% Type: grandfathered Tag: zh-guoyu Description: Mandarin or Standard Chinese Added: 1999-12-18 Preferred-Value: zh-cmn Deprecated: 2005-07-15 %% Type: grandfathered Tag: zh-hakka Description: Hakka Added: 1999-12-18 %% Type: grandfathered Tag: zh-min Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese Added: 1999-12-18 %% Type: grandfathered Tag: zh-min-nan Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern Fujian, Hoklo, Southern Fukien, Ho-lo Added: 2001-03-26 %% Type: grandfathered Tag: zh-wuu Description: Shanghaiese or Wu Added: 1999-12-18 %% Type: grandfathered Tag: zh-xiang Description: Xiang or Hunanese Added: 1999-12-18 %% Type: grandfathered Tag: zh-yue Description: Cantonese Added: 1999-12-18 %% Type: redundant Ewell Expires February 3, 2006 [Page 105] =0C Internet-Draft Initial Language Subtag Registry August 2005 Tag: az-Arab Description: Azerbaijani in Arabic script Added: 2003-05-30 %% Type: redundant Tag: az-Cyrl Description: Azerbaijani in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: az-Latn Description: Azerbaijani in Latin script Added: 2003-05-30 %% Type: redundant Tag: be-Latn Description: Belarusian in Latin script Added: 2005-01-06 %% Type: redundant Tag: bs-Cyrl Description: Bosnian in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: bs-Latn Description: Bosnian in Latin script Added: 2005-02-17 %% Type: redundant Tag: de-1901 Description: German, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-1996 Description: German, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-AT-1901 Description: German, Austrian variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-AT-1996 Description: German, Austrian variant, orthography of 1996 Added: 2001-07-17 Ewell Expires February 3, 2006 [Page 106] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: redundant Tag: de-CH-1901 Description: German, Swiss variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-CH-1996 Description: German, Swiss variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-DE-1901 Description: German, German variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-DE-1996 Description: German, German variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: es-419 Description: Latin American Spanish Added: 2005-07-15 %% Type: redundant Tag: iu-Cans Description: Inuktitut in Canadian Aboriginal Syllabic script Added: 2005-02-17 %% Type: redundant Tag: iu-Latn Description: Inuktitut in Latin script Added: 2005-02-17 %% Type: redundant Tag: mn-Cyrl Description: Mongolian in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: mn-Mong Description: Mongolian in Mongolian script Added: 2005-02-17 %% Type: redundant Tag: sgn-BR Ewell Expires February 3, 2006 [Page 107] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Brazilian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-CO Description: Colombian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-DE Description: German Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-DK Description: Danish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-ES Description: Spanish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-FR Description: French Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-GB Description: British Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-GR Description: Greek Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-IE Description: Irish Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-IT Description: Italian Sign Language Added: 2001-11-11 %% Ewell Expires February 3, 2006 [Page 108] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: redundant Tag: sgn-JP Description: Japanese Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-MX Description: Mexican Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-NI Description: Nicaraguan Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-NL Description: Dutch Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-NO Description: Norwegian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-PT Description: Portuguese Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-SE Description: Swedish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-US Description: American Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-ZA Description: South African Sign Language Added: 2001-11-11 %% Type: redundant Tag: sl-nedis Description: Natisone dialect, Nadiza dialect Ewell Expires February 3, 2006 [Page 109] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2004-06-01 %% Type: redundant Tag: sl-rozaj Description: Resian, Resianic, Rezijan Added: 2003-10-09 %% Type: redundant Tag: sr-Cyrl Description: Serbian in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: sr-Latn Description: Serbian in Latin script Added: 2003-05-30 %% Type: redundant Tag: tg-Arab Description: Tajik in Arabic script Added: 2005-02-17 %% Type: redundant Tag: tg-Cyrl Description: Tajik in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: uz-Cyrl Description: Uzbek in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: uz-Latn Description: Uzbek in Latin script Added: 2003-05-30 %% Type: redundant Tag: yi-latn Description: Yiddish, in Latin script Added: 2003-01-07 %% Type: redundant Tag: zh-Hans Description: simplified Chinese Added: 2003-05-30 %% Type: redundant Ewell Expires February 3, 2006 [Page 110] =0C Internet-Draft Initial Language Subtag Registry August 2005 Tag: zh-Hans-CN Description: PRC Mainland Chinese in simplified script Added: 2005-04-13 %% Type: redundant Tag: zh-Hans-HK Description: Hong Kong Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-MO Description: Macao Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-SG Description: Singapore Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-TW Description: Taiwan Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant Description: traditional Chinese Added: 2003-05-30 %% Type: redundant Tag: zh-Hant-CN Description: PRC Mainland Chinese in traditional script Added: 2005-04-13 %% Type: redundant Tag: zh-Hant-HK Description: Hong Kong Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-MO Description: Macao Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-SG Description: Singapore Chinese in traditional script Added: 2005-04-11 Ewell Expires February 3, 2006 [Page 111] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: redundant Tag: zh-Hant-TW Description: Taiwan Chinese in traditional script Added: 2005-04-11 Ewell Expires February 3, 2006 [Page 112] =0C Internet-Draft Initial Language Subtag Registry August 2005 4. Omitted Code Elements The following code elements from [UN_M.49] were not associated with [ISO3166-1] alpha-2 code elements. Consequently, they were not assigned as subtags in the initial Language Subtag Registry, but are valid candidates for registration as region subtags, using the process in [I-D.ietf-ltru-registry]: 830 Channel Islands 831 Guernsey 832 Jersey 833 Isle of Man Ewell Expires February 3, 2006 [Page 113] =0C Internet-Draft Initial Language Subtag Registry August 2005 5. Security Considerations This document specifies the initial contents to be used by IANA in populating the Language Subtag Registry. For security considerations relevant to that registry and the use of language tags, see [I-D.ietf-ltru-registry]. Ewell Expires February 3, 2006 [Page 114] =0C Internet-Draft Initial Language Subtag Registry August 2005 6. IANA Considerations This document provides the initial content for the Language Subtag Registry to be maintained by IANA. For details on the procedures for the format and ongoing maintenance of this registry, see [I-D.ietf- ltru-registry]. Ewell Expires February 3, 2006 [Page 115] =0C Internet-Draft Initial Language Subtag Registry August 2005 7. References 7.1 Normative References [I-D.ietf-ltru-registry] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", June 2005. 7.2 Informative References [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166: 1988. Codes for the representation of names of countries, 3rd edition", August 1988. [ISO639-1] International Organization for Standardization, "ISO 639- 1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", 2002. [ISO639-2] International Organization for Standardization, "ISO 639- 2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition", 1998. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", UN Standard Country or Area Codes for Statistical Use, Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. [record-jar] Raymond, E., "The Art of Unix Programming", 2003. Ewell Expires February 3, 2006 [Page 116] =0C Internet-Draft Initial Language Subtag Registry August 2005 Author's Address Doug Ewell (editor) Email: dewell@adelphia.net URI: http://users.adelphia.net/~dewell Ewell Expires February 3, 2006 [Page 117] =0C Internet-Draft Initial Language Subtag Registry August 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ewell Expires February 3, 2006 [Page 118] =0C ------=_NextPart_000_0063_01C59735.4A27A460 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_0063_01C59735.4A27A460-- From ltru-bounces@lists.ietf.org Tue Aug 02 11:24:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzycs-0002m5-Jm; Tue, 02 Aug 2005 11:24:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzycq-0002lP-GQ for ltru@megatron.ietf.org; Tue, 02 Aug 2005 11:24:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28466 for ; Tue, 2 Aug 2005 11:24:13 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzz9J-0005Ik-Pe for ltru@ietf.org; Tue, 02 Aug 2005 11:57:52 -0400 X-Medic-Info: 3335.42ef900f.0 8Poyiux6xhc4PC1Q Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 45A8D3EB7; Tue, 2 Aug 2005 17:23:59 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Tue, 2 Aug 2005 17:23:59 +0200 (CEST) Message-ID: <60591.83.248.26.202.1122996239.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> Date: Tue, 2 Aug 2005 17:23:59 +0200 (CEST) Subject: Re: [Ltru] ABNF beautification... From: "Kent Karlsson" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > I took Kent's suggestion for modifying and cleaning up the ABNF and mad= e > some changes to it. Mostly I removed extra rules from it, re-combining > some things (per messages from Frank and I), and doing some gentle > tugging. > > You will note that I renamed the production rule "lang" to "language". = It > puts the "extlang" production as an option on 2*3ALPHA subtags. The 4AL= PHA > production explicitly reserved here, which is an innovation in the ABNF > but not in the text or overall meaning of the ABNF (previously we had > 2*3ALPHA followed by extlang and 4*8ALPHA was registered lang and most > recently the relationship of extlangs to the likely use of 4ALPHA ISO63= 9-6 > was discussed). > > This ABNF is slightly cleaner than the current draft-09 ANBF (all the > language subtag stuff is together, the extlang relationship is clear, t= he > rule names are more expressive. > > Here is the current result: > > -- > Language-Tag =3D langtag > / privateuse ; private use tag > / grandfathered ; grandfathered registrations > > langtag =3D (language > ["-" script] > ["-" region] > *("-" variant) > *("-" extension) > ["-" privateuse]) > > language =3D 2*3ALPHA [ extlang ] ; shortest ISO 639 code > / 4ALPHA ; reserved for future use > / 5*8ALPHA ; registered language subtag > > extlang =3D *3("-" 3ALPHA) ; reserved for future use > > script =3D 4ALPHA ; ISO 15924 code > > region =3D 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN M.49 code > > variant =3D 5*8alphanum ; registered variants > / (DIGIT 3alphanum) > > extension =3D singleton 1*("-" (2*8alphanum)) > > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > ; Single letters: x/X is reserved for private use > > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) > > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > ; grandfathered registration > ; Note: i is the only singleton > ; that starts a grandfathered tag > > alphanum =3D (ALPHA / DIGIT) ; letters and numbers > -- > > This checks out via http://rtg.ietf.org/~fenner/abnf.cgi > > Any comments? Can I get a hum to use this in preference to draft-09's > version? Seem ok (with the deletion of the []s as Frank said). I guess that means that the -matching ABNF should look like (I don't see how it is sensible to just delete the "extension" part): Language-Tag =3D langtag / privateuse ; private use tag / grandfathered ; grandfathered registrations langtag =3D (language ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse]) language =3D (2*3ALPHA extlang) ; shortest ISO 639 code / 4ALPHA ; reserved for future use / 5*8ALPHA ; registered language subtag / "*" extlang =3D *3("-" 3ALPHA) ; reserved for future use / *2("-" 3ALPHA) "-*" script =3D 4ALPHA ; ISO 15924 code / "*" region =3D 2ALPHA ; ISO 3166 code / 3DIGIT ; UN M.49 code / "*" variant =3D 5*8alphanum ; registered variants / (DIGIT 3alphanum) / "*" extension =3D singleton 1*("-" (2*8alphanum)) / "*" singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" ; Single letters: x/X is reserved for private use privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered registration ; Note: i is the only singleton ; that starts a grandfathered tag alphanum =3D (ALPHA / DIGIT) ; letters and numbers Figure 3: Language Tag Pattern ABNF _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 11:26:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyfH-0004ZI-1v; Tue, 02 Aug 2005 11:26:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyfE-0004XS-Vi for ltru@megatron.ietf.org; Tue, 02 Aug 2005 11:26:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28620 for ; Tue, 2 Aug 2005 11:26:42 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzBk-0005OO-2X for ltru@ietf.org; Tue, 02 Aug 2005 12:00:20 -0400 X-Medic-Info: 3335.42ef90b2.0 jyvAnZPDlpLuZOMD Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id DA0813EFF; Tue, 2 Aug 2005 17:26:42 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Tue, 2 Aug 2005 17:26:42 +0200 (CEST) Message-ID: <60601.83.248.26.202.1122996402.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C3F969E@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0C3F969E@irvmbxw01.quest.com> Date: Tue, 2 Aug 2005 17:26:42 +0200 (CEST) Subject: Re: [Ltru] revised editor's copy online From: "Kent Karlsson" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison wrote: > incorporate Kent's suggestions for the ISO references (and > think I might have succeeded). The HTML of the references > isn't very nice looking, but the text version (which is what > counts, after all) looks more-or-less like Kent's > suggestions. I opted for consistency in doing the formatting, Hmm, I do *not* notice that... http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html -----> What is the sort order for the references?? ISO references should be in numeric order (by standard number). [ISO639-1] International Organization for Standardization, =93ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code,=94 2002. -----> Delete the "International Organization for Standardization, " part= ; replace the "--" by an em dash; the comma should be after the quote mark; replace the redundant "2002" by "first edition" (also redundant, but not obviously so). [ISO639-2] International Organization for Standardization, =93ISO 639-2:1998. Codes for the representation of names of languages - Part 2: Alpha-3 code, first edition,=94 1998. -----> Delete the "International Organization for Standardization, " part= ; replace the single "-" by an em dash; replace ', first edition,=94' by '", first edition"; delete the redundant "1998". [ISO15924] International Organization for Standardization, =93ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts,=94 January 2004. -----> Delete the "International Organization for Standardization, " part= ; replace the "--" by an em dash; the comma should be after the quote mark; replace the "January 2004" by "first edition". [ISO3166] International Organization for Standardization, =93ISO 3166:198= 8. Codes for the representation of names of countries, 3rd edition,=94 Augus= t 1988. -----> Delete the "International Organization for Standardization, " part= ; the comma should be after the quote mark; replace the "August 1988" by "first editi= on". [UN_M.49] Statistical Division, United Nations, =93Standard Country or Ar= ea Codes for Statistical Use,=94 UN Standard Country or Area Codes for Statistical Use, Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. [ISO10646] International Organization for Standardization, =93ISO/IEC 10646-1:2000. Information technology =97 Universal Multiple-Octet Coded Character Set (UCS) =97 Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001. Information technology =97 Universal Multiple-Octet Coded Character Set (UCS) =97 Part 2: Supplementary Planes= , as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts,=94 2000. -----> Delete the "International Organization for Standardization, " part= ; replace "-1:2000" by ":2003"; delete "=97 Part 1: Architecture and Basic Multilingual Plan= e and ISO/IEC 10646-2:2001. Information technology =97 Universal Multiple-Octet Coded Character Set (UCS) =97 Part 2: Supplementary Planes= , as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts,=94 2000"; add "first edition" (yes, it is the first *merged* edition). [RFC2234bis] Crocker, D. and P. Overell, =93Augmented BNF for Syntax Specifications: ABNF,=94 draft-crocker-abnf-rfc2234bis-00 (work in progress), March 2005. -----> this one seems out of sort order. [ISO646] ISO/IEC 646 JTC 1/SC 2, =93ISO/IEC 646:1991, Information technol= ogy -- ISO 7-bit coded character set for information interchange.,=94 1991. -----> delete the "ISO/IEC 646 JTC 1/SC 2, " part; replace the ".,=94 199= 1", by '", third edition'. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 11:56:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz8C-0003UY-GM; Tue, 02 Aug 2005 11:56:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz8B-0003UT-FP for ltru@megatron.ietf.org; Tue, 02 Aug 2005 11:56:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01278 for ; Tue, 2 Aug 2005 11:56:36 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzzed-00070Y-Jo for ltru@ietf.org; Tue, 02 Aug 2005 12:30:15 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 08:56:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] revised editor's copy online Date: Tue, 2 Aug 2005 08:56:19 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C4AB464@irvmbxw01.quest.com> Thread-Topic: [Ltru] revised editor's copy online Thread-Index: AcWXdpfAX2+vs+A3RPWMHDf74TWnzgAApfKw From: "Addison Phillips" To: "Kent Karlsson" X-OriginalArrivalTime: 02 Aug 2005 15:56:20.0196 (UTC) FILETIME=[B9625240:01C5977A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Notes follow. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Kent Karlsson [mailto:kentk@cs.chalmers.se] > Sent: 2005?8?2? 8:27 > To: Addison Phillips > Cc: LTRU Working Group; Doug Ewell > Subject: Re: [Ltru] revised editor's copy online >=20 > Addison wrote: >=20 > > incorporate Kent's suggestions for the ISO references (and > > think I might have succeeded). The HTML of the references > > isn't very nice looking, but the text version (which is what > > counts, after all) looks more-or-less like Kent's > > suggestions. I opted for consistency in doing the formatting, >=20 > Hmm, I do *not* notice that... >=20 > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html [Addison Phillips]=20 Not all of your requested changes are possible. >=20 > -----> What is the sort order for the references?? ISO references = should > be in numeric order > (by standard number). [Addison Phillips]=20 The ISO references are in an order: the ones used as subtag sources are = grouped together at the top in the order they are used in a language = tag. The remaining references could be grouped differently (e.g. with = ISO 646 appearing before ISO 10646). >=20 > [ISO639-1] International Organization for Standardization, "ISO > 639-1:2002. Codes for the representation of names of languages -- Part = 1: > Alpha-2 code," 2002. >=20 > -----> Delete the "International Organization for Standardization, " = part; [Addison Phillips]=20 The XML format requires an author. > replace the > "--" by an em dash; the comma should be after the quote mark; replace = the > redundant "2002" > by "first edition" (also redundant, but not obviously so). [Addison Phillips]=20 "em dash" is not an ISO 646 ASCII character and is forbidden by rule in = an RFC. The double-dash is preserved as the way of representing the em = dash in text from RFC 3066, etc. The date is required by the XML format used to author the document. I = *must* put in a date, so this date makes sense. All of these apply to the other ISO standards referenced. >=20 > [ISO10646] International Organization for Standardization, "ISO/IEC > 10646-1:2000. Information technology - Universal Multiple-Octet Coded > Character Set (UCS) - Part 1: Architecture and Basic Multilingual = Plane > and ISO/IEC 10646-2:2001. Information technology - Universal > Multiple-Octet Coded Character Set (UCS) - Part 2: Supplementary = Planes, > as, from time to time, amended, replaced by a new edition or expanded = by > the addition of new parts," 2000. >=20 > > replace "-1:2000" > by ":2003";=20 [Addison Phillips]=20 Okay. delete "- Part 1: Architecture and Basic Multilingual Plane > and ISO/IEC 10646-2:2001. Information technology - Universal > Multiple-Octet Coded Character Set (UCS) - Part 2: Supplementary = Planes, > as, from time to time, amended, replaced by a new edition or expanded = by > the addition of new parts," 2000"; add "first edition" (yes, it is the > first *merged* edition). [Addison Phillips]=20 Okay. >=20 > [RFC2234bis] Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF," draft-crocker-abnf-rfc2234bis-00 (work in > progress), March 2005. >=20 > -----> this one seems out of sort order. [Addison Phillips]=20 It is. >=20 > [ISO646] ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, Information = technology > -- ISO 7-bit coded character set for information interchange.," 1991. >=20 > -----> delete the "ISO/IEC 646 JTC 1/SC 2, " part; replace the ".," = 1991", > by '", third edition'. >=20 This one should have an author of "International Organization for = Standardization" too :-) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 11:58:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz9v-0004b6-NQ; Tue, 02 Aug 2005 11:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz9v-0004b0-4l for ltru@megatron.ietf.org; Tue, 02 Aug 2005 11:58:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01452 for ; Tue, 2 Aug 2005 11:58:24 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzgP-000796-S7 for ltru@ietf.org; Tue, 02 Aug 2005 12:32:03 -0400 Received: from wamui-andean.atl.sa.earthlink.net ([209.86.224.24]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzz9p-0007AP-00 for ltru@ietf.org; Tue, 02 Aug 2005 11:58:21 -0400 Message-ID: <26047540.1122998301745.JavaMail.root@wamui-andean.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 10:58:21 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] revised editor's copy online Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - As someone with some experience in references sections: (1) em-dash, etc. are not available to us. internet drafts and RFCs are limited to 7-bit ASCII, so "-" will have to do. (2) long-standing convention for references in IETF documents is to provide a date, rather than things like "first edition". If we were to depart from that convention, we would probably end up having to explain why we were omitting that date information. (3) to the extent that the order of quote marks and commas is determined by xml2rfc in these entries, we should go with whatever the tool does, to avoid creating pain for ourselves and the RFC editor. To the extent that we have control over them, we should stick to what is used in http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt even if that is at odds with scholarly English usage. (4) I see no harm to including "International Organization for Standardization" where it makes sense, particularly if it would be extra work to get rid of it. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 12:24:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzYr-0000SW-RP; Tue, 02 Aug 2005 12:24:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzYq-0000S0-3G for ltru@megatron.ietf.org; Tue, 02 Aug 2005 12:24:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03174 for ; Tue, 2 Aug 2005 12:24:09 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E005J-0008Le-34 for ltru@ietf.org; Tue, 02 Aug 2005 12:57:48 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DzzYh-0001aV-OH; Tue, 02 Aug 2005 09:24:04 -0700 Message-Id: <6.2.1.2.2.20050802173041.03cb75d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 Aug 2005 18:21:14 +0200 To: Randy Presuhn , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: issue #1072 Last Call text alternative over languages and Internet In-Reply-To: <22558519.1122991875047.JavaMail.root@wamui-bichon.atl.sa.e arthlink.net> References: <22558519.1122991875047.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 16:11 02/08/2005, Randy Presuhn wrote: > > >As a technical contributor, I find both of the changes Jefsey suggests > highly > > >objectionable. I strongly prefer that make neither of the changes he > proposes > > >below. (A) would clearly contravene syntactic compatibility, and is thus > > >not acceptable. (B) makes claims about applicability ("final language > > >tagging system for the whole Internet") that are patently false. > > > > Dear Randy, > > This is patently untrue. The Draft wants to replace RFC 3066 as BCP 47 and > > as such established a final language tagging system for the whole > Internet. > >"a" is ok. "final" is clearly wrong. "for the whole Internet" is both >true and false, >depending on whether one undestands it as meaning "with potential for >application >in a wide variety of places" or as "the sole such system permitted >anywhere in the >internet." Your original wording seemed to be intended in the latter >sense. If you meant >the former, I don't see why you're spending so much time whining. Correct. > > If you truly believe I am wrong (but then many others are wrong): > > 1. you simply have to have this confirmed by the IESG and IAB or use my > > text in replacing "wants" by "does not want". > >Even if either version would be a sensible sentence (attributing volition >to a document >is semantically bizarre), it's not an either-or proposition. Adapt. But commit. I find strange that after all this time you are unable to commit if I am or not right in saying that RFC 3066 bis will become BPC 47 and will enjoy the authority of a BCP? > > 2. I will introduce an RFC for information on the use of "0-". > >Cool. This would be a more constructive way to introduce the capabilities >you desire. No. Because you may have noted that "0-" is part of the Draft. My proposition is correct. Fortunately, this WG has been remarkably clear in expressing its >preferences, so any items that were overlooked should be easily corrected. Claiming something does not make it necessarily true. I repeat that my proposition "0-" (or Text A) is correct. That your comment is incorrect. That your decision to consider it closed is incorrect. Up to you to show me wrong about Text B in producing a statement by IESG that the Draft will not become BCP 47 and that it does not pretend to an exclusive. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 12:24:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzYt-0000YF-8b; Tue, 02 Aug 2005 12:24:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzYr-0000S8-2m for ltru@megatron.ietf.org; Tue, 02 Aug 2005 12:24:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03179 for ; Tue, 2 Aug 2005 12:24:10 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E005J-0008LY-39 for ltru@ietf.org; Tue, 02 Aug 2005 12:57:49 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DzzYf-0001aV-2V; Tue, 02 Aug 2005 09:24:01 -0700 Message-Id: <6.2.1.2.2.20050802160327.0460a6a0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 Aug 2005 18:23:57 +0200 To: Erkki Kolehmainen , Randy Presuhn From: r&d afrac Subject: Re: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax In-Reply-To: <42EF741E.6080406@kotus.fi> References: <24864460.1122985957212.JavaMail.root@wamui-billy.atl.sa.earthlink.net> <42EF741E.6080406@kotus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 15:24 02/08/2005, Erkki Kolehmainen wrote: >As this 0- would not be understood by any current implementation to be an >absolute escape sequence, which could be followed by any syntax, I'm >against its inclusion in the present memo. ??? Why? It conforms to the ABNF. Then what would be the result? Interesting since people are going to use it anyway. And Randy just said he would not oppose. Or you mean that Randy is joking at me? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 12:28:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzd1-0001Yb-Ar; Tue, 02 Aug 2005 12:28:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzcz-0001YT-VU for ltru@megatron.ietf.org; Tue, 02 Aug 2005 12:28:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03370 for ; Tue, 2 Aug 2005 12:28:24 -0400 (EDT) Received: from pop05.mail.atl.earthlink.net ([207.69.200.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E009S-0008Vn-PP for ltru@ietf.org; Tue, 02 Aug 2005 13:02:04 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop05.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzzcr-00069c-00 for ltru@ietf.org; Tue, 02 Aug 2005 12:28:21 -0400 Message-ID: <32218407.1123000101980.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 11:28:21 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Subject: RE: [Ltru] revised editor's copy online Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: Addison Phillips > Sent: Aug 2, 2005 10:56 AM > To: Kent Karlsson > Cc: Doug Ewell , LTRU Working Group > Subject: RE: [Ltru] revised editor's copy online ... > The ISO references are in an order: the ones used as subtag sources are > grouped together at the top in the order they are used in a language tag. > The remaining references could be grouped differently (e.g. with ISO 646 > appearing before ISO 10646). ... As someone who has been through this too many times... I strongly recommend using the "sortrefs" option (see http://xml.resource.org/authoring/README.html ) for xml2rfc. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 12:31:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzfj-0003Qa-Hl; Tue, 02 Aug 2005 12:31:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzfi-0003P9-8G for ltru@megatron.ietf.org; Tue, 02 Aug 2005 12:31:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03531 for ; Tue, 2 Aug 2005 12:31:15 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00CA-0000By-B6 for ltru@ietf.org; Tue, 02 Aug 2005 13:04:51 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 09:30:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax Date: Tue, 2 Aug 2005 09:30:56 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C4AB498@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax Thread-Index: AcWXfu2kawgrzE3PScOTq5pVcxSs3QAABkdA From: "Addison Phillips" To: "r&d afrac" , "Erkki Kolehmainen" , "Randy Presuhn" X-OriginalArrivalTime: 02 Aug 2005 16:30:57.0201 (UTC) FILETIME=[8F602210:01C5977F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org It does not work with "most" implementations and does not conform to the = ABNF if the subtags exceed 8 characters or include the characters colon = or dot. Try inputting your example into Mozilla (gee... it rejects the = tag as invalid) You can, of course, write an I-D (many of us have asked, nay, begged you = to do so for lo these past many months). Whether it gains acceptance or = not is dependent on the usual factors. May the best solution win. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of r&d afrac > Sent: 2005?8?2? 9:24 > To: Erkki Kolehmainen; Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #1092] WGLC treat 0- as escape from = syntax >=20 > At 15:24 02/08/2005, Erkki Kolehmainen wrote: > >As this 0- would not be understood by any current implementation to = be an > >absolute escape sequence, which could be followed by any syntax, I'm > >against its inclusion in the present memo. >=20 > ??? Why? It conforms to the ABNF. Then what would be the result? > Interesting since people are going to use it anyway. > And Randy just said he would not oppose. Or you mean that Randy is = joking > at me? > jfc >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 12:51:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzzE-0002Cg-BL; Tue, 02 Aug 2005 12:51:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzzB-0002C4-QT for ltru@megatron.ietf.org; Tue, 02 Aug 2005 12:51:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04684 for ; Tue, 2 Aug 2005 12:51:21 -0400 (EDT) Received: from pop05.mail.atl.earthlink.net ([207.69.200.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00Vf-00016F-ID for ltru@ietf.org; Tue, 02 Aug 2005 13:25:00 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop05.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzzz6-0004WA-00 for ltru@ietf.org; Tue, 02 Aug 2005 12:51:20 -0400 Message-ID: <18390633.1123001480259.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 11:51:20 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: issue #1072 Last Call text alternative over languages and Internet Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: r&d afrac > Sent: Aug 2, 2005 11:21 AM > To: Randy Presuhn , ltru@ietf.org > Subject: Re: [Ltru] Re: issue #1072 Last Call text alternative over languages and Internet ... > I find strange that after all this time you are unable to commit if I am or > not right in saying that RFC 3066 bis will become BPC 47 and will enjoy the > authority of a BCP? You seem to attribute far more import to the "BCP" designation than is warranted. Whether it is designated as a BCP is up to the IESG. ... > I repeat that my proposition "0-" (or Text A) is correct. > That your comment is incorrect. > That your decision to consider it closed is incorrect. This co-chair has already ruled. You may take your problem to the responsible AD. If I have misread the WG consensus, or the WG has collectively committed a technical blunder, our AD can instruct us to reconsider. > Up to you to show me wrong about Text B in producing a statement by IESG > that the Draft will not become BCP 47 and that it does not pretend to an > exclusive. ... Sorry. I'm simply not able to make any sense of this sentence. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 13:10:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00HP-0004Y1-Um; Tue, 02 Aug 2005 13:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00HN-0004TT-MO for ltru@megatron.ietf.org; Tue, 02 Aug 2005 13:10:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06220 for ; Tue, 2 Aug 2005 13:10:08 -0400 (EDT) Received: from pop05.mail.atl.earthlink.net ([207.69.200.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00nr-00024M-F3 for ltru@ietf.org; Tue, 02 Aug 2005 13:43:48 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop05.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E00HI-0001it-00 for ltru@ietf.org; Tue, 02 Aug 2005 13:10:08 -0400 Message-ID: <10021024.1123002608544.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 12:10:08 -0500 (GMT-05:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: r&d afrac > Sent: Aug 2, 2005 11:23 AM > To: Erkki Kolehmainen , > Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax > > At 15:24 02/08/2005, Erkki Kolehmainen wrote: > >As this 0- would not be understood by any current implementation to be an > >absolute escape sequence, which could be followed by any syntax, I'm > >against its inclusion in the present memo. > > ??? Why? It conforms to the ABNF. Then what would be the result? The string "0-" conforms to the ABNF. The rest of your proposal does not. > Interesting since people are going to use it anyway. Fine; they'd just not be in conformance to the spec. Time will tell whether the market will endorse non-conformance. > And Randy just said he would not oppose. Or you mean that Randy is joking > at me? ... Submitting an i-d requesting registration of 0- is the correct procedural path, as outlined in the current registry i-d. As for the content of your i-d, I reserve comment until it appears. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 16:46:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E03f5-0005zV-4T; Tue, 02 Aug 2005 16:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E03f2-0005wm-PH for ltru@megatron.ietf.org; Tue, 02 Aug 2005 16:46:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16716 for ; Tue, 2 Aug 2005 16:46:50 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E04BY-0001zi-M0 for ltru@ietf.org; Tue, 02 Aug 2005 17:20:31 -0400 X-Medic-Info: 3685.42efdbb2.0 6r3TwIde2Wv2bj1k Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 15BB93F5F for ; Tue, 2 Aug 2005 22:46:42 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Tue, 2 Aug 2005 22:46:42 +0200 (CEST) Message-ID: <61828.83.248.26.202.1123015602.squirrel@webmail.chalmers.se> Date: Tue, 2 Aug 2005 22:46:42 +0200 (CEST) Subject: RE: [Ltru] revised editor's copy online From: "Kent Karlsson" To: "LTRU Working Group" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org 1. You used en dash in the 10646 reference, and a single - in the 639-2 reference... 2. Use ISO/IEC or ISO as "author", remove the date after the standards number, keeping it at the end (the repetition is annoying), just the year number. If it is an ISO/IEC standard, using just "International Oragization for Standardisation" as author would be inappropriate. 3. Include edition number as well (I see no reason not to), outside of the quoted title (it is not part of the title). Preferebly the standards number should be outside of (before) the quoted title too. 4. Sort all the ISO/IEC (and ISO and IEC) references by number. I see no reason to do otherwise here (like grouping related standards together). /kent k > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Tuesday, August 02, 2005 5:56 PM > To: Kent Karlsson > Cc: LTRU Working Group; Doug Ewell > Subject: RE: [Ltru] revised editor's copy online > > > Notes follow. > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: Kent Karlsson [mailto:kentk@cs.chalmers.se] > > Sent: 2005?8?2? 8:27 > > To: Addison Phillips > > Cc: LTRU Working Group; Doug Ewell > > Subject: Re: [Ltru] revised editor's copy online > > > > Addison wrote: > > > > > incorporate Kent's suggestions for the ISO references (and > > > think I might have succeeded). The HTML of the references > > > isn't very nice looking, but the text version (which is what > > > counts, after all) looks more-or-less like Kent's > > > suggestions. I opted for consistency in doing the formatting, > > > > Hmm, I do *not* notice that... > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html > [Addison Phillips] > > Not all of your requested changes are possible. > > > > -----> What is the sort order for the references?? ISO > references should > > be in numeric order > > (by standard number). > [Addison Phillips] > > The ISO references are in an order: the ones used as subtag > sources are grouped together at the top in the order they are > used in a language tag. The remaining references could be > grouped differently (e.g. with ISO 646 appearing before ISO 10646). > > > > [ISO639-1] International Organization for Standardization, "ISO > > 639-1:2002. Codes for the representation of names of > languages -- Part 1: > > Alpha-2 code," 2002. > > > > -----> Delete the "International Organization for > Standardization, " part; > [Addison Phillips] > > The XML format requires an author. > > > replace the > > "--" by an em dash; the comma should be after the quote > mark; replace the > > redundant "2002" > > by "first edition" (also redundant, but not obviously so). > [Addison Phillips] > > "em dash" is not an ISO 646 ASCII character and is forbidden > by rule in an RFC. The double-dash is preserved as the way of > representing the em dash in text from RFC 3066, etc. > > The date is required by the XML format used to author the > document. I *must* put in a date, so this date makes sense. > > All of these apply to the other ISO standards referenced. > > > > > [ISO10646] International Organization for Standardization, "ISO/IEC > > 10646-1:2000. Information technology - Universal > Multiple-Octet Coded > > Character Set (UCS) - Part 1: Architecture and Basic > Multilingual Plane > > and ISO/IEC 10646-2:2001. Information technology - Universal > > Multiple-Octet Coded Character Set (UCS) - Part 2: > Supplementary Planes, > > as, from time to time, amended, replaced by a new edition > or expanded by > > the addition of new parts," 2000. > > > > > > replace "-1:2000" > > by ":2003"; > [Addison Phillips] > > Okay. > > > delete "- Part 1: Architecture and Basic Multilingual Plane > > and ISO/IEC 10646-2:2001. Information technology - Universal > > Multiple-Octet Coded Character Set (UCS) - Part 2: > Supplementary Planes, > > as, from time to time, amended, replaced by a new edition > or expanded by > > the addition of new parts," 2000"; add "first edition" > (yes, it is the > > first *merged* edition). > [Addison Phillips] > > Okay. > > > > [RFC2234bis] Crocker, D. and P. Overell, "Augmented BNF for Syntax > > Specifications: ABNF," draft-crocker-abnf-rfc2234bis-00 (work in > > progress), March 2005. > > > > -----> this one seems out of sort order. > [Addison Phillips] > > It is. > > > > [ISO646] ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, > Information technology > > -- ISO 7-bit coded character set for information > interchange.," 1991. > > > > -----> delete the "ISO/IEC 646 JTC 1/SC 2, " part; replace > the ".," 1991", > > by '", third edition'. > > > This one should have an author of "International Organization > for Standardization" too :-) > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 17:48:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04cn-0002Ea-EB; Tue, 02 Aug 2005 17:48:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04cm-0002EV-C0 for ltru@megatron.ietf.org; Tue, 02 Aug 2005 17:48:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19150 for ; Tue, 2 Aug 2005 17:48:33 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E059J-0004EY-QV for ltru@ietf.org; Tue, 02 Aug 2005 18:22:15 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j72LmPxk305284 for ; Tue, 2 Aug 2005 17:48:25 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j72LmW4l192740 for ; Tue, 2 Aug 2005 15:48:32 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j72LmO9S019032 for ; Tue, 2 Aug 2005 15:48:24 -0600 Received: from markdavis (sig-9-48-121-24.mts.ibm.com [9.48.121.24]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j72LmM6w018911; Tue, 2 Aug 2005 15:48:24 -0600 Message-ID: <00eb01c597ab$e7803cb0$18793009@sanjose.ibm.com> From: "Mark Davis" To: "Kent Karlsson" , "LTRU Working Group" References: <61828.83.248.26.202.1123015602.squirrel@webmail.chalmers.se> Subject: Re: [Ltru] revised editor's copy online Date: Tue, 2 Aug 2005 14:48:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j72LmPxk305284 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org These are all "nice to haves", not showstoppers. =E2=80=8EMark ----- Original Message -----=20 From: "Kent Karlsson" To: "LTRU Working Group" Sent: Tuesday, August 02, 2005 13:46 Subject: RE: [Ltru] revised editor's copy online 1. You used en dash in the 10646 reference, and a single - in the 639-2 reference... 2. Use ISO/IEC or ISO as "author", remove the date after the standards number, keeping it at the end (the repetition is annoying), just the year number. If it is an ISO/IEC standard, using just "International Oragization for Standardisation" as author would be inappropriate. 3. Include edition number as well (I see no reason not to), outside of the quoted title (it is not part of the title). Preferebly the standards number should be outside of (before) the quoted title too. 4. Sort all the ISO/IEC (and ISO and IEC) references by number. I see no reason to do otherwise here (like grouping related standards together). /kent k > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Tuesday, August 02, 2005 5:56 PM > To: Kent Karlsson > Cc: LTRU Working Group; Doug Ewell > Subject: RE: [Ltru] revised editor's copy online > > > Notes follow. > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: Kent Karlsson [mailto:kentk@cs.chalmers.se] > > Sent: 2005?8?2? 8:27 > > To: Addison Phillips > > Cc: LTRU Working Group; Doug Ewell > > Subject: Re: [Ltru] revised editor's copy online > > > > Addison wrote: > > > > > incorporate Kent's suggestions for the ISO references (and > > > think I might have succeeded). The HTML of the references > > > isn't very nice looking, but the text version (which is what > > > counts, after all) looks more-or-less like Kent's > > > suggestions. I opted for consistency in doing the formatting, > > > > Hmm, I do *not* notice that... > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html > [Addison Phillips] > > Not all of your requested changes are possible. > > > > -----> What is the sort order for the references?? ISO > references should > > be in numeric order > > (by standard number). > [Addison Phillips] > > The ISO references are in an order: the ones used as subtag > sources are grouped together at the top in the order they are > used in a language tag. The remaining references could be > grouped differently (e.g. with ISO 646 appearing before ISO 10646). > > > > [ISO639-1] International Organization for Standardization, "ISO > > 639-1:2002. Codes for the representation of names of > languages -- Part 1: > > Alpha-2 code," 2002. > > > > -----> Delete the "International Organization for > Standardization, " part; > [Addison Phillips] > > The XML format requires an author. > > > replace the > > "--" by an em dash; the comma should be after the quote > mark; replace the > > redundant "2002" > > by "first edition" (also redundant, but not obviously so). > [Addison Phillips] > > "em dash" is not an ISO 646 ASCII character and is forbidden > by rule in an RFC. The double-dash is preserved as the way of > representing the em dash in text from RFC 3066, etc. > > The date is required by the XML format used to author the > document. I *must* put in a date, so this date makes sense. > > All of these apply to the other ISO standards referenced. > > > > > [ISO10646] International Organization for Standardization, "ISO/IEC > > 10646-1:2000. Information technology - Universal > Multiple-Octet Coded > > Character Set (UCS) - Part 1: Architecture and Basic > Multilingual Plane > > and ISO/IEC 10646-2:2001. Information technology - Universal > > Multiple-Octet Coded Character Set (UCS) - Part 2: > Supplementary Planes, > > as, from time to time, amended, replaced by a new edition > or expanded by > > the addition of new parts," 2000. > > > > > > replace "-1:2000" > > by ":2003"; > [Addison Phillips] > > Okay. > > > delete "- Part 1: Architecture and Basic Multilingual Plane > > and ISO/IEC 10646-2:2001. Information technology - Universal > > Multiple-Octet Coded Character Set (UCS) - Part 2: > Supplementary Planes, > > as, from time to time, amended, replaced by a new edition > or expanded by > > the addition of new parts," 2000"; add "first edition" > (yes, it is the > > first *merged* edition). > [Addison Phillips] > > Okay. > > > > [RFC2234bis] Crocker, D. and P. Overell, "Augmented BNF for Syntax > > Specifications: ABNF," draft-crocker-abnf-rfc2234bis-00 (work in > > progress), March 2005. > > > > -----> this one seems out of sort order. > [Addison Phillips] > > It is. > > > > [ISO646] ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, > Information technology > > -- ISO 7-bit coded character set for information > interchange.," 1991. > > > > -----> delete the "ISO/IEC 646 JTC 1/SC 2, " part; replace > the ".," 1991", > > by '", third edition'. > > > This one should have an author of "International Organization > for Standardization" too :-) > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 21:46:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E08L2-0000UY-R2; Tue, 02 Aug 2005 21:46:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E08L1-0000R0-2M for ltru@megatron.ietf.org; Tue, 02 Aug 2005 21:46:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00296 for ; Tue, 2 Aug 2005 21:46:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E08rb-0004Ir-RZ for ltru@ietf.org; Tue, 02 Aug 2005 22:20:12 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E08Kv-0003AG-Ei; Tue, 02 Aug 2005 18:46:25 -0700 Message-Id: <6.2.1.2.2.20050802204848.0461fb20@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 03 Aug 2005 00:50:15 +0200 To: "Addison Phillips" From: r&d afrac Subject: RE: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C4AB498@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C4AB498@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 18:30 02/08/2005, Addison Phillips said: >It does not work with "most" implementations and does not conform to the >ABNF if the subtags exceed 8 characters or include the characters colon or >dot. Try inputting your example into Mozilla (gee... it rejects the tag as >invalid) This is exactly what we want, don't we? I do not represent every need in town: I am not interested in old Mozilla! >You can, of course, write an I-D (many of us have asked, nay, begged you >to do so for lo these past many months). Whether it gains acceptance or >not is dependent on the usual factors. May the best solution win. It was clearly useless in this WG. I wanted to call on ADs to demonstrate that through so many tricks the target was the protection of a commercial dominance against open source, user grassroots and industry competition. Thank you to spare me and the AD that load. You confuse standardisation and competition. There is no competing solutions, nobody wants to "win" here. The best solution is the one cute enough to "best" support the needs of _everyone_. The only winner is to be the user. You just failed that with your Draft. I asked, nay, begged you to succeed for eight months in changing one single word. Again and again. But you wanted to "win". To show you had the "best" solution. The "0-" escape sequence was most probably the best solution I could find to save _your_ Draft. IETF is a network standardisation body for a global network. Layer 8 bias, petty competition spirit as I suffered it is not only absurd, but totally counter productive. RFC 3869 says that if R&D funding mainly commercial, the Internet is in trouble: you demonstrated it. Worse you exposed it. This poor for the IETF image and bad for image of the supporting coporations. All the more than it will call the attention on the poor level of preparatory research and of multilingual network architecture vision. Had you worked a few days on the Charter to try understanding why RFC 3066 is inadequate you would have realised that the problem is with the choice of ISO typographer codes to document community relational exchanges. But .... you obviously know better. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 02 21:46:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E08L3-0000VC-06; Tue, 02 Aug 2005 21:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E08L1-0000R5-2P for ltru@megatron.ietf.org; Tue, 02 Aug 2005 21:46:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00295 for ; Tue, 2 Aug 2005 21:46:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E08rb-0004Is-Rd for ltru@ietf.org; Tue, 02 Aug 2005 22:20:12 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E08Kw-0003AG-PT; Tue, 02 Aug 2005 18:46:27 -0700 Message-Id: <6.2.1.2.2.20050803005101.05833890@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 03 Aug 2005 03:46:20 +0200 To: Randy Presuhn , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax In-Reply-To: <10021024.1123002608544.JavaMail.root@wamui-valley.atl.sa.e arthlink.net> References: <10021024.1123002608544.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 19:10 02/08/2005, Randy Presuhn wrote: >Hi - > > From: r&d afrac > > Sent: Aug 2, 2005 11:23 AM > > To: Erkki Kolehmainen , > > Randy Presuhn > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] [psg.com #1092] WGLC treat 0- as escape from syntax > > > > At 15:24 02/08/2005, Erkki Kolehmainen wrote: > > >As this 0- would not be understood by any current implementation to be an > > >absolute escape sequence, which could be followed by any syntax, I'm > > >against its inclusion in the present memo. > > > > ??? Why? It conforms to the ABNF. Then what would be the result? > >The string "0-" conforms to the ABNF. The rest of your proposal does not. ??? Most surprising since there is nothing else to consider after "0-" :-) > > Interesting since people are going to use it anyway. > >Fine; they'd just not be in conformance to the spec. >Time will tell whether the market will endorse non-conformance. Which specs? Oh you mean the Draft? Do you really believe that it will make an RFC withough the "0-" escape sequence? > > And Randy just said he would not oppose. Or you mean that Randy is joking > > at me? >... >Submitting an i-d requesting registration of 0- is the correct procedural >path, as outlined in the current registry i-d. As for the content of your >i-d, I reserve comment until it appears. Oh! you were right, God the Randy was joking at me! jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 00:30:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Au3-00073w-Tn; Wed, 03 Aug 2005 00:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Au2-00072F-2D for ltru@megatron.ietf.org; Wed, 03 Aug 2005 00:30:50 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06497 for ; Wed, 3 Aug 2005 00:30:46 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050803043018.VAQL29002.mta9.adelphia.net@DEWELL> for ; Wed, 3 Aug 2005 00:30:18 -0400 Message-ID: <00e901c597e3$f7daa900$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050802215138.NHMD3015.mta3.adelphia.net@megatron.ietf.org> Date: Tue, 2 Aug 2005 21:29:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: revised editor's copy online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: > 1. You used en dash in the 10646 reference, and a single - in the > 639-2 reference... I agree that parallel constructions should be represented in a parallel way. Either both should use a single dash, or both should use a double dash. The same goes for cases where the HTML version contains an en dash or em dash. But as Mark said, this is not really a Last Call showstopper, and could be handled by the draft editor(s). And as Randy said, RFCs aren't really allowed to have em dashes anyway. > 2. Use ISO/IEC or ISO as "author", remove the date after the standards > number, keeping it at the end (the repetition is annoying), just the > year number. If it is an ISO/IEC standard, using just > "International Oragization for Standardisation" as author would be > inappropriate. Could you provide a complete example of how you would like this to appear? Remember that xml2rfc requires explicit author, title, and date fields. Leaving the author out because the standard is called "ISO something" won't work. > 3. Include edition number as well (I see no reason not to), outside > of the quoted title (it is not part of the title). Preferebly the > standards number should be outside of (before) the quoted title too. What goes inside quotes and what goes outside is not up to us. We specify text for the fields, and xml2rfc formats them. > 4. Sort all the ISO/IEC (and ISO and IEC) references by number. > I see no reason to do otherwise here (like grouping related standards > together). My opinion is that all references should be sorted mechanically, using . This prevents manual errors and arguments. It does sort alphabetically, not numerically, which unfortunately results in ISO15924 < ISO3166 < ISO639 rather than the other way around. But at least it's deterministic. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 01:39:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Byb-00057Q-Jz; Wed, 03 Aug 2005 01:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ByY-00055l-AM for ltru@megatron.ietf.org; Wed, 03 Aug 2005 01:39:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09570 for ; Wed, 3 Aug 2005 01:39:33 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0CV9-0004JL-QV for ltru@ietf.org; Wed, 03 Aug 2005 02:13:17 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 22:39:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] putative issue [#1092] Date: Tue, 2 Aug 2005 22:39:14 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C5A7701@irvmbxw01.quest.com> Thread-Topic: [Ltru] putative issue [#1092] Thread-Index: AcWXzSoyCsRfNeuCRm+CL7/4YeV9xAAIDIQg From: "Addison Phillips" To: X-OriginalArrivalTime: 03 Aug 2005 05:39:15.0661 (UTC) FILETIME=[AF745FD0:01C597ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Shame on me for feeding the troll. Draft-10 will be submitted in the morning, when I get back to a high = speed connection. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 03:50:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0E1h-0004jb-3P; Wed, 03 Aug 2005 03:50:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0E1f-0004fS-Aa for ltru@megatron.ietf.org; Wed, 03 Aug 2005 03:50:55 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22369 for ; Wed, 3 Aug 2005 03:50:53 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E0E0V-0003jo-Q8 for ltru@lists.ietf.org; Wed, 03 Aug 2005 09:49:43 +0200 Received: from c-180-161-32.hh.dial.de.ignite.net ([62.180.161.32]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Aug 2005 09:49:43 +0200 Received: from nobody by c-180-161-32.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Aug 2005 09:49:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 03 Aug 2005 09:48:33 +0200 Organization: Lines: 11 Message-ID: <42F076D1.58BC@xyzzy.claranet.de> References: <20050802215138.NHMD3015.mta3.adelphia.net@megatron.ietf.org> <00e901c597e3$f7daa900$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-32.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: revised editor's copy online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > as Mark said, this is not really a Last Call showstopper, > and could be handled by the draft editor(s). And as Randy > said, RFCs aren't really allowed to have em dashes anyway. FWIW, new xml2rfc versions "translate" — into "--". If you want it you're free to use it. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 07:57:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Hs2-00043h-Dh; Wed, 03 Aug 2005 07:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Hs0-00043c-Ib for ltru@megatron.ietf.org; Wed, 03 Aug 2005 07:57:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07805 for ; Wed, 3 Aug 2005 07:57:11 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0IOf-0004QW-Qt for ltru@ietf.org; Wed, 03 Aug 2005 08:30:59 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E0Hrt-0008D7-84; Wed, 03 Aug 2005 04:57:05 -0700 Message-Id: <6.2.1.2.2.20050803115158.04cf6b50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 03 Aug 2005 11:59:32 +0200 To: "Addison Phillips" From: r&d afrac Subject: RE: [Ltru] putative issue [#1092] In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C5A7701@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C5A7701@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 07:39 03/08/2005, Addison Phillips said: >Shame on me for feeding the troll. There is no shame to tell the truth. Obviously, the truth you signed will not help your plans. But it will help users a lot. Is it not what you ultimately want? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 10:18:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Jyn-0000Qm-Or; Wed, 03 Aug 2005 10:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Jym-0000QW-3n for ltru@megatron.ietf.org; Wed, 03 Aug 2005 10:12:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19144 for ; Wed, 3 Aug 2005 10:12:17 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0KVR-00031P-LM for ltru@ietf.org; Wed, 03 Aug 2005 10:46:07 -0400 X-Medic-Info: 2249.42f0d0bf.0 iZYTGPCQNty3xyuP Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 84DED407D; Wed, 3 Aug 2005 16:12:15 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Wed, 3 Aug 2005 16:12:15 +0200 (CEST) Message-ID: <63034.83.248.26.202.1123078335.squirrel@webmail.chalmers.se> In-Reply-To: <00e901c597e3$f7daa900$030aa8c0@DEWELL> References: <20050802215138.NHMD3015.mta3.adelphia.net@megatron.ietf.org> <00e901c597e3$f7daa900$030aa8c0@DEWELL> Date: Wed, 3 Aug 2005 16:12:15 +0200 (CEST) Subject: Re: [Ltru] Re: revised editor's copy online From: "Kent Karlsson" To: "Doug Ewell" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050803161215_45528" X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org ------=_20050803161215_45528 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Could you provide a complete example of how you would like this to > appear? Remember that xml2rfc requires explicit author, title, and dat= e > fields. Leaving the author out because the standard is called "ISO > something" won't work. Well, if the tool does not check things that should go unchecked, the XML exerpt below (and attached) should work. (I haven't installed the xml2rfc tool...) > What goes inside quotes and what goes outside is not up to us. We > specify text for the fields, and xml2rfc formats them. Bad tool, bad tool! ;-) > My opinion is that all references should be sorted mechanically, using > . This prevents manual errors and arguments. = It > does sort alphabetically, not numerically, which unfortunately results > in ISO15924 < ISO3166 < ISO639 rather than the other way around. But a= t > least it's deterministic. I've sorted them. I also moved non-normative references to the informative references section. In addition I noticed a problem. ISO 3166:1988 has been divided into parts, out of which ISO 3166-1:1997 and ISO 3166-3:1999 seem to be the ones to reference. /kent k Information technology — ISO 7-bit coded character set fo= r information interchange ISO/IEC 646:1991 This standard defines an International Reference Version (IRV) which corresponds exactly to what is widely known as ASCII or US-ASCII. ISO/IEC 646 was based on the earlier standard ECMA-6. ECMA has maintained its standard up to date with respect to ISO/IEC 646 and makes an electronic copy available at http://www.ecma-international.org/publications/standards/Ecma-006.htm= Codes for the representation of names of languages — Part 1: Alpha-2 code ISO 639-1:2002 Codes for the representation of names of languages — Part 2: Alpha-3 code ISO 639-2:1998 Codes for the representation of names of countries and their subdivisions — Part 1: Country codes ISO 3166-1:1997 Codes for the representation of names of countries and their subdivisions &mdash Part 3: Code for formerly used names of countries ISO 3166-1:1999 Information technology — Universal multiple-octet coded character set (UCS) ISO/IEC 10646:2003 The 2003 version is the first merged edition of 10646; older versions came in two parts. Information and documentation — Codes for the representation of names of scripts ISO 15924:2004 &rfc2026; &rfc2028; &rfc2047; &rfc2119; Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a format syntax. Over the years a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. &rfc2860; &rfc3339; Standard Country or Area Codes for Statistical Use United Nations Statistics Division Working principles for ISO 639 maintenance ISO 639 Joint Advisory Committee The Art of Unix Programming This book contains the reference to the record-jar format in chapter 5. An online version is here: http://www.faqs.org/docs/artu/ch05s02.html#id2906931. &rfc1766; &rfc2231; &rfc2434; &rfc2781; &rfc3066; &rfc3552; Initial Language Subtag Registry LTRU Working Group The Unicode Standard, Version 4.1.0 The Unicode Consortium Extensible Markup Language (XML) 1.0 (third edition) XML Schema &mdash Part 2: Datatypes (second edition) ------=_20050803161215_45528 Content-Type: application/octet-stream; name="references.txt" Content-Disposition: attachment; filename="references.txt" Content-Transfer-Encoding: base64 DQo8cmVmZXJlbmNlcyB0aXRsZT0iTm9ybWF0aXZlIFJlZmVyZW5jZXMiPg0KDQo8cmVmZXJlbmNl IGFuY2hvcj0iSVNPNjQ2Ij48ZnJvbnQ+DQogICA8dGl0bGU+SW5mb3JtYXRpb24gdGVjaG5vbG9n eSAmbWRhc2g7IElTTyA3LWJpdCBjb2RlZCBjaGFyYWN0ZXIgc2V0IGZvciBpbmZvcm1hdGlvbiBp bnRlcmNoYW5nZTwvdGl0bGU+DQogICA8YXV0aG9yPjxvcmdhbml6YXRpb24+SVNPL0lFQyA2NDY6 MTk5MTwvb3JnYW5pemF0aW9uPjwvYXV0aG9yPg0KICAgPGRhdGUgeWVhcj0idGhpcmQgZWRpdGlv biIvPg0KICAgPGFic3RyYWN0Pjx0PlRoaXMgc3RhbmRhcmQgZGVmaW5lcyBhbiBJbnRlcm5hdGlv bmFsIFJlZmVyZW5jZSBWZXJzaW9uIChJUlYpIHdoaWNoIGNvcnJlc3BvbmRzIGV4YWN0bHkgdG8g d2hhdCBpcyB3aWRlbHkga25vd24gYXMgQVNDSUkgb3IgVVMtQVNDSUkuIElTTy9JRUMgNjQ2IHdh cyBiYXNlZCBvbiB0aGUgZWFybGllciBzdGFuZGFyZCBFQ01BLTYuIEVDTUEgaGFzIG1haW50YWlu ZWQgaXRzIHN0YW5kYXJkIHVwIHRvIGRhdGUgd2l0aCByZXNwZWN0IHRvIElTTy9JRUMgNjQ2IGFu ZCBtYWtlcyBhbiBlbGVjdHJvbmljIGNvcHkgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuZWNtYS1p bnRlcm5hdGlvbmFsLm9yZy9wdWJsaWNhdGlvbnMvc3RhbmRhcmRzL0VjbWEtMDA2Lmh0bTwvdD48 L2Fic3RyYWN0Pg0KPC9mcm9udD48L3JlZmVyZW5jZT4NCg0KPHJlZmVyZW5jZSBhbmNob3I9IklT TzYzOS0xIj48ZnJvbnQ+DQogICA8dGl0bGU+Q29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBv ZiBuYW1lcyBvZiBsYW5ndWFnZXMgJm1kYXNoOyBQYXJ0IDE6IEFscGhhLTIgY29kZTwvdGl0bGU+ DQogICA8YXV0aG9yPjxvcmdhbml6YXRpb24+SVNPIDYzOS0xOjIwMDI8L29yZ2FuaXphdGlvbj48 L2F1dGhvcj4NCiAgIDxkYXRlIHllYXI9ImZpcnN0IGVkaXRpb24iLz4NCjwvZnJvbnQ+PC9yZWZl cmVuY2U+DQoNCjxyZWZlcmVuY2UgYW5jaG9yPSJJU082MzktMiI+PGZyb250Pg0KICAgPHRpdGxl PkNvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgbGFuZ3VhZ2VzICZtZGFz aDsgUGFydCAyOiBBbHBoYS0zIGNvZGU8L3RpdGxlPg0KICAgPGF1dGhvcj48b3JnYW5pemF0aW9u PklTTyA2MzktMjoxOTk4PC9vcmdhbml6YXRpb24+PC9hdXRob3I+DQogICA8ZGF0ZSB5ZWFyPSJm aXJzdCBlZGl0aW9uIi8+DQo8L2Zyb250PjwvcmVmZXJlbmNlPg0KDQo8IS0tDQo8cmVmZXJlbmNl IGFuY2hvcj0iSVNPMzE2NiI+PGZyb250Pg0KICAgPHRpdGxlPkNvZGVzIGZvciB0aGUgcmVwcmVz ZW50YXRpb24gb2YgbmFtZXMgb2YgY291bnRyaWVzPC90aXRsZT4NCiAgIDxhdXRob3I+PG9yZ2Fu aXphdGlvbj5JU08gMzE2NjoxOTg4PC9vcmdhbml6YXRpb24+PC9hdXRob3I+DQogICA8ZGF0ZSB5 ZWFyPSJ0aGlyZCBlZGl0aW9uIi8+DQo8L2Zyb250PjwvcmVmZXJlbmNlPg0KLS0+DQoNCjxyZWZl cmVuY2UgYW5jaG9yPSJJU08zMTY2LTEiPjxmcm9udD4NCiAgIDx0aXRsZT5Db2RlcyBmb3IgdGhl IHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcyBhbmQgdGhlaXIgc3ViZGl2aXNp b25zICZtZGFzaDsgUGFydCAxOiBDb3VudHJ5IGNvZGVzPC90aXRsZT4NCiAgIDxhdXRob3I+PG9y Z2FuaXphdGlvbj5JU08gMzE2Ni0xOjE5OTc8L29yZ2FuaXphdGlvbj48L2F1dGhvcj4NCiAgIDxk YXRlIHllYXI9ImZpcnN0IGVkaXRpb24iLz4NCjwvZnJvbnQ+PC9yZWZlcmVuY2U+DQoNCjxyZWZl cmVuY2UgYW5jaG9yPSJJU08zMTY2LTMiPjxmcm9udD4NCiAgIDx0aXRsZT5Db2RlcyBmb3IgdGhl IHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcyBhbmQgdGhlaXIgc3ViZGl2aXNp b25zICZtZGFzaCBQYXJ0IDM6IENvZGUgZm9yIGZvcm1lcmx5IHVzZWQgbmFtZXMgb2YgY291bnRy aWVzPC90aXRsZT4NCiAgIDxhdXRob3I+PG9yZ2FuaXphdGlvbj5JU08gMzE2Ni0xOjE5OTk8L29y Z2FuaXphdGlvbj48L2F1dGhvcj4NCiAgIDxkYXRlIHllYXI9ImZpcnN0IGVkaXRpb24iLz4NCjwv ZnJvbnQ+PC9yZWZlcmVuY2U+DQoNCjxyZWZlcmVuY2UgYW5jaG9yPSJJU08xMDY0NiI+PGZyb250 Pg0KICAgPHRpdGxlPkluZm9ybWF0aW9uIHRlY2hub2xvZ3kgJm1kYXNoOyBVbml2ZXJzYWwgbXVs dGlwbGUtb2N0ZXQgY29kZWQgY2hhcmFjdGVyIHNldCAoVUNTKTwvdGl0bGU+DQogICA8YXV0aG9y Pjxvcmdhbml6YXRpb24+SVNPL0lFQyAxMDY0NjoyMDAzPC9vcmdhbml6YXRpb24+PC9hdXRob3I+ DQogICA8ZGF0ZSB5ZWFyPSJmaXJzdCBlZGl0aW9uIi8+DQogICA8YWJzdHJhY3Q+PHQ+VGhlIDIw MDMgdmVyc2lvbiBpcyB0aGUgZmlyc3QgbWVyZ2VkIGVkaXRpb24gb2YgMTA2NDY7IG9sZGVyIHZl cnNpb25zIGNhbWUgaW4gdHdvIHBhcnRzLjwvdD48L2Fic3RyYWN0Pg0KPC9mcm9udD48L3JlZmVy ZW5jZT4NCg0KPHJlZmVyZW5jZSBhbmNob3I9IklTTzE1OTI0Ij48ZnJvbnQ+DQogICA8dGl0bGU+ SW5mb3JtYXRpb24gYW5kIGRvY3VtZW50YXRpb24gJm1kYXNoOyBDb2RlcyBmb3IgdGhlIHJlcHJl c2VudGF0aW9uIG9mIG5hbWVzIG9mIHNjcmlwdHM8L3RpdGxlPg0KICAgPGF1dGhvcj48b3JnYW5p emF0aW9uPklTTyAxNTkyNDoyMDA0PC9vcmdhbml6YXRpb24+PC9hdXRob3I+DQogICA8ZGF0ZSB5 ZWFyPSJmaXJzdCBlZGl0aW9uIi8+DQo8L2Zyb250PjwvcmVmZXJlbmNlPg0KDQomcmZjMjAyNjsN Cg0KICAmcmZjMjAyODsNCg0KICAmcmZjMjA0NzsNCg0KJnJmYzIxMTk7DQoNCjxyZWZlcmVuY2Ug YW5jaG9yPSJSRkMyMjM0YmlzIj48ZnJvbnQ+DQogICA8dGl0bGU+QXVnbWVudGVkIEJORiBmb3Ig U3ludGF4IFNwZWNpZmljYXRpb25zOiBBQk5GPC90aXRsZT4NCiAgIDxhdXRob3IgaW5pdGlhbHM9 IkQiIHN1cm5hbWU9IkNyb2NrZXIiIGZ1bGxuYW1lPSJEYXZlIENyb2NrZXIiPjxvcmdhbml6YXRp b24vPjwvYXV0aG9yPg0KICAgPGF1dGhvciBpbml0aWFscz0iUCIgc3VybmFtZT0iT3ZlcmVsbCIg ZnVsbG5hbWU9IlBhdWwgT3ZlcmVsbCI+PG9yZ2FuaXphdGlvbi8+PC9hdXRob3I+DQogICA8ZGF0 ZSB5ZWFyPSIyMDA1IiBtb250aD0iMDMiIGRheT0iMDkiLz4NCiAgIDxhYnN0cmFjdD48dD5JbnRl cm5ldCB0ZWNobmljYWwgc3BlY2lmaWNhdGlvbnMgb2Z0ZW4gbmVlZCB0byBkZWZpbmUgYSBmb3Jt YXQgc3ludGF4LiBPdmVyIHRoZSB5ZWFycyBhIG1vZGlmaWVkIHZlcnNpb24gb2YgQmFja3VzLU5h dXIgRm9ybSAoQk5GKSwgY2FsbGVkIEF1Z21lbnRlZCBCTkYgKEFCTkYpLCBoYXMgYmVlbiBwb3B1 bGFyIGFtb25nIG1hbnkgSW50ZXJuZXQgc3BlY2lmaWNhdGlvbnMuIFRoZSBjdXJyZW50IHNwZWNp ZmljYXRpb24gZG9jdW1lbnRzIEFCTkYuIEl0IGJhbGFuY2VzIGNvbXBhY3RuZXNzIGFuZCBzaW1w bGljaXR5LCB3aXRoIHJlYXNvbmFibGUgcmVwcmVzZW50YXRpb25hbCBwb3dlci4gVGhlIGRpZmZl cmVuY2VzIGJldHdlZW4gc3RhbmRhcmQgQk5GIGFuZCBBQk5GIGludm9sdmUgbmFtaW5nIHJ1bGVz LCByZXBldGl0aW9uLCBhbHRlcm5hdGl2ZXMsIG9yZGVyLWluZGVwZW5kZW5jZSwgYW5kIHZhbHVl IHJhbmdlcy4gVGhpcyBzcGVjaWZpY2F0aW9uIGFsc28gc3VwcGxpZXMgYWRkaXRpb25hbCBydWxl IGRlZmluaXRpb25zIGFuZCBlbmNvZGluZyBmb3IgYSBjb3JlIGxleGljYWwgYW5hbHl6ZXIgb2Yg dGhlIHR5cGUgY29tbW9uIHRvIHNldmVyYWwgSW50ZXJuZXQgc3BlY2lmaWNhdGlvbnMuPC90Pjwv YWJzdHJhY3Q+DQo8L2Zyb250Pg0KPHNlcmllc0luZm8gbmFtZT0iSW50ZXJuZXQtRHJhZnQiIHZh bHVlPSJkcmFmdC1jcm9ja2VyLWFibmYtcmZjMjIzNGJpcy0wMCIvPg0KPGZvcm1hdCB0eXBlPSJU WFQiIHRhcmdldD0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY3Jv Y2tlci1hYm5mLXJmYzIyMzRiaXMtMDAudHh0Ii8+DQo8L3JlZmVyZW5jZT4NCg0KJnJmYzI4NjA7 DQoNCiZyZmMzMzM5Ow0KDQo8cmVmZXJlbmNlIGFuY2hvcj0iVU5fTS40OSIgdGFyZ2V0PSJodHRw Oi8vdW5zdGF0cy51bi5vcmcvdW5zZC9tZXRob2RzL200OS9tNDkuaHRtIj48ZnJvbnQ+DQogICA8 dGl0bGU+U3RhbmRhcmQgQ291bnRyeSBvciBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2U8 L3RpdGxlPg0KICAgPGF1dGhvcj48b3JnYW5pemF0aW9uPlVuaXRlZCBOYXRpb25zIFN0YXRpc3Rp Y3MgRGl2aXNpb248L29yZ2FuaXphdGlvbj48L2F1dGhvcj4NCiAgIDxkYXRlIHllYXI9IjIwMDQi IG1vbnRoPSIwMyIgZGF5PSIwOCIvPg0KPC9mcm9udD4NCjxzZXJpZXNJbmZvIG5hbWU9IlVOIiB2 YWx1ZT0iU3RhbmRhcmQgQ291bnRyeSBvciBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2Us IHJldmlzaW9uIDQgKFVuaXRlZCBOYXRpb25zIHB1YmxpY2F0aW9uLCBzYWxlcyBuby4gOTguWFZJ SS45Ii8+DQo8L3JlZmVyZW5jZT4NCg0KPC9yZWZlcmVuY2VzPg0KDQoNCg0KPHJlZmVyZW5jZXMg dGl0bGU9IkluZm9ybWF0aXZlIFJlZmVyZW5jZXMiPg0KDQoNCjxyZWZlcmVuY2UgYW5jaG9yPSJp c282MzkucHJpbmNpcGxlcyIgdGFyZ2V0PSJodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lz bzYzOS0yL2lzbzYzOWphY19uM3IuaHRtbCI+PGZyb250Pg0KICAgPHRpdGxlPldvcmtpbmcgcHJp bmNpcGxlcyBmb3IgSVNPIDYzOSBtYWludGVuYW5jZTwvdGl0bGU+DQogICA8YXV0aG9yPjxvcmdh bml6YXRpb24+SVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWU8L29yZ2FuaXphdGlvbj48 L2F1dGhvcj4NCiAgIDxkYXRlIHllYXI9IjIwMDAiIG1vbnRoPSIwMyIgZGF5PSI4Ii8+DQo8L2Zy b250PjwvcmVmZXJlbmNlPg0KDQo8cmVmZXJlbmNlIGFuY2hvcj0icmVjb3JkLWphciI+PGZyb250 Pg0KICAgPHRpdGxlPlRoZSBBcnQgb2YgVW5peCBQcm9ncmFtbWluZzwvdGl0bGU+DQogICA8YXV0 aG9yIGZ1bGxuYW1lPSJFcmljIFN0ZXZlbiBSYXltb25kIiBpbml0aWFscz0iRSIgc3VybmFtZT0i UmF5bW9uZCI+PG9yZ2FuaXphdGlvbi8+PC9hdXRob3I+DQogICA8ZGF0ZSB5ZWFyPSIyMDA0Ii8+ DQogICA8bm90ZSB0aXRsZT0iTm90ZSBhYm91dCByZWNvcmQtamFyOiI+PHQ+VGhpcyBib29rIGNv bnRhaW5zIHRoZSByZWZlcmVuY2UgdG8gdGhlIHJlY29yZC1qYXIgZm9ybWF0IGluIGNoYXB0ZXIg NS4gQW4gb25saW5lIHZlcnNpb24gaXMgaGVyZTogaHR0cDovL3d3dy5mYXFzLm9yZy9kb2NzL2Fy dHUvY2gwNXMwMi5odG1sI2lkMjkwNjkzMS48L3Q+PC9ub3RlPg0KPC9mcm9udD48L3JlZmVyZW5j ZT4NCg0KJnJmYzE3NjY7DQoNCiZyZmMyMjMxOw0KDQomcmZjMjQzNDsNCg0KJnJmYzI3ODE7DQoN CiZyZmMzMDY2Ow0KDQomcmZjMzU1MjsNCg0KPHJlZmVyZW5jZSBhbmNob3I9ImluaXRpYWwtcmVn aXN0cnkiIHRhcmdldD0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1sdHJ1LWluaXRpYWwtMDIudHh0Ij48ZnJvbnQ+DQogICA8dGl0bGUgYWJicmV2PSJkcmFm dC1pZXRmLWx0cnUtaW5pdGlhbCI+SW5pdGlhbCBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnk8L3Rp dGxlPg0KICAgPGF1dGhvciBpbml0aWFscz0iRCIgc3VybmFtZT0iRXdlbGwiIGZ1bGxuYW1lPSJE b3VnIEV3ZWxsIiByb2xlPSJlZGl0b3IiPjxvcmdhbml6YXRpb24+TFRSVSBXb3JraW5nIEdyb3Vw PC9vcmdhbml6YXRpb24+PC9hdXRob3I+DQogICA8ZGF0ZSB5ZWFyPSIyMDA1IiBtb250aD0iMDci IGRheT0iMTAiLz4NCjwvZnJvbnQ+PC9yZWZlcmVuY2U+DQoNCjxyZWZlcmVuY2UgYW5jaG9yPSJV bmljb2RlIiB0YXJnZXQ9Imh0dHA6Ly93d3cudW5pY29kZS5vcmcvdmVyc2lvbnMvVW5pY29kZTQu MS4wIj48ZnJvbnQ+DQogICA8dGl0bGU+VGhlIFVuaWNvZGUgU3RhbmRhcmQsIFZlcnNpb24gNC4x LjA8L3RpdGxlPg0KICAgPGF1dGhvcj48b3JnYW5pemF0aW9uPlRoZSBVbmljb2RlIENvbnNvcnRp dW08L29yZ2FuaXphdGlvbj48L2F1dGhvcj4NCiAgIDxkYXRlIHllYXI9IjIwMDUiIG1vbnRoPSIw MyIgZGF5PSIzMSIvPg0KPC9mcm9udD48L3JlZmVyZW5jZT4NCg0KPHJlZmVyZW5jZSBhbmNob3I9 IlhNTDEwIiB0YXJnZXQ9Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDQvUkVDLXhtbC0yMDA0MDIw NCI+PGZyb250Pg0KICAgPHRpdGxlPkV4dGVuc2libGUgTWFya3VwIExhbmd1YWdlIChYTUwpIDEu MCAodGhpcmQgZWRpdGlvbik8L3RpdGxlPg0KICAgPGF1dGhvciBmdWxsbmFtZT0iVGltIEJyYXkg ZXQgYWwuIiBpbml0aWFscz0iVCIgc3VybmFtZT0iQnJheSAoZXQgYWwuKSI+PG9yZ2FuaXphdGlv bi8+PC9hdXRob3I+DQogICA8ZGF0ZSB5ZWFyPSIyMDA0IiBtb250aD0iMDIiIGRheT0iMDQiLz4N CjwvZnJvbnQ+PC9yZWZlcmVuY2U+DQoNCjxyZWZlcmVuY2UgYW5jaG9yPSJYTUxTY2hlbWEiIHRh cmdldD0iIGh0dHA6Ly93d3cudzMub3JnL1RSL3htbHNjaGVtYS0yLyI+PGZyb250Pg0KICAgPHRp dGxlPlhNTCBTY2hlbWEgJm1kYXNoIFBhcnQgMjogRGF0YXR5cGVzIChzZWNvbmQgZWRpdGlvbik8 L3RpdGxlPg0KICAgPGF1dGhvciBpbml0aWFscz0iUCIgc3VybmFtZT0iQmlyb24iIGZ1bGxuYW1l PSJQYXVsIFYuIEJpcm9uIiByb2xlPSJlZGl0b3IiPjxvcmdhbml6YXRpb24vPjwvYXV0aG9yPg0K ICAgPGF1dGhvciBpbml0aWFscz0iQSIgc3VybmFtZT0iTWFsaG90cmEiIGZ1bGxuYW1lPSJBc2hv ayBNYWxob3RyYSIgcm9sZT0iZWRpdG9yIj48b3JnYW5pemF0aW9uLz48L2F1dGhvcj4NCiAgIDxk YXRlIHllYXI9IjIwMDQiIG1vbnRoPSIxMCIgZGF5PSIyOCIvPg0KPC9mcm9udD48L3JlZmVyZW5j ZT4NCg0KDQo8L3JlZmVyZW5jZXM+DQoNCg== ------=_20050803161215_45528 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_20050803161215_45528-- From ltru-bounces@lists.ietf.org Wed Aug 03 10:30:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KGN-0003Mb-5a; Wed, 03 Aug 2005 10:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KGM-0003MU-DW for ltru@megatron.ietf.org; Wed, 03 Aug 2005 10:30:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21879 for ; Wed, 3 Aug 2005 10:30:28 -0400 (EDT) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Kn2-0004BF-WF for ltru@ietf.org; Wed, 03 Aug 2005 11:04:18 -0400 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050803143013.FPSB19267.mta10.adelphia.net@DEWELL>; Wed, 3 Aug 2005 10:30:13 -0400 Message-ID: <002401c59837$d51259a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050802215138.NHMD3015.mta3.adelphia.net@megatron.ietf.org> <00e901c597e3$f7daa900$030aa8c0@DEWELL> <63034.83.248.26.202.1123078335.squirrel@webmail.chalmers.se> Subject: Re: [Ltru] Re: revised editor's copy online Date: Wed, 3 Aug 2005 07:30:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: > Well, if the tool does not check things that should go unchecked, > the XML exerpt below (and attached) should work. (I haven't installed > the xml2rfc tool...) This works if you buy info the semantic notion that "ISO/IEC 646:1991" and such are authors, or organizations. Randy, is this (a) acceptable and (b) recommended? I wouldn't mind doing this if it would end the thread. >> My opinion is that all references should be sorted mechanically, >> using . This prevents manual errors and >> arguments. It does sort alphabetically, not numerically, which >> unfortunately results in ISO15924 < ISO3166 < ISO639 rather than the >> other way around. But at least it's deterministic. > > I've sorted them. You've placed "ISO646" before "ISO639-1" and "ISO639-2", which is neither alphabetically nor numerically correct. This demonstrates what I said about "preventing manual errors." Can't we just let the tool do its job? > I also moved non-normative references to the informative > references section. I thought that had already been resolved in draft-registry. I know it has been in draft-initial. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 11:06:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Kpa-00072U-B0; Wed, 03 Aug 2005 11:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KpY-00071T-FX for ltru@megatron.ietf.org; Wed, 03 Aug 2005 11:06:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24301 for ; Wed, 3 Aug 2005 11:06:50 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0LMF-0005ln-Ed for ltru@ietf.org; Wed, 03 Aug 2005 11:40:40 -0400 X-Medic-Info: 2a97.42f0dd88.0 5I6sIa3bEjVrxWTt Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 038833F04; Wed, 3 Aug 2005 17:06:48 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Wed, 3 Aug 2005 17:06:48 +0200 (CEST) Message-ID: <63377.83.248.26.202.1123081608.squirrel@webmail.chalmers.se> In-Reply-To: <002401c59837$d51259a0$030aa8c0@DEWELL> References: <20050802215138.NHMD3015.mta3.adelphia.net@megatron.ietf.org> <00e901c597e3$f7daa900$030aa8c0@DEWELL> <63034.83.248.26.202.1123078335.squirrel@webmail.chalmers.se> <002401c59837$d51259a0$030aa8c0@DEWELL> Date: Wed, 3 Aug 2005 17:06:48 +0200 (CEST) Subject: Re: [Ltru] Re: revised editor's copy online From: "Kent Karlsson" To: "Doug Ewell" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > I said about "preventing manual errors." Can't we just let the tool do > its job? Sure. /k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 11:38:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LKD-0003ol-VZ; Wed, 03 Aug 2005 11:38:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LKD-0003og-8W for ltru@megatron.ietf.org; Wed, 03 Aug 2005 11:38:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26204 for ; Wed, 3 Aug 2005 11:38:31 -0400 (EDT) Received: from pop05.mail.atl.earthlink.net ([207.69.200.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Lqu-000734-GU for ltru@ietf.org; Wed, 03 Aug 2005 12:12:21 -0400 Received: from wamui-chipeau.atl.sa.earthlink.net ([209.86.224.30]) by pop05.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0LJw-0005PJ-00 for ltru@ietf.org; Wed, 03 Aug 2005 11:38:16 -0400 Message-ID: <28375568.1123083496355.JavaMail.root@wamui-chipeau.atl.sa.earthlink.net> Date: Wed, 3 Aug 2005 17:38:16 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: revised editor's copy online Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: Doug Ewell > Sent: Aug 3, 2005 4:30 PM > To: LTRU Working Group > Subject: Re: [Ltru] Re: revised editor's copy online > > Kent Karlsson wrote: > > > Well, if the tool does not check things that should go unchecked, > > the XML exerpt below (and attached) should work. (I haven't installed > > the xml2rfc tool...) > > This works if you buy info the semantic notion that "ISO/IEC 646:1991" > and such are authors, or organizations. > > Randy, is this (a) acceptable and (b) recommended? I wouldn't mind > doing this if it would end the thread. For guidance I look to the references section in http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt Several of the examples there list standards organizations as the "authors" of documents. On (A), the guidelines give wide leeway to authors / editors / WGs, so the acceptability of omitting the author is something that would probably be negotiated with the RFC editor during the editing process or AUTH48. On (B), omitting the author is clearly not the recommended practice. The XML hack, while it might generate acceptible ASCII, leaves misleading tagging in the source, inviting trouble. To sum up, I think we should NOT play games with xml2rfc; doing so invites delay. To see examples of recent practice, see also ftp://ftp.rfc-editor.org/in-notes/rfc3629.txt ... > You've placed "ISO646" before "ISO639-1" and "ISO639-2", which is > neither alphabetically nor numerically correct. This demonstrates what > I said about "preventing manual errors." Can't we just let the tool do > its job? ... We should let the tool do its job. Anything else will complicate the RFC editor's job and, consequently, AUTH48. (By the way, AUTH48 generally requires a lot more than 48 hours to resolve, so, based on my personal experience as an editor, I strongly recommended doing as much as possible to avoid AUTH28 changes.) Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 14:22:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nt4-0000kL-OM; Wed, 03 Aug 2005 14:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nt3-0000k8-2R for ltru@megatron.ietf.org; Wed, 03 Aug 2005 14:22:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04888 for ; Wed, 3 Aug 2005 14:22:39 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0OPk-0005PV-B4 for ltru@ietf.org; Wed, 03 Aug 2005 14:56:30 -0400 X-Medic-Info: 3878.42f10b68.0 48YxNeg4RH1bkue4 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 9F8983EA5; Wed, 3 Aug 2005 20:22:32 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Wed, 3 Aug 2005 20:22:32 +0200 (CEST) Message-ID: <60509.83.248.26.202.1123093352.squirrel@webmail.chalmers.se> In-Reply-To: <28375568.1123083496355.JavaMail.root@wamui-chipeau.atl.sa.earthlink.net> References: <28375568.1123083496355.JavaMail.root@wamui-chipeau.atl.sa.earthlink.net> Date: Wed, 3 Aug 2005 20:22:32 +0200 (CEST) Subject: Re: [Ltru] Re: revised editor's copy online From: "Kent Karlsson" To: "Randy Presuhn" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: mrose@not.invisible.net, ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org >> Kent Karlsson wrote: >> >> > Well, if the tool does not check things that should go unchecked, >> > the XML exerpt below (and attached) should work. (I haven't installe= d >> > the xml2rfc tool...) >> >> This works if you buy info the semantic notion that "ISO/IEC 646:1991" >> and such are authors, or organizations. >> >> Randy, is this (a) acceptable and (b) recommended? I wouldn't mind >> doing this if it would end the thread. > > For guidance I look to the references section in > http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt > Several of the examples there list standards organizations as the > "authors" > of documents. On (A), the guidelines give wide leeway to authors / > editors / WGs, > so the acceptability of omitting the author is something that would > probably > be negotiated with the RFC editor during the editing process or AUTH48. > On (B), > omitting the author is clearly not the recommended practice. The XML > hack, > while it might generate acceptible ASCII, leaves misleading tagging in = the > source, > inviting trouble. To sum up, I think we should NOT play games with > xml2rfc; > doing so invites delay. The DTD/tool is in this regard too limited. It does not fit the way ISO, IEC, and ISO/IEC standards should be referenced. This should be fixed in the xml2rfc DTD and tool. Meanwhile, it is not completely out of order to consider e.g. "ISO/IEC 10646:2003" as an "author" (the WG per se is never given as author), and "first edition" as a "date". /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 15:50:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0PFk-0000Rm-KX; Wed, 03 Aug 2005 15:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0PFb-0000Or-9l; Wed, 03 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09770; Wed, 3 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0PmL-0000Es-4e; Wed, 03 Aug 2005 16:23:53 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E0PFa-0001dh-1j; Wed, 03 Aug 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 03 Aug 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-initial-03.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Initial Language Subtag Registry Author(s) : D. Ewell Filename : draft-ietf-ltru-initial-03.txt Pages : 118 Date : 2005-8-3 This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-initial-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-initial-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-3125514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-initial-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-initial-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-3125514.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@lists.ietf.org Wed Aug 03 16:53:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0QEq-0007E7-Ue; Wed, 03 Aug 2005 16:53:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0QEo-0007BH-N2 for ltru@megatron.ietf.org; Wed, 03 Aug 2005 16:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19018 for ; Wed, 3 Aug 2005 16:53:14 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0QlW-0004mn-UX for ltru@ietf.org; Wed, 03 Aug 2005 17:27:08 -0400 Received: from dul1shollenbl1 ([::ffff:213.219.159.117]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 03 Aug 2005 16:53:08 -0400 id 005647F9.42F12EB5.00003174 From: "Scott Hollenbeck" To: "'Kent Karlsson'" Subject: RE: [Ltru] Re: revised editor's copy online Date: Wed, 3 Aug 2005 16:53:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcWYWHSPQjcAGrIeQIOyY8ijXXQpZQAFIb4g In-Reply-To: <60509.83.248.26.202.1123093352.squirrel@webmail.chalmers.se> Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org FWIW you can get already-formatted versions of ISO references online: http://xml.resource.org/public/rfc/bibxml2/ (look for the "reference.ISO" files) xml2rfc can even import these directly if you wish to avoid copying them. It might make sense to just use whatever convention is followed in the online versions so that they match what the rest of the xml2rfc community is using. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 16:57:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0QJA-00009k-KE; Wed, 03 Aug 2005 16:57:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0QJ9-00009f-Rs for ltru@megatron.ietf.org; Wed, 03 Aug 2005 16:57:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19138 for ; Wed, 3 Aug 2005 16:57:43 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Qpr-0004x3-PV for ltru@ietf.org; Wed, 03 Aug 2005 17:31:37 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 13:57:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: revised editor's copy online Date: Wed, 3 Aug 2005 13:57:29 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C5A7970@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: revised editor's copy online Thread-Index: AcWYWHSPQjcAGrIeQIOyY8ijXXQpZQAFIb4gAAApE2A= From: "Addison Phillips" To: "Scott Hollenbeck" , "Kent Karlsson" X-OriginalArrivalTime: 03 Aug 2005 20:57:31.0304 (UTC) FILETIME=[F7045280:01C5986D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Good grief, why didn't I think of that!?! I already have those on disk = locally. I think I'll import those right now and end this thread here. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Scott Hollenbeck > Sent: Wednesday, August 03, 2005 1:54 PM > To: 'Kent Karlsson' > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: revised editor's copy online >=20 > FWIW you can get already-formatted versions of ISO references online: >=20 > http://xml.resource.org/public/rfc/bibxml2/ >=20 > (look for the "reference.ISO" files) >=20 > xml2rfc can even import these directly if you wish to avoid copying = them. > It might make sense to just use whatever convention is followed in the > online versions so that they match what the rest of the xml2rfc = community > is > using. >=20 > -Scott- >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 17:07:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0QST-000399-Qv; Wed, 03 Aug 2005 17:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0QSS-000394-Bx for ltru@megatron.ietf.org; Wed, 03 Aug 2005 17:07:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19462 for ; Wed, 3 Aug 2005 17:07:22 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0QzC-0005FA-F1 for ltru@ietf.org; Wed, 03 Aug 2005 17:41:15 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 14:07:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: revised editor's copy online Date: Wed, 3 Aug 2005 14:07:12 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C5A7985@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: revised editor's copy online Thread-Index: AcWYWHSPQjcAGrIeQIOyY8ijXXQpZQAFIb4gAAApE2AAAFzJ0A== From: "Addison Phillips" To: "Addison Phillips" , "Scott Hollenbeck" , "Kent Karlsson" X-OriginalArrivalTime: 03 Aug 2005 21:07:12.0685 (UTC) FILETIME=[518C05D0:01C5986F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Ah... I see... because I can't. I need the specific ISO 639 parts and = the updated ISO 10646 reference. However... I do see that my elements use the exact format = that bibxml uses. Let's go with that. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: Wednesday, August 03, 2005 1:57 PM > To: Scott Hollenbeck; Kent Karlsson > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: revised editor's copy online >=20 > Good grief, why didn't I think of that!?! I already have those on disk > locally. I think I'll import those right now and end this thread here. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Scott Hollenbeck > > Sent: Wednesday, August 03, 2005 1:54 PM > > To: 'Kent Karlsson' > > Cc: ltru@ietf.org > > Subject: RE: [Ltru] Re: revised editor's copy online > > > > FWIW you can get already-formatted versions of ISO references = online: > > > > http://xml.resource.org/public/rfc/bibxml2/ > > > > (look for the "reference.ISO" files) > > > > xml2rfc can even import these directly if you wish to avoid copying = them. > > It might make sense to just use whatever convention is followed in = the > > online versions so that they match what the rest of the xml2rfc > community > > is > > using. > > > > -Scott- > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 03 17:51:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0R9P-0001bG-Ki; Wed, 03 Aug 2005 17:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0R9O-0001ak-3z for ltru@megatron.ietf.org; Wed, 03 Aug 2005 17:51:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20983 for ; Wed, 3 Aug 2005 17:51:43 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Rg7-0006i7-Iz for ltru@ietf.org; Wed, 03 Aug 2005 18:25:37 -0400 X-Medic-Info: 4094.42f13c6c.0 c37QM9SQwqOcTjrM Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 4023E3E08; Wed, 3 Aug 2005 23:51:40 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Wed, 3 Aug 2005 23:51:40 +0200 (CEST) Message-ID: <61967.83.248.26.202.1123105900.squirrel@webmail.chalmers.se> In-Reply-To: References: <60509.83.248.26.202.1123093352.squirrel@webmail.chalmers.se> Date: Wed, 3 Aug 2005 23:51:40 +0200 (CEST) Subject: RE: [Ltru] Re: revised editor's copy online From: "Kent Karlsson" To: "Scott Hollenbeck" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > FWIW you can get already-formatted versions of ISO references online: > > http://xml.resource.org/public/rfc/bibxml2/ > > (look for the "reference.ISO" files) > > xml2rfc can even import these directly if you wish to avoid copying the= m. > It might make sense to just use whatever convention is followed in the > online versions so that they match what the rest of the xml2rfc communi= ty > is > using. > > -Scott- > So them being wrong (I looked at a sample of them) does not matter to you= ? (I will not attempt to update all those references...) /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 01:40:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0YSy-0000Qh-JG; Thu, 04 Aug 2005 01:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0YSx-0000QW-AC for ltru@megatron.ietf.org; Thu, 04 Aug 2005 01:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09817 for ; Thu, 4 Aug 2005 01:40:26 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Yzm-0005kj-Ty for ltru@ietf.org; Thu, 04 Aug 2005 02:14:23 -0400 Received: from dul1shollenbl1 ([::ffff:86.255.31.245]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 04 Aug 2005 01:40:21 -0400 id 00564870.42F1AA45.000070E1 From: "Scott Hollenbeck" To: "'Kent Karlsson'" Subject: RE: [Ltru] Re: revised editor's copy online Date: Thu, 4 Aug 2005 01:41:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcWYdYpeDITVRzCaTGC142RDriEKngAQULoQ In-Reply-To: <61967.83.248.26.202.1123105900.squirrel@webmail.chalmers.se> Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: Kent Karlsson [mailto:kentk@cs.chalmers.se] > Sent: Wednesday, August 03, 2005 5:52 PM > To: Scott Hollenbeck > Cc: 'Kent Karlsson'; ltru@ietf.org > Subject: RE: [Ltru] Re: revised editor's copy online > > > FWIW you can get already-formatted versions of ISO > references online: > > > > http://xml.resource.org/public/rfc/bibxml2/ > > > > (look for the "reference.ISO" files) > > > > xml2rfc can even import these directly if you wish to avoid > copying them. > > It might make sense to just use whatever convention is > followed in the > > online versions so that they match what the rest of the > xml2rfc community > > is > > using. > > > > -Scott- > > > > So them being wrong (I looked at a sample of them) does not > matter to you? > (I will not attempt to update all those references...) Of course it matters. If they're wrong someone should let Marshall Rose know what needs to be changed. He's usually quite good about updating references as needed. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 03:41:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0aLd-0000A6-9p; Thu, 04 Aug 2005 03:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0aLb-00009s-59 for ltru@megatron.ietf.org; Thu, 04 Aug 2005 03:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08538 for ; Thu, 4 Aug 2005 03:40:57 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0asQ-0002at-Js for ltru@ietf.org; Thu, 04 Aug 2005 04:14:55 -0400 Received: from wamui-backed.atl.sa.earthlink.net ([209.86.224.25]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0aLQ-0001f7-00 for ltru@ietf.org; Thu, 04 Aug 2005 03:40:48 -0400 Message-ID: <13919908.1123141248485.JavaMail.root@wamui-backed.atl.sa.earthlink.net> Date: Thu, 4 Aug 2005 09:40:48 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: revised editor's copy online Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: Kent Karlsson > Sent: Aug 3, 2005 8:22 PM > To: Randy Presuhn > Cc: ltru@ietf.org, mrose@not.invisible.net > Subject: Re: [Ltru] Re: revised editor's copy online ... > The DTD/tool is in this regard too limited. It does not fit the way > ISO, IEC, and ISO/IEC standards should be referenced. This should > be fixed in the xml2rfc DTD and tool. Meanwhile, it is not completely > out of order to consider e.g. "ISO/IEC 10646:2003" as an "author" (the > WG per se is never given as author), and "first edition" as a "date". ... This is really outside the scope of this WG. I suggest that you forward your concerns regarding the general format of entries to the editors of http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt This document is currently in the "IESG Evaluation" state, so going to iesg@ietf.org would make sense if its editors' rationale isn't satisfactory. For DTD issues, there is another list. Look for "xml2rfc" on the web page https://datatracker.ietf.org/public/nwg_list.cgi; I wouldn't expect much support there for formats not reasonably well aligned with 2223bis. As a technical contributor, I'd be interested in learning why "first edition" would ever be more useful than a specific date for a document. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 05:11:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0blQ-0002S5-Fp; Thu, 04 Aug 2005 05:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0blO-0002Rv-PG for ltru@megatron.ietf.org; Thu, 04 Aug 2005 05:11:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14911 for ; Thu, 4 Aug 2005 05:11:39 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cIC-0007FC-BC for ltru@ietf.org; Thu, 04 Aug 2005 05:45:39 -0400 Received: from wamui-cedar.atl.sa.earthlink.net ([209.86.224.29]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0blE-00072C-00 for ltru@ietf.org; Thu, 04 Aug 2005 05:11:32 -0400 Message-ID: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlink.net> Date: Thu, 4 Aug 2005 11:11:32 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I see the announcement for the availability of the revised initial registry draft has been sent out. (Thanks to Doug and to the Secretariat for the quick turnaround!) We'll have a BRIEF second WG last call on this document, and I'd like to limit the scope of this last call to verifying that changes agreed during the first WG last call are properly reflected by the text. (Of course, if anyone finds a substantial technical error, we'd like to hear about it now rather than waiting for the IETF last call.) This last call will end Monday, August 8. The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt I'd like those who take the time to look at this document to post a message, either to the ltru WG mailing list or to the co-chairs, indicating that they've read it and whether they are OK with it. We need this information for the paperwork we need to submit along with our request to the IESG to consider it for publication as an Informational RFC. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 06:06:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ccm-0007YI-HC; Thu, 04 Aug 2005 06:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cck-0007Y1-Gh for ltru@megatron.ietf.org; Thu, 04 Aug 2005 06:06:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18882 for ; Thu, 4 Aug 2005 06:06:47 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0d9a-0001d2-UR for ltru@ietf.org; Thu, 04 Aug 2005 06:40:48 -0400 X-Medic-Info: 687a.42f1e8b0.0 46fS1d25idbone96 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id B82343E0D; Thu, 4 Aug 2005 12:06:40 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Thu, 4 Aug 2005 12:06:40 +0200 (CEST) Message-ID: <60143.83.248.26.202.1123150000.squirrel@webmail.chalmers.se> In-Reply-To: <13919908.1123141248485.JavaMail.root@wamui-backed.atl.sa.earthlink.net> References: <13919908.1123141248485.JavaMail.root@wamui-backed.atl.sa.earthlink.net> Date: Thu, 4 Aug 2005 12:06:40 +0200 (CEST) Subject: Re: [Ltru] Re: revised editor's copy online From: "Kent Karlsson" To: "Randy Presuhn" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > This is really outside the scope of this WG. I suggest that you forwar= d > your > concerns regarding the general format of entries to the editors of > http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt > This document is currently in the "IESG Evaluation" state, so going > to iesg@ietf.org would make sense if its editors' rationale isn't > satisfactory. > > For DTD issues, there is another list. Look for "xml2rfc" on the web p= age > https://datatracker.ietf.org/public/nwg_list.cgi; I wouldn't expect muc= h > support > there for formats not reasonably well aligned with 2223bis. Ok. Thanks for the referal. But none of those updates (nor any updates of the readymade references) will be done before 8th of August (or whatever the real final date will be for -registry). > As a technical contributor, I'd be interested in learning why "first > edition" would > ever be more useful than a specific date for a document. It's not. But the date (year) is already included after the colon in "ISO/IEC 10646:2003". National standards organisations have similar conventions. For instance, ANSI uses a hyphen and year number just after the standard's number. Giving the year number later on is more than redundant, it's repetition. I think it is better to follow the convention given by the publisher in this case, rather than moving things around. It is well established practice to have the publication year just after the standard's number. The edition number is redundant, but is usually mentioned anyway. This is not just for ISO standards. Look at the XML standards for instance; they include the edition number, even in the title (which I think is not quite the right place for it). (And the current DTD required a "year"= , which is written after the title, so I put the edition number as "year".) B.t.w., within ISO, at least, undated (normative) references refers to the latest edition, including future editions when issued; while dated references refers to that specific version, while later editions may (or may not) apply. Nobody has commented on that ISO 3166 (without parts) is outdated (withdrawn), and that the current parts 1 and 3 may be what should be referenced. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 08:20:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eiP-0001ze-PG; Thu, 04 Aug 2005 08:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eiO-0001zY-6a for ltru@megatron.ietf.org; Thu, 04 Aug 2005 08:20:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01004 for ; Thu, 4 Aug 2005 08:20:46 -0400 (EDT) Received: from pop03.mail.atl.earthlink.net ([207.69.200.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0fFE-0007lD-VJ for ltru@ietf.org; Thu, 04 Aug 2005 08:54:47 -0400 Received: from wamui-backed.atl.sa.earthlink.net ([209.86.224.25]) by pop03.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0eiG-0005SK-00 for ltru@ietf.org; Thu, 04 Aug 2005 08:20:40 -0400 Message-ID: <19095338.1123158040394.JavaMail.root@wamui-backed.atl.sa.earthlink.net> Date: Thu, 4 Aug 2005 14:20:40 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Identifying correct parts / version of ISO 3166 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: Kent Karlsson > Sent: Aug 4, 2005 12:06 PM > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: revised editor's copy online ... > Ok. Thanks for the referal. But none of those updates (nor any updates > of the readymade references) will be done before 8th of August (or > whatever the real final date will be for -registry). This kind of change is of the sort that if the RFC editor considers it worthwhile, it would be made during the RFC editing cycle, and we'd then be able to check that nothing got broken during AUTH48. My experience as an editor and WG chair is that departing from convention is far more likely to cause delay than abiding by it. ... > It is well established practice to have the publication year just after > the standard's number. Different style sheets impose different requirements. I don't know whether there is a consensus among publishers. If there is, it would be worth bringing whatever it is to the attention of the rfc editor. But I wouldn't wait for it to be settled. 2223 bis has taken too many years as it is. ... > B.t.w., within ISO, at least, undated (normative) references refers to > the latest edition, including future editions when issued; while dated > references refers to that specific version, while later editions may > (or may not) apply. There is no such convention in the IETF. > Nobody has commented on that ISO 3166 (without parts) is outdated > (withdrawn), and that the current parts 1 and 3 may be what should > be referenced. ... It looks like there is a problem here. The i-d (version http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt) specifically refers to part 1 of 3166 in section 2.2.4 (2). Though clearly an editorial nit, the editors should fix this at an appropriate time. (My recommendation would be to fold it in with any changes resulting from IESG review or IETF last call, unless other issues surface before the second WG last call closes.) Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 09:25:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fit-0000AH-7j; Thu, 04 Aug 2005 09:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fis-0000AC-IN for ltru@megatron.ietf.org; Thu, 04 Aug 2005 09:25:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09561 for ; Thu, 4 Aug 2005 09:25:20 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0gFk-0002UB-TD for ltru@ietf.org; Thu, 04 Aug 2005 09:59:22 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 06:25:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: revised editor's copy online Date: Thu, 4 Aug 2005 06:25:02 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C5A7B40@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: revised editor's copy online Thread-Index: AcWY3wM+N4GlgWZBQZ6zQJOPyOHfhwAGHA4g From: "Addison Phillips" To: "Kent Karlsson" , "Randy Presuhn" X-OriginalArrivalTime: 04 Aug 2005 13:25:04.0991 (UTC) FILETIME=[ECF76EF0:01C598F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > not quite the right place for it). (And the current DTD required a = "year", > which is written after the title, so I put the edition number as = "year".) Please note that the DTD requires a element whose attributes = (day, month, and year) must be numeric values with a specific length. = That is, the "year" must be a four digit year such as 2005 and cannot be = a string such as "first edition". > Nobody has commented on that ISO 3166 (without parts) is outdated > (withdrawn), and that the current parts 1 and 3 may be what should > be referenced. In fixing draft-registry I have repaired this (I used the ISO website to = get the dates, titles, and numbers correct). A power outage has = prevented me from finalizing this, but now (as you can see) the bits are = flowing. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Kent Karlsson > Sent: 2005?8?4? 3:07 > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: revised editor's copy online >=20 > > This is really outside the scope of this WG. I suggest that you = forward > > your > > concerns regarding the general format of entries to the editors of > > = http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt > > This document is currently in the "IESG Evaluation" state, so going > > to iesg@ietf.org would make sense if its editors' rationale isn't > > satisfactory. > > > > For DTD issues, there is another list. Look for "xml2rfc" on the = web > page > > https://datatracker.ietf.org/public/nwg_list.cgi; I wouldn't expect = much > > support > > there for formats not reasonably well aligned with 2223bis. >=20 > Ok. Thanks for the referal. But none of those updates (nor any updates > of the readymade references) will be done before 8th of August (or > whatever the real final date will be for -registry). >=20 > > As a technical contributor, I'd be interested in learning why "first > > edition" would > > ever be more useful than a specific date for a document. >=20 > It's not. But the date (year) is already included after the colon in > "ISO/IEC 10646:2003". National standards organisations have similar > conventions. For instance, ANSI uses a hyphen and year number just = after > the standard's number. Giving the year number later on is more than > redundant, it's repetition. I think it is better to follow the = convention > given by the publisher in this case, rather than moving things around. > It is well established practice to have the publication year just = after > the standard's number. >=20 > The edition number is redundant, but is usually mentioned anyway. This > is not just for ISO standards. Look at the XML standards for instance; > they include the edition number, even in the title (which I think is > not quite the right place for it). (And the current DTD required a = "year", > which is written after the title, so I put the edition number as = "year".) >=20 > B.t.w., within ISO, at least, undated (normative) references refers to > the latest edition, including future editions when issued; while dated > references refers to that specific version, while later editions may > (or may not) apply. >=20 > Nobody has commented on that ISO 3166 (without parts) is outdated > (withdrawn), and that the current parts 1 and 3 may be what should > be referenced. >=20 > /kent k >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 09:50:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0g73-00005U-OJ; Thu, 04 Aug 2005 09:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0g70-0008OQ-FW; Thu, 04 Aug 2005 09:50:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11453; Thu, 4 Aug 2005 09:49:51 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0gdS-0003Y3-70; Thu, 04 Aug 2005 10:23:53 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 06:49:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C598FB.5C16A60E" Date: Thu, 4 Aug 2005 06:49:39 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C5A7B50@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: LTRU submission: draft-ietf-ltru-registry-10 Thread-Index: AcWY+0xKdNtDKqU1Q1q+mUMxbAcTWQ== From: "Addison Phillips" To: X-OriginalArrivalTime: 04 Aug 2005 13:49:39.0985 (UTC) FILETIME=[5C21A810:01C598FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff6b1d16fa9fbb5097dcac5bca183c63 Cc: ltru@ietf.org Subject: [Ltru] LTRU submission: draft-ietf-ltru-registry-10 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C598FB.5C16A60E Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIHRoZSAiLTEwIiBkcmFmdCBvZiBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnkuDQoNCkJlc3QgUmVnYXJkcywNCg0KQWRkaXNvbiAoZm9y IHRoZSBlZGl0b3JzKQ0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0Mg SW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9y Zy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUu DQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= ------_=_NextPart_001_01C598FB.5C16A60E Content-Type: text/plain; name="draft-ietf-ltru-registry-10.txt" Content-Description: draft-ietf-ltru-registry-10.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-10.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IEZlYnJ1YXJ5 IDUsIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBdWd1c3QgMDQsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTANCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBGZWJydWFyeSA1LCAyMDA2Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLg0KDQpBYnN0cmFjdA0KDQogICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgc3RydWN0dXJlLCBjb250ZW50LCBjb25zdHJ1Y3Rp b24sIGFuZA0KICAgc2VtYW50aWNzIG9mIGxhbmd1YWdlIHRhZ3MgZm9yIHVzZSBpbiBjYXNlcyB3 aGVyZSBpdCBpcyBkZXNpcmFibGUgdG8NCiAgIGluZGljYXRlIHRoZSBsYW5ndWFnZSB1c2VkIGlu IGFuIGluZm9ybWF0aW9uIG9iamVjdC4gIEl0IGFsc28NCiAgIGRlc2NyaWJlcyBob3cgdG8gcmVn aXN0ZXIgdmFsdWVzIGZvciB1c2UgaW4gbGFuZ3VhZ2UgdGFncyBhbmQgdGhlDQogICBjcmVhdGlv biBvZiB1c2VyIGRlZmluZWQgZXh0ZW5zaW9ucyBmb3IgcHJpdmF0ZSBpbnRlcmNoYW5nZS4NCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYg ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNClRhYmxlIG9m IENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFRoZSBMYW5ndWFnZSBUYWcgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDIuMSAg IFN5bnRheCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDQNCiAgICAgMi4yICAgTGFuZ3VhZ2UgU3VidGFnIFNvdXJjZXMgYW5kIEludGVycHJldGF0 aW9uIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAgIDIuMi4xICAgUHJpbWFyeSBMYW5ndWFnZSBT dWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgICAgMi4yLjIgICBF eHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAN CiAgICAgICAyLjIuMyAgIFNjcmlwdCBTdWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMA0KICAgICAgIDIuMi40ICAgUmVnaW9uIFN1YnRhZyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICAgICAgMi4yLjUgICBWYXJpYW50 IFN1YnRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgICAg ICAyLjIuNiAgIEV4dGVuc2lvbiBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxNA0KICAgICAgIDIuMi43ICAgUHJpdmF0ZSBVc2UgU3VidGFncyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1DQogICAgICAgMi4yLjggICBQcmUtRXhpc3Rpbmcg UkZDIDMwNjYgUmVnaXN0cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgICAyLjIu OSAgIENsYXNzZXMgb2YgQ29uZm9ybWFuY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNg0KICAgMy4gIFJlZ2lzdHJ5IEZvcm1hdCBhbmQgTWFpbnRlbmFuY2UgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAgIDMuMSAgIEZvcm1hdCBvZiB0aGUgSUFOQSBMYW5n dWFnZSBTdWJ0YWcgUmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gMTgNCiAgICAgMy4yICAgTWFpbnRl bmFuY2Ugb2YgdGhlIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMw0K ICAgICAzLjMgICBTdGFiaWxpdHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDI1DQogICAgIDMuNCAgIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUgZm9yIFN1 YnRhZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCiAgICAgMy41ICAgUG9zc2liaWxpdGll cyBmb3IgUmVnaXN0cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMQ0KICAgICAz LjYgICBFeHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIE5hbWVzcGFjZSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDMzDQogICAgIDMuNyAgIEluaXRpYWxpemF0aW9uIG9mIHRoZSBSZWdpc3RyeSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYNCiAgIDQuICBGb3JtYXRpb24gYW5kIFByb2Nlc3Np bmcgb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAzNw0KICAgICA0LjEgICBD aG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDM3DQogICAgIDQuMiAgIE1lYW5pbmcgb2YgdGhlIExhbmd1YWdlIFRhZyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMzkNCiAgICAgNC4zICAgTGVuZ3RoIENvbnNpZGVyYXRpb25zICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MA0KICAgICAgIDQuMy4xICAgV29y a2luZyB3aXRoIExpbWl0ZWQgQnVmZmVyIFNpemVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwDQog ICAgICAgNC4zLjIgICBUcnVuY2F0aW9uIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDINCiAgICAgNC40ICAgQ2Fub25pY2FsaXphdGlvbiBvZiBMYW5ndWFnZSBU YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Mg0KICAgICA0LjUgICBDb25zaWRlcmF0aW9u cyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0DQogICA1LiAg SUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNDYNCiAgICAgNS4xICAgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Ng0KICAgICA1LjIgICBFeHRlbnNpb25zIFJlZ2lzdHJ5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ3DQogICA2LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NDgNCiAgIDcuICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0OQ0KICAgOC4gIENoYW5nZXMgZnJvbSBSRkMgMzA2NiAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwDQogICA5LiAgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTUNCiAg ICAgOS4xICAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA1NQ0KICAgICA5LjIgICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU2DQogICAgICAgQXV0aG9ycycgQWRkcmVzc2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTcNCiAgIEEuICBB Y2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA1OA0KICAgQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3MgKEluZm9ybWF0aXZlKSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU5DQogICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFu ZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gNjINCg0KDQoNCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAg ICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQoxLiAgSW50cm9kdWN0aW9u DQoNCiAgIEh1bWFuIGJlaW5ncyBvbiBvdXIgcGxhbmV0IGhhdmUsIHBhc3QgYW5kIHByZXNlbnQs IHVzZWQgYSBudW1iZXIgb2YNCiAgIGxhbmd1YWdlcy4gIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMg d2h5IG9uZSB3b3VsZCB3YW50IHRvIGlkZW50aWZ5IHRoZQ0KICAgbGFuZ3VhZ2UgdXNlZCB3aGVu IHByZXNlbnRpbmcgb3IgcmVxdWVzdGluZyBpbmZvcm1hdGlvbi4NCg0KICAgVXNlcidzIGxhbmd1 YWdlIHByZWZlcmVuY2VzIG9mdGVuIG5lZWQgdG8gYmUgaWRlbnRpZmllZCBzbyB0aGF0DQogICBh cHByb3ByaWF0ZSBwcm9jZXNzaW5nIGNhbiBiZSBhcHBsaWVkLiAgRm9yIGV4YW1wbGUsIHRoZSB1 c2VyJ3MNCiAgIGxhbmd1YWdlIHByZWZlcmVuY2VzIGluIGEgV2ViIGJyb3dzZXIgY2FuIGJlIHVz ZWQgdG8gc2VsZWN0IFdlYiBwYWdlcw0KICAgYXBwcm9wcmlhdGVseS4gIExhbmd1YWdlIHByZWZl cmVuY2VzIGNhbiBhbHNvIGJlIHVzZWQgdG8gc2VsZWN0IGFtb25nDQogICB0b29scyAoc3VjaCBh cyBkaWN0aW9uYXJpZXMpIHRvIGFzc2lzdCBpbiB0aGUgcHJvY2Vzc2luZyBvcg0KICAgdW5kZXJz dGFuZGluZyBvZiBjb250ZW50IGluIGRpZmZlcmVudCBsYW5ndWFnZXMuDQoNCiAgIEluIGFkZGl0 aW9uLCBrbm93bGVkZ2UgYWJvdXQgdGhlIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgdXNlZCBieSBzb21l DQogICBwaWVjZSBvZiBpbmZvcm1hdGlvbiBjb250ZW50IG1pZ2h0IGJlIHVzZWZ1bCBvciBldmVu IHJlcXVpcmVkIGJ5IHNvbWUNCiAgIHR5cGVzIG9mIHByb2Nlc3Npbmc7IGZvciBleGFtcGxlIHNw ZWxsLWNoZWNraW5nLCBjb21wdXRlci1zeW50aGVzaXplZA0KICAgc3BlZWNoLCBCcmFpbGxlIHRy YW5zY3JpcHRpb24sIG9yIGhpZ2gtcXVhbGl0eSBwcmludCByZW5kZXJpbmdzLg0KDQogICBPbmUg bWVhbnMgb2YgaW5kaWNhdGluZyB0aGUgbGFuZ3VhZ2UgdXNlZCBpcyBieSBsYWJlbGluZyB0aGUN CiAgIGluZm9ybWF0aW9uIGNvbnRlbnQgd2l0aCBhbiBpZGVudGlmaWVyIG9yICJ0YWciLiAgVGhl c2UgdGFncyBjYW4gYmUNCiAgIHVzZWQgdG8gc3BlY2lmeSB1c2VyIHByZWZlcmVuY2VzIHdoZW4g c2VsZWN0aW5nIGluZm9ybWF0aW9uIGNvbnRlbnQsDQogICBvciBmb3IgbGFiZWxpbmcgYWRkaXRp b25hbCBhdHRyaWJ1dGVzIG9mIGNvbnRlbnQgYW5kIGFzc29jaWF0ZWQNCiAgIHJlc291cmNlcy4N Cg0KICAgVGFncyBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZGljYXRlIGFkZGl0aW9uYWwgbGFuZ3Vh Z2UgYXR0cmlidXRlcyBvZg0KICAgY29udGVudC4gIEZvciBleGFtcGxlLCBpbmRpY2F0aW5nIHNw ZWNpZmljIGluZm9ybWF0aW9uIGFib3V0IHRoZQ0KICAgZGlhbGVjdCwgd3JpdGluZyBzeXN0ZW0s IG9yIG9ydGhvZ3JhcGh5IHVzZWQgaW4gYSBkb2N1bWVudCBvcg0KICAgcmVzb3VyY2UgbWF5IGVu YWJsZSB0aGUgdXNlciB0byBvYnRhaW4gaW5mb3JtYXRpb24gaW4gYSBmb3JtIHRoYXQNCiAgIHRo ZXkgY2FuIHVuZGVyc3RhbmQsIG9yIGltcG9ydGFudCBpbiBwcm9jZXNzaW5nIG9yIHJlbmRlcmlu ZyB0aGUNCiAgIGdpdmVuIGNvbnRlbnQgaW50byBhbiBhcHByb3ByaWF0ZSBmb3JtIG9yIHN0eWxl Lg0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHBhcnRpY3VsYXIgaWRlbnRpZmllciBt ZWNoYW5pc20gKHRoZQ0KICAgbGFuZ3VhZ2UgdGFnKSBhbmQgYSByZWdpc3RyYXRpb24gZnVuY3Rp b24gZm9yIHZhbHVlcyB0byBiZSB1c2VkIHRvDQogICBmb3JtIHRhZ3MuICBJdCBhbHNvIGRlZmlu ZXMgYSBtZWNoYW5pc20gZm9yIHByaXZhdGUgdXNlIHZhbHVlcyBhbmQNCiAgIGZ1dHVyZSBleHRl bnNpb24uDQoNCiAgIFRoaXMgZG9jdW1lbnQgcmVwbGFjZXMgW1JGQzMwNjZdLCB3aGljaCByZXBs YWNlZCBbUkZDMTc2Nl0uICBGb3IgYQ0KICAgbGlzdCBvZiBjaGFuZ2VzIGluIHRoaXMgZG9jdW1l bnQsIHNlZSBTZWN0aW9uIDguDQoNCiAgIFRoZSBrZXl3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQg Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0K DQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFy eSA1LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0K DQoyLiAgVGhlIExhbmd1YWdlIFRhZw0KDQogICBMYW5ndWFnZSB0YWdzIGFyZSB1c2VkIHRvIGhl bHAgaWRlbnRpZnkgbGFuZ3VhZ2VzLCB3aGV0aGVyIHNwb2tlbiwNCiAgIHdyaXR0ZW4sIHNpZ25l ZCwgb3Igb3RoZXJ3aXNlIHNpZ25hbGVkLCBmb3IgdGhlIHB1cnBvc2Ugb2YNCiAgIGNvbW11bmlj YXRpb24uICBUaGlzIGluY2x1ZGVzIGNvbnN0cnVjdGVkIGFuZCBhcnRpZmljaWFsIGxhbmd1YWdl cywNCiAgIGJ1dCBleGNsdWRlcyBsYW5ndWFnZXMgbm90IGludGVuZGVkIHByaW1hcmlseSBmb3Ig aHVtYW4NCiAgIGNvbW11bmljYXRpb24sIHN1Y2ggYXMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLg0K DQoyLjEgIFN5bnRheA0KDQogICBUaGUgbGFuZ3VhZ2UgdGFnIGlzIGNvbXBvc2VkIG9mIG9uZSBv ciBtb3JlIHBhcnRzIG9yICJzdWJ0YWdzIi4gIEVhY2gNCiAgIHN1YnRhZyBjb25zaXN0cyBvZiBh IHNlcXVlbmNlIG9mIGFscGhhLW51bWVyaWMgY2hhcmFjdGVycy4gIFN1YnRhZ3MNCiAgIGFyZSBk aXN0aW5ndWlzaGVkIGFuZCBzZXBhcmF0ZWQgZnJvbSBvbmUgYW5vdGhlciBieSBhIGh5cGhlbiAo Ii0iLA0KICAgQUJORiBbUkZDMjIzNGJpc10gJXgyRCkuICBBIGxhbmd1YWdlIHRhZyBjb25zaXN0 cyBvZiBhICJwcmltYXJ5DQogICBsYW5ndWFnZSIgc3VidGFnIGFuZCBhIChwb3NzaWJseSBlbXB0 eSkgc2VyaWVzIG9mIHN1YnNlcXVlbnQgc3VidGFncywNCiAgIGVhY2ggb2Ygd2hpY2ggcmVmaW5l cyBvciBuYXJyb3dzIHRoZSByYW5nZSBvZiBsYW5ndWFnZSBpZGVudGlmaWVkIGJ5DQogICB0aGUg b3ZlcmFsbCB0YWcuDQoNCiAgIEVhY2ggdHlwZSBvZiBzdWJ0YWcgaXMgZGlzdGluZ3Vpc2hlZCBi eSBsZW5ndGgsIHBvc2l0aW9uIGluIHRoZSB0YWcsDQogICBhbmQgY29udGVudDogc3VidGFncyBj YW4gYmUgcmVjb2duaXplZCBzb2xlbHkgYnkgdGhlc2UgZmVhdHVyZXMuDQogICBUaGlzIG1ha2Vz IGl0IHBvc3NpYmxlIHRvIGNvbnN0cnVjdCBhIHBhcnNlciB0aGF0IGNhbiBleHRyYWN0IGFuZA0K ICAgYXNzaWduIHNvbWUgc2VtYW50aWMgaW5mb3JtYXRpb24gdG8gdGhlIHN1YnRhZ3MsIGV2ZW4g aWYgdGhlIHNwZWNpZmljDQogICBzdWJ0YWcgdmFsdWVzIGFyZSBub3QgcmVjb2duaXplZC4gIFRo dXMgYSBwYXJzZXIgbmVlZCBub3QgaGF2ZSBhbiB1cC0NCiAgIHRvLWRhdGUgY29weSAob3IgYW55 IGNvcHkgYXQgYWxsKSBvZiB0aGUgc3VidGFnIHJlZ2lzdHJ5IHRvIHBlcmZvcm0NCiAgIG1vc3Qg c2VhcmNoaW5nIGFuZCBtYXRjaGluZyBvcGVyYXRpb25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1DQoNCg0KICAgVGhlIHN5bnRheCBvZiB0aGUgbGFuZ3VhZ2UgdGFnIGluIEFCTkYg W1JGQzIyMzRiaXNdIGlzOg0KDQogICBMYW5ndWFnZS1UYWcgID0gbGFuZ3RhZw0KICAgICAgICAg ICAgICAgICAvIHByaXZhdGV1c2UgICAgICAgICAgICAgOyBwcml2YXRlIHVzZSB0YWcNCiAgICAg ICAgICAgICAgICAgLyBncmFuZGZhdGhlcmVkICAgICAgICAgIDsgZ3JhbmRmYXRoZXJlZCByZWdp c3RyYXRpb25zDQoNCiAgIGxhbmd0YWcgICAgICAgPSAobGFuZ3VhZ2UNCiAgICAgICAgICAgICAg ICAgICAgWyItIiBzY3JpcHRdDQogICAgICAgICAgICAgICAgICAgIFsiLSIgcmVnaW9uXQ0KICAg ICAgICAgICAgICAgICAgICAqKCItIiB2YXJpYW50KQ0KICAgICAgICAgICAgICAgICAgICAqKCIt IiBleHRlbnNpb24pDQogICAgICAgICAgICAgICAgICAgIFsiLSIgcHJpdmF0ZXVzZV0pDQoNCiAg IGxhbmd1YWdlICAgICAgPSAoMiozQUxQSEEgWyBleHRsYW5nIF0pIDsgc2hvcnRlc3QgSVNPIDYz OSBjb2RlDQogICAgICAgICAgICAgICAgIC8gNEFMUEhBICAgICAgICAgICAgICAgICA7IHJlc2Vy dmVkIGZvciBmdXR1cmUgdXNlDQogICAgICAgICAgICAgICAgIC8gNSo4QUxQSEEgICAgICAgICAg ICAgICA7IHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFnDQoNCiAgIGV4dGxhbmcgICAgICAgPSAq MygiLSIgM0FMUEhBKSAgICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UNCg0KICAgc2Ny aXB0ICAgICAgICA9IDRBTFBIQSAgICAgICAgICAgICAgICAgOyBJU08gMTU5MjQgY29kZQ0KDQog ICByZWdpb24gICAgICAgID0gMkFMUEhBICAgICAgICAgICAgICAgICA7IElTTyAzMTY2IGNvZGUN CiAgICAgICAgICAgICAgICAgLyAzRElHSVQgICAgICAgICAgICAgICAgIDsgVU4gTS40OSBjb2Rl DQoNCiAgIHZhcmlhbnQgICAgICAgPSA1KjhhbHBoYW51bSAgICAgICAgICAgIDsgcmVnaXN0ZXJl ZCB2YXJpYW50cw0KICAgICAgICAgICAgICAgICAvIChESUdJVCAzYWxwaGFudW0pDQoNCiAgIGV4 dGVuc2lvbiAgICAgPSBzaW5nbGV0b24gMSooIi0iICgyKjhhbHBoYW51bSkpDQoNCiAgIHNpbmds ZXRvbiAgICAgPSAleDQxLTU3IC8gJXg1OS01QSAvICV4NjEtNzcgLyAleDc5LTdBIC8gRElHSVQN CiAgICAgICAgICAgICAgICAgOyAiYSItInciIC8gInkiLSJ6IiAvICJBIi0iVyIgLyAiWSItIloi IC8gIjAiLSI5Ig0KICAgICAgICAgICAgICAgICA7IFNpbmdsZSBsZXR0ZXJzOiB4L1ggaXMgcmVz ZXJ2ZWQgZm9yIHByaXZhdGUgdXNlDQoNCiAgIHByaXZhdGV1c2UgICAgPSAoIngiLyJYIikgMSoo Ii0iICgxKjhhbHBoYW51bSkpDQoNCiAgIGdyYW5kZmF0aGVyZWQgPSAxKjNBTFBIQSAxKjIoIi0i ICgyKjhhbHBoYW51bSkpDQogICAgICAgICAgICAgICAgICAgOyBncmFuZGZhdGhlcmVkIHJlZ2lz dHJhdGlvbg0KICAgICAgICAgICAgICAgICAgIDsgTm90ZTogaSBpcyB0aGUgb25seSBzaW5nbGV0 b24NCiAgICAgICAgICAgICAgICAgICA7IHRoYXQgc3RhcnRzIGEgZ3JhbmRmYXRoZXJlZCB0YWcN Cg0KICAgYWxwaGFudW0gICAgICA9IChBTFBIQSAvIERJR0lUKSAgICAgICA7IGxldHRlcnMgYW5k IG51bWJlcnMNCg0KICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IExhbmd1YWdlIFRh ZyBBQk5GDQoNCiAgIE5vdGU6IFRoZXJlIGlzIGEgc3VidGxldHkgaW4gdGhlIEFCTkYgZm9yICd2 YXJpYW50JzogdmFyaWFudHMNCiAgIHN0YXJ0aW5nIHdpdGggYSBkaWdpdCBNQVkgYmUgZm91ciBj aGFyYWN0ZXJzIGxvbmcsIHdoaWxlIHRob3NlDQogICBzdGFydGluZyB3aXRoIGEgbGV0dGVyIE1V U1QgYmUgYXQgbGVhc3QgZml2ZSBjaGFyYWN0ZXJzIGxvbmcuDQoNCg0KDQoNClBoaWxsaXBzICYg RGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgICBbUGFn ZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgQWxsIHN1YnRhZ3MgaGF2ZSBhIG1heGlt dW0gbGVuZ3RoIG9mIGVpZ2h0IGNoYXJhY3RlcnMgYW5kIHdoaXRlc3BhY2UNCiAgIGlzIG5vdCBw ZXJtaXR0ZWQgaW4gYSBsYW5ndWFnZSB0YWcuICBGb3IgZXhhbXBsZXMgb2YgbGFuZ3VhZ2UgdGFn cywNCiAgIHNlZSBBcHBlbmRpeCBCLg0KDQogICBOb3RlIHRoYXQgYWx0aG91Z2ggW1JGQzIyMzRi aXNdIHJlZmVycyB0byBvY3RldHMsIHRoZSBsYW5ndWFnZSB0YWdzDQogICBkZXNjcmliZWQgaW4g dGhpcyBkb2N1bWVudCBhcmUgc2VxdWVuY2VzIG9mIGNoYXJhY3RlcnMgZnJvbSB0aGUgVVMtDQog ICBBU0NJSSBbSVNPNjQ2XSByZXBlcnRvaXJlLiAgTGFuZ3VhZ2UgdGFncyBNQVkgYmUgdXNlZCBp biBkb2N1bWVudHMNCiAgIGFuZCBhcHBsaWNhdGlvbnMgdGhhdCB1c2Ugb3RoZXIgZW5jb2Rpbmdz LCBzbyBsb25nIGFzIHRoZXNlIGVuY29tcGFzcw0KICAgdGhlIFVTLUFTQ0lJIHJlcGVydG9pcmUu ICBBbiBleGFtcGxlIG9mIHRoaXMgd291bGQgYmUgYW4gWE1MIGRvY3VtZW50DQogICB0aGF0IHVz ZXMgdGhlIFVURi0xNkxFIFtSRkMyNzgxXSBlbmNvZGluZyBvZiBbVW5pY29kZV0uDQoNCiAgIFRo ZSB0YWdzIGFuZCB0aGVpciBzdWJ0YWdzLCBpbmNsdWRpbmcgcHJpdmF0ZSB1c2UgYW5kIGV4dGVu c2lvbnMsIGFyZQ0KICAgdG8gYmUgdHJlYXRlZCBhcyBjYXNlIGluc2Vuc2l0aXZlOiB0aGVyZSBl eGlzdCBjb252ZW50aW9ucyBmb3IgdGhlDQogICBjYXBpdGFsaXphdGlvbiBvZiBzb21lIG9mIHRo ZSBzdWJ0YWdzLCBidXQgdGhlc2UgTVVTVCBOT1QgYmUgdGFrZW4gdG8NCiAgIGNhcnJ5IG1lYW5p bmcuDQoNCiAgIEZvciBleGFtcGxlOg0KDQogICBvICBbSVNPNjM5LTFdIHJlY29tbWVuZHMgdGhh dCBsYW5ndWFnZSBjb2RlcyBiZSB3cml0dGVuIGluIGxvd2VyIGNhc2UNCiAgICAgICgnbW4nIE1v bmdvbGlhbikuDQoNCiAgIG8gIFtJU08zMTY2LTFdIHJlY29tbWVuZHMgdGhhdCBjb3VudHJ5IGNv ZGVzIGJlIGNhcGl0YWxpemVkICgnTU4nDQogICAgICBNb25nb2xpYSkuDQoNCiAgIG8gIFtJU08x NTkyNF0gcmVjb21tZW5kcyB0aGF0IHNjcmlwdCBjb2RlcyB1c2UgbG93ZXIgY2FzZSB3aXRoIHRo ZQ0KICAgICAgaW5pdGlhbCBsZXR0ZXIgY2FwaXRhbGl6ZWQgKCdDeXJsJyBDeXJpbGxpYykuDQoN CiAgIEhvd2V2ZXIsIGluIHRoZSB0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCwgdGhlIHVw cGVyY2FzZSBVUy1BU0NJSQ0KICAgbGV0dGVycyBpbiB0aGUgcmFuZ2UgJ0EnIHRocm91Z2ggJ1on IGFyZSBjb25zaWRlcmVkIGVxdWl2YWxlbnQgYW5kDQogICBtYXBwZWQgZGlyZWN0bHkgdG8gdGhl aXIgVVMtQVNDSUkgbG93ZXJjYXNlIGVxdWl2YWxlbnRzIGluIHRoZSByYW5nZQ0KICAgJ2EnIHRo cm91Z2ggJ3onLiAgVGh1cyB0aGUgdGFnICJtbi1DeXJsLU1OIiBpcyBub3QgZGlzdGluY3QgZnJv bSAiTU4tDQogICBjWVJMLW1uIiBvciAibU4tY1lyTC1NbiIgKG9yIGFueSBvdGhlciBjb21iaW5h dGlvbikgYW5kIGVhY2ggb2YgdGhlc2UNCiAgIHZhcmlhdGlvbnMgY29udmV5cyB0aGUgc2FtZSBt ZWFuaW5nOiBNb25nb2xpYW4gd3JpdHRlbiBpbiB0aGUNCiAgIEN5cmlsbGljIHNjcmlwdCBhcyB1 c2VkIGluIE1vbmdvbGlhLg0KDQoyLjIgIExhbmd1YWdlIFN1YnRhZyBTb3VyY2VzIGFuZCBJbnRl cnByZXRhdGlvbg0KDQogICBUaGUgbmFtZXNwYWNlIG9mIGxhbmd1YWdlIHRhZ3MgYW5kIHRoZWly IHN1YnRhZ3MgaXMgYWRtaW5pc3RlcmVkIGJ5DQogICB0aGUgSW50ZXJuZXQgQXNzaWduZWQgTnVt YmVycyBBdXRob3JpdHkgKElBTkEpIFtSRkMyODYwXSBhY2NvcmRpbmcgdG8NCiAgIHRoZSBydWxl cyBpbiBTZWN0aW9uIDUgb2YgdGhpcyBkb2N1bWVudC4gIFRoZSByZWdpc3RyeSBtYWludGFpbmVk IGJ5DQogICBJQU5BIGlzIHRoZSBzb3VyY2UgZm9yIHZhbGlkIHN1YnRhZ3M6IG90aGVyIHN0YW5k YXJkcyByZWZlcmVuY2VkIGluDQogICB0aGlzIHNlY3Rpb24gcHJvdmlkZSB0aGUgc291cmNlIG1h dGVyaWFsIGZvciB0aGF0IHJlZ2lzdHJ5Lg0KDQogICBUZXJtaW5vbG9neSBpbiB0aGlzIHNlY3Rp b246DQoNCiAgIG8gIFRhZyBvciB0YWdzIHJlZmVycyB0byBhIGNvbXBsZXRlIGxhbmd1YWdlIHRh Zywgc3VjaCBhcw0KICAgICAgImZyLUxhdG4tQ0EiLiAgRXhhbXBsZXMgb2YgdGFncyBpbiB0aGlz IGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbg0KICAgICAgZG91YmxlLXF1b3RlcyAoImVuLVVTIiku DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYg ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIG8gIFN1 YnRhZyByZWZlcnMgdG8gYSBzcGVjaWZpYyBzZWN0aW9uIG9mIGEgdGFnLCBkZWxpbWl0ZWQgYnkg aHlwaGVuLA0KICAgICAgc3VjaCBhcyB0aGUgc3VidGFnICdMYXRuJyBpbiAiZnItTGF0bi1DQSIu ICBFeGFtcGxlcyBvZiBzdWJ0YWdzIGluDQogICAgICB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3Nl ZCBpbiBzaW5nbGUgcXVvdGVzICgnTGF0bicpLg0KDQogICBvICBDb2RlIG9yIGNvZGVzIHJlZmVy cyB0byB2YWx1ZXMgZGVmaW5lZCBpbiBleHRlcm5hbCBzdGFuZGFyZHMgKGFuZA0KICAgICAgd2hp Y2ggYXJlIHVzZWQgYXMgc3VidGFncyBpbiB0aGlzIGRvY3VtZW50KS4gIEZvciBleGFtcGxlLCAn TGF0bicNCiAgICAgIGlzIGFuIFtJU08xNTkyNF0gc2NyaXB0IGNvZGUgd2hpY2ggd2FzIHVzZWQg dG8gZGVmaW5lIHRoZSAnTGF0bicNCiAgICAgIHNjcmlwdCBzdWJ0YWcgZm9yIHVzZSBpbiBhIGxh bmd1YWdlIHRhZy4gIEV4YW1wbGVzIG9mIGNvZGVzIGluDQogICAgICB0aGlzIGRvY3VtZW50IGFy ZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgnZW4nLCAnTGF0bicpLg0KDQogICBUaGUgZGVm aW5pdGlvbnMgaW4gdGhpcyBzZWN0aW9uIGFwcGx5IHRvIHRoZSB2YXJpb3VzIHN1YnRhZ3Mgd2l0 aGluDQogICB0aGUgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIGV4Y2Vw dGluZyB0aG9zZQ0KICAgImdyYW5kZmF0aGVyZWQiIHRhZ3MgZGVmaW5lZCBpbiBTZWN0aW9uIDIu Mi44Lg0KDQogICBMYW5ndWFnZSB0YWdzIGFyZSBkZXNpZ25lZCBzbyB0aGF0IGVhY2ggc3VidGFn IHR5cGUgaGFzIHVuaXF1ZSBsZW5ndGgNCiAgIGFuZCBjb250ZW50IHJlc3RyaWN0aW9ucy4gIFRo ZXNlIG1ha2UgaWRlbnRpZmljYXRpb24gb2YgdGhlIHN1YnRhZydzDQogICB0eXBlIHBvc3NpYmxl LCBldmVuIGlmIHRoZSBjb250ZW50IG9mIHRoZSBzdWJ0YWcgaXRzZWxmIGlzDQogICB1bnJlY29n bml6ZWQuICBUaGlzIGFsbG93cyB0YWdzIHRvIGJlIHBhcnNlZCBhbmQgcHJvY2Vzc2VkIHdpdGhv dXQNCiAgIHJlZmVyZW5jZSB0byB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIHVuZGVybHlpbmcg c3RhbmRhcmRzIG9yIHRoZQ0KICAgSUFOQSByZWdpc3RyeSBhbmQgbWFrZXMgdGhlIGFzc29jaWF0 ZWQgZXhjZXB0aW9uIGhhbmRsaW5nIHdoZW4NCiAgIHBhcnNpbmcgdGFncyBzaW1wbGVyLg0KDQog ICBTdWJ0YWdzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IHRoYXQgZG8gbm90IGNvbWUgZnJvbSBhbiB1 bmRlcmx5aW5nDQogICBzdGFuZGFyZCBjYW4gb25seSBhcHBlYXIgaW4gc3BlY2lmaWMgcG9zaXRp b25zIGluIGEgdGFnLg0KICAgU3BlY2lmaWNhbGx5LCB0aGV5IGNhbiBvbmx5IG9jY3VyIGFzIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBvciBhcw0KICAgdmFyaWFudCBzdWJ0YWdzLg0KDQogICBO b3RlIHRoYXQgc2VxdWVuY2VzIG9mIHByaXZhdGUgdXNlIGFuZCBleHRlbnNpb24gc3VidGFncyBN VVNUIG9jY3VyDQogICBhdCB0aGUgZW5kIG9mIHRoZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFuZCBN VVNUIE5PVCBiZSBpbnRlcnNwZXJzZWQNCiAgIHdpdGggc3VidGFncyBkZWZpbmVkIGVsc2V3aGVy ZSBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBTaW5nbGUgbGV0dGVyIGFuZCBkaWdpdCBzdWJ0YWdz IGFyZSByZXNlcnZlZCBmb3IgY3VycmVudCBvciBmdXR1cmUNCiAgIHVzZS4gIFRoZXNlIGluY2x1 ZGUgdGhlIGZvbGxvd2luZyBjdXJyZW50IHVzZXM6DQoNCiAgIG8gIFRoZSBzaW5nbGUgbGV0dGVy IHN1YnRhZyAneCcgaXMgcmVzZXJ2ZWQgdG8gaW50cm9kdWNlIGEgc2VxdWVuY2UNCiAgICAgIG9m IHByaXZhdGUgdXNlIHN1YnRhZ3MuICBUaGUgaW50ZXJwcmV0YXRpb24gb2YgYW55IHByaXZhdGUg dXNlDQogICAgICBzdWJ0YWdzIGlzIGRlZmluZWQgc29sZWx5IGJ5IHByaXZhdGUgYWdyZWVtZW50 IGFuZCBpcyBub3QgZGVmaW5lZA0KICAgICAgYnkgdGhlIHJ1bGVzIGluIHRoaXMgc2VjdGlvbiBv ciBpbiBhbnkgc3RhbmRhcmQgb3IgcmVnaXN0cnkNCiAgICAgIGRlZmluZWQgaW4gdGhpcyBkb2N1 bWVudC4NCg0KICAgbyAgQWxsIG90aGVyIHNpbmdsZSBsZXR0ZXIgc3VidGFncyBhcmUgcmVzZXJ2 ZWQgdG8gaW50cm9kdWNlDQogICAgICBzdGFuZGFyZGl6ZWQgZXh0ZW5zaW9uIHN1YnRhZyBzZXF1 ZW5jZXMgYXMgZGVzY3JpYmVkIGluDQogICAgICBTZWN0aW9uIDMuNi4NCg0KICAgVGhlIHNpbmds ZSBsZXR0ZXIgc3VidGFnICdpJyBpcyB1c2VkIGJ5IHNvbWUgZ3JhbmRmYXRoZXJlZCB0YWdzLCBz dWNoDQogICBhcyAiaS1lbm9jaGlhbiIsIHdoZXJlIGl0IGFsd2F5cyBhcHBlYXJzIGluIHRoZSBm aXJzdCBwb3NpdGlvbiBhbmQNCiAgIGNhbm5vdCBiZSBjb25mdXNlZCB3aXRoIGFuIGV4dGVuc2lv bi4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAy MDA2ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQoyLjIu MSAgUHJpbWFyeSBMYW5ndWFnZSBTdWJ0YWcNCg0KICAgVGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3Vi dGFnIGlzIHRoZSBmaXJzdCBzdWJ0YWcgaW4gYSBsYW5ndWFnZSB0YWcNCiAgICh3aXRoIHRoZSBl eGNlcHRpb24gb2YgcHJpdmF0ZSB1c2UgYW5kIGNlcnRhaW4gZ3JhbmRmYXRoZXJlZCB0YWdzKQ0K ICAgYW5kIGNhbm5vdCBiZSBvbWl0dGVkLiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0 aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAxLiAgQWxsIHR3byBjaGFyYWN0 ZXIgbGFuZ3VhZ2Ugc3VidGFncyB3ZXJlIGRlZmluZWQgaW4gdGhlIElBTkENCiAgICAgICByZWdp c3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIHRoZSBzdGFuZGFyZCBJ U08NCiAgICAgICA2MzkgUGFydCAxLCAiSVNPIDYzOS0xOjIwMDIsIENvZGVzIGZvciB0aGUgcmVw cmVzZW50YXRpb24gb2YNCiAgICAgICBuYW1lcyBvZiBsYW5ndWFnZXMgLS0gUGFydCAxOiBBbHBo YS0yIGNvZGUiIFtJU082MzktMV0sIG9yIHVzaW5nDQogICAgICAgYXNzaWdubWVudHMgc3Vic2Vx dWVudGx5IG1hZGUgYnkgdGhlIElTTyA2MzkgUGFydCAxIG1haW50ZW5hbmNlDQogICAgICAgYWdl bmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KDQogICAyLiAgQWxsIHRo cmVlIGNoYXJhY3RlciBsYW5ndWFnZSBzdWJ0YWdzIHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQQ0K ICAgICAgIHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQgaW4gSVNP IDYzOSBQYXJ0IDIsDQogICAgICAgIklTTyA2MzktMjoxOTk4IC0gQ29kZXMgZm9yIHRoZSByZXBy ZXNlbnRhdGlvbiBvZiBuYW1lcyBvZg0KICAgICAgIGxhbmd1YWdlcyAtLSBQYXJ0IDI6IEFscGhh LTMgY29kZSAtIGVkaXRpb24gMSIgW0lTTzYzOS0yXSwgb3INCiAgICAgICBhc3NpZ25tZW50cyBz dWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDYzOSBQYXJ0IDIgbWFpbnRlbmFuY2UNCiAgICAg ICBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuDQoNCiAgIDMuICBU aGUgc3VidGFncyBpbiB0aGUgcmFuZ2UgJ3FhYScgdGhyb3VnaCAncXR6JyBhcmUgcmVzZXJ2ZWQg Zm9yDQogICAgICAgcHJpdmF0ZSB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3Mg Y29ycmVzcG9uZCB0byBjb2Rlcw0KICAgICAgIHJlc2VydmVkIGJ5IElTTyA2MzktMiBmb3IgcHJp dmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZA0KICAgICAgIGZvciBub24tcmVnaXN0 ZXJlZCBwcmltYXJ5LWxhbmd1YWdlIHN1YnRhZ3MgKGluc3RlYWQgb2YgdXNpbmcNCiAgICAgICBw cml2YXRlIHVzZSBzdWJ0YWdzIGZvbGxvd2luZyAneC0nKS4gIFBsZWFzZSByZWZlciB0byBTZWN0 aW9uIDQuNQ0KICAgICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRh Z3MuDQoNCiAgIDQuICBBbGwgZm91ciBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgcmVz ZXJ2ZWQgZm9yIHBvc3NpYmxlDQogICAgICAgZnV0dXJlIHN0YW5kYXJkaXphdGlvbi4NCg0KICAg NS4gIEFsbCBsYW5ndWFnZSBzdWJ0YWdzIG9mIDUgdG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aCBp biB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IHdlcmUgZGVmaW5lZCB2aWEgdGhlIHJlZ2lzdHJh dGlvbiBwcm9jZXNzIGluIFNlY3Rpb24gMy40DQogICAgICAgYW5kIE1BWSBiZSB1c2VkIHRvIGZv cm0gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnLiAgQXQgdGhlIHRpbWUNCiAgICAgICB0aGlz IGRvY3VtZW50IHdhcyBjcmVhdGVkLCB0aGVyZSB3ZXJlIG5vIGV4YW1wbGVzIG9mIHRoaXMga2lu ZCBvZg0KICAgICAgIHN1YnRhZyBhbmQgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgb2YgdGhpcyB0eXBl IHdpbGwgYmUgZGlzY291cmFnZWQ6DQogICAgICAgcHJpbWFyeSBsYW5ndWFnZXMgYXJlIHN0cm9u Z2x5IFJFQ09NTUVOREVEIGZvciByZWdpc3RyYXRpb24gd2l0aA0KICAgICAgIElTTyA2MzkgYW5k IHByb3Bvc2FscyByZWplY3RlZCBieSBJU08gNjM5L1JBIHdpbGwgYmUgY2xvc2VseQ0KICAgICAg IHNjcnV0aW5pemVkIGJlZm9yZSB0aGV5IGFyZSByZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KICAg Ni4gIFRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRhZyAneCcgYXMgdGhlIHByaW1hcnkgc3VidGFn IGluZGljYXRlcw0KICAgICAgIHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBjb25zaXN0cyBzb2xlbHkg b2Ygc3VidGFncyB3aG9zZSBtZWFuaW5nIGlzDQogICAgICAgZGVmaW5lZCBieSBwcml2YXRlIGFn cmVlbWVudC4gIEZvciBleGFtcGxlLCBpbiB0aGUgdGFnICJ4LWZyLUNIIiwNCiAgICAgICB0aGUg c3VidGFncyAnZnInIGFuZCAnQ0gnIFNIT1VMRCBOT1QgYmUgdGFrZW4gdG8gcmVwcmVzZW50IHRo ZQ0KICAgICAgIEZyZW5jaCBsYW5ndWFnZSBvciB0aGUgY291bnRyeSBvZiBTd2l0emVybGFuZCAo b3IgYW55IG90aGVyIHZhbHVlDQogICAgICAgaW4gdGhlIElBTkEgcmVnaXN0cnkpIHVubGVzcyB0 aGVyZSBpcyBhIHByaXZhdGUgYWdyZWVtZW50IGluDQogICAgICAgcGxhY2UgdG8gZG8gc28uICBT ZWUgU2VjdGlvbiA0LjUuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA1DQoNCg0KICAgNy4gIFRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRhZyAnaScgaXMgdXNlZCBi eSBzb21lIGdyYW5kZmF0aGVyZWQNCiAgICAgICB0YWdzIChzZWUgU2VjdGlvbiAyLjIuOCkgc3Vj aCBhcyAiaS1rbGluZ29uIiBhbmQgImktYm5uIi4gIChPdGhlcg0KICAgICAgIGdyYW5kZmF0aGVy ZWQgdGFncyBoYXZlIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaW4gdGhlaXIgZmlyc3QNCiAg ICAgICBwb3NpdGlvbikNCg0KICAgOC4gIE90aGVyIHZhbHVlcyBNVVNUIE5PVCBiZSBhc3NpZ25l ZCB0byB0aGUgcHJpbWFyeSBzdWJ0YWcgZXhjZXB0IGJ5DQogICAgICAgcmV2aXNpb24gb3IgdXBk YXRlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5vdGU6IEZvciBsYW5ndWFnZXMgdGhhdCBoYXZl IGJvdGggYW4gSVNPIDYzOS0xIHR3byBjaGFyYWN0ZXIgY29kZQ0KICAgYW5kIGFuIElTTyA2Mzkt MiB0aHJlZSBjaGFyYWN0ZXIgY29kZSwgb25seSB0aGUgSVNPIDYzOS0xIHR3bw0KICAgY2hhcmFj dGVyIGNvZGUgaXMgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeS4NCg0KICAgTm90ZTogRm9y IGxhbmd1YWdlcyB0aGF0IGhhdmUgbm8gSVNPIDYzOS0xIHR3byBjaGFyYWN0ZXIgY29kZSBhbmQg Zm9yDQogICB3aGljaCB0aGUgSVNPIDYzOS0yL1QgKFRlcm1pbm9sb2d5KSBjb2RlIGFuZCB0aGUg SVNPIDYzOS0yL0INCiAgIChCaWJsaW9ncmFwaGljKSBjb2RlcyBkaWZmZXIsIG9ubHkgdGhlIFRl cm1pbm9sb2d5IGNvZGUgaXMgZGVmaW5lZCBpbg0KICAgdGhlIElBTkEgcmVnaXN0cnkuICBBdCB0 aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCBhbGwNCiAgIGxhbmd1YWdlcyB0aGF0 IGhhZCBib3RoIGtpbmRzIG9mIHRocmVlIGNoYXJhY3RlciBjb2RlIHdlcmUgYWxzbw0KICAgYXNz aWduZWQgYSB0d28gY2hhcmFjdGVyIGNvZGU7IGl0IGlzIG5vdCBleHBlY3RlZCB0aGF0IGZ1dHVy ZQ0KICAgYXNzaWdubWVudHMgb2YgdGhpcyBuYXR1cmUgd2lsbCBvY2N1ci4NCg0KICAgTm90ZTog VG8gYXZvaWQgcHJvYmxlbXMgd2l0aCB2ZXJzaW9uaW5nIGFuZCBzdWJ0YWcgY2hvaWNlIGFzDQog ICBleHBlcmllbmNlZCBkdXJpbmcgdGhlIHRyYW5zaXRpb24gYmV0d2VlbiBSRkMgMTc2NiBhbmQg UkZDIDMwNjYsIGFzDQogICB3ZWxsIGFzIHRoZSBjYW5vbmljYWwgbmF0dXJlIG9mIHN1YnRhZ3Mg ZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50LCB0aGUNCiAgIElTTyA2MzkgUmVnaXN0cmF0aW9uIEF1 dGhvcml0eSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWUgKElTTyA2MzkvDQogICBSQS1KQUMpIGhh cyBpbmNsdWRlZCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiBbaXNvNjM5LnByaW5jaXBsZXNd Og0KDQogICAiQSBsYW5ndWFnZSBjb2RlIGFscmVhZHkgaW4gSVNPIDYzOS0yIGF0IHRoZSBwb2lu dCBvZiBmcmVlemluZyBJU08NCiAgIDYzOS0xIHNoYWxsIG5vdCBsYXRlciBiZSBhZGRlZCB0byBJ U08gNjM5LTEuICBUaGlzIGlzIHRvIGVuc3VyZQ0KICAgY29uc2lzdGVuY3kgaW4gdXNhZ2Ugb3Zl ciB0aW1lLCBzaW5jZSB1c2VycyBhcmUgZGlyZWN0ZWQgaW4gSW50ZXJuZXQNCiAgIGFwcGxpY2F0 aW9ucyB0byBlbXBsb3kgdGhlIGFscGhhLTMgY29kZSB3aGVuIGFuIGFscGhhLTIgY29kZSBmb3Ig dGhhdA0KICAgbGFuZ3VhZ2UgaXMgbm90IGF2YWlsYWJsZS4iDQoNCiAgIEluIG9yZGVyIHRvIGF2 b2lkIGluc3RhYmlsaXR5IGluIHRoZSBjYW5vbmljYWwgZm9ybSBvZiB0YWdzLCBpZiBhIHR3bw0K ICAgY2hhcmFjdGVyIGNvZGUgaXMgYWRkZWQgdG8gSVNPIDYzOS0xIGZvciBhIGxhbmd1YWdlIGZv ciB3aGljaCBhIHRocmVlDQogICBjaGFyYWN0ZXIgY29kZSB3YXMgYWxyZWFkeSBpbmNsdWRlZCBp biBJU08gNjM5LTIsIHRoZSB0d28gY2hhcmFjdGVyDQogICBjb2RlIE1VU1QgTk9UIGJlIHJlZ2lz dGVyZWQuICBTZWUgU2VjdGlvbiAzLjMuDQoNCiAgIEZvciBleGFtcGxlLCBpZiBzb21lIGNvbnRl bnQgd2VyZSB0YWdnZWQgd2l0aCAnaGF3JyAoSGF3YWlpYW4pLCB3aGljaA0KICAgY3VycmVudGx5 IGhhcyBubyB0d28gY2hhcmFjdGVyIGNvZGUsIHRoZSB0YWcgd291bGQgbm90IGJlIGludmFsaWRh dGVkDQogICBpZiBJU08gNjM5LTEgd2VyZSB0byBhc3NpZ24gYSB0d28gY2hhcmFjdGVyIGNvZGUg dG8gdGhlIEhhd2FpaWFuDQogICBsYW5ndWFnZSBhdCBhIGxhdGVyIGRhdGUuDQoNCiAgIEZvciBl eGFtcGxlLCBvbmUgb2YgdGhlIGdyYW5kZmF0aGVyZWQgSUFOQSByZWdpc3RyYXRpb25zIGlzDQog ICAiaS1lbm9jaGlhbiIuICBUaGUgc3VidGFnICdlbm9jaGlhbicgY291bGQgYmUgcmVnaXN0ZXJl ZCBpbiB0aGUgSUFOQQ0KICAgcmVnaXN0cnkgYXMgYSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyAo YXNzdW1pbmcgdGhhdCBJU08gNjM5IGRvZXMgbm90DQogICByZWdpc3RlciB0aGlzIGxhbmd1YWdl IGZpcnN0KSwgbWFraW5nIHRhZ3Mgc3VjaCBhcyAiZW5vY2hpYW4tQVEiIGFuZA0KICAgImVub2No aWFuLUxhdG4iIHZhbGlkLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVz IEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3Qg MjAwNQ0KDQoNCjIuMi4yICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzDQoNCiAgIFRoZSBmb2xs b3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3M6DQoNCiAg IDEuICBUaHJlZSBsZXR0ZXIgc3VidGFncyBpbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIHByaW1h cnkgc3VidGFnIGFyZQ0KICAgICAgIHJlc2VydmVkIGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9u LCBhbnRpY2lwYXRpbmcgd29yayB0aGF0IGlzDQogICAgICAgY3VycmVudGx5IHVuZGVyIHdheSBv biBJU08gNjM5Lg0KDQogICAyLiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIGZvbGxv dyB0aGUgcHJpbWFyeSBzdWJ0YWcgYW5kDQogICAgICAgcHJlY2VkZSBhbnkgb3RoZXIgc3VidGFn cy4NCg0KICAgMy4gIFRoZXJlIE1BWSBiZSB1cCB0byB0aHJlZSBleHRlbmRlZCBsYW5ndWFnZSBz dWJ0YWdzLg0KDQogICA0LiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIE5PVCBiZSBy ZWdpc3RlcmVkIG9yIHVzZWQgdG8gZm9ybQ0KICAgICAgIGxhbmd1YWdlIHRhZ3MuICBUaGVpciBz eW50YXggaXMgZGVzY3JpYmVkIGhlcmUgc28gdGhhdA0KICAgICAgIGltcGxlbWVudGF0aW9ucyBj YW4gYmUgY29tcGF0aWJsZSB3aXRoIGFueSBmdXR1cmUgcmV2aXNpb24gb2YNCiAgICAgICB0aGlz IGRvY3VtZW50IHdoaWNoIGRvZXMgcHJvdmlkZSBmb3IgdGhlaXIgcmVnaXN0cmF0aW9uLg0KDQog ICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcgcmVjb3Jkcywgb25jZSB0aGV5IGFwcGVhciBpbiB0 aGUgcmVnaXN0cnksDQogICBNVVNUIGluY2x1ZGUgZXhhY3RseSBvbmUgJ1ByZWZpeCcgZmllbGQg aW5kaWNhdGluZyBhbiBhcHByb3ByaWF0ZQ0KICAgbGFuZ3VhZ2Ugc3VidGFnIG9yIHNlcXVlbmNl IG9mIHN1YnRhZ3MgdGhhdCBNVVNUIGFsd2F5cyBhcHBlYXIgYXMgYQ0KICAgcHJlZml4IHRvIHRo ZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6IEluIGEgZnV0dXJlIHJl dmlzaW9uIG9yIHVwZGF0ZSBvZiB0aGlzIGRvY3VtZW50LCB0aGUgdGFnDQogICAiemgtZ2FuIiAo cmVnaXN0ZXJlZCB1bmRlciBSRkMgMzA2NikgbWlnaHQgYmVjb21lIGEgdmFsaWQgbm9uLQ0KICAg Z3JhbmRmYXRoZXJlZCAodGhhdCBpcywgcmVkdW5kYW50KSB0YWcgaW4gd2hpY2ggdGhlIHN1YnRh ZyAnZ2FuJw0KICAgbWlnaHQgcmVwcmVzZW50IHRoZSBDaGluZXNlIGRpYWxlY3QgJ0dhbicuDQoN CjIuMi4zICBTY3JpcHQgU3VidGFnDQoNCiAgIFNjcmlwdCBzdWJ0YWdzIGFyZSB1c2VkIHRvIGlu ZGljYXRlIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBzeXN0ZW0NCiAgIHZhcmlhdGlvbnMgdGhhdCBk aXN0aW5ndWlzaCB0aGUgd3JpdHRlbiBmb3JtcyBvZiBhIGxhbmd1YWdlIG9yIGl0cw0KICAgZGlh bGVjdHMuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSBzY3JpcHQgc3VidGFnczoN Cg0KICAgMS4gIEFsbCBmb3VyIGNoYXJhY3RlciBzdWJ0YWdzIHdlcmUgZGVmaW5lZCBhY2NvcmRp bmcgdG8NCiAgICAgICBbSVNPMTU5MjRdLS0iQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBv ZiB0aGUgbmFtZXMgb2YNCiAgICAgICBzY3JpcHRzIjogYWxwaGEtNCBzY3JpcHQgY29kZXMsIG9y IHN1YnNlcXVlbnRseSBhc3NpZ25lZCBieSB0aGUNCiAgICAgICBJU08gMTU5MjQgbWFpbnRlbmFu Y2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLA0KICAgICAgIGRl bm90aW5nIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBzeXN0ZW0gdXNlZCBpbiBjb25qdW5jdGlvbiB3 aXRoDQogICAgICAgdGhpcyBsYW5ndWFnZS4NCg0KICAgMi4gIFNjcmlwdCBzdWJ0YWdzIE1VU1Qg aW1tZWRpYXRlbHkgZm9sbG93IHRoZSBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgc3VidGFnIGFu ZCBhbGwgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhbmQgTVVTVCBvY2N1ciBiZWZvcmUNCiAg ICAgICBhbnkgb3RoZXIgdHlwZSBvZiBzdWJ0YWcgZGVzY3JpYmVkIGJlbG93Lg0KDQogICAzLiAg VGhlIHNjcmlwdCBzdWJ0YWdzICdRYWFhJyB0aHJvdWdoICdRYWJ4JyBhcmUgcmVzZXJ2ZWQgZm9y IHByaXZhdGUNCiAgICAgICB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MgY29y cmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZA0KICAgICAgIGJ5IElTTyAxNTkyNCBmb3IgcHJpdmF0 ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZCBmb3Igbm9uLQ0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1Bh Z2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAgcmVnaXN0ZXJlZCBzY3JpcHQg dmFsdWVzLiAgUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gNC41IGZvciBtb3JlDQogICAgICAgaW5m b3JtYXRpb24gb24gcHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0KICAgNC4gIFNjcmlwdCBzdWJ0YWdz IE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQgdXNpbmcgdGhlIHByb2Nlc3MgaW4NCiAgICAgICBTZWN0 aW9uIDMuNCBvZiB0aGlzIGRvY3VtZW50LiAgVmFyaWFudCBzdWJ0YWdzIE1BWSBiZSBjb25zaWRl cmVkDQogICAgICAgZm9yIHJlZ2lzdHJhdGlvbiBmb3IgdGhhdCBwdXJwb3NlLg0KDQogICA1LiAg VGhlcmUgTVVTVCBiZSBhdCBtb3N0IG9uZSBzY3JpcHQgc3VidGFnIGluIGEgbGFuZ3VhZ2UgdGFn IGFuZCB0aGUNCiAgICAgICBzY3JpcHQgc3VidGFnIFNIT1VMRCBiZSBvbWl0dGVkIHdoZW4gaXQg YWRkcyBubyBkaXN0aW5ndWlzaGluZw0KICAgICAgIHZhbHVlIHRvIHRoZSB0YWcgb3Igd2hlbiB0 aGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcncyByZWNvcmQNCiAgICAgICBpbmNsdWRlcyBhIFN1 cHByZXNzLVNjcmlwdCBmaWVsZCBsaXN0aW5nIHRoZSBhcHBsaWNhYmxlIHNjcmlwdA0KICAgICAg IHN1YnRhZy4NCg0KICAgRXhhbXBsZTogInNyLUxhdG4iIHJlcHJlc2VudHMgU2VyYmlhbiB3cml0 dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQuDQoNCjIuMi40ICBSZWdpb24gU3VidGFnDQoNCiAg IFJlZ2lvbiBzdWJ0YWdzIGFyZSB1c2VkIHRvIGluZGljYXRlIGxpbmd1aXN0aWMgdmFyaWF0aW9u cyBhc3NvY2lhdGVkDQogICB3aXRoIG9yIGFwcHJvcHJpYXRlIHRvIGEgc3BlY2lmaWMgY291bnRy eSwgdGVycml0b3J5LCBvciByZWdpb24uDQogICBUeXBpY2FsbHksIGEgcmVnaW9uIHN1YnRhZyBp cyB1c2VkIHRvIGluZGljYXRlIHJlZ2lvbmFsIGRpYWxlY3RzIG9yDQogICB1c2FnZSwgb3IgcmVn aW9uLXNwZWNpZmljIHNwZWxsaW5nIGNvbnZlbnRpb25zLiAgQSByZWdpb24gc3VidGFnIGNhbg0K ICAgYWxzbyBiZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgY29udGVudCBpcyBleHByZXNzZWQgaW4g YSB3YXkgdGhhdCBpcw0KICAgYXBwcm9wcmlhdGUgZm9yIHVzZSB0aHJvdWdob3V0IGEgcmVnaW9u OyBmb3IgaW5zdGFuY2UsIFNwYW5pc2gNCiAgIGNvbnRlbnQgdGFpbG9yZWQgdG8gYmUgdXNlZnVs IHRocm91Z2hvdXQgTGF0aW4gQW1lcmljYS4NCg0KICAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBs eSB0byB0aGUgcmVnaW9uIHN1YnRhZ3M6DQoNCiAgIDEuICBSZWdpb24gc3VidGFncyBNVVNUIGZv bGxvdyBhbnkgbGFuZ3VhZ2UsIGV4dGVuZGVkIGxhbmd1YWdlLCBvcg0KICAgICAgIHNjcmlwdCBz dWJ0YWdzIGFuZCBNVVNUIHByZWNlZGUgYWxsIG90aGVyIHN1YnRhZ3MuDQoNCiAgIDIuICBBbGwg dHdvIGNoYXJhY3RlciBzdWJ0YWdzIGZvbGxvd2luZyB0aGUgcHJpbWFyeSBzdWJ0YWcgd2VyZQ0K ICAgICAgIGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3Np Z25tZW50cyBmb3VuZA0KICAgICAgIGluIFtJU08zMTY2LTFdICgiQ29kZXMgZm9yIHRoZSByZXBy ZXNlbnRhdGlvbiBvZiBuYW1lcyBvZg0KICAgICAgIGNvdW50cmllcyBhbmQgdGhlaXIgc3ViZGl2 aXNpb25zIC0tIFBhcnQgMTogQ291bnRyeSBjb2RlcyIpIHVzaW5nDQogICAgICAgdGhlIGxpc3Qg b2YgYWxwaGEtMiBjb3VudHJ5IGNvZGVzLCBvciB1c2luZyBhc3NpZ25tZW50cw0KICAgICAgIHN1 YnNlcXVlbnRseSBtYWRlIGJ5IHRoZSBJU08gMzE2NiBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292 ZXJuaW5nDQogICAgICAgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4NCg0KICAgMy4gIEFsbCB0aHJl ZSBjaGFyYWN0ZXIgc3VidGFncyBjb25zaXN0aW5nIG9mIGRpZ2l0IChudW1lcmljKQ0KICAgICAg IGNoYXJhY3RlcnMgZm9sbG93aW5nIHRoZSBwcmltYXJ5IHN1YnRhZyB3ZXJlIGRlZmluZWQgaW4g dGhlIElBTkENCiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZv dW5kIGluIFVOIFN0YW5kYXJkDQogICAgICAgQ291bnRyeSBvciBBcmVhIENvZGVzIGZvciBTdGF0 aXN0aWNhbCAgVXNlIFtVTl9NLjQ5XSBvcg0KICAgICAgIGFzc2lnbm1lbnRzIHN1YnNlcXVlbnRs eSBtYWRlIGJ5IHRoZSBnb3Zlcm5pbmcgc3RhbmRhcmRzIGJvZHkuDQogICAgICAgTm90ZSB0aGF0 IG5vdCBhbGwgb2YgdGhlIFVOIE0uNDkgY29kZXMgYXJlIGRlZmluZWQgaW4gdGhlIElBTkENCiAg ICAgICByZWdpc3RyeS4gIFRoZSBmb2xsb3dpbmcgcnVsZXMgZGVmaW5lIHdoaWNoIGNvZGVzIGFy ZSBlbnRlcmVkDQogICAgICAgaW50byB0aGUgcmVnaXN0cnkgYXMgdmFsaWQgc3VidGFnczoNCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYg ICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgICAgICBB LiAgVU4gbnVtZXJpYyBjb2RlcyBhc3NpZ25lZCB0byAnbWFjcm8tZ2VvZ3JhcGhpY2FsDQogICAg ICAgICAgIChjb250aW5lbnRhbCknIG9yIHN1Yi1yZWdpb25zIE1VU1QgYmUgcmVnaXN0ZXJlZCBp biB0aGUNCiAgICAgICAgICAgcmVnaXN0cnkuICBUaGVzZSBjb2RlcyBhcmUgbm90IGFzc29jaWF0 ZWQgd2l0aCBhbiBhc3NpZ25lZA0KICAgICAgICAgICBJU08gMzE2NiBhbHBoYS0yIGNvZGUgYW5k IHJlcHJlc2VudCBzdXByYS1uYXRpb25hbCBhcmVhcywNCiAgICAgICAgICAgdXN1YWxseSBjb3Zl cmluZyBtb3JlIHRoYW4gb25lIG5hdGlvbiwgc3RhdGUsIHByb3ZpbmNlLCBvcg0KICAgICAgICAg ICB0ZXJyaXRvcnkuDQoNCiAgICAgICBCLiAgVU4gbnVtZXJpYyBjb2RlcyBmb3IgJ2Vjb25vbWlj IGdyb3VwaW5ncycgb3IgJ290aGVyDQogICAgICAgICAgIGdyb3VwaW5ncycgTVVTVCBOT1QgYmUg cmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhbmQNCiAgICAgICAgICAgTVVTVCBOT1Qg YmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3MuDQoNCiAgICAgICBDLiAgVU4gbnVtZXJpYyBj b2RlcyBmb3IgY291bnRyaWVzIG9yIGFyZWFzIHdpdGggYW1iaWd1b3VzIElTTw0KICAgICAgICAg ICAzMTY2IGFscGhhLTIgY29kZXMsIHdoZW4gZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSwgTVVT VCBiZQ0KICAgICAgICAgICBkZWZpbmVkIGFjY29yZGluZyB0byB0aGUgcnVsZXMgaW4gU2VjdGlv biAzLjMgYW5kIE1VU1QgYmUNCiAgICAgICAgICAgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mg dGhhdCByZXByZXNlbnQgdGhlIGNvdW50cnkgb3INCiAgICAgICAgICAgcmVnaW9uIGZvciB3aGlj aCB0aGV5IGFyZSBkZWZpbmVkLg0KDQogICAgICAgRC4gIFVOIG51bWVyaWMgY29kZXMgZm9yIGNv dW50cmllcyBvciBhcmVhcyBmb3Igd2hpY2ggdGhlcmUgaXMgYW4NCiAgICAgICAgICAgYXNzb2Np YXRlZCBJU08gMzE2NiBhbHBoYS0yIGNvZGUgaW4gdGhlIHJlZ2lzdHJ5IE1VU1QgTk9UIGJlDQog ICAgICAgICAgIGVudGVyZWQgaW50byB0aGUgcmVnaXN0cnkgYW5kIE1VU1QgTk9UIGJlIHVzZWQg dG8gZm9ybQ0KICAgICAgICAgICBsYW5ndWFnZSB0YWdzLiAgTm90ZSB0aGF0IHRoZSBJU08gMzE2 Ni1iYXNlZCBzdWJ0YWcgaW4gdGhlDQogICAgICAgICAgIHJlZ2lzdHJ5IE1VU1QgYWN0dWFsbHkg YmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBVTiBNLjQ5IGNvZGUgaW4NCiAgICAgICAgICAgcXVlc3Rp b24uDQoNCiAgICAgICBFLiAgVU4gbnVtZXJpYyBjb2RlcyBhbmQgSVNPIDMxNjYgYWxwaGEtMiBj b2RlcyBmb3IgY291bnRyaWVzIG9yDQogICAgICAgICAgIGFyZWFzIGxpc3RlZCBhcyBlbGlnaWJs ZSBmb3IgcmVnaXN0cmF0aW9uIGluIFtpbml0aWFsLQ0KICAgICAgICAgICByZWdpc3RyeV0gYnV0 IG5vdCBwcmVzZW50bHkgcmVnaXN0ZXJlZCBNQVkgYmUgZW50ZXJlZCBpbnRvDQogICAgICAgICAg IHRoZSBJQU5BIHJlZ2lzdHJ5IHZpYSB0aGUgcHJvY2VzcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAz LjQuDQogICAgICAgICAgIE9uY2UgcmVnaXN0ZXJlZCwgdGhlc2UgY29kZXMgTUFZIGJlIHVzZWQg dG8gZm9ybSBsYW5ndWFnZQ0KICAgICAgICAgICB0YWdzLg0KDQogICAgICAgRi4gIEFsbCBvdGhl ciBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMgd2hpY2ggZG8NCiAgICAg ICAgICAgbm90IGhhdmUgYW4gYXNzb2NpYXRlZCBJU08gMzE2NiBhbHBoYS0yIGNvZGUgTVVTVCBO T1QgYmUNCiAgICAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1Qg YmUgdXNlZCB0byBmb3JtDQogICAgICAgICAgIGxhbmd1YWdlIHRhZ3MuICBGb3IgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCB0aGVzZSBjb2Rlcywgc2VlDQogICAgICAgICAgIFNlY3Rpb24gMy4zLg0K DQogICA0LiAgTm90ZTogVGhlIGFscGhhbnVtZXJpYyBjb2RlcyBpbiBBcHBlbmRpeCBYIG9mIHRo ZSBVTiBkb2N1bWVudA0KICAgICAgIE1VU1QgTk9UIGJlIGVudGVyZWQgaW50byB0aGUgcmVnaXN0 cnkgYW5kIE1VU1QgTk9UIGJlIHVzZWQgdG8NCiAgICAgICBmb3JtIGxhbmd1YWdlIHRhZ3MuICAo QXQgdGhlIHRpbWUgdGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCB0aGVzZQ0KICAgICAgIHZhbHVl cyBtYXRjaCB0aGUgSVNPIDMxNjYgYWxwaGEtMiBjb2Rlcy4pDQoNCiAgIDUuICBUaGVyZSBNVVNU IGJlIGF0IG1vc3Qgb25lIHJlZ2lvbiBzdWJ0YWcgaW4gYSBsYW5ndWFnZSB0YWcgYW5kIHRoZQ0K ICAgICAgIHJlZ2lvbiBzdWJ0YWcgTUFZIGJlIG9taXR0ZWQsIGFzIHdoZW4gaXQgYWRkcyBubyBk aXN0aW5ndWlzaGluZw0KICAgICAgIHZhbHVlIHRvIHRoZSB0YWcuDQoNCiAgIDYuICBUaGUgcmVn aW9uIHN1YnRhZ3MgJ0FBJywgJ1FNJy0nUVonLCAnWEEnLSdYWicsIGFuZCAnWlonIGFyZQ0KICAg ICAgIHJlc2VydmVkIGZvciBwcml2YXRlIHVzZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ugc3Vi dGFncw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAy MDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAg ICAgY29ycmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZCBieSBJU08gMzE2NiBmb3IgcHJpdmF0ZSB1 c2UuICBUaGVzZQ0KICAgICAgIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBwcml2YXRlIHVzZSByZWdp b24gc3VidGFncyAoaW5zdGVhZCBvZg0KICAgICAgIHVzaW5nIGEgcHJpdmF0ZSB1c2Ugc3VidGFn IHNlcXVlbmNlKS4gIFBsZWFzZSByZWZlciB0bw0KICAgICAgIFNlY3Rpb24gNC41IGZvciBtb3Jl IGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgICJkZS1DSCIgcmVwcmVz ZW50cyBHZXJtYW4gKCdkZScpIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQgKCdDSCcpLg0KDQogICAi c3ItTGF0bi1DUyIgcmVwcmVzZW50cyBTZXJiaWFuICgnc3InKSB3cml0dGVuIHVzaW5nIExhdGlu IHNjcmlwdA0KICAgKCdMYXRuJykgYXMgdXNlZCBpbiBTZXJiaWEgYW5kIE1vbnRlbmVncm8gKCdD UycpLg0KDQogICAiZXMtNDE5IiByZXByZXNlbnRzIFNwYW5pc2ggKCdlcycpIGFwcHJvcHJpYXRl IHRvIHRoZSBVTi1kZWZpbmVkDQogICBMYXRpbiBBbWVyaWNhIGFuZCBDYXJpYmJlYW4gcmVnaW9u ICgnNDE5JykuDQoNCjIuMi41ICBWYXJpYW50IFN1YnRhZ3MNCg0KICAgVmFyaWFudCBzdWJ0YWdz IGFyZSB1c2VkIHRvIGluZGljYXRlIGFkZGl0aW9uYWwsIHdlbGwtcmVjb2duaXplZA0KICAgdmFy aWF0aW9ucyB0aGF0IGRlZmluZSBhIGxhbmd1YWdlIG9yIGl0cyBkaWFsZWN0cyB3aGljaCBhcmUg bm90DQogICBjb3ZlcmVkIGJ5IG90aGVyIGF2YWlsYWJsZSBzdWJ0YWdzLiAgVGhlIGZvbGxvd2lu ZyBydWxlcyBhcHBseSB0byB0aGUNCiAgIHZhcmlhbnQgc3VidGFnczoNCg0KICAgMS4gIFZhcmlh bnQgc3VidGFncyBhcmUgbm90IGFzc29jaWF0ZWQgd2l0aCBhbnkgZXh0ZXJuYWwgc3RhbmRhcmQu DQogICAgICAgVmFyaWFudCBzdWJ0YWdzIGFuZCB0aGVpciBtZWFuaW5ncyBhcmUgZGVmaW5lZCBi eSB0aGUNCiAgICAgICByZWdpc3RyYXRpb24gcHJvY2VzcyBkZWZpbmVkIGluIFNlY3Rpb24gMy40 Lg0KDQogICAyLiAgVmFyaWFudCBzdWJ0YWdzIE1VU1QgZm9sbG93IGFsbCBvZiB0aGUgb3RoZXIg ZGVmaW5lZCBzdWJ0YWdzLCBidXQNCiAgICAgICBwcmVjZWRlIGFueSBleHRlbnNpb24gb3IgcHJp dmF0ZSB1c2Ugc3VidGFnIHNlcXVlbmNlcy4NCg0KICAgMy4gIE1vcmUgdGhhbiBvbmUgdmFyaWFu dCBNQVkgYmUgdXNlZCB0byBmb3JtIHRoZSBsYW5ndWFnZSB0YWcuDQoNCiAgIDQuICBWYXJpYW50 IHN1YnRhZ3MgTVVTVCBiZSByZWdpc3RlcmVkIHdpdGggSUFOQSBhY2NvcmRpbmcgdG8gdGhlDQog ICAgICAgcnVsZXMgaW4gU2VjdGlvbiAzLjQgb2YgdGhpcyBkb2N1bWVudCBiZWZvcmUgYmVpbmcg dXNlZCB0byBmb3JtDQogICAgICAgbGFuZ3VhZ2UgdGFncy4gIEluIG9yZGVyIHRvIGRpc3Rpbmd1 aXNoIHZhcmlhbnRzIGZyb20gb3RoZXIgdHlwZXMNCiAgICAgICBvZiBzdWJ0YWdzLCByZWdpc3Ry YXRpb25zIE1VU1QgbWVldCB0aGUgZm9sbG93aW5nIGxlbmd0aCBhbmQNCiAgICAgICBjb250ZW50 IHJlc3RyaWN0aW9uczoNCg0KICAgICAgIDEuICBWYXJpYW50IHN1YnRhZ3MgdGhhdCBiZWdpbiB3 aXRoIGEgbGV0dGVyIChhLXosIEEtWikgTVVTVCBiZQ0KICAgICAgICAgICBhdCBsZWFzdCBmaXZl IGNoYXJhY3RlcnMgbG9uZy4NCg0KICAgICAgIDIuICBWYXJpYW50IHN1YnRhZ3MgdGhhdCBiZWdp biB3aXRoIGEgZGlnaXQgKDAtOSkgTVVTVCBiZSBhdA0KICAgICAgICAgICBsZWFzdCBmb3VyIGNo YXJhY3RlcnMgbG9uZy4NCg0KICAgVmFyaWFudCBzdWJ0YWcgcmVjb3JkcyBpbiB0aGUgbGFuZ3Vh Z2Ugc3VidGFnIHJlZ2lzdHJ5IE1BWSBpbmNsdWRlDQogICBvbmUgb3IgbW9yZSAnUHJlZml4JyBm aWVsZHMsIHdoaWNoIGluZGljYXRlcyB0aGUgbGFuZ3VhZ2UgdGFnIG9yIHRhZ3MNCiAgIHRoYXQg d291bGQgbWFrZSBhIHN1aXRhYmxlIHByZWZpeCAod2l0aCBvdGhlciBzdWJ0YWdzLCBhcw0KICAg YXBwcm9wcmlhdGUpIGluIGZvcm1pbmcgYSBsYW5ndWFnZSB0YWcgd2l0aCB0aGUgdmFyaWFudC4g IEZvcg0KICAgZXhhbXBsZSwgdGhlIHN1YnRhZyAnbmVkaXMnIGhhcyBhIFByZWZpeCBvZiAic2wi LCBtYWtpbmcgaXQgc3VpdGFibGUNCiAgIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyBzdWNoIGFzICJz bC1uZWRpcyIgYW5kICJzbC1JVC1uZWRpcyIsIGJ1dCBub3QNCiAgIHN1aXRhYmxlIGZvciB1c2Ug aW4gYSB0YWcgc3VjaCBhcyAiemgtbmVkaXMiIG9yICJpdC1JVC1uZWRpcyIuDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAg ICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgICJzbC1uZWRpcyIgcmVwcmVz ZW50cyB0aGUgTmF0aXNvbmUgb3IgTmFkaXphIGRpYWxlY3Qgb2YgU2xvdmVuaWFuLg0KDQogICAi ZGUtQ0gtMTk5NiIgcmVwcmVzZW50cyBHZXJtYW4gYXMgdXNlZCBpbiBTd2l0emVybGFuZCBhbmQg YXMgd3JpdHRlbg0KICAgdXNpbmcgdGhlIHNwZWxsaW5nIHJlZm9ybSBiZWdpbm5pbmcgaW4gdGhl IHllYXIgMTk5NiBDLkUuDQoNCiAgIE1vc3QgdmFyaWFudHMgdGhhdCBzaGFyZSBhIHByZWZpeCBh cmUgbXV0dWFsbHkgZXhjbHVzaXZlLiAgRm9yDQogICBleGFtcGxlLCB0aGUgR2VybWFuIG9ydGhv Z3JhcGhpYyB2YXJpYXRpb25zICcxOTk2JyBhbmQgJzE5MDEnIFNIT1VMRA0KICAgTk9UIGJlIHVz ZWQgaW4gdGhlIHNhbWUgdGFnLCBhcyB0aGV5IHJlcHJlc2VudCB0aGUgZGF0ZXMgb2YgZGlmZmVy ZW50DQogICBzcGVsbGluZyByZWZvcm1zLiAgQSB2YXJpYW50IHRoYXQgY2FuIG1lYW5pbmdmdWxs eSBiZSB1c2VkIGluDQogICBjb21iaW5hdGlvbiB3aXRoIGFub3RoZXIgdmFyaWFudCBTSE9VTEQg aW5jbHVkZSBhICdQcmVmaXgnIGZpZWxkIGluDQogICBpdHMgcmVnaXN0cnkgcmVjb3JkIHRoYXQg bGlzdHMgdGhhdCBvdGhlciB2YXJpYW50LiAgRm9yIGV4YW1wbGUsIGlmDQogICBhbm90aGVyIEdl cm1hbiB2YXJpYW50ICdleGFtcGxlJyB3ZXJlIGNyZWF0ZWQgdGhhdCBtYWRlIHNlbnNlIHRvIHVz ZQ0KICAgd2l0aCAnMTk5NicsIHRoZW4gJ2V4YW1wbGUnIHNob3VsZCBpbmNsdWRlIHR3byBQcmVm aXggZmllbGRzOiAiZGUiDQogICBhbmQgImRlLTE5OTYiLg0KDQoyLjIuNiAgRXh0ZW5zaW9uIFN1 YnRhZ3MNCg0KICAgRXh0ZW5zaW9ucyBwcm92aWRlIGEgbWVjaGFuaXNtIGZvciBleHRlbmRpbmcg bGFuZ3VhZ2UgdGFncyBmb3IgdXNlIGluDQogICB2YXJpb3VzIGFwcGxpY2F0aW9ucy4gIFNlZTog U2VjdGlvbiAzLjYuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5DQogICB0byBleHRlbnNpb25z Og0KDQogICAxLiAgIEV4dGVuc2lvbiBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgb3Ro ZXIgc3VidGFncyBkZWZpbmVkDQogICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgYSBzaW5nbGUt bGV0dGVyIHN1YnRhZyAoInNpbmdsZXRvbiIpLiAgVGhlDQogICAgICAgIHNpbmdsZXRvbiBNVVNU IGJlIG9uZSBhbGxvY2F0ZWQgdG8gYSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IHZpYQ0KICAgICAg ICB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNiBhbmQgTVVTVCBOT1QgYmUg dGhlDQogICAgICAgIGxldHRlciAneCcsIHdoaWNoIGlzIHJlc2VydmVkIGZvciBwcml2YXRlIHVz ZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAyLiAgIE5vdGU6IFByaXZhdGUgdXNlIHN1YnRhZyBz ZXF1ZW5jZXMgc3RhcnRpbmcgd2l0aCB0aGUgc2luZ2xldG9uDQogICAgICAgIHN1YnRhZyAneCcg YXJlIGRlc2NyaWJlZCBiZWxvdy4NCg0KICAgMy4gICBBbiBleHRlbnNpb24gTVVTVCBmb2xsb3cg YXQgbGVhc3QgYSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZy4NCiAgICAgICAgVGhhdCBpcywgYSBs YW5ndWFnZSB0YWcgY2Fubm90IGJlZ2luIHdpdGggYW4gZXh0ZW5zaW9uLg0KICAgICAgICBFeHRl bnNpb25zIGV4dGVuZCBsYW5ndWFnZSB0YWdzLCB0aGV5IGRvIG5vdCBvdmVycmlkZSBvciByZXBs YWNlDQogICAgICAgIHRoZW0uICBGb3IgZXhhbXBsZSwgImEtdmFsdWUiIGlzIG5vdCBhIHdlbGwt Zm9ybWVkIGxhbmd1YWdlIHRhZywNCiAgICAgICAgd2hpbGUgImRlLWEtdmFsdWUiIGlzLg0KDQog ICA0LiAgIEVhY2ggc2luZ2xldG9uIHN1YnRhZyBNVVNUIGFwcGVhciBhdCBtb3N0IG9uZSB0aW1l IGluIGVhY2ggdGFnDQogICAgICAgIChvdGhlciB0aGFuIGFzIGEgcHJpdmF0ZSB1c2Ugc3VidGFn KS4gIFRoYXQgaXMsIHNpbmdsZXRvbg0KICAgICAgICBzdWJ0YWdzIE1VU1QgTk9UIGJlIHJlcGVh dGVkLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImVuLWEtYmJiLWEtDQogICAgICAgIGNjYyIgaXMg aW52YWxpZCBiZWNhdXNlIHRoZSBzdWJ0YWcgJ2EnIGFwcGVhcnMgdHdpY2UuICBOb3RlIHRoYXQN CiAgICAgICAgdGhlIHRhZyAiZW4tYS1iYmIteC1hLWNjYyIgaXMgdmFsaWQgYmVjYXVzZSB0aGUg c2Vjb25kDQogICAgICAgIGFwcGVhcmFuY2Ugb2YgdGhlIHNpbmdsZXRvbiAnYScgaXMgaW4gYSBw cml2YXRlIHVzZSBzZXF1ZW5jZS4NCg0KICAgNS4gICBFeHRlbnNpb24gc3VidGFncyBNVVNUIG1l ZXQgYWxsIG9mIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZQ0KICAgICAgICBjb250ZW50IGFuZCBm b3JtYXQgb2Ygc3VidGFncyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIDYuICAgRXh0 ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IHdoYXRldmVyIHJlcXVpcmVtZW50cyBhcmUgc2V0IGJ5 IHRoZQ0KICAgICAgICBkb2N1bWVudCB0aGF0IGRlZmluZXMgdGhlaXIgc2luZ2xldG9uIHByZWZp eCBhbmQgd2hhdGV2ZXINCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1 DQoNCg0KICAgICAgICByZXF1aXJlbWVudHMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBtYWludGFpbmlu ZyBhdXRob3JpdHkuDQoNCiAgIDcuICAgRWFjaCBleHRlbnNpb24gc3VidGFnIE1VU1QgYmUgZnJv bSB0d28gdG8gZWlnaHQgY2hhcmFjdGVycyBsb25nDQogICAgICAgIGFuZCBjb25zaXN0IHNvbGVs eSBvZiBsZXR0ZXJzIG9yIGRpZ2l0cywgd2l0aCBlYWNoIHN1YnRhZw0KICAgICAgICBzZXBhcmF0 ZWQgYnkgYSBzaW5nbGUgJy0nLg0KDQogICA4LiAgIEVhY2ggc2luZ2xldG9uIE1VU1QgYmUgZm9s bG93ZWQgYnkgYXQgbGVhc3Qgb25lIGV4dGVuc2lvbg0KICAgICAgICBzdWJ0YWcuICBGb3IgZXhh bXBsZSwgdGhlIHRhZyAidGxoLWEtYi1mb28iIGlzIGludmFsaWQgYmVjYXVzZQ0KICAgICAgICB0 aGUgZmlyc3Qgc2luZ2xldG9uICdhJyBpcyBmb2xsb3dlZCBpbW1lZGlhdGVseSBieSBhbm90aGVy DQogICAgICAgIHNpbmdsZXRvbiAnYicuDQoNCiAgIDkuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVT VCBmb2xsb3cgYWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwNCiAgICAgICAgc2NyaXB0 LCByZWdpb24gYW5kIHZhcmlhbnQgc3VidGFncyBpbiBhIHRhZy4NCg0KICAgMTAuICBBbGwgc3Vi dGFncyBmb2xsb3dpbmcgdGhlIHNpbmdsZXRvbiBhbmQgYmVmb3JlIGFub3RoZXIgc2luZ2xldG9u DQogICAgICAgIGFyZSBwYXJ0IG9mIHRoZSBleHRlbnNpb24uICBFeGFtcGxlOiBJbiB0aGUgdGFn ICJmci1hLUxhdG4iLCB0aGUNCiAgICAgICAgc3VidGFnICdMYXRuJyBkb2VzIG5vdCByZXByZXNl bnQgdGhlIHNjcmlwdCBzdWJ0YWcgJ0xhdG4nDQogICAgICAgIGRlZmluZWQgaW4gdGhlIElBTkEg TGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5LiAgSXRzIG1lYW5pbmcgaXMNCiAgICAgICAgZGVmaW5l ZCBieSB0aGUgZXh0ZW5zaW9uICdhJy4NCg0KICAgMTEuICBJbiB0aGUgZXZlbnQgdGhhdCBtb3Jl IHRoYW4gb25lIGV4dGVuc2lvbiBhcHBlYXJzIGluIGEgc2luZ2xlDQogICAgICAgIHRhZywgdGhl IHRhZyBTSE9VTEQgYmUgY2Fub25pY2FsaXplZCBhcyBkZXNjcmliZWQgaW4NCiAgICAgICAgU2Vj dGlvbiA0LjQuDQoNCiAgIEZvciBleGFtcGxlLCBpZiB0aGUgcHJlZml4IHNpbmdsZXRvbiAncicg YW5kIHRoZSBzaG93biBzdWJ0YWdzIHdlcmUNCiAgIGRlZmluZWQsIHRoZW4gdGhlIGZvbGxvd2lu ZyB0YWcgd291bGQgYmUgYSB2YWxpZCBleGFtcGxlOiAiZW4tTGF0bi0NCiAgIEdCLWJvb250LXIt ZXh0ZW5kZWQtc2VxdWVuY2UteC1wcml2YXRlIg0KDQoyLjIuNyAgUHJpdmF0ZSBVc2UgU3VidGFn cw0KDQogICBQcml2YXRlIHVzZSBzdWJ0YWdzIGFyZSB1c2VkIHRvIGluZGljYXRlIGRpc3RpbmN0 aW9ucyBpbiBsYW5ndWFnZQ0KICAgaW1wb3J0YW50IGluIGEgZ2l2ZW4gY29udGV4dCBieSBwcml2 YXRlIGFncmVlbWVudC4gIFRoZSBmb2xsb3dpbmcNCiAgIHJ1bGVzIGFwcGx5IHRvIHByaXZhdGUg dXNlIHN1YnRhZ3M6DQoNCiAgIDEuICBQcml2YXRlIHVzZSBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQg ZnJvbSB0aGUgb3RoZXIgc3VidGFncyBkZWZpbmVkDQogICAgICAgaW4gdGhpcyBkb2N1bWVudCBi eSB0aGUgcmVzZXJ2ZWQgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgJ3gnLg0KDQogICAyLiAgUHJp dmF0ZSB1c2Ugc3VidGFncyBNVVNUIGNvbmZvcm0gdG8gdGhlIGZvcm1hdCBhbmQgY29udGVudA0K ICAgICAgIGNvbnN0cmFpbnRzIGRlZmluZWQgaW4gdGhlIEFCTkYgZm9yIGFsbCBzdWJ0YWdzLg0K DQogICAzLiAgUHJpdmF0ZSB1c2Ugc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2UsIGV4 dGVuZGVkIGxhbmd1YWdlLA0KICAgICAgIHNjcmlwdCwgcmVnaW9uLCB2YXJpYW50LCBhbmQgZXh0 ZW5zaW9uIHN1YnRhZ3MgaW4gdGhlIHRhZy4NCiAgICAgICBBbm90aGVyIHdheSBvZiBzYXlpbmcg dGhpcyBpcyB0aGF0IGFsbCBzdWJ0YWdzIGZvbGxvd2luZyB0aGUNCiAgICAgICBzaW5nbGV0b24g J3gnIE1VU1QgYmUgY29uc2lkZXJlZCBwcml2YXRlIHVzZS4gIEV4YW1wbGU6IFRoZQ0KICAgICAg IHN1YnRhZyAnVVMnIGluIHRoZSB0YWcgImVuLXgtVVMiIGlzIGEgcHJpdmF0ZSB1c2Ugc3VidGFn Lg0KDQogICA0LiAgQSB0YWcgTUFZIGNvbnNpc3QgZW50aXJlbHkgb2YgcHJpdmF0ZSB1c2Ugc3Vi dGFncy4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1 LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQog ICA1LiAgTm8gc291cmNlIGlzIGRlZmluZWQgZm9yIHByaXZhdGUgdXNlIHN1YnRhZ3MuICBVc2Ug b2YgcHJpdmF0ZSB1c2UNCiAgICAgICBzdWJ0YWdzIGlzIGJ5IHByaXZhdGUgYWdyZWVtZW50IG9u bHkuDQoNCiAgIDYuICBQcml2YXRlIHVzZSBzdWJ0YWdzIGFyZSBOT1QgUkVDT01NRU5ERUQgd2hl cmUgYWx0ZXJuYXRpdmVzIGV4aXN0DQogICAgICAgb3IgZm9yIGdlbmVyYWwgaW50ZXJjaGFuZ2Uu ICBTZWUgU2VjdGlvbiA0LjUgZm9yIG1vcmUgaW5mb3JtYXRpb24NCiAgICAgICBvbiBwcml2YXRl IHVzZSBzdWJ0YWcgY2hvaWNlLg0KDQogICBGb3IgZXhhbXBsZTogVXNlcnMgd2hvIHdpc2hlZCB0 byB1dGlsaXplIGNvZGVzIGZyb20gdGhlIEV0aG5vbG9ndWUNCiAgIHB1YmxpY2F0aW9uIG9mIFNJ TCBJbnRlcm5hdGlvbmFsIGZvciBsYW5ndWFnZSBpZGVudGlmaWNhdGlvbiBtaWdodA0KICAgYWdy ZWUgdG8gZXhjaGFuZ2UgdGFncyBzdWNoIGFzICJhei1BcmFiLXgtQVpFLWRlcmJlbmQiLiAgVGhp cyBleGFtcGxlDQogICBjb250YWlucyB0d28gcHJpdmF0ZSB1c2Ugc3VidGFncy4gIFRoZSBmaXJz dCBpcyAnQVpFJyBhbmQgdGhlIHNlY29uZA0KICAgaXMgJ2RlcmJlbmQnLg0KDQoyLjIuOCAgUHJl LUV4aXN0aW5nIFJGQyAzMDY2IFJlZ2lzdHJhdGlvbnMNCg0KICAgRXhpc3RpbmcgSUFOQS1yZWdp c3RlcmVkIGxhbmd1YWdlIHRhZ3MgZnJvbSBSRkMgMTc2NiBhbmQvb3IgUkZDIDMwNjYNCiAgIG1h aW50YWluIHRoZWlyIHZhbGlkaXR5LiAgVGhlc2UgdGFncyB3aWxsIGJlIG1haW50YWluZWQgaW4g dGhlDQogICByZWdpc3RyeSBpbiByZWNvcmRzIG9mIGVpdGhlciB0aGUgImdyYW5kZmF0aGVyZWQi IG9yICJyZWR1bmRhbnQiDQogICB0eXBlLiAgRm9yIG1vcmUgaW5mb3JtYXRpb24gc2VlIFNlY3Rp b24gMy43Lg0KDQogICBJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IGFsbCBsYW5ndWFnZSB0 YWdzIGZvcm1lZCB1bmRlciB0aGUNCiAgIGd1aWRlbGluZXMgaW4gdGhpcyBkb2N1bWVudCB3ZXJl IGVpdGhlciBsZWdhbCwgd2VsbC1mb3JtZWQgdGFncyBvcg0KICAgY291bGQgaGF2ZSBiZWVuIHJl Z2lzdGVyZWQgdW5kZXIgUkZDIDMwNjYuDQoNCjIuMi45ICBDbGFzc2VzIG9mIENvbmZvcm1hbmNl DQoNCiAgIEltcGxlbWVudGF0aW9ucyBzb21ldGltZXMgbmVlZCB0byBkZXNjcmliZSB0aGVpciBj YXBhYmlsaXRpZXMgd2l0aA0KICAgcmVnYXJkIHRvIHRoZSBydWxlcyBhbmQgcHJhY3RpY2VzIGRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhlcmUNCiAgIGFyZSB0d28gY2xhc3NlcyBvZiBj b25mb3JtaW5nIGltcGxlbWVudGF0aW9ucyBkZXNjcmliZWQgYnkgdGhpcw0KICAgZG9jdW1lbnQ6 ICJ3ZWxsLWZvcm1lZCIgcHJvY2Vzc29ycyBhbmQgInZhbGlkYXRpbmciIHByb2Nlc3NvcnMuDQog ICBDbGFpbXMgb2YgY29uZm9ybWFuY2UgU0hPVUxEIGV4cGxpY2l0bHkgcmVmZXJlbmNlIG9uZSBv ZiB0aGVzZQ0KICAgZGVmaW5pdGlvbnMuDQoNCiAgIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgY2xh aW1zIHRvIGNoZWNrIGZvciB3ZWxsLWZvcm1lZCBsYW5ndWFnZSB0YWdzDQogICBNVVNUOg0KDQog ICBvICBDaGVjayB0aGF0IHRoZSB0YWcgYW5kIGFsbCBvZiBpdHMgc3VidGFncywgaW5jbHVkaW5n IGV4dGVuc2lvbiBhbmQNCiAgICAgIHByaXZhdGUgdXNlIHN1YnRhZ3MsIGNvbmZvcm0gdG8gdGhl IEFCTkYgb3IgdGhhdCB0aGUgdGFnIGlzIG9uIHRoZQ0KICAgICAgbGlzdCBvZiBncmFuZGZhdGhl cmVkIHRhZ3MuDQoNCiAgIG8gIENoZWNrIHRoYXQgc2luZ2xldG9uIHN1YnRhZ3MgdGhhdCBpZGVu dGlmeSBleHRlbnNpb25zIGRvIG5vdA0KICAgICAgcmVwZWF0LiAgRm9yIGV4YW1wbGUsIHRoZSB0 YWcgImVuLWEteHgtYi15eS1hLXp6IiBpcyBub3Qgd2VsbC0NCiAgICAgIGZvcm1lZC4NCg0KICAg V2VsbC1mb3JtZWQgcHJvY2Vzc29ycyBhcmUgc3Ryb25nbHkgZW5jb3VyYWdlZCB0byBpbXBsZW1l bnQgdGhlDQogICBjYW5vbmljYWxpemF0aW9uIHJ1bGVzIGNvbnRhaW5lZCBpbiBTZWN0aW9uIDQu NC4NCg0KICAgQW4gaW1wbGVtZW50YXRpb24gdGhhdCBjbGFpbXMgdG8gYmUgdmFsaWRhdGluZyBN VVNUOg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAy MDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICBv ICBDaGVjayB0aGF0IHRoZSB0YWcgaXMgd2VsbC1mb3JtZWQuDQoNCiAgIG8gIFNwZWNpZnkgdGhl IHBhcnRpY3VsYXIgcmVnaXN0cnkgZGF0ZSBmb3Igd2hpY2ggdGhlIGltcGxlbWVudGF0aW9uDQog ICAgICBwZXJmb3JtcyB2YWxpZGF0aW9uIG9mIHN1YnRhZ3MuDQoNCiAgIG8gIENoZWNrIHRoYXQg ZWl0aGVyIHRoZSB0YWcgaXMgYSBncmFuZGZhdGhlcmVkIHRhZywgb3IgdGhhdCBhbGwNCiAgICAg IGxhbmd1YWdlLCBzY3JpcHQsIHJlZ2lvbiwgYW5kIHZhcmlhbnQgc3VidGFncyBjb25zaXN0IG9m IHZhbGlkDQogICAgICBjb2RlcyBmb3IgdXNlIGluIGxhbmd1YWdlIHRhZ3MgYWNjb3JkaW5nIHRv IHRoZSBJQU5BIHJlZ2lzdHJ5IGFzDQogICAgICBvZiB0aGUgcGFydGljdWxhciBkYXRlIHNwZWNp ZmllZCBieSB0aGUgaW1wbGVtZW50YXRpb24uDQoNCiAgIG8gIFNwZWNpZnkgd2hpY2gsIGlmIGFu eSwgZXh0ZW5zaW9uIFJGQ3MgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuNg0KICAgICAgYXJlIHN1 cHBvcnRlZCwgaW5jbHVkaW5nIHZlcnNpb24sIHJldmlzaW9uLCBhbmQgZGF0ZS4NCg0KICAgbyAg Rm9yIGFueSBzdWNoIGV4dGVuc2lvbnMgc3VwcG9ydGVkLCBjaGVjayB0aGF0IGFsbCBzdWJ0YWdz IHVzZWQgaW4NCiAgICAgIHRoYXQgZXh0ZW5zaW9uIGFyZSB2YWxpZC4NCg0KICAgbyAgRm9yIHZh cmlhbnQgYW5kIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MsIGlmIHRoZSByZWdpc3RyeQ0KICAg ICAgY29udGFpbnMgb25lIG9yIG1vcmUgJ1ByZWZpeCcgZmllbGRzIGZvciB0aGF0IHN1YnRhZywg Y2hlY2sgdGhhdA0KICAgICAgdGhlIHRhZyBtYXRjaGVzIGF0IGxlYXN0IG9uZSBwcmVmaXguICBU aGUgdGFnIG1hdGNoZXMgaWYgYWxsIHRoZQ0KICAgICAgc3VidGFncyBpbiB0aGUgJ1ByZWZpeCcg YWxzbyBhcHBlYXIgaW4gdGhlIHRhZy4gIEZvciBleGFtcGxlLCB0aGUNCiAgICAgIHByZWZpeCAi ZXMtQ08iIG1hdGNoZXMgdGhlIHRhZyAiZXMtTGF0bi1DTy14LXByaXZhdGUiIGJlY2F1c2UgYm90 aA0KICAgICAgdGhlICdlcycgbGFuZ3VhZ2Ugc3VidGFnIGFuZCAnQ08nIHJlZ2lvbiBzdWJ0YWcg YXBwZWFyIGluIHRoZSB0YWcuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUN Cg0KDQozLiAgUmVnaXN0cnkgRm9ybWF0IGFuZCBNYWludGVuYW5jZQ0KDQogICBUaGlzIHNlY3Rp b24gZGVmaW5lcyB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IGFuZCB0aGUgbWFpbnRlbmFu Y2UNCiAgIGFuZCB1cGRhdGUgcHJvY2VkdXJlcyBhc3NvY2lhdGVkIHdpdGggaXQuDQoNCiAgIFRo ZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkgd2lsbCBiZSBtYWludGFpbmVkIHNvIHRoYXQsIGV4 Y2VwdCBmb3INCiAgIGV4dGVuc2lvbiBzdWJ0YWdzLCBpdCBpcyBwb3NzaWJsZSB0byB2YWxpZGF0 ZSBhbGwgb2YgdGhlIHN1YnRhZ3MgdGhhdA0KICAgYXBwZWFyIGluIGEgbGFuZ3VhZ2UgdGFnIHVu ZGVyIHRoZSBwcm92aXNpb25zIG9mIHRoaXMgZG9jdW1lbnQgb3IgaXRzDQogICByZXZpc2lvbnMg b3Igc3VjY2Vzc29ycy4gIEluIGFkZGl0aW9uLCB0aGUgbWVhbmluZyBvZiB0aGUgdmFyaW91cw0K ICAgc3VidGFncyB3aWxsIGJlIHVuYW1iaWd1b3VzIGFuZCBzdGFibGUgb3ZlciB0aW1lLiAgKFRo ZSBtZWFuaW5nIG9mDQogICBwcml2YXRlIHVzZSBzdWJ0YWdzLCBvZiBjb3Vyc2UsIGlzIG5vdCBk ZWZpbmVkIGJ5IHRoZSBJQU5BIHJlZ2lzdHJ5LikNCg0KICAgVGhlIHJlZ2lzdHJ5IGRlZmluZWQg dW5kZXIgdGhpcyBkb2N1bWVudCBjb250YWlucyBhIGNvbXByZWhlbnNpdmUNCiAgIGxpc3Qgb2Yg YWxsIG9mIHRoZSBzdWJ0YWdzIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MuICBUaGlzIGFsbG93cw0K ICAgaW1wbGVtZW50ZXJzIGEgc3RyYWlnaHRmb3J3YXJkIGFuZCByZWxpYWJsZSB3YXkgdG8gdmFs aWRhdGUgbGFuZ3VhZ2UNCiAgIHRhZ3MuDQoNCjMuMSAgRm9ybWF0IG9mIHRoZSBJQU5BIExhbmd1 YWdlIFN1YnRhZyBSZWdpc3RyeQ0KDQogICBUaGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0 cnkgKCJ0aGUgcmVnaXN0cnkiKSBjb25zaXN0cyBvZiBhIHRleHQNCiAgIGZpbGUgdGhhdCBpcyBt YWNoaW5lIHJlYWRhYmxlIGluIHRoZSBmb3JtYXQgZGVzY3JpYmVkIGluIHRoaXMNCiAgIHNlY3Rp b24sIHBsdXMgY29waWVzIG9mIHRoZSByZWdpc3RyYXRpb24gZm9ybXMgYXBwcm92ZWQgYnkgdGhl DQogICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBwcm9j ZXNzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjQuICBXaXRoIHRoZSBleGNlcHRpb24gb2Yg dGhlIHJlZ2lzdHJhdGlvbiBmb3JtcyBmb3INCiAgIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFu dCB0YWdzLCBubyByZWdpc3RyYXRpb24gcmVjb3JkcyB3aWxsIGJlDQogICBtYWludGFpbmVkIGZv ciB0aGUgaW5pdGlhbCBzZXQgb2Ygc3VidGFncy4NCg0KICAgVGhlIHJlZ2lzdHJ5IGlzIGluIGEg bW9kaWZpZWQgcmVjb3JkLWphciBmb3JtYXQgdGV4dCBmaWxlIFtyZWNvcmQtDQogICBqYXJdLiAg TGluZXMgYXJlIGxpbWl0ZWQgdG8gNzIgY2hhcmFjdGVycywgaW5jbHVkaW5nIGFsbCB3aGl0ZXNw YWNlLg0KDQogICBSZWNvcmRzIGFyZSBzZXBhcmF0ZWQgYnkgbGluZXMgY29udGFpbmluZyBvbmx5 IHRoZSBzZXF1ZW5jZSAiJSUiDQogICAoJXgyNS4yNSkuDQoNCiAgIEVhY2ggZmllbGQgY2FuIGJl IHZpZXdlZCBhcyBhIHNpbmdsZSwgbG9naWNhbCBsaW5lICBvZiBBU0NJSQ0KICAgY2hhcmFjdGVy cywgIGNvbXByaXNpbmcgYSBmaWVsZC1uYW1lIGFuZCBhIGZpZWxkLWJvZHkgc2VwYXJhdGVkIGJ5 IGENCiAgIENPTE9OIGNoYXJhY3RlciAoJXgzQSkuICBGb3IgY29udmVuaWVuY2UsIHRoZSBmaWVs ZC1ib2R5IHBvcnRpb24gIG9mDQogICB0aGlzICBjb25jZXB0dWFsIGVudGl0eSAgY2FuIGJlIHNw bGl0IGludG8gYSBtdWx0aXBsZS1saW5lDQogICByZXByZXNlbnRhdGlvbjsgdGhpcyBpcyBjYWxs ZWQgImZvbGRpbmciLiAgVGhlIGZvcm1hdCBvZiB0aGUgcmVnaXN0cnkNCiAgIGlzIGRlc2NyaWJl ZCBieSB0aGUgZm9sbG93aW5nIEFCTkYgKHBlciBbUkZDMjIzNGJpc10pOg0KDQogICByZWdpc3Ry eSAgID0gcmVjb3JkICooIiUlIiBDUkxGIHJlY29yZCkNCiAgIHJlY29yZCAgICAgPSAxKiggZmll bGQtbmFtZSAqU1AgIjoiICpTUCBmaWVsZC1ib2R5IENSTEYgKQ0KICAgZmllbGQtbmFtZSA9IChB TFBIQSAvIERJR0lUKVsqKEFMUEhBIC8gRElHSVQgLyAiLSIpIChBTFBIQSAvIERJR0lUKV0NCiAg IGZpZWxkLWJvZHkgPSAqKEFTQ0NIQVIvTFdTUCkNCiAgIEFTQ0NIQVIgICAgPSAleDIxLTI1IC8g JXgyNy03RSAvIFVOSUNIQVIgOyBOb3RlOiBBTVBFUlNBTkQgaXMgJXgyNg0KICAgVU5JQ0hBUiAg ICA9ICImI3giIDIqNkhFWERJRyAiOyINCg0KICAgVGhlIHNlcXVlbmNlICcuLicgKCV4MkUuMkUp IGluIGEgZmllbGQtYm9keSBkZW5vdGVzIGEgcmFuZ2Ugb2YNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDE4 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgdmFsdWVzLiAgU3VjaCBhIHJhbmdlIHJlcHJl c2VudHMgYWxsIHN1YnRhZ3Mgb2YgdGhlIHNhbWUgbGVuZ3RoIHRoYXQNCiAgIGFyZSBhbHBoYWJl dGljYWxseSB3aXRoaW4gdGhhdCByYW5nZSwgaW5jbHVkaW5nIHRoZSB2YWx1ZXMgZXhwbGljaXRs eQ0KICAgbWVudGlvbmVkLiAgRm9yIGV4YW1wbGUgJ2EuLmMnIGRlbm90ZXMgdGhlIHZhbHVlcyAn YScsICdiJywgYW5kICdjJy4NCg0KICAgQ2hhcmFjdGVycyBmcm9tIG91dHNpZGUgdGhlIFVTLUFT Q0lJW0lTTzY0Nl0gcmVwZXJ0b2lyZSwgYXMgd2VsbCBhcw0KICAgdGhlIEFNUEVSU0FORCBjaGFy YWN0ZXIgKCImIiwgJXgyNikgd2hlbiBpdCBvY2N1cnMgaW4gYSBmaWVsZC1ib2R5DQogICBhcmUg cmVwcmVzZW50ZWQgYnkgYSAiTnVtZXJpYyBDaGFyYWN0ZXIgUmVmZXJlbmNlIiB1c2luZyBoZXhh ZGVjaW1hbA0KICAgbm90YXRpb24gaW4gdGhlIHN0eWxlIHVzZWQgYnkgW1hNTDEwXSAoc2VlDQog ICA8aHR0cDovL3d3dy53My5vcmcvVFIvUkVDLXhtbC8jZHQtY2hhcnJlZj4pLiAgVGhpcyBjb25z aXN0cyBvZiB0aGUNCiAgIHNlcXVlbmNlICImI3giICgleDI2LjIzLjc4KSBmb2xsb3dlZCBieSBh IGhleGFkZWNpbWFsIHJlcHJlc2VudGF0aW9uDQogICBvZiB0aGUgY2hhcmFjdGVyJ3MgY29kZSBw b2ludCBpbiBbSVNPMTA2NDZdIGZvbGxvd2VkIGJ5IGEgY2xvc2luZw0KICAgc2VtaWNvbG9uICgl eDNCKS4gIEZvciBleGFtcGxlLCB0aGUgRVVSTyBTSUdOLCBVKzIwQUMsIHdvdWxkIGJlDQogICBy ZXByZXNlbnRlZCBieSB0aGUgc2VxdWVuY2UgIiYjeDIwQUM7Ii4gIE5vdGUgdGhhdCB0aGUgaGV4 YWRlY2ltYWwNCiAgIG5vdGF0aW9uIE1BWSBoYXZlIGJldHdlZW4gdHdvIGFuZCBzaXggZGlnaXRz Lg0KDQogICBBbGwgZmllbGRzIHdob3NlIGZpZWxkLWJvZHkgY29udGFpbnMgYSBkYXRlIHZhbHVl IHVzZSB0aGUgImZ1bGwtZGF0ZSINCiAgIGZvcm1hdCBzcGVjaWZpZWQgaW4gW1JGQzMzMzldLiAg Rm9yIGV4YW1wbGU6ICIyMDA0LTA2LTI4IiByZXByZXNlbnRzDQogICBKdW5lIDI4LCAyMDA0IGlu IHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIuDQoNCiAgIFRoZSBmaXJzdCByZWNvcmQgaW4gdGhlIGZp bGUgY29udGFpbnMgdGhlIHNpbmdsZSBmaWVsZCB3aG9zZSBmaWVsZC0NCiAgIG5hbWUgaXMgIkZp bGUtRGF0ZSIuICBUaGUgZmllbGQtYm9keSBvZiB0aGlzIHJlY29yZCBjb250YWlucyB0aGUgbGFz dA0KICAgbW9kaWZpY2F0aW9uIGRhdGUgb2YgdGhpcyBjb3B5IG9mIHRoZSByZWdpc3RyeSwgbWFr aW5nIGl0IHBvc3NpYmxlIHRvDQogICBjb21wYXJlIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiB0aGUg cmVnaXN0cnkuICBUaGUgcmVnaXN0cnkgb24gdGhlIElBTkENCiAgIHdlYnNpdGUgaXMgdGhlIG1v c3QgY3VycmVudC4gIFZlcnNpb25zIHdpdGggYW4gb2xkZXIgZGF0ZSB0aGFuIHRoYXQNCiAgIG9u ZSBhcmUgbm90IHVwLXRvLWRhdGUuDQoNCiAgIEZpbGUtRGF0ZTogMjAwNC0wNi0yOA0KICAgJSUN Cg0KICAgU3Vic2VxdWVudCByZWNvcmRzIHJlcHJlc2VudCBzdWJ0YWdzIGluIHRoZSByZWdpc3Ry eS4gIEVhY2ggb2YgdGhlDQogICBmaWVsZHMgaW4gZWFjaCByZWNvcmQgTVVTVCBvY2N1ciBubyBt b3JlIHRoYW4gb25jZSwgdW5sZXNzIG90aGVyd2lzZQ0KICAgbm90ZWQgYmVsb3cuICBFYWNoIHJl Y29yZCBNVVNUIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoNCiAgIG8gICdUeXBlJw0K DQogICAgICAqICBUeXBlJ3MgZmllbGQtdmFsdWUgTVVTVCBjb25zaXN0IG9mIG9uZSBvZiB0aGUg Zm9sbG93aW5nDQogICAgICAgICBzdHJpbmdzOiAibGFuZ3VhZ2UiLCAiZXh0bGFuZyIsICJzY3Jp cHQiLCAicmVnaW9uIiwgInZhcmlhbnQiLA0KICAgICAgICAgImdyYW5kZmF0aGVyZWQiLCBhbmQg InJlZHVuZGFudCIgYW5kIGRlbm90ZXMgdGhlIHR5cGUgb2YgdGFnIG9yDQogICAgICAgICBzdWJ0 YWcuDQoNCiAgIG8gIEVpdGhlciAnU3VidGFnJyBvciAnVGFnJw0KDQogICAgICAqICBTdWJ0YWcn cyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgc3VidGFnIGJlaW5nIGRlZmluZWQuICBUaGlzDQog ICAgICAgICBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMgb2Ygd2hvc2UgJ1R5cGUn IGhhcyBvbmUgb2YNCiAgICAgICAgIHRoZXNlIHZhbHVlczogImxhbmd1YWdlIiwgImV4dGxhbmci LCAic2NyaXB0IiwgInJlZ2lvbiIsIG9yDQogICAgICAgICAidmFyaWFudCIuDQoNCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAg ICAgICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAqICBUYWcncyBm aWVsZC12YWx1ZSBjb250YWlucyBhIGNvbXBsZXRlIGxhbmd1YWdlIHRhZy4gIFRoaXMgZmllbGQN CiAgICAgICAgIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3JkcyB3aG9zZSAnVHlwZScgaGFzIG9u ZSBvZiB0aGVzZQ0KICAgICAgICAgdmFsdWVzOiAiZ3JhbmRmYXRoZXJlZCIgb3IgInJlZHVuZGFu dCIuDQoNCiAgIG8gIERlc2NyaXB0aW9uDQoNCiAgICAgICogIERlc2NyaXB0aW9uJ3MgZmllbGQt dmFsdWUgY29udGFpbnMgYSBub24tbm9ybWF0aXZlIGRlc2NyaXB0aW9uDQogICAgICAgICBvZiB0 aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgQWRkZWQNCg0KICAgICAgKiAgQWRkZWQncyBmaWVs ZC12YWx1ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcyBhZGRlZCB0bw0KICAgICAg ICAgdGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgJ1N1YnRhZycgb3IgJ1RhZycgZmllbGQgTVVTVCB1 c2UgbG93ZXJjYXNlIGxldHRlcnMgdG8gZm9ybSB0aGUNCiAgIHN1YnRhZyBvciB0YWcsIHdpdGgg dHdvIGV4Y2VwdGlvbnMuICBTdWJ0YWdzIHdob3NlICdUeXBlJyBmaWVsZCBpcw0KICAgJ3Njcmlw dCcgKGluIG90aGVyIHdvcmRzLCBzdWJ0YWdzIGRlZmluZWQgYnkgSVNPIDE1OTI0KSBNVVNUIHVz ZQ0KICAgdGl0bGVjYXNlLiAgU3VidGFncyB3aG9zZSAnVHlwZScgZmllbGQgaXMgJ3JlZ2lvbicg KGluIG90aGVyIHdvcmRzLA0KICAgc3VidGFncyBkZWZpbmVkIGJ5IElTTyAzMTY2KSBNVVNUIHVz ZSB1cHBlcmNhc2UuICBUaGVzZSBleGNlcHRpb25zDQogICBtaXJyb3IgdGhlIHVzZSBvZiBjYXNl IGluIHRoZSB1bmRlcmx5aW5nIHN0YW5kYXJkcy4NCg0KICAgVGhlIGZpZWxkICdEZXNjcmlwdGlv bicgTUFZIGFwcGVhciBtb3JlIHRoYW4gb25lIHRpbWUuICBBdCBsZWFzdCBvbmUNCiAgIG9mIHRo ZSAgJ0Rlc2NyaXB0aW9uJyBmaWVsZHMgTVVTVCBjb250YWluIGEgZGVzY3JpcHRpb24gb2YgdGhl IHRhZw0KICAgYmVpbmcgcmVnaXN0ZXJlZCB3cml0dGVuIG9yIHRyYW5zY3JpYmVkIGludG8gdGhl IExhdGluIHNjcmlwdDsgdGhlDQogICBzYW1lIG9yIGFkZGl0aW9uYWwgZmllbGRzIE1BWSBhbHNv IGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5vbi0NCiAgIExhdGluIHNjcmlwdC4gIFRoZSAn RGVzY3JpcHRpb24nIGZpZWxkIGlzIHVzZWQgZm9yIGlkZW50aWZpY2F0aW9uDQogICBwdXJwb3Nl cyBhbmQgU0hPVUxEIE5PVCBiZSB0YWtlbiB0byByZXByZXNlbnQgdGhlIGFjdHVhbCBuYXRpdmUg bmFtZQ0KICAgb2YgdGhlIGxhbmd1YWdlIG9yIHZhcmlhdGlvbiBvciB0byBiZSBpbiBhbnkgcGFy dGljdWxhciBsYW5ndWFnZS4NCiAgIE1vc3QgZGVzY3JpcHRpb25zIGFyZSB0YWtlbiBkaXJlY3Rs eSBmcm9tIHNvdXJjZSBzdGFuZGFyZHMgc3VjaCBhcw0KICAgSVNPIDYzOSBvciBJU08gMzE2Ni4N Cg0KICAgTm90ZTogRGVzY3JpcHRpb25zIGluIHJlZ2lzdHJ5IGVudHJpZXMgdGhhdCBjb3JyZXNw b25kIHRvIElTTyA2MzksDQogICBJU08gMTU5MjQsICBJU08gMzE2NiBvciBVTiBNLjQ5IGNvZGVz IGFyZSBpbnRlbmRlZCBvbmx5IHRvIGluZGljYXRlDQogICB0aGUgbWVhbmluZyBvZiB0aGF0IGlk ZW50aWZpZXIgYXMgZGVmaW5lZCBpbiB0aGUgc291cmNlIHN0YW5kYXJkIGF0DQogICB0aGUgdGlt ZSBpdCB3YXMgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5LiAgVGhlIGRlc2NyaXB0aW9uIGRvZXMgbm90 DQogICByZXBsYWNlIHRoZSBjb250ZW50IG9mIHRoZSBzb3VyY2Ugc3RhbmRhcmQgaXRzZWxmLiAg VGhlIGRlc2NyaXB0aW9ucw0KICAgYXJlIG5vdCBpbnRlbmRlZCB0byBiZSB0aGUgRW5nbGlzaCBs b2NhbGl6ZWQgbmFtZXMgZm9yIHRoZSBzdWJ0YWdzLg0KICAgTG9jYWxpemF0aW9uIG9yIHRyYW5z bGF0aW9uIG9mIGxhbmd1YWdlIHRhZyBhbmQgc3VidGFnIGRlc2NyaXB0aW9ucw0KICAgaXMgb3V0 IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIEVhY2ggcmVjb3JkIE1BWSBhbHNvIGNv bnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoNCiAgIG8gIFByZWZlcnJlZC1WYWx1ZQ0KDQog ICAgICAqICBGb3IgZmllbGRzIG9mIHR5cGUgJ2xhbmd1YWdlJywgJ2V4dGxhbmcnLCAnc2NyaXB0 JywgJ3JlZ2lvbicsDQogICAgICAgICBhbmQgJ3ZhcmlhbnQnLCAnUHJlZmVycmVkLVZhbHVlJyBj b250YWlucyBhIHN1YnRhZyBvZiB0aGUgc2FtZQ0KICAgICAgICAgJ1R5cGUnIHdoaWNoIGlzIHBy ZWZlcnJlZCBmb3IgZm9ybWluZyB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFn ZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgICAgICogIEZvciBmaWVsZHMgb2YgdHlw ZSAnZ3JhbmRmYXRoZXJlZCcgYW5kICdyZWR1bmRhbnQnLCBhIGNhbm9uaWNhbA0KICAgICAgICAg bWFwcGluZyB0byBhIGNvbXBsZXRlIGxhbmd1YWdlIHRhZy4NCg0KICAgbyAgRGVwcmVjYXRlZA0K DQogICAgICAqICBEZXByZWNhdGVkJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgdGhlIGRhdGUgdGhl IHJlY29yZCB3YXMNCiAgICAgICAgIGRlcHJlY2F0ZWQuDQoNCiAgIG8gIFByZWZpeA0KDQogICAg ICAqICBQcmVmaXgncyBmaWVsZC12YWx1ZSBjb250YWlucyBhIGxhbmd1YWdlIHRhZyB3aXRoIHdo aWNoIHRoaXMNCiAgICAgICAgIHN1YnRhZyBNQVkgYmUgdXNlZCB0byBmb3JtIGEgbmV3IGxhbmd1 YWdlIHRhZywgcGVyaGFwcyB3aXRoDQogICAgICAgICBvdGhlciBzdWJ0YWdzIGFzIHdlbGwuICBU aGlzIGZpZWxkIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3Jkcw0KICAgICAgICAgd2hvc2UgJ1R5 cGUnIGZpZWxkLXZhbHVlIGlzICd2YXJpYW50JyBvciAnZXh0bGFuZycuICBGb3INCiAgICAgICAg IGV4YW1wbGUsIHRoZSAnUHJlZml4JyBmb3IgdGhlIHZhcmlhbnQgJ25lZGlzJyBpcyAnc2wnLCBt ZWFuaW5nDQogICAgICAgICB0aGF0IHRoZSB0YWdzICJzbC1uZWRpcyIgYW5kICJzbC1JVC1uZWRp cyIgbWlnaHQgYmUgYXBwcm9wcmlhdGUNCiAgICAgICAgIHdoaWxlIHRoZSB0YWcgImlzLW5lZGlz IiBpcyBub3QuDQoNCiAgIG8gIENvbW1lbnRzDQoNCiAgICAgICogIENvbW1lbnRzIGNvbnRhaW5z IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHN1YnRhZywgYXMNCiAgICAgICAgIGRl ZW1lZCBhcHByb3ByaWF0ZSBmb3IgdW5kZXJzdGFuZGluZyB0aGUgcmVnaXN0cnkgYW5kDQogICAg ICAgICBpbXBsZW1lbnRpbmcgbGFuZ3VhZ2UgdGFncyB1c2luZyB0aGUgc3VidGFnIG9yIHRhZy4N Cg0KICAgbyAgU3VwcHJlc3MtU2NyaXB0DQoNCiAgICAgICogIFN1cHByZXNzLVNjcmlwdCBjb250 YWlucyBhIHNjcmlwdCBzdWJ0YWcgdGhhdCBTSE9VTEQgTk9UIGJlDQogICAgICAgICB1c2VkIHRv IGZvcm0gbGFuZ3VhZ2UgdGFncyB3aXRoIHRoZSBhc3NvY2lhdGVkIHByaW1hcnkgbGFuZ3VhZ2UN CiAgICAgICAgIHN1YnRhZy4gIFRoaXMgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRz IHdob3NlICdUeXBlJw0KICAgICAgICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFNlZSBT ZWN0aW9uIDQuMS4NCg0KICAgVGhlIGZpZWxkICdEZXByZWNhdGVkJyBNQVkgYmUgYWRkZWQgdG8g YW55IHJlY29yZCB2aWEgdGhlIG1haW50ZW5hbmNlDQogICBwcm9jZXNzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDMuMiBvciB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzDQogICBkZXNjcmliZWQg aW4gU2VjdGlvbiAzLjQuICBVc3VhbGx5IHRoZSBhZGRpdGlvbiBvZiBhICdEZXByZWNhdGVkJw0K ICAgZmllbGQgaXMgZHVlIHRvIHRoZSBhY3Rpb24gb2Ygb25lIG9mIHRoZSBzdGFuZGFyZHMgYm9k aWVzLCBzdWNoIGFzDQogICBJU08gMzE2Niwgd2l0aGRyYXdpbmcgYSBjb2RlLiAgSW4gc29tZSBo aXN0b3JpY2FsIGNhc2VzIGl0IG1pZ2h0IG5vdA0KICAgaGF2ZSBiZWVuIHBvc3NpYmxlIHRvIHJl Y29uc3RydWN0IHRoZSBvcmlnaW5hbCBkZXByZWNhdGlvbiBkYXRlLiAgRm9yDQogICB0aGVzZSBj YXNlcywgYW4gYXBwcm94aW1hdGUgZGF0ZSBhcHBlYXJzIGluIHRoZSByZWdpc3RyeS4gIEFsdGhv dWdoDQogICB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLCBzdWJ0YWdzIGFuZCB0YWdzIHdpdGggYSAn RGVwcmVjYXRlZCcgZmllbGQNCiAgIGFyZSBkZXByZWNhdGVkIGFuZCB2YWxpZGF0aW5nIHByb2Nl c3NvcnMgU0hPVUxEIE5PVCBnZW5lcmF0ZSB0aGVzZQ0KICAgc3VidGFncy4gIE5vdGUgdGhhdCBh IHJlY29yZCB0aGF0IGNvbnRhaW5zIGEgJ0RlcHJlY2F0ZWQnIGZpZWxkIGFuZA0KICAgbm8gY29y cmVzcG9uZGluZyAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBoYXMgbm8gcmVwbGFjZW1lbnQgbWFw cGluZy4NCg0KICAgVGhlIGZpZWxkICdQcmVmZXJyZWQtVmFsdWUnIGNvbnRhaW5zIGEgbWFwcGlu ZyBiZXR3ZWVuIHRoZSByZWNvcmQgaW4NCiAgIHdoaWNoIGl0IGFwcGVhcnMgYW5kIGEgdGFnIG9y IHN1YnRhZyB3aGljaCBTSE9VTEQgYmUgcHJlZmVycmVkIHdoZW4NCiAgIHNlbGVjdGVkIGxhbmd1 YWdlIHRhZ3MuICBUaGVzZSB2YWx1ZXMgZm9ybSB0aHJlZSBncm91cHM6DQoNCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAg ICAgW1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICBJU08gNjM5IGxhbmd1 YWdlIGNvZGVzIHdoaWNoIHdlcmUgbGF0ZXIgd2l0aGRyYXduIGluIGZhdm9yIG9mDQogICAgICBv dGhlciBjb2Rlcy4gIFRoZXNlIHZhbHVlcyBhcmUgbW9zdGx5IGEgaGlzdG9yaWNhbCBjdXJpb3Np dHkuDQoNCiAgICAgIElTTyAzMTY2IHJlZ2lvbiBjb2RlcyB3aGljaCBoYXZlIGJlZW4gd2l0aGRy YXduIGluIGZhdm9yIG9mIGEgbmV3DQogICAgICBjb2RlLiAgVGhpcyBzb21ldGltZXMgaGFwcGVu cyB3aGVuIGEgY291bnRyeSBjaGFuZ2VzIGl0cyBuYW1lIG9yDQogICAgICBhZG1pbmlzdHJhdGlv biBpbiBzdWNoIGEgd2F5IHRoYXQgd2FycmFudHMgYSBuZXcgcmVnaW9uIGNvZGUuDQoNCiAgICAg IFRhZ3MgZ3JhbmRmYXRoZXJlZCBmcm9tIFJGQyAzMDY2LiAgSW4gbWFueSBjYXNlcyB0aGVzZSB0 YWdzIGhhdmUNCiAgICAgIGJlY29tZSBvYnNvbGV0ZSBiZWNhdXNlIHRoZSB2YWx1ZXMgdGhleSBy ZXByZXNlbnQgd2VyZSBsYXRlcg0KICAgICAgZW5jb2RlZCBieSBJU08gNjM5Lg0KDQogICBSZWNv cmRzIHRoYXQgY29udGFpbiBhICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIE1VU1QgYWxzbyBoYXZl IGENCiAgICdEZXByZWNhdGVkJyBmaWVsZC4gIFRoaXMgZmllbGQgY29udGFpbnMgYSBkYXRlIG9m IGRlcHJlY2F0aW9uLiAgVGh1cw0KICAgYSBsYW5ndWFnZSB0YWcgcHJvY2Vzc29yIGNhbiB1c2Ug dGhlIHJlZ2lzdHJ5IHRvIGNvbnN0cnVjdCB0aGUgdmFsaWQsDQogICBub24tZGVwcmVjYXRlZCBz ZXQgb2Ygc3VidGFncyBmb3IgYSBnaXZlbiBkYXRlLiAgSW4gYWRkaXRpb24sIGZvciBhbnkNCiAg IGdpdmVuIHRhZywgYSBwcm9jZXNzb3IgY2FuIGNvbnN0cnVjdCB0aGUgc2V0IG9mIHZhbGlkIGxh bmd1YWdlIHRhZ3MNCiAgIHRoYXQgY29ycmVzcG9uZCB0byB0aGF0IHRhZyBmb3IgYWxsIGRhdGVz IHVwIHRvIHRoZSBkYXRlIG9mIHRoZQ0KICAgcmVnaXN0cnkuICBUaGUgYWJpbGl0eSB0byBkbyB0 aGVzZSBtYXBwaW5ncyBNQVkgYmUgYmVuZWZpY2lhbCB0bw0KICAgYXBwbGljYXRpb25zIHRoYXQg YXJlIG1hdGNoaW5nLCBzZWxlY3RpbmcsIGZvciBmaWx0ZXJpbmcgY29udGVudA0KICAgYmFzZWQg b24gaXRzIGxhbmd1YWdlIHRhZ3MuDQoNCiAgIE5vdGUgdGhhdCAnUHJlZmVycmVkLVZhbHVlJyBt YXBwaW5ncyBpbiByZWNvcmRzIG9mIHR5cGUgJ3JlZ2lvbicNCiAgIHNvbWV0aW1lcyBkbyBub3Qg cmVwcmVzZW50IGV4YWN0bHkgdGhlIHNhbWUgbWVhbmluZyBhcyB0aGUgb3JpZ2luYWwNCiAgIHZh bHVlLiAgVGhlcmUgYXJlIG1hbnkgcmVhc29ucyBmb3IgYSBjb3VudHJ5IGNvZGUgdG8gYmUgY2hh bmdlZCBhbmQNCiAgIHRoZSBlZmZlY3QgdGhpcyBoYXMgb24gdGhlIGZvcm1hdGlvbiBvZiBsYW5n dWFnZSB0YWdzIHdpbGwgZGVwZW5kIG9uDQogICB0aGUgbmF0dXJlIG9mIHRoZSBjaGFuZ2UgaW4g cXVlc3Rpb24uDQoNCiAgIEluIHBhcnRpY3VsYXIsIHRoZSAnUHJlZmVycmVkLVZhbHVlJyBmaWVs ZCBkb2VzIG5vdCBpbXBseSByZXRhZ2dpbmcNCiAgIGNvbnRlbnQgdGhhdCB1c2VzIHRoZSBhZmZl Y3RlZCBzdWJ0YWcuDQoNCiAgIFRoZSBmaWVsZCAnUHJlZmVycmVkLVZhbHVlJyBNVVNUIE5PVCBi ZSBtb2RpZmllZCBvbmNlIGNyZWF0ZWQgaW4gdGhlDQogICByZWdpc3RyeS4gIFRoZSBmaWVsZCBN QVkgYmUgYWRkZWQgdG8gcmVjb3JkcyBvZiB0eXBlICJncmFuZGZhdGhlcmVkIg0KICAgYW5kICJy ZWdpb24iIGFjY29yZGluZyB0byB0aGUgcnVsZXMgaW4gU2VjdGlvbiAzLjIuICBPdGhlcndpc2Ug dGhlDQogICBmaWVsZCBNVVNUIE5PVCBiZSBhZGRlZCB0byBhbnkgcmVjb3JkIGFscmVhZHkgaW4g dGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQgaW4gcmVjb3Jk cyBvZiB0eXBlICJncmFuZGZhdGhlcmVkIiBhbmQNCiAgICJyZWR1bmRhbnQiIGNvbnRhaW5zIHdo b2xlIGxhbmd1YWdlIHRhZ3MgdGhhdCBhcmUgc3Ryb25nbHkNCiAgIFJFQ09NTUVOREVEIGZvciB1 c2UgaW4gcGxhY2Ugb2YgdGhlIHJlY29yZCdzIHZhbHVlLiAgSW4gbWFueSBjYXNlcw0KICAgdGhl IG1hcHBpbmdzIHdlcmUgY3JlYXRlZCBieSBkZXByZWNhdGlvbiBvZiB0aGUgdGFncyBkdXJpbmcg dGhlDQogICBwZXJpb2QgYmVmb3JlIHRoaXMgZG9jdW1lbnQgd2FzIGFkb3B0ZWQuICBGb3IgZXhh bXBsZSwgdGhlIHRhZyAibm8tDQogICBueW4iIHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRo ZSBJU08gNjM5LTEgZGVmaW5lZCBsYW5ndWFnZSBjb2RlDQogICAnbm4nLg0KDQogICBSZWNvcmRz IG9mIHR5cGUgJ3ZhcmlhbnQnIE1BWSBoYXZlIG1vcmUgdGhhbiBvbmUgZmllbGQgb2YgdHlwZQ0K ICAgJ1ByZWZpeCcuICBBZGRpdGlvbmFsIGZpZWxkcyBvZiB0aGlzIHR5cGUgTUFZIGJlIGFkZGVk IHRvIGEgJ3ZhcmlhbnQnDQogICByZWNvcmQgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4N Cg0KICAgUmVjb3JkcyBvZiB0eXBlICdleHRsYW5nJyBNVVNUIGhhdmUgX2V4YWN0bHlfIG9uZSAn UHJlZml4JyBmaWVsZC4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDIyXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1 DQoNCg0KICAgVGhlIGZpZWxkLXZhbHVlIG9mIHRoZSAnUHJlZml4JyBmaWVsZCBjb25zaXN0cyBv ZiBhIGxhbmd1YWdlIHRhZw0KICAgd2hvc2Ugc3VidGFncyBhcmUgYXBwcm9wcmlhdGUgdG8gdXNl IHdpdGggdGhpcyBzdWJ0YWcuICBGb3IgZXhhbXBsZSwNCiAgIHRoZSB2YXJpYW50IHN1YnRhZyAn MTk5NicgaGFzIGEgUHJlZml4IGZpZWxkIG9mICJkZSIuICBUaGlzIG1lYW5zDQogICB0aGF0IHRh Z3Mgc3RhcnRpbmcgd2l0aCB0aGUgc2VxdWVuY2UgImRlLSIgYXJlIGFwcHJvcHJpYXRlIHdpdGgg dGhpcw0KICAgc3VidGFnLCBzbyAiZGUtTGF0Zy0xOTk2IiBhbmQgImRlLUNILTE5OTYiIGFyZSBi b3RoIGFjY2VwdGFibGUsIHdoaWxlDQogICB0aGUgdGFnICJmci0xOTk2IiBpcyBhbiBpbmFwcHJv cHJpYXRlIGNob2ljZS4NCg0KICAgVGhlIGZpZWxkIG9mIHR5cGUgJ1ByZWZpeCcgTVVTVCBOT1Qg YmUgcmVtb3ZlZCBmcm9tIGFueSByZWNvcmQuICBUaGUNCiAgIGZpZWxkLXZhbHVlIGZvciB0aGlz IHR5cGUgb2YgZmllbGQgTVVTVCBOT1QgYmUgbW9kaWZpZWQuDQoNCiAgIFRoZSBmaWVsZCAnQ29t bWVudHMnIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgcGVyIHJlY29yZC4gIFRoaXMNCiAgIGZp ZWxkIE1BWSBiZSBpbnNlcnRlZCBvciBjaGFuZ2VkIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nl c3MgYW5kIG5vDQogICBndWFyYW50ZWUgb2Ygc3RhYmlsaXR5IGlzIHByb3ZpZGVkLiAgVGhlIGNv bnRlbnQgb2YgdGhpcyBmaWVsZCBpcyBub3QNCiAgIHJlc3RyaWN0ZWQsIGV4Y2VwdCBieSB0aGUg bmVlZCB0byByZWdpc3RlciB0aGUgaW5mb3JtYXRpb24sIHRoZQ0KICAgc3VpdGFiaWxpdHkgb2Yg dGhlIHJlcXVlc3QsIGFuZCBieSByZWFzb25hYmxlIHByYWN0aWNhbCBzaXplDQogICBsaW1pdGF0 aW9ucy4gIExvbmcgdGV4dHMgYWJvdXQgYSBwYXJ0aWN1bGFyIHN1YnRhZyBhcmUgZnJvd25lZCB1 cG9uLg0KDQogICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTVVTVCBvbmx5IGFwcGVhciBp biByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFRo aXMgZmllbGQgTVVTVCBOT1QgYXBwZWFyIG1vcmUgdGhhbiBvbmUNCiAgIHRpbWUgaW4gYSByZWNv cmQuICBUaGlzIGZpZWxkIGluZGljYXRlcyBhIHNjcmlwdCB1c2VkIHRvIHdyaXRlIHRoZQ0KICAg b3ZlcndoZWxtaW5nIG1ham9yaXR5IG9mIGRvY3VtZW50cyBmb3IgdGhlIGdpdmVuIGxhbmd1YWdl IGFuZCB3aGljaA0KICAgdGhlcmVmb3JlIGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRp b24gdG8gYSBsYW5ndWFnZSB0YWcuICBJdA0KICAgaGVscHMgZW5zdXJlIGdyZWF0ZXIgY29tcGF0 aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFnZSB0YWdzDQogICBnZW5lcmF0ZWQgYWNjb3JkaW5n IHRvIHRoZSBydWxlcyBpbiB0aGlzIGRvY3VtZW50IGFuZCBsYW5ndWFnZSB0YWdzDQogICBhbmQg dGFnIHByb2Nlc3NvcnMgb3IgY29uc3VtZXJzIGJhc2VkIG9uIFJGQyAzMDY2LiAgRm9yIGV4YW1w bGUsDQogICB2aXJ0dWFsbHkgYWxsIEljZWxhbmRpYyBkb2N1bWVudHMgYXJlIHdyaXR0ZW4gaW4g dGhlIExhdGluIHNjcmlwdCwNCiAgIG1ha2luZyB0aGUgc3VidGFnICdMYXRuJyByZWR1bmRhbnQg aW4gdGhlIHRhZyAiaXMtTGF0biIuDQoNCjMuMiAgTWFpbnRlbmFuY2Ugb2YgdGhlIFJlZ2lzdHJ5 DQoNCiAgIE1haW50ZW5hbmNlIG9mIHRoZSByZWdpc3RyeSByZXF1aXJlcyB0aGF0IGFzIGNvZGVz IGFyZSBhc3NpZ25lZCBvcg0KICAgd2l0aGRyYXduIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgSVNP IDMxNjYsIGFuZCBVTiBNLjQ5LCB0aGUgTGFuZ3VhZ2UNCiAgIFN1YnRhZyBSZXZpZXdlciBNVVNU IGV2YWx1YXRlIGVhY2ggY2hhbmdlLCBkZXRlcm1pbmUgd2hldGhlciBpdA0KICAgY29uZmxpY3Rz IHdpdGggZXhpc3RpbmcgcmVnaXN0cnkgZW50cmllcywgYW5kIHN1Ym1pdCB0aGUgaW5mb3JtYXRp b24NCiAgIHRvIElBTkEgZm9yIGluY2x1c2lvbiBpbiB0aGUgcmVnaXN0cnkuICBJZiBhbiBjaGFu Z2UgdGFrZXMgcGxhY2UgYW5kDQogICB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGRvZXMg bm90IGRvIHRoaXMgaW4gYSB0aW1lbHkgbWFubmVyLA0KICAgdGhlbiBhbnkgaW50ZXJlc3RlZCBw YXJ0eSBNQVkgdXNlIHRoZSBwcm9jZWR1cmUgaW4gU2VjdGlvbiAzLjQgdG8NCiAgIHJlZ2lzdGVy IHRoZSBhcHByb3ByaWF0ZSB1cGRhdGUuDQoNCiAgIE5vdGU6IFRoZSByZWR1bmRhbnQgYW5kIGdy YW5kZmF0aGVyZWQgZW50cmllcyB0b2dldGhlciBhcmUgdGhlDQogICBjb21wbGV0ZSBsaXN0IG9m IHRhZ3MgcmVnaXN0ZXJlZCB1bmRlciBbUkZDMzA2Nl0uICBUaGUgcmVkdW5kYW50IHRhZ3MNCiAg IGFyZSB0aG9zZSB0aGF0IGNhbiBub3cgYmUgZm9ybWVkIHVzaW5nIHRoZSBzdWJ0YWdzIGRlZmlu ZWQgaW4gdGhlDQogICByZWdpc3RyeSB0b2dldGhlciB3aXRoIHRoZSBydWxlcyBvZiAgU2VjdGlv biAyLjIuICBUaGUgZ3JhbmRmYXRoZXJlZA0KICAgZW50cmllcyBhcmUgdGhvc2UgdGhhdCBjYW4g bmV2ZXIgYmUgbGVnYWwgdW5kZXIgdGhvc2Ugc2FtZQ0KICAgcHJvdmlzaW9ucy4NCg0KICAgVGhl IHNldCBvZiByZWR1bmRhbnQgYW5kIGdyYW5kZmF0aGVyZWQgdGFncyBpcyBwZXJtYW5lbnQgYW5k IHN0YWJsZToNCiAgIG5ldyBlbnRyaWVzIGluIHRoaXMgc2VjdGlvbiBNVVNUIE5PVCBiZSBhZGRl ZCBhbmQgZXhpc3RpbmcgZW50cmllcw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVn dXN0IDIwMDUNCg0KDQogICBNVVNUIE5PVCBiZSByZW1vdmVkLiAgUmVjb3JkcyBvZiB0eXBlICdn cmFuZGZhdGhlcmVkJyBNQVkgaGF2ZSB0aGVpcg0KICAgdHlwZSBjb252ZXJ0ZWQgdG8gJ3JlZHVu ZGFudCc6IHNlZSAgU2VjdGlvbiAzLjcgZm9yIG1vcmUgaW5mb3JtYXRpb24uDQoNCiAgIFJGQyAz MDY2IHRhZ3MgdGhhdCB3ZXJlIGRlcHJlY2F0ZWQgcHJpb3IgdG8gdGhlIGFkb3B0aW9uIG9mIHRo aXMNCiAgIGRvY3VtZW50IGFyZSBwYXJ0IG9mIHRoZSBsaXN0IG9mIGdyYW5kZmF0aGVyZWQgdGFn cyBhbmQgdGhlaXINCiAgIGNvbXBvbmVudCBzdWJ0YWdzIHdlcmUgbm90IGluY2x1ZGVkIGFzIHJl Z2lzdGVyZWQgdmFyaWFudHMgKGFsdGhvdWdoDQogICB0aGV5IHJlbWFpbiBlbGlnaWJsZSBmb3Ig cmVnaXN0cmF0aW9uKS4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJhcnQtDQogICBsb2piYW4iIHdh cyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBsYW5ndWFnZSBzdWJ0YWcgJ2pibycuDQoNCiAg IFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBlbnN1cmUgdGhhdCBuZXcgc3VidGFn cyBtZWV0IHRoZQ0KICAgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gNC4xIG9yIHN1Ym1pdCBhbiBh cHByb3ByaWF0ZSBhbHRlcm5hdGUgc3VidGFnDQogICBhcyBkZXNjcmliZWQgaW4gdGhhdCBzZWN0 aW9uLiAgV2hlbiBlaXRoZXIgYSBjaGFuZ2Ugb3IgYWRkaXRpb24gdG8NCiAgIHRoZSByZWdpc3Ry eSBpcyBuZWVkZWQsIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBwcmVwYXJlIHRo ZQ0KICAgY29tcGxldGUgcmVjb3JkLCBpbmNsdWRpbmcgYWxsIGZpZWxkcywgYW5kIGZvcndhcmQg aXQgdG8gSUFOQSBmb3INCiAgIGluc2VydGlvbiBpbnRvIHRoZSByZWdpc3RyeS4NCg0KICAgSWYg cmVjb3JkIHJlcHJlc2VudHMgYSBuZXcgc3VidGFnIHRoYXQgZG9lcyBub3QgY3VycmVudGx5IGV4 aXN0IGluDQogICB0aGUgcmVnaXN0cnksIHRoZW4gdGhlIG1lc3NhZ2UncyBzdWJqZWN0IGxpbmUg TVVTVCBpbmNsdWRlIHRoZSB3b3JkDQogICAiSU5TRVJUIi4gIElmIHRoZSByZWNvcmQgcmVwcmVz ZW50cyBhIGNoYW5nZSB0byBhbiBleGlzdGluZyBzdWJ0YWcsDQogICB0aGVuIHRoZSBzdWJqZWN0 IGxpbmUgb2YgdGhlIG1lc3NhZ2UgTVVTVCBpbmNsdWRlIHRoZSB3b3JkICJNT0RJRlkiLg0KICAg VGhlIG1lc3NhZ2UgTVVTVCBjb250YWluIGJvdGggdGhlIHJlY29yZCBmb3IgdGhlIHN1YnRhZyBi ZWluZw0KICAgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgYW5kIHRoZSBuZXcgRmlsZS1EYXRlIHJlY29y ZC4gIEhlcmUgaXMgYW4NCiAgIGV4YW1wbGUgb2Ygd2hhdCB0aGUgYm9keSBvZiB0aGUgbWVzc2Fn ZSBtaWdodCBjb250YWluOg0KDQogICBMQU5HVUFHRSBTVUJUQUcgTU9ESUZJQ0FUSU9ODQogICBG aWxlLURhdGU6IDIwMDUtMDEtMDINCiAgICUlDQogICBUeXBlOiB2YXJpYW50DQogICBTdWJ0YWc6 IG5lZGlzDQogICBEZXNjcmlwdGlvbjogTmF0aXNvbmUgZGlhbGVjdA0KICAgRGVzY3JpcHRpb246 IE5hZGl6YSBkaWFsZWN0DQogICBBZGRlZDogMjAwMy0xMC0wOQ0KICAgUHJlZml4OiBzbA0KICAg Q29tbWVudHM6IFRoaXMgaXMgYSBjb21tZW50IHNob3duDQogICAgIGFzIGFuIGV4YW1wbGUuDQog ICAlJQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNA0KDQogICBX aGVuZXZlciBhbiBlbnRyeSBpcyBjcmVhdGVkIG9yIG1vZGlmaWVkIGluIHRoZSByZWdpc3RyeSwg dGhlICdGaWxlLQ0KICAgRGF0ZScgcmVjb3JkIGF0IHRoZSBzdGFydCBvZiB0aGUgcmVnaXN0cnkg aXMgdXBkYXRlZCB0byByZWZsZWN0IHRoZQ0KICAgbW9zdCByZWNlbnQgbW9kaWZpY2F0aW9uIGRh dGUgaW4gdGhlIFtSRkMzMzM5XSAiZnVsbC1kYXRlIiBmb3JtYXQuDQoNCiAgIFZhbHVlcyBpbiB0 aGUgJ1N1YnRhZycgZmllbGQgTVVTVCBiZSBsb3dlcmNhc2UgZXhjZXB0IGFzIHByb3ZpZGVkIGZv cg0KICAgaW4gU2VjdGlvbiAzLjEuDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICBBdWd1c3QgMjAwNQ0KDQoNCjMuMyAgU3RhYmlsaXR5IG9mIElBTkEgUmVnaXN0cnkgRW50cmll cw0KDQogICBUaGUgc3RhYmlsaXR5IG9mIGVudHJpZXMgYW5kIHRoZWlyIG1lYW5pbmcgaW4gdGhl IHJlZ2lzdHJ5IGlzDQogICBjcml0aWNhbCB0byB0aGUgbG9uZyB0ZXJtIHN0YWJpbGl0eSBvZiBs YW5ndWFnZSB0YWdzLiAgVGhlIHJ1bGVzIGluDQogICB0aGlzIHNlY3Rpb24gZ3VhcmFudGVlIHRo YXQgYSBzcGVjaWZpYyBsYW5ndWFnZSB0YWcncyBtZWFuaW5nIGlzDQogICBzdGFibGUgb3ZlciB0 aW1lIGFuZCB3aWxsIG5vdCBjaGFuZ2UuDQoNCiAgIFRoZXNlIHJ1bGVzIHNwZWNpZmljYWxseSBk ZWFsIHdpdGggaG93IGNoYW5nZXMgdG8gY29kZXMgKGluY2x1ZGluZw0KICAgd2l0aGRyYXdhbCBh bmQgZGVwcmVjYXRpb24gb2YgY29kZXMpIG1haW50YWluZWQgYnkgSVNPIDYzOSwgSVNPDQogICAx NTkyNCwgSVNPIDMxNjYsIGFuZCBVTiBNLjQ5IGFyZSByZWZsZWN0ZWQgaW4gdGhlIElBTkEgTGFu Z3VhZ2UNCiAgIFN1YnRhZyBSZWdpc3RyeS4gIEFzc2lnbm1lbnRzIHRvIHRoZSBJQU5BIExhbmd1 YWdlIFN1YnRhZyBSZWdpc3RyeQ0KICAgTVVTVCBmb2xsb3cgdGhlIGZvbGxvd2luZyBzdGFiaWxp dHkgcnVsZXM6DQoNCiAgIDEuICAgVmFsdWVzIGluIHRoZSBmaWVsZHMgJ1R5cGUnLCAnU3VidGFn JywgJ1RhZycsICdBZGRlZCcsDQogICAgICAgICdEZXByZWNhdGVkJyBhbmQgJ1ByZWZlcnJlZC1W YWx1ZScgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlDQogICAgICAgIGd1YXJhbnRlZWQgdG8g YmUgc3RhYmxlIG92ZXIgdGltZS4NCg0KICAgMi4gICBWYWx1ZXMgaW4gdGhlICdEZXNjcmlwdGlv bicgZmllbGQgTVVTVCBOT1QgYmUgY2hhbmdlZCBpbiBhIHdheQ0KICAgICAgICB0aGF0IHdvdWxk IGludmFsaWRhdGUgcHJldmlvdXNseS1leGlzdGluZyB0YWdzLiAgVGhleSBNQVkgYmUNCiAgICAg ICAgYnJvYWRlbmVkIHNvbWV3aGF0IGluIHNjb3BlLCBjaGFuZ2VkIHRvIGFkZCBpbmZvcm1hdGlv biwgb3INCiAgICAgICAgYWRhcHRlZCB0byB0aGUgbW9zdCBjb21tb24gbW9kZXJuIHVzYWdlLiAg Rm9yIGV4YW1wbGUsIGNvdW50cmllcw0KICAgICAgICBvY2Nhc2lvbmFsbHkgY2hhbmdlIHRoZWly IG9mZmljaWFsIG5hbWVzOiBhbiBoaXN0b3JpY2FsIGV4YW1wbGUNCiAgICAgICAgb2YgdGhpcyB3 b3VsZCBiZSAiVXBwZXIgVm9sdGEiIGNoYW5naW5nIHRvICJCdXJraW5hIEZhc28iLg0KDQogICAz LiAgIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcgTUFZIGJlIGFkZGVkIHRvIHJlY29yZHMg b2YgdHlwZQ0KICAgICAgICAndmFyaWFudCcgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4N Cg0KICAgNC4gICBWYWx1ZXMgaW4gdGhlIGZpZWxkICdQcmVmaXgnIE1BWSBiZSBtb2RpZmllZCwg c28gbG9uZyBhcyB0aGUNCiAgICAgICAgbW9kaWZpY2F0aW9ucyBicm9hZGVuIHRoZSBzZXQgb2Yg cHJlZml4ZXMuICBUaGF0IGlzLCBhIHByZWZpeA0KICAgICAgICBNQVkgYmUgcmVwbGFjZWQgYnkg b25lIG9mIGl0cyBvd24gcHJlZml4ZXMuICBGb3IgZXhhbXBsZSwgdGhlDQogICAgICAgIHByZWZp eCAiZW4tVVMiIGNvdWxkIGJlIHJlcGxhY2VkIGJ5ICJlbiIsIGJ1dCBub3QgYnkgdGhlDQogICAg ICAgIHByZWZpeGVzICJlbi1MYXRuIiwgImZyIiwgb3IgImVuLVVTLWJvb250Ii4gIElmIG9uZSBv ZiB0aG9zZQ0KICAgICAgICBwcmVmaXhlcyB3ZXJlIG5lZWRlZCwgYSBuZXcgUHJlZml4IFNIT1VM RCBiZSByZWdpc3RlcmVkLg0KDQogICA1LiAgIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcg TVVTVCBOT1QgYmUgcmVtb3ZlZC4NCg0KICAgNi4gICBUaGUgZmllbGQgJ0NvbW1lbnRzJyBNQVkg YmUgYWRkZWQsIGNoYW5nZWQsIG1vZGlmaWVkLCBvciByZW1vdmVkDQogICAgICAgIHZpYSB0aGUg cmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3IgYW55IG9mIHRoZSBwcm9jZXNzZXMgb3INCiAgICAgICAg Y29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbi4NCg0KICAgNy4gICBUaGUg ZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTUFZIGJlIGFkZGVkIG9yIHJlbW92ZWQgdmlhIHRoZQ0K ICAgICAgICByZWdpc3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgOC4gICBDb2RlcyBhc3NpZ25lZCBi eSBJU08gNjM5LCBJU08gMTU5MjQsIGFuZCBJU08gMzE2NiB0aGF0IGRvIG5vdA0KICAgICAgICBj b25mbGljdCB3aXRoIGV4aXN0aW5nIHN1YnRhZ3Mgb2YgdGhlIGFzc29jaWF0ZWQgdHlwZSBhbmQg d2hvc2UNCiAgICAgICAgbWVhbmluZyBpcyBub3QgdGhlIHNhbWUgYXMgYW4gZXhpc3Rpbmcgc3Vi dGFnIG9mIHRoZSBzYW1lIHR5cGUNCiAgICAgICAgYXJlIGVudGVyZWQgaW50byB0aGUgSUFOQSBy ZWdpc3RyeSBhcyBuZXcgcmVjb3Jkcy4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjVdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg QXVndXN0IDIwMDUNCg0KDQogICA5LiAgIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAx NTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBhcmUNCiAgICAgICAgd2l0aGRyYXduIGJ5IHRoZWlyIHJl c3BlY3RpdmUgbWFpbnRlbmFuY2Ugb3IgcmVnaXN0cmF0aW9uDQogICAgICAgIGF1dGhvcml0eSBy ZW1haW4gdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIEEgJ0RlcHJlY2F0ZWQnIGZpZWxkDQogICAg ICAgIGNvbnRhaW5pbmcgdGhlIGRhdGUgb2Ygd2l0aGRyYXdhbCBpcyBhZGRlZCB0byB0aGUgcmVj b3JkLiAgSWYgYQ0KICAgICAgICBuZXcgcmVjb3JkIG9mIHRoZSBzYW1lIHR5cGUgaXMgYWRkZWQg dGhhdCByZXByZXNlbnRzIGENCiAgICAgICAgcmVwbGFjZW1lbnQgdmFsdWUsIHRoZW4gYSAnUHJl ZmVycmVkLVZhbHVlJyBmaWVsZCBNQVkgYWxzbyBiZQ0KICAgICAgICBhZGRlZC4gIFRoZSByZWdp c3RyYXRpb24gcHJvY2VzcyBNQVkgYmUgdXNlZCB0byBhZGQgY29tbWVudHMNCiAgICAgICAgYWJv dXQgdGhlIHdpdGhkcmF3YWwgb2YgdGhlIGNvZGUgYnkgdGhlIHJlc3BlY3RpdmUgc3RhbmRhcmQu DQoNCiAgICAgICAgRXhhbXBsZSBUaGUgcmVnaW9uIGNvZGUgJ1RMJyB3YXMgYXNzaWduZWQgdG8g dGhlIGNvdW50cnkgJ1RpbW9yLQ0KICAgICAgICAgICBMZXN0ZScsIHJlcGxhY2luZyB0aGUgY29k ZSAnVFAnICh3aGljaCB3YXMgYXNzaWduZWQgdG8gJ0Vhc3QNCiAgICAgICAgICAgVGltb3InIHdo ZW4gaXQgd2FzIHVuZGVyIGFkbWluaXN0cmF0aW9uIGJ5IFBvcnR1Z2FsKS4gIFRoZQ0KICAgICAg ICAgICBzdWJ0YWcgJ1RQJyByZW1haW5zIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MsIGJ1dCBpdHMg cmVjb3JkDQogICAgICAgICAgIGNvbnRhaW5zIHRoZSBhICdQcmVmZXJyZWQtVmFsdWUnIG9mICdU TCcgYW5kIGl0cyBmaWVsZA0KICAgICAgICAgICAnRGVwcmVjYXRlZCcgY29udGFpbnMgdGhlIGRh dGUgdGhlIG5ldyBjb2RlIHdhcyBhc3NpZ25lZA0KICAgICAgICAgICAoJzIwMDQtMDctMDYnKS4N Cg0KICAgMTAuICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIG9yIElTTyAz MTY2IHRoYXQgY29uZmxpY3QNCiAgICAgICAgd2l0aCBleGlzdGluZyBzdWJ0YWdzIG9mIHRoZSBh c3NvY2lhdGVkIHR5cGUsIGluY2x1ZGluZyBzdWJ0YWdzDQogICAgICAgIHRoYXQgYXJlIGRlcHJl Y2F0ZWQsIE1VU1QgTk9UIGJlIGVudGVyZWQgaW50byB0aGUgcmVnaXN0cnkuICBUaGUNCiAgICAg ICAgZm9sbG93aW5nIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgYXBwbHkgdG8gc3VidGFnIHZh bHVlcyB0aGF0DQogICAgICAgIGFyZSByZWFzc2lnbmVkOg0KDQogICAgICAgIEEuICBGb3IgSVNP IDYzOSBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAg ICAgICAgICBub3QgcmVwcmVzZW50ZWQgYnkgYSBzdWJ0YWcgaW4gdGhlIElBTkEgcmVnaXN0cnks IHRoZQ0KICAgICAgICAgICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiAzLjQsIFNIQUxMDQogICAgICAgICAgICBwcmVwYXJlIGEgcHJvcG9zYWwgZm9y IGVudGVyaW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIHNvb24NCiAgICAgICAgICAgIGFzIHBy YWN0aWNhbCBhIHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFnIGFzIGFuIGFsdGVybmF0ZQ0KICAg ICAgICAgICAgdmFsdWUgZm9yIHRoZSBuZXcgY29kZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3Rl cmVkIGxhbmd1YWdlDQogICAgICAgICAgICBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlzY3JldGlv biBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnDQogICAgICAgICAgICBSZXZpZXdlciBhbmQgTVVTVCBj b25mb3JtIHRvIG90aGVyIHJlc3RyaWN0aW9ucyBvbiBsYW5ndWFnZQ0KICAgICAgICAgICAgc3Vi dGFncyBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICAgICAgIEIuICBGb3IgYWxsIHN1YnRhZ3Mgd2hv c2UgbWVhbmluZyBpcyBkZXJpdmVkIGZyb20gYW4gZXh0ZXJuYWwNCiAgICAgICAgICAgIHN0YW5k YXJkIChpLmUuICBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBvciBVTiBNLjQ5KSwNCiAg ICAgICAgICAgIGlmIGEgbmV3IG1lYW5pbmcgaXMgYXNzaWduZWQgdG8gYW4gZXhpc3RpbmcgY29k ZSBhbmQgdGhlIG5ldw0KICAgICAgICAgICAgbWVhbmluZyBicm9hZGVucyB0aGUgbWVhbmluZyBv ZiB0aGF0IGNvZGUsIHRoZW4gdGhlIG1lYW5pbmcNCiAgICAgICAgICAgIGZvciB0aGUgYXNzb2Np YXRlZCBzdWJ0YWcgTUFZIGJlIGNoYW5nZWQgdG8gbWF0Y2guICBUaGUNCiAgICAgICAgICAgIG1l YW5pbmcgb2YgYSBzdWJ0YWcgTVVTVCBOT1QgYmUgbmFycm93ZWQsIGhvd2V2ZXIsIGFzIHRoaXMN CiAgICAgICAgICAgIGNhbiByZXN1bHQgaW4gYW4gdW5rbm93biBwcm9wb3J0aW9uIG9mIHRoZSBl eGlzdGluZyB1c2VzIG9mDQogICAgICAgICAgICBhIHN1YnRhZyBiZWNvbWluZyBpbnZhbGlkLiAg Tm90ZTogSVNPIDYzOSBNQS9SQSBoYXMgYWRvcHRlZA0KICAgICAgICAgICAgYSBzaW1pbGFyIHN0 YWJpbGl0eSBwb2xpY3kuDQoNCiAgICAgICAgQy4gIEZvciBJU08gMTU5MjQgY29kZXMsIGlmIHRo ZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgICAgbm90IHJlcHJl c2VudGVkIGJ5IGEgc3VidGFnIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LCB0aGUNCiAgICAgICAgICAg IExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LCBT SEFMTA0KICAgICAgICAgICAgcHJlcGFyZSBhIHByb3Bvc2FsIGZvciBlbnRlcmluZyBpbiB0aGUg SUFOQSByZWdpc3RyeSBhcyBzb29uDQogICAgICAgICAgICBhcyBwcmFjdGljYWwgYSByZWdpc3Rl cmVkIHZhcmlhbnQgc3VidGFnIGFzIGFuIGFsdGVybmF0ZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjZd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAgICAgICB2YWx1ZSBmb3IgdGhlIG5ldyBj b2RlLiAgVGhlIGZvcm0gb2YgdGhlIHJlZ2lzdGVyZWQgdmFyaWFudA0KICAgICAgICAgICAgc3Vi dGFnIHdpbGwgYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIExhbmd1YWdlIFN1YnRhZw0KICAg ICAgICAgICAgUmV2aWV3ZXIgYW5kIE1VU1QgY29uZm9ybSB0byBvdGhlciByZXN0cmljdGlvbnMg b24gdmFyaWFudA0KICAgICAgICAgICAgc3VidGFncyBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICAg ICAgIEQuICBGb3IgSVNPIDMxNjYgY29kZXMsIGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3Mg bWVhbmluZyBpcw0KICAgICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIFVOIE0uNDkg Y29kZSBhcyBhbm90aGVyICdyZWdpb24nDQogICAgICAgICAgICBzdWJ0YWcsIHRoZW4gdGhlIGV4 aXN0aW5nIHJlZ2lvbiBzdWJ0YWcgcmVtYWlucyBhcyB0aGUNCiAgICAgICAgICAgIHByZWZlcnJl ZCB2YWx1ZSBmb3IgdGhhdCByZWdpb24gYW5kIG5vIG5ldyBlbnRyeSBpcyBjcmVhdGVkLg0KICAg ICAgICAgICAgQSBjb21tZW50IE1BWSBiZSBhZGRlZCB0byB0aGUgZXhpc3RpbmcgcmVnaW9uIHN1 YnRhZw0KICAgICAgICAgICAgaW5kaWNhdGluZyB0aGUgcmVsYXRpb25zaGlwIHRvIHRoZSBuZXcg SVNPIDMxNjYgY29kZS4NCg0KICAgICAgICBFLiAgRm9yIElTTyAzMTY2IGNvZGVzLCBpZiB0aGUg bmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgICAgIGFzc29jaWF0ZWQg d2l0aCBhIFVOIE0uNDkgY29kZSB0aGF0IGlzIG5vdCByZXByZXNlbnRlZCBieSBhbg0KICAgICAg ICAgICAgZXhpc3RpbmcgcmVnaW9uIHN1YnRhZywgdGhlbiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJl dmlld2VyLA0KICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LCBTSEFMTCBw cmVwYXJlIGEgcHJvcG9zYWwgZm9yDQogICAgICAgICAgICBlbnRlcmluZyB0aGUgYXBwcm9wcmlh dGUgVU4gTS40OSBjb3VudHJ5IGNvZGUgYXMgYW4gZW50cnkgaW4NCiAgICAgICAgICAgIHRoZSBJ QU5BIHJlZ2lzdHJ5Lg0KDQogICAgICAgIEYuICBGb3IgSVNPIDMxNjYgY29kZXMsIGlmIHRoZXJl IGlzIG5vIGFzc29jaWF0ZWQgVU4gbnVtZXJpYw0KICAgICAgICAgICAgY29kZSwgdGhlbiB0aGUg TGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIFNIQUxMIHBldGl0aW9uIHRoZQ0KICAgICAgICAgICAg VU4gdG8gY3JlYXRlIG9uZS4gIElmIHRoZXJlIGlzIG5vIHJlc3BvbnNlIGZyb20gdGhlIFVODQog ICAgICAgICAgICB3aXRoaW4gbmluZXR5IGRheXMgb2YgdGhlIHJlcXVlc3QgYmVpbmcgc2VudCwg dGhlIExhbmd1YWdlDQogICAgICAgICAgICBTdWJ0YWcgUmV2aWV3ZXIgU0hBTEwgcHJlcGFyZSBh IHByb3Bvc2FsIGZvciBlbnRlcmluZyBpbiB0aGUNCiAgICAgICAgICAgIElBTkEgcmVnaXN0cnkg YXMgc29vbiBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIHZhcmlhbnQNCiAgICAgICAgICAgIHN1 YnRhZyBhcyBhbiBhbHRlcm5hdGUgdmFsdWUgZm9yIHRoZSBuZXcgY29kZS4gIFRoZSBmb3JtIG9m DQogICAgICAgICAgICB0aGUgcmVnaXN0ZXJlZCB2YXJpYW50IHN1YnRhZyB3aWxsIGJlIGF0IHRo ZSBkaXNjcmV0aW9uIG9mDQogICAgICAgICAgICB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2Vy IGFuZCBNVVNUIGNvbmZvcm0gdG8gb3RoZXINCiAgICAgICAgICAgIHJlc3RyaWN0aW9ucyBvbiB2 YXJpYW50IHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVudC4gIFRoaXMNCiAgICAgICAgICAgIHNpdHVh dGlvbiBpcyB2ZXJ5IHVubGlrZWx5IHRvIGV2ZXIgb2NjdXIuDQoNCiAgIDExLiAgVU4gTS40OSBo YXMgY29kZXMgZm9yIGJvdGggY291bnRyaWVzIGFuZCBhcmVhcyAoc3VjaCBhcyAnMjc2Jw0KICAg ICAgICBmb3IgR2VybWFueSkgYW5kIGdlb2dyYXBoaWNhbCByZWdpb25zIGFuZCBzdWItcmVnaW9u cyAoc3VjaCBhcw0KICAgICAgICAnMTUwJyBmb3IgRXVyb3BlKS4gIFVOIE0uNDkgY291bnRyeSBv ciBhcmVhIGNvZGVzIGZvciB3aGljaA0KICAgICAgICB0aGVyZSBpcyBubyBjb3JyZXNwb25kaW5n IElTTyAzMTY2IGNvZGUgU0hPVUxEIE5PVCBiZQ0KICAgICAgICByZWdpc3RlcmVkLCBleGNlcHQg YXMgYSBzdXJyb2dhdGUgZm9yIGFuIElTTyAzMTY2IGNvZGUgdGhhdCBpcw0KICAgICAgICBibG9j a2VkIGZyb20gcmVnaXN0cmF0aW9uIGJ5IGFuIGV4aXN0aW5nIHN1YnRhZy4gIElmIHN1Y2ggYSBj b2RlDQogICAgICAgIGJlY29tZXMgbmVjZXNzYXJ5LCB0aGVuIHRoZSByZWdpc3RyYXRpb24gYXV0 aG9yaXR5IGZvciBJU08gMzE2Ng0KICAgICAgICBTSE9VTEQgZmlyc3QgYmUgcGV0aXRpb25lZCB0 byBhc3NpZ24gYSBjb2RlIHRvIHRoZSByZWdpb24uICBJZg0KICAgICAgICB0aGUgcGV0aXRpb24g Zm9yIGEgY29kZSBhc3NpZ25tZW50IGJ5IElTTyAzMTY2IGlzIHJlZnVzZWQgb3Igbm90DQogICAg ICAgIGFjdGVkIG9uIGluIGEgdGltZWx5IG1hbm5lciwgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNz IGRlc2NyaWJlZA0KICAgICAgICBpbiBTZWN0aW9uIDMuNCBNQVkgdGhlbiBiZSB1c2VkIHRvIHJl Z2lzdGVyIHRoZSBjb3JyZXNwb25kaW5nIFVODQogICAgICAgIE0uNDkgY29kZS4gIEF0IHRoZSB0 aW1lIHRoaXMgZG9jdW1lbnQgd2FzIHdyaXR0ZW4sIHRoZXJlIHdlcmUNCiAgICAgICAgb25seSBm b3VyIHN1Y2ggY29kZXM6IDgzMCAoQ2hhbm5lbCBJc2xhbmRzKSwgODMxIChHdWVybnNleSksIDgz Mg0KICAgICAgICAoSmVyc2V5KSwgYW5kIDgzMyAoSXNsZSBvZiBNYW4pLiAgVGhpcyB3YXkgVU4g TS40OSBjb2RlcyByZW1haW4NCiAgICAgICAgYXZhaWxhYmxlIGFzIHRoZSB2YWx1ZSBvZiBsYXN0 IHJlc29ydCBpbiBjYXNlcyB3aGVyZSBJU08gMzE2Ng0KICAgICAgICByZWFzc2lnbnMgYSBkZXBy ZWNhdGVkIHZhbHVlIGluIHRoZSByZWdpc3RyeS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjddDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAxMi4gIFN0YWJpbGl0eSBwcm92aXNpb25zIGFwcGx5 IHRvIGdyYW5kZmF0aGVyZWQgdGFncyB3aXRoIHRoaXMNCiAgICAgICAgZXhjZXB0aW9uOiBzaG91 bGQgYWxsIG9mIHRoZSBzdWJ0YWdzIGluIGEgZ3JhbmRmYXRoZXJlZCB0YWcNCiAgICAgICAgYmVj b21lIHZhbGlkIHN1YnRhZ3MgaW4gdGhlIElBTkEgcmVnaXN0cnksIHRoZW4gdGhlIGZpZWxkICdU eXBlJw0KICAgICAgICBpbiB0aGF0IHJlY29yZCBpcyBjaGFuZ2VkIGZyb20gJ2dyYW5kZmF0aGVy ZWQnIHRvICdyZWR1bmRhbnQnLg0KICAgICAgICBOb3RlIHRoYXQgdGhpcyB3aWxsIG5vdCBhZmZl Y3QgbGFuZ3VhZ2UgdGFncyB0aGF0IG1hdGNoIHRoZQ0KICAgICAgICBncmFuZGZhdGhlcmVkIHRh Zywgc2luY2UgdGhlc2UgdGFncyB3aWxsIG5vdyBtYXRjaCB2YWxpZA0KICAgICAgICBnZW5lcmF0 aXZlIHN1YnRhZyBzZXF1ZW5jZXMuICBGb3IgZXhhbXBsZSwgaWYgdGhlIHN1YnRhZyAnZ2FuJw0K ICAgICAgICBpbiB0aGUgbGFuZ3VhZ2UgdGFnICJ6aC1nYW4iIHdlcmUgdG8gYmUgcmVnaXN0ZXJl ZCBhcyBhbg0KICAgICAgICBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcsIHRoZW4gdGhlIGdyYW5k ZmF0aGVyZWQgdGFnICJ6aC1nYW4iDQogICAgICAgIHdvdWxkIGJlIGRlcHJlY2F0ZWQgKGJ1dCBl eGlzdGluZyBjb250ZW50IG9yIGltcGxlbWVudGF0aW9ucw0KICAgICAgICB0aGF0IHVzZSAiemgt Z2FuIiB3b3VsZCByZW1haW4gdmFsaWQpLg0KDQoNCjMuNCAgUmVnaXN0cmF0aW9uIFByb2NlZHVy ZSBmb3IgU3VidGFncw0KDQogICBUaGUgcHJvY2VkdXJlIGdpdmVuIGhlcmUgTVVTVCBiZSB1c2Vk IGJ5IGFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGENCiAgIHN1YnRhZyBub3QgY3VycmVudGx5IGlu IHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4NCg0KICAgT25seSBzdWJ0YWdzICBv ZiB0eXBlICdsYW5ndWFnZScgYW5kICd2YXJpYW50JyB3aWxsIGJlIGNvbnNpZGVyZWQgZm9yDQog ICBpbmRlcGVuZGVudCByZWdpc3RyYXRpb24gb2YgbmV3IHN1YnRhZ3MuICBIYW5kbGluZyBvZiBz dWJ0YWdzIG5lZWRlZA0KICAgZm9yIHN0YWJpbGl0eSBhbmQgc3VidGFncyBuZWNlc3NhcnkgdG8g a2VlcCB0aGUgcmVnaXN0cnkgc3luY2hyb25pemVkDQogICB3aXRoIElTTyA2MzksIElTTyAxNTky NCwgSVNPIDMxNjYsIGFuZCBVTiBNLjQ5IHdpdGhpbiB0aGUgbGltaXRzDQogICBkZWZpbmVkIGJ5 IHRoaXMgZG9jdW1lbnQgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMi4gIFN0YWJpbGl0eQ0K ICAgcHJvdmlzaW9ucyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLg0KDQogICBUaGlzIHBy b2NlZHVyZSBNQVkgYWxzbyBiZSB1c2VkIHRvIHJlZ2lzdGVyIG9yIGFsdGVyIHRoZSBpbmZvcm1h dGlvbg0KICAgZm9yIHRoZSAiRGVzY3JpcHRpb24iLCAiQ29tbWVudHMiLCAiRGVwcmVjYXRlZCIs IG9yICJQcmVmaXgiIGZpZWxkcw0KICAgaW4gYSBzdWJ0YWcncyByZWNvcmQgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gMy4zLiAgQ2hhbmdlcyB0byBhbGwNCiAgIG90aGVyIGZpZWxkcyBpbiB0aGUg SUFOQSByZWdpc3RyeSBhcmUgTk9UIHBlcm1pdHRlZC4NCg0KICAgUmVnaXN0ZXJpbmcgYSBuZXcg c3VidGFnIG9yIHJlcXVlc3RpbmcgbW9kaWZpY2F0aW9ucyB0byBhbiBleGlzdGluZw0KICAgdGFn IG9yIHN1YnRhZyBzdGFydHMgd2l0aCB0aGUgcmVxdWVzdGVyIGZpbGxpbmcgb3V0IHRoZSByZWdp c3RyYXRpb24NCiAgIGZvcm0gcmVwcm9kdWNlZCBiZWxvdy4gIE5vdGUgdGhhdCBlYWNoIHJlc3Bv bnNlIGlzIG5vdCBsaW1pdGVkIGluDQogICBzaXplIHNvIHRoYXQgdGhlIHJlcXVlc3QgY2FuIGFk ZXF1YXRlbHkgZGVzY3JpYmUgdGhlIHJlZ2lzdHJhdGlvbi4NCiAgIFRoZSBmaWVsZHMgaW4gdGhl ICJSZWNvcmQgUmVxdWVzdGVkIiBzZWN0aW9uIFNIT1VMRCBmb2xsb3cgdGhlDQogICByZXF1aXJl bWVudHMgaW4gU2VjdGlvbiAzLjEuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAg ICBbUGFnZSAyOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIExBTkdVQUdFIFNVQlRBRyBS RUdJU1RSQVRJT04gRk9STQ0KICAgMS4gTmFtZSBvZiByZXF1ZXN0ZXI6DQogICAyLiBFLW1haWwg YWRkcmVzcyBvZiByZXF1ZXN0ZXI6DQogICAzLiBSZWNvcmQgUmVxdWVzdGVkOg0KDQogICAgICBU eXBlOg0KICAgICAgU3VidGFnOg0KICAgICAgRGVzY3JpcHRpb246DQogICAgICBQcmVmaXg6DQog ICAgICBQcmVmZXJyZWQtVmFsdWU6DQogICAgICBEZXByZWNhdGVkOg0KICAgICAgU3VwcHJlc3Mt U2NyaXB0Og0KICAgICAgQ29tbWVudHM6DQoNCiAgIDQuIEludGVuZGVkIG1lYW5pbmcgb2YgdGhl IHN1YnRhZzoNCiAgIDUuIFJlZmVyZW5jZSB0byBwdWJsaXNoZWQgZGVzY3JpcHRpb24NCiAgICAg IG9mIHRoZSBsYW5ndWFnZSAoYm9vayBvciBhcnRpY2xlKToNCiAgIDYuIEFueSBvdGhlciByZWxl dmFudCBpbmZvcm1hdGlvbjoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDUNCg0KICAgVGhlIHN1YnRhZyByZWdpc3RyYXRpb24gZm9ybSBNVVNUIGJlIHNlbnQgdG8N CiAgIDxpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZz4gZm9yIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlv ZCBiZWZvcmUgaXQgY2FuDQogICBiZSBzdWJtaXR0ZWQgdG8gSUFOQS4gIChUaGlzIGlzIGFuIG9w ZW4gbGlzdCBhbmQgY2FuIGJlIGpvaW5lZCBieQ0KICAgc2VuZGluZyBhIHJlcXVlc3QgdG8gPGll dGYtbGFuZ3VhZ2VzLXJlcXVlc3RAaWFuYS5vcmc+LikNCg0KICAgVmFyaWFudCBhbmQgZXh0bGFu ZyBzdWJ0YWdzIGFyZSBhbHdheXMgcmVnaXN0ZXJlZCBmb3IgdXNlIHdpdGggYQ0KICAgcGFydGlj dWxhciByYW5nZSBvZiBsYW5ndWFnZSB0YWdzLiAgRm9yIGV4YW1wbGUsIHRoZSBzdWJ0YWcgJ3Jv emFqJw0KICAgaXMgaW50ZW5kZWQgZm9yIHVzZSB3aXRoIGxhbmd1YWdlIHRhZ3MgdGhhdCBzdGFy dCB3aXRoIHRoZSBwcmltYXJ5DQogICBsYW5ndWFnZSBzdWJ0YWcgInNsIiwgc2luY2UgUmVzaWFu IGlzIGEgZGlhbGVjdCBvZiBTbG92ZW5pYW4uICBUaHVzDQogICB0aGUgc3VidGFnICdyb3phaicg Y291bGQgYmUgaW5jbHVkZWQgaW4gdGFncyBzdWNoIGFzICJzbC1MYXRuLXJvemFqIg0KICAgb3Ig InNsLUlULXJvemFqIi4gIFRoaXMgaW5mb3JtYXRpb24gaXMgc3RvcmVkIGluIHRoZSAiUHJlZml4 IiBmaWVsZA0KICAgaW4gdGhlIHJlZ2lzdHJ5LiAgVmFyaWFudCByZWdpc3RyYXRpb24gcmVxdWVz dHMgYXJlIFJFUVVJUkVEIHRvDQogICBpbmNsdWRlIGF0IGxlYXN0IG9uZSAiUHJlZml4IiBmaWVs ZCBpbiB0aGUgcmVnaXN0cmF0aW9uIGZvcm0uDQoNCiAgIFRoZSAnUHJlZml4JyBmaWVsZCBmb3Ig YSBnaXZlbiByZWdpc3RlcmVkIHN1YnRhZyBleGlzdHMgaW4gdGhlIElBTkENCiAgIHJlZ2lzdHJ5 IGFzIGEgZ3VpZGUgdG8gdXNhZ2UuICBBZGRpdGlvbmFsIHByZWZpeGVzIE1BWSBiZSBhZGRlZCBi eQ0KICAgZmlsaW5nIGFuIGFkZGl0aW9uYWwgcmVnaXN0cmF0aW9uIGZvcm0uICBJbiB0aGF0IGZv cm0sIHRoZSAiQW55IG90aGVyDQogICByZWxldmFudCBpbmZvcm1hdGlvbjoiIGZpZWxkIE1VU1Qg aW5kaWNhdGUgdGhhdCBpdCBpcyB0aGUgYWRkaXRpb24gb2YNCiAgIGEgcHJlZml4Lg0KDQogICBS ZXF1ZXN0cyB0byBhZGQgYSBwcmVmaXggdG8gYSB2YXJpYW50IHN1YnRhZyB0aGF0IGltcGx5IGEg ZGlmZmVyZW50DQogICBzZW1hbnRpYyBtZWFuaW5nIHdpbGwgcHJvYmFibHkgYmUgcmVqZWN0ZWQu ICBGb3IgZXhhbXBsZSwgYSByZXF1ZXN0DQogICB0byBhZGQgdGhlIHByZWZpeCAiZGUiIHRvIHRo ZSBzdWJ0YWcgJ25lZGlzJyBzbyB0aGF0IHRoZSB0YWcgImRlLQ0KICAgbmVkaXMiIHJlcHJlc2Vu dGVkIHNvbWUgR2VybWFuIGRpYWxlY3Qgd291bGQgYmUgcmVqZWN0ZWQuICBUaGUNCiAgICduZWRp cycgc3VidGFnIHJlcHJlc2VudHMgYSBwYXJ0aWN1bGFyIFNsb3ZlbmlhbiBkaWFsZWN0IGFuZCB0 aGUNCiAgIGFkZGl0aW9uYWwgcmVnaXN0cmF0aW9uIHdvdWxkIGNoYW5nZSB0aGUgc2VtYW50aWMg bWVhbmluZyBhc3NpZ25lZCB0bw0KICAgdGhlIHN1YnRhZy4gIEEgc2VwYXJhdGUgc3VidGFnIFNI T1VMRCBiZSBwcm9wb3NlZCBpbnN0ZWFkLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjldDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg QXVndXN0IDIwMDUNCg0KDQogICBUaGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBNVVNUIGNvbnRhaW4g YSBkZXNjcmlwdGlvbiBvZiB0aGUgdGFnIGJlaW5nDQogICByZWdpc3RlcmVkIHdyaXR0ZW4gb3Ig dHJhbnNjcmliZWQgaW50byB0aGUgTGF0aW4gc2NyaXB0OyBpdCBNQVkgYWxzbw0KICAgaW5jbHVk ZSBhIGRlc2NyaXB0aW9uIGluIGEgbm9uLUxhdGluIHNjcmlwdC4gIE5vbi1BU0NJSSBjaGFyYWN0 ZXJzDQogICBNVVNUIGJlIGVzY2FwZWQgdXNpbmcgdGhlIHN5bnRheCBkZXNjcmliZWQgaW4gU2Vj dGlvbiAzLjEuICBUaGUNCiAgICdEZXNjcmlwdGlvbicgZmllbGQgaXMgdXNlZCBmb3IgaWRlbnRp ZmljYXRpb24gcHVycG9zZXMgYW5kIGRvZXNuJ3QNCiAgIG5lY2Vzc2FyaWx5ICByZXByZXNlbnQg dGhlIGFjdHVhbCBuYXRpdmUgbmFtZSBvZiB0aGUgbGFuZ3VhZ2Ugb3INCiAgIHZhcmlhdGlvbiBv ciB0byBiZSBpbiBhbnkgcGFydGljdWxhciBsYW5ndWFnZS4NCg0KICAgV2hpbGUgdGhlICdEZXNj cmlwdGlvbicgZmllbGQgaXRzZWxmIGlzIG5vdCBndWFyYW50ZWVkIHRvIGJlIHN0YWJsZQ0KICAg YW5kIGVycmF0YSBjb3JyZWN0aW9ucyBNQVkgYmUgdW5kZXJ0YWtlbiBmcm9tIHRpbWUgdG8gdGlt ZSwgYXR0ZW1wdHMNCiAgIHRvIHByb3ZpZGUgdHJhbnNsYXRpb25zIG9yIHRyYW5zY3JpcHRpb25z IG9mIGVudHJpZXMgaW4gdGhlIHJlZ2lzdHJ5DQogICBpdHNlbGYgd2lsbCBwcm9iYWJseSBiZSBm cm93bmVkIHVwb24gYnkgdGhlIGNvbW11bml0eSBvciByZWplY3RlZA0KICAgb3V0cmlnaHQsIGFz IGNoYW5nZXMgb2YgdGhpcyBuYXR1cmUgaGF2ZSBhbiBpbXBhY3Qgb24gdGhlIHByb3Zpc2lvbnMN CiAgIGluIFNlY3Rpb24gMy4zLg0KDQogICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGlz IHJlc3BvbnNpYmxlIGZvciByZXNwb25kaW5nIHRvDQogICByZXF1ZXN0cyBmb3IgdGhlIHJlZ2lz dHJhdGlvbiBvZiBzdWJ0YWdzIHRocm91Z2ggdGhlIHJlZ2lzdHJhdGlvbg0KICAgcHJvY2VzcyAg YW5kIGlzIGFwcG9pbnRlZCBieSB0aGUgSUVTRy4NCg0KICAgV2hlbiB0aGUgdHdvIHdlZWsgcGVy aW9kIGhhcyBwYXNzZWQgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlcg0KICAgZWl0aGVyIGZv cndhcmRzIHRoZSByZWNvcmQgdG8gYmUgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgdG8NCiAgIGlhbmFA aWFuYS5vcmcgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmUgZGVzY3JpYmVkIGluIFNlY3Rpb24g My4yLCBvcg0KICAgcmVqZWN0cyB0aGUgcmVxdWVzdCBiZWNhdXNlIG9mIHNpZ25pZmljYW50IG9i amVjdGlvbnMgcmFpc2VkIG9uIHRoZQ0KICAgbGlzdCBvciBkdWUgdG8gcHJvYmxlbXMgd2l0aCBj b25zdHJhaW50cyBpbiB0aGlzIGRvY3VtZW50ICh3aGljaCBNVVNUDQogICBiZSBleHBsaWNpdGx5 IGNpdGVkKS4gIFRoZSByZXZpZXdlciBNQVkgYWxzbyBleHRlbmQgdGhlIHJldmlldyBwZXJpb2QN CiAgIGluIHR3byB3ZWVrIGluY3JlbWVudHMgdG8gcGVybWl0IGZ1cnRoZXIgZGlzY3Vzc2lvbi4g IFRoZSByZXZpZXdlcg0KICAgTVVTVCBpbmRpY2F0ZSBvbiB0aGUgbGlzdCB3aGV0aGVyIHRoZSBy ZWdpc3RyYXRpb24gaGFzIGJlZW4gYWNjZXB0ZWQsDQogICByZWplY3RlZCwgb3IgZXh0ZW5kZWQg Zm9sbG93aW5nIGVhY2ggdHdvIHdlZWsgcGVyaW9kLg0KDQogICBOb3RlIHRoYXQgdGhlIHJldmll d2VyIE1BWSByYWlzZSBvYmplY3Rpb25zIG9uIHRoZSBsaXN0IGlmIGhlIG9yIHNoZQ0KICAgc28g ZGVzaXJlcy4gIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB0aGUgb2JqZWN0aW9uIE1VU1Qg YmUgbWFkZQ0KICAgcHVibGljbHkuDQoNCiAgIFRoZSBhcHBsaWNhbnQgaXMgZnJlZSB0byBtb2Rp ZnkgYSByZWplY3RlZCBhcHBsaWNhdGlvbiB3aXRoDQogICBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IGFuZCBzdWJtaXQgaXQgYWdhaW47IHRoaXMgcmVzdGFydHMgdGhlIHR3bw0KICAgd2VlayBjb21t ZW50IHBlcmlvZC4NCg0KICAgRGVjaXNpb25zIG1hZGUgYnkgdGhlIHJldmlld2VyIE1BWSBiZSBh cHBlYWxlZCB0byB0aGUgSUVTRyBbUkZDMjAyOF0NCiAgIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFz IG90aGVyIElFVEYgZGVjaXNpb25zIFtSRkMyMDI2XS4NCg0KICAgQWxsIGFwcHJvdmVkIHJlZ2lz dHJhdGlvbiBmb3JtcyBhcmUgYXZhaWxhYmxlIG9ubGluZSBpbiB0aGUgZGlyZWN0b3J5DQogICBo dHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbCB1bmRlciAibGFuZ3VhZ2VzIi4NCg0KICAg VXBkYXRlcyBvciBjaGFuZ2VzIHRvIGV4aXN0aW5nIHJlY29yZHMgZm9sbG93IHRoZSBzYW1lIHBy b2NlZHVyZSBhcw0KICAgbmV3IHJlZ2lzdHJhdGlvbnMuICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJl dmlld2VyIGRlY2lkZXMgd2hldGhlcg0KICAgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHVwZGF0ZSB0 aGUgcmVnaXN0cmF0aW9uIGZvbGxvd2luZyB0aGUgdHdvIHdlZWsNCiAgIHJldmlldyBwZXJpb2Q7 IG5vcm1hbGx5IG9iamVjdGlvbnMgYnkgdGhlIG9yaWdpbmFsIHJlZ2lzdHJhbnQgd2lsbA0KICAg Y2FycnkgZXh0cmEgd2VpZ2h0IGluIGZvcm1pbmcgc3VjaCBhIGNvbnNlbnN1cy4NCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAg ICAgIFtQYWdlIDMwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgUmVnaXN0cmF0aW9ucyBh cmUgcGVybWFuZW50IGFuZCBzdGFibGUuICBPbmNlIHJlZ2lzdGVyZWQsIHN1YnRhZ3MNCiAgIHdp bGwgbm90IGJlIHJlbW92ZWQgZnJvbSB0aGUgcmVnaXN0cnkgYW5kIHdpbGwgcmVtYWluIGEgdmFs aWQgd2F5IGluDQogICB3aGljaCB0byBzcGVjaWZ5IGEgc3BlY2lmaWMgbGFuZ3VhZ2Ugb3IgdmFy aWFudC4NCg0KICAgTm90ZTogVGhlIHB1cnBvc2Ugb2YgdGhlICJEZXNjcmlwdGlvbiIgaW4gdGhl IHJlZ2lzdHJhdGlvbiBmb3JtIGlzDQogICBpbnRlbmRlZCBhcyBhbiBhaWQgdG8gcGVvcGxlIHRy eWluZyB0byB2ZXJpZnkgd2hldGhlciBhIGxhbmd1YWdlIGlzDQogICByZWdpc3RlcmVkIG9yIHdo YXQgbGFuZ3VhZ2Ugb3IgbGFuZ3VhZ2UgdmFyaWF0aW9uIGEgcGFydGljdWxhciBzdWJ0YWcNCiAg IHJlZmVycyB0by4gIEluIG1vc3QgY2FzZXMsIHJlZmVyZW5jZSB0byBhbiBhdXRob3JpdGF0aXZl IGdyYW1tYXIgb3INCiAgIGRpY3Rpb25hcnkgb2YgdGhhdCBsYW5ndWFnZSB3aWxsIGJlIHVzZWZ1 bDsgaW4gY2FzZXMgd2hlcmUgbm8gc3VjaA0KICAgd29yayBleGlzdHMsIG90aGVyIHdlbGwga25v d24gd29ya3MgZGVzY3JpYmluZyB0aGF0IGxhbmd1YWdlIG9yIGluDQogICB0aGF0IGxhbmd1YWdl IE1BWSBiZSBhcHByb3ByaWF0ZS4gIFRoZSBzdWJ0YWcgcmV2aWV3ZXIgZGVjaWRlcyB3aGF0DQog ICBjb25zdGl0dXRlcyAiZ29vZCBlbm91Z2giIHJlZmVyZW5jZSBtYXRlcmlhbC4gIFRoaXMgcmVx dWlyZW1lbnQgaXMNCiAgIG5vdCBpbnRlbmRlZCB0byBleGNsdWRlIHBhcnRpY3VsYXIgbGFuZ3Vh Z2VzIG9yIGRpYWxlY3RzIGR1ZSB0byB0aGUNCiAgIHNpemUgb2YgdGhlIHNwZWFrZXIgcG9wdWxh dGlvbiBvciBsYWNrIG9mIGEgc3RhbmRhcmRpemVkIG9ydGhvZ3JhcGh5Lg0KICAgTWlub3JpdHkg bGFuZ3VhZ2VzIHdpbGwgYmUgY29uc2lkZXJlZCBlcXVhbGx5IG9uIHRoZWlyIG93biBtZXJpdHMu DQoNCjMuNSAgUG9zc2liaWxpdGllcyBmb3IgUmVnaXN0cmF0aW9uDQoNCiAgIFBvc3NpYmlsaXRp ZXMgZm9yIHJlZ2lzdHJhdGlvbiBvZiBzdWJ0YWdzIG9yIGluZm9ybWF0aW9uIGFib3V0DQogICBz dWJ0YWdzIGluY2x1ZGU6DQoNCiAgIG8gIFByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBmb3IgbGFu Z3VhZ2VzIG5vdCBsaXN0ZWQgaW4gSVNPIDYzOSB0aGF0DQogICAgICBhcmUgbm90IHZhcmlhbnRz IG9mIGFueSBsaXN0ZWQgb3IgcmVnaXN0ZXJlZCBsYW5ndWFnZSBNQVkgYmUNCiAgICAgIHJlZ2lz dGVyZWQuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkIHRoZXJlIHdlcmUg bm8NCiAgICAgIGV4YW1wbGVzIG9mIHRoaXMgZm9ybSBvZiBzdWJ0YWcuICBCZWZvcmUgYXR0ZW1w dGluZyB0byByZWdpc3RlciBhDQogICAgICBsYW5ndWFnZSBzdWJ0YWcsIHRoZXJlIE1VU1QgYmUg YW4gYXR0ZW1wdCB0byByZWdpc3RlciB0aGUgbGFuZ3VhZ2UNCiAgICAgIHdpdGggSVNPIDYzOS4g IFN1YnRhZ3MgTVVTVCBOT1QgYmUgcmVnaXN0ZXJlZCBmb3IgY29kZXMgdGhhdCBleGlzdA0KICAg ICAgaW4gSVNPIDYzOS0xIG9yIElTTyA2MzktMiwgd2hpY2ggYXJlIHVuZGVyIGNvbnNpZGVyYXRp b24gYnkgdGhlDQogICAgICBJU08gNjM5IG1haW50ZW5hbmNlIG9yIHJlZ2lzdHJhdGlvbiBhdXRo b3JpdGllcywgb3Igd2hpY2ggaGF2ZQ0KICAgICAgbmV2ZXIgYmVlbiBhdHRlbXB0ZWQgZm9yIHJl Z2lzdHJhdGlvbiB3aXRoIHRob3NlIGF1dGhvcml0aWVzLiAgSWYNCiAgICAgIElTTyA2MzkgaGFz IHByZXZpb3VzbHkgcmVqZWN0ZWQgYSBsYW5ndWFnZSBmb3IgcmVnaXN0cmF0aW9uLCBpdCBpcw0K ICAgICAgcmVhc29uYWJsZSB0byBhc3N1bWUgdGhhdCB0aGVyZSBtdXN0IGJlIGFkZGl0aW9uYWwg dmVyeSBjb21wZWxsaW5nDQogICAgICBldmlkZW5jZSBvZiBuZWVkIGJlZm9yZSBpdCB3aWxsIGJl IHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkNCiAgICAgICh0byB0aGUgZXh0ZW50IHRo YXQgaXQgaXMgdmVyeSB1bmxpa2VseSB0aGF0IGFueSBzdWJ0YWdzIHdpbGwgYmUNCiAgICAgIHJl Z2lzdGVyZWQgb2YgdGhpcyB0eXBlKS4NCg0KICAgbyAgRGlhbGVjdCBvciBvdGhlciBkaXZpc2lv bnMgb3IgdmFyaWF0aW9ucyB3aXRoaW4gYSBsYW5ndWFnZSwgaXRzDQogICAgICBvcnRob2dyYXBo eSwgd3JpdGluZyBzeXN0ZW0sIHJlZ2lvbmFsIG9yIGhpc3RvcmljYWwgdXNhZ2UsDQogICAgICB0 cmFuc2xpdGVyYXRpb24gb3Igb3RoZXIgdHJhbnNmb3JtYXRpb24sIG9yIGRpc3Rpbmd1aXNoaW5n DQogICAgICB2YXJpYXRpb24gTUFZIGJlIHJlZ2lzdGVyZWQgYXMgdmFyaWFudCBzdWJ0YWdzLiAg QW4gZXhhbXBsZSBpcyB0aGUNCiAgICAgICdyb3phaicgc3VidGFnICh0aGUgUmVzaWFuIGRpYWxl Y3Qgb2YgU2xvdmVuaWFuKS4NCg0KICAgbyAgVGhlIGFkZGl0aW9uIG9yIG1haW50ZW5hbmNlIG9m IGZpZWxkcyAoZ2VuZXJhbGx5IG9mIGFuDQogICAgICBpbmZvcm1hdGlvbmFsIG5hdHVyZSkgaW4g VGFnIG9yIFN1YnRhZyByZWNvcmRzIGFzIGRlc2NyaWJlZCBpbg0KICAgICAgU2VjdGlvbiAzLjEg YW5kIHN1YmplY3QgdG8gdGhlIHN0YWJpbGl0eSBwcm92aXNpb25zIGluDQogICAgICBTZWN0aW9u IDMuMy4gIFRoaXMgaW5jbHVkZXMgIGRlc2NyaXB0aW9uczsgY29tbWVudHM7IGRlcHJlY2F0aW9u DQogICAgICBhbmQgcHJlZmVycmVkIHZhbHVlcyBmb3Igb2Jzb2xldGUgb3Igd2l0aGRyYXduIGNv ZGVzOyBvciB0aGUNCiAgICAgIGFkZGl0aW9uIG9mIHNjcmlwdCBvciBleHRsYW5nIGluZm9ybWF0 aW9uIHRvIHByaW1hcnkgbGFuZ3VhZ2UNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDMxXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1DQoNCg0KICAgICAgc3VidGFncy4NCg0KICAgbyAgVGhlIGFkZGl0aW9uIG9mIHJl Y29yZHMgYW5kIHJlbGF0ZWQgZmllbGQgdmFsdWUgY2hhbmdlcyBuZWNlc3NhcnkNCiAgICAgIHRv IHJlZmxlY3QgYXNzaWdubWVudHMgbWFkZSBieSBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2 LCBhbmQNCiAgICAgIFVOICBNLjQ5IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4NCg0KICAg VGhpcyBkb2N1bWVudCBsZWF2ZXMgdGhlIGRlY2lzaW9uIG9uIHdoYXQgc3VidGFncyAgb3IgY2hh bmdlcyB0bw0KICAgc3VidGFncyBhcmUgYXBwcm9wcmlhdGUgKG9yIG5vdCkgdG8gdGhlIHJlZ2lz dHJhdGlvbiBwcm9jZXNzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQuDQoNCiAgIE5vdGU6 IGZvdXIgY2hhcmFjdGVyIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgcmVzZXJ2ZWQgdG8g YWxsb3cNCiAgIGZvciB0aGUgcG9zc2liaWxpdHkgb2YgIGFscGhhNCBjb2RlcyBpbiBzb21lIGZ1 dHVyZSBhZGRpdGlvbiB0byB0aGUNCiAgIElTTyA2MzkgZmFtaWx5IG9mIHN0YW5kYXJkcy4NCg0K ICAgSVNPIDYzOSBkZWZpbmVzIGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBhZGRpdGlvbnMgdG8g YW5kIGNoYW5nZXMgaW4NCiAgIHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBpbiBJU08gNjM5LiAgVGhp cyBhZ2VuY3kgaXM6DQoNCiAgIEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24gQ2VudHJlIGZvciBU ZXJtaW5vbG9neSAoSW5mb3Rlcm0pDQogICBBaWNoaG9semdhc3NlIDYvMTIsIEFULTExMjANCiAg IFdpZW4sIEF1c3RyaWENCiAgIFBob25lOiArNDMgMSAyNiA3NSAzNSBFeHQuIDMxMiBGYXg6ICs0 MyAxIDIxNiAzMiA3Mg0KDQogICBJU08gNjM5LTIgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFnZW5j eSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzDQogICBpbiB0aGUgbGlzdCBvZiBsYW5ndWFn ZXMgaW4gSVNPIDYzOS0yLiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIExpYnJhcnkgb2YgQ29uZ3Jl c3MNCiAgIE5ldHdvcmsgRGV2ZWxvcG1lbnQgYW5kIE1BUkMgU3RhbmRhcmRzIE9mZmljZQ0KICAg V2FzaGluZ3RvbiwgRC5DLiAyMDU0MCBVU0ENCiAgIFBob25lOiArMSAyMDIgNzA3IDYyMzcgIEZh eDogKzEgMjAyIDcwNyAwMTE1DQogICBVUkw6IGh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMv aXNvNjM5DQoNCiAgIFRoZSBtYWludGVuYW5jZSBhZ2VuY3kgZm9yIElTTyAzMTY2IChjb3VudHJ5 IGNvZGVzKSBpczoNCg0KICAgSVNPIDMxNjYgTWFpbnRlbmFuY2UgQWdlbmN5DQogICBjL28gSW50 ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbg0KICAgQ2FzZSBwb3N0 YWxlIDU2DQogICBDSC0xMjExIEdlbmV2YSAyMCBTd2l0emVybGFuZA0KICAgUGhvbmU6ICs0MSAy MiA3NDkgNzIgMzMgIEZheDogKzQxIDIyIDc0OSA3MyA0OQ0KICAgVVJMOiBodHRwOi8vd3d3Lmlz by5vcmcvaXNvL2VuL3Byb2RzLXNlcnZpY2VzL2lzbzMxNjZtYS9pbmRleC5odG1sDQoNCiAgIFRo ZSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IGZvciBJU08gMTU5MjQgKHNjcmlwdCBjb2RlcykgaXM6 DQoNCiAgIFVuaWNvZGUgQ29uc29ydGl1bSBCb3ggMzkxNDc2DQogICBNb3VudGFpbiBWaWV3LCBD QSA5NDAzOS0xNDc2LCBVU0ENCiAgIFVSTDogaHR0cDovL3d3dy51bmljb2RlLm9yZy9pc28xNTky NA0KDQogICBUaGUgU3RhdGlzdGljcyBEaXZpc2lvbiBvZiB0aGUgVW5pdGVkIE5hdGlvbnMgU2Vj cmV0YXJpYXQgbWFpbnRhaW5zDQogICB0aGUgU3RhbmRhcmQgQ291bnRyeSBvciBBcmVhIENvZGVz IGZvciBTdGF0aXN0aWNhbCBVc2UgYW5kIGNhbiBiZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMzJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgQXVndXN0IDIwMDUNCg0KDQogICByZWFjaGVkIGF0Og0KDQogICBTdGF0aXN0aWNhbCBT ZXJ2aWNlcyBCcmFuY2gNCiAgIFN0YXRpc3RpY3MgRGl2aXNpb24NCiAgIFVuaXRlZCBOYXRpb25z LCBSb29tIERDMi0xNjIwDQogICBOZXcgWW9yaywgTlkgMTAwMTcsIFVTQQ0KDQogICBGYXg6ICsx LTIxMi05NjMtMDYyMw0KICAgRS1tYWlsOiBzdGF0aXN0aWNzQHVuLm9yZw0KICAgVVJMOiBodHRw Oi8vdW5zdGF0cy51bi5vcmcvdW5zZC9tZXRob2RzL200OS9tNDlhbHBoYS5odG0NCg0KMy42ICBF eHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIE5hbWVzcGFjZQ0KDQogICBFeHRlbnNpb24gc3VidGFn cyBhcmUgdGhvc2UgaW50cm9kdWNlZCBieSBzaW5nbGUtbGV0dGVyIHN1YnRhZ3Mgb3RoZXINCiAg IHRoYW4gJ3gnLiAgVGhleSBhcmUgcmVzZXJ2ZWQgZm9yIHRoZSBnZW5lcmF0aW9uIG9mIGlkZW50 aWZpZXJzIHdoaWNoDQogICBjb250YWluIGEgbGFuZ3VhZ2UgY29tcG9uZW50LCBhbmQgYXJlIGNv bXBhdGlibGUgd2l0aCBhcHBsaWNhdGlvbnMNCiAgIHRoYXQgdW5kZXJzdGFuZCBsYW5ndWFnZSB0 YWdzLg0KDQogICBUaGUgc3RydWN0dXJlIGFuZCBmb3JtIG9mIGV4dGVuc2lvbnMgYXJlIGRlZmlu ZWQgYnkgdGhpcyBkb2N1bWVudCBzbw0KICAgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY2FuIGJlIGNy ZWF0ZWQgdGhhdCBhcmUgZm9yd2FyZCBjb21wYXRpYmxlIHdpdGgNCiAgIGFwcGxpY2F0aW9ucyB0 aGF0IG1pZ2h0IGJlIGNyZWF0ZWQgdXNpbmcgc2luZ2xlLWxldHRlciBzdWJ0YWdzIGluIHRoZQ0K ICAgZnV0dXJlLiAgSW4gYWRkaXRpb24sIGRlZmluaW5nIGEgbWVjaGFuaXNtIGZvciBtYWludGFp bmluZyBzaW5nbGUtDQogICBsZXR0ZXIgc3VidGFncyB3aWxsIGxlbmQgc3RhYmlsaXR5IHRvIHRo aXMgZG9jdW1lbnQgYnkgcmVkdWNpbmcgdGhlDQogICBsaWtlbHkgbmVlZCBmb3IgZnV0dXJlIHJl dmlzaW9ucyBvciB1cGRhdGVzLg0KDQogICBTaW5nbGUtbGV0dGVyIHN1YnRhZ3MgYXJlIHRvIGJl IGFzc2lnbmVkIGJ5IElBTkEgdXNpbmcgdGhlICJJRVRGDQogICBDb25zZW5zdXMiIHBvbGljeSBk ZWZpbmVkIGJ5IFtSRkMyNDM0XS4gIFRoaXMgcG9saWN5IHJlcXVpcmVzIHRoZQ0KICAgZGV2ZWxv cG1lbnQgb2YgYW4gUkZDLCB3aGljaCBTSEFMTCBkZWZpbmUgdGhlIG5hbWUsIHB1cnBvc2UsDQog ICBwcm9jZXNzZXMsIGFuZCBwcm9jZWR1cmVzIGZvciBtYWludGFpbmluZyB0aGUgc3VidGFncy4g IFRoZQ0KICAgbWFpbnRhaW5pbmcgb3IgcmVnaXN0ZXJpbmcgYXV0aG9yaXR5LCBpbmNsdWRpbmcg bmFtZSwgY29udGFjdCBlbWFpbCwNCiAgIGRpc2N1c3Npb24gbGlzdCBlbWFpbCwgYW5kIFVSTCBs b2NhdGlvbiBvZiB0aGUgcmVnaXN0cnkgTVVTVCBiZQ0KICAgaW5kaWNhdGVkIGNsZWFybHkgaW4g dGhlIFJGQy4gIFRoZSBSRkMgTVVTVCBzcGVjaWZ5IG9yIGluY2x1ZGUgZWFjaA0KICAgb2YgdGhl IGZvbGxvd2luZzoNCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCByZWZlcmVuY2UgdGhl IHNwZWNpZmljIHZlcnNpb24gb3IgcmV2aXNpb24NCiAgICAgIG9mIHRoaXMgZG9jdW1lbnQgdGhh dCBnb3Zlcm5zIGl0cyBjcmVhdGlvbiBhbmQgTVVTVCByZWZlcmVuY2UgdGhpcw0KICAgICAgc2Vj dGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBhbmQgYWxs IHN1YnRhZ3MgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbg0KICAgICAgTVVTVCBmb2xsb3cg dGhlIEFCTkYgYW5kIG90aGVyIHJ1bGVzIGZvciB0aGUgZm9ybWF0aW9uIG9mIHRhZ3MgYW5kDQog ICAgICBzdWJ0YWdzIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIEluIHBhcnRpY3VsYXIg aXQgTVVTVA0KICAgICAgc3BlY2lmeSB0aGF0IGNhc2UgaXMgbm90IHNpZ25pZmljYW50IGFuZCB0 aGF0IHN1YnRhZ3MgTVVTVCBOT1QNCiAgICAgIGV4Y2VlZCBlaWdodCBjaGFyYWN0ZXJzIGluIGxl bmd0aC4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBzcGVjaWZ5IGEgY2Fub25pY2Fs IHJlcHJlc2VudGF0aW9uLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBvZiB2YWxpZCBzdWJ0 YWdzIE1VU1QgYmUgYXZhaWxhYmxlIG92ZXIgdGhlDQogICAgICBJbnRlcm5ldCBhbmQgYXQgbm8g Y29zdC4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwg MjAwNiAgICAgICAgICAgICAgIFtQYWdlIDMzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAg byAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBiZSBpbiB0aGUgcHVibGljIGRvbWFpbiBvciBhdmFp bGFibGUgdmlhIGENCiAgICAgIHJveWFsdHktZnJlZSBsaWNlbnNlIGFjY2VwdGFibGUgdG8gdGhl IElFVEYgYW5kIHNwZWNpZmllZCBpbiB0aGUNCiAgICAgIFJGQy4NCg0KICAgbyAgVGhlIHNwZWNp ZmljYXRpb24gTVVTVCBiZSB2ZXJzaW9uZWQgYW5kIGVhY2ggdmVyc2lvbiBvZiB0aGUNCiAgICAg IHNwZWNpZmljYXRpb24gTVVTVCBiZSBudW1iZXJlZCwgZGF0ZWQsIGFuZCBzdGFibGUuDQoNCiAg IG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgc3RhYmxlLiAgVGhhdCBpcywgZXh0ZW5zaW9u IHN1YnRhZ3MsDQogICAgICBvbmNlIGRlZmluZWQgYnkgYSBzcGVjaWZpY2F0aW9uLCBNVVNUIE5P VCBiZSByZXRyYWN0ZWQgb3IgY2hhbmdlDQogICAgICBpbiBtZWFuaW5nIGluIGFueSBzdWJzdGFu dGlhbCB3YXkuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgaW5jbHVkZSBpbiBhIHNl cGFyYXRlIHNlY3Rpb24gdGhlDQogICAgICByZWdpc3RyYXRpb24gZm9ybSByZXByb2R1Y2VkIGlu IHRoaXMgc2VjdGlvbiAoYmVsb3cpIHRvIGJlIHVzZWQgaW4NCiAgICAgIHJlZ2lzdGVyaW5nIHRo ZSBleHRlbnNpb24gdXBvbiBwdWJsaWNhdGlvbiBhcyBhbiBSRkMuDQoNCiAgIG8gIElBTkEgTVVT VCBiZSBpbmZvcm1lZCBvZiBjaGFuZ2VzIHRvIHRoZSBjb250YWN0IGluZm9ybWF0aW9uIGFuZA0K ICAgICAgVVJMIGZvciB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KICAgSUFOQSB3aWxsIG1haW50YWlu IGEgcmVnaXN0cnkgb2YgYWxsb2NhdGVkIHNpbmdsZS1sZXR0ZXIgKHNpbmdsZXRvbikNCiAgIHN1 YnRhZ3MuICBUaGlzIHJlZ2lzdHJ5IE1VU1QgdXNlIHRoZSByZWNvcmQtamFyIGZvcm1hdCBkZXNj cmliZWQgYnkNCiAgIHRoZSBBQk5GIGluIFNlY3Rpb24gMy4xLiAgVXBvbiBwdWJsaWNhdGlvbiBv ZiBhbiBleHRlbnNpb24gYXMgYW4gUkZDLA0KICAgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBk ZWZpbmVkIGluIHRoZSBSRkMgTVVTVCBmb3J3YXJkIHRoaXMNCiAgIHJlZ2lzdHJhdGlvbiBmb3Jt IHRvIGllc2dAaWV0Zi5vcmcsIHdobyBNVVNUIGZvcndhcmQgdGhlIHJlcXVlc3QgdG8NCiAgIGlh bmFAaWFuYS5vcmcuICBUaGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IG9mIHRoZSBleHRlbnNpb24g TVVTVA0KICAgbWFpbnRhaW4gdGhlIGFjY3VyYWN5IG9mIHRoZSByZWNvcmQgYnkgc2VuZGluZyBh biB1cGRhdGVkIGZ1bGwgY29weQ0KICAgb2YgdGhlIHJlY29yZCB0byBpYW5hQGlhbmEub3JnIHdp dGggdGhlIHN1YmplY3QgbGluZSAiTEFOR1VBR0UgVEFHDQogICBFWFRFTlNJT04gVVBEQVRFIiB3 aGVuZXZlciBjb250ZW50IGNoYW5nZXMuICBPbmx5IHRoZSAnQ29tbWVudHMnLA0KICAgJ0NvbnRh Y3RfRW1haWwnLCAnTWFpbGluZ19MaXN0JywgYW5kICdVUkwnIGZpZWxkcyBNQVkgYmUgbW9kaWZp ZWQgaW4NCiAgIHRoZXNlIHVwZGF0ZXMuDQoNCiAgIEZhaWx1cmUgdG8gbWFpbnRhaW4gdGhpcyBy ZWNvcmQsIHRoZSBjb3JyZXNwb25kaW5nIHJlZ2lzdHJ5LCBvciBtZWV0DQogICBvdGhlciBjb25k aXRpb25zIGltcG9zZWQgYnkgdGhpcyBzZWN0aW9uIG9mIHRoaXMgZG9jdW1lbnQgTUFZIGJlDQog ICBhcHBlYWxlZCB0byB0aGUgSUVTRyBbUkZDMjAyOF0gdW5kZXIgdGhlIHNhbWUgcnVsZXMgYXMg b3RoZXIgSUVURg0KICAgZGVjaXNpb25zIChzZWUgW1JGQzIwMjZdKSBhbmQgTUFZIHJlc3VsdCBp biB0aGUgYXV0aG9yaXR5IHRvIG1haW50YWluDQogICB0aGUgZXh0ZW5zaW9uIGJlaW5nIHdpdGhk cmF3biBvciByZWFzc2lnbmVkIGJ5IHRoZSBJRVNHLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYg ICAgICAgICAgICAgICBbUGFnZSAzNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgICUlDQog ICBJZGVudGlmaWVyOg0KICAgRGVzY3JpcHRpb246DQogICBDb21tZW50czoNCiAgIEFkZGVkOg0K ICAgUkZDOg0KICAgQXV0aG9yaXR5Og0KICAgQ29udGFjdF9FbWFpbDoNCiAgIE1haWxpbmdfTGlz dDoNCiAgIFVSTDoNCiAgICUlDQoNCiAgICBGaWd1cmUgNjogRm9ybWF0IG9mIFJlY29yZHMgaW4g dGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5DQoNCiAgICdJZGVudGlmaWVyJyBj b250YWlucyB0aGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgKHNpbmdsZXRvbikgYXNzaWduZWQNCiAg IHRvIHRoZSBleHRlbnNpb24uICBUaGUgSW50ZXJuZXQtRHJhZnQgc3VibWl0dGVkIHRvIGRlZmlu ZSB0aGUNCiAgIGV4dGVuc2lvbiBTSE9VTEQgc3BlY2lmeSB3aGljaCBsZXR0ZXIgdG8gdXNlLCBh bHRob3VnaCB0aGUgSUVTRyBNQVkNCiAgIGNoYW5nZSB0aGUgYXNzaWdubWVudCB3aGVuIGFwcHJv dmluZyB0aGUgUkZDLg0KDQogICAnRGVzY3JpcHRpb24nIGNvbnRhaW5zIHRoZSBuYW1lIGFuZCBk ZXNjcmlwdGlvbiBvZiB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQ29tbWVudHMnIGlzIGFuIE9QVElP TkFMIGZpZWxkIGFuZCBNQVkgY29udGFpbiBhIGJyb2FkZXIgZGVzY3JpcHRpb24NCiAgIG9mIHRo ZSBleHRlbnNpb24uDQoNCiAgICdBZGRlZCcgY29udGFpbnMgdGhlIGRhdGUgdGhlIFJGQyB3YXMg cHVibGlzaGVkIGluIHRoZSAiZnVsbC1kYXRlIg0KICAgZm9ybWF0IHNwZWNpZmllZCBpbiBbUkZD MzMzOV0uICBGb3IgZXhhbXBsZTogMjAwNC0wNi0yOCByZXByZXNlbnRzDQogICBKdW5lIDI4LCAy MDA0LCBpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLg0KDQogICAnUkZDJyBjb250YWlucyB0aGUg UkZDIG51bWJlciBhc3NpZ25lZCB0byB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQXV0aG9yaXR5JyBj b250YWlucyB0aGUgbmFtZSBvZiB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGZvciB0aGUNCiAg IGV4dGVuc2lvbi4NCg0KICAgJ0NvbnRhY3RfRW1haWwnIGNvbnRhaW5zIHRoZSBlbWFpbCBhZGRy ZXNzIHVzZWQgdG8gY29udGFjdCB0aGUNCiAgIG1haW50YWluaW5nIGF1dGhvcml0eS4NCg0KICAg J01haWxpbmdfTGlzdCcgY29udGFpbnMgdGhlIFVSTCBvciBzdWJzY3JpcHRpb24gZW1haWwgYWRk cmVzcyBvZiB0aGUNCiAgIG1haWxpbmcgbGlzdCB1c2VkIGJ5IHRoZSBtYWludGFpbmluZyBhdXRo b3JpdHkuDQoNCiAgICdVUkwnIGNvbnRhaW5zIHRoZSBVUkwgb2YgdGhlIHJlZ2lzdHJ5IGZvciB0 aGlzIGV4dGVuc2lvbi4NCg0KICAgVGhlIGRldGVybWluYXRpb24gb2Ygd2hldGhlciBhbiBJbnRl cm5ldC1EcmFmdCBtZWV0cyB0aGUgYWJvdmUNCiAgIGNvbmRpdGlvbnMgYW5kIHRoZSBkZWNpc2lv biB0byBncmFudCBvciB3aXRoaG9sZCBzdWNoIGF1dGhvcml0eSByZXN0cw0KICAgc29sZWx5IHdp dGggdGhlIElFU0csIGFuZCBpcyBzdWJqZWN0IHRvIHRoZSBub3JtYWwgcmV2aWV3IGFuZCBhcHBl YWxzDQogICBwcm9jZXNzIGFzc29jaWF0ZWQgd2l0aCB0aGUgUkZDIHByb2Nlc3MuDQoNCiAgIEV4 dGVuc2lvbiBhdXRob3JzIGFyZSBzdHJvbmdseSBjYXV0aW9uZWQgdGhhdCBtYW55IChpbmNsdWRp bmcgbW9zdA0KICAgd2VsbC1mb3JtZWQpIHByb2Nlc3NvcnMgd2lsbCBiZSB1bmF3YXJlIG9mIGFu eSBzcGVjaWFsIHJlbGF0aW9uc2hpcHMNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDM1XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1DQoNCg0KICAgb3IgbWVhbmluZyBpbmhlcmVudCBpbiB0aGUgb3JkZXIgb2YgZXh0 ZW5zaW9uIHN1YnRhZ3MuICBFeHRlbnNpb24NCiAgIGF1dGhvcnMgU0hPVUxEIGF2b2lkIHN1YnRh ZyByZWxhdGlvbnNoaXBzIG9yIGNhbm9uaWNhbGl6YXRpb24NCiAgIG1lY2hhbmlzbXMgdGhhdCBp bnRlcmZlcmUgd2l0aCBtYXRjaGluZyBvciB3aXRoIGxlbmd0aCByZXN0cmljdGlvbnMNCiAgIHRo YXQgc29tZXRpbWVzIGV4aXN0IGluIGNvbW1vbiBwcm90b2NvbHMgd2hlcmUgdGhlIGV4dGVuc2lv biBpcyB1c2VkLg0KICAgSW4gcGFydGljdWxhciwgYXBwbGljYXRpb25zIE1BWSB0cnVuY2F0ZSB0 aGUgc3VidGFncyBpbiBkb2luZw0KICAgbWF0Y2hpbmcgb3IgaW4gZml0dGluZyBpbnRvIGxpbWl0 ZWQgbGVuZ3Rocywgc28gaXQgaXMgUkVDT01NRU5ERUQNCiAgIHRoYXQgdGhlIG1vc3Qgc2lnbmlm aWNhbnQgaW5mb3JtYXRpb24gYmUgaW4gdGhlIG1vc3Qgc2lnbmlmaWNhbnQNCiAgIChsZWZ0LW1v c3QpIHN1YnRhZ3MsIGFuZCB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIGdyYWNlZnVsbHkgaGFuZGxl DQogICB0cnVuY2F0ZWQgc3VidGFncy4NCg0KICAgV2hlbiBhIGxhbmd1YWdlIHRhZyBpcyB0byBi ZSB1c2VkIGluIGEgc3BlY2lmaWMsIGtub3duLCBwcm90b2NvbCwgaXQNCiAgIGlzIFJFQ09NTUVO REVEIHRoYXQgdGhhdCB0aGUgbGFuZ3VhZ2UgdGFnIG5vdCBjb250YWluIGV4dGVuc2lvbnMgbm90 DQogICBzdXBwb3J0ZWQgYnkgdGhhdCBwcm90b2NvbC4gIEluIGFkZGl0aW9uLCBub3RlIHRoYXQg c29tZSBwcm90b2NvbHMNCiAgIE1BWSBpbXBvc2UgdXBwZXIgbGltaXRzIG9uIHRoZSBsZW5ndGgg b2YgdGhlIHN0cmluZ3MgdXNlZCB0byBzdG9yZSBvcg0KICAgdHJhbnNwb3J0IHRoZSBsYW5ndWFn ZSB0YWcuDQoNCjMuNyAgSW5pdGlhbGl6YXRpb24gb2YgdGhlIFJlZ2lzdHJ5DQoNCiAgIEFkb3B0 aW9uIG9mIHRoaXMgZG9jdW1lbnQgd2lsbCBSRVFVSVJFIGFuIGluaXRpYWwgdmVyc2lvbiBvZiB0 aGUNCiAgIHJlZ2lzdHJ5IGNvbnRhaW5pbmcgdGhlIHZhcmlvdXMgc3VidGFncyBpbml0aWFsbHkg dmFsaWQgaW4gYSBsYW5ndWFnZQ0KICAgdGFnLiAgVGhpcyBjb2xsZWN0aW9uIG9mIHN1YnRhZ3Ms IGFsb25nIHdpdGggYSBkZXNjcmlwdGlvbiBvZiB0aGUNCiAgIHByb2Nlc3MgdXNlZCB0byBjcmVh dGUgaXQsIGlzIGRlc2NyaWJlZCBieSBbaW5pdGlhbC1yZWdpc3RyeV0uDQoNCiAgIFJlZ2lzdHJh dGlvbnMgdGhhdCBhcmUgaW4gcHJvY2VzcyB1bmRlciB0aGUgcnVsZXMgZGVmaW5lZCBpbg0KICAg W1JGQzMwNjZdIHdoZW4gdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIE1BWSBiZSBjb21wbGV0ZWQg dW5kZXIgdGhlDQogICBmb3JtZXIgcnVsZXMsIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBsYW5n dWFnZSB0YWcgcmV2aWV3ZXIuICBBbnkNCiAgIG5ldyByZWdpc3RyYXRpb25zIHN1Ym1pdHRlZCBh ZnRlciB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBNVVNUDQogICBiZSByZWplY3RlZC4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFn ZSAzNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCjQuICBGb3JtYXRpb24gYW5kIFByb2Nlc3Np bmcgb2YgTGFuZ3VhZ2UgVGFncw0KDQogICBUaGlzIHNlY3Rpb24gYWRkcmVzc2VzIGhvdyB0byB1 c2UgdGhlIGluZm9ybWF0aW9uIGluIHRoZSByZWdpc3RyeQ0KICAgd2l0aCB0aGUgdGFnIHN5bnRh eCB0byBjaG9vc2UsIGZvcm0gYW5kIHByb2Nlc3MgbGFuZ3VhZ2UgdGFncy4NCg0KNC4xICBDaG9p Y2Ugb2YgTGFuZ3VhZ2UgVGFnDQoNCiAgIE9uZSBpcyBzb21ldGltZXMgZmFjZWQgd2l0aCB0aGUg Y2hvaWNlIGJldHdlZW4gc2V2ZXJhbCBwb3NzaWJsZSB0YWdzDQogICBmb3IgdGhlIHNhbWUgYm9k eSBvZiB0ZXh0Lg0KDQogICBJbnRlcm9wZXJhYmlsaXR5IGlzIGJlc3Qgc2VydmVkIHdoZW4gYWxs IHVzZXJzIHVzZSB0aGUgc2FtZSBsYW5ndWFnZQ0KICAgdGFnIGluIG9yZGVyIHRvIHJlcHJlc2Vu dCB0aGUgc2FtZSBsYW5ndWFnZS4gIElmIGFuIGFwcGxpY2F0aW9uIGhhcw0KICAgcmVxdWlyZW1l bnRzIHRoYXQgbWFrZSB0aGUgcnVsZXMgaGVyZSBpbmFwcGxpY2FibGUsIHRoZW4gdGhhdA0KICAg YXBwbGljYXRpb24gcmlza3MgZGFtYWdpbmcgaW50ZXJvcGVyYWJpbGl0eS4gIEl0IGlzIHN0cm9u Z2x5DQogICBSRUNPTU1FTkRFRCB0aGF0IHVzZXJzIG5vdCBkZWZpbmUgdGhlaXIgb3duIHJ1bGVz IGZvciBsYW5ndWFnZSB0YWcNCiAgIGNob2ljZS4NCg0KICAgU3VidGFncyBTSE9VTEQgb25seSBi ZSB1c2VkICB3aGVyZSB0aGV5IGFkZCB1c2VmdWwgZGlzdGluZ3Vpc2hpbmcNCiAgIGluZm9ybWF0 aW9uOyBleHRyYW5lb3VzIHN1YnRhZ3MgaW50ZXJmZXJlIHdpdGggdGhlIG1lYW5pbmcsDQogICB1 bmRlcnN0YW5kaW5nLCBhbmQgcHJvY2Vzc2luZyBvZiBsYW5ndWFnZSB0YWdzLiAgSW4gcGFydGlj dWxhciwgdXNlcnMNCiAgIGFuZCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGZvbGxvdyB0aGUgJ1By ZWZpeCcgYW5kICdTdXBwcmVzcy1TY3JpcHQnDQogICBmaWVsZHMgaW4gdGhlIHJlZ2lzdHJ5IChk ZWZpbmVkIGluIFNlY3Rpb24gMy4xKTogdGhlc2UgZmllbGRzIHByb3ZpZGUNCiAgIGd1aWRhbmNl IG9uIHdoZW4gc3BlY2lmaWMgYWRkaXRpb25hbCBzdWJ0YWdzIFNIT1VMRCAoYW5kIFNIT1VMRCBO T1QpDQogICBiZSB1c2VkIGluIGEgbGFuZ3VhZ2UgdGFnLg0KDQogICBPZiBwYXJ0aWN1bGFyIG5v dGUsIG1hbnkgYXBwbGljYXRpb25zIGNhbiBiZW5lZml0IGZyb20gdGhlIHVzZSBvZg0KICAgc2Ny aXB0IHN1YnRhZ3MgaW4gbGFuZ3VhZ2UgdGFncywgYXMgbG9uZyBhcyB0aGUgdXNlIGlzIGNvbnNp c3RlbnQgZm9yDQogICBhIGdpdmVuIGNvbnRleHQuICBTY3JpcHQgc3VidGFncyB3ZXJlIG5vdCBm b3JtYWxseSBkZWZpbmVkIGluIFJGQw0KICAgMzA2NiBhbmQgdGhlaXIgdXNlIGNhbiBhZmZlY3Qg bWF0Y2hpbmcgYW5kIHN1YnRhZyBpZGVudGlmaWNhdGlvbiBieQ0KICAgaW1wbGVtZW50YXRpb25z IG9mIFJGQyAzMDY2LCBhcyB0aGVzZSBzdWJ0YWdzIGFwcGVhciBiZXR3ZWVuIHRoZQ0KICAgcHJp bWFyeSBsYW5ndWFnZSBhbmQgcmVnaW9uIHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwgaWYgYSB1c2Vy IHJlcXVlc3RzDQogICBjb250ZW50IGluIGFuIGltcGxlbWVudGF0aW9uIG9mIFNlY3Rpb24gMi41 IG9mIFtSRkMzMDY2XSB1c2luZyB0aGUNCiAgIGxhbmd1YWdlIHJhbmdlICJlbi1VUyIsIGNvbnRl bnQgbGFiZWxlZCAiZW4tTGF0bi1VUyIgd2lsbCBub3QgbWF0Y2gNCiAgIHRoZSByZXF1ZXN0LiAg VGhlcmVmb3JlIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHdoZW4gc2NyaXB0IHN1YnRhZ3MNCiAg IHdpbGwgY3VzdG9tYXJpbHkgYmUgdXNlZCBhbmQgd2hlbiB0aGV5IG91Z2h0IG5vdCBiZSB1c2Vk LiAgSW4gdGhlDQogICByZWdpc3RyeSwgdGhlIFN1cHByZXNzLVNjcmlwdCBmaWVsZCBoZWxwcyBl bnN1cmUgZ3JlYXRlcg0KICAgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFnZSB0YWdz IGdlbmVyYXRlZCBhY2NvcmRpbmcgdG8gdGhlDQogICBydWxlcyBpbiB0aGlzIGRvY3VtZW50IGFu ZCBsYW5ndWFnZSB0YWdzIGFuZCB0YWcgcHJvY2Vzc29ycyBvcg0KICAgY29uc3VtZXJzIGJhc2Vk IG9uIFJGQyAzMDY2IGJ5IGRlZmluaW5nIHdoZW4gdXNlcnMgU0hPVUxEIE5PVCBpbmNsdWRlDQog ICBhIHNjcmlwdCBzdWJ0YWcgd2l0aCBhIHBhcnRpY3VsYXIgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0 YWcuDQoNCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgKHR5cGUgJ2V4dGxhbmcnIGluIHRo ZSByZWdpc3RyeSwgc2VlDQogICBTZWN0aW9uIDMuMSkgYWxzbyBhcHBlYXIgYmV0d2VlbiB0aGUg cHJpbWFyeSBsYW5ndWFnZSBhbmQgcmVnaW9uDQogICBzdWJ0YWdzIGFuZCBhcmUgcmVzZXJ2ZWQg Zm9yIGZ1dHVyZSBzdGFuZGFyZGl6YXRpb24uICBBcHBsaWNhdGlvbnMNCiAgIG1pZ2h0IGJlbmVm aXQgZnJvbSB0aGVpciBqdWRpY2lvdXMgdXNlIGluIGZvcm1pbmcgbGFuZ3VhZ2UgdGFncyBpbg0K ICAgdGhlIGZ1dHVyZS4gIFNpbWlsYXIgcmVjb21tZW5kYXRpb25zIGFyZSBleHBlY3RlZCB0byBh cHBseSB0byB0aGVpcg0KICAgdXNlIGFzIGFwcGx5IHRvIHNjcmlwdCBzdWJ0YWdzLg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAg ICAgICAgICBbUGFnZSAzN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIFN0YW5kYXJkcywg cHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlvbnMgdGhhdCByZWZlcmVuY2UgdGhpcyBkb2N1bWVudA0K ICAgbm9ybWF0aXZlbHkgYnV0IGFwcGx5IGRpZmZlcmVudCBydWxlcyB0byB0aGUgb25lcyBnaXZl biBpbiB0aGlzDQogICBzZWN0aW9uIE1VU1Qgc3BlY2lmeSBob3cgdGhlIHByb2NlZHVyZSB2YXJp ZXMgZnJvbSB0aGUgb25lIGdpdmVuDQogICBoZXJlLg0KDQogICBUaGUgY2hvaWNlIG9mIHN1YnRh Z3MgdXNlZCB0byBmb3JtIGEgbGFuZ3VhZ2UgdGFnIFNIT1VMRCBiZSBndWlkZWQgYnkNCiAgIHRo ZSBmb2xsb3dpbmcgcnVsZXM6DQoNCiAgIDEuICBVc2UgYXMgcHJlY2lzZSBhIHRhZyBhcyBwb3Nz aWJsZSwgYnV0IG5vIG1vcmUgc3BlY2lmaWMgdGhhbiBpcw0KICAgICAgIGp1c3RpZmllZC4gIEF2 b2lkIHVzaW5nIHN1YnRhZ3MgdGhhdCBhcmUgbm90IGltcG9ydGFudCBmb3INCiAgICAgICBkaXN0 aW5ndWlzaGluZyBjb250ZW50IGluIGFuIGFwcGxpY2F0aW9uLg0KDQogICAgICAgKiAgRm9yIGV4 YW1wbGUsICdkZScgbWlnaHQgc3VmZmljZSBmb3IgdGFnZ2luZyBhbiBlbWFpbCB3cml0dGVuDQog ICAgICAgICAgaW4gR2VybWFuLCB3aGlsZSAiZGUtQ0gtMTk5NiIgaXMgcHJvYmFibHkgdW5uZWNl c3NhcmlseQ0KICAgICAgICAgIHByZWNpc2UgZm9yIHN1Y2ggYSB0YXNrLg0KDQogICAyLiAgVGhl IHNjcmlwdCBzdWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB1 bmxlc3MNCiAgICAgICB0aGUgc2NyaXB0IGFkZHMgc29tZSBkaXN0aW5ndWlzaGluZyBpbmZvcm1h dGlvbiB0byB0aGUgdGFnLiAgVGhlDQogICAgICAgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgaW4g dGhlIHByaW1hcnkgbGFuZ3VhZ2UgcmVjb3JkIGluIHRoZQ0KICAgICAgIHJlZ2lzdHJ5IGluZGlj YXRlcyB3aGljaCBzY3JpcHQgc3VidGFncyBkbyBub3QgYWRkIGRpc3Rpbmd1aXNoaW5nDQogICAg ICAgaW5mb3JtYXRpb24gZm9yIG1vc3QgYXBwbGljYXRpb25zLg0KDQogICAgICAgKiAgRm9yIGV4 YW1wbGUsIHRoZSBzdWJ0YWcgJ0xhdG4nIHNob3VsZCBub3QgYmUgdXNlZCB3aXRoIHRoZQ0KICAg ICAgICAgIHByaW1hcnkgbGFuZ3VhZ2UgJ2VuJyBiZWNhdXNlIG5lYXJseSBhbGwgRW5nbGlzaCBk b2N1bWVudHMgYXJlDQogICAgICAgICAgd3JpdHRlbiBpbiB0aGUgTGF0aW4gc2NyaXB0IGFuZCBp dCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQogICAgICAgICAgaW5mb3JtYXRpb24uICBIb3dldmVy LCBpZiBhIGRvY3VtZW50IHdlcmUgd3JpdHRlbiBpbiBFbmdsaXNoDQogICAgICAgICAgbWl4aW5n IExhdGluIHNjcmlwdCB3aXRoIGFub3RoZXIgc2NyaXB0IHN1Y2ggYXMgQnJhaWxsZQ0KICAgICAg ICAgICgnQnJhaScpLCB0aGVuIGl0IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIHRvIGNob29zZSB0byBp bmRpY2F0ZQ0KICAgICAgICAgIGJvdGggc2NyaXB0cyB0byBhaWQgaW4gY29udGVudCBzZWxlY3Rp b24sIHN1Y2ggYXMgdGhlDQogICAgICAgICAgYXBwbGljYXRpb24gb2YgYSBzdHlsZSBzaGVldC4N Cg0KICAgMy4gIElmIGEgdGFnIG9yIHN1YnRhZyBoYXMgYSAnUHJlZmVycmVkLVZhbHVlJyBmaWVs ZCBpbiBpdHMgcmVnaXN0cnkNCiAgICAgICBlbnRyeSwgdGhlbiB0aGUgIHZhbHVlIG9mIHRoYXQg ZmllbGQgU0hPVUxEIGJlIHVzZWQgdG8gZm9ybSB0aGUNCiAgICAgICBsYW5ndWFnZSB0YWcgaW4g cHJlZmVyZW5jZSB0byB0aGUgdGFnIG9yIHN1YnRhZyBpbiB3aGljaCB0aGUNCiAgICAgICBwcmVm ZXJyZWQgdmFsdWUgYXBwZWFycy4NCg0KICAgICAgICogIEZvciBleGFtcGxlLCB1c2UgJ2hlJyBm b3IgSGVicmV3IGluIHByZWZlcmVuY2UgdG8gJ2l3Jy4NCg0KICAgNC4gIFRoZSAndW5kJyAoVW5k ZXRlcm1pbmVkKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBTSE9VTEQgTk9UIGJlDQogICAgICAg dXNlZCB0byBsYWJlbCBjb250ZW50LCBldmVuIGlmIHRoZSBsYW5ndWFnZSBpcyB1bmtub3duLiAg T21pdHRpbmcNCiAgICAgICB0aGUgbGFuZ3VhZ2UgdGFnIGFsdG9nZXRoZXIgaXMgcHJlZmVycmVk IHRvIHVzaW5nIGEgdGFnIHdpdGggYQ0KICAgICAgIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIG9m ICd1bmQnLiAgVGhlICd1bmQnIHN1YnRhZyBNQVkgYmUgdXNlZnVsDQogICAgICAgZm9yIHByb3Rv Y29scyB0aGF0IHJlcXVpcmUgYSBsYW5ndWFnZSB0YWcgdG8gYmUgcHJvdmlkZWQuICBUaGUNCiAg ICAgICAndW5kJyBzdWJ0YWcgTUFZIGFsc28gYmUgdXNlZnVsIHdoZW4gbWF0Y2hpbmcgbGFuZ3Vh Z2UgdGFncyBpbg0KICAgICAgIGNlcnRhaW4gc2l0dWF0aW9ucy4NCg0KICAgNS4gIFRoZSAnbXVs JyAoTXVsdGlwbGUpIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZA0K ICAgICAgIHdoZW5ldmVyIHRoZSBwcm90b2NvbCBhbGxvd3MgdGhlIHNlcGFyYXRlIHRhZ3MgZm9y IG11bHRpcGxlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAzOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoN CiAgICAgICBsYW5ndWFnZXMsIGFzIGlzIHRoZSBjYXNlIGZvciB0aGUgQ29udGVudC1MYW5ndWFn ZSBoZWFkZXIgaW4NCiAgICAgICBIVFRQLiAgVGhlICdtdWwnIHN1YnRhZyBjb252ZXlzIGxpdHRs ZSB1c2VmdWwgaW5mb3JtYXRpb246DQogICAgICAgY29udGVudCBpbiBtdWx0aXBsZSBsYW5ndWFn ZXMgU0hPVUxEIGluZGl2aWR1YWxseSB0YWcgdGhlDQogICAgICAgbGFuZ3VhZ2VzIHdoZXJlIHRo ZXkgYXBwZWFyIG9yIG90aGVyd2lzZSBpbmRpY2F0ZSB0aGUgYWN0dWFsDQogICAgICAgbGFuZ3Vh Z2UgaW4gcHJlZmVyZW5jZSB0byB0aGUgJ211bCcgc3VidGFnLg0KDQogICA2LiAgVGhlIHNhbWUg dmFyaWFudCBzdWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2VkIG1vcmUgdGhhbiBvbmNlIHdpdGhpbg0K ICAgICAgIGEgbGFuZ3VhZ2UgdGFnLg0KDQogICAgICAgKiAgRm9yIGV4YW1wbGUsIGRvIG5vdCB1 c2UgImRlLURFLTE5MDEtMTkwMSIuDQoNCiAgIFRvIGVuc3VyZSBjb25zaXN0ZW50IGJhY2t3YXJk IGNvbXBhdGliaWxpdHksIHRoaXMgZG9jdW1lbnQgY29udGFpbnMNCiAgIHNldmVyYWwgcHJvdmlz aW9ucyB0byBhY2NvdW50IGZvciBwb3RlbnRpYWwgaW5zdGFiaWxpdHkgaW4gdGhlDQogICBzdGFu ZGFyZHMgdXNlZCB0byBkZWZpbmUgdGhlIHN1YnRhZ3MgdGhhdCBtYWtlIHVwIGxhbmd1YWdlIHRh Z3MuDQogICBUaGVzZSBwcm92aXNpb25zIG1lYW4gdGhhdCBubyBsYW5ndWFnZSB0YWcgY3JlYXRl ZCB1bmRlciB0aGUgcnVsZXMgaW4NCiAgIHRoaXMgZG9jdW1lbnQgd2lsbCBiZWNvbWUgb2Jzb2xl dGUuDQoNCjQuMiAgTWVhbmluZyBvZiB0aGUgTGFuZ3VhZ2UgVGFnDQoNCiAgIFRoZSByZWxhdGlv bnNoaXAgYmV0d2VlbiB0aGUgdGFnIGFuZCB0aGUgaW5mb3JtYXRpb24gaXQgcmVsYXRlcyB0byBp cw0KICAgZGVmaW5lZCBieSB0aGUgY29udGV4dCBpbiB3aGljaCB0aGUgdGFnIGFwcGVhcnMuICBB Y2NvcmRpbmdseSwgdGhpcw0KICAgc2VjdGlvbiBnaXZlcyBvbmx5IHBvc3NpYmxlIGV4YW1wbGVz IG9mIGl0cyB1c2FnZS4NCg0KICAgbyAgRm9yIGEgc2luZ2xlIGluZm9ybWF0aW9uIG9iamVjdCwg dGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UgdGFncw0KICAgICAgbWlnaHQgYmUgaW50ZXJwcmV0ZWQg YXMgdGhlIHNldCBvZiBsYW5ndWFnZXMgdGhhdCBpcyBuZWNlc3NhcnkgZm9yDQogICAgICBhIGNv bXBsZXRlIGNvbXByZWhlbnNpb24gb2YgdGhlIGNvbXBsZXRlIG9iamVjdC4gIEV4YW1wbGU6IFBs YWluDQogICAgICB0ZXh0IGRvY3VtZW50cy4NCg0KICAgbyAgRm9yIGFuIGFnZ3JlZ2F0aW9uIG9m IGluZm9ybWF0aW9uIG9iamVjdHMsIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlDQogICAgICB0YWdz IGNvdWxkIGJlIHRha2VuIGFzIHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHVzZWQgaW5zaWRlIGNvbXBv bmVudHMNCiAgICAgIG9mIHRoYXQgYWdncmVnYXRpb24uICBFeGFtcGxlczogRG9jdW1lbnQgc3Rv cmVzIGFuZCBsaWJyYXJpZXMuDQoNCiAgIG8gIEZvciBpbmZvcm1hdGlvbiBvYmplY3RzIHdob3Nl IHB1cnBvc2UgaXMgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZXMsDQogICAgICB0aGUgYXNzb2NpYXRl ZCBsYW5ndWFnZSB0YWdzIGNvdWxkIGJlIHJlZ2FyZGVkIGFzIGEgaGludCB0aGF0IHRoZQ0KICAg ICAgY29udGVudCBpcyBwcm92aWRlZCBpbiBzZXZlcmFsIGxhbmd1YWdlcywgYW5kIHRoYXQgb25l IGhhcyB0bw0KICAgICAgaW5zcGVjdCBlYWNoIG9mIHRoZSBhbHRlcm5hdGl2ZXMgaW4gb3JkZXIg dG8gZmluZCBpdHMgbGFuZ3VhZ2Ugb3INCiAgICAgIGxhbmd1YWdlcy4gIEluIHRoaXMgY2FzZSwg dGhlIHByZXNlbmNlIG9mIG11bHRpcGxlIHRhZ3MgbWlnaHQgbm90DQogICAgICBtZWFuIHRoYXQg b25lIG5lZWRzIHRvIGJlIG11bHRpLWxpbmd1YWwgdG8gZ2V0IGNvbXBsZXRlDQogICAgICB1bmRl cnN0YW5kaW5nIG9mIHRoZSBkb2N1bWVudC4gIEV4YW1wbGU6IE1JTUUgbXVsdGlwYXJ0Lw0KICAg ICAgYWx0ZXJuYXRpdmUuDQoNCiAgIG8gIEluIG1hcmt1cCBsYW5ndWFnZXMsIHN1Y2ggYXMgSFRN TCBhbmQgWE1MLCBsYW5ndWFnZSBpbmZvcm1hdGlvbg0KICAgICAgY2FuIGJlIGFkZGVkIHRvIGVh Y2ggcGFydCBvZiB0aGUgZG9jdW1lbnQgaWRlbnRpZmllZCBieSB0aGUgbWFya3VwDQogICAgICBz dHJ1Y3R1cmUgKGluY2x1ZGluZyB0aGUgd2hvbGUgZG9jdW1lbnQgaXRzZWxmKS4gIEZvciBleGFt cGxlLCBvbmUNCiAgICAgIGNvdWxkIHdyaXRlIDxzcGFuIGxhbmc9ImZyIj5DJ2VzdCBsYSB2aWUu PC9zcGFuPiBpbnNpZGUgYQ0KICAgICAgTm9yd2VnaWFuIGRvY3VtZW50OyB0aGUgTm9yd2VnaWFu LXNwZWFraW5nIHVzZXIgY291bGQgdGhlbiBhY2Nlc3MNCiAgICAgIGEgRnJlbmNoLU5vcndlZ2lh biBkaWN0aW9uYXJ5IHRvIGZpbmQgb3V0IHdoYXQgdGhlIG1hcmtlZCBzZWN0aW9uDQogICAgICBt ZWFudC4gIElmIHRoZSB1c2VyIHdlcmUgbGlzdGVuaW5nIHRvIHRoYXQgZG9jdW1lbnQgdGhyb3Vn aCBhDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIw MDYgICAgICAgICAgICAgICBbUGFnZSAzOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgICAg IHNwZWVjaCBzeW50aGVzaXMgaW50ZXJmYWNlLCB0aGlzIGZvcm1hdGlvbiBjb3VsZCBiZSB1c2Vk IHRvIHNpZ25hbA0KICAgICAgdGhlIHN5bnRoZXNpemVyIHRvIGFwcHJvcHJpYXRlbHkgYXBwbHkg RnJlbmNoIHRleHQtdG8tc3BlZWNoDQogICAgICBwcm9udW5jaWF0aW9uIHJ1bGVzIHRvIHRoYXQg c3BhbiBvZiB0ZXh0LCBpbnN0ZWFkIG9mIGFwcGx5aW5nIHRoZQ0KICAgICAgaW5hcHByb3ByaWF0 ZSBOb3J3ZWdpYW4gcnVsZXMuDQoNCiAgIExhbmd1YWdlIHRhZ3MgYXJlIHJlbGF0ZWQgd2hlbiB0 aGV5IGNvbnRhaW4gYSBzaW1pbGFyIHNlcXVlbmNlIG9mDQogICBzdWJ0YWdzLiAgRm9yIGV4YW1w bGUsIGlmIGEgbGFuZ3VhZ2UgdGFnIEIgY29udGFpbnMgbGFuZ3VhZ2UgdGFnIEEgYXMNCiAgIGEg cHJlZml4LCB0aGVuIEIgaXMgdHlwaWNhbGx5ICJuYXJyb3dlciIgb3IgIm1vcmUgc3BlY2lmaWMi IHRoYW4gQS4NCiAgIFRodXMgInpoLUhhbnQtVFciIGlzIG1vcmUgc3BlY2lmaWMgdGhhbiAiemgt SGFudCIuDQoNCiAgIFRoaXMgcmVsYXRpb25zaGlwIGlzIG5vdCBndWFyYW50ZWVkIGluIGFsbCBj YXNlczogc3BlY2lmaWNhbGx5LA0KICAgbGFuZ3VhZ2VzIHRoYXQgYmVnaW4gd2l0aCB0aGUgc2Ft ZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFyZSBOT1QNCiAgIGd1YXJhbnRlZWQgdG8gYmUgbXV0dWFs bHkgaW50ZWxsaWdpYmxlLCBhbHRob3VnaCB0aGV5IG1pZ2h0IGJlLiAgRm9yDQogICBleGFtcGxl LCB0aGUgdGFnICJheiIgc2hhcmVzIGEgcHJlZml4IHdpdGggYm90aCAiYXotTGF0biINCiAgIChB emVyYmFpamFuaSB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQpIGFuZCAiYXotQ3lybCIN CiAgIChBemVyYmFpamFuaSB3cml0dGVuIHVzaW5nIHRoZSBDeXJpbGxpYyBzY3JpcHQpLiAgQSBw ZXJzb24gZmx1ZW50IGluDQogICBvbmUgc2NyaXB0IG1pZ2h0IG5vdCBiZSBhYmxlIHRvIHJlYWQg dGhlIG90aGVyLCBldmVuIHRob3VnaCB0aGUgdGV4dA0KICAgbWlnaHQgYmUgaWRlbnRpY2FsLiAg Q29udGVudCB0YWdnZWQgYXMgImF6IiBtb3N0IHByb2JhYmx5IGlzIHdyaXR0ZW4NCiAgIGluIGp1 c3Qgb25lIHNjcmlwdCBhbmQgdGh1cyBtaWdodCBub3QgYmUgaW50ZWxsaWdpYmxlIHRvIGEgcmVh ZGVyDQogICBmYW1pbGlhciB3aXRoIHRoZSBvdGhlciBzY3JpcHQuDQoNCjQuMyAgTGVuZ3RoIENv bnNpZGVyYXRpb25zDQoNCiAgIFtSRkMzMDY2XSBkaWQgbm90IHByb3ZpZGUgYW4gdXBwZXIgbGlt aXQgb24gdGhlIHNpemUgb2YgbGFuZ3VhZ2UNCiAgIHRhZ3MuICBXaGlsZSBSRkMgMzA2NiBkaWQg ZGVmaW5lIHRoZSBzZW1hbnRpY3Mgb2YgcGFydGljdWxhciBzdWJ0YWdzDQogICBpbiBzdWNoIGEg d2F5IHRoYXQgbW9zdCBsYW5ndWFnZSB0YWdzIGNvbnNpc3RlZCBvZiBsYW5ndWFnZSBhbmQNCiAg IHJlZ2lvbiBzdWJ0YWdzIHdpdGggYSBjb21iaW5lZCB0b3RhbCBsZW5ndGggb2YgdXAgdG8gc2l4 IGNoYXJhY3RlcnMsDQogICBsYXJnZXIgcmVnaXN0ZXJlZCB0YWdzIHdlcmUgbm90IG9ubHkgcG9z c2libGUgYnV0IHdlcmUgYWN0dWFsbHkNCiAgIHJlZ2lzdGVyZWQuDQoNCiAgIE5laXRoZXIgdGhl IGxhbmd1YWdlIHRhZyBzeW50YXggbm9yIG90aGVyIHJlcXVpcmVtZW50cyBpbiB0aGlzDQogICBk b2N1bWVudCAgaW1wb3NlIGEgZml4ZWQgdXBwZXIgbGltaXQgb24gdGhlIG51bWJlciBvZiBzdWJ0 YWdzIGluIGENCiAgIGxhbmd1YWdlIHRhZyAoYW5kIHRodXMgYW4gdXBwZXIgYm91bmQgb24gdGhl IHNpemUgb2YgYSB0YWcpLiAgVGhlDQogICBsYW5ndWFnZSB0YWcgc3ludGF4IHN1Z2dlc3RzIHRo YXQsIGRlcGVuZGluZyBvbiB0aGUgc3BlY2lmaWMNCiAgIGxhbmd1YWdlLCBtb3JlIHN1YnRhZ3Mg KGFuZCB0aHVzIGEgbG9uZ2VyIHRhZykgYXJlIHNvbWV0aW1lcw0KICAgbmVjZXNzYXJ5IHRvIGNv bXBsZXRlbHkgaWRlbnRpZnkgdGhlIGxhbmd1YWdlIGZvciBjZXJ0YWluDQogICBhcHBsaWNhdGlv bnM7IHRodXMgaXQgaXMgcG9zc2libGUgdG8gZW52aXNpb24gbG9uZyBvciBjb21wbGV4IHN1YnRh Zw0KICAgc2VxdWVuY2VzLg0KDQo0LjMuMSAgV29ya2luZyB3aXRoIExpbWl0ZWQgQnVmZmVyIFNp emVzDQoNCiAgIFNvbWUgYXBwbGljYXRpb25zIGFuZCBwcm90b2NvbHMgYXJlIGZvcmNlZCB0byBh bGxvY2F0ZSBmaXhlZCBidWZmZXINCiAgIHNpemVzIG9yIG90aGVyd2lzZSBsaW1pdCB0aGUgbGVu Z3RoIG9mIGEgbGFuZ3VhZ2UgdGFnLiAgQSBjb25mb3JtYW50DQogICBpbXBsZW1lbnRhdGlvbiBv ciBzcGVjaWZpY2F0aW9uIE1BWSByZWZ1c2UgdG8gc3VwcG9ydCB0aGUgc3RvcmFnZSBvZg0KICAg bGFuZ3VhZ2UgdGFncyB3aGljaCBleGNlZWQgYSBzcGVjaWZpZWQgbGVuZ3RoLiAgQW55IHN1Y2gg bGltaXRhdGlvbg0KICAgU0hPVUxEIGJlIGNsZWFybHkgZG9jdW1lbnRlZCwgYW5kIHN1Y2ggZG9j dW1lbnRhdGlvbiBTSE9VTEQgaW5jbHVkZQ0KICAgd2hhdCBoYXBwZW5zIHRvIGxvbmdlciB0YWdz IChmb3IgZXhhbXBsZSwgd2hldGhlciBhbiBlcnJvciB2YWx1ZSBpcw0KICAgZ2VuZXJhdGVkIG9y IHRoZSBsYW5ndWFnZSB0YWcgaXMgdHJ1bmNhdGVkKS4gIEEgcHJvdG9jb2wgdGhhdCBhbGxvd3MN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAg ICAgICAgICAgICAgIFtQYWdlIDQwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgdGFncyB0 byBiZSB0cnVuY2F0ZWQgYXQgYW4gYXJiaXRyYXJ5IGxpbWl0LCB3aXRob3V0IGdpdmluZyBhbnkN CiAgIGluZGljYXRpb24gb2Ygd2hhdCB0aGF0IGxpbWl0IGlzLCBoYXMgdGhlIHBvdGVudGlhbCBm b3IgY2F1c2luZyBoYXJtDQogICBieSBjaGFuZ2luZyB0aGUgbWVhbmluZyBvZiB0YWdzIGluIHN1 YnN0YW50aWFsIHdheXMuDQoNCiAgIEluIHByYWN0aWNlLCBtb3N0IGxhbmd1YWdlIHRhZ3MgZG8g bm90IHJlcXVpcmUgbW9yZSB0aGFuIGEgZmV3DQogICBzdWJ0YWdzIGFuZCB3aWxsIG5vdCBhcHBy b2FjaCByZWFzb25hYmx5IHNpemVkIGJ1ZmZlciBsaW1pdGF0aW9uczoNCiAgIHNlZSBTZWN0aW9u IDQuMS4NCg0KICAgU29tZSBzcGVjaWZpY2F0aW9ucyBvciBwcm90b2NvbHMgaGF2ZSBsaW1pdHMg b24gdGFnIGxlbmd0aCBidXQgZG8gbm90DQogICBoYXZlIGEgZml4ZWQgbGVuZ3RoIGxpbWl0YXRp b24uICBGb3IgZXhhbXBsZSwgW1JGQzIyMzFdICBoYXMgbm8NCiAgIGV4cGxpY2l0IGxlbmd0aCBs aW1pdGF0aW9uOiB0aGUgbGVuZ3RoIGF2YWlsYWJsZSBmb3IgdGhlIGxhbmd1YWdlIHRhZw0KICAg aXMgY29uc3RyYWluZWQgYnkgdGhlIGxlbmd0aCBvZiBvdGhlciBoZWFkZXIgY29tcG9uZW50cyAo c3VjaCBhcyB0aGUNCiAgIGNoYXJzZXQncyBuYW1lKSBjb3VwbGVkIHdpdGggdGhlIDc2IGNoYXJh Y3RlciBsaW1pdCBpbiBbUkZDMjA0N10uDQogICBUaHVzIHRoZSAibGltaXQiIG1pZ2h0IGJlIDUw IG9yIG1vcmUgY2hhcmFjdGVycywgYnV0IGl0IGNvdWxkDQogICBwb3RlbnRpYWxseSBiZSBxdWl0 ZSBzbWFsbC4NCg0KICAgVGhlIGNvbnNpZGVyYXRpb25zIGZvciBhc3NpZ25pbmcgYSBidWZmZXIg bGltaXQgYXJlOg0KDQogICAgICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIE5PVCB0cnVuY2F0ZSBs YW5ndWFnZSB0YWdzIHVubGVzcyB0aGUNCiAgICAgIG1lYW5pbmcgb2YgdGhlIHRhZyBpcyBwdXJw b3NlZnVsbHkgYmVpbmcgY2hhbmdlZCwgb3IgdW5sZXNzIHRoZQ0KICAgICAgdGFnIGRvZXMgbm90 IGZpdCBpbnRvIGEgbGltaXRlZCBidWZmZXIgc2l6ZSBzcGVjaWZpZWQgYnkgYQ0KICAgICAgcHJv dG9jb2wgZm9yIHN0b3JhZ2Ugb3IgdHJhbnNtaXNzaW9uLg0KDQogICAgICBJbXBsZW1lbnRhdGlv bnMgU0hPVUxEIHdhcm4gdGhlIHVzZXIgd2hlbiBhIHRhZyBpcyB0cnVuY2F0ZWQgc2luY2UNCiAg ICAgIHRydW5jYXRpb24gY2hhbmdlcyB0aGUgc2VtYW50aWMgbWVhbmluZyBvZiB0aGUgdGFnLg0K DQogICAgICBJbXBsZW1lbnRhdGlvbnMgb2YgcHJvdG9jb2xzIG9yIHNwZWNpZmljYXRpb25zIHRo YXQgYXJlIHNwYWNlDQogICAgICBjb25zdHJhaW5lZCBidXQgZG8gbm90IGhhdmUgYSBmaXhlZCBs aW1pdCBTSE9VTEQgdXNlIHRoZSBsb25nZXN0DQogICAgICBwb3NzaWJsZSB0YWcgaW4gcHJlZmVy ZW5jZSB0byB0cnVuY2F0aW9uLg0KDQogICAgICBQcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMg dGhhdCBzcGVjaWZ5IGxpbWl0ZWQgYnVmZmVyIHNpemVzIGZvcg0KICAgICAgbGFuZ3VhZ2UgdGFn cyBNVVNUIGFsbG93IGZvciBsYW5ndWFnZSB0YWdzIG9mIHVwIHRvIDMzIGNoYXJhY3RlcnMuDQoN CiAgICAgIFByb3RvY29scyBvciBzcGVjaWZpY2F0aW9ucyB0aGF0IHNwZWNpZnkgbGltaXRlZCBi dWZmZXIgc2l6ZXMgZm9yDQogICAgICBsYW5ndWFnZSB0YWdzIFNIT1VMRCBhbGxvdyBmb3IgbGFu Z3VhZ2UgdGFncyBvZiBhdCBsZWFzdCA0Mg0KICAgICAgY2hhcmFjdGVycy4NCg0KICAgVGhlIGZv bGxvd2luZyBpbGx1c3RyYXRpb24gc2hvd3MgaG93IHRoZSA0Mi1jaGFyYWN0ZXIgcmVjb21tZW5k YXRpb24NCiAgIHdhcyBkZXJpdmVkLiAgVGhlIGNvbWJpbmF0aW9uIG9mIGxhbmd1YWdlIGFuZCBl eHRlbmRlZCBsYW5ndWFnZQ0KICAgc3VidGFncyB3YXMgY2hvc2VuIGZvciBmdXR1cmUgY29tcGF0 aWJpbGl0eS4gIEF0IHVwIHRvIDE1IGNoYXJhY3RlcnMsDQogICB0aGlzIGNvbWJpbmF0aW9uIGlz IGxvbmdlciB0aGFuIHRoZSBsb25nZXN0IHBvc3NpYmxlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgIHN1 YnRhZyAoOCBjaGFyYWN0ZXJzKToNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDQxXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgbGFuZ3VhZ2UgICAgICA9ICAzIChJU08gNjM5LTI7 IElTTyA2MzktMSByZXF1aXJlcyAyKQ0KICAgZXh0bGFuZzEgICAgICA9ICA0IChlYWNoIHN1YnNl cXVlbnQgc3VidGFnIGluY2x1ZGVzICctJykNCiAgIGV4dGxhbmcyICAgICAgPSAgNCAodW5saWtl bHk6IG5lZWRzIHByZWZpeD0ibGFuZ3VhZ2UtZXh0bGFuZzEiKQ0KICAgZXh0bGFuZzMgICAgICA9 ICA0IChleHRyZW1lbHkgdW5saWtlbHkpDQogICBzY3JpcHQgICAgICAgID0gIDUgKGlmIG5vdCBz dXBwcmVzc2VkOiBzZWUgU2VjdGlvbiA0LjEpDQogICByZWdpb24gICAgICAgID0gIDQgKFVOIE0u NDk7IElTTyAzMTY2IHJlcXVpcmVzIDMpDQogICB2YXJpYW50MSAgICAgID0gIDkgKE1VU1QgaGF2 ZSBsYW5ndWFnZSBhcyBhIHByZWZpeCkNCiAgIHZhcmlhbnQyICAgICAgPSAgOSAoTVVTVCBoYXZl IGxhbmd1YWdlLXZhcmlhbnQxIGFzIGEgcHJlZml4KQ0KDQogICB0b3RhbCAgICAgICAgID0gNDIg Y2hhcmFjdGVycw0KDQogICAgICAgICAgICAgIEZpZ3VyZSA3OiBEZXJpdmF0aW9uIG9mIHRoZSBM aW1pdCBvbiBUYWcgTGVuZ3RoDQoNCg0KNC4zLjIgIFRydW5jYXRpb24gb2YgTGFuZ3VhZ2UgVGFn cw0KDQogICBUcnVuY2F0aW9uIG9mIGEgbGFuZ3VhZ2UgdGFnIGFsdGVycyB0aGUgbWVhbmluZyBv ZiB0aGUgdGFnLCBhbmQgdGh1cw0KICAgU0hPVUxEIGJlIGF2b2lkZWQuICBIb3dldmVyLCB0cnVu Y2F0aW9uIG9mIGxhbmd1YWdlIHRhZ3MgaXMgc29tZXRpbWVzDQogICBuZWNlc3NhcnkgZHVlIHRv IGxpbWl0ZWQgYnVmZmVyIHNpemVzLiAgU3VjaCB0cnVuY2F0aW9uIE1VU1QgTk9UDQogICBwZXJt aXQgYSBzdWJ0YWcgdG8gYmUgY2hvcHBlZCBvZmYgaW4gdGhlIG1pZGRsZSBvciB0aGUgZm9ybWF0 aW9uIG9mDQogICBpbnZhbGlkIHRhZ3MgKGZvciBleGFtcGxlLCBvbmUgZW5kaW5nIHdpdGggdGhl ICItIiBjaGFyYWN0ZXIpLg0KDQogICBUaGlzIG1lYW5zIHRoYXQgYXBwbGljYXRpb25zIG9yIHBy b3RvY29scyB3aGljaCB0cnVuY2F0ZSB0YWdzIE1VU1QgZG8NCiAgIHNvIGJ5IHByb2dyZXNzaXZl bHkgcmVtb3Zpbmcgc3VidGFncyBhbG9uZyB3aXRoIHRoZWlyIHByZWNlZGluZyAiLSINCiAgIGZy b20gdGhlIHJpZ2h0IHNpZGUgb2YgdGhlIGxhbmd1YWdlIHRhZyB1bnRpbCB0aGUgdGFnIGlzIHNo b3J0IGVub3VnaA0KICAgZm9yIHRoZSBnaXZlbiBidWZmZXIuICBJZiB0aGUgcmVzdWx0aW5nIHRh ZyBlbmRzIHdpdGggYSBzaW5nbGUtDQogICBjaGFyYWN0ZXIgc3VidGFnLCB0aGF0IHN1YnRhZyBh bmQgaXRzIHByZWNlZGluZyAiLSIgTVVTVCBhbHNvIGJlDQogICByZW1vdmVkLiAgRm9yIGV4YW1w bGU6DQoNCiAgIFRhZyB0byB0cnVuY2F0ZTogemgtSGFudC1DTi12YXJpYW50MS1hLWV4dGVuZDEt eC13YWRlZ2lsZS1wcml2YXRlMQ0KICAgMS4gemgtTGF0bi1DTi12YXJpYW50MS1hLWV4dGVuZDEt eC13YWRlZ2lsZQ0KICAgMi4gemgtTGF0bi1DTi12YXJpYW50MS1hLWV4dGVuZDENCiAgIDMuIHpo LUxhdG4tQ04tdmFyaWFudDENCiAgIDQuIHpoLUxhdG4tQ04NCiAgIDUuIHpoLUxhdG4NCiAgIDYu IHpoDQoNCiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDg6IEV4YW1wbGUgb2YgVGFnIFRydW5j YXRpb24NCg0KDQo0LjQgIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0KDQogICBT aW5jZSBhIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgdGFnIGlzIHNvbWV0aW1lcyB1c2VkIGJ5IG1hbnkg cHJvY2Vzc2VzLA0KICAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWx3YXlzIGJlIGNyZWF0ZWQgb3Ig Z2VuZXJhdGVkIGluIGEgY2Fub25pY2FsDQogICBmb3JtLg0KDQogICBBIGxhbmd1YWdlIHRhZyBp cyBpbiBjYW5vbmljYWwgZm9ybSB3aGVuOg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA0Ml0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICBBdWd1c3QgMjAwNQ0KDQoNCiAgIDEuICBUaGUgdGFnIGlzIHdlbGwtZm9ybWVkIGFjY29yZGlu ZyB0aGUgcnVsZXMgaW4gU2VjdGlvbiAyLjEgYW5kDQogICAgICAgU2VjdGlvbiAyLjIuDQoNCiAg IDIuICBTdWJ0YWdzIG9mIHR5cGUgJ1JlZ2lvbicgdGhhdCBoYXZlIGEgUHJlZmVycmVkLVZhbHVl IG1hcHBpbmcgaW4NCiAgICAgICB0aGUgSUFOQSByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4xKSBT SE9VTEQgYmUgcmVwbGFjZWQgd2l0aCB0aGVpcg0KICAgICAgIG1hcHBlZCB2YWx1ZS4gIE5vdGU6 IEluIHJhcmUgY2FzZXMgdGhlIG1hcHBlZCB2YWx1ZSB3aWxsIGFsc28NCiAgICAgICBoYXZlIGEg UHJlZmVycmVkLVZhbHVlLg0KDQogICAzLiAgUmVkdW5kYW50IG9yIGdyYW5kZmF0aGVyZWQgdGFn cyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUNCiAgICAgICBtYXBwaW5nIGluIHRoZSBJQU5B IHJlZ2lzdHJ5IChzZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFjZWQNCiAgICAgICB3aXRo IHRoZWlyIG1hcHBlZCB2YWx1ZS4gIFRoZXNlIGl0ZW1zIGFyZSBlaXRoZXIgZGVwcmVjYXRlZA0K ICAgICAgIG1hcHBpbmdzIGNyZWF0ZWQgYmVmb3JlIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3Vt ZW50IChzdWNoIGFzDQogICAgICAgdGhlIG1hcHBpbmcgb2YgIm5vLW55biIgdG8gIm5uIiBvciAi aS1rbGluZ29uIiB0byAidGxoIikgb3IgYXJlDQogICAgICAgdGhlIHJlc3VsdCBvZiBsYXRlciBy ZWdpc3RyYXRpb25zIG9yIGFkZGl0aW9ucyB0byB0aGlzIGRvY3VtZW50DQogICAgICAgKGZvciBl eGFtcGxlLCAiemgtZ3VveXUiIG1pZ2h0IGJlIG1hcHBlZCB0byBhIGxhbmd1YWdlLWV4dGxhbmcN CiAgICAgICBjb21iaW5hdGlvbiBzdWNoIGFzICJ6aC1jbW4iIGJ5IHNvbWUgZnV0dXJlIHVwZGF0 ZSBvZiB0aGlzDQogICAgICAgZG9jdW1lbnQpLg0KDQogICA0LiAgT3RoZXIgc3VidGFncyB0aGF0 IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUgbWFwcGluZyBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lz dHJ5IChzZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwZWQN CiAgICAgICB2YWx1ZS4gIFRoZXNlIGl0ZW1zIGNvbnNpc3QgZW50aXJlbHkgb2YgY2xlcmljYWwg Y29ycmVjdGlvbnMgdG8NCiAgICAgICBJU08gNjM5LTEgaW4gd2hpY2ggdGhlIGRlcHJlY2F0ZWQg c3VidGFncyBoYXZlIGJlZW4gbWFpbnRhaW5lZA0KICAgICAgIGZvciBjb21wYXRpYmlsaXR5IHB1 cnBvc2VzLg0KDQogICA1LiAgSWYgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24gc3VidGFnIHNlcXVl bmNlIGV4aXN0cywgdGhlIGV4dGVuc2lvbg0KICAgICAgIHNlcXVlbmNlcyBhcmUgb3JkZXJlZCBp bnRvIGNhc2UtaW5zZW5zaXRpdmUgQVNDSUkgb3JkZXIgYnkNCiAgICAgICBzaW5nbGV0b24gc3Vi dGFnLg0KDQogICBFeGFtcGxlOiBUaGUgbGFuZ3VhZ2UgdGFnICJlbi1BLWFhYS1CLWNjYy1iYmIt eC14eXoiIGlzIGluIGNhbm9uaWNhbA0KICAgZm9ybSwgd2hpbGUgImVuLUItY2NjLWJiYi1BLWFh YS1YLXh5eiIgaXMgd2VsbC1mb3JtZWQgYnV0IG5vdCBpbg0KICAgY2Fub25pY2FsIGZvcm0uDQoN CiAgIEV4YW1wbGU6IFRoZSBsYW5ndWFnZSB0YWcgImVuLUJVIiAoRW5nbGlzaCBhcyB1c2VkIGlu IEJ1cm1hKSBpcyBub3QNCiAgIGNhbm9uaWNhbCBiZWNhdXNlIHRoZSAnQlUnIHN1YnRhZyBoYXMg YSBjYW5vbmljYWwgbWFwcGluZyB0byAnTU0nDQogICAoTXlhbm1hciksIGFsdGhvdWdoIHRoZSB0 YWcgImVuLUJVIiBtYWludGFpbnMgaXRzIHZhbGlkaXR5Lg0KDQogICBDYW5vbmljYWxpemF0aW9u IG9mIGxhbmd1YWdlIHRhZ3MgZG9lcyBub3QgaW1wbHkgYW55dGhpbmcgYWJvdXQgdGhlDQogICB1 c2Ugb2YgdXBwZXIgb3IgbG93ZXJjYXNlIGxldHRlcnMgd2hlbiBwcm9jZXNzaW5nIG9yIGNvbXBh cmluZw0KICAgc3VidGFncyAoYW5kIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMSkuICBBbGwg Y29tcGFyaXNvbnMgTVVTVCBiZQ0KICAgcGVyZm9ybWVkIGluIGEgY2FzZS1pbnNlbnNpdGl2ZSBt YW5uZXIuDQoNCiAgIFdoZW4gcGVyZm9ybWluZyBjYW5vbmljYWxpemF0aW9uIG9mIGxhbmd1YWdl IHRhZ3MsIHByb2Nlc3NvcnMgTUFZDQogICByZWd1bGFyaXplIHRoZSBjYXNlIG9mIHRoZSBzdWJ0 YWdzICh0aGF0IGlzLCB0aGlzIHByb2Nlc3MgaXMNCiAgIE9QVElPTkFMKSwgZm9sbG93aW5nIHRo ZSBjYXNlIHVzZWQgaW4gdGhlIHJlZ2lzdHJ5LiAgTm90ZSB0aGF0IHRoaXMNCiAgIGNvcnJlc3Bv bmRzIHRvIHRoZSBmb2xsb3dpbmcgY2FzaW5nIHJ1bGVzOiB1cHBlcmNhc2UgYWxsIG5vbi1pbml0 aWFsDQogICB0d28tbGV0dGVyIHN1YnRhZ3M7IHRpdGxlY2FzZSBhbGwgbm9uLWluaXRpYWwgZm91 ci1sZXR0ZXIgc3VidGFnczsNCiAgIGxvd2VyY2FzZSBldmVyeXRoaW5nIGVsc2UuDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAg ICAgICAgIFtQYWdlIDQzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgTm90ZTogQ2FzZSBm b2xkaW5nIG9mIEFTQ0lJIGxldHRlcnMgaW4gY2VydGFpbiBsb2NhbGVzLCB1bmxlc3MNCiAgIGNh cmVmdWxseSBoYW5kbGVkLCBzb21ldGltZXMgcHJvZHVjZXMgbm9uLUFTQ0lJIGNoYXJhY3RlciB2 YWx1ZXMuDQogICBUaGUgVW5pY29kZSBDaGFyYWN0ZXIgRGF0YWJhc2UgZmlsZSAiU3BlY2lhbENh c2luZy50eHQiIGRlZmluZXMgdGhlDQogICBzcGVjaWZpYyBjYXNlcyB0aGF0IGFyZSBrbm93biB0 byBjYXVzZSBwcm9ibGVtcyB3aXRoIHRoaXMuICBJbg0KICAgcGFydGljdWxhciwgdGhlIGxldHRl ciAnaScgKFUrMDA2OSkgaW4gVHVya2lzaCBhbmQgQXplcmJhaWphbmkgaXMNCiAgIHVwcGVyY2Fz ZWQgdG8gVSswMTMwIChMQVRJTiBDQVBJVEFMIExFVFRFUiBJIFdJVEggRE9UIEFCT1ZFKS4NCiAg IEltcGxlbWVudGVycyBTSE9VTEQgc3BlY2lmeSBhIGxvY2FsZS1uZXV0cmFsIGNhc2luZyBvcGVy YXRpb24gdG8NCiAgIGVuc3VyZSB0aGF0IGNhc2UgZm9sZGluZyBvZiBzdWJ0YWdzIGRvZXMgbm90 IHByb2R1Y2UgdGhpcyB2YWx1ZSwNCiAgIHdoaWNoIGlzIGlsbGVnYWwgaW4gbGFuZ3VhZ2UgdGFn cy4gIEZvciBleGFtcGxlLCBpZiBvbmUgd2VyZSB0bw0KICAgdXBwZXJjYXNlIHRoZSByZWdpb24g c3VidGFnICdpbicgdXNpbmcgVHVya2lzaCBsb2NhbGUgcnVsZXMsIHRoZQ0KICAgc2VxdWVuY2Ug VSswMTMwIFUrMDA0RSB3b3VsZCByZXN1bHQgaW5zdGVhZCBvZiB0aGUgZXhwZWN0ZWQgJ0lOJy4N Cg0KICAgTm90ZTogaWYgdGhlIGZpZWxkICdEZXByZWNhdGVkJyBhcHBlYXJzIGluIGEgcmVnaXN0 cnkgcmVjb3JkIHdpdGhvdXQNCiAgIGFuIGFjY29tcGFueWluZyAnUHJlZmVycmVkLVZhbHVlJyBm aWVsZCwgdGhlbiB0aGF0IHRhZyBvciBzdWJ0YWcgaXMNCiAgIGRlcHJlY2F0ZWQgd2l0aG91dCBh IHJlcGxhY2VtZW50LiAgVmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VMRCBOT1QNCiAgIGdlbmVy YXRlIHRhZ3MgdGhhdCBpbmNsdWRlIHRoZXNlIHZhbHVlcywgYWx0aG91Z2ggdGhlIHZhbHVlcyBh cmUNCiAgIGNhbm9uaWNhbCB3aGVuIHRoZXkgYXBwZWFyIGluIGEgbGFuZ3VhZ2UgdGFnLg0KDQog ICBBbiBleHRlbnNpb24gTVVTVCBkZWZpbmUgYW55IHJlbGF0aW9uc2hpcHMgdGhhdCBleGlzdCBi ZXR3ZWVuIHRoZQ0KICAgdmFyaW91cyBzdWJ0YWdzIGluIHRoZSBleHRlbnNpb24gYW5kIHRodXMg TUFZIGRlZmluZSBhbiBhbHRlcm5hdGUNCiAgIGNhbm9uaWNhbGl6YXRpb24gc2NoZW1lIGZvciB0 aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncy4gIEV4dGVuc2lvbnMgTUFZDQogICBkZWZpbmUgaG93IHRo ZSBvcmRlciBvZiB0aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncyBhcmUgaW50ZXJwcmV0ZWQuICBGb3IN CiAgIGV4YW1wbGUsIGFuIGV4dGVuc2lvbiBjb3VsZCBkZWZpbmUgdGhhdCBpdHMgc3VidGFncyBh cmUgaW4gY2Fub25pY2FsDQogICBvcmRlciB3aGVuIHRoZSBzdWJ0YWdzIGFyZSBwbGFjZWQgaW50 byBBU0NJSSBvcmRlcjogdGhhdCBpcywgImVuLWEtDQogICBhYWEtYmJiLWNjYyIgaW5zdGVhZCBv ZiAiZW4tYS1jY2MtYmJiLWFhYSIuICBBbm90aGVyIGV4dGVuc2lvbiBtaWdodA0KICAgZGVmaW5l IHRoYXQgdGhlIG9yZGVyIG9mIHRoZSBzdWJ0YWdzIGluZmx1ZW5jZXMgdGhlaXIgc2VtYW50aWMN CiAgIG1lYW5pbmcgKHNvIHRoYXQgImVuLWItY2NjLWJiYi1hYWEiIGhhcyBhIGRpZmZlcmVudCB2 YWx1ZSBmcm9tICJlbi1iLQ0KICAgYWFhLWJiYi1jY2MiKS4gIEhvd2V2ZXIsIGV4dGVuc2lvbiBz cGVjaWZpY2F0aW9ucyBTSE9VTEQgYmUgZGVzaWduZWQNCiAgIHNvIHRoYXQgdGhleSBhcmUgdG9s ZXJhbnQgb2YgdGhlIHR5cGljYWwgcHJvY2Vzc2VzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAz LjYuDQoNCjQuNSAgQ29uc2lkZXJhdGlvbnMgZm9yIFByaXZhdGUgVXNlIFN1YnRhZ3MNCg0KICAg UHJpdmF0ZSB1c2Ugc3VidGFncywgbGlrZSBhbGwgb3RoZXIgc3VidGFncywgTVVTVCBjb25mb3Jt IHRvIHRoZQ0KICAgZm9ybWF0IGFuZCBjb250ZW50IGNvbnN0cmFpbnRzIGluIHRoZSBBQk5GLiAg UHJpdmF0ZSB1c2Ugc3VidGFncyBoYXZlDQogICBubyBtZWFuaW5nIG91dHNpZGUgdGhlIHByaXZh dGUgYWdyZWVtZW50IGJldHdlZW4gdGhlIHBhcnRpZXMgdGhhdA0KICAgaW50ZW5kIHRvIHVzZSBv ciBleGNoYW5nZSBsYW5ndWFnZSB0YWdzIHRoYXQgZW1wbG95IHRoZW0uICBUaGUgc2FtZQ0KICAg c3VidGFncyBNQVkgYmUgdXNlZCB3aXRoIGEgZGlmZmVyZW50IG1lYW5pbmcgdW5kZXIgYSBzZXBh cmF0ZSBwcml2YXRlDQogICBhZ3JlZW1lbnQuICBUaGV5IFNIT1VMRCBOT1QgYmUgdXNlZCB3aGVy ZSBhbHRlcm5hdGl2ZXMgZXhpc3QgYW5kDQogICBTSE9VTEQgTk9UIGJlIHVzZWQgaW4gY29udGVu dCBvciBwcm90b2NvbHMgaW50ZW5kZWQgZm9yIGdlbmVyYWwgdXNlLg0KDQogICBQcml2YXRlIHVz ZSBzdWJ0YWdzIGFyZSBzaW1wbHkgdXNlbGVzcyBmb3IgaW5mb3JtYXRpb24gZXhjaGFuZ2UNCiAg IHdpdGhvdXQgcHJpb3IgYXJyYW5nZW1lbnQuICBUaGUgdmFsdWUgYW5kIHNlbWFudGljIG1lYW5p bmcgb2YgcHJpdmF0ZQ0KICAgdXNlIHRhZ3MgYW5kIG9mIHRoZSBzdWJ0YWdzIHVzZWQgd2l0aGlu IHN1Y2ggYSBsYW5ndWFnZSB0YWcgYXJlIG5vdA0KICAgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50 Lg0KDQogICBTdWJ0YWdzIGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgaGF2aW5nIGEg c3BlY2lmaWMgcHJpdmF0ZSB1c2UNCiAgIG1lYW5pbmcgY29udmV5IG1vcmUgaW5mb3JtYXRpb24g dGhhdCBhIHB1cmVseSBwcml2YXRlIHVzZSB0YWcNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDQ0XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgcHJlZml4ZWQgYnkgdGhlIHNpbmdsZXRvbiBzdWJ0YWcg J3gnLiAgRm9yIGFwcGxpY2F0aW9ucyB0aGlzDQogICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIE1B WSBiZSB1c2VmdWwuDQoNCiAgIEZvciBleGFtcGxlLCB0aGUgcmVnaW9uIHN1YnRhZ3MgJ0FBJywg J1paJyBhbmQgaW4gdGhlIHJhbmdlcw0KICAgJ1FNJy0nUVonIGFuZCAnWEEnLSdYWicgKGRlcml2 ZWQgZnJvbSBJU08gMzE2NiBwcml2YXRlIHVzZSBjb2RlcykgTUFZDQogICBiZSB1c2VkIHRvIGZv cm0gYSBsYW5ndWFnZSB0YWcuICBBIHRhZyBzdWNoIGFzICJ6aC1IYW5zLVhRIiBjb252ZXlzIGEN CiAgIGdyZWF0IGRlYWwgb2YgcHVibGljLCBpbnRlcmNoYW5nZWFibGUgaW5mb3JtYXRpb24gYWJv dXQgdGhlIGxhbmd1YWdlDQogICBtYXRlcmlhbCAodGhhdCBpdCBpcyBDaGluZXNlIGluIHRoZSBz aW1wbGlmaWVkIENoaW5lc2Ugc2NyaXB0IGFuZCBpcw0KICAgc3VpdGFibGUgZm9yIHNvbWUgZ2Vv Z3JhcGhpYyByZWdpb24gJ1hRJykuICBXaGlsZSB0aGUgcHJlY2lzZQ0KICAgZ2VvZ3JhcGhpYyBy ZWdpb24gaXMgbm90IGtub3duIG91dHNpZGUgb2YgcHJpdmF0ZSBhZ3JlZW1lbnQsIHRoZSB0YWcN CiAgIGNvbnZleXMgZmFyIG1vcmUgaW5mb3JtYXRpb24gdGhhbiBhbiBvcGFxdWUgdGFnIHN1Y2gg YXMgIngtc29tZUxhbmciLA0KICAgd2hpY2ggY29udGFpbnMgbm8gaW5mb3JtYXRpb24gYWJvdXQg dGhlIGxhbmd1YWdlIHN1YnRhZyBvciBzY3JpcHQNCiAgIHN1YnRhZyBvdXRzaWRlIG9mIHRoZSBw cml2YXRlIGFncmVlbWVudC4NCg0KICAgSG93ZXZlciwgaW4gc29tZSBjYXNlcyBjb250ZW50IHRh Z2dlZCB3aXRoIHByaXZhdGUgdXNlIHN1YnRhZ3MgTUFZDQogICBpbnRlcmFjdCB3aXRoIG90aGVy IHN5c3RlbXMgaW4gYSBkaWZmZXJlbnQgYW5kIHBvc3NpYmx5IHVuc3VpdGFibGUNCiAgIG1hbm5l ciBjb21wYXJlZCB0byB0YWdzIHRoYXQgdXNlIG9wYXF1ZSwgcHJpdmF0ZWx5IGRlZmluZWQgc3Vi dGFncywNCiAgIHNvIHRoZSBjaG9pY2Ugb2YgdGhlIGJlc3QgYXBwcm9hY2ggc29tZXRpbWVzIGRl cGVuZHMgb24gdGhlDQogICBwYXJ0aWN1bGFyIGRvbWFpbiBpbiBxdWVzdGlvbi4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAg ICAgICBbUGFnZSA0NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCjUuICBJQU5BIENvbnNpZGVy YXRpb25zDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWFscyB3aXRoIHRoZSBwcm9jZXNzZXMgYW5kIHJl cXVpcmVtZW50cyBuZWNlc3NhcnkgZm9yDQogICBJQU5BIHRvIHVuZGVydGFrZSB0byBtYWludGFp biB0aGUgc3VidGFnIGFuZCBleHRlbnNpb24gcmVnaXN0cmllcyBhcw0KICAgZGVmaW5lZCBieSB0 aGlzIGRvY3VtZW50IGFuZCBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIHJlcXVpcmVtZW50cyBvZg0K ICAgW1JGQzI0MzRdLg0KDQogICBUaGUgaW1wYWN0IG9uIHRoZSBJQU5BIG1haW50YWluZXJzIG9m IHRoZSB0d28gcmVnaXN0cmllcyBkZWZpbmVkIGJ5DQogICB0aGlzIGRvY3VtZW50IHdpbGwgYmUg YSBzbWFsbCBpbmNyZWFzZSBpbiB0aGUgZnJlcXVlbmN5IG9mIG5ldw0KICAgZW50cmllcyBvciB1 cGRhdGVzLg0KDQo1LjEgIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQ0KDQogICBVcG9uIGFkb3B0 aW9uIG9mIHRoaXMgZG9jdW1lbnQsIHRoZSByZWdpc3RyeSB3aWxsIGJlIGluaXRpYWxpemVkIGJ5 IGENCiAgIGNvbXBhbmlvbiBkb2N1bWVudDogW2luaXRpYWwtcmVnaXN0cnldLiAgVGhlIGNyaXRl cmlhIGFuZCBwcm9jZXNzIGZvcg0KICAgc2VsZWN0aW5nIHRoZSBpbml0aWFsIHNldCBvZiByZWNv cmRzIGlzIGRlc2NyaWJlZCBpbiB0aGF0IGRvY3VtZW50Lg0KICAgVGhlIGluaXRpYWwgc2V0IG9m IHJlY29yZHMgcmVwcmVzZW50cyBubyBpbXBhY3Qgb24gSUFOQSwgc2luY2UgdGhlDQogICB3b3Jr IHRvIGNyZWF0ZSBpdCB3aWxsIGJlIHBlcmZvcm1lZCBleHRlcm5hbGx5Lg0KDQogICBUaGUgbmV3 IHJlZ2lzdHJ5IE1VU1QgYmUgbGlzdGVkIHVuZGVyICJMYW5ndWFnZSBUYWdzIiBhdA0KICAgPGh0 dHA6Ly93d3cuaWFuYS5vcmcvbnVtYmVycy5odG1sPiwgcmVwbGFjaW5nIHRoZSBleGlzdGluZw0K ICAgcmVnaXN0cmF0aW9ucyBkZWZpbmVkIGJ5IFtSRkMzMDY2XS4gIFRoZSBleGlzdGluZyBzZXQg b2YgcmVnaXN0cmF0aW9uDQogICBmb3JtcyBhbmQgUkZDIDMwNjYgcmVnaXN0cmF0aW9ucyBNVVNU IGJlIHJlbGFiZWxlZCBhcyAiTGFuZ3VhZ2UgVGFncw0KICAgKE9ic29sZXRlKSIgYW5kIG1haW50 YWluZWQgKGJ1dCBub3QgYWRkZWQgdG8gb3IgbW9kaWZpZWQpLg0KDQogICBGdXR1cmUgd29yayBv biB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IFNIQUxMIGJlIGxpbWl0ZWQgdG8NCiAgIGlu c2VydGluZyBvciByZXBsYWNpbmcgd2hvbGUgcmVjb3JkcyBwcmVmb3JtYXR0ZWQgZm9yIElBTkEg YnkgdGhlDQogICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gMy4yIG9mIHRoaXMNCiAgIGRvY3VtZW50LiAgVGhpcyBzaW1wbGlmaWVzIElBTkEncyB3b3Jr IGJ5IGxpbWl0aW5nIGl0IHRvIHBsYWNpbmcgdGhlDQogICB0ZXh0IGluIHRoZSBhcHByb3ByaWF0 ZSBsb2NhdGlvbiBpbiB0aGUgcmVnaXN0cnkuDQoNCiAgIEVhY2ggcmVjb3JkIE1VU1QgYmUgc2Vu dCB0byBpYW5hQGlhbmEub3JnIHdpdGggYSBzdWJqZWN0IGxpbmUNCiAgIGluZGljYXRpbmcgd2hl dGhlciB0aGUgZW5jbG9zZWQgcmVjb3JkIGlzIGFuIGluc2VydGlvbiBvZiBhIG5ldw0KICAgcmVj b3JkIChpbmRpY2F0ZWQgYnkgdGhlIHdvcmQgIklOU0VSVCIgaW4gdGhlIHN1YmplY3QgbGluZSkg b3IgYQ0KICAgcmVwbGFjZW1lbnQgb2YgYW4gZXhpc3RpbmcgcmVjb3JkIChpbmRpY2F0ZWQgYnkg dGhlIHdvcmQgIk1PRElGWSIgaW4NCiAgIHRoZSBzdWJqZWN0IGxpbmUpLiAgUmVjb3JkcyBNVVNU IE5PVCBiZSBkZWxldGVkIGZyb20gdGhlIHJlZ2lzdHJ5Lg0KICAgSUFOQSBNVVNUIHBsYWNlIGFu eSBpbnNlcnRlZCBvciBtb2RpZmllZCByZWNvcmRzIGludG8gdGhlIGFwcHJvcHJpYXRlDQogICBz ZWN0aW9uIG9mIHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnksIGdyb3VwaW5nIHRoZSByZWNv cmRzIGJ5DQogICB0aGVpciAnVHlwZScgZmllbGQuICBJbnNlcnRlZCByZWNvcmRzIE1BWSBiZSBw bGFjZWQgYW55d2hlcmUgaW4gdGhlDQogICBhcHByb3ByaWF0ZSBzZWN0aW9uOyB0aGVyZSBpcyBu byBndWFyYW50ZWUgb2YgdGhlIG9yZGVyIG9mIHRoZQ0KICAgcmVjb3JkcyBiZXlvbmQgZ3JvdXBp bmcgdGhlbSB0b2dldGhlciBieSAnVHlwZScuICBNb2RpZmllZCByZWNvcmRzDQogICBNVVNUIG92 ZXJ3cml0ZSB0aGUgcmVjb3JkIHRoZXkgcmVwbGFjZS4NCg0KICAgSW5jbHVkZWQgaW4gYW55IHJl cXVlc3QgdG8gaW5zZXJ0IG9yIG1vZGlmeSByZWNvcmRzIE1VU1QgYmUgYSBuZXcNCiAgIEZpbGUt RGF0ZSByZWNvcmQuICBUaGlzIHJlY29yZCBNVVNUIGJlIHBsYWNlZCBmaXJzdCBpbiB0aGUgcmVn aXN0cnkuDQogICBJbiB0aGUgZXZlbnQgdGhhdCB0aGUgRmlsZS1EYXRlIHJlY29yZCBwcmVzZW50 IGluIHRoZSByZWdpc3RyeSBoYXMgYQ0KICAgbGF0ZXIgZGF0ZSB0aGVuIHRoZSByZWNvcmQgYmVp bmcgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQsIHRoZSBleGlzdGluZw0KICAgcmVjb3JkIE1VU1QgYmUg cHJlc2VydmVkLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFy eSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0K DQo1LjIgIEV4dGVuc2lvbnMgUmVnaXN0cnkNCg0KICAgVGhlIExhbmd1YWdlIFRhZyBFeHRlbnNp b25zIHJlZ2lzdHJ5IHdpbGwgYWxzbyBiZSBnZW5lcmF0ZWQgYW5kIHNlbnQNCiAgIHRvIElBTkEg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy42LiAgVGhpcyByZWdpc3RyeSBjYW4gY29udGFpbiBh dA0KICAgbW9zdCAzNSByZWNvcmRzIGFuZCB0aHVzIGNoYW5nZXMgdG8gdGhpcyByZWdpc3RyeSBh cmUgZXhwZWN0ZWQgdG8gYmUNCiAgIHZlcnkgaW5mcmVxdWVudC4NCg0KICAgRnV0dXJlIHdvcmsg YnkgSUFOQSBvbiB0aGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgUmVnaXN0cnkgaXMNCiAgIGxp bWl0ZWQgdG8gdHdvIGNhc2VzLiAgRmlyc3QsIHRoZSBJRVNHIE1BWSByZXF1ZXN0IHRoYXQgbmV3 IHJlY29yZHMNCiAgIGJlIGluc2VydGVkIGludG8gdGhpcyByZWdpc3RyeSBmcm9tIHRpbWUgdG8g dGltZS4gIFRoZXNlIHJlcXVlc3RzDQogICBNVVNUIGluY2x1ZGUgdGhlIHJlY29yZCB0byBpbnNl cnQgaW4gdGhlIGV4YWN0IGZvcm1hdCBkZXNjcmliZWQgaW4NCiAgIFNlY3Rpb24gMy42LiAgSW4g YWRkaXRpb24sIHRoZXJlIE1BWSBiZSBvY2Nhc2lvbmFsIHJlcXVlc3RzIGZyb20gdGhlDQogICBt YWludGFpbmluZyBhdXRob3JpdHkgZm9yIGEgc3BlY2lmaWMgZXh0ZW5zaW9uIHRvIHVwZGF0ZSB0 aGUgY29udGFjdA0KICAgaW5mb3JtYXRpb24gb3IgVVJMcyBpbiB0aGUgcmVjb3JkLiAgVGhlc2Ug cmVxdWVzdHMgTVVTVCBpbmNsdWRlIHRoZQ0KICAgY29tcGxldGUsIHVwZGF0ZWQgcmVjb3JkLiAg SUFOQSBpcyBub3QgcmVzcG9uc2libGUgZm9yIHZhbGlkYXRpbmcgdGhlDQogICBpbmZvcm1hdGlv biBwcm92aWRlZCwgb25seSB0aGF0IGl0IGlzIHByb3Blcmx5IGZvcm1hdHRlZC4gIEl0IHNob3Vs ZA0KICAgcmVhc29uYWJseSBiZSBzZWVuIHRvIGNvbWUgZnJvbSB0aGUgbWFpbnRhaW5pbmcgYXV0 aG9yaXR5IG5hbWVkIGluDQogICB0aGUgcmVjb3JkIHByZXNlbnQgaW4gdGhlIHJlZ2lzdHJ5Lg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2 ICAgICAgICAgICAgICAgW1BhZ2UgNDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQo2LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgTGFuZ3VhZ2UgdGFncyB1c2VkIGluIGNvbnRlbnQg bmVnb3RpYXRpb24sIGxpa2UgYW55IG90aGVyIGluZm9ybWF0aW9uDQogICBleGNoYW5nZWQgb24g dGhlIEludGVybmV0LCBtaWdodCBiZSBhIHNvdXJjZSBvZiBjb25jZXJuIGJlY2F1c2UgdGhleQ0K ICAgbWlnaHQgYmUgdXNlZCB0byBpbmZlciB0aGUgbmF0aW9uYWxpdHkgb2YgdGhlIHNlbmRlciwg YW5kIHRodXMNCiAgIGlkZW50aWZ5IHBvdGVudGlhbCB0YXJnZXRzIGZvciBzdXJ2ZWlsbGFuY2Uu DQoNCiAgIFRoaXMgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIGdlbmVyYWwgcHJvYmxlbSB0aGF0 IGFueXRoaW5nIHNlbnQgaXMNCiAgIHZpc2libGUgdG8gdGhlIHJlY2VpdmluZyBwYXJ0eSBhbmQg cG9zc2libHkgdG8gdGhpcmQgcGFydGllcyBhcyB3ZWxsLg0KICAgSXQgaXMgdXNlZnVsIHRvIGJl IGF3YXJlIHRoYXQgc3VjaCBjb25jZXJucyBjYW4gZXhpc3QgaW4gc29tZSBjYXNlcy4NCg0KICAg VGhlIGV2YWx1YXRpb24gb2YgdGhlIGV4YWN0IG1hZ25pdHVkZSBvZiB0aGUgdGhyZWF0LCBhbmQg YW55IHBvc3NpYmxlDQogICBjb3VudGVybWVhc3VyZXMsIGlzIGxlZnQgdG8gZWFjaCBhcHBsaWNh dGlvbiBwcm90b2NvbCAoc2VlIEJDUCA3Mg0KICAgW1JGQzM1NTJdIGZvciBiZXN0IGN1cnJlbnQg cHJhY3RpY2UgZ3VpZGFuY2Ugb24gc2VjdXJpdHkgdGhyZWF0cyBhbmQNCiAgIGRlZmVuc2VzKS4N Cg0KICAgVGhlIGxhbmd1YWdlIHRhZyBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIGluZm9y bWF0aW9uIGl0ZW0gaXMgb2YNCiAgIG5vIGNvbnNlcXVlbmNlIHdoYXRzb2V2ZXIgaW4gZGV0ZXJt aW5pbmcgd2hldGhlciB0aGF0IGNvbnRlbnQgbWlnaHQNCiAgIGNvbnRhaW4gcG9zc2libGUgaG9t b2dyYXBocy4gIFRoZSBmYWN0IHRoYXQgYSB0ZXh0IGlzIHRhZ2dlZCBhcyBiZWluZw0KICAgaW4g b25lIGxhbmd1YWdlIG9yIHVzaW5nIGEgcGFydGljdWxhciBzY3JpcHQgc3VidGFnIHByb3ZpZGVz IG5vDQogICBhc3N1cmFuY2Ugd2hhdHNvZXZlciB0aGF0IGl0IGRvZXMgbm90IGNvbnRhaW4gY2hh cmFjdGVycyBmcm9tIHNjcmlwdHMNCiAgIG90aGVyIHRoYW4gdGhlIG9uZShzKSBhc3NvY2lhdGVk IHdpdGggb3Igc3BlY2lmaWVkIGJ5IHRoYXQgbGFuZ3VhZ2UNCiAgIHRhZy4NCg0KICAgU2luY2Ug dGhlcmUgaXMgbm8gbGltaXQgdG8gdGhlIG51bWJlciBvZiB2YXJpYW50LCBwcml2YXRlIHVzZSwg YW5kDQogICBleHRlbnNpb24gc3VidGFncywgYW5kIGNvbnNlcXVlbnRseSBubyBsaW1pdCBvbiB0 aGUgcG9zc2libGUgbGVuZ3RoDQogICBvZiBhIHRhZywgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8g Z3VhcmQgYWdhaW5zdCBidWZmZXIgb3ZlcmZsb3cNCiAgIGF0dGFja3MuICBTZWUgU2VjdGlvbiA0 LjMgZm9yIGRldGFpbHMgb24gbGFuZ3VhZ2UgdGFnIHRydW5jYXRpb24sDQogICB3aGljaCBjYW4g b2NjdXIgYXMgYSBjb25zZXF1ZW5jZSBvZiBkZWZlbnNlcyBhZ2FpbnN0IGJ1ZmZlciBvdmVyZmxv dy4NCg0KICAgQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gb2YgdmFsaWQgc3VidGFncyBmb3Ig YW4gZXh0ZW5zaW9uIChzZWU6DQogICBTZWN0aW9uIDMuNikgTVVTVCBiZSBhdmFpbGFibGUgb3Zl ciB0aGUgSW50ZXJuZXQsIGltcGxlbWVudGF0aW9ucw0KICAgU0hPVUxEIE5PVCBtZWNoYW5pY2Fs bHkgZGVwZW5kIG9uIGl0IGJlaW5nIGFsd2F5cyBhY2Nlc3NpYmxlLCB0bw0KICAgcHJldmVudCBk ZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAg ICAgICAgICAgIFtQYWdlIDQ4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KNy4gIENoYXJhY3Rl ciBTZXQgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhlIHN5bnRheCBpbiB0aGlzIGRvY3VtZW50IHJl cXVpcmVzIHRoYXQgbGFuZ3VhZ2UgdGFncyB1c2Ugb25seSB0aGUNCiAgIGNoYXJhY3RlcnMgQS1a LCBhLXosIDAtOSwgYW5kIEhZUEhFTi1NSU5VUywgd2hpY2ggYXJlIHByZXNlbnQgaW4gbW9zdA0K ICAgY2hhcmFjdGVyIHNldHMsIHNvIHRoZSBjb21wb3NpdGlvbiBvZiBsYW5ndWFnZSB0YWdzIHNo b3VsZCBub3QgaGF2ZQ0KICAgYW55IGNoYXJhY3RlciBzZXQgaXNzdWVzLg0KDQogICBSZW5kZXJp bmcgb2YgY2hhcmFjdGVycyBiYXNlZCBvbiB0aGUgY29udGVudCBvZiBhIGxhbmd1YWdlIHRhZyBp cyBub3QNCiAgIGFkZHJlc3NlZCBpbiB0aGlzIG1lbW8uICBIaXN0b3JpY2FsbHksIHNvbWUgbGFu Z3VhZ2VzIGhhdmUgcmVsaWVkIG9uDQogICB0aGUgdXNlIG9mIHNwZWNpZmljIGNoYXJhY3RlciBz ZXRzIG9yIG90aGVyIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvDQogICBpbmZlciBob3cgYSBzcGVj aWZpYyBjaGFyYWN0ZXIgc2hvdWxkIGJlIHJlbmRlcmVkIChub3RhYmx5IHRoaXMNCiAgIGFwcGxp ZXMgdG8gbGFuZ3VhZ2UgYW5kIGN1bHR1cmUgc3BlY2lmaWMgdmFyaWF0aW9ucyBvZiBIYW4gaWRl b2dyYXBocw0KICAgYXMgdXNlZCBpbiBKYXBhbmVzZSwgQ2hpbmVzZSwgYW5kIEtvcmVhbikuICBX aGVuIGxhbmd1YWdlIHRhZ3MgYXJlDQogICBhcHBsaWVkIHRvIHNwYW5zIG9mIHRleHQsIHJlbmRl cmluZyBlbmdpbmVzIHNvbWV0aW1lcyB1c2UgdGhhdA0KICAgaW5mb3JtYXRpb24gaW4gZGVjaWRp bmcgd2hpY2ggZm9udCB0byB1c2UgaW4gdGhlIGFic2VuY2Ugb2Ygb3RoZXINCiAgIGluZm9ybWF0 aW9uLCBwYXJ0aWN1bGFybHkgd2hlcmUgbGFuZ3VhZ2VzIHdpdGggZGlzdGluY3Qgd3JpdGluZw0K ICAgdHJhZGl0aW9ucyB1c2UgdGhlIHNhbWUgY2hhcmFjdGVycy4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAg W1BhZ2UgNDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQo4LiAgQ2hhbmdlcyBmcm9tIFJGQyAz MDY2DQoNCiAgIFRoZSBtYWluIGdvYWxzIGZvciB0aGlzIHJldmlzaW9uIG9mIGxhbmd1YWdlIHRh Z3Mgd2VyZSB0aGUgZm9sbG93aW5nOg0KDQogICAqQ29tcGF0aWJpbGl0eS4qIEFsbCBSRkMgMzA2 NiBsYW5ndWFnZSB0YWdzICAoaW5jbHVkaW5nIHRob3NlIGluIHRoZQ0KICAgSUFOQSByZWdpc3Ry eSkgIHJlbWFpbiB2YWxpZCBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBUaGUgY2hhbmdlcyBpbg0K ICAgdGhpcyBkb2N1bWVudCByZXByZXNlbnQgYWRkaXRpb25hbCBjb25zdHJhaW50cyBvbiBsYW5n dWFnZSB0YWdzLg0KICAgVGhhdCBpcywgaW4gbm8gY2FzZSBpcyB0aGUgc3ludGF4IG1vcmUgcGVy bWlzc2l2ZSBhbmQgcHJvY2Vzc29ycw0KICAgYmFzZWQgb24gdGhlIEFCTkYgYW5kIG90aGVyIHBy b3Zpc2lvbnMgb2YgUkZDIDMwNjYgKHN1Y2ggYXMgdGhvc2UNCiAgIGRlc2NyaWJlZCBpbiBbWE1M U2NoZW1hXSkgd2lsbCBiZSBhYmxlIHRvIHByb2Nlc3MgdGhlIHRhZ3MgZGVzY3JpYmVkDQogICBi eSB0aGlzIGRvY3VtZW50LiAgSW4gYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBsYW5n dWFnZSB0YWdzDQogICBpbiBzdWNoIGFzIHdheSBhcyB0byBlbnN1cmUgZnV0dXJlIGNvbXBhdGli aWxpdHkuDQoNCiAgICpTdGFiaWxpdHkuKiBCZWNhdXNlIG9mIGNoYW5nZXMgaW4gdGhlIHBhc3Qg aW4gdGhlIHVuZGVybHlpbmcgSVNPDQogICBzdGFuZGFyZHMsIGEgdmFsaWQgUkZDIDMwNjYgbGFu Z3VhZ2UgdGFnIGNvdWxkIGJlY29tZSBpbnZhbGlkIG9yIGhhdmUNCiAgIGl0cyBtZWFuaW5nIGNo YW5nZS4gIFRoaXMgaGFzIHRoZSBwb3RlbnRpYWwgb2YgaW52YWxpZGF0aW5nIGNvbnRlbnQNCiAg IHRoYXQgbWF5IGhhdmUgYW4gZXh0ZW5zaXZlIHNoZWxmLWxpZmUuICBJbiB0aGlzIHNwZWNpZmlj YXRpb24sIG9uY2UgYQ0KICAgbGFuZ3VhZ2UgdGFnIGlzIHZhbGlkLCBpdCByZW1haW5zIHZhbGlk IGZvcmV2ZXIuDQoNCiAgICpWYWxpZGl0eS4qICBUaGUgc3RydWN0dXJlIG9mIGxhbmd1YWdlIHRh Z3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50DQogICBtYWtlcyBpdCBwb3NzaWJsZSB0byBkZXRl cm1pbmUgaWYgYSBwYXJ0aWN1bGFyIHRhZyBpcyB3ZWxsLWZvcm1lZA0KICAgd2l0aG91dCByZWdh cmQgZm9yIHRoZSBhY3R1YWwgY29udGVudCBvciAibWVhbmluZyIgb2YgdGhlIHRhZyBhcyBhDQog ICB3aG9sZS4gIFRoaXMgaXMgaW1wb3J0YW50IGJlY2F1c2UgdGhlIHJlZ2lzdHJ5IGdyb3dzIGFu ZCB1bmRlcmx5aW5nDQogICBzdGFuZGFyZHMgIGNoYW5nZSBvdmVyIHRpbWUuICBJbiBhZGRpdGlv biwgaXQgbXVzdCBiZSBwb3NzaWJsZSB0bw0KICAgZGV0ZXJtaW5lIGlmIGEgdGFnIGlzIHZhbGlk IChvciBub3QpIGZvciBhIGdpdmVuIHBvaW50IGluIHRpbWUgaW4NCiAgIG9yZGVyICB0byBwcm92 aWRlIHJlcHJvZHVjaWJsZSwgdGVzdGFibGUgcmVzdWx0cy4gIFRoaXMgcHJvY2VzcyBtdXN0DQog ICBub3QgYmUgZXJyb3ItcHJvbmU7IG90aGVyd2lzZSBpbXBsZW1lbnRhdGlvbnMgbWlnaHQgZ2l2 ZSBkaWZmZXJlbnQNCiAgIHJlc3VsdHMuICBCeSBoYXZpbmcgYW4gYXV0aG9yaXRhdGl2ZSByZWdp c3RyeSB3aXRoIHNwZWNpZmljDQogICB2ZXJzaW9uaW5nIGluZm9ybWF0aW9uLCB0aGUgdmFsaWRp dHkgb2YgbGFuZ3VhZ2UgdGFncyBhdCBhbnkgcG9pbnQgaW4NCiAgIHRpbWUgY2FuIGJlIHByZWNp c2VseSBkZXRlcm1pbmVkIChpbnN0ZWFkIG9mIGludGVycG9sYXRpbmcgdmFsdWVzDQogICBmcm9t IG1hbnkgc2VwYXJhdGUgc291cmNlcykuDQoNCiAgICpVdGlsaXR5LiogSXQgaXMgc29tZXRpbWVz IGltcG9ydGFudCB0byBiZSBhYmxlIHRvIGRpZmZlcmVudGlhdGUNCiAgIGJldHdlZW4gd3JpdHRl biBmb3JtcyBvZiBhIGxhbmd1YWdlIC0tIGZvciBtYW55IGltcGxlbWVudGF0aW9ucyB0aGlzDQog ICBpcyBtb3JlIGltcG9ydGFudCB0aGFuIGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gdGhlIHNwb2tl biB2YXJpYW50cyBvZg0KICAgYSBsYW5ndWFnZS4gIExhbmd1YWdlcyBhcmUgd3JpdHRlbiBpbiBh IHdpZGUgdmFyaWV0eSBvZiBkaWZmZXJlbnQNCiAgIHNjcmlwdHMsIHNvIHRoaXMgZG9jdW1lbnQg cHJvdmlkZXMgZm9yIHRoZSBnZW5lcmF0aXZlIHVzZSBvZiBJU08NCiAgIDE1OTI0IHNjcmlwdCBj b2Rlcy4gIExpa2UgdGhlIGdlbmVyYXRpdmUgdXNlIG9mIElTTyBsYW5ndWFnZSBhbmQNCiAgIGNv dW50cnkgY29kZXMgaW4gUkZDIDMwNjYsIHRoaXMgYWxsb3dzIGNvbWJpbmF0aW9ucyB0byBiZSBw cm9kdWNlZA0KICAgd2l0aG91dCByZXNvcnRpbmcgdG8gdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNz LiAgVGhlIGFkZGl0aW9uIG9mIFVODQogICBNLjQ5IGNvZGVzIHByb3ZpZGVzIGZvciB0aGUgZ2Vu ZXJhdGlvbiBvZiBsYW5ndWFnZSB0YWdzIHdpdGggcmVnaW9uYWwNCiAgIHNjb3BlLCB3aGljaCBp cyBhbHNvIHJlcXVpcmVkIGJ5IHNvbWUgYXBwbGljYXRpb25zLg0KDQogICBUaGUgcmVjYXN0IG9m IHRoZSByZWdpc3RyeSBmcm9tIGNvbnRhaW5pbmcgd2hvbGUgbGFuZ3VhZ2UgdGFncyB0bw0KICAg c3VidGFncyBpcyBhIGtleSBwYXJ0IG9mIHRoaXMuICBBbiBpbXBvcnRhbnQgZmVhdHVyZSBvZiBS RkMgMzA2NiB3YXMNCiAgIHRoYXQgaXQgYWxsb3dlZCBnZW5lcmF0aXZlIHVzZSBvZiBzdWJ0YWdz LiAgVGhpcyBhbGxvd3MgcGVvcGxlIHRvDQogICBtZWFuaW5nZnVsbHkgdXNlIGdlbmVyYXRlZCB0 YWdzLCB3aXRob3V0IHRoZSBkZWxheXMgaW4gcmVnaXN0ZXJpbmcNCiAgIHdob2xlIHRhZ3Mgb3Ig dGhlIG5lZWQgdG8gcmVnaXN0ZXIgYWxsIG9mIHRoZSBjb21iaW5hdGlvbnMgdGhhdCBtaWdodA0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAg ICAgICAgICAgICAgW1BhZ2UgNTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICBiZSB1c2Vm dWwuDQoNCiAgIFRoZSBjaG9pY2Ugb2YgcGxhY2luZyB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2UgYW5k IHNjcmlwdCBzdWJ0YWdzDQogICBiZXR3ZWVuIHRoZSBwcmltYXJ5IGxhbmd1YWdlIGFuZCByZWdp b24gc3VidGFncyB3YXMgd2lkZWx5IGRlYmF0ZWQuDQogICBUaGlzIGRlc2lnbiB3YXMgY2hvc2Vu IGJlY2F1c2UgdGhlIHByZXZhbGVudCBtYXRjaGluZyBhbmQgY29udGVudA0KICAgbmVnb3RpYXRp b24gc2NoZW1lcyByZWx5IG9uIHRoZSBzdWJ0YWdzIGJlaW5nIGFycmFuZ2VkIGluIG9yZGVyIG9m DQogICBpbmNyZWFzaW5nIHNwZWNpZmljaXR5LiAgVGhhdCBpcywgdGhlIHN1YnRhZ3MgdGhhdCBt YXJrIGEgZ3JlYXRlcg0KICAgYmFycmllciB0byBtdXR1YWwgaW50ZWxsaWdpYmlsaXR5IGFwcGVh ciBsZWZ0LW1vc3QgaW4gYSB0YWcuICBGb3INCiAgIGV4YW1wbGUsIHdoZW4gc2VsZWN0aW5nIGNv bnRlbnQgd3JpdHRlbiBpbiBBemVyYmFpamFuaSwgdGhlIHNjcmlwdA0KICAgKEFyYWJpYywgQ3ly aWxsaWMsIG9yIExhdGluKSByZXByZXNlbnRzIGEgZ3JlYXRlciBiYXJyaWVyIHRvDQogICB1bmRl cnN0YW5kaW5nIHRoYW4gYW55IHJlZ2lvbmFsIHZhcmlhdGlvbnMgKHRob3NlIGFzc29jaWF0ZWQg d2l0aA0KICAgQXplcmJhaWphbiBvciBJcmFuLCBmb3IgZXhhbXBsZSkuICBJbmRpdmlkdWFscyB3 aG8gcHJlZmVyIGRvY3VtZW50cw0KICAgaW4gYSBwYXJ0aWN1bGFyIHNjcmlwdCwgYnV0IGNhbiBk ZWFsIHdpdGggdGhlIG1pbm9yIHJlZ2lvbmFsDQogICBkaWZmZXJlbmNlcywgY2FuIHRoZXJlZm9y ZSBzZWxlY3QgYXBwcm9wcmlhdGUgY29udGVudC4gIEFwcGxpY2F0aW9ucw0KICAgdGhhdCBkbyBu b3QgZGVhbCB3aXRoIHdyaXR0ZW4gY29udGVudCB3aWxsIGNvbnRpbnVlIHRvIG9taXQgdGhlc2UN CiAgIHN1YnRhZ3MuDQoNCiAgICpFeHRlbnNpYmlsaXR5LiogQmVjYXVzZSBvZiB0aGUgd2lkZXNw cmVhZCB1c2Ugb2YgbGFuZ3VhZ2UgdGFncywgaXQNCiAgIGlzIGRpc3J1cHRpdmUgdG8gaGF2ZSBw ZXJpb2RpYyByZXZpc2lvbnMgb2YgdGhlIGNvcmUgc3BlY2lmaWNhdGlvbiwNCiAgIGV2ZW4gaW4g dGhlIGZhY2Ugb2YgZGVtb25zdHJhdGVkIG5lZWQuICBUaGUgZXh0ZW5zaW9uIG1lY2hhbmlzbQ0K ICAgcHJvdmlkZXMgZm9yIGEgd2F5IGZvciBpbmRlcGVuZGVudCBSRkNzIHRvIGRlZmluZSBleHRl bnNpb25zIHRvDQogICBsYW5ndWFnZSB0YWdzLiAgVGhlc2UgZXh0ZW5zaW9ucyBoYXZlIGEgdmVy eSBjb25zdHJhaW5lZCwgd2VsbC0NCiAgIGRlZmluZWQgc3RydWN0dXJlIHRoYXQgcHJldmVudCBl eHRlbnNpb25zIGZyb20gaW50ZXJmZXJpbmcgd2l0aA0KICAgaW1wbGVtZW50YXRpb25zIG9mIGxh bmd1YWdlIHRhZ3MgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBUaGUgZG9jdW1lbnQg YWxzbyBhbnRpY2lwYXRlcyBmZWF0dXJlcyBvZiBJU08gNjM5LTMgd2l0aCB0aGUgYWRkaXRpb24N CiAgIG9mIHRoZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzLCBhcyB3ZWxsIGFzIHRoZSBwb3Nz aWJpbGl0eSBvZiBvdGhlcg0KICAgSVNPIDYzOSBwYXJ0cyBiZWNvbWluZyB1c2VmdWwgZm9yIHRo ZSBmb3JtYXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBpbg0KICAgdGhlIGZ1dHVyZS4NCg0KICAgVGhl IHVzZSBhbmQgZGVmaW5pdGlvbiBvZiBwcml2YXRlIHVzZSB0YWdzIGhhcyBhbHNvIGJlZW4gbW9k aWZpZWQsIHRvDQogICBhbGxvdyBwZW9wbGUgdG8gdXNlIHByaXZhdGUgdXNlIHN1YnRhZ3MgdG8g ZXh0ZW5kIG9yIG1vZGlmeSBkZWZpbmVkDQogICB0YWdzIGFuZCB0byBtb3ZlIGFzIG11Y2ggaW5m b3JtYXRpb24gYXMgcG9zc2libGUgb3V0IG9mIHByaXZhdGUgdXNlDQogICBhbmQgaW50byB0aGUg cmVndWxhciBzdHJ1Y3R1cmUuDQoNCiAgIFRoZSBnb2FsIGZvciBlYWNoIG9mIHRoZXNlIG1vZGlm aWNhdGlvbnMgaXMgdG8gcmVkdWNlIG9yIGVsaW1pbmF0ZQ0KICAgdGhlIG5lZWQgZm9yIGZ1dHVy ZSByZXZpc2lvbnMgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgVGhlIHNwZWNpZmljIGNoYW5nZXMg aW4gdGhpcyBkb2N1bWVudCB0byBtZWV0IHRoZXNlIGdvYWxzIGFyZToNCg0KICAgbyAgRGVmaW5l cyB0aGUgQUJORiBhbmQgcnVsZXMgZm9yIHN1YnRhZ3Mgc28gdGhhdCB0aGUgY2F0ZWdvcnkgb2Yg YWxsDQogICAgICBzdWJ0YWdzIGNhbiBiZSBkZXRlcm1pbmVkIHdpdGhvdXQgcmVmZXJlbmNlIHRv IHRoZSByZWdpc3RyeS4NCg0KICAgbyAgQWRkcyB0aGUgY29uY2VwdCBvZiB3ZWxsLWZvcm1lZCB2 cy4gdmFsaWRhdGluZyBwcm9jZXNzb3JzLA0KICAgICAgZGVmaW5pbmcgdGhlIHJ1bGVzIGJ5IHdo aWNoIGFuIGltcGxlbWVudGF0aW9uIGNhbiBjbGFpbSB0byBiZSBvbmUNCiAgICAgIG9yIHRoZSBv dGhlci4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA1MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoN CiAgIG8gIFJlcGxhY2VzIHRoZSBJQU5BIGxhbmd1YWdlIHRhZyByZWdpc3RyeSB3aXRoIGEgbGFu Z3VhZ2Ugc3VidGFnDQogICAgICByZWdpc3RyeSB0aGF0IHByb3ZpZGVzIGEgY29tcGxldGUgbGlz dCBvZiB2YWxpZCBzdWJ0YWdzIGluIHRoZQ0KICAgICAgSUFOQSByZWdpc3RyeS4gIFRoaXMgYWxs b3dzIGZvciByb2J1c3QgaW1wbGVtZW50YXRpb24gYW5kIGVhc2Ugb2YNCiAgICAgIG1haW50ZW5h bmNlLiAgVGhlIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSBiZWNvbWVzIHRoZSBjYW5vbmljYWwN CiAgICAgIHNvdXJjZSBmb3IgZm9ybWluZyBsYW5ndWFnZSB0YWdzLg0KDQogICBvICBQcm92aWRl cyBhIHByb2Nlc3MgdGhhdCBndWFyYW50ZWVzIHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLCBi eQ0KICAgICAgaGFuZGxpbmcgcmV1c2Ugb2YgdmFsdWVzIGJ5IElTTyA2MzksIElTTyAxNTkyNCwg YW5kIElTTyAzMTY2IGluDQogICAgICB0aGUgZXZlbnQgdGhhdCB0aGV5IHJlZ2lzdGVyIGEgcHJl dmlvdXNseSB1c2VkIHZhbHVlIGZvciBhIG5ldw0KICAgICAgcHVycG9zZS4NCg0KICAgbyAgQWxs b3dzIElTTyAxNTkyNCBzY3JpcHQgY29kZSBzdWJ0YWdzIGFuZCBhbGxvd3MgdGhlbSB0byBiZSB1 c2VkDQogICAgICBnZW5lcmF0aXZlbHkuICBEZWZpbmVzIGEgbWV0aG9kIGZvciBpbmRpY2F0aW5n IGluIHRoZSByZWdpc3RyeQ0KICAgICAgd2hlbiBzY3JpcHQgc3VidGFncyBhcmUgbmVjZXNzYXJ5 IGZvciBhIGdpdmVuIGxhbmd1YWdlIHRhZy4NCg0KICAgbyAgQWRkcyB0aGUgY29uY2VwdCBvZiBh IHZhcmlhbnQgc3VidGFnIGFuZCBhbGxvd3MgdmFyaWFudHMgdG8gYmUNCiAgICAgIHVzZWQgZ2Vu ZXJhdGl2ZWx5Lg0KDQogICBvICBBZGRzIHRoZSBhYmlsaXR5IHRvIHVzZSBhIGNsYXNzIG9mIFVO IE0uNDkgdGFncyBmb3IgIHN1cHJhLQ0KICAgICAgbmF0aW9uYWwgcmVnaW9ucyBhbmQgdG8gcmVz b2x2ZSBjb25mbGljdHMgaW4gdGhlIGFzc2lnbm1lbnQgb2YgSVNPDQogICAgICAzMTY2IGNvZGVz Lg0KDQogICBvICBEZWZpbmVzIHRoZSBwcml2YXRlIHVzZSB0YWdzIGluIElTTyA2MzksIElTTyAx NTkyNCwgYW5kIElTTyAzMTY2DQogICAgICBhcyB0aGUgbWVjaGFuaXNtIGZvciBjcmVhdGluZyBw cml2YXRlIHVzZSBsYW5ndWFnZSwgc2NyaXB0LCBhbmQNCiAgICAgIHJlZ2lvbiBzdWJ0YWdzIHJl c3BlY3RpdmVseS4NCg0KICAgbyAgQWRkcyBhIHdlbGwtZGVmaW5lZCBleHRlbnNpb24gbWVjaGFu aXNtLg0KDQogICBvICBEZWZpbmVzIGFuIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZywgcG9zc2li bHkgZm9yIHVzZSB3aXRoIGNlcnRhaW4NCiAgICAgIGFudGljaXBhdGVkIGZlYXR1cmVzIG9mIElT TyA2MzktMy4NCg0KICAgRWQgTm90ZTogVGhlIGZvbGxvd2luZyBpdGVtcyBhcmUgcHJvdmlkZWQg Zm9yIHRoZSBjb252ZW5pZW5jZSBvZg0KICAgcmV2aWV3ZXJzIGFuZCB3aWxsIGJlIHJlbW92ZWQg ZnJvbSB0aGUgZmluYWwgZG9jdW1lbnQuDQoNCiAgIENoYW5nZXMgYmV0d2VlbiBkcmFmdC1pZXRm LWx0cnUtcmVnaXN0cnktMDkgYW5kIHRoaXMgdmVyc2lvbiBhcmU6DQoNCiAgIG8gIEluY29ycG9y YXRlZCBKb2huIENvd2FuJ3MgbGlzdCBvZiBuaXRzIHNlbGVjdGl2ZWx5IGJ5IGxvb2tpbmcgYXQN CiAgICAgIHRoZSBjb250ZXh0LiAgUkZDIDIxMTkgd29yZCBjaGFuZ2VzIGxpc3RlZC4gKCMxMDI2 DQogICAgICB0aHJlYWQpKEouQ293YW4pDQoNCiAgICAgICogIGNvdWxkIGJlIHVzZWQgPT4gTUFZ IGluIFNlY3Rpb24gNC41DQoNCiAgICAgICogIGNhbm5vdCA9PiBNVVNUIE5PVCBpbiBTZWN0aW9u IDMuNg0KDQogICAgICAqICBjYW4gcmFpc2Ugb2JqZWN0aW9ucyA9PiBNQVkgaW4gU2VjdGlvbiAz LjQNCg0KICAgICAgKiAgY2FuIGJlIHJlZ2lzdGVyZWQgPT4gTUFZIGluIFNlY3Rpb24gMy41DQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAg ICAgICAgICAgICAgIFtQYWdlIDUyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgKiAg d2lsbCBub3QgYmUgYWRkZWQgPT4gTVVTVCBpbiBTZWN0aW9uIDIuMi4xDQoNCiAgICAgICogIHdp bGwgZXZhbHVhdGUgPT4gTVVTVCBpbiBTZWN0aW9uIDMuMg0KDQogICAgICAqICAnbm8gbmV3IGVu dHJpZXMgd2lsbCBiZSBhZGRlZCBhbmQgbm9uZSBvZiB0aGUgZW50cmllcyByZW1vdmVkJw0KICAg ICAgICAgbWFkZSBub3JtYXRpdmUgaW4gU2VjdGlvbiAzLjINCg0KICAgICAgKiAgJ05vIHN1YnRh Z3Mgd2lsbCBiZSByZWdpc3RlcmVkJyA9PiAnU3VidGFncyBNVVNUIE5PVCBiZQ0KICAgICAgICAg cmVnaXN0ZXJlZCcgaW4gU2VjdGlvbiAzLjUNCg0KICAgICAgKiAgd2lsbCB1c2UsIHdpbGwgZm9y d2FyZCA9PiBNVVNUIGluIFNlY3Rpb24gMy42DQoNCiAgICAgICogIHdpbGwgYmUgcmVsYWJlbGVk LCB3aWxsIGJlIHNlbnQgPT4gTVVTVCBpbiBTZWN0aW9uIDUuMQ0KDQogICAgICAqICB3aWxsIGJl IGxpbWl0ZWQgPT4gU0hBTEwgaW4gU2VjdGlvbiA1LjENCg0KICAgICAgKiAgd2lsbCBpbmNsdWRl ID0+IE1VU1QgaW4gU2VjdGlvbiA1LjINCg0KICAgbyAgQ2hhbmdlZCB0aGUgaW50cm9kdWN0b3J5 IHBhcmFncmFwaCB0byBhdm9pZCB0aGUgbG9hZGVkIHdvcmQNCiAgICAgICJkZWZpbmVkIiAoTS5E dWVyc3QsIEpGQyBNb3JmaW4pDQoNCiAgIG8gIEFkZGVkIGNsYXJpZmljYXRpb24gdG8gdGhlICJD b21wYXRpYmlsaXR5IiBwYXJhZ3JhcGgganVzdCBhYm92ZQ0KICAgICAgKE0uRGF2aXMpDQoNCiAg IG8gIE1vZGlmaWVkIHRoZSBpbnRyb2R1Y3Rpb24gdG8gU2VjdGlvbiAyLiAgKE0uR3VubikNCg0K ICAgbyAgQWRkZWQgZm9ybWFsIHJlZmVyZW5jZSBsaW5rcyB0byBbUkZDMzA2Nl0gYW5kIFtSRkMx NzY2XSBpbg0KICAgICAgU2VjdGlvbiAxIChTLkhvbGxlbmJlY2spDQoNCiAgIG8gIEFkZGVkIGEg cmVmZXJlbmNlIHRvIFtSRkMyMjM0YmlzXSB0byB0aGUgcmVmZXJlbmNlIHRvIEFCTkYgJTJEIGlu DQogICAgICBTZWN0aW9uIDIuMSAoUy5Ib2xsZW5iZWNrKQ0KDQogICBvICBBZGRlZCBhIG5vcm1h dGl2ZSByZWZlcmVuY2UgdG8gW0lTTzY0Nl0gYW5kIHJlZmVyZW5jZWQgaXQgaW4NCiAgICAgIFNl Y3Rpb24gMi4xIChTLkhvbGxlbmJlY2spDQoNCiAgIG8gIENoYW5nZWQgIk1VU1Qgbm90IiB0byAi TVVTVCBOT1QiIGluIFNlY3Rpb24gMi4xIChTLkhvbGxlbmJlY2spDQoNCiAgIG8gIENoYW5nZWQg Ik1BWSBOT1QiICh3aGljaCBpc24ndCBSRkMgMjExOSBkZWZpbmVkKSB0byByZWFkDQogICAgICAi Li4ucmVjb3JkcyBvZiB0eXBlICdyZWdpb24nIHNvbWV0aW1lcyBkb2VzIG5vdCByZXByZXNlbnQu Li4iIGluDQogICAgICBTZWN0aW9uIDMuMSAoUy5Ib2xsZW5iZWNrKQ0KDQogICBvICBSZWZlcmVu Y2VkIFJGQzI0MzQgYW5kICJJRVRGIENvbnNlbnN1cyIgcG9saWN5IGluIFNlY3Rpb24gMy42DQog ICAgICAoUy5Ib2xsZW5iZWNrKQ0KDQogICBvICBBZGp1c3RlZCBhbiBpbnRyb2R1Y3Rpb24gcGFy YWdyYXBoIGluIG9yZGVyIHRvIGhhdmUgYSBmb3J3YXJkDQogICAgICByZWZlcmVuY2UgdG8gdGhl IHN1YnRhZyByZWdpc3RyeS4gIChQLkNvbnN0YWJsZSkNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA1 M10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIG8gIEJlYXV0aWZpZWQgdGhlIEFCTkYgKEsu S2FybHNzb24pDQoNCiAgIG8gIEJlYXV0aWZpZWQgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIGFydHdv cmsgYnkgYWRkaW5nIHNvbWUgaW5kZW50aW9uDQogICAgICAoRi5FbGxlcm1hbm4pDQoNCiAgIG8g IE90aGVyIG1pbm9yIGVkaXRvcmlhbCBuaXRzLiAgKEYuRWxsZXJtYW5uKQ0KDQogICBvICBSZW1v dmVkIHRoZSAibG9jYWxlIGlkZW50aWZpZXJzIiBzZW50ZW5jZS4gKCMxMDY3KSAoUi5QcmVzdWhu KQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA1NF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBB dWd1c3QgMjAwNQ0KDQoNCjkuICBSZWZlcmVuY2VzDQoNCjkuMSAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMNCg0KICAgW0lTTzEwNjQ2XQ0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXph dGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPL0lFQw0KICAgICAgICAgICAgICAxMDY0Njoy MDAzLiAJSW5mb3JtYXRpb24gdGVjaG5vbG9neSAtLSBVbml2ZXJzYWwgTXVsdGlwbGUtDQogICAg ICAgICAgICAgIE9jdGV0IENvZGVkIENoYXJhY3RlciBTZXQgKFVDUyksIGFzLCBmcm9tIHRpbWUg dG8gdGltZSwNCiAgICAgICAgICAgICAgYW1lbmRlZCwgcmVwbGFjZWQgYnkgYSBuZXcgZWRpdGlv biBvciBleHBhbmRlZCBieSB0aGUNCiAgICAgICAgICAgICAgYWRkaXRpb24gb2YgbmV3IHBhcnRz IiwgMjAwMy4NCg0KICAgW0lTTzE1OTI0XQ0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9y Z2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPDQogICAgICAgICAgICAgIDE1OTI0 OjIwMDQuIEluZm9ybWF0aW9uIGFuZCBkb2N1bWVudGF0aW9uIC0tIENvZGVzIGZvciB0aGUNCiAg ICAgICAgICAgICAgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2Ygc2NyaXB0cyIsIEphbnVhcnkg MjAwNC4NCg0KICAgW0lTTzMxNjYtMV0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdh bml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyAzMTY2LQ0KICAgICAgICAgICAgICAx OjE5OTcuIAlDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mDQogICAgICAg ICAgICAgIGNvdW50cmllcyBhbmQgdGhlaXIgc3ViZGl2aXNpb25zIC0tIFBhcnQgMTogQ291bnRy eQ0KICAgICAgICAgICAgICBjb2RlcyIsIDE5OTcuDQoNCiAgIFtJU082MzktMV0NCiAgICAgICAg ICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklT TyA2MzktDQogICAgICAgICAgICAgIDE6MjAwMi4gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlv biBvZiBuYW1lcyBvZiBsYW5ndWFnZXMNCiAgICAgICAgICAgICAgLS0gUGFydCAxOiBBbHBoYS0y IGNvZGUiLCAyMDAyLg0KDQogICBbSVNPNjM5LTJdDQogICAgICAgICAgICAgIEludGVybmF0aW9u YWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08gNjM5LQ0KICAgICAgICAg ICAgICAyOjE5OTguIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgbGFu Z3VhZ2VzDQogICAgICAgICAgICAgIC0tIFBhcnQgMjogQWxwaGEtMyBjb2RlLCBmaXJzdCBlZGl0 aW9uIiwgMTk5OC4NCg0KICAgW0lTTzY0Nl0gICBJU08vSUVDIDY0NiBKVEMgMS9TQyAyLCAiSVNP L0lFQyA2NDY6MTk5MSwgSW5mb3JtYXRpb24NCiAgICAgICAgICAgICAgdGVjaG5vbG9neSAtLSBJ U08gNy1iaXQgY29kZWQgY2hhcmFjdGVyIHNldCBmb3INCiAgICAgICAgICAgICAgaW5mb3JtYXRp b24gaW50ZXJjaGFuZ2UuIiwgMTk5MS4NCg0KICAgW1JGQzIwMjZdICBCcmFkbmVyLCBTLiwgIlRo ZSBJbnRlcm5ldCBTdGFuZGFyZHMgUHJvY2VzcyAtLSBSZXZpc2lvbg0KICAgICAgICAgICAgICAz IiwgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuDQoNCiAgIFtSRkMyMDI4XSAgSG92ZXks IFIuIGFuZCBTLiBCcmFkbmVyLCAiVGhlIE9yZ2FuaXphdGlvbnMgSW52b2x2ZWQgaW4NCiAgICAg ICAgICAgICAgdGhlIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MiLCBCQ1AgMTEsIFJGQyAyMDI4LA0K ICAgICAgICAgICAgICBPY3RvYmVyIDE5OTYuDQoNCiAgIFtSRkMyMDQ3XSAgTW9vcmUsIEsuLCAi TUlNRSAoTXVsdGlwdXJwb3NlIEludGVybmV0IE1haWwgRXh0ZW5zaW9ucykNCiAgICAgICAgICAg ICAgUGFydCBUaHJlZTogTWVzc2FnZSBIZWFkZXIgRXh0ZW5zaW9ucyBmb3IgTm9uLUFTQ0lJIFRl eHQiLA0KICAgICAgICAgICAgICBSRkMgMjA0NywgTm92ZW1iZXIgMTk5Ni4NCg0KICAgW1JGQzIx MTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAg ICAgICAgICAgICAgIFtQYWdlIDU1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0K DQogICBbUkZDMjIzNGJpc10NCiAgICAgICAgICAgICAgQ3JvY2tlciwgRC4gYW5kIFAuIE92ZXJl bGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlv bnM6IEFCTkYiLCBkcmFmdC1jcm9ja2VyLWFibmYtcmZjMjIzNGJpcy0wMA0KICAgICAgICAgICAg ICAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDIwMDUuDQoNCiAgIFtSRkMyNDM0XSAgTmFydGVu LCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4NCiAgICAg ICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJG QyAyNDM0LA0KICAgICAgICAgICAgICBPY3RvYmVyIDE5OTguDQoNCiAgIFtSRkMyNzgxXSAgSG9m Zm1hbiwgUC4gYW5kIEYuIFllcmdlYXUsICJVVEYtMTYsIGFuIGVuY29kaW5nIG9mIElTTw0KICAg ICAgICAgICAgICAxMDY0NiIsIFJGQyAyNzgxLCBGZWJydWFyeSAyMDAwLg0KDQogICBbUkZDMjg2 MF0gIENhcnBlbnRlciwgQi4sIEJha2VyLCBGLiwgYW5kIE0uIFJvYmVydHMsICJNZW1vcmFuZHVt IG9mDQogICAgICAgICAgICAgIFVuZGVyc3RhbmRpbmcgQ29uY2VybmluZyB0aGUgVGVjaG5pY2Fs IFdvcmsgb2YgdGhlDQogICAgICAgICAgICAgIEludGVybmV0IEFzc2lnbmVkIE51bWJlcnMgQXV0 aG9yaXR5IiwgUkZDIDI4NjAsIEp1bmUgMjAwMC4NCg0KICAgW1JGQzMzMzldICBLbHluZSwgRy4g YW5kIEMuIE5ld21hbiwgIkRhdGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0Og0KICAgICAgICAg ICAgICBUaW1lc3RhbXBzIiwgUkZDIDMzMzksIEp1bHkgMjAwMi4NCg0KICAgW1JGQzM1NTJdICBS ZXNjb3JsYSwgRS4gYW5kIEIuIEtvcnZlciwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgUkZDDQog ICAgICAgICAgICAgIFRleHQgb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLCBCQ1AgNzIsIFJG QyAzNTUyLA0KICAgICAgICAgICAgICBKdWx5IDIwMDMuDQoNCiAgIFtVTl9NLjQ5XSAgU3RhdGlz dGljYWwgRGl2aXNpb24sIFVuaXRlZCBOYXRpb25zLCAiU3RhbmRhcmQgQ291bnRyeSBvcg0KICAg ICAgICAgICAgICBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UiLCBVTiBTdGFuZGFyZCBD b3VudHJ5IG9yDQogICAgICAgICAgICAgIEFyZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2FsIFVzZSwg UmV2aXNpb24gNCAoVW5pdGVkIE5hdGlvbnMNCiAgICAgICAgICAgICAgcHVibGljYXRpb24sIFNh bGVzIE5vLiA5OC5YVklJLjksIEp1bmUgMTk5OS4NCg0KOS4yICBJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzDQoNCiAgIFtSRkMxNzY2XSAgQWx2ZXN0cmFuZCwgSC4sICJUYWdzIGZvciB0aGUgSWRlbnRp ZmljYXRpb24gb2YNCiAgICAgICAgICAgICAgTGFuZ3VhZ2VzIiwgUkZDIDE3NjYsIE1hcmNoIDE5 OTUuDQoNCiAgIFtSRkMyMjMxXSAgRnJlZWQsIE4uIGFuZCBLLiBNb29yZSwgIk1JTUUgUGFyYW1l dGVyIFZhbHVlIGFuZCBFbmNvZGVkDQogICAgICAgICAgICAgIFdvcmQgRXh0ZW5zaW9uczogQ2hh cmFjdGVyIFNldHMsIExhbmd1YWdlcywgYW5kDQogICAgICAgICAgICAgIENvbnRpbnVhdGlvbnMi LCBSRkMgMjIzMSwgTm92ZW1iZXIgMTk5Ny4NCg0KICAgW1JGQzMwNjZdICBBbHZlc3RyYW5kLCBI LiwgIlRhZ3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBvZg0KICAgICAgICAgICAgICBMYW5ndWFn ZXMiLCBCQ1AgNDcsIFJGQyAzMDY2LCBKYW51YXJ5IDIwMDEuDQoNCiAgIFtVbmljb2RlXSAgVW5p Y29kZSBDb25zb3J0aXVtLCAiVGhlIFVuaWNvZGUgQ29uc29ydGl1bS4gVGhlIFVuaWNvZGUNCiAg ICAgICAgICAgICAgU3RhbmRhcmQsIFZlcnNpb24gNC4xLjAsIGRlZmluZWQgYnk6IFRoZSBVbmlj b2RlIFN0YW5kYXJkLA0KICAgICAgICAgICAgICBWZXJzaW9uIDQuMCAoQm9zdG9uLCBNQSwgQWRk aXNvbi1XZXNsZXksIDIwMDMuIElTQk4gMC0zMjEtDQogICAgICAgICAgICAgIDE4NTc4LTEpLCBh cyBhbWVuZGVkIGJ5IFVuaWNvZGUgNC4wLjENCiAgICAgICAgICAgICAgKGh0dHA6Ly93d3cudW5p Y29kZS5vcmcvdmVyc2lvbnMvVW5pY29kZTQuMC4xKSBhbmQgYnkNCiAgICAgICAgICAgICAgVW5p Y29kZSA0LjEuMA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFy eSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0K DQogICAgICAgICAgICAgIChodHRwOi8vd3d3LnVuaWNvZGUub3JnL3ZlcnNpb25zL1VuaWNvZGU0 LjEuMCkuIiwNCiAgICAgICAgICAgICAgTWFyY2ggMjAwNS4NCg0KICAgW1hNTDEwXSAgICBCcmF5 IChldCBhbCksIFQuLCAiRXh0ZW5zaWJsZSBNYXJrdXAgTGFuZ3VhZ2UgKFhNTCkgMS4wIiwNCiAg ICAgICAgICAgICAgMDIgMjAwNC4NCg0KICAgW1hNTFNjaGVtYV0NCiAgICAgICAgICAgICAgQmly b24sIFAuLCBFZC4gYW5kIEEuIE1hbGhvdHJhLCBFZC4sICJYTUwgU2NoZW1hIFBhcnQgMjoNCiAg ICAgICAgICAgICAgRGF0YXR5cGVzIFNlY29uZCBFZGl0aW9uIiwgMTAgMjAwNCwgPA0KICAgICAg ICAgICAgICBodHRwOi8vd3d3LnczLm9yZy9UUi94bWxzY2hlbWEtMi8+Lg0KDQogICBbaW5pdGlh bC1yZWdpc3RyeV0NCiAgICAgICAgICAgICAgRXdlbGwsIEQuLCBFZC4sICJJbml0aWFsIExhbmd1 YWdlIFN1YnRhZyBSZWdpc3RyeSIsDQogICAgICAgICAgICAgIEp1bmUgMjAwNSwgPGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLWx0 cnUtaW5pdGlhbC1yZWdpc3RyeS0wMC50eHQ+Lg0KDQogICBbaXNvNjM5LnByaW5jaXBsZXNdDQog ICAgICAgICAgICAgIElTTyA2MzkgSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlLCAiSVNPIDYzOSBK b2ludCBBZHZpc29yeQ0KICAgICAgICAgICAgICBDb21taXR0ZWU6ICBXb3JraW5nIHByaW5jaXBs ZXMgZm9yIElTTyA2MzkgbWFpbnRlbmFuY2UiLA0KICAgICAgICAgICAgICBNYXJjaCAyMDAwLA0K ICAgICAgICAgICAgICA8aHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi8NCiAg ICAgICAgICAgICAgaXNvNjM5amFjX24zci5odG1sPi4NCg0KICAgW3JlY29yZC1qYXJdDQogICAg ICAgICAgICAgIFJheW1vbmQsIEUuLCAiVGhlIEFydCBvZiBVbml4IFByb2dyYW1taW5nIiwgMjAw My4NCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgQWRkaXNvbiBQaGlsbGlwcyAoZWRpdG9y KQ0KICAgUXVlc3QgU29mdHdhcmUNCg0KICAgRW1haWw6IGFkZGlzb24ucGhpbGxpcHNAcXVlc3Qu Y29tDQogICBVUkk6ICAgaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tDQoNCg0KICAgTWFyayBE YXZpcyAoZWRpdG9yKQ0KICAgSUJNDQoNCiAgIEVtYWlsOiBtYXJrLmRhdmlzQHVzLmlibS5jb20N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDUsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA1N10NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAw NQ0KDQoNCkFwcGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIEFueSBsaXN0IG9mIGNv bnRyaWJ1dG9ycyBpcyBib3VuZCB0byBiZSBpbmNvbXBsZXRlOyBwbGVhc2UgcmVnYXJkIHRoZQ0K ICAgZm9sbG93aW5nIGFzIG9ubHkgYSBzZWxlY3Rpb24gZnJvbSB0aGUgZ3JvdXAgb2YgcGVvcGxl IHdobyBoYXZlDQogICBjb250cmlidXRlZCB0byBtYWtlIHRoaXMgZG9jdW1lbnQgd2hhdCBpdCBp cyB0b2RheS4NCg0KICAgVGhlIGNvbnRyaWJ1dG9ycyB0byBSRkMgMzA2NiBhbmQgUkZDIDE3NjYs IHRoZSBwcmVjdXJzb3JzIG9mIHRoaXMNCiAgIGRvY3VtZW50LCBtYWRlIGVub3Jtb3VzIGNvbnRy aWJ1dGlvbnMgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSB0byB0aGlzDQogICBkb2N1bWVudCBhbmQg YXJlIGdlbmVyYWxseSByZXNwb25zaWJsZSBmb3IgdGhlIHN1Y2Nlc3Mgb2YgbGFuZ3VhZ2UNCiAg IHRhZ3MuDQoNCiAgIFRoZSBmb2xsb3dpbmcgcGVvcGxlIChpbiBhbHBoYWJldGljYWwgb3JkZXIp IGNvbnRyaWJ1dGVkIHRvIHRoaXMNCiAgIGRvY3VtZW50IG9yIHRvIFJGQ3MgMTc2NiBhbmQgMzA2 NjoNCg0KICAgR2xlbm4gQWRhbXMsIEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCBUaW0gQmVybmVy cy1MZWUsIE1hcmMgQmxhbmNoZXQsDQogICBOYXRoYW5pZWwgQm9yZW5zdGVpbiwgS2FyZW4gQnJv b21lLCBFcmljIEJydW5uZXIsIFNlYW4gTS4gQnVya2UsIE0uVC4NCiAgIENhcnJhc2NvIEJlbml0 ZXosIEplcmVteSBDYXJyb2xsLCBKb2huIENsZXdzLCBKaW0gQ29ua2xpbiwgUGV0ZXINCiAgIENv bnN0YWJsZSwgSm9obiBDb3dhbiwgTWFyayBDcmlzcGluLCBEYXZlIENyb2NrZXIsIE1hcnRpbiBE dWVyc3QsDQogICBGcmFuayBFbGxlcm1hbiwgTWljaGFlbCBFdmVyc29uLCBEb3VnIEV3ZWxsLCBO ZWQgRnJlZWQsIFRpbSBHb29kd2luLA0KICAgRGlyay1XaWxsZW0gdmFuIEd1bGlrLCBNYXJpb24g R3VubiwgSm9lbCBIYWxwcmVuLCBFbGxpb3R0ZSBSdXN0eQ0KICAgSGFyb2xkLCBQYXVsIEhvZmZt YW4sIFNjb3R0IEhvbGxlbmJlY2ssIFJpY2hhcmQgSXNoaWRhLCBPbGxlDQogICBKYXJuZWZvcnMs IEtlbnQgS2FybHNzb24sIEpvaG4gS2xlbnNpbiwgRXJra2kgS29sZWhtYWluZW4sIEFsYWluDQog ICBMYUJvbnRlLCBFcmljIE1hZGVyLCBJcmEgTWNEb25hbGQsIEtlaXRoIE1vb3JlLCBDaHJpcyBO ZXdtYW4sDQogICBNYXNhdGFrYSBPaHRhLCBEeWxhbiBQaWVyY2UsIFJhbmR5IFByZXN1aG4sIEdl b3JnZSBSaG90ZW4sIEZlbGl4DQogICBTYXNha2ksIE1hcmt1cyBTY2hlcmVyLCBLZWxkIEpvcm4g U2ltb25zZW4sIFRoaWVycnkgU291cmJpZXIsIE90dG8NCiAgIFN0b2x6LCBUZXggVGV4aW4sIEFu ZHJlYSBWaW5lLCBSaHlzIFdlYXRoZXJsZXksIE1pc2hhIFdvbGYsIEZyYW5jb2lzDQogICBZZXJn ZWF1IGFuZCBtYW55LCBtYW55IG90aGVycy4NCg0KICAgVmVyeSBzcGVjaWFsIHRoYW5rcyBtdXN0 IGdvIHRvIEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCB3aG8NCiAgIG9yaWdpbmF0ZWQgUkZDcyAx NzY2IGFuZCAzMDY2LCBhbmQgd2l0aG91dCB3aG9tIHRoaXMgZG9jdW1lbnQgd291bGQNCiAgIG5v dCBoYXZlIGJlZW4gcG9zc2libGUuICBTcGVjaWFsIHRoYW5rcyBtdXN0IGdvIHRvIE1pY2hhZWwg RXZlcnNvbiwNCiAgIHdobyBoYXMgc2VydmVkIGFzIGxhbmd1YWdlIHRhZyByZXZpZXdlciBmb3Ig YWxtb3N0IHRoZSBjb21wbGV0ZQ0KICAgcGVyaW9kIHNpbmNlIHRoZSBwdWJsaWNhdGlvbiBvZiBS RkMgMTc2Ni4gIFNwZWNpYWwgdGhhbmtzIHRvIERvdWcNCiAgIEV3ZWxsLCBmb3IgaGlzIHByb2R1 Y3Rpb24gb2YgdGhlIGZpcnN0IGNvbXBsZXRlIHN1YnRhZyByZWdpc3RyeSwgYW5kDQogICBoaXMg d29yayBpbiBwcm9kdWNpbmcgYSB0ZXN0IHBhcnNlciBmb3IgdmVyaWZ5aW5nIGxhbmd1YWdlIHRh Z3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDU4XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA1DQoNCg0KQXBwZW5kaXggQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRh Z3MgKEluZm9ybWF0aXZlKQ0KDQogICBTaW1wbGUgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAgICBk ZSAoR2VybWFuKQ0KDQogICAgICBmciAoRnJlbmNoKQ0KDQogICAgICBqYSAoSmFwYW5lc2UpDQoN CiAgICAgIGktZW5vY2hpYW4gKGV4YW1wbGUgb2YgYSBncmFuZGZhdGhlcmVkIHRhZykNCg0KICAg TGFuZ3VhZ2Ugc3VidGFnIHBsdXMgU2NyaXB0IHN1YnRhZzoNCg0KICAgICAgemgtSGFudCAoQ2hp bmVzZSB3cml0dGVuIHVzaW5nIHRoZSBUcmFkaXRpb25hbCBDaGluZXNlIHNjcmlwdCkNCg0KICAg ICAgemgtSGFucyAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBTaW1wbGlmaWVkIENoaW5lc2Ug c2NyaXB0KQ0KDQogICAgICBzci1DeXJsIChTZXJiaWFuIHdyaXR0ZW4gdXNpbmcgdGhlICBDeXJp bGxpYyBzY3JpcHQpDQoNCiAgICAgIHNyLUxhdG4gKFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUg TGF0aW4gc2NyaXB0KQ0KDQogICBMYW5ndWFnZS1TY3JpcHQtUmVnaW9uOg0KDQogICAgICB6aC1I YW5zLUNOIChDaGluZXNlIHdyaXR0ZW4gdXNpbmcgdGhlIFNpbXBsaWZpZWQgc2NyaXB0IGFzIHVz ZWQgaW4NCiAgICAgIG1haW5sYW5kIENoaW5hKQ0KDQogICAgICBzci1MYXRuLUNTIChTZXJiaWFu IHdyaXR0ZW4gdXNpbmcgdGhlIExhdGluIHNjcmlwdCBhcyB1c2VkIGluDQogICAgICBTZXJiaWEg YW5kIE1vbnRlbmVncm8pDQoNCiAgIExhbmd1YWdlLVZhcmlhbnQ6DQoNCiAgICAgIHNsLXJvemFq IChSZXNpYW4gZGlhbGVjdCBvZiBTbG92ZW5pYW4NCg0KICAgICAgc2wtbmVkaXMgKE5hZGl6YSBk aWFsZWN0IG9mIFNsb3ZlbmlhbikNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uLVZhcmlhbnQ6DQoNCiAg ICAgIGRlLUNILTE5MDEgKEdlcm1hbiBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kIHVzaW5nIHRoZSAx OTAxIHZhcmlhbnQNCiAgICAgIFtvcnRob2dyYXBoeV0pDQoNCiAgICAgIHNsLUlULW5lZGlzIChT bG92ZW5pYW4gYXMgdXNlZCBpbiBJdGFseSwgTmFkaXphIGRpYWxlY3QpDQoNCiAgIExhbmd1YWdl LVNjcmlwdC1SZWdpb24tVmFyaWFudDoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNTldDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICBzbC1MYXRuLUlULW5lZGlzIChOYWRpemEgZGlh bGVjdCBvZiBTbG92ZW5pYW4gd3JpdHRlbiB1c2luZyB0aGUNCiAgICAgIExhdGluIHNjcmlwdCBh cyB1c2VkIGluIEl0YWx5LiAgTm90ZSB0aGF0IHRoaXMgdGFnIGlzIE5PVA0KICAgICAgUkVDT01N RU5ERUQgYmVjYXVzZSBzdWJ0YWcgJ3NsJyBoYXMgYSBTdXBwcmVzcy1TY3JpcHQgdmFsdWUgb2YN CiAgICAgICdMYXRuJykNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uOg0KDQogICAgICBkZS1ERSAoR2Vy bWFuIGZvciBHZXJtYW55KQ0KDQogICAgICBlbi1VUyAoRW5nbGlzaCBhcyB1c2VkIGluIHRoZSBV bml0ZWQgU3RhdGVzKQ0KDQogICAgICBlcy00MTkgKFNwYW5pc2ggYXBwcm9wcmlhdGUgZm9yIHRo ZSBMYXRpbiBBbWVyaWNhIGFuZCBDYXJpYmJlYW4NCiAgICAgIHJlZ2lvbiB1c2luZyB0aGUgVU4g cmVnaW9uIGNvZGUpDQoNCiAgIFByaXZhdGUgdXNlIHN1YnRhZ3M6DQoNCiAgICAgIGRlLUNILXgt cGhvbmViaw0KDQogICAgICBhei1BcmFiLXgtQVpFLWRlcmJlbmQNCg0KICAgRXh0ZW5kZWQgbGFu Z3VhZ2Ugc3VidGFncyAoZXhhbXBsZXMgT05MWTogZXh0ZW5kZWQgbGFuZ3VhZ2VzIE1VU1QgYmUN CiAgIGRlZmluZWQgYnkgcmV2aXNpb24gb3IgdXBkYXRlIHRvIHRoaXMgZG9jdW1lbnQpOg0KDQog ICAgICB6aC1taW4NCg0KICAgICAgemgtbWluLW5hbi1IYW50LUNODQoNCiAgIFByaXZhdGUgdXNl IHJlZ2lzdHJ5IHZhbHVlczoNCg0KICAgICAgeC13aGF0ZXZlciAocHJpdmF0ZSB1c2UgdXNpbmcg dGhlIHNpbmdsZXRvbiAneCcpDQoNCiAgICAgIHFhYS1RYWFhLVFNLXgtc291dGhlcm4gKGFsbCBw cml2YXRlIHRhZ3MpDQoNCiAgICAgIGRlLVFhYWEgKEdlcm1hbiwgd2l0aCBhIHByaXZhdGUgc2Ny aXB0KQ0KDQogICAgICBzci1MYXRuLVFNIChTZXJiaWFuLCBMYXRpbi1zY3JpcHQsIHByaXZhdGUg cmVnaW9uKQ0KDQogICAgICBzci1RYWFhLUNTIChTZXJiaWFuLCBwcml2YXRlIHNjcmlwdCwgZm9y IFNlcmJpYSBhbmQgTW9udGVuZWdybykNCg0KICAgVGFncyB0aGF0IHVzZSBleHRlbnNpb25zIChl eGFtcGxlcyBPTkxZOiBleHRlbnNpb25zIE1VU1QgYmUgZGVmaW5lZA0KICAgYnkgcmV2aXNpb24g b3IgdXBkYXRlIHRvIHRoaXMgZG9jdW1lbnQgb3IgYnkgUkZDKToNCg0KICAgICAgZW4tVVMtdS1p c2xhbUNhbA0KDQogICAgICB6aC1DTi1hLW15RXh0LXgtcHJpdmF0ZQ0KDQoNCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAgICAg ICAgW1BhZ2UgNjBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICBlbi1hLW15RXh0LWIt YW5vdGhlcg0KDQogICBTb21lIEludmFsaWQgVGFnczoNCg0KICAgICAgZGUtNDE5LURFICh0d28g cmVnaW9uIHRhZ3MpDQoNCiAgICAgIGEtREUgKHVzZSBvZiBhIHNpbmdsZSBjaGFyYWN0ZXIgc3Vi dGFnIGluIHByaW1hcnkgcG9zaXRpb247IG5vdGUNCiAgICAgIHRoYXQgdGhlcmUgYXJlIGEgZmV3 IGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IHN0YXJ0IHdpdGggImktIiB0aGF0DQogICAgICBhcmUg dmFsaWQpDQoNCiAgICAgIGFyLWEtYWFhLWItYmJiLWEtY2NjICh0d28gZXh0ZW5zaW9ucyB3aXRo IHNhbWUgc2luZ2xlIGxldHRlcg0KICAgICAgcHJlZml4KQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDA2ICAgICAgICAg ICAgICAgW1BhZ2UgNjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQpJbnRlbGxlY3R1YWwgUHJv cGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGlu ZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkg UmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRh aW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmli ZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5z ZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsg bm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVu dCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9u IHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBj YW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBS IGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNz dXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBv ZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJt aXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBs ZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWlu ZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3 LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0 eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBv ciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRo YXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50 DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRo ZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpEaXNjbGFpbWVyIG9mIFZhbGlk aXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVy ZWluIGFyZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJV VE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09S RUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAg IEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1Mg T1IgSU1QTElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZ IFRIQVQgVEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZS SU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5U QUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpDb3B5cmln aHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIw MDUpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNl cyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZA0KICAgZXhjZXB0IGFz IHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4N Cg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5j dGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5ldCBTb2NpZXR5Lg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMDYg ICAgICAgICAgICAgICBbUGFnZSA2Ml0NCgwNCg== ------_=_NextPart_001_01C598FB.5C16A60E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C598FB.5C16A60E-- From ltru-bounces@lists.ietf.org Thu Aug 04 10:17:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gXB-0000MS-Sr; Thu, 04 Aug 2005 10:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gXA-0000MM-Nx for ltru@megatron.ietf.org; Thu, 04 Aug 2005 10:17:20 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14102 for ; Thu, 4 Aug 2005 10:17:18 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050804141645.UKVC29002.mta9.adelphia.net@DEWELL> for ; Thu, 4 Aug 2005 10:16:45 -0400 Message-ID: <004b01c598ff$16dea6a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050804102548.DKMY25460.edge4.adelphia.net@megatron.ietf.org> Date: Thu, 4 Aug 2005 07:16:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: revised editor's copy online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: > The edition number is redundant, but is usually mentioned anyway. This > is not just for ISO standards. Look at the XML standards for instance; > they include the edition number, even in the title (which I think is > not quite the right place for it). To the extent draft-initial is involved in this discussion, I took the names of ISO standards directly from their listing in the online ISO catalog (per Kent's suggestion), including the ordinal version number where given. > (And the current DTD required a "year", which is written after the > title, so I put the edition number as "year".) To me, that constitutes playing games with xml2rfc. A document number is not an author, and an edition number is not a year. > Nobody has commented on that ISO 3166 (without parts) is outdated > (withdrawn), and that the current parts 1 and 3 may be what should > be referenced. If some part of draft-registry refers to the old ISO 3166, and some other part refers to the new ISO 3166-1 and 3166-3 (for whatever reason), then both should be cited. If this is not the case, then the superfluous reference(s) should be removed. I don't disagree that the flexibility of xml2rfc may be less than perfect. I also don't disagree that perhaps there should be a formal description of exactly how ISO and other external standards should be cited within RFCs, if there isn't one already, and that xml2rfc should allow an author or editor to format references according to this description. What I do disagree with is that this WG Last Call is the time or place to do this. There must be many, many RFCs in existence that use the formatting imposed by xml2rfc to refer to ISO standards, and the respective WGs and IETF and RFC editor have apparently considered them to be valid references. Formally, we would like to have the best and most consistent bibliographic style we can, but informally, the references are there to guide readers to the correct document, and if they do that -- apart from questions of redundancy and comma placement -- then they should be considered good enough for now. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 10:23:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gdP-0002eK-F5; Thu, 04 Aug 2005 10:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gdO-0002eC-VX for ltru@megatron.ietf.org; Thu, 04 Aug 2005 10:23:47 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14829 for ; Thu, 4 Aug 2005 10:23:44 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050804142315.MNGV19267.mta10.adelphia.net@DEWELL> for ; Thu, 4 Aug 2005 10:23:15 -0400 Message-ID: <005201c598ff$fed9dba0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050804135045.VWQH25460.edge4.adelphia.net@megatron.ietf.org> Date: Thu, 4 Aug 2005 07:22:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: revised editor's copy online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I noticed that the reference to ISO 3166-1 in draft-registry-10 is to the 1997 edition, while the reference in draft-initial-03 is to the 1988 edition. I'll be happy to change this in draft-initial as a Second Last Call item (text not reflecting agreed-upon changes), if the co-chairs wish. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 11:09:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hM0-0007xU-S9; Thu, 04 Aug 2005 11:09:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hLz-0007xK-Cl for ltru@megatron.ietf.org; Thu, 04 Aug 2005 11:09:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18055 for ; Thu, 4 Aug 2005 11:09:48 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0hss-0006Ye-L6 for ltru@ietf.org; Thu, 04 Aug 2005 11:43:51 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0hLw-0006Rh-00 for ltru@ietf.org; Thu, 04 Aug 2005 11:09:48 -0400 Message-ID: <6535153.1123168188492.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Thu, 4 Aug 2005 17:09:48 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: revised editor's copy online Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This seems reasonable to me, though it could in my opinion also be merged with any IESG comments or IETF last call comments, since in this case it's an editorial change to a non-normative reference. Randy, ltru co-chair BTW, mail for Martin's is bouncing due to a too-many-hops problem, so we might have to wait until he returns to Japan before we hear from him. -----Original Message----- From: Doug Ewell Sent: Aug 4, 2005 4:22 PM To: LTRU Working Group Subject: [Ltru] Re: revised editor's copy online I noticed that the reference to ISO 3166-1 in draft-registry-10 is to the 1997 edition, while the reference in draft-initial-03 is to the 1988 edition. I'll be happy to change this in draft-initial as a Second Last Call item (text not reflecting agreed-upon changes), if the co-chairs wish. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 11:09:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hM2-0007y2-2q; Thu, 04 Aug 2005 11:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hM0-0007xP-KJ for ltru@megatron.ietf.org; Thu, 04 Aug 2005 11:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18058 for ; Thu, 4 Aug 2005 11:09:50 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0hsv-0006Yj-9l for ltru@ietf.org; Thu, 04 Aug 2005 11:43:53 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0hLz-0006ST-00 for ltru@ietf.org; Thu, 04 Aug 2005 11:09:51 -0400 Message-ID: <3361774.1123168191653.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Thu, 4 Aug 2005 17:09:51 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] Re: revised editor's copy online Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This seems reasonable to me, though it could in my opinion also be merged with any IESG comments or IETF last call comments, since in this case it's an editorial change to a non-normative reference. Randy, ltru co-chair BTW, mail for Martin's is bouncing due to a too-many-hops problem, so we might have to wait until he returns to Japan before we hear from him. -----Original Message----- From: Doug Ewell Sent: Aug 4, 2005 4:22 PM To: LTRU Working Group Subject: [Ltru] Re: revised editor's copy online I noticed that the reference to ISO 3166-1 in draft-registry-10 is to the 1997 edition, while the reference in draft-initial-03 is to the 1988 edition. I'll be happy to change this in draft-initial as a Second Last Call item (text not reflecting agreed-upon changes), if the co-chairs wish. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 11:11:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hNX-00085o-0J; Thu, 04 Aug 2005 11:11:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hNV-00085j-0c for ltru@megatron.ietf.org; Thu, 04 Aug 2005 11:11:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18108 for ; Thu, 4 Aug 2005 11:11:22 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0huO-0006bS-FG for ltru@ietf.org; Thu, 04 Aug 2005 11:45:25 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j74FBERX298056 for ; Thu, 4 Aug 2005 11:11:14 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j74FBM5q173438 for ; Thu, 4 Aug 2005 09:11:22 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j74FBDb4006145 for ; Thu, 4 Aug 2005 09:11:13 -0600 Received: from markdavis (sig-9-48-114-20.mts.ibm.com [9.48.114.20]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j74FBCAb006079; Thu, 4 Aug 2005 09:11:13 -0600 Message-ID: <00f201c59906$bf7b4eb0$86433409@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , References: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlink.net> Subject: Re: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 Date: Thu, 4 Aug 2005 08:11:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j74FBERX298056 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I hereby indicate that I've read it and am OK with it. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Thursday, August 04, 2005 02:11 Subject: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt end= s 2005-08-08 > Hi - > > I see the announcement for the availability of the revised initial registry draft has > been sent out. (Thanks to Doug and to the Secretariat for the quick turnaround!) > > We'll have a BRIEF second WG last call on this document, and I'd like t= o limit > the scope of this last call to verifying that changes agreed during > the first WG last call are properly reflected by the text. (Of course,= if anyone > finds a substantial technical error, we'd like to hear about it now rat= her than > waiting for the IETF last call.) This last call will end Monday, Augus= t 8. The > draft is available at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt > > I'd like those who take the time to look at this document to post a message, > either to the ltru WG mailing list or to the co-chairs, indicating that they've > read it and whether they are OK with it. We need this information for = the > paperwork we need to submit along with our request to the IESG to consi= der > it for publication as an Informational RFC. > > Randy, ltru co-chair > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 11:15:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hRT-0000RK-N8; Thu, 04 Aug 2005 11:15:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hRR-0000Ql-U2 for ltru@megatron.ietf.org; Thu, 04 Aug 2005 11:15:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18335 for ; Thu, 4 Aug 2005 11:15:27 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0hyL-0006i1-FD for ltru@ietf.org; Thu, 04 Aug 2005 11:49:30 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j74FFAWY300768 for ; Thu, 4 Aug 2005 11:15:12 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j74FF5tq186816 for ; Thu, 4 Aug 2005 09:15:05 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j74FF9Fe016190 for ; Thu, 4 Aug 2005 09:15:09 -0600 Received: from markdavis (sig-9-48-114-20.mts.ibm.com [9.48.114.20]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j74FF8HN016107; Thu, 4 Aug 2005 09:15:09 -0600 Message-ID: <010201c59907$4c1b5e50$86433409@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" References: <20050804135045.VWQH25460.edge4.adelphia.net@megatron.ietf.org> <005201c598ff$fed9dba0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: revised editor's copy online Date: Thu, 4 Aug 2005 08:15:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j74FFAWY300768 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug, can you update the (more readable) html version on http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.html? =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Thursday, August 04, 2005 07:22 Subject: [Ltru] Re: revised editor's copy online > I noticed that the reference to ISO 3166-1 in draft-registry-10 is to > the 1997 edition, while the reference in draft-initial-03 is to the 198= 8 > edition. I'll be happy to change this in draft-initial as a Second Las= t > Call item (text not reflecting agreed-upon changes), if the co-chairs > wish. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 11:25:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hbT-0003Jf-NR; Thu, 04 Aug 2005 11:25:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hbS-0003GT-GZ for ltru@megatron.ietf.org; Thu, 04 Aug 2005 11:25:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18779 for ; Thu, 4 Aug 2005 11:25:48 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0i8L-0006yk-8U for ltru@ietf.org; Thu, 04 Aug 2005 11:59:51 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E0hbM-0002a5-3E; Thu, 04 Aug 2005 08:25:44 -0700 Message-Id: <6.2.1.2.2.20050804153447.04c806e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 04 Aug 2005 15:47:05 +0200 To: Randy Presuhn , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 In-Reply-To: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.ea rthlink.net> References: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org No comment on this text which lists typographer related information. Except that it is not defined by any RFC, that its Informational status does not seem to fit with its normative quality (except if the main Draft only claims Informational status what would be appropriate, as describing an application related group intents). I note that Addison's change in abstract to make sure it is only IANA related, has not be copied into the text of the document, which still can be ISO 11173 conformant. It has no Internationlisation considerations section what is innapropriate as it should document why it is not internationalised. jfc At 11:11 04/08/2005, Randy Presuhn wrote: >Hi - >I see the announcement for the availability of the revised initial >registry draft has >been sent out. (Thanks to Doug and to the Secretariat for the quick >turnaround!) > >We'll have a BRIEF second WG last call on this document, and I'd like to limit >the scope of this last call to verifying that changes agreed during >the first WG last call are properly reflected by the text. (Of course, if >anyone >finds a substantial technical error, we'd like to hear about it now rather >than >waiting for the IETF last call.) This last call will end Monday, August >8. The >draft is available at >http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt > >I'd like those who take the time to look at this document to post a message, >either to the ltru WG mailing list or to the co-chairs, indicating that >they've >read it and whether they are OK with it. We need this information for the >paperwork we need to submit along with our request to the IESG to consider >it for publication as an Informational RFC. > >Randy, ltru co-chair > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 11:26:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hbf-0003T4-8U; Thu, 04 Aug 2005 11:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hbZ-0003NV-D5 for ltru@megatron.ietf.org; Thu, 04 Aug 2005 11:25:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18785 for ; Thu, 4 Aug 2005 11:25:55 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0i8U-0006yu-58 for ltru@ietf.org; Thu, 04 Aug 2005 11:59:58 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E0hbW-0002a5-IL; Thu, 04 Aug 2005 08:25:56 -0700 Message-Id: <6.2.1.2.2.20050804154814.04c8dbe0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 04 Aug 2005 15:48:46 +0200 To: Randy Presuhn , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Identifying correct parts / version of ISO 3166 In-Reply-To: <19095338.1123158040394.JavaMail.root@wamui-backed.atl.sa.e arthlink.net> References: <19095338.1123158040394.JavaMail.root@wamui-backed.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 14:20 04/08/2005, Randy Presuhn wrote: > > It is well established practice to have the publication year just after > > the standard's number. > >Different style sheets impose different requirements. I don't know whether >there is a consensus among publishers This is an ISO 11173 conformant practice. This should not be followed. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 11:29:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0heb-0004CZ-03; Thu, 04 Aug 2005 11:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hea-0004CS-1d for ltru@megatron.ietf.org; Thu, 04 Aug 2005 11:29:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18940 for ; Thu, 4 Aug 2005 11:29:01 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0iBT-00074n-Rs for ltru@ietf.org; Thu, 04 Aug 2005 12:03:05 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E0heX-0003V0-PT; Thu, 04 Aug 2005 08:29:02 -0700 Message-Id: <6.2.1.2.2.20050804172030.04d5c9b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 04 Aug 2005 17:28:53 +0200 To: "Doug Ewell" From: r&d afrac Subject: Re: [Ltru] Re: revised editor's copy online In-Reply-To: <005201c598ff$fed9dba0$030aa8c0@DEWELL> References: <20050804135045.VWQH25460.edge4.adelphia.net@megatron.ietf.org> <005201c598ff$fed9dba0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 16:22 04/08/2005, Doug Ewell said: >I noticed that the reference to ISO 3166-1 in draft-registry-10 is to >the 1997 edition, while the reference in draft-initial-03 is to the 1988 >edition. I'll be happy to change this in draft-initial as a Second Last >Call item (text not reflecting agreed-upon changes), if the co-chairs >wish. Dear Dooug, Do not worry too much. Editor changes. There may be some time before the Draft is approved as it depends on its normative main Draft which will not be approved before a long. So, you will have then to enter the then appropriate version. By that time Channel Islands may be in ISO 3166-1, so you will also have to change the sections. The work is clean and neat. Thank you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 12:45:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0iqF-0002fX-9v; Thu, 04 Aug 2005 12:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0iqE-0002fQ-KB for ltru@megatron.ietf.org; Thu, 04 Aug 2005 12:45:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24001 for ; Thu, 4 Aug 2005 12:45:07 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0jN9-000143-13 for ltru@ietf.org; Thu, 04 Aug 2005 13:19:12 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0iq8-0003P0-00 for ltru@ietf.org; Thu, 04 Aug 2005 12:45:04 -0400 Message-ID: <4685351.1123173904440.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Thu, 4 Aug 2005 18:45:04 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] add internationalization considerations to initial registry draft? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - It's not clear to me how one would apply the recommendations of RFC 2277 in this case. Could you suggest some meaningful text to go in the internationalizations considerations section you request? Unless such text adds significant technical value to the document, I would argue against making such a change at this late stage in the process. Since the only use of the contents of this document is to initialize the IANA registry, I believe any internationalization considerations would belong in the registry document, rather than here. I note that both the abstract and the document text are quite clear that they are talking about the IANA registry, so I believe the editor faithfully applied the change I (not Addison, as you write) suggested. On the issue of ISO 11173 alignment, this issue is OLD and rejected. Reopening at this time has not been justified. Randy, ltru co-chair -----Original Message----- From: r&d afrac Sent: Aug 4, 2005 3:47 PM To: Randy Presuhn , ltru@ietf.org Subject: Re: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 No comment on this text which lists typographer related information. Except that it is not defined by any RFC, that its Informational status does not seem to fit with its normative quality (except if the main Draft only claims Informational status what would be appropriate, as describing an application related group intents). I note that Addison's change in abstract to make sure it is only IANA related, has not be copied into the text of the document, which still can be ISO 11173 conformant. It has no Internationlisation considerations section what is innapropriate as it should document why it is not internationalised. jfc At 11:11 04/08/2005, Randy Presuhn wrote: >Hi - >I see the announcement for the availability of the revised initial >registry draft has >been sent out. (Thanks to Doug and to the Secretariat for the quick >turnaround!) > >We'll have a BRIEF second WG last call on this document, and I'd like to limit >the scope of this last call to verifying that changes agreed during >the first WG last call are properly reflected by the text. (Of course, if >anyone >finds a substantial technical error, we'd like to hear about it now rather >than >waiting for the IETF last call.) This last call will end Monday, August >8. The >draft is available at >http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt > >I'd like those who take the time to look at this document to post a message, >either to the ltru WG mailing list or to the co-chairs, indicating that >they've >read it and whether they are OK with it. We need this information for the >paperwork we need to submit along with our request to the IESG to consider >it for publication as an Informational RFC. > >Randy, ltru co-chair > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 17:21:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0n9Z-0006Er-Mr; Thu, 04 Aug 2005 17:21:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0n9X-0006Ek-D6 for ltru@megatron.ietf.org; Thu, 04 Aug 2005 17:21:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10225 for ; Thu, 4 Aug 2005 17:21:20 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-red.bigfish.com ([216.148.222.61] helo=mail85-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ngS-0008LQ-HP for ltru@ietf.org; Thu, 04 Aug 2005 17:55:27 -0400 Received: from mail85-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail85-red-R.bigfish.com (Postfix) with ESMTP id EC4D22F85AA; Thu, 4 Aug 2005 21:20:59 +0000 (UTC) X-BigFish: VP Received: by mail85-red.bigfish.com (MessageSwitch) id 1123190459617338_19715; Thu, 4 Aug 2005 21:20:59 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail85-red.bigfish.com (Postfix) with ESMTP id 8E9A32F857C; Thu, 4 Aug 2005 21:20:59 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005080414290130:159393 ; Thu, 4 Aug 2005 14:29:01 -0700 To: Randy Presuhn Subject: Re: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Thu, 4 Aug 2005 14:17:48 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 08/04/2005 14:17:59, Serialize complete at 08/04/2005 14:17:59, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 08/04/2005 02:29:01 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 08/04/2005 02:29:01 PM, Serialize complete at 08/04/2005 02:29:01 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I have read the document and support it. Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Randy Presuhn Sent by: ltru-bounces@lists.ietf.org 08/04/2005 02:11 AM Please respond to Randy Presuhn To: ltru@ietf.org cc: Subject: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 Hi - I see the announcement for the availability of the revised initial registry draft has been sent out. (Thanks to Doug and to the Secretariat for the quick turnaround!) We'll have a BRIEF second WG last call on this document, and I'd like to limit the scope of this last call to verifying that changes agreed during the first WG last call are properly reflected by the text. (Of course, if anyone finds a substantial technical error, we'd like to hear about it now rather than waiting for the IETF last call.) This last call will end Monday, August 8. The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt I'd like those who take the time to look at this document to post a message, either to the ltru WG mailing list or to the co-chairs, indicating that they've read it and whether they are OK with it. We need this information for the paperwork we need to submit along with our request to the IESG to consider it for publication as an Informational RFC. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 04 17:34:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0nLx-0000Oo-RB; Thu, 04 Aug 2005 17:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0nLv-0000Nx-SB for ltru@megatron.ietf.org; Thu, 04 Aug 2005 17:34:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10591 for ; Thu, 4 Aug 2005 17:34:09 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0nst-00009G-Hj for ltru@ietf.org; Thu, 04 Aug 2005 18:08:16 -0400 X-Medic-Info: 3ffa.42f289cb.0 H4aUG7UJpfhwGRu1 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 9685F42B1; Thu, 4 Aug 2005 23:34:03 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Thu, 4 Aug 2005 23:34:03 +0200 (CEST) Message-ID: <60321.83.248.26.202.1123191243.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C5A7B50@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0C5A7B50@irvmbxw01.quest.com> Date: Thu, 4 Aug 2005 23:34:03 +0200 (CEST) Subject: Re: [Ltru] LTRU submission: draft-ietf-ltru-registry-10 From: "Kent Karlsson" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I'm sorry, but I'm still not happy with the references. 9.1 Normative References [ISO10646] International Organization for Standardization, "ISO/IEC 10646:2003. Information technology -- Universal Multiple- Octet Coded Character Set (UCS), as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts", 2003. ----> Remove the excess spaces, remove the ", as, from time to time, ----> amended, replaced by a new edition or expanded by the ----> addition of new parts" as that is absolutely not part of ----> the title. (And recall my note about the ISO convention of dated ----> and undated references.) No need to repeat the year twice for any ----> of the references. [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166- 1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 1997. ----> What about part 3? [ISO639-1] International Organization for Standardization, "ISO 639- 1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", 2002. [ISO639-2] International Organization for Standardization, "ISO 639- 2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition", 1998. ----> Either consistently include edition (for dated references...) ----> or consistenly exclude it. [ISO646] ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991. ----> I thought it was agreed that "ISO/IEC 646 JTC 1/SC 2" should not be ----> author (the ISO WG is never cited in referring to published standar= ds). [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. ----> I still think this one should not be listed as "normative". It is ----> more "metanormative" for IETF standards, and would then not need to= be ----> listed as "normative" for any particular RFC. (ISO standards never ----> refer to the "ISO directives" normatively, only informatively.) [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. ----> I thought it was agreed that this wasn't (and cannot be) a normativ= e ----> reference. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. ----> I thought it was agreed that this wasn't a normative reference here= . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ----> I still think this one should not be listed as "normative". It is ----> more "metanormative" for IETF standards, and would then not need to= be ----> listed as "normative" for any particular RFC. [RFC2234bis] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 (work in progress), March 2005. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. ----> I thought it was agreed that this wasn't a normative reference. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. ----> I thought it was agreed that this wasn't a normative reference here= . [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. ----> I thought it was agreed that this wasn't a normative reference. [UN_M.49] Statistical Division, United Nations, "Standard Country or Area Codes for Statistical Use", UN Standard Country or Area Codes for Statistical Use, Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 00:55:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uFA-0001zu-97; Fri, 05 Aug 2005 00:55:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uF7-0001zg-ME for ltru@megatron.ietf.org; Fri, 05 Aug 2005 00:55:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00454 for ; Fri, 5 Aug 2005 00:55:34 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0um7-0001dF-6H for ltru@ietf.org; Fri, 05 Aug 2005 01:29:45 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E0uEw-0008Px-So; Thu, 04 Aug 2005 21:55:27 -0700 Message-Id: <6.2.1.2.2.20050805061712.05c5eeb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 05 Aug 2005 06:55:18 +0200 To: Randy Presuhn , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] add internationalization considerations to initial registry draft? In-Reply-To: <4685351.1123173904440.JavaMail.root@wamui-valley.atl.sa.ea rthlink.net> References: <4685351.1123173904440.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Randy, At 18:45 04/08/2005, Randy Presuhn wrote: >It's not clear to me how one would apply the recommendations of RFC 2277 >in this case. Could you suggest some meaningful text to go in the >internationalizations considerations section you request? Unless such >text adds >significant technical value to the document, I would argue against making such >a change at this late stage in the process. Since the only use of the >contents >of this document is to initialize the IANA registry, I believe any >internationalization >considerations would belong in the registry document, rather than here. I suppose you are right. But it is rather odd to document all the languages and the scripts of the world in ASCII without explaning why. Some people could think it is because of a natural superiority of the Anglicanus Mens. >I note that both the abstract and the document text are quite clear that they >are talking about the IANA registry, so I believe the editor faithfully >applied the >change I (not Addison, as you write) suggested. Oh! I know that you asked to make sure you would block one of my remarks, just in case. Addison said he did it. What I say is that the correction is in the Abstract only. The IANA exclusive is not repeated in the text. >On the issue of ISO 11173 alignment, this issue is OLD and >rejected. Reopening >at this time has not been justified. I just wanted to make sure you would confirm it, because the text still could be construed as permitting such an alignment. May be this could be indicated. I suggest the following text: "This document establishes an independent registry. This registry is not intended to be related to any registry, database or content not documented in this document." I suppose this is what you want to say. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 01:24:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uhV-0007VC-PF; Fri, 05 Aug 2005 01:24:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uhT-0007Sm-UJ for ltru@megatron.ietf.org; Fri, 05 Aug 2005 01:24:55 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01572 for ; Fri, 5 Aug 2005 01:24:54 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050805052423.PFRW29002.mta9.adelphia.net@DEWELL> for ; Fri, 5 Aug 2005 01:24:23 -0400 Message-ID: <001901c5997d$e20d2080$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050804160646.ZOVP29598.mta4.adelphia.net@megatron.ietf.org> Date: Thu, 4 Aug 2005 22:23:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: revised editor's copy online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: >> I noticed that the reference to ISO 3166-1 in draft-registry-10 is to >> the 1997 edition, while the reference in draft-initial-03 is to the >> 1988 edition. I'll be happy to change this in draft-initial as a >> Second Last Call item (text not reflecting agreed-upon changes), if >> the co-chairs wish. > > Doug, can you update the (more readable) html version on > http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.html? I can do that, but I thought Randy (while agreeing with the change) had sort of casually suggested that it should be batched with other changes. This would be draft-initial-04, right? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 01:42:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uyl-0002Tq-QD; Fri, 05 Aug 2005 01:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uyj-0002Td-8G for ltru@megatron.ietf.org; Fri, 05 Aug 2005 01:42:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02188 for ; Fri, 5 Aug 2005 01:42:43 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0vVk-0002VN-D7 for ltru@ietf.org; Fri, 05 Aug 2005 02:16:53 -0400 Received: from dul1shollenbl1 ([::ffff:86.255.31.245]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 05 Aug 2005 01:42:40 -0400 id 00564957.42F2FC50.0000694A From: "Scott Hollenbeck" To: "'Kent Karlsson'" Subject: RE: [Ltru] LTRU submission: draft-ietf-ltru-registry-10 Date: Fri, 5 Aug 2005 01:43:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <60321.83.248.26.202.1123191243.squirrel@webmail.chalmers.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcWZPFTRVrLzn8g3R42y32TfzGEwfQARAMwA Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > ----> I still think this one should not be listed as > "normative". It is > ----> more "metanormative" for IETF standards, and would then > not need to be > ----> listed as "normative" for any particular RFC. There's no such thing as "metanormative". It either needs to be listed as a normative reference (if it is), or it should be omitted (if it isn't). If 2119 keywords are used, it's a normative reference. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 01:49:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0v5U-0003gi-Cw; Fri, 05 Aug 2005 01:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0v5T-0003gV-68 for ltru@megatron.ietf.org; Fri, 05 Aug 2005 01:49:43 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02434 for ; Fri, 5 Aug 2005 01:49:27 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050805054857.SEMP14360.mta13.adelphia.net@DEWELL> for ; Fri, 5 Aug 2005 01:48:57 -0400 Message-ID: <002601c59981$52f8dfc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 4 Aug 2005 22:48:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: > I'm sorry, but I'm still not happy with the references. I'm sorry to hear that, because it seems to me that most of the things you're not happy with (a) are dictated by tools we do not have the power to change, at least not today, (b) are not any different from other RFCs that reference ISO standards, and (c) can be changed by the RFC editor anyway if he sees fit. > [ISO10646] > International Organization for Standardization, "ISO/IEC > 10646:2003. Information technology -- Universal Multiple- > Octet Coded Character Set (UCS), as, from time to time, > amended, replaced by a new edition or expanded by the > addition of new parts", 2003. > > ---> Remove the excess spaces, What excess spaces? Surely you're not talking about the double space after "10646:2003." A double space in that situation is actually preferred over a single space; see Section 3.1, item 7 of draft-rfc-editor-rfc2223bis-08.txt. But surely a single "excess" space in a reference is not cause for rejecting a document. > remove the ", as, from time to time, > ---> amended, replaced by a new edition or expanded by the > ---> addition of new parts" as that is absolutely not part of > ---> the title. Probably true. > No need to repeat the year twice for any > ---> of the references. Except that (a) we were supposed to use the name of the document from the online ISO catalog, and (b) xml2rfc makes us insert a date. > [ISO3166-1] > International Organization for Standardization, "ISO 3166- > 1:1997. Codes for the representation of names of > countries and their subdivisions -- Part 1: Country > codes", 1997. > > ---> What about part 3? The draft doesn't reference part 3. > [ISO639-1] > International Organization for Standardization, "ISO 639- > 1:2002. Codes for the representation of names of languages > -- Part 1: Alpha-2 code", 2002. > > [ISO639-2] > International Organization for Standardization, "ISO 639- > 2:1998. Codes for the representation of names of languages > -- Part 2: Alpha-3 code, first edition", 1998. > > ---> Either consistently include edition (for dated references...) > ---> or consistenly exclude it. I thought you wanted us to use the listings straight out of the online ISO catalog. That is what they have. > [UN_M.49] Statistical Division, United Nations, "Standard Country or > Area Codes for Statistical Use", UN Standard Country or > Area Codes for Statistical Use, Revision 4 (United Nations > publication, Sales No. 98.XVII.9, June 1999. OK, my turn. I take this opportunity to point out, as I have done privately, that the correct name is "United Nations Statistics Division," not "Statistical." -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 03:58:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0x6K-0000uS-2l; Fri, 05 Aug 2005 03:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0x6I-0000uI-GW for ltru@megatron.ietf.org; Fri, 05 Aug 2005 03:58:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23479 for ; Fri, 5 Aug 2005 03:58:40 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xdL-0006eR-SH for ltru@ietf.org; Fri, 05 Aug 2005 04:32:52 -0400 Received: from mswamui-bichon.atl.sa.earthlink.net ([209.86.224.26] helo=wamui-bichon.atl.sa.earthlink.net) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0x6C-0004e1-00 for ltru@ietf.org; Fri, 05 Aug 2005 03:58:36 -0400 Message-ID: <5964532.1123228716370.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Date: Fri, 5 Aug 2005 09:58:36 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] add internationalization considerations to initial registry draft? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - We're in second working group last call. Jefsey has kindly provided specific text he would like added to the initial registry draft, which is planned to be submitted for consideration for publication as an Informational RFC. Does the WG believe that this addition is technically necessary? Randy, ltru co-chair -----Original Message----- From: r&d afrac Sent: Aug 5, 2005 6:55 AM To: Randy Presuhn , ltru@ietf.org Subject: Re: [Ltru] add internationalization considerations to initial registry draft? Dear Randy, At 18:45 04/08/2005, Randy Presuhn wrote: >It's not clear to me how one would apply the recommendations of RFC 2277 >in this case. Could you suggest some meaningful text to go in the >internationalizations considerations section you request? Unless such >text adds >significant technical value to the document, I would argue against making such >a change at this late stage in the process. Since the only use of the >contents >of this document is to initialize the IANA registry, I believe any >internationalization >considerations would belong in the registry document, rather than here. I suppose you are right. But it is rather odd to document all the languages and the scripts of the world in ASCII without explaning why. Some people could think it is because of a natural superiority of the Anglicanus Mens. >I note that both the abstract and the document text are quite clear that they >are talking about the IANA registry, so I believe the editor faithfully >applied the >change I (not Addison, as you write) suggested. Oh! I know that you asked to make sure you would block one of my remarks, just in case. Addison said he did it. What I say is that the correction is in the Abstract only. The IANA exclusive is not repeated in the text. >On the issue of ISO 11173 alignment, this issue is OLD and >rejected. Reopening >at this time has not been justified. I just wanted to make sure you would confirm it, because the text still could be construed as permitting such an alignment. May be this could be indicated. I suggest the following text: "This document establishes an independent registry. This registry is not intended to be related to any registry, database or content not documented in this document." I suppose this is what you want to say. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 04:03:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xBK-0002ye-Lh; Fri, 05 Aug 2005 04:03:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xBJ-0002vQ-5G for ltru@megatron.ietf.org; Fri, 05 Aug 2005 04:03:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23743 for ; Fri, 5 Aug 2005 04:03:50 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xiM-0006oo-7h for ltru@ietf.org; Fri, 05 Aug 2005 04:38:02 -0400 Received: from mswamui-bichon.atl.sa.earthlink.net ([209.86.224.26] helo=wamui-bichon.atl.sa.earthlink.net) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0xBH-0005P8-00 for ltru@ietf.org; Fri, 05 Aug 2005 04:03:51 -0400 Message-ID: <20785174.1123229031189.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Date: Fri, 5 Aug 2005 10:03:51 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Subject: Re: [Ltru] add internationalization considerations to initial registry draft? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - As a technical contributor, I believe there is no technical need for the proposed addition. further, I believe that the proposed text is technically incorrect: the initial registry document does NOT "establish" the registry. Randy -----Original Message----- From: Randy Presuhn Sent: Aug 5, 2005 9:58 AM To: ltru@ietf.org Subject: Re: [Ltru] add internationalization considerations to initial registry draft? Hi - We're in second working group last call. Jefsey has kindly provided specific text he would like added to the initial registry draft, which is planned to be submitted for consideration for publication as an Informational RFC. Does the WG believe that this addition is technically necessary? Randy, ltru co-chair -----Original Message----- From: r&d afrac Sent: Aug 5, 2005 6:55 AM To: Randy Presuhn , ltru@ietf.org Subject: Re: [Ltru] add internationalization considerations to initial registry draft? Dear Randy, At 18:45 04/08/2005, Randy Presuhn wrote: >It's not clear to me how one would apply the recommendations of RFC 2277 >in this case. Could you suggest some meaningful text to go in the >internationalizations considerations section you request? Unless such >text adds >significant technical value to the document, I would argue against making such >a change at this late stage in the process. Since the only use of the >contents >of this document is to initialize the IANA registry, I believe any >internationalization >considerations would belong in the registry document, rather than here. I suppose you are right. But it is rather odd to document all the languages and the scripts of the world in ASCII without explaning why. Some people could think it is because of a natural superiority of the Anglicanus Mens. >I note that both the abstract and the document text are quite clear that they >are talking about the IANA registry, so I believe the editor faithfully >applied the >change I (not Addison, as you write) suggested. Oh! I know that you asked to make sure you would block one of my remarks, just in case. Addison said he did it. What I say is that the correction is in the Abstract only. The IANA exclusive is not repeated in the text. >On the issue of ISO 11173 alignment, this issue is OLD and >rejected. Reopening >at this time has not been justified. I just wanted to make sure you would confirm it, because the text still could be construed as permitting such an alignment. May be this could be indicated. I suggest the following text: "This document establishes an independent registry. This registry is not intended to be related to any registry, database or content not documented in this document." I suppose this is what you want to say. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 04:05:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xDD-0003h0-UM; Fri, 05 Aug 2005 04:05:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xDC-0003gJ-KD for ltru@megatron.ietf.org; Fri, 05 Aug 2005 04:05:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23825 for ; Fri, 5 Aug 2005 04:05:48 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xkE-0006rt-K6 for ltru@ietf.org; Fri, 05 Aug 2005 04:40:00 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 5 Aug 2005 08:05:33 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IKQ00BANP59LW@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 05 Aug 2005 09:05:33 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Fri, 05 Aug 2005 09:05:33 +0100 Date: Fri, 05 Aug 2005 09:05:32 +0100 From: Misha Wolf Subject: RE: [Ltru] add internationalization considerations to initial registry draft? To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF7804422CD9@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] add internationalization considerations to initial registry draft? Thread-Index: AcWZk7ov3zIeu1iJSmCgKDb0Nvhf4gAAHpUA content-class: urn:content-classes:message X-OriginalArrivalTime: 05 Aug 2005 08:05:33.0194 (UTC) FILETIME=[74191EA0:01C59994] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The proposed text is unhelpful and should not be included. Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Randy Presuhn Sent: 05 August 2005 08:59 To: ltru@ietf.org Subject: Re: [Ltru] add internationalization considerations to initial registry draft? Hi - We're in second working group last call. Jefsey has kindly provided specific text he would like added to the initial registry draft, which is planned to be submitted for consideration for publication as an Informational RFC. Does the WG believe that this addition is technically necessary? Randy, ltru co-chair [...] "This document establishes an independent registry. This registry is not intended to be related to any registry, database or content not documented=20 in this document." ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 04:07:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xF9-0004GJ-8v; Fri, 05 Aug 2005 04:07:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xF7-0004GE-Te for ltru@megatron.ietf.org; Fri, 05 Aug 2005 04:07:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23897 for ; Fri, 5 Aug 2005 04:07:47 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xmA-0006v5-BL for ltru@ietf.org; Fri, 05 Aug 2005 04:41:59 -0400 X-Medic-Info: 20bb.42f31e4e.0 U9z3vtvJH1TuogFx Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id F3967413D; Fri, 5 Aug 2005 10:07:42 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Fri, 5 Aug 2005 10:07:43 +0200 (CEST) Message-ID: <60108.83.248.26.202.1123229263.squirrel@webmail.chalmers.se> In-Reply-To: <002601c59981$52f8dfc0$030aa8c0@DEWELL> References: <002601c59981$52f8dfc0$030aa8c0@DEWELL> Date: Fri, 5 Aug 2005 10:07:43 +0200 (CEST) Subject: Re: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 From: "Kent Karlsson" To: "Doug Ewell" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Kent Karlsson wrote: > >> I'm sorry, but I'm still not happy with the references. > > I'm sorry to hear that, because it seems to me that most of the things > you're not happy with (a) are dictated by tools we do not have the powe= r > to change, at least not today, I did not comment on that in my previous mail. > (b) are not any different from other RFCs > that reference ISO standards, Ditto. > and (c) can be changed by the RFC editor > anyway if he sees fit. Maybe so. >> No need to repeat the year twice for any >> ---> of the references. > > Except that (a) we were supposed to use the name of the document from > the online ISO catalog, and (b) xml2rfc makes us insert a date. There is no need to mention the year twice. If it cannot be put only wher= e ISO puts it, include it only where the tool requires it. >> ---> Either consistently include edition (for dated references...) >> ---> or consistenly exclude it. > > I thought you wanted us to use the listings straight out of the online > ISO catalog. Yes. > That is what they have. No. Look again. The ISO catalogue (at www.iso.org) is consistent on this point. The edition nr. is always given, but separately from the title. >> [UN_M.49] Statistical Division, United Nations, "Standard Country or >> Area Codes for Statistical Use", UN Standard Country or >> Area Codes for Statistical Use, Revision 4 (United Nations >> publication, Sales No. 98.XVII.9, June 1999. > > OK, my turn. I take this opportunity to point out, as I have done > privately, that the correct name is "United Nations Statistics > Division," not "Statistical." Which I corrected too, in the edited version of the references section that I sent the other day. I did double-check all the non-RFC references. Again, I don't see the need to repeat subitems twice, though here it is not the year that is repeated. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 04:09:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xGz-0004VD-2P; Fri, 05 Aug 2005 04:09:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xGy-0004V8-Hx for ltru@megatron.ietf.org; Fri, 05 Aug 2005 04:09:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23989 for ; Fri, 5 Aug 2005 04:09:42 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xo1-0006y8-Rk for ltru@ietf.org; Fri, 05 Aug 2005 04:43:54 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j7589apX010308; Fri, 5 Aug 2005 11:09:36 +0300 (EEST) Message-ID: <42F31EC0.9050007@kotus.fi> Date: Fri, 05 Aug 2005 11:09:36 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] add internationalization considerations to initial registry draft? References: <5964532.1123228716370.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Re attached: I don't believe that the addition is technically necessary, nor is it particularly helpful as a clarification. Erkki I. Kolehmainen (RILF) Randy Presuhn wrote: > Hi - > > We're in second working group last call. Jefsey has kindly provided > specific text he would like added to the initial registry draft, which is > planned to be submitted for consideration for publication as an Informational > RFC. Does the WG believe that this addition is technically necessary? > > Randy, ltru co-chair > > -----Original Message----- > From: r&d afrac > Sent: Aug 5, 2005 6:55 AM > To: Randy Presuhn , ltru@ietf.org > Subject: Re: [Ltru] add internationalization considerations to initial registry draft? > > Dear Randy, > > At 18:45 04/08/2005, Randy Presuhn wrote: > >>It's not clear to me how one would apply the recommendations of RFC 2277 >>in this case. Could you suggest some meaningful text to go in the >>internationalizations considerations section you request? Unless such >>text adds >>significant technical value to the document, I would argue against making such >>a change at this late stage in the process. Since the only use of the >>contents >>of this document is to initialize the IANA registry, I believe any >>internationalization >>considerations would belong in the registry document, rather than here. >> > > I suppose you are right. > But it is rather odd to document all the languages and the scripts of the > world in ASCII without explaning why. Some people could think it is because > of a natural superiority of the Anglicanus Mens. > > >>I note that both the abstract and the document text are quite clear that they >>are talking about the IANA registry, so I believe the editor faithfully >>applied the >>change I (not Addison, as you write) suggested. >> > > Oh! I know that you asked to make sure you would block one of my remarks, > just in case. Addison said he did it. What I say is that the correction is > in the Abstract only. The IANA exclusive is not repeated in the text. > > >>On the issue of ISO 11173 alignment, this issue is OLD and >>rejected. Reopening >>at this time has not been justified. >> > > I just wanted to make sure you would confirm it, because the text still > could be construed as permitting such an alignment. May be this could be > indicated. I suggest the following text: > > "This document establishes an independent registry. This registry is not > intended to be related to any registry, database or content not documented > in this document." > > I suppose this is what you want to say. > jfc > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 04:19:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xOA-00074f-Pp; Fri, 05 Aug 2005 04:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xO7-00070d-He for ltru@megatron.ietf.org; Fri, 05 Aug 2005 04:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24864 for ; Fri, 5 Aug 2005 04:17:05 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xvB-0007Nv-3E for ltru@ietf.org; Fri, 05 Aug 2005 04:51:17 -0400 X-Medic-Info: 1999.42f32082.0 kiFyfPipU6k6QDjx Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 394764558; Fri, 5 Aug 2005 10:17:06 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Fri, 5 Aug 2005 10:17:06 +0200 (CEST) Message-ID: <60174.83.248.26.202.1123229826.squirrel@webmail.chalmers.se> In-Reply-To: References: <60321.83.248.26.202.1123191243.squirrel@webmail.chalmers.se> Date: Fri, 5 Aug 2005 10:17:06 +0200 (CEST) Subject: RE: [Ltru] LTRU submission: draft-ietf-ltru-registry-10 From: "Kent Karlsson" To: "Scott Hollenbeck" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> ----> I still think this one should not be listed as >> "normative". It is >> ----> more "metanormative" for IETF standards, and would then >> not need to be >> ----> listed as "normative" for any particular RFC. > > There's no such thing as "metanormative". I did put it in quotes. > It either needs to be listed as a > normative reference (if it is), or it should be omitted (if it isn't). = If > 2119 keywords are used, it's a normative reference. Well, I (nor anyone else apparently) would dream of putting the ISO (IEC) directives in as a normative reference in an ISO (IEC) standard. I've eve= n gotten the comment from the ISO central secretariat that one should not even include "shall" and "should" in the list of defined terms, since their use is dictated by the directives, and thus applies to all ISO (and IEC) standards. My take is that normative references are references that are at the technical level, not at the document authoring level (which is the level of the definition and use of "shall" and "should"). /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 04:43:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xo3-0005nI-8r; Fri, 05 Aug 2005 04:43:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xo1-0005lo-L3 for ltru@megatron.ietf.org; Fri, 05 Aug 2005 04:43:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26371 for ; Fri, 5 Aug 2005 04:43:51 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0yL5-0008GW-1d for ltru@ietf.org; Fri, 05 Aug 2005 05:18:03 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j758hppX012575; Fri, 5 Aug 2005 11:43:51 +0300 (EEST) Message-ID: <42F326C7.8080503@kotus.fi> Date: Fri, 05 Aug 2005 11:43:51 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 References: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I've read the subject document and I'm OK with it. Sincerely, Erkki I. Kolehmainen (RILF) Randy Presuhn wrote: > Hi - > > I see the announcement for the availability of the revised initial registry draft has > been sent out. (Thanks to Doug and to the Secretariat for the quick turnaround!) > > We'll have a BRIEF second WG last call on this document, and I'd like to limit > the scope of this last call to verifying that changes agreed during > the first WG last call are properly reflected by the text. (Of course, if anyone > finds a substantial technical error, we'd like to hear about it now rather than > waiting for the IETF last call.) This last call will end Monday, August 8. The > draft is available at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt > > I'd like those who take the time to look at this document to post a message, > either to the ltru WG mailing list or to the co-chairs, indicating that they've > read it and whether they are OK with it. We need this information for the > paperwork we need to submit along with our request to the IESG to consider > it for publication as an Informational RFC. > > Randy, ltru co-chair > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 04:46:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xqE-0006fh-WC; Fri, 05 Aug 2005 04:46:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xqC-0006fU-Cn for ltru@megatron.ietf.org; Fri, 05 Aug 2005 04:46:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26609 for ; Fri, 5 Aug 2005 04:46:06 -0400 (EDT) Received: from pop05.mail.atl.earthlink.net ([207.69.200.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0yNG-0008O3-9P for ltru@ietf.org; Fri, 05 Aug 2005 05:20:18 -0400 Received: from mswamui-blood.atl.sa.earthlink.net ([209.86.224.28] helo=wamui-blood.atl.sa.earthlink.net) by pop05.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E0xq7-000314-00 for ltru@ietf.org; Fri, 05 Aug 2005 04:46:03 -0400 Message-ID: <1924989.1123231563092.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Date: Fri, 5 Aug 2005 10:46:02 +0200 (GMT+02:00) From: Randy Presuhn To: ltru@ietf.org Subject: RE: [Ltru] LTRU submission: draft-ietf-ltru-registry-10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - An understandable interpretation, but IETF practice is that documents that use the 2119 keywords treat the reference to 2119 as a normative reference. Changing that practicew is well beyond the scope of this WG; if you feel strongly about changing this practice, I'd suggest taking it up of the ietf@ietf.org mailing list. Randy, ltru co-chair -----Original Message----- From: Kent Karlsson Sent: Aug 5, 2005 10:17 AM To: Scott Hollenbeck Cc: ltru@ietf.org Subject: RE: [Ltru] LTRU submission: draft-ietf-ltru-registry-10 >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> ----> I still think this one should not be listed as >> "normative". It is >> ----> more "metanormative" for IETF standards, and would then >> not need to be >> ----> listed as "normative" for any particular RFC. > > There's no such thing as "metanormative". I did put it in quotes. > It either needs to be listed as a > normative reference (if it is), or it should be omitted (if it isn't). If > 2119 keywords are used, it's a normative reference. Well, I (nor anyone else apparently) would dream of putting the ISO (IEC) directives in as a normative reference in an ISO (IEC) standard. I've even gotten the comment from the ISO central secretariat that one should not even include "shall" and "should" in the list of defined terms, since their use is dictated by the directives, and thus applies to all ISO (and IEC) standards. My take is that normative references are references that are at the technical level, not at the document authoring level (which is the level of the definition and use of "shall" and "should"). /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 06:21:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zKt-0006Qy-FK; Fri, 05 Aug 2005 06:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zKr-0006Qt-Vz for ltru@megatron.ietf.org; Fri, 05 Aug 2005 06:21:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00781 for ; Fri, 5 Aug 2005 06:21:50 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E0zJz-0006a0-8s for ltru@lists.ietf.org; Fri, 05 Aug 2005 12:20:59 +0200 Received: from c-180-160-128.hh.dial.de.ignite.net ([62.180.160.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Aug 2005 12:20:59 +0200 Received: from nobody by c-180-160-128.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Aug 2005 12:20:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 05 Aug 2005 12:18:45 +0200 Organization: Lines: 73 Message-ID: <42F33D04.26F0@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C5A7B50@irvmbxw01.quest.com> <60321.83.248.26.202.1123191243.squirrel@webmail.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-128.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: > (And recall my note about the ISO convention of dated > and undated references.) For the "date A" (1988) business the dates are relevant. > [ISO3166-1] [...] > ----> What about part 3? Should be added / included, it's used to track code changes like YDYE. > Part 2: Alpha-3 code, first edition", 1998. > Either consistently include edition (for dated references...) > or consistenly exclude it. 1988 is a magic year here, RfC 3066 and 1766 used precisely this edition, therefore we ignored crap deprecated before 1988 like NHVU, RHZW, or VDVN. > [RFC2026] [...] > I still think this one should not be listed as "normative". Required as part of the appeal procedure in chapter 3.4 > [RFC2028] [...] > I thought it was agreed that this wasn't (and cannot be) a > normative reference. Used to explain "IESG" in the same statement where 2026 is used (normatively), so that's in fact unnecessary, 2026 has its own explanation of "IESG" in its introduction. And as long as 2860 is (ab)used to explain IANA nobody needs 2028, let alone normatively. > [RFC2047] [...] > I thought it was agreed that this wasn't a normative > reference here. Should be on the same level as 2231 for consistency. > [RFC2119] [...] > I still think this one should not be listed as "normative". > It is more "metanormative" for IETF standards No, it is NOT "metanormative", you're free to use your own funny definitions for MUST, SHOULD, and STRONGLY DISCOURAGED. So if you want the 2119 definitions 2119 IS normative. Just leave 2119 alone, it belongs to "hums" and "BoFs" and other IETF rituals. > [RFC2434] [...] > I thought it was agreed that this wasn't a normative reference Not sure about "agreed", but FWIW "seconded". > [RFC2781] Dito. > [RFC3552] Dito. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 06:33:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zVy-0000Cd-SA; Fri, 05 Aug 2005 06:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zVx-00009c-Fh for ltru@megatron.ietf.org; Fri, 05 Aug 2005 06:33:21 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01109 for ; Fri, 5 Aug 2005 06:33:18 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E0zUj-0007h3-2o for ltru@lists.ietf.org; Fri, 05 Aug 2005 12:32:05 +0200 Received: from c-180-160-128.hh.dial.de.ignite.net ([62.180.160.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Aug 2005 12:32:05 +0200 Received: from nobody by c-180-160-128.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Aug 2005 12:32:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 05 Aug 2005 12:29:53 +0200 Organization: Lines: 12 Message-ID: <42F33FA1.6D61@xyzzy.claranet.de> References: <4685351.1123173904440.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-128.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: add internationalization considerations to initial registry draft? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > It's not clear to me how one would apply the recommendations > of RFC 2277 in this case. We have I18N considerations, twice: the whole document, and especially chapter 7 "character set considerations". So far I thought that's obvious. 2277 says SHOULD be "I18N considerations", but for our text "character set considerations" nails it more precisely. Bye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 08:06:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10yR-0005JE-Rx; Fri, 05 Aug 2005 08:06:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10y8-00051N-PP for ltru@megatron.ietf.org; Fri, 05 Aug 2005 08:06:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05977 for ; Fri, 5 Aug 2005 08:06:31 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E11VC-0005OC-AD for ltru@ietf.org; Fri, 05 Aug 2005 08:40:44 -0400 X-Medic-Info: 67e4.42f35642.0 7iiyOiN8npBm0cec Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id EF39D41D6; Fri, 5 Aug 2005 14:06:26 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Fri, 5 Aug 2005 14:06:26 +0200 (CEST) Message-ID: <61590.83.248.26.202.1123243586.squirrel@webmail.chalmers.se> In-Reply-To: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlink.net> References: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlink.net> Date: Fri, 5 Aug 2005 14:06:26 +0200 (CEST) Subject: Re: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 From: "Kent Karlsson" To: "Randy Presuhn" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > We'll have a BRIEF second WG last call on this document, and I'd like t= o > limit > the scope of this last call to verifying that changes agreed during > the first WG last call are properly reflected by the text. (Of course,= if > anyone > finds a substantial technical error, we'd like to hear about it now rat= her > than > waiting for the IETF last call.) This last call will end Monday, Augus= t > 8. The > draft is available at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt > > I'd like those who take the time to look at this document to post a > message, > either to the ltru WG mailing list or to the co-chairs, indicating that > they've > read it and whether they are OK with it. We need this information for = the > paperwork we need to submit along with our request to the IESG to consi= der > it for publication as an Informational RFC. 1. 'no' should be deprecated in favor of 'nb'. That is, one should assume 'nb' if 'no' is used. 'no' is is (now) in theory a language group code, but all languages in that group have individual codes (nb and nn); not counting dialects. But effectively, in practice, 'nb' *replaces* 'no' ('nn' is much rarer than 'nb'). But I guess this can be dealt with later on (I hope I did not miss any provision preventing such a fix). 2. Will all the "added" dates be changed to that of the date when the actual registry goes "live"? (As well for the initial value of the "File-Date".) 3. There is no mention about phasing out the old registry (or perhaps I missed that), either in -initial or -registry. Is the old registry to be kept permanently? Or removed at some later date. An immediate retirement/replacement of the old registry might not be so good. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 08:30:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11Lf-0002NJ-9c; Fri, 05 Aug 2005 08:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11LS-0002NA-M9 for ltru@megatron.ietf.org; Fri, 05 Aug 2005 08:30:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07172 for ; Fri, 5 Aug 2005 08:30:37 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E11sX-000625-Ft for ltru@ietf.org; Fri, 05 Aug 2005 09:04:50 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j75CUNhS004710; Fri, 5 Aug 2005 08:30:23 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 5 Aug 2005 08:30:18 -0400 Date: Fri, 5 Aug 2005 08:30:18 -0400 From: "John.Cowan" To: Randy Presuhn Subject: Re: [Ltru] add internationalization considerations to initial registry draft? Message-ID: <20050805123018.GF20004@NYCMJCOWA2> References: <5964532.1123228716370.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5964532.1123228716370.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > "This document establishes an independent registry. This registry is not > intended to be related to any registry, database or content not documented > in this document." -1. It doesn't remove any confusions in practice. -- Take two turkeys, one goose, four John Cowan cabbages, but no duck, and mix them http://www.ccil.org/~cowan together. After one taste, you'll duck jcowan@reutershealth.com soup the rest of your life. http://www.reutershealth.com --Groucho _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 09:31:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12IL-0000jg-Uj; Fri, 05 Aug 2005 09:31:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12IL-0000jX-4E for ltru@megatron.ietf.org; Fri, 05 Aug 2005 09:31:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10247 for ; Fri, 5 Aug 2005 09:31:27 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E12pR-0007fo-Ds for ltru@ietf.org; Fri, 05 Aug 2005 10:05:41 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E12IE-00013y-AS; Fri, 05 Aug 2005 06:31:22 -0700 Message-Id: <6.2.1.2.2.20050805142549.04ca76d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 05 Aug 2005 15:31:14 +0200 To: Randy Presuhn , ltru@ietf.org From: r&d afrac In-Reply-To: <20785174.1123229031189.JavaMail.root@wamui-bichon.atl.sa.e arthlink.net> References: <20785174.1123229031189.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Subject: [Ltru] ISO 11173 (non) alignment in main draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy, I read your comment. So, I will rephrase my text to express what a reader will expect from the text due to the involvement of ISO standards, directly or indirectly subject to ISO 11173 (at least via ISO 639-4). UN has no position I know of about ISO 11173, but the day they align, every developer will expect by way of consequences that IANA registries based upon and ISO and UN codes also aligns. ISO 11173 procedures and related libraries will naturally be expected to work. You can chose between the two following texts. I obviously favor (b), but I am neutral about ISO 11173 support in the context of the Draft I globally disapprove . But I am not neutral about confusion: when you decide something you should document it. I have no doubt that IESG will adopt the same position. An RFC is a document to help developers and to support a consistent common compatibility. Proposed choice (or anyone can better the texts if respecting their intent). The target is clarity. (a) "Even if the registry documented in this memo relates in part to ISO codes it is not aligned on ISO 11173 provisions." (b) "The registry documented in this memo relates in part to ISO codes and SHOULD respect their alignment on ISO 11173 provisions as they develop." NB. The open source libraries we will eventually develop, test and produce will support both "0-" escape sequence and ISO 11173 support. They will obviously also be restricted (probably as an alternative version for simpler use) to the specifications of this Draft, the day it is implemented - if this happens - to support every users (we do not compete against anyone as others do, we just strive to best serve all the users). We may very well then be in a limbo situation regarding ISO 11173 if (a) or (b) is not included, and if ISO 11173 leads to contradictions (please remember that ISO 11173 has not yet worked on the multilingual and on the networking issues). That day we could put a disclaimer indicating we rose the question at the WG and were opposed. This may be also handled in the Security section, considering that ISO 11173 (no) conformance would be a danger of confusion? But it would be a strange place for such a concern. jfc At 10:03 05/08/2005, Randy Presuhn wrote: >Hi - >As a technical contributor, I believe there is no technical need for the >proposed addition. further, I believe that the proposed text is technically >incorrect: the initial registry document does NOT "establish" the registry. > >"This document establishes an independent registry. This registry is not >intended to be related to any registry, database or content not documented >in this document." > >I suppose this is what you want to say. >jfc > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 10:00:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12kX-0007Tq-RU; Fri, 05 Aug 2005 10:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12kW-0007Tl-BL for ltru@megatron.ietf.org; Fri, 05 Aug 2005 10:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11561 for ; Fri, 5 Aug 2005 10:00:31 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E13HZ-0008OG-F2 for ltru@ietf.org; Fri, 05 Aug 2005 10:34:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Aug 2005 07:00:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] add internationalization considerations to initialregistry draft? Date: Fri, 5 Aug 2005 07:00:14 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C5A7F49@irvmbxw01.quest.com> Thread-Topic: [Ltru] add internationalization considerations to initialregistry draft? Thread-Index: AcWZk6/owXX8HgPKQdi5I+xqpOfm8AAMgIsg From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 05 Aug 2005 14:00:15.0393 (UTC) FILETIME=[0146F910:01C599C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The suggested text says nothing, so I see no reason to include it. Regarding the confusion of who does what where, I note that Doug (the = editor of draft-initial) put IANA into both the abstract and = introduction, although he then reverts from "IANA Language Subtag = Registry" to just "Language Subtag Registry" in the second paragraph. It's an editorial change, and not a very important one in my view. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?5? 0:59 > To: ltru@ietf.org > Subject: Re: [Ltru] add internationalization considerations to > initialregistry draft? >=20 > Hi - >=20 > We're in second working group last call. Jefsey has kindly provided > specific text he would like added to the initial registry draft, which = is > planned to be submitted for consideration for publication as an > Informational > RFC. Does the WG believe that this addition is technically necessary? >=20 > Randy, ltru co-chair >=20 > -----Original Message----- > From: r&d afrac > Sent: Aug 5, 2005 6:55 AM > To: Randy Presuhn , ltru@ietf.org > Subject: Re: [Ltru] add internationalization considerations to initial > registry draft? >=20 > Dear Randy, >=20 > At 18:45 04/08/2005, Randy Presuhn wrote: > >It's not clear to me how one would apply the recommendations of RFC = 2277 > >in this case. Could you suggest some meaningful text to go in the > >internationalizations considerations section you request? Unless = such > >text adds > >significant technical value to the document, I would argue against = making > such > >a change at this late stage in the process. Since the only use of = the > >contents > >of this document is to initialize the IANA registry, I believe any > >internationalization > >considerations would belong in the registry document, rather than = here. >=20 > I suppose you are right. > But it is rather odd to document all the languages and the scripts of = the > world in ASCII without explaning why. Some people could think it is > because > of a natural superiority of the Anglicanus Mens. >=20 > >I note that both the abstract and the document text are quite clear = that > they > >are talking about the IANA registry, so I believe the editor = faithfully > >applied the > >change I (not Addison, as you write) suggested. >=20 > Oh! I know that you asked to make sure you would block one of my = remarks, > just in case. Addison said he did it. What I say is that the = correction is > in the Abstract only. The IANA exclusive is not repeated in the text. >=20 > >On the issue of ISO 11173 alignment, this issue is OLD and > >rejected. Reopening > >at this time has not been justified. >=20 > I just wanted to make sure you would confirm it, because the text = still > could be construed as permitting such an alignment. May be this could = be > indicated. I suggest the following text: >=20 > "This document establishes an independent registry. This registry is = not > intended to be related to any registry, database or content not = documented > in this document." >=20 > I suppose this is what you want to say. > jfc >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 10:09:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12sr-0000bQ-Nv; Fri, 05 Aug 2005 10:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12sq-0000bL-C4 for ltru@megatron.ietf.org; Fri, 05 Aug 2005 10:09:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12149 for ; Fri, 5 Aug 2005 10:09:09 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E13Pu-00006k-LY for ltru@ietf.org; Fri, 05 Aug 2005 10:43:24 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Aug 2005 07:09:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 Date: Fri, 5 Aug 2005 07:09:00 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C5A7F55@irvmbxw01.quest.com> Thread-Topic: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 Thread-Index: AcWZtqtEdCuHGrFPTlyx0QfyyK0iagAD9VyA From: "Addison Phillips" To: "Kent Karlsson" , "Randy Presuhn" X-OriginalArrivalTime: 05 Aug 2005 14:09:00.0528 (UTC) FILETIME=[3A483700:01C599C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Notes below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Kent Karlsson > Sent: 2005?8?5? 5:06 > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] Second WG last call on = draft-ietf-ltru-initial-03.txt > ends 2005-08-08 >=20 >=20 > 1. 'no' should be deprecated in favor of 'nb'. That is, > one should assume 'nb' if 'no' is used. [Addison Phillips]=20 I don't agree. This is something the registration process could tangle = with, if someone feels strongly about it later. >=20 >=20 >=20 > 2. Will all the "added" dates be changed to that of the date when > the actual registry goes "live"? (As well for the initial value > of the "File-Date".) >=20 [Addison Phillips]=20 No. The initial value of File-Date should change, but not the added = dates. >=20 > 3. There is no mention about phasing out the old registry (or > perhaps I missed that), either in -initial or -registry. Is the > old registry to be kept permanently? Or removed at some later > date. An immediate retirement/replacement of the old registry > might not be so good. >=20 You missed it. See Section 5.1: The new registry MUST be listed under "Language Tags" at = http://www.iana.org/numbers.html, replacing the existing registrations = defined by [RFC3066] (Alvestrand, H., "Tags for the Identification of = Languages," January 2001.). The existing set of registration forms and = RFC 3066 registrations MUST be relabeled as "Language Tags (Obsolete)" = and maintained (but not added to or modified). _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 10:15:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12ys-0002MH-C8; Fri, 05 Aug 2005 10:15:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12yq-0002MB-NE for ltru@megatron.ietf.org; Fri, 05 Aug 2005 10:15:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12936 for ; Fri, 5 Aug 2005 10:15:22 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E13Vu-0000Jk-Qf for ltru@ietf.org; Fri, 05 Aug 2005 10:49:37 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Aug 2005 07:15:08 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Aug 2005 07:15:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Identifying correct parts / version of ISO 3166 Date: Fri, 5 Aug 2005 07:15:08 -0700 Message-ID: Thread-Topic: [Ltru] Identifying correct parts / version of ISO 3166 Thread-Index: AcWZCQphX51abYqhS8mLrVGW/TW6NAAtrTTQ From: "Peter Constable" To: X-OriginalArrivalTime: 05 Aug 2005 14:15:10.0470 (UTC) FILETIME=[16C8E260:01C599C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of r&d afrac > > > It is well established practice to have the publication year just > after > > > the standard's number. > > > >Different style sheets impose different requirements. I don't know > whether > >there is a consensus among publishers >=20 > This is an ISO 11173 conformant practice. This should not be followed. Hmmm... ISO 11173:1994, Thermoplastics pipes -- Determination of resistance to external blows -- Staircase method. I hope we don't have anything in this draft that conforms to ISO 11173. On the other hand, if JFC meant ISO 11179, then it's interesting to note that he now recommends that ISO 11179 practice should not be followed. Just for everyone's info, ISO 11179 specifies a Reference Document class with four owned attributes: - reference document identifier (mandatory, string, one value) - reference document language identifier (optional, zero or more values) - reference document title (optional, string, zero or one value) - reference document type description (optional, string, zero or one value) This class is also related to zero or more instances of the Organization class (implementation is mandatory), which has attributes for name (required) and mailing address (optional). I don't see any specification for how any of the values should be formatted.=20 Thus, it would appear that conformance would amount to having reference document identifiers. Note that this is in relation to administered items in the registry. This has *nothing whatsoever* to do with how we refer to documents in the draft. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 10:39:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13Mc-0007uT-LZ; Fri, 05 Aug 2005 10:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13Mb-0007u6-6B for ltru@megatron.ietf.org; Fri, 05 Aug 2005 10:39:57 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14489 for ; Fri, 5 Aug 2005 10:39:54 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050805143919.THIB19267.mta10.adelphia.net@DEWELL> for ; Fri, 5 Aug 2005 10:39:19 -0400 Message-ID: <003301c599cb$6145c3a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050805080054.NODK21541.mta2.adelphia.net@megatron.ietf.org> Subject: Re: [Ltru] add internationalization considerations to initial registry draft? Date: Fri, 5 Aug 2005 07:38:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> "This document establishes an independent registry. This registry is >> not intended to be related to any registry, database or content not >> documented in this document." > > We're in second working group last call. Jefsey has kindly provided > specific text he would like added to the initial registry draft, which > is planned to be submitted for consideration for publication as an > Informational RFC. Does the WG believe that this addition is > technically necessary? This is like making a statement, when I get into my car, that I am only getting into my own car and not anyone else's. Additionally, the word "content" makes me wonder if there is more to this text than meets the eye. Tags that are conformant to RFC 3066bis are composed of subtags defined in the registry, and are indeed related to other content -- the written, spoken, or other natural-language content being tagged as to language and variant. The proposed text could be interpreted to mean that the IANA Language Subtag Registry has no meaning or significance. I do not support adding this text to any of the three WG documents. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 10:42:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13Of-0008Hv-75; Fri, 05 Aug 2005 10:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13Oe-0008Hq-63 for ltru@megatron.ietf.org; Fri, 05 Aug 2005 10:42:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14588 for ; Fri, 5 Aug 2005 10:42:01 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E13vk-0000xc-4G for ltru@ietf.org; Fri, 05 Aug 2005 11:16:17 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Aug 2005 07:41:52 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Aug 2005 07:41:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] ISO 11173 (non) alignment in main draft Date: Fri, 5 Aug 2005 07:41:51 -0700 Message-ID: Thread-Topic: [Ltru] ISO 11173 (non) alignment in main draft Thread-Index: AcWZwhZLW64VhCEURAe+J618jIvm5wABuO1Q From: "Peter Constable" To: X-OriginalArrivalTime: 05 Aug 2005 14:41:52.0492 (UTC) FILETIME=[D1AA0AC0:01C599CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of r&d afrac > Proposed choice (or anyone can better the texts if respecting their > intent). The target is clarity. >=20 > (a) "Even if the registry documented in this memo relates in part to ISO > codes it is not aligned on ISO 11173 provisions." >=20 > (b) "The registry documented in this memo relates in part to ISO codes and > SHOULD respect their alignment on ISO 11173 provisions as they develop." I strongly object to both wordings. Apart from the typo (referring to a standard on plastics), "aligned on ISO 11179 provisions" is thoroughly ambiguous, and nothing of particular use is contributed. Indeed, I find both to introduce problems: - The first wording contributes nothing other than to inform users of how this registry relates to ISO 11179, which assessment should not be stated unless this or a subsequent WG reviews a written analysis of the same.=20 - The second wording imposes a requirement on IANA with no guidance whatsoever on how it should be fulfilled; moreover, it imposes a vaguely-stated requirement that could permit future interpretation requiring changes in the specification in which it would be contained in ways that are completely unforeseen. We have been over the role of ISO 11179 in relation to this draft before and concluded that no reference to it was required. I would like to see this matter put to rest. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 10:46:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13Si-0000ki-Ff; Fri, 05 Aug 2005 10:46:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13Sh-0000kd-5W for ltru@megatron.ietf.org; Fri, 05 Aug 2005 10:46:15 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14749 for ; Fri, 5 Aug 2005 10:46:12 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050805144543.UZVI24042.mta11.adelphia.net@DEWELL> for ; Fri, 5 Aug 2005 10:45:43 -0400 Message-ID: <003a01c599cc$3b0b46a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050805102302.ZLW3015.mta3.adelphia.net@megatron.ietf.org> Date: Fri, 5 Aug 2005 07:44:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: >>> ---> Either consistently include edition (for dated references...) >>> ---> or consistenly exclude it. >> >> I thought you wanted us to use the listings straight out of the >> online ISO catalog. > > Yes. > >> That is what they have. > > No. Look again. The ISO catalogue (at www.iso.org) is consistent on > this point. The edition nr. is always given, but separately from the > title. I stand corrected. I will be completely guided by the co-chairs as to any changes that need to made in the references in draft-initial. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 10:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13YC-0002Tj-4k; Fri, 05 Aug 2005 10:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13YA-0002Rf-Rg for ltru@megatron.ietf.org; Fri, 05 Aug 2005 10:51:54 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15059 for ; Fri, 5 Aug 2005 10:51:52 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050805145113.TZBL19267.mta10.adelphia.net@DEWELL> for ; Fri, 5 Aug 2005 10:51:13 -0400 Message-ID: <003f01c599cd$013dcd20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050805102302.ZLW3015.mta3.adelphia.net@megatron.ietf.org> Date: Fri, 5 Aug 2005 07:50:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> [ISO3166-1] > [...] >> ----> What about part 3? > > Should be added / included, it's used to track code changes > like YDYE. It might be helpful if the contents of this standard were freely available like 3166-1. In any case, whether it would be helpful to use 3166-3 or not, the fact is that the current draft does not use it, and thus does not need a reference to it. > 1988 is a magic year here, RfC 3066 and 1766 used precisely > this edition, therefore we ignored crap deprecated before > 1988 like NHVU, RHZW, or VDVN. It's only crap because we ignore it. If we had needed to maintain compatibility with tags generated before 1980, we would absolutely have to include a region subtag RH (with a Preferred-Value of ZW). -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 10:56:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13d5-0003Vu-5o; Fri, 05 Aug 2005 10:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13d3-0003Vp-Ab for ltru@megatron.ietf.org; Fri, 05 Aug 2005 10:56:57 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15275 for ; Fri, 5 Aug 2005 10:56:54 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050805145626.UHME19267.mta10.adelphia.net@DEWELL> for ; Fri, 5 Aug 2005 10:56:26 -0400 Message-ID: <004601c599cd$b472e060$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050805144118.XFFJ5577.mta7.adelphia.net@megatron.ietf.org> Date: Fri, 5 Aug 2005 07:55:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: add internationalization considerations to initial registry draft? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Regarding the confusion of who does what where, I note that Doug > (the editor of draft-initial) put IANA into both the abstract and > introduction, although he then reverts from "IANA Language Subtag > Registry" to just "Language Subtag Registry" in the second paragraph. And in some places I reduced it to "the registry." I'm not really convinced there is any genuine confusion over which registry is implied. > It's an editorial change, and not a very important one in my view. +1 -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 11:01:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13hM-0004Vr-AM; Fri, 05 Aug 2005 11:01:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13hK-0004TK-ON for ltru@megatron.ietf.org; Fri, 05 Aug 2005 11:01:22 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15414 for ; Fri, 5 Aug 2005 11:01:19 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050805150051.EZFC29002.mta9.adelphia.net@DEWELL> for ; Fri, 5 Aug 2005 11:00:51 -0400 Message-ID: <004b01c599ce$52e6d760$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050805144118.XFFJ5577.mta7.adelphia.net@megatron.ietf.org> Date: Fri, 5 Aug 2005 07:59:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >> 2. Will all the "added" dates be changed to that of the date when >> the actual registry goes "live"? (As well for the initial value >> of the "File-Date".) >> > [Addison Phillips] > > No. The initial value of File-Date should change, but not the added > dates. Oops. This was not my understanding, and so I've been advancing all the Added dates with each revision. What should the dates be? Fixed at the date when draft-initial passes WGLC and moves into IETF Last Call? Something previous to that? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 11:15:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13uh-0007dw-5f; Fri, 05 Aug 2005 11:15:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13uf-0007dr-QR for ltru@megatron.ietf.org; Fri, 05 Aug 2005 11:15:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15959 for ; Fri, 5 Aug 2005 11:15:07 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E14Rk-0001oy-P5 for ltru@ietf.org; Fri, 05 Aug 2005 11:49:23 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j75FEs7U009695 for ; Fri, 5 Aug 2005 11:14:54 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j75FEsNg223152 for ; Fri, 5 Aug 2005 11:14:54 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j75FErOS016067 for ; Fri, 5 Aug 2005 11:14:54 -0400 Received: from markdavis (sig-9-48-114-138.mts.ibm.com [9.48.114.138]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j75FEq9t015642; Fri, 5 Aug 2005 11:14:53 -0400 Message-ID: <004b01c599d0$6cbf2280$76d52b09@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , References: <20785174.1123229031189.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Subject: Re: [Ltru] add internationalization considerations to initialregistry draft? Date: Fri, 5 Aug 2005 08:14:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j75FEs7U009695 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Strongly agree =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Friday, August 05, 2005 01:03 Subject: Re: [Ltru] add internationalization considerations to initialregistry draft? > Hi - > > As a technical contributor, I believe there is no technical need for th= e > proposed addition. further, I believe that the proposed text is technically > incorrect: the initial registry document does NOT "establish" the registry. > > Randy > > -----Original Message----- > From: Randy Presuhn > Sent: Aug 5, 2005 9:58 AM > To: ltru@ietf.org > Subject: Re: [Ltru] add internationalization considerations to initial registry draft? > > Hi - > > We're in second working group last call. Jefsey has kindly provided > specific text he would like added to the initial registry draft, which = is > planned to be submitted for consideration for publication as an Informational > RFC. Does the WG believe that this addition is technically necessary? > > Randy, ltru co-chair > > -----Original Message----- > From: r&d afrac > Sent: Aug 5, 2005 6:55 AM > To: Randy Presuhn , ltru@ietf.org > Subject: Re: [Ltru] add internationalization considerations to initial registry draft? > > Dear Randy, > > At 18:45 04/08/2005, Randy Presuhn wrote: > >It's not clear to me how one would apply the recommendations of RFC 22= 77 > >in this case. Could you suggest some meaningful text to go in the > >internationalizations considerations section you request? Unless such > >text adds > >significant technical value to the document, I would argue against mak= ing such > >a change at this late stage in the process. Since the only use of the > >contents > >of this document is to initialize the IANA registry, I believe any > >internationalization > >considerations would belong in the registry document, rather than here. > > I suppose you are right. > But it is rather odd to document all the languages and the scripts of t= he > world in ASCII without explaning why. Some people could think it is because > of a natural superiority of the Anglicanus Mens. > > >I note that both the abstract and the document text are quite clear th= at they > >are talking about the IANA registry, so I believe the editor faithfull= y > >applied the > >change I (not Addison, as you write) suggested. > > Oh! I know that you asked to make sure you would block one of my remark= s, > just in case. Addison said he did it. What I say is that the correction= is > in the Abstract only. The IANA exclusive is not repeated in the text. > > >On the issue of ISO 11173 alignment, this issue is OLD and > >rejected. Reopening > >at this time has not been justified. > > I just wanted to make sure you would confirm it, because the text still > could be construed as permitting such an alignment. May be this could b= e > indicated. I suggest the following text: > > "This document establishes an independent registry. This registry is no= t > intended to be related to any registry, database or content not documen= ted > in this document." > > I suppose this is what you want to say. > jfc > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 13:42:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E16DX-0002UN-OG; Fri, 05 Aug 2005 13:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E16DV-0002To-Ra for ltru@megatron.ietf.org; Fri, 05 Aug 2005 13:42:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22978 for ; Fri, 5 Aug 2005 13:42:42 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E16kd-0006Ez-8t for ltru@ietf.org; Fri, 05 Aug 2005 14:17:00 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E16DP-0004Kb-4j; Fri, 05 Aug 2005 10:42:39 -0700 Message-Id: <6.2.1.2.2.20050805190859.05452150@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 05 Aug 2005 19:12:08 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: add internationalization considerations to initial registry draft? In-Reply-To: <004601c599cd$b472e060$030aa8c0@DEWELL> References: <20050805144118.XFFJ5577.mta7.adelphia.net@megatron.ietf.org> <004601c599cd$b472e060$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 16:55 05/08/2005, Doug Ewell wrote: >I'm not really convinced there is any genuine confusion over which >registry is implied. In that case I suggest you put IANA everywhere. The other registries will refer to then current ISO 11179 conformant ISO codes version at their creation date. This may lead to discrepancies as the Registry is not intended to be ISO 11179 conformant. At least you will have claified your intent and we will build a conversion table when necessary. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 05 15:50:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18Co-00028H-5W; Fri, 05 Aug 2005 15:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18Cg-00020j-QA; Fri, 05 Aug 2005 15:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28810; Fri, 5 Aug 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E18jq-0000yJ-5g; Fri, 05 Aug 2005 16:24:18 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E18Cf-0008N3-Px; Fri, 05 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-10.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-registry-10.txt Pages : 62 Date : 2005-8-5 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-registry-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-registry-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-5112732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-5112732.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@lists.ietf.org Fri Aug 05 17:43:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E19y2-0003t3-EN; Fri, 05 Aug 2005 17:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E19y0-0003sd-Qw for ltru@megatron.ietf.org; Fri, 05 Aug 2005 17:43:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05300 for ; Fri, 5 Aug 2005 17:42:57 -0400 (EDT) Received: from eastrmmtao05.cox.net ([68.230.240.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1AV8-0004Gf-1m for ltru@ietf.org; Fri, 05 Aug 2005 18:17:17 -0400 Received: from A31P ([68.100.55.187]) by eastrmmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050805214242.IMLE2947.eastrmmtao05.cox.net@A31P>; Fri, 5 Aug 2005 17:42:42 -0400 From: "Scott Hollenbeck" To: "'Kent Karlsson'" Subject: RE: [Ltru] LTRU submission: draft-ietf-ltru-registry-10 Date: Fri, 5 Aug 2005 17:44:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <60174.83.248.26.202.1123229826.squirrel@webmail.chalmers.se> Thread-Index: AcWZlhI8cIXn5P2NQWye1c6SOHnNKAAcJI1Q Message-Id: <20050805214242.IMLE2947.eastrmmtao05.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: Kent Karlsson [mailto:kentk@cs.chalmers.se] > Sent: Friday, August 05, 2005 4:17 AM > To: Scott Hollenbeck > Cc: ltru@ietf.org > Subject: RE: [Ltru] LTRU submission: draft-ietf-ltru-registry-10 > > >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > >> Requirement Levels", BCP 14, RFC 2119, March 1997. > >> > >> ----> I still think this one should not be listed as > >> "normative". It is > >> ----> more "metanormative" for IETF standards, and would then > >> not need to be > >> ----> listed as "normative" for any particular RFC. > > > > There's no such thing as "metanormative". > > I did put it in quotes. > > > It either needs to be listed as a > > normative reference (if it is), or it should be omitted (if > it isn't). > > If > > 2119 keywords are used, it's a normative reference. > > Well, I (nor anyone else apparently) would dream of putting > the ISO (IEC) directives in as a normative reference in an > ISO (IEC) standard. I've even gotten the comment from the ISO > central secretariat that one should not even include "shall" > and "should" in the list of defined terms, since their use is > dictated by the directives, and thus applies to all ISO (and > IEC) standards. My take is that normative references are > references that are at the technical level, not at the > document authoring level (which is the level of the > definition and use of "shall" and "should"). This isn't the ISO. In the IETF, we require that 2119 be cited as a normative reference if it's used to describe conformance langauge. That's been the practice for a long time, and it's still the practice today. -Scott- (speaking as Area Advisor) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 08:48:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1O5z-0001Fh-Cz; Sat, 06 Aug 2005 08:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1O5u-0001DF-5m for ltru@megatron.ietf.org; Sat, 06 Aug 2005 08:48:06 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21224 for ; Sat, 6 Aug 2005 08:48:04 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1O4j-0000pp-VH for ltru@lists.ietf.org; Sat, 06 Aug 2005 14:46:54 +0200 Received: from c-134-88-178.hh.dial.de.ignite.net ([62.134.88.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Aug 2005 14:46:53 +0200 Received: from nobody by c-134-88-178.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Aug 2005 14:46:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 06 Aug 2005 14:44:13 +0200 Organization: Lines: 36 Message-ID: <42F4B09D.25C0@xyzzy.claranet.de> References: <20050805102302.ZLW3015.mta3.adelphia.net@megatron.ietf.org> <003f01c599cd$013dcd20$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-178.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: [3166-3] > It might be helpful if the contents of this standard were > freely available like 3166-1. Three 3166-3 newsletters since 1999 are available so far: http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-1.html http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-2.html http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-3.html Complete list incl. French versions: http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/index.html > In any case, whether it would be helpful to use 3166-3 or > not, the fact is that the current draft does not use it, and > thus does not need a reference to it. ACK, not in 3.1, we only disussed it as source for the initial registry and cases like YDYE or DDDE. >> we ignored crap deprecated before 1988 like NHVU, RHZW, or >> VDVN. > It's only crap because we ignore it. No, we ignore it because it's historical crap... And you had a hard time to gag me when I wanted to get rid of all old regions from the second millennium, based on the year of the publication of RfC 1766. The seven years from 1988 - 1995 are a royal PITA. But Mark wanted BU, tough, let future software archaeologists have some fun. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 09:12:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1OTw-0006mB-BJ; Sat, 06 Aug 2005 09:12:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1OTu-0006jw-7i for ltru@megatron.ietf.org; Sat, 06 Aug 2005 09:12:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22107 for ; Sat, 6 Aug 2005 09:12:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1OTj-0002XQ-BL for ltru@lists.ietf.org; Sat, 06 Aug 2005 15:12:43 +0200 Received: from c-134-88-178.hh.dial.de.ignite.net ([62.134.88.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Aug 2005 15:12:43 +0200 Received: from nobody by c-134-88-178.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Aug 2005 15:12:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 06 Aug 2005 15:10:35 +0200 Organization: Lines: 40 Message-ID: <42F4B6CB.71D5@xyzzy.claranet.de> References: <20050805144118.XFFJ5577.mta7.adelphia.net@megatron.ietf.org> <004b01c599ce$52e6d760$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-178.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: >> The initial value of File-Date should change, but not the >> added dates. > Oops. This was not my understanding, and so I've been > advancing all the Added dates with each revision. One consistent way to do it, IMHO okay, it's the fiction that you created the initial registry at "date B". Another way would be to get the "real" dates of the additions (more or less, e.g. using available 3166 newsletters) with a fiction, that the initial registry existed since 1988 "date A" and was updated a.s.a.p. Probably you'd have a hard time to get the latter right, so I think you better stick to the former strategy. In theory I'd prefer the latter, because "deprecated" before "added" is ugly, but in practice it would force you to guess in too many cases. Better stick to your original strategy. > What should the dates be? Fixed at the date when > draft-initial passes WGLC and moves into IETF Last Call? Pick the last possible "date B" where you're confident to have _all_ changes in _all_ sources. If that's in your AUTH48 in some months it's okay. But tf they introduce GG, IM, and JE next week (example) use a "date B" in this week, because it would confuse several parts of the text if you try to integrate these changes in the initial registry: Let the normal specified update procedure handle GG, IM, JE, and pick a "date B" before this change. OTOH don't pick a "date B" before the introduction of 831 and 832, because this could again confuse the existing text. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 09:34:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Op3-00031p-AW; Sat, 06 Aug 2005 09:34:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Ooz-00031V-R5 for ltru@megatron.ietf.org; Sat, 06 Aug 2005 09:34:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22837 for ; Sat, 6 Aug 2005 09:34:40 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1PMH-000775-Eo for ltru@ietf.org; Sat, 06 Aug 2005 10:09:06 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Sat, 6 Aug 2005 13:36:15 +0000 Message-ID: Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IKS00LH1Z142L@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sat, 06 Aug 2005 13:34:16 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sat, 06 Aug 2005 14:34:16 +0100 Date: Sat, 06 Aug 2005 14:34:16 +0100 From: Misha Wolf Subject: RE: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 Thread-Index: AcWahUVK7nJAmJTURiSkXeZLeSH2fQABcvCw content-class: urn:content-classes:message X-OriginalArrivalTime: 06 Aug 2005 13:34:16.0694 (UTC) FILETIME=[8AA22160:01C59A8B] X-Spam-Score: 0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Frank, > [...] I wanted to get rid of all old regions from the=20 > second millennium [...] Please check your calendar. We are in the sixth millennium,=20 as the current year is 5765. I doubt that we are including=20 named regions from the second millennium, though maybe we=20 should be doing so:-) Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 09:40:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1OuF-00049r-BU; Sat, 06 Aug 2005 09:40:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1OuB-000490-JQ for ltru@megatron.ietf.org; Sat, 06 Aug 2005 09:40:03 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22944 for ; Sat, 6 Aug 2005 09:40:01 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1Oth-0004Sp-IL for ltru@lists.ietf.org; Sat, 06 Aug 2005 15:39:33 +0200 Received: from c-134-88-178.hh.dial.de.ignite.net ([62.134.88.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Aug 2005 15:39:33 +0200 Received: from nobody by c-134-88-178.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Aug 2005 15:39:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 06 Aug 2005 15:37:20 +0200 Organization: Lines: 10 Message-ID: <42F4BD10.2862@xyzzy.claranet.de> References: <20050805144118.XFFJ5577.mta7.adelphia.net@megatron.ietf.org> <004b01c599ce$52e6d760$030aa8c0@DEWELL> <42F4B6CB.71D5@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-178.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addition: > in practice it would force you to guess in too many cases. Hm... not necessarily, you could use 2001-01-01 as default "added" date (= publication of RfC 3066), and "real" dates for all modifications between 2001-01-01 and "date B". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 11:51:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1QxG-0005Gl-R7; Sat, 06 Aug 2005 11:51:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1QxE-0005Gg-9G for ltru@megatron.ietf.org; Sat, 06 Aug 2005 11:51:20 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28729 for ; Sat, 6 Aug 2005 11:51:17 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1Qw6-0006gk-SC for ltru@lists.ietf.org; Sat, 06 Aug 2005 17:50:10 +0200 Received: from c-134-88-178.hh.dial.de.ignite.net ([62.134.88.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Aug 2005 17:50:10 +0200 Received: from nobody by c-134-88-178.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Aug 2005 17:50:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 06 Aug 2005 17:47:22 +0200 Organization: Lines: 27 Message-ID: <42F4DB89.5572@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-178.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: LTRU submission: draft-ietf-ltru-registry-10 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Misha Wolf wrote: > Please check your calendar. We are in the sixth millennium, > as the current year is 5765. "Obsoletes 3066, updates 3339" - we could have a lot of fun with these issues, I'm a lurker on the TZ list. As long as you don't count seconds since 1970-01-01T00:00Z it's okay - otherwise I'm lost with leap seconds. Some algorithms I use break before 0000-03-011T00:00Z, that's "base" day -306 with REXX, MJD -678881, or JD 1721119.5, so I still prefer to count days after 0000-02-28. Assuming that "0000" is allowed for the moment, and ignoring all historical dates before JD 2299161, JD 2361222, or whenever you want the current leap year scheme to start. > I doubt that we are including named regions from the second > millennium, though maybe we should be doing so:-) Not for long, the Mayan calendar cycle ends 2012 / 5772, that is by definition the end of the universe. :-) Just looking into RfC 2445 (text/calendar) for the first time - we better stay away from these issues as far as possible. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 13:50:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Sow-0004Sd-Pn; Sat, 06 Aug 2005 13:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Sov-0004RM-CZ for ltru@megatron.ietf.org; Sat, 06 Aug 2005 13:50:53 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03514 for ; Sat, 6 Aug 2005 13:50:52 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050806175021.CZAK19267.mta10.adelphia.net@DEWELL> for ; Sat, 6 Aug 2005 13:50:21 -0400 Message-ID: <003201c59aaf$2957c760$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050806161024.EHOZ5577.mta7.adelphia.net@megatron.ietf.org> Date: Sat, 6 Aug 2005 10:49:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Old country codes (was: Re: LTRU submission: draft-ietf-ltru-registry-10) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > [3166-3] >> It might be helpful if the contents of this standard were >> freely available like 3166-1. > > Three 3166-3 newsletters since 1999 are available so far: > > http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-1.html > http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-2.html > http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-3.html > > Complete list incl. French versions: > > http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/index.html Since 1999. That is helpful, and it provides definitive guidance for some code elements, but unfortunately the others (back to 1988, which is our "Date A," and further back to the mid-1970s) are available only for a price, or through unofficial sources. >> In any case, whether it would be helpful to use 3166-3 or >> not, the fact is that the current draft does not use it, and >> thus does not need a reference to it. > > ACK, not in 3.1, we only disussed it as source for the initial > registry and cases like YDYE or DDDE. Background material for discussion doesn't necessarily need to be referenced in the finished document. What we said in the draft was that the code elements from ISO 3166:1988 were used, along with subsequent updates. That might or might not have been accomplished by actually procuring a copy of the 1988 standard. >>> we ignored crap deprecated before 1988 like NHVU, RHZW, or >>> VDVN. >> >> It's only crap because we ignore it. > > No, we ignore it because it's historical crap... The fact that DY for Dahomey was changed to BN for Benin is not "crap" just because it happened in 1977 any more than the change from TP to TL that happened in 2002. It happens that this WG's draft seeks to maintain compatibility with tags generated under RFC 1766, which referenced the 1988 version of ISO 3166, so we allow subtags based on ISO 3166 code elements going back to 1988. But for an application that really uses ISO 3166 code elements per se, and might have to recognize all previous code elements for its own compatibility reasons, DY as a historical code element is just as legitimate as TL. > And you > had a hard time to gag me when I wanted to get rid of all old > regions from the second millennium, based on the year of the > publication of RfC 1766. RFC 1766, published in 1995, allowed code elements dating back to 1988, and notoriously did not contain any text about versioning of ISO 3166 except to say there was a Maintenance Agency. > The seven years from 1988 - 1995 are a royal PITA. No, they're not. Older deprecated subtags don't cause any problems that newer (or future) deprecated subtags won't cause. They're a lot like grandfathered tags; if you have to support one, supporting 500 is no big deal. > But Mark wanted BU, tough, let future software > archaeologists have some fun. 1. I don't see any need to personalize this. Mark wasn't the only one. I've explained the logic for maintaining compatibility with 1988 above. 2. If you already have to support TP, there is no additional cost to supporting BU. 3. One major reason we have a registry at all is so that tag recipients don't have to be software archaeologists, tracing their way back through ISO change notices (if available) to interpret deprecated code elements. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 15:18:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1UC2-0004dk-4y; Sat, 06 Aug 2005 15:18:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1UC0-0004df-K1 for ltru@megatron.ietf.org; Sat, 06 Aug 2005 15:18:48 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07540 for ; Sat, 6 Aug 2005 15:18:46 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050806191816.GAAW19267.mta10.adelphia.net@DEWELL> for ; Sat, 6 Aug 2005 15:18:16 -0400 Message-ID: <003701c59abb$80821de0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050806161024.EHOZ5577.mta7.adelphia.net@megatron.ietf.org> Date: Sat, 6 Aug 2005 12:17:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Dates A and B redux (was: Re: Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > One consistent way to do it, IMHO okay, it's the fiction that > you created the initial registry at "date B". That's not fiction, it's by definition. From draft-initial, Section 2: | 1. For each source standard, the date of the standard referenced in | [RFC1766] was selected as the starting date. Code elements that were | valid on that date in the selected standard were added to the ILSR. That's Date A. | 2. For each successive change to the standard, any additional | assignments up to the date of the adoption of [I-D.ietf-ltru-registry] | were added to the ILSR. That's Date B, the date of adoption of draft-registry. That day has not come yet. > Another way would be to get the "real" dates of the additions > (more or less, e.g. using available 3166 newsletters) with a > fiction, that the initial registry existed since 1988 "date A" > and was updated a.s.a.p. That isn't the date the subtag was added to the registry. From draft-registry, Section 3.1: | Added's field-value contains the date the record was added to the | registry. Changing the rules about dates would require changing the text of draft-registry and/or draft-initial. As a technical contributor, I don't think we should go down that path at this time. As editor of draft-initial, I will do what the co-chairs say. Speaking of this, I'm still waiting for an answer to my question in http://www1.ietf.org/mail-archive/web/ltru/current/msg03183.html. I know it's the weekend and not everyone is available right now. > Probably you'd have a hard time to get the latter right, so I > think you better stick to the former strategy. In theory I'd > prefer the latter, because "deprecated" before "added" is ugly, > but in practice it would force you to guess in too many cases. "Deprecated" before "added" is ugly, I agree, but the WG agreed to a convention *quite some time ago* that subtags in the initial regsitry, based on ISO code elements, would have a Deprecated date equal to the date the code element was deprecated in the source standard. Claiming that a given subtag was added to the registry 10 or 20 or 30 years ago before the registry was even created is also ugly IMHO. >> What should the dates be? Fixed at the date when >> draft-initial passes WGLC and moves into IETF Last Call? > > Pick the last possible "date B" where you're confident to have > _all_ changes in _all_ sources. If that's in your AUTH48 in > some months it's okay. But tf they introduce GG, IM, and JE > next week (example) use a "date B" in this week, because it > would confuse several parts of the text if you try to integrate > these changes in the initial registry: > > Let the normal specified update procedure handle GG, IM, JE, > and pick a "date B" before this change. OTOH don't pick a > "date B" before the introduction of 831 and 832, because this > could again confuse the existing text. Date B has already been picked. Read item 2 in Section 2 of draft-initial, and then go back and read it again. That is the definition of Date B that this WG has agreed to. We will not know the final value of Date B until the left side of the equation has been filled in (i.e. the date of adoption of draft-registry). If that date is delayed until GG and IM and JE are added to ISO 3166-1, then those subtags will be added to the initial registry. It is as simple as that. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 16:51:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1VdP-0004Kn-DZ; Sat, 06 Aug 2005 16:51:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1VdO-0004Ki-Ea for ltru@megatron.ietf.org; Sat, 06 Aug 2005 16:51:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10535 for ; Sat, 6 Aug 2005 16:51:08 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1WAk-00086y-4j for ltru@ietf.org; Sat, 06 Aug 2005 17:25:39 -0400 X-Medic-Info: 6298.42f522b5.0 MUO3H1oORURRhAGX Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 3A21C4188 for ; Sat, 6 Aug 2005 22:51:01 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Sat, 6 Aug 2005 22:51:01 +0200 (CEST) Message-ID: <62747.83.248.26.202.1123361461.squirrel@webmail.chalmers.se> In-Reply-To: References: Date: Sat, 6 Aug 2005 22:51:01 +0200 (CEST) Subject: Re: [Ltru] draft-ietf-ltru-registry-10.txt From: "Kent Karlsson" To: ltru@ietf.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Section 5.2 seems to imply that an initial extensions registry will be generated by this WG, like that for initial subtags registry. I guess it initially will be empty, just (?) containing a File-Date; but if that is stated explicitly anywhere, then I have so far not reached that piece of text. (Nit: File-Date updates should be done like for the subtag registry, I guess; but when a record is updated, the date of the update should be included in the record itself ("Last-Update:"?); also for language subtag registry records.) The extensions registry does not seem to have the same maintenance rigor in where it is to be placed and handled as the subtag registry. Since there has been some (too...) detail updates to the -initial document on which registry is meant (which is quite clear there), is is a bit odd that the -registry document sometimes says just "the registry", when that document actually talks about two registries, the (IANA) Language subtag registry, and the (IANA) Language extension subtag registry. I, at least, got the impression that those are two separate registries. I would suggest that each occurrence of "registry" in the -registry document be clarified to "(IANA) Language subtag registry", "(IANA) Language tag extension registry", or "(IANA) Language subtag and tag extensions registries" (with suitable unambiguous short forms) as appropriate. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 17:52:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1WaL-00080x-Rt; Sat, 06 Aug 2005 17:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1WaJ-00080s-Jo for ltru@megatron.ietf.org; Sat, 06 Aug 2005 17:52:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13730 for ; Sat, 6 Aug 2005 17:52:01 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1X7d-0000nQ-SE for ltru@ietf.org; Sat, 06 Aug 2005 18:26:33 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E1WaB-0005sl-2k for ltru@ietf.org; Sat, 06 Aug 2005 14:51:55 -0700 Message-Id: <6.2.1.2.2.20050806113648.03050cd0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 06 Aug 2005 23:51:46 +0200 To: "LTRU Working Group" From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Subject: [Ltru] W3C tag policy disclaimers and IETF RFCs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org May be should I ask now a question I always wanted to ask. Addison co-signs his Draft on language tags as a member of the W3C. He explained well the problems he faces with XML (Mark did not explain the ones he has with CLDR locales, and I have been prevented to explain those I have with the DNS-locales). So, we have an Internet standard process oriented BCP Draft, by the W3C generously imposed to all the Internet protocols, to document the language sub-class of tag object class. There is a document approved as an RFC on the Editor's desk which describes "the tag URIs also known as 'tags'", i.e. that tag class. This document is authored by gentlemen from HP and W3C. This Draft by gentlemen from IBM and W3C. This RFC soon to be published (draft-kindberg-tag-uri-07.txt) is the Internet document of reference we used as a source of inspiration when documenting the "x-tags", trying to keep two W3C Drafts consistent. Everyone observed it is not that it is not easy. The Kindberg/Hawke RFC, approved by the IESG, has still be less considered by this WG than the IESG Charter. It is however as well worded as the Draft on some points. So after having tried with the "x-" proposition, we followed Lee Guillam and disengaged through the "0-" escaped sequence. But technically it is unlikely that Draft be accepted if the "x-" does not support Kindberg RFC inheritance. The difference between the two documents are: - the Kindberg/Hawke RFC has been approved, is open and tag class generic, respects ISO 1179, and includes a disclaimer that it may not reflect the views and opinion of the W3C - the Draft has already failed two Last Calls, is constrained and limited to tag sub-class, is not interested in aligning on ISO 11179 and does not include an IESG or W3C disclaimer. The problem is that the ABNFs of the two documents (as it was opposed to me) are not compatible. The "x-" format I proposed was Kindberg/Hawke conformant, but was denied by the W3C author of the Draft. There is therefore a need for the Draft either to include a disclaimer that the "W3C language tag" does not represent the views and opinion of the W3C anymore than the Kindberg/Hawke, or that to the contrary the ambiguity of the Kindberg/Hawker RFC is now clarify and the Draft do represent the views and opinions of the W3C and Unicode, at least for the part of the tag class documenting languages. Otherwise it is likely that the Draft will be opposed the IESG approved definition of a "tag". The solution seems obvious. It is simply to modify the "x-" ABNF as: "encapsulates a RFC X- ABNF conformant tag" and to remove the adverse language in 2.2. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 17:57:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Wfx-0000Xm-PB; Sat, 06 Aug 2005 17:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Wfx-0000Wt-2S for ltru@megatron.ietf.org; Sat, 06 Aug 2005 17:57:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14060 for ; Sat, 6 Aug 2005 17:57:48 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1XDI-0000uP-8a for ltru@ietf.org; Sat, 06 Aug 2005 18:32:20 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 14:57:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs Date: Sat, 6 Aug 2005 14:57:36 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C5A8323@irvmbxw01.quest.com> Thread-Topic: [Ltru] W3C tag policy disclaimers and IETF RFCs Thread-Index: AcWa0RmVrDljiPUuQMW74A/eNAvz0wAAEB0g From: "Addison Phillips" To: "r&d afrac" , "LTRU Working Group" X-OriginalArrivalTime: 06 Aug 2005 21:57:36.0812 (UTC) FILETIME=[DB4E6EC0:01C59AD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org How many times do I have to write, troll, that my work here is = unaffiliated with my work at W3C (or anywhere else)? I do not "sign" my work here as a "member" of the W3C. The only person = on this list that purports to represent more than one person is YOU. You = claim to represent organizations as well as the opinions of others. I = claim to represent only myself. Frostily, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of r&d afrac > Sent: 2005?8?6? 14:52 > To: LTRU Working Group > Subject: [Ltru] W3C tag policy disclaimers and IETF RFCs >=20 > May be should I ask now a question I always wanted to ask. Addison co- > signs > his Draft on language tags as a member of the W3C. He explained well = the > problems he faces with XML (Mark did not explain the ones he has with = CLDR > locales, and I have been prevented to explain those I have with the > DNS-locales). >=20 > So, we have an Internet standard process oriented BCP Draft, by the = W3C > generously imposed to all the Internet protocols, to document the = language > sub-class of tag object class. >=20 > There is a document approved as an RFC on the Editor's desk which > describes > "the tag URIs also known as 'tags'", i.e. that tag class. This = document is > authored by gentlemen from HP and W3C. This Draft by gentlemen from = IBM > and > W3C. This RFC soon to be published (draft-kindberg-tag-uri-07.txt) is = the > Internet document of reference we used as a source of inspiration when > documenting the "x-tags", trying to keep two W3C Drafts consistent. > Everyone observed it is not that it is not easy. >=20 > The Kindberg/Hawke RFC, approved by the IESG, has still be less = considered > by this WG than the IESG Charter. It is however as well worded as the > Draft > on some points. So after having tried with the "x-" proposition, we > followed Lee Guillam and disengaged through the "0-" escaped sequence. = But > technically it is unlikely that Draft be accepted if the "x-" does not > support Kindberg RFC inheritance. >=20 > The difference between the two documents are: > - the Kindberg/Hawke RFC has been approved, is open and tag class = generic, > respects ISO 1179, and includes a disclaimer that it may not reflect = the > views and opinion of the W3C > - the Draft has already failed two Last Calls, is constrained and = limited > to tag sub-class, is not interested in aligning on ISO 11179 and does = not > include an IESG or W3C disclaimer. >=20 > The problem is that the ABNFs of the two documents (as it was opposed = to > me) are not compatible. The "x-" format I proposed was Kindberg/Hawke > conformant, but was denied by the W3C author of the Draft. >=20 > There is therefore a need for the Draft either to include a disclaimer > that > the "W3C language tag" does not represent the views and opinion of the = W3C > anymore than the Kindberg/Hawke, or that to the contrary the ambiguity = of > the Kindberg/Hawker RFC is now clarify and the Draft do represent the > views > and opinions of the W3C and Unicode, at least for the part of the tag > class > documenting languages. >=20 > Otherwise it is likely that the Draft will be opposed the IESG = approved > definition of a "tag". The solution seems obvious. It is simply to = modify > the "x-" ABNF as: >=20 > "encapsulates a RFC X- ABNF conformant tag" >=20 > and to remove the adverse language in 2.2. >=20 > jfc >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 18:01:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1WjT-0001IY-KD; Sat, 06 Aug 2005 18:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1WjR-0001IO-Ly for ltru@megatron.ietf.org; Sat, 06 Aug 2005 18:01:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14265 for ; Sat, 6 Aug 2005 18:01:27 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1XGm-00010k-Ue for ltru@ietf.org; Sat, 06 Aug 2005 18:35:59 -0400 Received: from uknsprd1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Sat, 6 Aug 2005 22:01:15 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IKT00070MI3Z2@eupig2.dtc.lon.ime.reuters.com>; Sat, 06 Aug 2005 23:01:15 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Sat, 06 Aug 2005 23:01:14 +0100 Date: Sat, 06 Aug 2005 23:01:13 +0100 From: Misha Wolf Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs To: r&d afrac Message-id: <1987416CA83AC7499AC772F92E2DBF780442306A@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] W3C tag policy disclaimers and IETF RFCs Thread-Index: AcWa0Ru3fkvb0RIPQcChFOcHArnJawAAKjMg content-class: urn:content-classes:message X-OriginalArrivalTime: 06 Aug 2005 22:01:14.0792 (UTC) FILETIME=[5D3B8A80:01C59AD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear JFC, I very much hope that your spaceship will soon complete=20 its repairs and that you will be able to continue your=20 journey, spreading wisdom to other species. We will=20 remember you fondly and will tell our grandchildren=20 about the time when you visited our Planet. Bon voyage, Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 18:15:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Wtv-0004HX-Qx; Sat, 06 Aug 2005 18:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Wtu-0004FU-2F for ltru@megatron.ietf.org; Sat, 06 Aug 2005 18:12:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15220 for ; Sat, 6 Aug 2005 18:12:15 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1XRH-0001HN-GG for ltru@ietf.org; Sat, 06 Aug 2005 18:46:47 -0400 Received: from eupig1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Sat, 6 Aug 2005 22:12:04 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IKT006JYN0442@eupig1.dtc.lon.ime.reuters.com>; Sat, 06 Aug 2005 22:12:04 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sat, 06 Aug 2005 23:12:04 +0100 Date: Sat, 06 Aug 2005 23:12:03 +0100 From: Misha Wolf Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs To: Addison Phillips MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] W3C tag policy disclaimers and IETF RFCs Thread-Index: AcWa0RmVrDljiPUuQMW74A/eNAvz0wAAEB0gAABKwyA= content-class: urn:content-classes:message X-OriginalArrivalTime: 06 Aug 2005 22:12:04.0271 (UTC) FILETIME=[E05A2BF0:01C59AD3] X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison, [...]=20 > Frostily, [...] Your cold tone is unwarranted. JFC has travelled untold=20 lightyears to bring us greetings from the many Galaxies he=20 represents. Who are you to belittle his great task? Rather=20 than make fun of him, we should be ever grateful for the self- deprecating manner in which he communicates. Has he even once=20 alluded to his ability to destroy the Earth to make way for a=20 hyperspace bypass? JFC and the other Vogons should be treated=20 with kid gloves as otherwise the members of this WG, together=20 with the rest of humanity, may not be around to repent at=20 leisure. Please give JFC the respect he deserves. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 21:12:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Zik-0000Ga-PE; Sat, 06 Aug 2005 21:12:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Zij-0000G8-9G for ltru@megatron.ietf.org; Sat, 06 Aug 2005 21:12:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23475 for ; Sat, 6 Aug 2005 21:12:55 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1aG5-0004sm-6r for ltru@ietf.org; Sat, 06 Aug 2005 21:47:28 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E1Zie-0007W8-6t; Sat, 06 Aug 2005 18:12:52 -0700 Message-Id: <6.2.1.2.2.20050807000340.04e09880@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 07 Aug 2005 00:52:27 +0200 To: "Addison Phillips" , "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C5A8323@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C5A8323@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Addison, ??? Why to be aggressive when I ask a question that will be asked at IESG Last Call? I did not rise it before not to confuse the debate. But you will now have to be ready to address it. At 23:57 06/08/2005, Addison Phillips wrote: >I do not "sign" my work here as a "member" of the W3C. This affirmation seems signed: "Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group" (is from the troll you signaled it?) >The only person on this list that purports to represent more than one >person is YOU. I claim to represent only myself. As far as I am concerned I certainly do not make that claim. Transparency is of the essence. This is why I switched to an organisation e-mail address. You respond that you publish in the same conditions as S. Hawke. Perfect with me. Question is only: why don't you use the same disclaimer, while you plant a conflicting proposition in his garden? Would you think your proposition is better and you should "win" (You know I disagree with the attitude "S. Hawke's tags winning over Addison Philips' tags, or the other way around"). Or is there a good reason? I only long clear, stable, efficient, scalable IETF tags we all can use in peace. This is a legitimate demand I will repeat again and again until I get them: this is what the IETF is about. I certainly agree that your proposition has merits for people thinking they need it. This is why the interest of the Internet community is that you find a way to agree with the Kindberg/Hawke RFC. I proposed two solutions: you may have an other one. Just expose it and if the WG supports it and if the IESG agrees it fits the RFC on tags they approved, it will be accepted. Or you may document how your Draft partly or totally obsoletes their RFC. Either way is OK with me. But conflicting confusion cannot be. >You claim to represent organizations as well as the opinions of others. This is my job to report and document users needs and problems , and I am trusted to bring solutions. I do not represent "opinions" however. I deal with facts. I have or share personal opinions and propositions. When they are supported by some and becomes running code, solutions or decisions, they become facts. Instead of opposing/despising your users, may I suggest you listen to them? I am very patient and I do not worry too much about people being hurting. What counts is a good result. I will always be available to kindly help you in that area. But I am sorry, I cannot support what blocks my R&D, opposes RFC we use and people tell me they do not want. All the best. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 21:51:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1aK2-0008Np-FC; Sat, 06 Aug 2005 21:51:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1aK1-0008Nk-Ko for ltru@megatron.ietf.org; Sat, 06 Aug 2005 21:51:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24645 for ; Sat, 6 Aug 2005 21:51:27 -0400 (EDT) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1arQ-0005cX-1s for ltru@ietf.org; Sat, 06 Aug 2005 22:26:01 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1E1aR1-00089m-Oq; Sat, 06 Aug 2005 21:58:43 -0400 Date: Sat, 6 Aug 2005 21:58:43 -0400 To: r&d afrac Subject: Re: [Ltru] W3C tag policy disclaimers and IETF RFCs Message-ID: <20050807015843.GA13441@ccil.org> References: <634978A7DF025A40BFEF33EB191E13BC0C5A8323@irvmbxw01.quest.com> <6.2.1.2.2.20050807000340.04e09880@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050807000340.04e09880@mail.afrac.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org r&d afrac scripsit: > I only long clear, stable, efficient, scalable IETF tags we all can use in > peace. This is a legitimate demand I will repeat again and again until I > get them: this is what the IETF is about. This is a clear statement of the author's intent to spam this mailing list and other IETF mailing lists until he gets his way. It should be obvious to all that this will never happen. Since there is at least a good possibility that this WG will continue for some time, through the matching draft, RFC 3066ter (ISO 639-3), and perhaps even quater (ISO 639-6), I see no reason at all why we should continue to put up with this treatment. I call for an immediate warning under BCP 94, to be followed by suspension under BCP 94 and if necessary under BCP 83 as well. -- John Cowan cowan@ccil.org www.reutershealth.com www.ccil.org/~cowan The known is finite, the unknown infinite; intellectually we stand on an islet in the midst of an illimitable ocean of inexplicability. Our business in every generation is to reclaim a little more land, to add something to the extent and the solidity of our possessions. --Thomas Henry Huxley _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 22:35:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1b0R-0001Sb-KX; Sat, 06 Aug 2005 22:35:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1b0P-0001Ru-Tk for ltru@megatron.ietf.org; Sat, 06 Aug 2005 22:35:17 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26172 for ; Sat, 6 Aug 2005 22:35:15 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050807023446.UUWY19267.mta10.adelphia.net@DEWELL> for ; Sat, 6 Aug 2005 22:34:46 -0400 Message-ID: <000801c59af8$8bc46cc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050806221250.VMJH9082.mta1.adelphia.net@megatron.ietf.org> Date: Sat, 6 Aug 2005 19:34:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Extension registry (was: Re: draft-ietf-ltru-registry-10.txt) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: > Section 5.2 seems to imply that an initial extensions registry will > be generated by this WG, like that for initial subtags registry. > I guess it initially will be empty, just (?) containing a File-Date; > but if that is stated explicitly anywhere, then I have so far not > reached that piece of text. (Nit: File-Date updates should be done > like for the subtag registry, I guess; but when a record is updated, > the date of the update should be included in the record itself > ("Last-Update:"?); also for language subtag registry records.) (Counter-nit: We already have an agreed-upon mechanism for the dates of records, which is that only the Added and Deprecated dates exist, and are not changed after their creation.) Back to the extension registry: I think Kent has a point. It does seem that a vestigial initial extension registry needs to exist. I don't see any provision to defer its creation until approval of the first extension RFC. Assuming that the extension registry does have a File-Date, just like the language subtag registry (I can't find a passage that says it does or doesn't), then the entire contents of the initial extension registry would be as follows: File-Date: 2005-08-06 (or whatever Date B turns out to be). Then after the first extension RFC is approved, it might be updated to look something like the following (warning: purely hypothetical examples follow): File-Date: 2006-06-01 %% Identifier: F Description: Frame-of-mind Comments: This extension indicates the speaker or writer's frame of mind at the time the linguistic content was created (e.g. "happy", "pensive", "morose"). Added: 2006-06-01 RFC: 5678 Authority: Molvanian Psychological Society Contact_Email: webmaster@mps.mj Mailing_List: fom-list@mps.mj URL: http://www.mps.mj/stds/fom-reg.txt (Do not try to contact these addresses. There is no Molvania.) > The extensions registry does not seem to have the same maintenance > rigor in where it is to be placed and handled as the subtag registry. I agree. Whether that should be changed is a matter for the WG and co-chairs. > Since there has been some (too...) detail updates to the -initial > document on which registry is meant (which is quite clear there), > is is a bit odd that the -registry document sometimes says just > "the registry", when that document actually talks about two > registries, the (IANA) Language subtag registry, and the (IANA) > Language extension subtag registry. I, at least, got the impression > that those are two separate registries. I think there are two registries. I didn't, however, find any spots in the text where I was confused over which registry was being referred to. Maybe I didn't try hard enough. :-) > I would suggest that each > occurrence of "registry" in the -registry document be clarified > to "(IANA) Language subtag registry", "(IANA) Language tag extension > registry", or "(IANA) Language subtag and tag extensions registries" > (with suitable unambiguous short forms) as appropriate. Perhaps Kent could identify the particular spots that seemed troublesome, and the group can decide whether appropriate editorial changes are needed. I suspect that changing every reference throughout the entire document would be excessive (just as I believe it would be excessive in draft-initial, which only deals with one registry). The references to "registry" in sections 3.6 and 5.2 would be most likely to benefit from clarification. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 06 23:15:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1bdg-00013D-Tn; Sat, 06 Aug 2005 23:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1bde-000138-59 for ltru@megatron.ietf.org; Sat, 06 Aug 2005 23:15:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27248 for ; Sat, 6 Aug 2005 23:15:47 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1cB3-0007CV-As for ltru@ietf.org; Sat, 06 Aug 2005 23:50:22 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Aug 2005 20:15:38 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Aug 2005 20:15:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs Date: Sat, 6 Aug 2005 20:15:38 -0700 Message-ID: Thread-Topic: [Ltru] W3C tag policy disclaimers and IETF RFCs Thread-Index: AcWa8yZNce1OC8GCQtyEBBija7wHwgACpoSQ From: "Peter Constable" To: X-OriginalArrivalTime: 07 Aug 2005 03:15:38.0969 (UTC) FILETIME=[49288490:01C59AFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > This is a clear statement of the author's intent to spam this mailing > list and other IETF mailing lists until he gets his way. It should be > obvious to all that this will never happen. > I call for an immediate warning under BCP 94, to be followed by suspension > under BCP 94 and if necessary under BCP 83 as well. I agree. I came back from a week's vacation to find a barrage of mail to this list, 40% of which involved this one person's attempt, once again, to get his way on proposals everyone that had previously been rejected. This is not collaborative contribution; this is obstruction of progress. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 08:13:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1k1a-0002u5-QI; Sun, 07 Aug 2005 08:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1k1Z-0002tr-Hp for ltru@megatron.ietf.org; Sun, 07 Aug 2005 08:13:05 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03230 for ; Sun, 7 Aug 2005 08:13:03 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1k0S-0004p1-Fi for ltru@lists.ietf.org; Sun, 07 Aug 2005 14:11:56 +0200 Received: from c-180-160-143.hh.dial.de.ignite.net ([62.180.160.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 14:11:56 +0200 Received: from nobody by c-180-160-143.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 14:11:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 07 Aug 2005 14:06:12 +0200 Organization: Lines: 61 Message-ID: <42F5F934.5108@xyzzy.claranet.de> References: <20050806161024.EHOZ5577.mta7.adelphia.net@megatron.ietf.org> <003201c59aaf$2957c760$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-143.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Old country codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > Since 1999. That is helpful, and it provides definitive > guidance for some code elements, but unfortunately the others > (back to 1988, which is our "Date A," and further back to the > mid-1970s) are available only for a price, or through > unofficial sources. Older stuff is their "initial" 3166-3, it's not as old as the other parts. See their iso3166-past-present-and-future page: http://www.iso.org/iso/en/prods-services/iso3166ma/04background-on-iso-3166/iso3166-past-present-and-future.html 3166-3 was created 1997-99, the newsletters cover all updates. One of my several "date A" proposals was "5th edition" (1999). Somebody here ordered and got it, and IIRC the result was that your unofficial source of code changes was complete. > this WG's draft seeks to maintain compatibility with tags > generated under RFC 1766, which referenced the 1988 version > of ISO 3166, so we allow subtags based on ISO 3166 code > elements going back to 1988. Are you talking with me or for the press ? I know what we did, in theory I could find Randy's ticket number, and the article where he declared consens about "date A". Nobody cared to produce any tags deprecated before 1995, maybe not one exists, but we can't be sure. > DY as a historical code element is just as legitimate as TL. Not in language tags, it was never valid under 1766 / 3066. If DYBN was 1977, then it was dead 11 years before 1988, and 18 years before RfC 1766. There are precisely zero reasons to find it in the wild in 1766 / 3066 / 3066bis language tage. >> The seven years from 1988 - 1995 are a royal PITA. > No, they're not. Older deprecated subtags don't cause any > problems that newer (or future) deprecated subtags won't > cause. They're a lot like grandfathered tags; if you have > to support one, supporting 500 is no big deal. We all discussed this here again and again, of course they are a PITA because they are blocked for future "recycling". Nobody can use any future BU in language tags, because it's blocked by the old BUMM. Unlike DY and NH. BUMM was 1989, one year after "date A", but still before the WWW was started, and maybe also before somebody counted 18 letters in I18N. > If you already have to support TP, there is no additional > cost to supporting BU. As far as I'm concerned this error is the main reason why an LTRU WG was created. Plus the "most perverse tag" issue, and "Suppress-Script". Anything else is essentially the same as you (= language tag list) already had it in the old last call. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 09:10:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1kvM-00055K-Fm; Sun, 07 Aug 2005 09:10:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1kvI-000559-2H for ltru@megatron.ietf.org; Sun, 07 Aug 2005 09:10:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05606 for ; Sun, 7 Aug 2005 09:10:38 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1ktr-0000Rq-5z for ltru@lists.ietf.org; Sun, 07 Aug 2005 15:09:11 +0200 Received: from c-180-160-143.hh.dial.de.ignite.net ([62.180.160.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 15:09:11 +0200 Received: from nobody by c-180-160-143.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 15:09:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 07 Aug 2005 15:04:47 +0200 Organization: Lines: 53 Message-ID: <42F606EF.718C@xyzzy.claranet.de> References: <20050806161024.EHOZ5577.mta7.adelphia.net@megatron.ietf.org> <003701c59abb$80821de0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-143.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Dates A and B redux X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > That's Date A. Doug, I _know_ what "date A" is, I was here, remember ? From my POV it was the most conservative choice, there were no language tags before 1995, nobody had a reason to use anything deprecated before RfC 1766 - unless he had an old copy of ISO 3166-1 region codes without the updates. Rough consensus was to be paranoid about this hypothetical case => ready, "date A" is 1988. > Changing the rules about dates would require changing > the text of draft-registry and/or draft-initial. If the rules are clear why did you ask ? I'm fine with your strategy to use "date B" everywhere. Addison did not propose another strategy for the "ILSR", his remark was about the future function of "Added" dates for all registry updates after "date B". > Claiming that a given subtag was added to the registry > 10 or 20 or 30 years ago before the registry was even > created is also ugly IMHO. The idea is fine - we've used past modifications in the sources to simulate the effects on an imaginary registry started at various potential "date A". But in practice getting these "Added" dates right would be too difficult. And one day before the end of the second dress rehearsal it's also too late for such major "nice to have" changes. > Date B has already been picked. Read item 2 in Section > 2 of draft-initial, and then go back and read it again. If you don't want answers you don't like beause you already have your own answers don't ask. I only told you what I'd do about it, delay "date B" as long as possible, but not beyond potential major changes of the sources, if it causes inconsistencies with the "last called" texts. > If that date is delayed until GG and IM and JE are added > to ISO 3166-1, then those subtags will be added to the > initial registry. It is as simple as that. It's not, it could invalidate parts of your chapter 4, in the "worst" (= best) case completely. It would also affect the text in 3.3 point 11 in 3066bis. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 09:42:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1lQZ-00020w-3b; Sun, 07 Aug 2005 09:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1lQX-0001yo-Ab for ltru@megatron.ietf.org; Sun, 07 Aug 2005 09:42:57 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06595 for ; Sun, 7 Aug 2005 09:42:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1lPG-0002oT-8n for ltru@lists.ietf.org; Sun, 07 Aug 2005 15:41:38 +0200 Received: from c-180-160-143.hh.dial.de.ignite.net ([62.180.160.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 15:41:38 +0200 Received: from nobody by c-180-160-143.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 15:41:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 07 Aug 2005 15:38:20 +0200 Organization: Lines: 18 Message-ID: <42F60ECC.E62@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-143.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable quoted: >> From: ltru-bounces@lists.ietf.org [...] >> On Behalf Of John Cowan That mail didn't make it to GMaNe (or I screwed up), see also http://www.ietf.org/mail-archive/web/ltru/current/msg03201.html >> I call for an immediate warning under BCP 94, to be followed >> by suspension under BCP 94 and if necessary under BCP 83 BCP 83 is Marhall's RfC 3683 about DoS attacks on IETF lists. Language tags and the tag: URI scheme are completely unrelated, the latter is something like UUIDs or Message-IDs, it's only an informational RfC (waiting to be published). JFTR, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 11:44:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nKD-0003mX-5C; Sun, 07 Aug 2005 11:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nKB-0003mK-7J for ltru@megatron.ietf.org; Sun, 07 Aug 2005 11:44:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11851 for ; Sun, 7 Aug 2005 11:44:29 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1nrf-0002ak-S4 for ltru@ietf.org; Sun, 07 Aug 2005 12:19:10 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E1nK2-0005w3-3x; Sun, 07 Aug 2005 08:44:22 -0700 Message-Id: <6.2.1.2.2.20050807124103.05684090@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 07 Aug 2005 17:44:14 +0200 To: "Peter Constable" , John Cowan , From: r&d afrac Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Doug and Peter, as everyone knows for eight months now this debate lasts, I consider the proposition introduced by Addison and Mark, you sponsor, would lead to a terrible world cultural, societal and political catastrophe due its central positioning and to the technical inadequacy of its layer violations (confusing typography and network needs - and ignoring, refusing to consider [as for ISO 11179] or conflicting [as with Kindberg/Hawke RFC] with the work of other SDOs, international organisations and of thousands of local initiatives), the impact the scarcity of its options favoring the language industry dominant commercial interests, against competing and open source innovation I work on, or the dangers of supporting political discrimination it creates (and it documents in its security section). As everyone also knows, I still believe that a consensus is possible. Because this is what IETF is about. I will make therefore sure that all the Internet standard process possibilities (WG, Lasts Calls, appeals), legal procedures, international organisation political fora and conferences are properly respected and that procedures insuring their transparency are enabled. As the same time I lead R&D and share in Open Source work to technically address the real needs. The target is to unlock the exclusion introduced by this proposition, and simplify and open it until it permits the ultimate support of _every_ stakeholder without exclusive. I do regret the bias your comments document: the longer it will take for you to accept the legitimacy of this effort and to cooperate in a true IETF spirit, the latter a final consensus will be possible. I am sorry but these ad-hominems are not proper technical answers to: - my question about the ABNF conflicts between the RFC ruling IETF generic tags and the Draft, which does not update accordingly the RFC 3066 ABNF (Charter: "[registry] likely to be updated by the document ") - my request to the authors to propose us solutions, to address this questions since they refuse my propositions. On 03:58 07/08/2005, John Cowan said: >r&d afrac scripsit: > > > I only long for clear, stable, efficient, scalable IETF tags we all can > use in > > peace. This is a legitimate demand I will repeat again and again until I > > get them: this is what the IETF is about. > >This is a clear statement of the author's intent to spam this mailing >list and other IETF mailing lists until he gets his way. It should be >obvious to all that this will never happen. To call "spam" the normal usage of the Internet standard process towards an equal IETF success, says a lot of the work unfortunately remaining to accomplish before we can reach a rough consensus. I regret that you consider this WG will never share in a clear, stable, efficient, scalable IETF tags. I would not share in it if I did not believe it will. >Since there is at least a good possibility that this WG will continue >for some time, through the matching draft, RFC 3066ter (ISO 639-3), and >perhaps even quater (ISO 639-6), I see no reason at all why we should >continue to put up with this treatment. I note that this "treatment" is the normal respect of the Internet standard process ... I am not sure this is a correct manner to qualify it. May I suggest that instead you bring technical answers to technical questions. At least we agree that your current technical positions may make this WG to last a long time. >I call for an immediate warning under BCP 94, to be followed by suspension >under BCP 94 and if necessary under BCP 83 as well. This is a good documentation of the exclusion spirit of the proposition. At 05:15 07/08/2005, Peter Constable wrote: I agree. I came back from a week's vacation to find a barrage of mail to >this list, 40% of which involved this one person's attempt, once again, >to get his way on proposals everyone that had previously been rejected. >This is not collaborative contribution; this is obstruction of progress. This unfortunately only documents a lack of interest in the WG Last Call, the very limited number of contributors and support. This is a real problem since a WG LC is to prepare the EISG LC. Excluding the only one interested in finding a common consensus will then not help. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 11:44:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nKD-0003mv-BN; Sun, 07 Aug 2005 11:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nKB-0003mL-Di for ltru@megatron.ietf.org; Sun, 07 Aug 2005 11:44:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11850 for ; Sun, 7 Aug 2005 11:44:29 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1nrf-0002al-S8 for ltru@ietf.org; Sun, 07 Aug 2005 12:19:10 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E1nK3-0005w3-9f; Sun, 07 Aug 2005 08:44:23 -0700 Message-Id: <6.2.1.2.2.20050807161837.05694d40@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 07 Aug 2005 17:34:32 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs In-Reply-To: <42F60ECC.E62@xyzzy.claranet.de> References: <42F60ECC.E62@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 15:38 07/08/2005, Frank Ellermann wrote: >Language tags and the tag: URI scheme are completely unrelated, the latter >is something like UUIDs or Message-IDs, it's only an >informational RfC (waiting to be published). JFTR, bye, Frank This is the kind of simple answer I expected to receive! Thank you. However, your answer does not address the point. The Charter says that "The RFC 3066 standard for language tags has been widely adopted in various protocols and text formats, including HTML, XML, and CLDR, as the best means of identifying languages and language preferences." Let ignore CLDR since Mark wants his project to be ignored. But let consider HTML and XML. The reason why RFC 3066 bis is supposed to be urgently needed is a better support of XML. This has been widely documented by Addison. I contested that point because I think that this is detrimental to the users for the reasons noted in the RFC 3066 and in the Draft security sections; and because other solutions (modular documentation of the meta elements of a document) exist which are able to far better support the flexibility required by architexts. I also contested it because this is inadequate to the network architecture needs and does not properly scale. I also contested it because the limited number of subtags gives a commercial unfair dramatic advantage to the market dominant publishers with a dramatic ecocultural impact. But I accepted to share in this WG to try to obtain against every odds an acceptable opening of the intended closed standard. I did that, and documented it many times, because I was convinced this was a true genuine request of the W3C. Because in the archives of this WG-ltru the mention "Chair, W3C Internationalization Core Working Group" appears 168 times todate. But Addison says: - he considers the WG as a competition instead of a work in common, violating the IETF commonly agreed spirit. - his proposition is private and has nothing to do with the W3C, what makes the Draft lose my support. - yet he does not consider a W3C disclaimer as did S. Hawke, what makes it also supicious to me. Then I see that no one (but you) tries to technically respond. That I am on the contrary opposed ad hominems (will I be banned for having proposed Addison to loyally help him respecting the Internet standard process and get his Draft accepted...?). I must say that I quite lost faith in the possibility to save this Draft. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 11:52:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nRg-00052R-EG; Sun, 07 Aug 2005 11:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nRe-00052E-7q for ltru@megatron.ietf.org; Sun, 07 Aug 2005 11:52:14 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12090 for ; Sun, 7 Aug 2005 11:52:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050807155142.YLGM14360.mta13.adelphia.net@DEWELL> for ; Sun, 7 Aug 2005 11:51:42 -0400 Message-ID: <004701c59b67$b8df35e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 7 Aug 2005 08:50:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Old country codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> Since 1999... > > Older stuff is their "initial" 3166-3, it's not as old as the > other parts. See their iso3166-past-present-and-future page: > ... > 3166-3 was created 1997-99, the newsletters cover all updates. > One of my several "date A" proposals was "5th edition" (1999). I acknowledge that the free ISO 3166-3 newsletters cover the full range of updates since 1999. The standard itself, including all the entries for 3166-1 codes withdrawn between 1975 and 1999, is not free. > Somebody here ordered and got it, and IIRC the result was that > your unofficial source of code changes was complete. I really should write to Clive Feather and thank him for his clear and accurate page that served as my unofficial source. > Nobody cared to > produce any tags deprecated before 1995, maybe not one exists, > but we can't be sure. Well, that's exactly the point: we can't be sure. More on this later. >> DY as a historical code element is just as legitimate as TL. > > Not in language tags, it was never valid under 1766 / 3066. > If DYBN was 1977, then it was dead 11 years before 1988, and > 18 years before RfC 1766. There are precisely zero reasons > to find it in the wild in 1766 / 3066 / 3066bis language tage. You didn't quote me fully: "But for an application that really uses ISO 3166 code elements per se, and might have to recognize all previous code elements for its own compatibility reasons, DY as a historical code element is just as legitimate as TL." We are not such an application. We only care about code elements valid as of 1988. The point is that *somebody else* might care about code elements going back to the original 1974 version, and somebody else might only care about the ones that are current. That is why I say it is only the case that the pre-1988 codes are "crap" because we ignore them (i.e. they fall before our cutoff date); it is not the case that we ignore them because they are inherently crap. >> Older deprecated subtags don't cause any >> problems that newer (or future) deprecated subtags won't >> cause. > ... > We all discussed this here again and again, of course they > are a PITA because they are blocked for future "recycling". I know we had that discussion, as you said, "again and again." We were never able to see eye to eye on whether (a) the likelihood that ISO 3166/MA would reuse these codes was greater than (b) the likelihood that there's a language tag somewhere that uses it, with which we have to stay compatible. We'll never know, really. > Nobody can use any future BU in language tags, because it's > blocked by the old BUMM. Unlike DY and NH. BUMM was 1989, > one year after "date A", but still before the WWW was started, > and maybe also before somebody counted 18 letters in I18N. But after the date of the standard referenced by RFC 1766. Remember that in 1995, neither ISO 639 RA/JAC nor ISO 3166/MA had a Web site, and often the only source for these ISO code lists was someone's private typed-up copy (sort of like Clive's page, but much less diligently maintained). Before the Web there were bulletin boards and the "file areas" of CompuServe forums, where you could get the same private copies. These were very seldom updated every time a code like BU was withdrawn; often the curators of these lists had no way of knowing there was an ISO change. There was also a list of ISO 639-1 codes, created and maintained by some very respected people, that accidentally omitted the codes "ti" for Tigrinya and "tr" for Turkish, which led me (at least) to think ISO had somehow omitted these important languages. And EVEN NOW, there is a list of language codes on the Unicode Web site that says, in reference to pairs of codes like "he, iw*" where the latter was deprecated 16 years ago in favor of the former: "When writing: write the second, (oldest) one - marked with an asterisk - for legacy applications that cannot manage correctly the new standard code or for classes of applications for which you are not certain that they can use the new standard." So even now, in 2005, there are still plenty of opportunities for users to find code elements that they don't know have been deprecated, and apply them in language tags and elsewhere. >> If you already have to support TP, there is no additional >> cost to supporting BU. > > As far as I'm concerned this error is the main reason why an > LTRU WG was created. Plus the "most perverse tag" issue, and > "Suppress-Script". Anything else is essentially the same as > you (= language tag list) already had it in the old last call. I thought you said before that we had changed lots of things, mostly to your satisfaction. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 12:18:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nqv-0001Ja-Es; Sun, 07 Aug 2005 12:18:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nqt-0001JU-PB for ltru@megatron.ietf.org; Sun, 07 Aug 2005 12:18:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12955 for ; Sun, 7 Aug 2005 12:18:12 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E1oOL-0003Fs-NA for ltru@ietf.org; Sun, 07 Aug 2005 12:52:54 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Sun, 7 Aug 2005 17:17:32 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Aug 2005 17:17:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs Date: Sun, 7 Aug 2005 17:17:31 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A2121A59D5@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] W3C tag policy disclaimers and IETF RFCs Thread-Index: AcWa0ZQ0Y7ZErRwjQXu+5yzkH1acSgAmKhNx From: "L.Gillam" To: ltru X-OriginalArrivalTime: 07 Aug 2005 16:17:31.0795 (UTC) FILETIME=[8361AE30:01C59B6B] X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1533133113==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1533133113== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59B6B.8343BF01" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59B6B.8343BF01 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Jefsey, are you deliberately attempting to misrepresent my position = again? And doing so even after I described to you privately how to make = use of x- for your own needs, which you have neither acknowledged nor = refuted. And, above all, spelling my name incorrectly. Do you seek to = annoy people in as many ways as possible? Is it a hobby? =20 "What we've got here is... failure to communicate. Some men you just = can't reach." ________________________________ From: ltru-bounces@lists.ietf.org on behalf of r&d afrac Sent: Sat 06/08/2005 22:51 To: LTRU Working Group Subject: [Ltru] W3C tag policy disclaimers and IETF RFC [snip] So after having tried with the "x-" proposition, we followed Lee Guillam and disengaged through the "0-" escaped sequence. = But technically it is unlikely that Draft be accepted if the "x-" does not support Kindberg RFC inheritance. [snip] ------_=_NextPart_001_01C59B6B.8343BF01 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Ltru] W3C tag policy disclaimers and IETF RFCs=0A= =0A= =0A=
=0A=
 
=0A=
Jefsey, are you deliberately = attempting to =0A= misrepresent my position again? And doing so even after I described to = you =0A= privately how to make use of x- for your own needs, which you have = neither =0A= acknowledged nor refuted. And, above all, spelling my name = incorrectly. Do =0A= you seek to annoy people in as many ways as possible? Is it a =0A= hobby?
=0A=
 
=0A=
"What =0A= we've got here is... failure to communicate. Some men you just can't =0A= reach."
=0A=

=0A=
=0A= From: ltru-bounces@lists.ietf.org on = behalf of =0A= r&d afrac
Sent: Sat 06/08/2005 22:51
To: LTRU = Working =0A= Group
Subject: [Ltru] W3C tag policy disclaimers and IETF =0A= RFC
=0A=
=0A=

[snip]

=0A=

 So after having tried with the "x-" proposition, =0A= we
followed Lee Guillam and disengaged through the "0-" escaped = sequence. =0A= But
technically it is unlikely that Draft be accepted if the "x-" = does =0A= not
support Kindberg RFC inheritance.

=0A=

[snip]

=0A= =0A= =0A= ------_=_NextPart_001_01C59B6B.8343BF01-- --===============1533133113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1533133113==-- From ltru-bounces@lists.ietf.org Sun Aug 07 12:20:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nsi-0001Tt-CO; Sun, 07 Aug 2005 12:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1nsg-0001Tl-KY for ltru@megatron.ietf.org; Sun, 07 Aug 2005 12:20:11 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13020 for ; Sun, 7 Aug 2005 12:20:08 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050807161938.MOWP19267.mta10.adelphia.net@DEWELL> for ; Sun, 7 Aug 2005 12:19:38 -0400 Message-ID: <004a01c59b6b$8b2fd1a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050807154759.HOHA9082.mta1.adelphia.net@megatron.ietf.org> Date: Sun, 7 Aug 2005 09:17:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Dates A and B redux X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > Doug, I _know_ what "date A" is, I was here, remember ? Yes, sorry. I just wanted to make sure everyone was on the same page. > From my POV it was the most conservative choice, there > were no language tags before 1995, nobody had a reason > to use anything deprecated before RfC 1766 - unless he > had an old copy of ISO 3166-1 region codes without the > updates. Rough consensus was to be paranoid about this > hypothetical case => ready, "date A" is 1988. See my other message. Non-updated copies of the standard and unofficial code lists were much more common than official subscribed copies of the standard. (How many people, even now, know about the special meaning of "OO" and "OOO" in ISO 3166? You can really only find out about those by reading the standard.) >> Changing the rules about dates would require changing >> the text of draft-registry and/or draft-initial. > > If the rules are clear why did you ask ? I didn't ask about Date B. I asked, somewhat rhetorically, because Addison responded to Kent: >> 2. Will all the "added" dates be changed to that of the date when >> the actual registry goes "live"? (As well for the initial value >> of the "File-Date".) > > No. The initial value of File-Date should change, but not the added > dates. and this came as a surprise to me, based on my understanding of Date B and File-Date and Added. So far nobody's responded (it's a nice weekend). > I'm fine with > your strategy to use "date B" everywhere. Addison did > not propose another strategy for the "ILSR", his remark > was about the future function of "Added" dates for all > registry updates after "date B". Kent asked what would happen "when the actual registry goes 'live'." That could only refer to the initial registry. I think everyone understands that the Added dates for existing subtags won't change after the registry goes live, and indeed draft-registry mandates that. >> Claiming that a given subtag was added to the registry >> 10 or 20 or 30 years ago before the registry was even >> created is also ugly IMHO. > > The idea is fine - we've used past modifications in the > sources to simulate the effects on an imaginary registry > started at various potential "date A". But in practice > getting these "Added" dates right would be too difficult. I wish we did have exact dates for these things. >> Date B has already been picked. Read item 2 in Section >> 2 of draft-initial, and then go back and read it again. > > If you don't want answers you don't like beause you already > have your own answers don't ask. I only told you what I'd > do about it, delay "date B" as long as possible, but not > beyond potential major changes of the sources, if it causes > inconsistencies with the "last called" texts. I didn't ask about Date B. Really. We can never tell when there will be "potential major changes" to the source standards. With the notable exception of CS, which ISO 3166/MA apparently knew would cause problems, the MAs don't generally tell us when there is a change in the works. They simply announce the change after it is approved (or in the case of UNSD, post it on the Web with no announcement). >> If that date is delayed until GG and IM and JE are added >> to ISO 3166-1, then those subtags will be added to the >> initial registry. It is as simple as that. > > It's not, it could invalidate parts of your chapter 4, in > the "worst" (= best) case completely. It would also affect > the text in 3.3 point 11 in 3066bis. Section 4 of draft-initial is essentially just a code list, an "unregistry" as you once called it. Removing 831 through 833 would not cause me any grief personally, and we can be fairly sure we will not have to remove 830. The editors of draft-registry have essentially mirrored that list in Section 3.3, point 11, and they can decide whether amending that section would cause problems. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 13:25:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1ouI-00048O-Md; Sun, 07 Aug 2005 13:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1ouH-00048J-Fo for ltru@megatron.ietf.org; Sun, 07 Aug 2005 13:25:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16204 for ; Sun, 7 Aug 2005 13:25:50 -0400 (EDT) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1pRo-0004vj-7J for ltru@ietf.org; Sun, 07 Aug 2005 14:00:33 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1E1p1T-0005pE-Lv; Sun, 07 Aug 2005 13:33:19 -0400 Date: Sun, 7 Aug 2005 13:33:19 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Dates A and B redux Message-ID: <20050807173319.GA15189@ccil.org> References: <20050807154759.HOHA9082.mta1.adelphia.net@megatron.ietf.org> <004a01c59b6b$8b2fd1a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004a01c59b6b$8b2fd1a0$030aa8c0@DEWELL> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell scripsit: > See my other message. Non-updated copies of the standard and unofficial > code lists were much more common than official subscribed copies of the > standard. (How many people, even now, know about the special meaning of > "OO" and "OOO" in ISO 3166? You can really only find out about those by > reading the standard.) Not I, for sure. Whatever it is, it isn't in the draft registry. Should it be? What does it mean? -- Work hard, John Cowan play hard, cowan@ccil.org die young, http://www.reutershealth.com rot quickly. http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 13:52:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1pJi-0007hX-99; Sun, 07 Aug 2005 13:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1pJg-0007hS-Ii for ltru@megatron.ietf.org; Sun, 07 Aug 2005 13:52:08 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17282 for ; Sun, 7 Aug 2005 13:52:06 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1pIW-00058Q-PR for ltru@lists.ietf.org; Sun, 07 Aug 2005 19:50:56 +0200 Received: from c-180-160-143.hh.dial.de.ignite.net ([62.180.160.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 19:50:56 +0200 Received: from nobody by c-180-160-143.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 19:50:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 07 Aug 2005 19:47:52 +0200 Organization: Lines: 65 Message-ID: <42F64947.1255@xyzzy.claranet.de> References: <004701c59b67$b8df35e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-143.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Old country codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I really should write to Clive Feather and thank him for his > clear and accurate page that served as my unofficial source. ACK - after his 240 KB nntpext-base-27 monster draft I won't forget his name. > We only care about code elements valid as of 1988. The point > is that *somebody else* might care about code elements going > back to the original 1974 version Oh, yes, of course. There's even a group trying to "invent" historical codes for obsolete regions. And I also care about obscure region codes in my "rxwhois" script, codes like EA, EH, FX, or existing ccTLDs like AC, AX, etc. But that's about public whois servers, not language tags. > We were never able to see eye to eye on whether (a) the > likelihood that ISO 3166/MA would reuse these codes was > greater than (b) the likelihood that there's a language > tag somewhere that uses it In theory we could compute it, 26*26 - private use codes, changes over the last 30 years, so far three (?) collisions with old codes (GE, SK, CS) => one collision per decade, so let's say in about 1000 years all region codes in language tags are either numeric or deprecated. OTOH the frequency of the 1766 / 3066 / 3066bis updates was shorter than 3166-1 collisions so far. > Before the Web there were bulletin boards and the "file > areas" of CompuServe forums, where you could get the same > private copies. Yes, but using region codes in laguage tags was invented 1995, before that time we only had locales like en-UK and of course ccTLDs. FidoNet had zone and region numbers at this time, on top of an older system with only net and node numbers. > EVEN NOW, there is a list of language codes on the Unicode > Web site that says, in reference to pairs of codes like > "he, iw*" where the latter was deprecated 16 years ago Yes, one of your pet peeves, I'm more worried about my region code zoo, because it changes more frequently. Actually I'm more interested in TLDs, the problems aren't exactly the same as for language codes. Slightly different POV => slightly different conclusions. Nobody proposes to use TP instead of TL, they just need some time for the transition. > I thought you said before that we had changed lots of things, > mostly to your satisfaction. Yes, lots of details like the ABNF, references, record-jar, etc., but in essence it's still what you had last year. Plus "Suppress-Script", 2047-compatibility, and better rules for the region code zoo. If we still missed something really important let's hope that the "IETF last call" finds it. Or in other words Bruce Lilly ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 15:57:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1rGq-0000u0-Mm; Sun, 07 Aug 2005 15:57:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1rGp-0000tv-PO for ltru@megatron.ietf.org; Sun, 07 Aug 2005 15:57:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24107 for ; Sun, 7 Aug 2005 15:57:18 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1roO-0000De-MV for ltru@ietf.org; Sun, 07 Aug 2005 16:32:01 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E1rGh-0005yC-Pz; Sun, 07 Aug 2005 12:57:12 -0700 Message-Id: <6.2.1.2.2.20050807210207.056573e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 07 Aug 2005 21:57:04 +0200 To: "L.Gillam" , ltru From: r&d afrac Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A2121A59D5@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A2121A59D5@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2074000219==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============2074000219== Content-Type: multipart/alternative; boundary="=====================_35286369==.ALT" --=====================_35286369==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 18:17 07/08/2005, L.Gillam wrote: >Jefsey, are you deliberately attempting to misrepresent my position again? Dear Lee, ??? I do not represent any position of yours? I just say that your point was well made. AFRAC discussed it and thought the best idea was to leave "x-" to your ideas (even if I do not think they match our needs: this is your ideas and you have the right to get them supported - up to you to document and support them). They also thought that the "0- escape sequence" is the best way to support our needs and to best respect the Draft ABNF (for "basic" libraries, it only means that all what is after "0-" is disregarded). But I do not think your proposition support the Kindberg/Hawke RFC. >And doing so even after I described to you privately how to make use of x- >for your own needs, which you have neither acknowledged nor refuted. I have responded and fully documented that you did not. Or you responded a mail I did not receive (or which was filtered out by my anti-spam). What is the date-time of your last mail? >And, above all, spelling my name incorrectly. I apologies for that typo. No harm intended. >Do you seek to annoy people in as many ways as possible? It is rather a hobby to protect the human and cultural interests of as many people as possible against the annoyments artificially created by others. But first, it is a defense against a few people wanting to annoy our work as much as they can. > Is it a hobby? Oh! no.... unfortunately just a necessity they impose on us. Also a response to a demand of people, civil rights, industry and Govs, from developed and developing countries to help protecting their culture. An ethical duty. jfc --=====================_35286369==.ALT Content-Type: text/html; charset="us-ascii" At 18:17 07/08/2005, L.Gillam wrote:
Jefsey, are you deliberately attempting to misrepresent my position again?

Dear Lee,
??? I do not represent any position of yours?

I just say that your point was well made. AFRAC discussed it and thought the best idea was to leave "x-" to your ideas (even if I do not think they match our needs: this is your ideas and you have the right to get them supported - up to you to document and support them). They also thought that the "0- escape sequence" is the best way to support our needs and to best respect the Draft ABNF (for "basic" libraries, it only means that all what is after "0-" is disregarded).

But I do not think your proposition support the Kindberg/Hawke RFC.

And doing so even after I described to you privately how to make use of x- for your own needs, which you have neither acknowledged nor refuted.

I have responded and fully documented that you did not. Or you responded a mail I did not receive (or which was filtered out by my anti-spam). What is the date-time of your last mail?

And, above all, spelling my name incorrectly.

I apologies for that typo. No harm intended.

Do you seek to annoy people in as many ways as possible?

It is rather a hobby to protect the human and cultural interests of as many people as possible against the annoyments artificially created by  others. But first, it is a defense against a few people wanting to annoy our work as much as they can.

 Is it a hobby?

Oh! no.... unfortunately just a necessity they impose on us. Also a response to a demand of people, civil rights, industry and Govs, from developed and developing countries to help protecting their culture. An ethical duty.

jfc
--=====================_35286369==.ALT-- --===============2074000219== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2074000219==-- From ltru-bounces@lists.ietf.org Sun Aug 07 16:44:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1s0a-00089S-Jx; Sun, 07 Aug 2005 16:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1s0Y-00089I-6K for ltru@megatron.ietf.org; Sun, 07 Aug 2005 16:44:34 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26884 for ; Sun, 7 Aug 2005 16:44:31 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1rzR-00023b-OA for ltru@lists.ietf.org; Sun, 07 Aug 2005 22:43:25 +0200 Received: from c-180-160-143.hh.dial.de.ignite.net ([62.180.160.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 22:43:25 +0200 Received: from nobody by c-180-160-143.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 22:43:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 07 Aug 2005 22:22:29 +0200 Organization: Lines: 126 Message-ID: <42F66D85.7DE5@xyzzy.claranet.de> References: <42F60ECC.E62@xyzzy.claranet.de> <6.2.1.2.2.20050807161837.05694d40@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-143.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org r&d afrac wrote: > However, your answer does not address the point. Yes, the tag: URI scheme is beside the point for this WG. I discussed it on the uri@w3 list, not knowing that it's already approved, but some of its problems with percent-encoded email addresses and STD 66 oddities also affect problems with the mailto: and news: URI schemes. That's fascinating, but really unrelated to the language tags of 1766 / 3066 / 3066bis. Maybe relevant for your alternative schemes, if you want to allow characters that are not allowed in STD 66 URIs. > The reason why RFC 3066 bis is supposed to be urgently > needed is a better support of XML. This has been widely > documented by Addison. > I contested that point because I think that this is > detrimental to the users I also "contested" it, IMHO we need the explicit scripts, because with Unicode that's not more an implicit attribute of the charset. It's not detrimental for users. It's better than the old 3066 rules. It's the best possible solution compatible with 3066. It's a necessity, we won't win a price for the most beutiful standard with our "Suppress-Script" kludge. > I also contested it because this is inadequate to the > network architecture needs and does not properly scale. Support Bruce's Content-Script I-D if you like it better. I've no problem to do both at the same time, support 3066bis _and_ Bruce's idea. > I also contested it because the limited number of subtags > gives a commercial unfair dramatic advantage to the market > dominant publishers with a dramatic ecocultural impact. I don't see any "commercial advantage". But the _technical_ problems with the "most perverse tag" were real. That was a point in the old last call. Nothing is wrong if standards are implemented, and if some implementations are "commercial". I certainly hope that my next box will run under a "free" OS, with a browser supporting UniCode and 3066bis and CSS. And if that's exactly what *** wants me to think it doesn't mean that it's necessarily wrong. One company where I'd have serious reservations has less than three letters. > I was convinced this was a true genuine request of the W3C. We're here because the IETF last call of the old draft found problems above editorial nits, not "on request of the W3C", ICANN, VeriSign, Unicode, Redmond, IBM, Thorvald, or who else. Somebody, IIRC it was John Klensin among others, proposed to do it in a proper IETF WG. Where is the problem with this ? > in the archives of this WG-ltru the mention "Chair, W3C > Internationalization Core Working Group" appears 168 times Yeah, maybe, so what ? Probably as often as "Quest Software". Or "AFRAC". Or "xyzzy". > his proposition is private and has nothing to do with the > W3C, what makes the Draft lose my support. We're all supposed to contribute / work as individuals. It is an IETF standard, we play by IETF rules. We've even discussed to appoint a W3C liaison, but then we agreed to do it solely by IETF rules without such formalities. Of course the result will be something W3C and Unicode and ICU can live with, and it will be also something IMAP, MIME, etc. can live with. That was the purpose of this LTRU WG. > he does not consider a W3C disclaimer as did S. Hawke, The BCP 78 / BCP 79 boilerplates are bad enough, inventing new "disclaimers" would make it worse from my POV. Network Working Group A. Phillips, Ed. Internet-Draft Quest Software Expires: February 5, 2006 M. Davis, Ed. IBM Network Working Group T. Kindberg Internet-Draft Hewlett-Packard Corporation Expires: August 4, 2005 S. Hawke World Wide Web Consortium Major difference. Maybe Sandro is an employee of the W3C, and felt that it's necessary to point out that the tag: URI idea was his private business. If you're curious ask him. Harmless political details at the border between W3C and IETF, I don't care at the moment. It also has its funny sides, see Martin's discussions with Leslie about the proper URI list. Of course I miss tons of background history, it could be very important, and I only can't judge it. Like Haralds fights with Bob, all these reorganization BCPs. But in that case I could at least guess that it was about money paid by the visitors of IETF meetings and spent for the Secretary. Or whatever, I'm no "paying member", it's none of my business. > I must say that I quite lost faith in the possibility to save > this Draft. It's not threatened, only Bruce has the power to kill a draft, because I'd let him if he has good reasons. The last time he did it his review was longer than the draft... But I'm 100% certain that this won't happen with the LTRU drafts. Okay, the IESG has its own tricks to kill drafts, they approve them as "experimental", one big experiment with 700.000 domains and about 10 implementations, one small experiment with a few hundreds of domains and one implementation. Because that's too obvious the big experiment is decreed to be a part of the small experiment. An experiment with non-consenting participants - maybe the G in IESG stands for "Godwin". It definitely means that I'm now excessively far off topic, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 17:38:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1sqa-0007xe-Ut; Sun, 07 Aug 2005 17:38:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1sqZ-0007xD-2V for ltru@megatron.ietf.org; Sun, 07 Aug 2005 17:38:19 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28818 for ; Sun, 7 Aug 2005 17:38:15 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E1spO-00072x-JX for ltru@lists.ietf.org; Sun, 07 Aug 2005 23:37:06 +0200 Received: from c-180-160-143.hh.dial.de.ignite.net ([62.180.160.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 23:37:06 +0200 Received: from nobody by c-180-160-143.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Aug 2005 23:37:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 07 Aug 2005 23:34:00 +0200 Organization: Lines: 36 Message-ID: <42F67E48.2FA3@xyzzy.claranet.de> References: <20050807154759.HOHA9082.mta1.adelphia.net@megatron.ietf.org> <004a01c59b6b$8b2fd1a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-143.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Dates A and B redux X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > How many people, even now, know about the special meaning > of "OO" and "OOO" in ISO 3166? Certainly not me - deja vu, you already explained this some months ago, didn't you ? For X.25 "OOO" is the "out of order" protocol state... ;-) >| The initial value of File-Date should change, but not >| the added dates. > and this came as a surprise to me, based on my understanding > of Date B and File-Date and Added. Your understanding is correct. I think Addison's answer was about the registry after "date B". You've always updated all "Added" dates. We discussed it here, because my simple Xref- "validator" noted all "Added after Deprecated" dates. > So far nobody's responded (it's a nice weekend). At least you have my answer. No big issue, you could always change it later. But there's no serious alternative to what you have done, hunting historical "Added" dates is no option. > Removing 831 through 833 would not cause me any grief > personally, and we can be fairly sure we will not have to > remove 830. Checking, yes, 830 is still there. And so far no iSO 3166-1 newsletter in 2005. The language tag reviewer could try to subscribe the language tag list. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 20:49:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1vpP-0005Pq-SL; Sun, 07 Aug 2005 20:49:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1vpO-0005PR-M8 for ltru@megatron.ietf.org; Sun, 07 Aug 2005 20:49:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07804 for ; Sun, 7 Aug 2005 20:49:17 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1wN0-0006dX-29 for ltru@ietf.org; Sun, 07 Aug 2005 21:24:02 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E1vpI-0007d4-AY; Sun, 07 Aug 2005 17:49:12 -0700 Message-Id: <6.2.1.2.2.20050808003809.056569e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 08 Aug 2005 02:49:08 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs In-Reply-To: <42F66D85.7DE5@xyzzy.claranet.de> References: <42F60ECC.E62@xyzzy.claranet.de> <6.2.1.2.2.20050807161837.05694d40@mail.afrac.org> <42F66D85.7DE5@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 22:22 07/08/2005, Frank Ellermann wrote: >r&d afrac wrote: > > > However, your answer does not address the point. > >Yes, the tag: URI scheme is beside the point for this WG. I >discussed it on the uri@w3 list, not knowing that it's already >approved, but some of its problems with percent-encoded email >addresses and STD 66 oddities also affect problems with the >mailto: and news: URI schemes. That's fascinating, but really >unrelated to the language tags of 1766 / 3066 / 3066bis. Dear Frank, I think it is related. You probably know better why there is a W3C disclaimer. But there is a W3C disclaimer but there is no IESG disclaimer. The IESG charter calls for bettering RFC 3066. The IESG approved the tags RFC in the meanwhile. "x-" privateuse needs IRI tags to work. So ... >Maybe relevant for your alternative schemes, if you want to >allow characters that are not allowed in STD 66 URIs. > > The reason why RFC 3066 bis is supposed to be urgently > > needed is a better support of XML. This has been widely > > documented by Addison. > > > I contested that point because I think that this is > > detrimental to the users > >I also "contested" it, IMHO we need the explicit scripts, >because with Unicode that's not more an implicit attribute >of the charset. > >It's not detrimental for users. It's better than the old 3066 >rules. It's the best possible solution compatible with 3066. I understand you want to get it, I do not object. But I object you want to impose it to me who do not want it. >It's a necessity, we won't win a price for the most beutiful >standard with our "Suppress-Script" kludge. > > > I also contested it because this is inadequate to the > > network architecture needs and does not properly scale. > >Support Bruce's Content-Script I-D if you like it better. I've >no problem to do both at the same time, support 3066bis _and_ >Bruce's idea. I do not any support specific scheme. I support flexibiliy: that the user can chose, define and use the schemes he needs, along with his own needs. This is why I propose we work on an IETF language framework to replace RFC 3066, and to organise all the different identification tag systems. > > I also contested it because the limited number of subtags > > gives a commercial unfair dramatic advantage to the market > > dominant publishers with a dramatic ecocultural impact. > >I don't see any "commercial advantage". But the _technical_ >problems with the "most perverse tag" were real. That was a >point in the old last call. Nothing is wrong if standards are >implemented, and if some implementations are "commercial". I am not sure I understand all. What is wrong is when the standard favors a commercial implementation and blocks others or open source projects. >I certainly hope that my next box will run under a "free" OS, >with a browser supporting UniCode and 3066bis and CSS. I wish I am sure your next free OS box is free of locale related patented features. You may recall that one of the first questions I rose was about the CLDR IPRs. You may recall the Javascript issue between Netscape and IE. >And if >that's exactly what *** wants me to think it doesn't mean that >it's necessarily wrong. One company where I'd have serious >reservations has less than three letters. The point is not to say if someone is right or wrong. It is to support everyone's needs. > > I was convinced this was a true genuine request of the W3C. > >We're here because the IETF last call of the old draft found >problems above editorial nits, not "on request of the W3C", >ICANN, VeriSign, Unicode, Redmond, IBM, Thorvald, or who else. > >Somebody, IIRC it was John Klensin among others, proposed to >do it in a proper IETF WG. Where is the problem with this ? I was one of those who asked for a WG. The reason why is that a WG has a Charter and should have permitted an open debate further to a clean sheet review of the Charter. Randy asked me to tell the IESG I supported his project. I still wait for that review. > > in the archives of this WG-ltru the mention "Chair, W3C > > Internationalization Core Working Group" appears 168 times > >Yeah, maybe, so what ? Probably as often as "Quest Software". >Or "AFRAC". Or "xyzzy". Correct. But I am here as AFRAC R&D. Randy says he is not as W3C. > > his proposition is private and has nothing to do with the > > W3C, what makes the Draft lose my support. > >We're all supposed to contribute / work as individuals. It is >an IETF standard, we play by IETF rules. We've even discussed >to appoint a W3C liaison, but then we agreed to do it solely by >IETF rules without such formalities. > >Of course the result will be something W3C and Unicode and ICU >can live with, and it will be also something IMAP, MIME, etc. >can live with. That was the purpose of this LTRU WG. But not AFRAC? > > he does not consider a W3C disclaimer as did S. Hawke, > >The BCP 78 / BCP 79 boilerplates are bad enough, inventing new >"disclaimers" would make it worse from my POV. ???? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 07 23:28:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1yJ0-0006rb-MO; Sun, 07 Aug 2005 23:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1yIy-0006rW-Qy for ltru@megatron.ietf.org; Sun, 07 Aug 2005 23:28:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12812 for ; Sun, 7 Aug 2005 23:27:58 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1yqa-0001SP-Lw for ltru@ietf.org; Mon, 08 Aug 2005 00:02:45 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Aug 2005 20:27:49 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Aug 2005 20:27:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Old country codes Date: Sun, 7 Aug 2005 20:27:48 -0700 Message-ID: Thread-Topic: [Ltru] Re: Old country codes Thread-Index: AcWbSbLK1OtYyfcHQNucWnhZYISaMQAfyJqQ From: "Peter Constable" To: X-OriginalArrivalTime: 08 Aug 2005 03:27:49.0691 (UTC) FILETIME=[271D98B0:01C59BC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Somebody here ordered and got it, and IIRC the result was that > your unofficial source of code changes was complete. I purchased it and reported on the contents -- some months ago. That msg would be in the archives somewhere. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 08 03:06:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E21iN-0005Yr-GP; Mon, 08 Aug 2005 03:06:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E21iL-0005Ur-IR for ltru@megatron.ietf.org; Mon, 08 Aug 2005 03:06:25 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04101 for ; Mon, 8 Aug 2005 03:06:23 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050808070554.EZUU24042.mta11.adelphia.net@DEWELL>; Mon, 8 Aug 2005 03:05:54 -0400 Message-ID: <021101c59be7$8bf58040$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050807154759.HOHA9082.mta1.adelphia.net@megatron.ietf.org> <004a01c59b6b$8b2fd1a0$030aa8c0@DEWELL> <20050807173319.GA15189@ccil.org> Subject: Re: [Ltru] Re: Dates A and B redux Date: Mon, 8 Aug 2005 00:05:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: >> See my other message. Non-updated copies of the standard and >> unofficial code lists were much more common than official subscribed >> copies of the standard. (How many people, even now, know about the >> special meaning of "OO" and "OOO" in ISO 3166? You can really only >> find out about those by reading the standard.) > > Not I, for sure. Whatever it is, it isn't in the draft registry. > Should it be? What does it mean? I thought so. "OO" and "OOO" are special escape codes to indicate a switch to a different coding system. We don't have to worry about them in the registry because they are not assigned in ISO 3166, and because draft-registry defines only one "coding system," with a choice of registered or private-use subtags. As described in a draft update to ISO 3166-1: "8.1.4 Extended facility of user-assigned code elements (escape code element) "If the number of user-assigned code elements in 8.1.3 is not sufficient to cover a particular user requirement, the alphabetic code elements OO or OOO or the numeric code element 000 are to be utilized to indicate that code elements other than those defined in this part of ISO 3166 are used." Or as paraphrased by Clive Feather: "The codes OO, OOO, and 000 are designated for use as "escape codes" to indicate that additional codes are being used." I can't find any previous message about this in my "Sent" box. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 08 08:45:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E270A-0000sX-VG; Mon, 08 Aug 2005 08:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2708-0000ru-D2 for ltru@megatron.ietf.org; Mon, 08 Aug 2005 08:45:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18158 for ; Mon, 8 Aug 2005 08:45:04 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E27Xl-0006qc-R8 for ltru@ietf.org; Mon, 08 Aug 2005 09:19:55 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 8 Aug 2005 13:44:29 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Aug 2005 13:44:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs Date: Mon, 8 Aug 2005 13:44:28 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212DFFB2A@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] W3C tag policy disclaimers and IETF RFCs Thread-Index: AcWbiklFbJgyM5RAS7Oazdih6eIOIgAjKMuA From: "L.Gillam" To: rd , ltru X-OriginalArrivalTime: 08 Aug 2005 12:44:28.0441 (UTC) FILETIME=[EA526890:01C59C16] X-Spam-Score: 0.9 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0761852431==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0761852431== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59C16.EA25DE58" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59C16.EA25DE58 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jefsey, =20 On what official basis do you represent human and cultural interests and = civil rights? And for which peoples and cultures?=20 -----Original Message----- From: r&d afrac [mailto:rd@afrac.org] Sent: 07 August 2005 20:57 To: Gillam L Dr (Computing); ltru Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs =20 [snips]=20 It is rather a hobby to protect the human and cultural interests of as = many people as possible against the annoyments artificially created by = others. But first, it is a defense against a few people wanting to annoy = our work as much as they can.=20 Oh! no.... unfortunately just a necessity they impose on us. Also a = response to a demand of people, civil rights, industry and Govs, from = developed and developing countries to help protecting their culture. An = ethical duty. jfc ------_=_NextPart_001_01C59C16.EA25DE58 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jefsey,
 
On=20 what official basis do you represent human and cultural interests = and civil=20 rights? And for which peoples and = cultures? 
-----Original Message-----
From: r&d afrac=20 [mailto:rd@afrac.org]
Sent: 07 August 2005 = 20:57
To:=20 Gillam L Dr (Computing); ltru
Subject: RE: [Ltru] W3C tag = policy=20 disclaimers and IETF RFCs
 
[snips] 
It is = rather a hobby=20 to protect the human and cultural interests of as many people as = possible=20 against the annoyments artificially created by  others. But = first, it is=20 a defense against a few people wanting to annoy our work as much as = they can.=20
Oh! no.... unfortunately just a necessity they impose on us. Also = a=20 response to a demand of people, civil rights, industry and Govs, from=20 developed and developing countries to help protecting their culture. = An=20 ethical duty.

jfc
------_=_NextPart_001_01C59C16.EA25DE58-- --===============0761852431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0761852431==-- From ltru-bounces@lists.ietf.org Mon Aug 08 08:58:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27DQ-00042p-LR; Mon, 08 Aug 2005 08:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27DL-00042k-8o for ltru@megatron.ietf.org; Mon, 08 Aug 2005 08:58:47 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18752 for ; Mon, 8 Aug 2005 08:58:44 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E27Ag-0002vy-7f for ltru@lists.ietf.org; Mon, 08 Aug 2005 14:56:02 +0200 Received: from c-180-160-105.hh.dial.de.ignite.net ([62.180.160.105]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Aug 2005 14:56:02 +0200 Received: from nobody by c-180-160-105.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Aug 2005 14:56:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 08 Aug 2005 14:55:19 +0200 Organization: Lines: 14 Message-ID: <42F75637.980@xyzzy.claranet.de> References: <20050807154759.HOHA9082.mta1.adelphia.net@megatron.ietf.org> <004a01c59b6b$8b2fd1a0$030aa8c0@DEWELL> <20050807173319.GA15189@ccil.org> <021101c59be7$8bf58040$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-105.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Dates A and B redux X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > "OO" and "OOO" are special escape codes to indicate a switch > to a different coding system. We don't have to worry about > them in the registry because they are not assigned in ISO > 3166 Odd, on their decoder page "OO" is simply white => unassigned. > I can't find any previous message about this in my "Sent" > box. Probably I've seen it on Clive's ISO 3166 page. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 08 10:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28eo-0004rW-Fc; Mon, 08 Aug 2005 10:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28ek-0004p7-En for ltru@megatron.ietf.org; Mon, 08 Aug 2005 10:31:12 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24902 for ; Mon, 8 Aug 2005 10:31:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E28cE-0000KG-FY for ltru@lists.ietf.org; Mon, 08 Aug 2005 16:28:34 +0200 Received: from c-180-160-105.hh.dial.de.ignite.net ([62.180.160.105]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Aug 2005 16:28:34 +0200 Received: from nobody by c-180-160-105.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Aug 2005 16:28:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 08 Aug 2005 16:20:22 +0200 Organization: Lines: 93 Message-ID: <42F76A26.6F4@xyzzy.claranet.de> References: <42F60ECC.E62@xyzzy.claranet.de> <6.2.1.2.2.20050807161837.05694d40@mail.afrac.org> <42F66D85.7DE5@xyzzy.claranet.de> <6.2.1.2.2.20050808003809.056569e0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-105.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org r&d afrac wrote: > You probably know better why there is a W3C disclaimer. No, when I wrote "maybe" I was guessing, and when I said "if you're curious ask him" I meant it, literally. See for the complete thread, it was with the other tag: author. > I object you want to impose it to me who do not want it. If you don't like 3066bis language tags don't use them. All language tags I'm personally interested in (on my Web pages) have a Suppress-Script: Latn. From my POV nothing changes, I can even keep one en-GB-oed. Why should I join you and try to derail a draft allowing scripts for those who need it ? All problems in the old draft as far as I could identify them are fixed. I'm not at all interested in private-use language tags: Do what you like and hurt nobody. If that "restricts" you to letter-digit-hyphen and at most eight letters or digits before the next hyphen laugh about it, use UTF-8, encode it with base-64, insert hyphens, ready. "Jefsey insists on some funny private tags" would be SmVmc2V5IGluc2lzdHMgb24gc29tZSBmdW5ueSBwcml2YXRlIHRhZ3M= resulting in: x-SmVmc2V5-IGluc2lz-dHMgb24g-c29tZSBm-dW5ueSBw-cml2YXRl-IHRhZ3M Okay, case sensitive won't work, so find the RfC about base-32, or roll your own encoding scheme. If you're lost take hex. 0123456789ABCDEF and insert hyphens after eight hex. digits. If length doesn't matter percent-encode it replacing all "%" by "-". If that's not good enough for whatever you want check out Dublin Core or similar activities. > What is wrong is when the standard favors a commercial > implementation and blocks others or open source projects. The proposed standard favors KISS and compatibility with existing 3066 implementations. Apparently the latter is irrelevant for you, in that case you're free to propose whatever you like. Obviously not more related to LTRU - see the WG charter - but if you find new and interesting applications for the future registry ignoring the syntax for combined tags, just do so. After all that's exactly what we did here, combined stuff found elsewhere to 3066bis tags. You're free to use the 3066bis subtags in completely different ways. Or free to ignore them if they don't do what you want. > I wish I am sure your next free OS box is free of locale > related patented features. Software patents in our part of the world are meaningless. Has somebody really patented locales ? I hope they catch him before he hurts himself or others, he needs medical care in a closed environment. >> Of course the result will be something W3C and Unicode and >> ICU can live with, and it will be also something IMAP, MIME, >> etc. can live with. That was the purpose of this LTRU WG. > But not AFRAC? No idea, I don't know what "AFRAC" is and what it does. That doesn't mean anything, I also have no clue about IMAP, I only trust that Ira, Ned, or Bruce would tell us if we try something that won't work with IMAP. So far all you told us about "AFRAC" was that it distributes CD ROMs mirroring IANA registries, and we calculated that the maximal registry size after the addition of 7000+ languages (= 3066ter, not more 3066bis) could be about 500 KB and still fit on your CD ROM. So yes, we also considered that aspect, overall registry size. We also considered that I really hate to download big files with my V.90 line. But 500 KB is okay. And if it gets worse somebody will offer split views on the language tag registry: Maybe you or AFRAC offer a whois server, query = tag, reply = corresponding subtag entries in the complete registry. Bye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 08 11:25:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29Vb-0004Wi-Jb; Mon, 08 Aug 2005 11:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29Va-0004Wd-9w for ltru@megatron.ietf.org; Mon, 08 Aug 2005 11:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28123 for ; Mon, 8 Aug 2005 11:25:43 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2A3I-0002x8-6l for ltru@ietf.org; Mon, 08 Aug 2005 12:00:37 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E29VQ-0000PJ-LE; Mon, 08 Aug 2005 08:25:37 -0700 Message-Id: <6.2.1.2.2.20050808160559.03eb57a0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 08 Aug 2005 17:23:17 +0200 To: "L.Gillam" From: r&d afrac Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A212DFFB2A@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A212DFFB2A@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0007189000==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0007189000== Content-Type: multipart/alternative; boundary="=====================_19607313==.ALT" --=====================_19607313==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed On 14:44 08/08/2005, L.Gillam said: >Jefsey, >On what official basis do you represent human and cultural interests and >civil rights? And for which peoples and cultures? I am not sure I should answer such details in here (scope of the mailing list)? However I am for transparency. I have also been opposed by Addison who signs as "Chair, W3C Internationalisation ..." but says he does not speak in that position, but privately, what confused me and my partial support of his Draft. As far as I am concerned I always said I speak privately _and_ as a trustee of several efforts. I am also a member of various other organisations (see Google), I do not claim to speak here on their behalf (hat off). I am not sure of what you mean by "official", and you mix what I wrote. So, I will respond from my point of view, rather than from the point of view of others, documenting what I actually wrote. This is, I suppose, the best and most comprehensive response I can offer. I said "my 'hobby' is to protect the human and cultural interests of as many people as possible against the annoyments artificially created by others". I created Intlnet in 1978 to serve the development of the public International Network, with an innovate user-centric architecture. This organisation teamed with Tymnet until 1986. At this date commercial/network-centric interests took over Tymnet annoying my effort, which had lead to extended services analysis, models, first products deployment and Department. There was a split from Tymnet, and various projects using the OSI technology - where annoyment came from an unnecessary rigidity in implementing the network architecture. For a few years the Internet solutions permit in part to develop some R&D and projects. Artificial annoyments come (as documented by RFC 3869) from lack of non-commercial R&D, lack of experience and competence, network basic understanding and vision. This WG is a good example of this lack of understanding of the needs and of the vision to address them. It considers typographer's tools to address networked relations. Out of scope by lack of proper competent analysis of its Charter, and as such a dramatic possible nuisance due to its intended positionning. I talked of "a defense against a few people wanting to annoy our work as much as they can.". Until recently I though that W3C had a wrong evaluation of the market needs and due to that opposed the AFRAC work. That it did not yet identified our concurrent priorities. I respected the Draft propositions as possibly addressing some W3C members priorities, but I objected that this respect would be ballanced by a disrespect of the AFRAC needs. Now, Addison nearly simultaneously expressed that he conceived an IETF WG as a competition (confirming the reasons of my objections), that he is not here as a W3C Member (removing the reasons of my partial support) and has probably the motivation to annoy the thinking track we share with other W3C members (I am not interested in W3C internal discussions). I therefore feel totally at ease now to fully object the proposed Draft, as I see no technical interest in pursuing in the RFC 3066 error, documented in its security section. I also said it was "a response to a demand of people, civil rights, industry and Govs, from developed and developing countries to help protecting their culture". I am not bound to disclose my political/cultural engagements nor to violate privacy rules, or legal/contractual obligations. But some have been broadly disclosed on Google and from them you can deduce the level of others. I am an elected person in several organisations, an industry consultant, one of the activists of the @large movement, a Member and a speaker of the ccTLD Registry community, and the founder of the fast developing http://nicso.org small think-thank. It is part of the fall outs of the Intlnet dot-root experiment, along the lines of ICANN. Other initiatives are under way in other areas. I eventually said, "an ethical duty". We all have a duty to the people of the world, to the global internet community, to the IETF, to the members of the WG one shares in, to avoid mistakes being made when one identifies them. With 30 years of experience and ties in networking and cultural internetworking and in some other human, technical, artistic and political areas, I identify this Draft as the second and determining phase of a major error. I cannot do anything but to provide the service to the WG, the IETF, the GIC, etc. to help making sure it does not proceed. I certainly feel sorry for Addison's and Mark's. But an error can be sympathetic, it stays an error. And this one is not only big, but proud of being one big error. While it could be so easy to correct, as most of the biggest mistakes. You asked. I responded again. I hope you are satisfied. All this takes an awful lot of time, to prevent a catastrophe. Building would be more rewarding for all. jfc >-----Original Message----- >From: r&d afrac [mailto:rd@afrac.org] >Sent: 07 August 2005 20:57 >To: Gillam L Dr (Computing); ltru >Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs > >[snips] >It is rather a hobby to protect the human and cultural interests of as >many people as possible against the annoyments artificially created >by others. But first, it is a defense against a few people wanting to >annoy our work as much as they can. >Oh! no.... unfortunately just a necessity they impose on us. Also a >response to a demand of people, civil rights, industry and Govs, from >developed and developing countries to help protecting their culture. An >ethical duty. > >jfc --=====================_19607313==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit On 14:44 08/08/2005, L.Gillam said:
Jefsey,
On what official basis do you represent human and cultural interests and civil rights? And for which peoples and cultures?

I am not sure I should answer such details in here (scope of the mailing list)?

However I am for transparency. I have also been opposed by Addison who signs as "Chair, W3C Internationalisation ..." but says he does not speak in that position, but privately, what confused me and my partial support of his Draft. As far as I am concerned I always said I speak privately _and_ as a trustee of several efforts. I am also a member of various other organisations (see Google), I do not claim to speak here on their behalf (hat off).

I am not sure of what you mean by "official", and you mix what I wrote. So, I will respond from my point of view, rather than from the point of view of others, documenting what I actually wrote. This is, I suppose, the best and most comprehensive response I can offer.

I said "my 'hobby' is to protect the human and cultural interests of as many people as possible against the annoyments artificially created by others". I created Intlnet in 1978 to serve the development of the public International Network, with an innovate user-centric architecture. This organisation teamed with Tymnet until 1986. At this date commercial/network-centric interests took over Tymnet annoying my effort, which had lead to extended services analysis, models, first products deployment and Department. There was a split from Tymnet, and various projects using the OSI technology - where annoyment came from an unnecessary rigidity in implementing the network architecture. For a few years the Internet solutions permit in part to develop some R&D and projects. Artificial annoyments come (as documented by RFC 3869) from lack of non-commercial R&D, lack of experience and competence, network basic understanding and vision. This WG is a good example of this lack of understanding of the needs and of the vision to address them. It considers typographer's tools to address networked relations. Out of scope by lack of proper competent analysis of its Charter, and as such a dramatic possible nuisance due to its intended positionning.

I talked of "a defense against a few people wanting to annoy our work as much as they can.". Until recently I though that W3C had a wrong evaluation of the market needs and due to that opposed the AFRAC work. That it did not yet identified our concurrent priorities. I respected the Draft propositions as possibly addressing some W3C members priorities, but I objected that this respect would be ballanced by a disrespect of the AFRAC needs. Now, Addison nearly simultaneously expressed that he conceived an IETF WG as a competition (confirming the reasons of my objections), that he is not here as a W3C Member (removing the reasons of my partial support) and has probably the motivation to annoy the thinking track we share with other W3C members (I am not interested in W3C internal discussions). I therefore feel totally at ease now to fully object the proposed Draft, as I see no technical interest in pursuing in the RFC 3066 error, documented in its security section.

I also said it was "a response to a demand of people, civil rights, industry and Govs, from developed and developing countries to help protecting their culture". I am not bound to disclose my political/cultural engagements nor to violate privacy rules, or legal/contractual obligations. But some have been broadly disclosed on Google and from them you can deduce the level of others. I am an elected person in several organisations, an industry consultant, one of the activists of the @large movement, a Member and a speaker of the ccTLD Registry community, and the founder of the fast developing http://nicso.org small think-thank. It is part of the fall outs of the Intlnet dot-root experiment, along the lines of ICANN. Other initiatives are under way in other areas.

I eventually said, "an ethical duty". We all have a duty to the people of the world, to the global internet community, to the IETF, to the members of the WG one shares in, to avoid mistakes being made when one identifies them. With 30 years of experience and ties in networking and cultural internetworking and in some other human, technical, artistic and political areas, I identify this Draft as the second and determining phase of a major error. I cannot do anything but to provide the service to the WG, the IETF, the GIC, etc. to help making sure it does not proceed. I certainly feel sorry for Addison's and Mark's. But an error can be sympathetic, it stays an error. And this one is not only big, but proud of being one big error.

While it could be so easy to correct, as most of the biggest mistakes.

You asked. I responded again. I hope you are satisfied. All this takes an awful lot of time, to prevent a catastrophe. Building would be more rewarding for all.
jfc


-----Original Message-----
From: r&d afrac [mailto:rd@afrac.org ]
Sent: 07 August 2005 20:57
To: Gillam L Dr (Computing); ltru
Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs
 
[snips]
It is rather a hobby to protect the human and cultural interests of as many people as possible against the annoyments artificially created by  others. But first, it is a defense against a few people wanting to annoy our work as much as they can.
Oh! no.... unfortunately just a necessity they impose on us. Also a response to a demand of people, civil rights, industry and Govs, from developed and developing countries to help protecting their culture. An ethical duty.

jfc
--=====================_19607313==.ALT-- --===============0007189000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0007189000==-- From ltru-bounces@lists.ietf.org Mon Aug 08 12:33:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2AYw-0008Do-2V; Mon, 08 Aug 2005 12:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2AYu-0008Dj-5m for ltru@megatron.ietf.org; Mon, 08 Aug 2005 12:33:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01261 for ; Mon, 8 Aug 2005 12:33:13 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2B6c-0004nZ-PJ for ltru@ietf.org; Mon, 08 Aug 2005 13:08:08 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E2AYr-0005A2-1r; Mon, 08 Aug 2005 09:33:13 -0700 Message-Id: <6.2.1.2.2.20050808173842.03e6ac50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 08 Aug 2005 18:33:01 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs In-Reply-To: <42F76A26.6F4@xyzzy.claranet.de> References: <42F60ECC.E62@xyzzy.claranet.de> <6.2.1.2.2.20050807161837.05694d40@mail.afrac.org> <42F66D85.7DE5@xyzzy.claranet.de> <6.2.1.2.2.20050808003809.056569e0@mail.afrac.org> <42F76A26.6F4@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Frank, At 16:20 08/08/2005, Frank Ellermann wrote: >r&d afrac wrote: > > I object you want to impose it to me who do not want it. >If you don't like 3066bis language tags don't use them. :-) This is unfortunately not possible. RFC 3066 is a most unfortunate legacy of Harald Alvestrand. As an RFC and as a BCP. If the Draft is accepted it gets an _exclusive_ over language tagging/identification. The IESG like it or not. Some IESG people seem to feel they have been trapped into this problem. >All language tags I'm personally interested in (on my >Web pages) have a Suppress-Script: Latn. From my POV >nothing changes, I can even keep one en-GB-oed. I am personally interested in ISO 11179 compatible 20.000 language tags. >Why should I join you and try to derail a draft allowing >scripts for those who need it ? ??? Please stop thinking as Addison is. This is not a competition !!! No one asks you to "join me". We only as why would you exclude us and derail our approach, while we permit all yours? >All problems in the old draft as far as I could identify them are fixed. No. All the non Draft ABNF conformant format are excluded from the Internet standards. >I'm not at all interested in private-use language tags: >Do what you like and hurt nobody. If that "restricts" >you to letter-digit-hyphen and at most eight letters or >digits before the next hyphen laugh about it, use UTF-8, >encode it with base-64, insert hyphens, ready. 1. there is no reason the world messes all its formats to please Harald's old fancy 2. but even if the world accepted it: I documented practical case (K/H RFC conformant) which cannot be supported IMO. No one responded except by ad hominem. Without taking them again: these formats use ":,@/.?=%-" characters and "xn--" please document how you support them in hexatridecimal. >"Jefsey insists on some funny private tags" would be >SmVmc2V5IGluc2lzdHMgb24gc29tZSBmdW5ueSBwcml2YXRlIHRhZ3M= >resulting in: >x-SmVmc2V5-IGluc2lz-dHMgb24g-c29tZSBm-dW5ueSBw-cml2YXRl-IHRhZ3M this example is a joke. Respond the question above. >Okay, case sensitive won't work, so find the RfC about >base-32, or roll your own encoding scheme. If you're >lost take hex. 0123456789ABCDEF and insert hyphens after >eight hex. digits. :-) Are you not a little bit kidding? >If length doesn't matter percent-encode it replacing all >"%" by "-". If that's not good enough for whatever you >want check out Dublin Core or similar activities. :-) I am sure now you are kidding. > > What is wrong is when the standard favors a commercial > > implementation and blocks others or open source projects. > >The proposed standard favors KISS and compatibility with >existing 3066 implementations. Apparently the latter is >irrelevant for you, in that case you're free to propose >whatever you like. No intent to oppose. I just add the "0-" sequence. >Obviously not more related to LTRU - >see the WG charter - but if you find new and interesting >applications for the future registry ignoring the syntax >for combined tags, just do so. I am not considering "future" applications. I have long, long standing applications. It is as simple as that: or you add yours in a way which does not hurt ours (or we can accept to adapt to) or they will be denied. >After all that's exactly what we did here, combined stuff >found elsewhere to 3066bis tags. Obviously not. Or there would be no problem. >You're free to use the >3066bis subtags in completely different ways. Or free to >ignore them if they don't do what you want. No, I am not. But I am free to use Internet standard process rules and international agreement to block what is hurting my interests. Since I observe that my interests are also those of the German, of the French, of the EU, of Chinese, of Indian, etc. etc. interests I do not really feel alone in the process :-) The only problem I see with these guys is that they dont feel it is appropriate to step down in an IETF WG and do not want to oppose to this before it is at IANA stage. This means they will kill the project (until now I wanted to protect it, as I thought it was a W3C proposition) what may be a problem for some, as you point it out. This also means at least one or tow years delay, what interests no one. > > I wish I am sure your next free OS box is free of locale > > related patented features. > >Software patents in our part of the world are meaningless. > >Has somebody really patented locales ? I hope they catch >him before he hurts himself or others, he needs medical >care in a closed environment. You may be the one proposing it. I suggest you consider the CLDR project carefully. It may be a fully open source project for Windows? It may be a Windows project for Linux? I do not know: I asked and responses were refused (search archives for jefsey and CLDR). I think the question to be important enough to be asked and answered. I am at least sure some in the community will too. As people in Brussels also do. > >> Of course the result will be something W3C and Unicode and > >> ICU can live with, and it will be also something IMAP, MIME, > >> etc. can live with. That was the purpose of this LTRU WG. > > > But not AFRAC? > >No idea, I don't know what "AFRAC" is and what it does. That >doesn't mean anything, I also have no clue about IMAP, I only >trust that Ira, Ned, or Bruce would tell us if we try something >that won't work with IMAP. But you deny me the right to tell you that it does not work with us? >So far all you told us about "AFRAC" was that it distributes >CD ROMs mirroring IANA registries, and we calculated that the >maximal registry size after the addition of 7000+ languages >(= 3066ter, not more 3066bis) could be about 500 KB and still >fit on your CD ROM. It works on CRC (Common Reference Centers - distributed granular dramatic extension of IANA). Just go look at http://afrac.org. This means ISO 11179 compliant support of tags. Including language tags in any scheme:format. Some may want to develop libraries to use a centralised ASCII scheme as the one proposed by the Draft. No objection to that and we will fully support it. But K/H RFC fully documents why this is limited. The Draft for us is like a child saying "I know how to read 'abc', I do not want you to read anything else". We respect the programers/standardiser language equal opportunity declaration. Our interest is MGN (Multilingual Global NGN). >Maybe you or AFRAC offer a whois server, query = tag, reply = >corresponding subtag entries in the complete registry. Yes. This is one of the key issue we have. An RCP like "shuttle" protocol. The basic architectual option we took is to have: scheme:tag -> itemID query = itemID + authentication reply = crypted (response) One of the oddity of the Draft (this is one the many reasons why I say it is a "typographer" system) is that however we are in a network the tag name is flat. There is an absolute need for a scheme, even in the case you use a single central reference center: you must say the origin of the tag. When I say "x-jfc-angl" this may be the same as when you say "en-Latn-GB". Another oddity is that the Draft is so rigid, it must wait years to support ISO 639-3 and may be sometimes ISO 639-6. We already use them and whatever people want to use, we support them. This is just a double enntry in a table.... Another oddity of this Draft is that it does not document the class of the tags. All the tags are supposed to be language tags. Languages are important, but they are not alone? But most of all, the Draft is so constrained with its 3 main subtags. I obviously understand the reason why :-) ... but that cannot work. So why not to correct it. Definitly "0-" is the solution, unless you propose a better one.... But it is also a huge commercial/political loss for some ... IF the Draft goes through. jfc >Bye > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 08 13:03:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2B2C-0001AY-1x; Mon, 08 Aug 2005 13:03:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2B29-00016i-Qv for ltru@megatron.ietf.org; Mon, 08 Aug 2005 13:03:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03028 for ; Mon, 8 Aug 2005 13:03:26 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2BZs-0005da-7Q for ltru@ietf.org; Mon, 08 Aug 2005 13:38:21 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 8 Aug 2005 18:02:58 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Aug 2005 18:02:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs Date: Mon, 8 Aug 2005 18:02:56 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212DFFB46@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs Thread-Index: AcWcOPYalH4iLzEpQoC7m1JP9sEBnAAAjW/Q From: "L.Gillam" To: ltru X-OriginalArrivalTime: 08 Aug 2005 17:02:56.0987 (UTC) FILETIME=[0622BAB0:01C59C3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > No intent to oppose. I just add the "0-" sequence. Jefsey, Do you mean that you will create an RFC that takes in whatever is in the = current draft and expands it with 0- to provide whatever it is that you = want, such that the following would be allowed: en-US-0-jefsey.wants.this.to.be.possible? en-US-x-private-0-jefsey.wants.this.to.be.possible? 0-jefsey.wants.this.to.be.possible? ? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 08 15:33:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DNd-0007S1-8y; Mon, 08 Aug 2005 15:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DNb-0007Rj-VA for ltru@megatron.ietf.org; Mon, 08 Aug 2005 15:33:48 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12810 for ; Mon, 8 Aug 2005 15:33:45 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E2DLv-0006We-Qh for ltru@lists.ietf.org; Mon, 08 Aug 2005 21:32:03 +0200 Received: from du-042-231.access.de.clara.net ([213.221.65.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Aug 2005 21:32:03 +0200 Received: from nobody by du-042-231.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Aug 2005 21:32:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 08 Aug 2005 21:28:09 +0200 Organization: Lines: 31 Message-ID: <42F7B249.2FEC@xyzzy.claranet.de> References: <42F60ECC.E62@xyzzy.claranet.de> <6.2.1.2.2.20050807161837.05694d40@mail.afrac.org> <42F66D85.7DE5@xyzzy.claranet.de> <6.2.1.2.2.20050808003809.056569e0@mail.afrac.org> <42F76A26.6F4@xyzzy.claranet.de> <6.2.1.2.2.20050808173842.03e6ac50@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-231.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org r&d afrac wrote: > there is no reason the world messes all its formats to > please Harald's old fancy As I said, the results would be very different if we break backwards compatibility, The first thing I'd kill would be the weird 3166-1 region code zoo. PN is too small and US is too big. But that's dreaming, in reality breaking 3066 compatibility when it's not absolutely necessary is a bad idea. >> take hex. 0123456789ABCDEF and insert hyphens after eight >> hex. digits. > :-) Are you not a little bit kidding? Look at RfC 2047, IDNA, IRIs, UTF-8, etc.: Squeezing a new concept into the syntactical restrictions of older concepts is a bit ridiculous - but OTOH it's necessary if you are not free to start the whole Net from scratch. > I just add the "0-" sequence. Fair enough, 3066bis doesn't allow a digit as singleton, so even the most stupid 3066 or 3066bis implementation should immediately get the idea "this is no 3066 / 3066bis tag". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 08 17:30:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FCY-0000lF-IE; Mon, 08 Aug 2005 17:30:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FCW-0000l2-HF for ltru@megatron.ietf.org; Mon, 08 Aug 2005 17:30:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25921 for ; Mon, 8 Aug 2005 17:30:25 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2FkI-0007Th-QE for ltru@ietf.org; Mon, 08 Aug 2005 18:05:23 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E2FCU-0004qZ-Nw; Mon, 08 Aug 2005 14:30:27 -0700 Message-Id: <6.2.1.2.2.20050808224556.03e53750@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 08 Aug 2005 23:25:05 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs In-Reply-To: <42F7B249.2FEC@xyzzy.claranet.de> References: <42F60ECC.E62@xyzzy.claranet.de> <6.2.1.2.2.20050807161837.05694d40@mail.afrac.org> <42F66D85.7DE5@xyzzy.claranet.de> <6.2.1.2.2.20050808003809.056569e0@mail.afrac.org> <42F76A26.6F4@xyzzy.claranet.de> <6.2.1.2.2.20050808173842.03e6ac50@mail.afrac.org> <42F7B249.2FEC@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 21:28 08/08/2005, Frank Ellermann wrote: >r&d afrac wrote: > > there is no reason the world messes all its formats to > > please Harald's old fancy > >As I said, the results would be very different if we break >backwards compatibility, Dear Frank, again, this is not a competition between Addison's proposition and mine. This is to find what can support all the needs and not harm the others. 1. Addison wants to preserve backward compatibility. This is legitimate. But is of no use for applications which never used RFC 3066. 2. Lee documents that there is actually a possible interest with "x-" 8alphanum. This can have been used: I fully accept it is respected. 3. we need and use langtags with no relation with RFC 3066. The "0-" escape sequence permits to introduce them. Now, let review the impact on the propositions to make sure it is possible. 1. Addison's proposition is not affected by the "x-" support since it is a scheme used by RFC 3066. There is an error that Addison documented if "0-" is used. But "0-" is intended to be NOT supported by RFC 3066 compatible libraries. So we get what we actually _want_: an error. 2. the impact on our usage is to replace "xxx.xxx:xxx.xxx" by "0-xxx.xxx:xxx.xxx". This is a more substantial change. However, we are OK to make it. Should we have an agreement on that, we could then introduce the multilingual gobal tag proposition I documented in my response to Lee. 3. the Addison's format is a default scheme our libraries are to support. So, the Addison's format as no problem with me. >The first thing I'd kill would be the weird 3166-1 region code zoo. PN is >too small and US is too big. You should remember that langtags are to be used under many circumstances. When the langtag is to specify something related to a country (commecial agent, contractual obligations, IPRs, censoring, rates, e-commerce legal obligations, etc. etc.) there is no objection. The objection is to rigidity. The Draft makes me younger. It reminds me 20 years ago when we discussed X.500 in Geneva. I fought these ideas on the same grounds as today (complex ABNF, rigid constraints, etc.). We ultimately won .... You may want to use post codes, telephone areas, states, lingual, business, cultural, etc. areas. The real point is not what is in an IANA tables, but what you, your correspondant and your programs will commonly understand. If you decide to name your local German version "0-nobody@xyzzy.claranet.de:addison" and your friends' programs accept it, let it be! >But that's dreaming, in reality breaking 3066 compatibility >when it's not absolutely necessary is a bad idea. I would rather say "there must be an absolute necessity to keep a dumb stupid compatibility with a four years old arbitrary format". That your laibraries have not been updated is a good reason. But the main good reason is that you must be able to read old pages which used it. I suppose that for some times people found a solution: some are still keeping reading compatibility with the Egyptian hieroglyphs but some of us also use ASCII code.... > >> take hex. 0123456789ABCDEF and insert hyphens after eight > >> hex. digits. > > > :-) Are you not a little bit kidding? > >Look at RfC 2047, IDNA, IRIs, UTF-8, etc.: Squeezing a new >concept into the syntactical restrictions of older concepts >is a bit ridiculous - but OTOH it's necessary if you are >not free to start the whole Net from scratch. RFC 1958. There is only one permanent principle in the Internet architecture: except that principle everything may, has and will change. > > I just add the "0-" sequence. > >Fair enough, 3066bis doesn't allow a digit as singleton, so >even the most stupid 3066 or 3066bis implementation should >immediately get the idea "this is no 3066 / 3066bis tag". Yes. Addison fully documented that after testing on Mozilla. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 08 17:30:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FCY-0000lb-NI; Mon, 08 Aug 2005 17:30:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FCW-0000l6-Vg for ltru@megatron.ietf.org; Mon, 08 Aug 2005 17:30:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25924 for ; Mon, 8 Aug 2005 17:30:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2FkI-0007TI-Di for ltru@ietf.org; Mon, 08 Aug 2005 18:05:23 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E2FCP-0004qZ-NR; Mon, 08 Aug 2005 14:30:22 -0700 Message-Id: <6.2.1.2.2.20050808210443.03f5ceb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 08 Aug 2005 23:30:13 +0200 To: "L.Gillam" , ltru From: r&d afrac Subject: RE: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A212DFFB46@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A212DFFB46@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 19:02 08/08/2005, L.Gillam wrote: > > No intent to oppose. I just add the "0-" sequence. >Jefsey, >Do you mean that you will create an RFC that takes in whatever is in the >current draft and expands it with 0- to provide whatever it is that you >want, such that the following would be allowed: Dear Lee, The result is certainly in the form you say. But it cannot be documented in any other RFC if not permitted by this Draft. It needs the paragraph I introduced. >en-US-0-jefsey.wants.this.to.be.possible? >en-US-x-private-0-jefsey.wants.this.to.be.possible? >0-jefsey.wants.this.to.be.possible? Yes. Or respecting the K/H RFC: en-0-sheme.sub-scheme:subname.name. I then have two possibilities: either to propose the IESG to review the K/H RFC before it is published, to have a unique RFC or to introduce a generalised multilngual tagging system where the K/H RFC "tags:" scheme would be replaced by the "0-" sequence. All this is compatible with the Draft ABNF since it is made to stop at "0-". jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 00:20:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2LbH-0005Yr-00; Tue, 09 Aug 2005 00:20:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2LbF-0005Ym-2T for ltru@megatron.ietf.org; Tue, 09 Aug 2005 00:20:25 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27378 for ; Tue, 9 Aug 2005 00:20:21 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050809041952.IOCA24042.mta11.adelphia.net@DEWELL> for ; Tue, 9 Aug 2005 00:19:52 -0400 Message-ID: <001401c59c99$86292560$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 8 Aug 2005 21:19:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > Fair enough, 3066bis doesn't allow a digit as singleton Yes it does: singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" ; Single letters: x/X is reserved for private use The text in Section 3.6 continually refers to "single-letter subtags," left over from the days before the ABNF was expanded to allow digits (I forget when this was). Judging from all the attention this ABNF has gotten, I'd say the correct move is to trust the ABNF over the prose. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 02:04:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NDz-0005Oi-0R; Tue, 09 Aug 2005 02:04:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NDu-0005Mr-FM for ltru@megatron.ietf.org; Tue, 09 Aug 2005 02:04:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04586 for ; Tue, 9 Aug 2005 02:04:24 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E2NDi-0002qZ-8M for ltru@lists.ietf.org; Tue, 09 Aug 2005 08:04:14 +0200 Received: from du-001-196.access.de.clara.net ([212.82.227.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Aug 2005 08:04:14 +0200 Received: from nobody by du-001-196.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Aug 2005 08:04:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 09 Aug 2005 08:02:30 +0200 Organization: Lines: 29 Message-ID: <42F846F5.7121@xyzzy.claranet.de> References: <001401c59c99$86292560$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-196.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] singleton DIGIT (was: W3C tag policy disclaimers and IETF RFCs) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: >> Fair enough, 3066bis doesn't allow a digit as singleton > Yes it does: > singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT Sigh, and I thought that I know the ABNF by heart. So far for that idea. Jefsey has to pick another "escape" character for his "not-3066bis-scheme". Maybe "!" or "$". > left over from the days before the ABNF was expanded to allow > digits (I forget when this was). Added in -01, in -00 it was still without DIGIT. No idea what the old pre-LTRU drafts did, I don't find them anymore on Addison's pages. > Judging from all the attention this ABNF has gotten, I'd say > the correct move is to trust the ABNF over the prose. Yes, although I must admit that I don't recall _why_ DIGIT was added. John proposed to sort extensions alphabetically, and IIRC we discussed to exclude "y" and "z" - both ideas were rejected. I wanted "x" instead of "x" / "X" because in ABNF "x" is already case insensitive, also rejected, and that's all I can say without digging through the archive. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 09:28:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UA2-0005aE-BI; Tue, 09 Aug 2005 09:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2U9z-0005a9-An for ltru@megatron.ietf.org; Tue, 09 Aug 2005 09:28:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06188 for ; Tue, 9 Aug 2005 09:28:49 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Uht-0007dy-Kz for ltru@ietf.org; Tue, 09 Aug 2005 10:03:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E2U9s-0002HR-HI; Tue, 09 Aug 2005 06:28:45 -0700 Message-Id: <6.2.1.2.2.20050809104838.04ae66a0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 09 Aug 2005 15:05:06 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] singleton DIGIT (was: W3C tag policy disclaimers and IETF RFCs) In-Reply-To: <42F846F5.7121@xyzzy.claranet.de> References: <001401c59c99$86292560$030aa8c0@DEWELL> <42F846F5.7121@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA06188 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Structural comment below. For Members' coporate people. At 08:02 09/08/2005, Frank Ellermann wrote: >Doug Ewell wrote: > > >> Fair enough, 3066bis doesn't allow a digit as singleton > > Yes it does: > > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > >Sigh, and I thought that I know the ABNF by heart. So far for >that idea. Jefsey has to pick another "escape" character for >his "not-3066bis-scheme". Maybe "!" or "$". > > > left over from the days before the ABNF was expanded to allow > > digits (I forget when this was). > >Added in -01, in -00 it was still without DIGIT. No idea what >the old pre-LTRU drafts did, I don't find them anymore on >Addison's pages. > > > Judging from all the attention this ABNF has gotten, I'd say > > the correct move is to trust the ABNF over the prose. > >Yes, although I must admit that I don't recall _why_ DIGIT was >added. John proposed to sort extensions alphabetically, and >IIRC we discussed to exclude "y" and "z" - both ideas were >rejected. I wanted "x" instead of "x" / "X" because in ABNF >"x" is already case insensitive, also rejected, and that's all >I can say without digging through the archive. Dear Frank, RFC 3066 permitted digits in subtags. What Doug says is "I cannot support= =20 it in the document I write since I did not write that I would". This kind= =20 of position will obviously not hold for ever in front of IESG, IAB, GAC,=20 WTO, but if can confuse people enough to hold for years. This is why I am= =20 spending so much time explaining the obvious again and again. To give=20 "lawyers" quotes enough to discuss the bad or the good faith of the autho= rs. ABNF is not the point. You may note that only you and Lee, who are=20 motivated in finding a technical solution, in an IETF fashion, are=20 seriously following this technical thread. The point is political and=20 commercial. Why? And is it bad or not? Just try to figure out who are the customers here. Who has money in=20 language related industries? Who print, sell and buy books? Typographers,= =20 Publishers and Libraries. What is their common target? To sell/rent books= =20 to readers. Who are the readers? More and more Internet users. The=20 customers of the book industries evade books. Two things to do: cheaper=20 books and to move the book industry into the internet (and in so doing tr= y=20 to protect the existing market repartition and to invade the share of the= =20 slow movers) with the minimum of compromise with the natives (Yahoo!,=20 Google, etc.) Study http://www.unicode.org/history/boardmembers.html and=20 http://www.unicode.org/consortium/directors.html. Unicode is certainly th= e=20 most active and talented (*) place where this concerns can be discussed a= nd=20 acted upon. It certainly gathers representatives from the market and=20 customer leaders. It is likely that its propositions carry enormous weigh= t,=20 but also call for serious political attention. This attention is from the= =20 competition and the partners of its Directors and Executives corporations= ,=20 from cultural authorities. It is from Governments, due to this weight and= =20 the possible direct or indirect impact on the most sensitive human areas:= =20 culture, civilisation memory, political influence, religion, human=20 relations, etc. You may have noted the force and the speed of the Europea= n=20 reactions to the Google digital library announcement. (*) Some individual members are: Harald Alvestrand, John Cowan, Martin=20 D=FCrst, Doug Ewell, Jean-Fran=E7ois Morfin; some corporate Members (whos= e=20 employees also form the broad majority of the consortium directors and=20 executives) are: RLG (whose BoD Member is the only one to stay from the=20 very beginning), Microsoft, IBM, Apple, Cisco. Verisign just joined as a=20 Member. What is the target of the people gathered in Unicode? "The Unicode=20 Consortium is a non-profit organisation founded to develop, extend and=20 promote use of the Unicode Standard, which specifies the representation o= f=20 text in modern software products and standards." Unicode is therefore an=20 active participant to the W3C (web standards) and to ISO (international=20 standards). Now, read http://ietf.org/overview.html. It starts saying "The Internet=20 Engineering Task Force (IETF) is a large open international community of=20 network designers, operators, vendors, and researchers concerned with the= =20 evolution of the Internet architecture and the smooth operation of the=20 Internet." The first problem is here. Unicode (Mark Davis' culture) is about=20 characters in texts and W3C (Addison Philips' cultures) is about Web=20 i.e. modern software to print/display/speak texts. But IETF is about=20 Internet architecture and the Draft does not bridge the huge gap between=20 one of the network application, however big it is and however historicall= y=20 rooted it is, and the network architecture. The only way they have to kee= p=20 them together is to "constrain" the network into their typographer/printe= r=20 culture. This obviously cannot work. Typographer, printer and bookstores=20 chains are different trades. The second problem is that the customers needs are outdated and the book=20 industry does not know how to match our time's challenge. People like Pet= er=20 Constable and me certainly try to help in our own ways - him as an=20 employee, me as an applied searcher. This is the very same problem as=20 Telcos and music publishers. Book publishers and Libraries have been=20 impacted more slowly and for a longer time than Music publishers and Medi= a,=20 but the problem is similar. Music publishers introduced RPM, iPod, etc.=20 Book Publishers and Libraries introduce RFIDs and langtags. Is that a bad idea? No. It even looks very promising both for Libraries and Publishers, and for=20 software and service providers. A unique basis to build good organisation= =20 and market protection control. Every text can be tagged with a langtag; w= e=20 will find them everywhere (RFID on the books in bookstores, Libraries,=20 Colleges, etc. Operating System locales - Windows and Linux alike) with a= n=20 easy to add ISSN when printed. The catalogues, management, organisation=20 savings can be huge for publishers, libraries etc. This is very urgent=20 while the printer increasingly challenges the book. The need is to level=20 the practical cost of satisfaction of a book and of a printout; and to ge= t=20 the copyrights paid in both cases. Same problem as Sony and Napster. The=20 solution is like iPod: the library of Congress on an USB iLib, which can=20 plug on any bookprinter to come, and stay compatible whatever the version= =20 of text over the centuries. At the same time, the langtags makes it easier to rush down the web,=20 reading every web page, sorting them by langtags, reading them for=20 incorrect words, copyright infringement, etc. and printing the daily=20 police/lawyer report for copyright actions. I obviously only give rough lines and do not go into the details of the w= ay=20 it helps reducing costs, improving quality, increasing security etc.=20 through system convergence, simplification, etc. So, you understand why this Jefsey is a very bad/poor stupid troll, makin= g=20 "industry" to waste huge amounts of money with his "delaying practices". You also understand that if his "0-" were to be accepted the whole scheme= =20 would be useless. The whole thing is format exclusiveness, so _every_ boo= k=20 and page in the world can fit in a unique industry controlled format. Every other attempt MUST be excluded. And here is the huge "but". Because= =20 it scale and stay. The supposed retrocompatibility obligation with a never used format is on= ly=20 a bluff. This is probably one of the reasons why the WG-ltru never wanted= =20 to consider its Charter. The Charter says something quite different: "It = is=20 expected to specify a mechanism for easily identifying the role of each=20 subtag in the language tag, so that, for example, whenever a script code = or=20 country code is present in the tag it can be extracted, even without acce= ss=20 to a current version of the registry. Such a mechanism would clearly=20 distinguish between well-formed and valid language tags, to allow for=20 maximal compatibility between implementations released at different times= ,=20 and thus using different versions of the registry." Jefsey is also quite worrying. Because he works on the matter for 30 year= s=20 (among other things, I came to networking in 1976 in discussing with Xero= x,=20 Compugraphic, etc. about an international network to print books. I studi= ed=20 in 1979 with all the large newspapers not printing photos - Le Monde, la=20 Stampa, Die Welt, etc. - simultaneous locale editions over the=20 international public network. I managed my own daily economical newsfaxer= =20 during five years, with editions on Minitel, professional papers, etc.). = He=20 knows networks (I am first a Navy communication officer dealing with secu= re=20 world networks since 1971). He possibly has the technical user-centric=20 architecture to change all that (I do). He knows the future; and the futu= re=20 he knows is probably quite different from the past the industry wants to=20 protect (it extends it, it does not kill it). No way to permit his ideas=20 and demands through. He must be excluded. Whatever the way (including=20 anonymous telephone threads, what next?). Another problem with Jefsey: he is no English mother-tongue. So he knows=20 more and he is engaged into structures, solutions, propositions that do n= ot=20 want to use English as the language of reference. This is quite worrying=20 for several reasons. - One reason is that industry is mainly US driven and has no collective=20 knowledge, experience and practice of languages at this level.=20 Multilingualism is a difficult and complex area. Stakeholders prefer to=20 address it as an internationalisation+localisation=20 http://www.w3.org/TR/2005/WD-itsreq-20050805 which permits them (they=20 think, but this is one of the main technical error by lack of complete=20 analysis and modelisation) to simplify the issue and to control it from t= he=20 computer root (via CLDR: the control of locale files). - Another reason is that the industry is also conducted by market leaders= =20 which happen to be Americans and therefore to benefit from the American=20 commercial environment, and which are under European scrutiny for possibl= e=20 market dominant position. - Multilingualism is also a threat of balkanisation of the network which=20 would kill the acquired vision of the network and would remove the partia= l=20 protection provided by "an American built Internet" Hollywood story (Jefs= ey=20 knows the truth: danger). You can sue a Chinese in the US for having=20 violated a copyright on the Internet. This is more difficult if the=20 violation was on the "Chinese Internet", with Chinese domain names. The l= aw=20 will be the same, the eventual decision will be the same, but the cost=20 balance will switch: it will be cheaper to the Chinese user, and more=20 expansive to the multinational stakeholder. Another problem with Jefsey is that he only considers the "Web" as one=20 application on the network and not as the main system. The langtags MUST = be=20 the internal core of the Internet system to be on every text. Or the sche= me=20 will never be powerfull enough to work. There are obviously many other problems with Jefsey. I just wanted to quo= te=20 some. A last worrying one: he is impressed by technical pertinence and=20 vision, not by corporate positions. Now, I explained the why, may be interesting to discuss the bad/good issu= e. As often in period of dramatic industrial changes, industries fight for=20 survival in making incorrect short-sighted choices based upon immediate=20 self-protection (innovative quick consensus is quite unusual). The way to= =20 best help them is to accompany their change, in first trying to understan= d=20 its reasons. Often, as in this case, the change proceed in several phases= =20 due to the hysteresis of the interaction with technology and users: timin= g=20 is important. In fighting my graduated propositions to carefully move fro= m=20 one step to an other, the Draft affinity group actually represents a huge= =20 danger for the industry it wants to protect. They waste time and modern=20 solutions in fighting the last war. One can easily see that by the lack o= f=20 definition of the terms they use: it would show they confuse the contexts= .=20 As a consequence their resulting proposition will not be acceptable to=20 their competition, to their market partners, to governments etc. and is o= f=20 no real interest to their "end-users" (an old notion they have not yet=20 departed from). It is not far. But it is not acceptable. A simple explanation is that the= y=20 start from where they come from (typographers) instead of considering whe= re=20 they want to arrive (distributed networks). Also, that they have a wrong=20 economical model. Their model is to reduce costs through simplification,=20 what means rigidity. This could work if the market was dwindling. But the= =20 market is exploding. But not exploding in the way they see it=20 (publishing/rending stocked books), but in the way the users see it=20 (multimedia access to knowledge). Scalability and simplicity are confused= =20 with limitation: they do not mean less options; they mean an infinite=20 number of easy to get options and only a few built-in defaults. I must say they are not helped by the current status of the world thinkin= g.=20 The WSIS is a major misconception for them. "Information" is currently=20 understood as a mix between technical data and French 1960 "informatique"= .=20 The WSIS was initially a first attempt by librarians to address their=20 problem. It went out of their control. For the same reason why langtags a= re=20 to escape them. The problem is new, complex and a past protection approac= h=20 can only be increasingly inadequate. What they need is a solid, open,=20 stable, innovative and secure generalised network framework, where they c= an=20 lodge their own solutions. Unfortunately the Internet does not fully=20 deliver it, yet. This is why before addressing the book industry needs th= e=20 International Network system must first become a Multilingual Global NGN.= =20 The advantage of Majors over Unicode is that Music is a unique universal=20 languages. But pictures are multilingual - with a larger possible diversi= ty=20 of languages than texts. MPEG should be included in the analysis. The solution IMHO is to proceed step by step. Considering immediate=20 interests, ending with exclusion but carefully discussing timing,=20 experimentation and deployment areas. Until one can agree on a future=20 economical model. We can discuss that too. It will necessarily include the convergence of various forms of=20 data-providers (search engines, domain names, libraries, mail, etc.), of=20 content structures (architexts, multimedia, services), storing=20 (memorisation technologies are a key issue), o payment means (probably a=20 secure micro payment support). etc. Then the common standard MUST address= =20 the need of EVERYONE. Because it is legal, the IETF objective, but most o= f=20 all because it is business efficient in a network. And, what if Jefsey finds a trick to proceed otherwise? Take care. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 10:34:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VBI-0000Wx-MJ; Tue, 09 Aug 2005 10:34:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VBF-0000VP-LX for ltru@megatron.ietf.org; Tue, 09 Aug 2005 10:34:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11471 for ; Tue, 9 Aug 2005 10:34:10 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Vj7-0001J7-Bl for ltru@ietf.org; Tue, 09 Aug 2005 11:09:16 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j79EXu5q003608 for ; Tue, 9 Aug 2005 10:33:56 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j79EXurF227984 for ; Tue, 9 Aug 2005 10:33:56 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j79EXuAI006667 for ; Tue, 9 Aug 2005 10:33:56 -0400 Received: from markdavis (sig-9-48-113-12.mts.ibm.com [9.48.113.12]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j79EXsBk006501; Tue, 9 Aug 2005 10:33:55 -0400 Message-ID: <00ba01c59cef$5eba1f60$e9793009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <001401c59c99$86292560$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs Date: Tue, 9 Aug 2005 07:33:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j79EXu5q003608 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I agree. A minor editorial fix would be to correct 'letter' to 'character= ' in those cases. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Monday, August 08, 2005 21:19 Subject: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs > Frank Ellermann wrote: > > > Fair enough, 3066bis doesn't allow a digit as singleton > > Yes it does: > > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > ; Single letters: x/X is reserved for private use > > The text in Section 3.6 continually refers to "single-letter subtags," > left over from the days before the ABNF was expanded to allow digits (I > forget when this was). Judging from all the attention this ABNF has > gotten, I'd say the correct move is to trust the ABNF over the prose. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 11:26:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VzT-000784-6y; Tue, 09 Aug 2005 11:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VzS-00077z-FD for ltru@megatron.ietf.org; Tue, 09 Aug 2005 11:26:06 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15594 for ; Tue, 9 Aug 2005 11:26:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050809152530.RXKE19267.mta10.adelphia.net@DEWELL> for ; Tue, 9 Aug 2005 11:25:30 -0400 Message-ID: <086f01c59cf6$8a83aba0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 9 Aug 2005 08:25:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: singleton DIGIT (was: W3C tag policy disclaimers and IETF RFCs) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > What Doug says is "I cannot support it in the document I write since > I did not write that I would". If that is supposed to be a direct quote, I did not say it, and if it is supposed to be a paraphrase, I can't tell because I don't know what it means. Evidently JFC now realizes he can post whatever he likes without fear of administrative action, and is using that to best advantage. I simply quoted the draft, expressed no opinion except that ABNF should supersede body text, yet that was apparently enough to make me his next target. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 11:35:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2W87-0002sW-QX; Tue, 09 Aug 2005 11:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2W85-0002pV-Sn for ltru@megatron.ietf.org; Tue, 09 Aug 2005 11:35:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16090 for ; Tue, 9 Aug 2005 11:34:59 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Wg0-0003UX-EC for ltru@ietf.org; Tue, 09 Aug 2005 12:10:06 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 08:34:49 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.10]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 08:34:50 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETF RFCs) Date: Tue, 9 Aug 2005 08:34:45 -0700 Message-ID: Thread-Topic: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETF RFCs) Thread-Index: AcWc5xmJvxNk9gowT6iudUHTBzC7sQAC9l4Q From: "Peter Constable" To: X-OriginalArrivalTime: 09 Aug 2005 15:34:50.0236 (UTC) FILETIME=[E1664BC0:01C59CF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of r&d afrac > The first problem is here. Unicode (Mark Davis' culture) is about > characters in texts and W3C (Addison Philips' cultures) is about Web > i.e. modern software to print/display/speak texts. But IETF is about > Internet architecture and the Draft does not bridge the huge gap between > one of the network application, however big it is and however historically > rooted it is, and the network architecture. The only way they have to keep > them together is to "constrain" the network into their typographer/printer > culture. This obviously cannot work. Typographer, printer and bookstores > chains are different trades. This is a pretty empty critique. You assert that the draft fails to "bridge the gap...", but that is not a measurable technical specification. What specifically is the requirement -- what are the scenarios in which beneficial functionality is lacking? You have not identified any. Further, you assert that the authors have "'constrain[ed]' the network" to the requirements of typographers/printers, but there is nothing in the draft that reflects that, and furthermore it has been shown all along that the draft provides for tags for not-textual content equally with textual content. > The second problem is that the customers needs are outdated and the book > industry does not know how to match our time's challenge. Another empty critique since, as mentioned, there is nothing about this draft that limits it to use for textual content, let alone books in particular. Moreover, you have failed to acknowledge that this WG includes members of the non-print media industry, and those members are in support of the draft. > The supposed retrocompatibility obligation with a never used format is > only a bluff. Everyone else here seems to think otherwise. > Another problem with Jefsey: he is no English mother-tongue. So he knows > more=20 There's a fine bit of prejudice. If two people speak both English and French, one mother-tongue French and the other mother-tongue English, then the former is on that basis more knowledgeable? It's pretty arrogant to assert that you know more, and even discount the knowledge of others here who support the draft yet are not mother-tongue English speakers. > and he is engaged into structures, solutions, propositions that do > not > want to use English as the language of reference. This is quite worrying > for several reasons. Since we are discussing a specification for protocol elements that are themselves non-linguistic, abstract identifiers, this is irrelevant except in perhaps in regard to the language or languages in which the specification and documentation of the identifiers is provided. Anyone is free to translate these. It is not an IETF requirement that development of specifications be conducted in a multilingual manner. =20 > - One reason is that industry is mainly US driven and has no collective > knowledge, experience and practice of languages at this level. > Multilingualism is a difficult and complex area. Stakeholders prefer to > address it as an internationalisation+localisation Internationalization and localization are simply two aspects of product development in response to a multilingual environment. The fact that industry identifies these two items as significant in their own right does not make industry, or even US industries, ignorant of multilingualism. > Another problem with Jefsey is that he only considers the "Web" as one > application on the network and not as the main system. There is nothing about this draft that limits its focus of application to the Web. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 12:05:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Wbk-00050B-5B; Tue, 09 Aug 2005 12:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Wbh-0004zY-Ak for ltru@megatron.ietf.org; Tue, 09 Aug 2005 12:05:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19154 for ; Tue, 9 Aug 2005 12:05:32 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2X9a-0004rk-KO for ltru@ietf.org; Tue, 09 Aug 2005 12:40:39 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 09:05:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETF RFCs) Date: Tue, 9 Aug 2005 09:05:18 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C6792C9@irvmbxw01.quest.com> Thread-Topic: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETF RFCs) Thread-Index: AcWc5xlg4IPi3MwYSXC0Frr+QbwN7AAEmjnQ From: "Addison Phillips" To: X-OriginalArrivalTime: 09 Aug 2005 16:05:20.0253 (UTC) FILETIME=[242CBAD0:01C59CFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org There is nothing preventing the creation of a tagging scheme that is not = compatible with RFC 3066. There is no reason why one cannot create a new = and potentially better scheme, using whatever requirements one feels = compelling: I have proposed one myself in the past. I do not insist on the primacy of any particular design, but Jefsey's = design and proposed text do not meet a fundamental requirement for a = specification compatible with RFC 3066, which is one of the requirements = this Working Group has chosen to impose upon ourselves. It would be poor = practice to encourage malformed data to be transmitted using existing = RFC 3066 implementations and protocols, since we do not know the full = impact on interoperability. Therefore:=20 - I oppose the last call suggestion to put in text reserving the digit 0 = to introduce malformed tags. - I support fixing the text where it says "letter" to say "character" in = reference to singletons. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of r&d afrac > Sent: Tuesday, August 09, 2005 6:05 AM > To: Frank Ellermann; ltru@ietf.org > Subject: Re: [Ltru] singleton DIGIT (was: W3C tag policy = disclaimersand > IETF RFCs) >=20 > Structural comment below. For Members' coporate people. >=20 > At 08:02 09/08/2005, Frank Ellermann wrote: > >Doug Ewell wrote: > > > > >> Fair enough, 3066bis doesn't allow a digit as singleton > > > Yes it does: > > > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > > > >Sigh, and I thought that I know the ABNF by heart. So far for > >that idea. Jefsey has to pick another "escape" character for > >his "not-3066bis-scheme". Maybe "!" or "$". > > > > > left over from the days before the ABNF was expanded to allow > > > digits (I forget when this was). > > > >Added in -01, in -00 it was still without DIGIT. No idea what > >the old pre-LTRU drafts did, I don't find them anymore on > >Addison's pages. > > > > > Judging from all the attention this ABNF has gotten, I'd say > > > the correct move is to trust the ABNF over the prose. > > > >Yes, although I must admit that I don't recall _why_ DIGIT was > >added. John proposed to sort extensions alphabetically, and > >IIRC we discussed to exclude "y" and "z" - both ideas were > >rejected. I wanted "x" instead of "x" / "X" because in ABNF > >"x" is already case insensitive, also rejected, and that's all > >I can say without digging through the archive. >=20 > Dear Frank, > RFC 3066 permitted digits in subtags. What Doug says is "I cannot = support > it in the document I write since I did not write that I would". This = kind > of position will obviously not hold for ever in front of IESG, IAB, = GAC, > WTO, but if can confuse people enough to hold for years. This is why I = am > spending so much time explaining the obvious again and again. To give > "lawyers" quotes enough to discuss the bad or the good faith of the > authors. >=20 > ABNF is not the point. You may note that only you and Lee, who are > motivated in finding a technical solution, in an IETF fashion, are > seriously following this technical thread. The point is political and > commercial. >=20 > Why? And is it bad or not? >=20 >=20 > Just try to figure out who are the customers here. Who has money in > language related industries? Who print, sell and buy books? = Typographers, > Publishers and Libraries. What is their common target? To sell/rent = books > to readers. Who are the readers? More and more Internet users. The > customers of the book industries evade books. Two things to do: = cheaper > books and to move the book industry into the internet (and in so doing = try > to protect the existing market repartition and to invade the share of = the > slow movers) with the minimum of compromise with the natives (Yahoo!, > Google, etc.) >=20 > Study http://www.unicode.org/history/boardmembers.html and > http://www.unicode.org/consortium/directors.html. Unicode is certainly = the > most active and talented (*) place where this concerns can be = discussed > and > acted upon. It certainly gathers representatives from the market and > customer leaders. It is likely that its propositions carry enormous = weight, > but also call for serious political attention. This attention is from = the > competition and the partners of its Directors and Executives = corporations, > from cultural authorities. It is from Governments, due to this weight = and > the possible direct or indirect impact on the most sensitive human = areas: > culture, civilisation memory, political influence, religion, human > relations, etc. You may have noted the force and the speed of the = European > reactions to the Google digital library announcement. >=20 > (*) Some individual members are: Harald Alvestrand, John Cowan, Martin > D=FCrst, Doug Ewell, Jean-Fran=E7ois Morfin; some corporate Members = (whose > employees also form the broad majority of the consortium directors and > executives) are: RLG (whose BoD Member is the only one to stay from = the > very beginning), Microsoft, IBM, Apple, Cisco. Verisign just joined as = a > Member. >=20 > What is the target of the people gathered in Unicode? "The Unicode > Consortium is a non-profit organisation founded to develop, extend and > promote use of the Unicode Standard, which specifies the = representation of > text in modern software products and standards." Unicode is therefore = an > active participant to the W3C (web standards) and to ISO = (international > standards). >=20 >=20 > Now, read http://ietf.org/overview.html. It starts saying "The = Internet > Engineering Task Force (IETF) is a large open international community = of > network designers, operators, vendors, and researchers concerned with = the > evolution of the Internet architecture and the smooth operation of the > Internet." >=20 > The first problem is here. Unicode (Mark Davis' culture) is about > characters in texts and W3C (Addison Philips' cultures) is about Web > i.e. modern software to print/display/speak texts. But IETF is about > Internet architecture and the Draft does not bridge the huge gap = between > one of the network application, however big it is and however = historically > rooted it is, and the network architecture. The only way they have to = keep > them together is to "constrain" the network into their = typographer/printer > culture. This obviously cannot work. Typographer, printer and = bookstores > chains are different trades. >=20 >=20 > The second problem is that the customers needs are outdated and the = book > industry does not know how to match our time's challenge. People like > Peter > Constable and me certainly try to help in our own ways - him as an > employee, me as an applied searcher. This is the very same problem as > Telcos and music publishers. Book publishers and Libraries have been > impacted more slowly and for a longer time than Music publishers and = Media, > but the problem is similar. Music publishers introduced RPM, iPod, = etc. > Book Publishers and Libraries introduce RFIDs and langtags. >=20 > Is that a bad idea? No. >=20 > It even looks very promising both for Libraries and Publishers, and = for > software and service providers. A unique basis to build good = organisation > and market protection control. Every text can be tagged with a = langtag; we > will find them everywhere (RFID on the books in bookstores, Libraries, > Colleges, etc. Operating System locales - Windows and Linux alike) = with an > easy to add ISSN when printed. The catalogues, management, = organisation > savings can be huge for publishers, libraries etc. This is very urgent > while the printer increasingly challenges the book. The need is to = level > the practical cost of satisfaction of a book and of a printout; and to = get > the copyrights paid in both cases. Same problem as Sony and Napster. = The > solution is like iPod: the library of Congress on an USB iLib, which = can > plug on any bookprinter to come, and stay compatible whatever the = version > of text over the centuries. >=20 > At the same time, the langtags makes it easier to rush down the web, > reading every web page, sorting them by langtags, reading them for > incorrect words, copyright infringement, etc. and printing the daily > police/lawyer report for copyright actions. >=20 > I obviously only give rough lines and do not go into the details of = the > way > it helps reducing costs, improving quality, increasing security etc. > through system convergence, simplification, etc. >=20 >=20 > So, you understand why this Jefsey is a very bad/poor stupid troll, = making > "industry" to waste huge amounts of money with his "delaying = practices". >=20 > You also understand that if his "0-" were to be accepted the whole = scheme > would be useless. The whole thing is format exclusiveness, so _every_ = book > and page in the world can fit in a unique industry controlled format. >=20 > Every other attempt MUST be excluded. And here is the huge "but". = Because > it scale and stay. >=20 > The supposed retrocompatibility obligation with a never used format is > only > a bluff. This is probably one of the reasons why the WG-ltru never = wanted > to consider its Charter. The Charter says something quite different: = "It > is > expected to specify a mechanism for easily identifying the role of = each > subtag in the language tag, so that, for example, whenever a script = code > or > country code is present in the tag it can be extracted, even without > access > to a current version of the registry. Such a mechanism would clearly > distinguish between well-formed and valid language tags, to allow for > maximal compatibility between implementations released at different = times, > and thus using different versions of the registry." >=20 > Jefsey is also quite worrying. Because he works on the matter for 30 = years > (among other things, I came to networking in 1976 in discussing with = Xerox, > Compugraphic, etc. about an international network to print books. I > studied > in 1979 with all the large newspapers not printing photos - Le Monde, = la > Stampa, Die Welt, etc. - simultaneous locale editions over the > international public network. I managed my own daily economical = newsfaxer > during five years, with editions on Minitel, professional papers, = etc.). > He > knows networks (I am first a Navy communication officer dealing with > secure > world networks since 1971). He possibly has the technical user-centric > architecture to change all that (I do). He knows the future; and the > future > he knows is probably quite different from the past the industry wants = to > protect (it extends it, it does not kill it). No way to permit his = ideas > and demands through. He must be excluded. Whatever the way (including > anonymous telephone threads, what next?). >=20 > Another problem with Jefsey: he is no English mother-tongue. So he = knows > more and he is engaged into structures, solutions, propositions that = do > not > want to use English as the language of reference. This is quite = worrying > for several reasons. >=20 > - One reason is that industry is mainly US driven and has no = collective > knowledge, experience and practice of languages at this level. > Multilingualism is a difficult and complex area. Stakeholders prefer = to > address it as an internationalisation+localisation > http://www.w3.org/TR/2005/WD-itsreq-20050805 which permits them (they > think, but this is one of the main technical error by lack of complete > analysis and modelisation) to simplify the issue and to control it = from > the > computer root (via CLDR: the control of locale files). >=20 > - Another reason is that the industry is also conducted by market = leaders > which happen to be Americans and therefore to benefit from the = American > commercial environment, and which are under European scrutiny for = possible > market dominant position. >=20 > - Multilingualism is also a threat of balkanisation of the network = which > would kill the acquired vision of the network and would remove the = partial > protection provided by "an American built Internet" Hollywood story > (Jefsey > knows the truth: danger). You can sue a Chinese in the US for having > violated a copyright on the Internet. This is more difficult if the > violation was on the "Chinese Internet", with Chinese domain names. = The > law > will be the same, the eventual decision will be the same, but the cost > balance will switch: it will be cheaper to the Chinese user, and more > expansive to the multinational stakeholder. >=20 > Another problem with Jefsey is that he only considers the "Web" as one > application on the network and not as the main system. The langtags = MUST > be > the internal core of the Internet system to be on every text. Or the > scheme > will never be powerfull enough to work. >=20 > There are obviously many other problems with Jefsey. I just wanted to > quote > some. A last worrying one: he is impressed by technical pertinence and > vision, not by corporate positions. >=20 >=20 > Now, I explained the why, may be interesting to discuss the bad/good = issue. >=20 > As often in period of dramatic industrial changes, industries fight = for > survival in making incorrect short-sighted choices based upon = immediate > self-protection (innovative quick consensus is quite unusual). The way = to > best help them is to accompany their change, in first trying to = understand > its reasons. Often, as in this case, the change proceed in several = phases > due to the hysteresis of the interaction with technology and users: = timing > is important. In fighting my graduated propositions to carefully move = from > one step to an other, the Draft affinity group actually represents a = huge > danger for the industry it wants to protect. They waste time and = modern > solutions in fighting the last war. One can easily see that by the = lack of > definition of the terms they use: it would show they confuse the = contexts. > As a consequence their resulting proposition will not be acceptable = to > their competition, to their market partners, to governments etc. and = is of > no real interest to their "end-users" (an old notion they have not yet > departed from). >=20 > It is not far. But it is not acceptable. A simple explanation is that = they > start from where they come from (typographers) instead of considering > where > they want to arrive (distributed networks). Also, that they have a = wrong > economical model. Their model is to reduce costs through = simplification, > what means rigidity. This could work if the market was dwindling. But = the > market is exploding. But not exploding in the way they see it > (publishing/rending stocked books), but in the way the users see it > (multimedia access to knowledge). Scalability and simplicity are = confused > with limitation: they do not mean less options; they mean an infinite > number of easy to get options and only a few built-in defaults. >=20 > I must say they are not helped by the current status of the world = thinking. > The WSIS is a major misconception for them. "Information" is currently > understood as a mix between technical data and French 1960 = "informatique". > The WSIS was initially a first attempt by librarians to address their > problem. It went out of their control. For the same reason why = langtags > are > to escape them. The problem is new, complex and a past protection = approach > can only be increasingly inadequate. What they need is a solid, open, > stable, innovative and secure generalised network framework, where = they > can > lodge their own solutions. Unfortunately the Internet does not fully > deliver it, yet. This is why before addressing the book industry needs = the > International Network system must first become a Multilingual Global = NGN. > The advantage of Majors over Unicode is that Music is a unique = universal > languages. But pictures are multilingual - with a larger possible > diversity > of languages than texts. MPEG should be included in the analysis. >=20 >=20 > The solution IMHO is to proceed step by step. Considering immediate > interests, ending with exclusion but carefully discussing timing, > experimentation and deployment areas. Until one can agree on a future > economical model. We can discuss that too. >=20 > It will necessarily include the convergence of various forms of > data-providers (search engines, domain names, libraries, mail, etc.), = of > content structures (architexts, multimedia, services), storing > (memorisation technologies are a key issue), o payment means (probably = a > secure micro payment support). etc. Then the common standard MUST = address > the need of EVERYONE. Because it is legal, the IETF objective, but = most of > all because it is business efficient in a network. >=20 > And, what if Jefsey finds a trick to proceed otherwise? > Take care. > jfc >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 12:18:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Wo9-0006En-5y; Tue, 09 Aug 2005 12:18:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Wo6-0006Ec-VA for ltru@megatron.ietf.org; Tue, 09 Aug 2005 12:18:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19905 for ; Tue, 9 Aug 2005 12:18:23 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2XM0-0005Gz-Mb for ltru@ietf.org; Tue, 09 Aug 2005 12:53:31 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j79GIBCT008426 for ; Tue, 9 Aug 2005 12:18:11 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j79GIBRF262922 for ; Tue, 9 Aug 2005 12:18:11 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j79GIB9w009725 for ; Tue, 9 Aug 2005 12:18:11 -0400 Received: from markdavis (sig-9-48-113-12.mts.ibm.com [9.48.113.12]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j79GI9ws009612; Tue, 9 Aug 2005 12:18:10 -0400 Message-ID: <012501c59cfd$ef0924e0$e9793009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , References: <634978A7DF025A40BFEF33EB191E13BC0C6792C9@irvmbxw01.quest.com> Subject: Re: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETFRFCs) Date: Tue, 9 Aug 2005 09:18:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id j79GIBCT008426 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: Sent: Tuesday, August 09, 2005 09:05 Subject: RE: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETFRFCs) There is nothing preventing the creation of a tagging scheme that is not compatible with RFC 3066. There is no reason why one cannot create a new = and potentially better scheme, using whatever requirements one feels compelli= ng: I have proposed one myself in the past. I do not insist on the primacy of any particular design, but Jefsey's des= ign and proposed text do not meet a fundamental requirement for a specificati= on compatible with RFC 3066, which is one of the requirements this Working Group has chosen to impose upon ourselves. It would be poor practice to encourage malformed data to be transmitted using existing RFC 3066 implementations and protocols, since we do not know the full impact on interoperability. Therefore: - I oppose the last call suggestion to put in text reserving the digit 0 = to introduce malformed tags. - I support fixing the text where it says "letter" to say "character" in reference to singletons. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of r&d afrac > Sent: Tuesday, August 09, 2005 6:05 AM > To: Frank Ellermann; ltru@ietf.org > Subject: Re: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand > IETF RFCs) > > Structural comment below. For Members' coporate people. > > At 08:02 09/08/2005, Frank Ellermann wrote: > >Doug Ewell wrote: > > > > >> Fair enough, 3066bis doesn't allow a digit as singleton > > > Yes it does: > > > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > > > >Sigh, and I thought that I know the ABNF by heart. So far for > >that idea. Jefsey has to pick another "escape" character for > >his "not-3066bis-scheme". Maybe "!" or "$". > > > > > left over from the days before the ABNF was expanded to allow > > > digits (I forget when this was). > > > >Added in -01, in -00 it was still without DIGIT. No idea what > >the old pre-LTRU drafts did, I don't find them anymore on > >Addison's pages. > > > > > Judging from all the attention this ABNF has gotten, I'd say > > > the correct move is to trust the ABNF over the prose. > > > >Yes, although I must admit that I don't recall _why_ DIGIT was > >added. John proposed to sort extensions alphabetically, and > >IIRC we discussed to exclude "y" and "z" - both ideas were > >rejected. I wanted "x" instead of "x" / "X" because in ABNF > >"x" is already case insensitive, also rejected, and that's all > >I can say without digging through the archive. > > Dear Frank, > RFC 3066 permitted digits in subtags. What Doug says is "I cannot suppo= rt > it in the document I write since I did not write that I would". This ki= nd > of position will obviously not hold for ever in front of IESG, IAB, GAC= , > WTO, but if can confuse people enough to hold for years. This is why I = am > spending so much time explaining the obvious again and again. To give > "lawyers" quotes enough to discuss the bad or the good faith of the > authors. > > ABNF is not the point. You may note that only you and Lee, who are > motivated in finding a technical solution, in an IETF fashion, are > seriously following this technical thread. The point is political and > commercial. > > Why? And is it bad or not? > > > Just try to figure out who are the customers here. Who has money in > language related industries? Who print, sell and buy books? Typographer= s, > Publishers and Libraries. What is their common target? To sell/rent boo= ks > to readers. Who are the readers? More and more Internet users. The > customers of the book industries evade books. Two things to do: cheaper > books and to move the book industry into the internet (and in so doing = try > to protect the existing market repartition and to invade the share of t= he > slow movers) with the minimum of compromise with the natives (Yahoo!, > Google, etc.) > > Study http://www.unicode.org/history/boardmembers.html and > http://www.unicode.org/consortium/directors.html. Unicode is certainly = the > most active and talented (*) place where this concerns can be discussed > and > acted upon. It certainly gathers representatives from the market and > customer leaders. It is likely that its propositions carry enormous weight, > but also call for serious political attention. This attention is from t= he > competition and the partners of its Directors and Executives corporatio= ns, > from cultural authorities. It is from Governments, due to this weight a= nd > the possible direct or indirect impact on the most sensitive human area= s: > culture, civilisation memory, political influence, religion, human > relations, etc. You may have noted the force and the speed of the Europ= ean > reactions to the Google digital library announcement. > > (*) Some individual members are: Harald Alvestrand, John Cowan, Martin > D=C3=BCrst, Doug Ewell, Jean-Fran=C3=A7ois Morfin; some corporate Membe= rs (whose > employees also form the broad majority of the consortium directors and > executives) are: RLG (whose BoD Member is the only one to stay from the > very beginning), Microsoft, IBM, Apple, Cisco. Verisign just joined as = a > Member. > > What is the target of the people gathered in Unicode? "The Unicode > Consortium is a non-profit organisation founded to develop, extend and > promote use of the Unicode Standard, which specifies the representation= of > text in modern software products and standards." Unicode is therefore a= n > active participant to the W3C (web standards) and to ISO (international > standards). > > > Now, read http://ietf.org/overview.html. It starts saying "The Internet > Engineering Task Force (IETF) is a large open international community o= f > network designers, operators, vendors, and researchers concerned with t= he > evolution of the Internet architecture and the smooth operation of the > Internet." > > The first problem is here. Unicode (Mark Davis' culture) is about > characters in texts and W3C (Addison Philips' cultures) is about Web > i.e. modern software to print/display/speak texts. But IETF is about > Internet architecture and the Draft does not bridge the huge gap betwee= n > one of the network application, however big it is and however historica= lly > rooted it is, and the network architecture. The only way they have to k= eep > them together is to "constrain" the network into their typographer/prin= ter > culture. This obviously cannot work. Typographer, printer and bookstore= s > chains are different trades. > > > The second problem is that the customers needs are outdated and the boo= k > industry does not know how to match our time's challenge. People like > Peter > Constable and me certainly try to help in our own ways - him as an > employee, me as an applied searcher. This is the very same problem as > Telcos and music publishers. Book publishers and Libraries have been > impacted more slowly and for a longer time than Music publishers and Media, > but the problem is similar. Music publishers introduced RPM, iPod, etc. > Book Publishers and Libraries introduce RFIDs and langtags. > > Is that a bad idea? No. > > It even looks very promising both for Libraries and Publishers, and for > software and service providers. A unique basis to build good organisati= on > and market protection control. Every text can be tagged with a langtag;= we > will find them everywhere (RFID on the books in bookstores, Libraries, > Colleges, etc. Operating System locales - Windows and Linux alike) with= an > easy to add ISSN when printed. The catalogues, management, organisation > savings can be huge for publishers, libraries etc. This is very urgent > while the printer increasingly challenges the book. The need is to leve= l > the practical cost of satisfaction of a book and of a printout; and to = get > the copyrights paid in both cases. Same problem as Sony and Napster. Th= e > solution is like iPod: the library of Congress on an USB iLib, which ca= n > plug on any bookprinter to come, and stay compatible whatever the versi= on > of text over the centuries. > > At the same time, the langtags makes it easier to rush down the web, > reading every web page, sorting them by langtags, reading them for > incorrect words, copyright infringement, etc. and printing the daily > police/lawyer report for copyright actions. > > I obviously only give rough lines and do not go into the details of the > way > it helps reducing costs, improving quality, increasing security etc. > through system convergence, simplification, etc. > > > So, you understand why this Jefsey is a very bad/poor stupid troll, mak= ing > "industry" to waste huge amounts of money with his "delaying practices". > > You also understand that if his "0-" were to be accepted the whole sche= me > would be useless. The whole thing is format exclusiveness, so _every_ b= ook > and page in the world can fit in a unique industry controlled format. > > Every other attempt MUST be excluded. And here is the huge "but". Becau= se > it scale and stay. > > The supposed retrocompatibility obligation with a never used format is > only > a bluff. This is probably one of the reasons why the WG-ltru never want= ed > to consider its Charter. The Charter says something quite different: "I= t > is > expected to specify a mechanism for easily identifying the role of each > subtag in the language tag, so that, for example, whenever a script cod= e > or > country code is present in the tag it can be extracted, even without > access > to a current version of the registry. Such a mechanism would clearly > distinguish between well-formed and valid language tags, to allow for > maximal compatibility between implementations released at different tim= es, > and thus using different versions of the registry." > > Jefsey is also quite worrying. Because he works on the matter for 30 ye= ars > (among other things, I came to networking in 1976 in discussing with Xerox, > Compugraphic, etc. about an international network to print books. I > studied > in 1979 with all the large newspapers not printing photos - Le Monde, l= a > Stampa, Die Welt, etc. - simultaneous locale editions over the > international public network. I managed my own daily economical newsfax= er > during five years, with editions on Minitel, professional papers, etc.). > He > knows networks (I am first a Navy communication officer dealing with > secure > world networks since 1971). He possibly has the technical user-centric > architecture to change all that (I do). He knows the future; and the > future > he knows is probably quite different from the past the industry wants t= o > protect (it extends it, it does not kill it). No way to permit his idea= s > and demands through. He must be excluded. Whatever the way (including > anonymous telephone threads, what next?). > > Another problem with Jefsey: he is no English mother-tongue. So he know= s > more and he is engaged into structures, solutions, propositions that do > not > want to use English as the language of reference. This is quite worryin= g > for several reasons. > > - One reason is that industry is mainly US driven and has no collective > knowledge, experience and practice of languages at this level. > Multilingualism is a difficult and complex area. Stakeholders prefer to > address it as an internationalisation+localisation > http://www.w3.org/TR/2005/WD-itsreq-20050805 which permits them (they > think, but this is one of the main technical error by lack of complete > analysis and modelisation) to simplify the issue and to control it from > the > computer root (via CLDR: the control of locale files). > > - Another reason is that the industry is also conducted by market leade= rs > which happen to be Americans and therefore to benefit from the American > commercial environment, and which are under European scrutiny for possi= ble > market dominant position. > > - Multilingualism is also a threat of balkanisation of the network whic= h > would kill the acquired vision of the network and would remove the part= ial > protection provided by "an American built Internet" Hollywood story > (Jefsey > knows the truth: danger). You can sue a Chinese in the US for having > violated a copyright on the Internet. This is more difficult if the > violation was on the "Chinese Internet", with Chinese domain names. The > law > will be the same, the eventual decision will be the same, but the cost > balance will switch: it will be cheaper to the Chinese user, and more > expansive to the multinational stakeholder. > > Another problem with Jefsey is that he only considers the "Web" as one > application on the network and not as the main system. The langtags MUS= T > be > the internal core of the Internet system to be on every text. Or the > scheme > will never be powerfull enough to work. > > There are obviously many other problems with Jefsey. I just wanted to > quote > some. A last worrying one: he is impressed by technical pertinence and > vision, not by corporate positions. > > > Now, I explained the why, may be interesting to discuss the bad/good issue. > > As often in period of dramatic industrial changes, industries fight for > survival in making incorrect short-sighted choices based upon immediate > self-protection (innovative quick consensus is quite unusual). The way = to > best help them is to accompany their change, in first trying to underst= and > its reasons. Often, as in this case, the change proceed in several phas= es > due to the hysteresis of the interaction with technology and users: tim= ing > is important. In fighting my graduated propositions to carefully move f= rom > one step to an other, the Draft affinity group actually represents a hu= ge > danger for the industry it wants to protect. They waste time and modern > solutions in fighting the last war. One can easily see that by the lack= of > definition of the terms they use: it would show they confuse the contex= ts. > As a consequence their resulting proposition will not be acceptable to > their competition, to their market partners, to governments etc. and is= of > no real interest to their "end-users" (an old notion they have not yet > departed from). > > It is not far. But it is not acceptable. A simple explanation is that t= hey > start from where they come from (typographers) instead of considering > where > they want to arrive (distributed networks). Also, that they have a wron= g > economical model. Their model is to reduce costs through simplification= , > what means rigidity. This could work if the market was dwindling. But t= he > market is exploding. But not exploding in the way they see it > (publishing/rending stocked books), but in the way the users see it > (multimedia access to knowledge). Scalability and simplicity are confus= ed > with limitation: they do not mean less options; they mean an infinite > number of easy to get options and only a few built-in defaults. > > I must say they are not helped by the current status of the world thinking. > The WSIS is a major misconception for them. "Information" is currently > understood as a mix between technical data and French 1960 "informatiqu= e". > The WSIS was initially a first attempt by librarians to address their > problem. It went out of their control. For the same reason why langtags > are > to escape them. The problem is new, complex and a past protection appro= ach > can only be increasingly inadequate. What they need is a solid, open, > stable, innovative and secure generalised network framework, where they > can > lodge their own solutions. Unfortunately the Internet does not fully > deliver it, yet. This is why before addressing the book industry needs = the > International Network system must first become a Multilingual Global NG= N. > The advantage of Majors over Unicode is that Music is a unique universa= l > languages. But pictures are multilingual - with a larger possible > diversity > of languages than texts. MPEG should be included in the analysis. > > > The solution IMHO is to proceed step by step. Considering immediate > interests, ending with exclusion but carefully discussing timing, > experimentation and deployment areas. Until one can agree on a future > economical model. We can discuss that too. > > It will necessarily include the convergence of various forms of > data-providers (search engines, domain names, libraries, mail, etc.), o= f > content structures (architexts, multimedia, services), storing > (memorisation technologies are a key issue), o payment means (probably = a > secure micro payment support). etc. Then the common standard MUST addre= ss > the need of EVERYONE. Because it is legal, the IETF objective, but most= of > all because it is business efficient in a network. > > And, what if Jefsey finds a trick to proceed otherwise? > Take care. > jfc > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 12:23:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2WsW-0000YV-63; Tue, 09 Aug 2005 12:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2WsT-0000WZ-V9 for ltru@megatron.ietf.org; Tue, 09 Aug 2005 12:22:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20439 for ; Tue, 9 Aug 2005 12:22:55 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2XQP-0005WF-2g for ltru@ietf.org; Tue, 09 Aug 2005 12:58:02 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j79GJ2pX006902; Tue, 9 Aug 2005 19:19:02 +0300 (EEST) Message-ID: <42F8D77B.4080703@kotus.fi> Date: Tue, 09 Aug 2005 19:19:07 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETF RFCs) References: <634978A7DF025A40BFEF33EB191E13BC0C6792C9@irvmbxw01.quest.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I concur with this. Erkki I. Kolehmainen Addison Phillips wrote: > There is nothing preventing the creation of a tagging scheme that is not compatible with RFC 3066. There is no reason why one cannot create a new and potentially better scheme, using whatever requirements one feels compelling: I have proposed one myself in the past. > > I do not insist on the primacy of any particular design, but Jefsey's design and proposed text do not meet a fundamental requirement for a specification compatible with RFC 3066, which is one of the requirements this Working Group has chosen to impose upon ourselves. It would be poor practice to encourage malformed data to be transmitted using existing RFC 3066 implementations and protocols, since we do not know the full impact on interoperability. > > Therefore: > > - I oppose the last call suggestion to put in text reserving the digit 0 to introduce malformed tags. > > - I support fixing the text where it says "letter" to say "character" in reference to singletons. > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 12:27:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2WxH-0002zX-DH; Tue, 09 Aug 2005 12:27:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2WxF-0002zS-Bb for ltru@megatron.ietf.org; Tue, 09 Aug 2005 12:27:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20625 for ; Tue, 9 Aug 2005 12:27:50 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2XVA-0005dJ-K4 for ltru@ietf.org; Tue, 09 Aug 2005 13:02:57 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 9 Aug 2005 16:27:29 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IKY00J8HR1TP5@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Tue, 09 Aug 2005 17:27:29 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Tue, 09 Aug 2005 17:27:28 +0100 Date: Tue, 09 Aug 2005 17:27:28 +0100 From: Misha Wolf Subject: RE: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETFRFCs) To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF78044D500E@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETFRFCs) Thread-Index: AcWc5xlg4IPi3MwYSXC0Frr+QbwN7AAEmjnQAAFtLCA= content-class: urn:content-classes:message X-OriginalArrivalTime: 09 Aug 2005 16:27:28.0863 (UTC) FILETIME=[3C1686F0:01C59CFF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Addison Phillips Sent: 09 August 2005 17:05 To: ltru@ietf.org Subject: RE: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETFRFCs) There is nothing preventing the creation of a tagging scheme that is not compatible with RFC 3066. There is no reason why one cannot create a new and potentially better scheme, using whatever requirements one feels compelling: I have proposed one myself in the past. I do not insist on the primacy of any particular design, but Jefsey's design and proposed text do not meet a fundamental requirement for a specification compatible with RFC 3066, which is one of the requirements this Working Group has chosen to impose upon ourselves. It would be poor practice to encourage malformed data to be transmitted using existing RFC 3066 implementations and protocols, since we do not know the full impact on interoperability. Therefore:=20 - I oppose the last call suggestion to put in text reserving the digit 0 to introduce malformed tags. - I support fixing the text where it says "letter" to say "character" in reference to singletons. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 12:33:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X2q-0005U5-QY; Tue, 09 Aug 2005 12:33:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X2p-0005Qd-PN for ltru@megatron.ietf.org; Tue, 09 Aug 2005 12:33:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21426 for ; Tue, 9 Aug 2005 12:33:36 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Xai-0005p1-TM for ltru@ietf.org; Tue, 09 Aug 2005 13:08:44 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j79GXLTQ024808; Tue, 9 Aug 2005 12:33:21 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 9 Aug 2005 12:33:19 -0400 Date: Tue, 9 Aug 2005 12:33:18 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETF RFCs) Message-ID: <20050809163318.GB6072@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C6792C9@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C6792C9@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > - I oppose the last call suggestion to put in text reserving the digit > 0 to introduce malformed tags. > > - I support fixing the text where it says "letter" to say "character" > in reference to singletons. And so say I. -- My confusion is rapidly waxing John Cowan For XML Schema's too taxing: jcowan@reutershealth.com I'd use DTDs http://www.reutershealth.com If they had local trees -- http://www.ccil.org/~cowan I think I best switch to RELAX NG. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 12:36:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X5u-00064B-Lt; Tue, 09 Aug 2005 12:36:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X5t-00063l-1b for ltru@megatron.ietf.org; Tue, 09 Aug 2005 12:36:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21861 for ; Tue, 9 Aug 2005 12:36:34 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2Xdc-0005vW-PQ for ltru@ietf.org; Tue, 09 Aug 2005 13:11:42 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 9 Aug 2005 17:36:19 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 17:36:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] singleton DIGIT (was: W3C tag policy disclaimers and IETF RFCs) Date: Tue, 9 Aug 2005 17:36:18 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212DFFB6D@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] singleton DIGIT (was: W3C tag policy disclaimers and IETF RFCs) Thread-Index: AcWc6BIZlQ9RMi+HQjm6WuKa+huxkgAF8C3w From: "L.Gillam" To: rd , ltru X-OriginalArrivalTime: 09 Aug 2005 16:36:18.0600 (UTC) FILETIME=[77D5FA80:01C59D00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of r&d afrac > Sent: 09 August 2005 14:05 > To: Frank Ellermann; ltru@ietf.org > Subject: Re: [Ltru] singleton DIGIT (was: W3C tag policy=20 > disclaimers and > IETF RFCs) [snip] > ABNF is not the point. You may note that only you and Lee, who are=20 > motivated in finding a technical solution, in an IETF fashion, are=20 > seriously following this technical thread. The point is political and=20 > commercial. [snip] Let me try to stay away from "potentially" inflammatory material and ask = a relatively straightforward question: Is there anything to prevent Jefsey creating a new kind of tag - for the = sake of argument, let's say "Tags for the unique identification of = Internet content", that provides a combination that can be declared in = ABNF of Language Identifiers (RFC 3066) and the 'tag' URI scheme such = that e.g. jefseyTag =3D "jefsey:" Language-Tag "-0-" tagURI which, since -0- is reserved in the 3066 scheme has the rule that if = there are 2 -0- strings, the second denotes the beginning of the tagURI. = Could he, in fact, produce something that *was* partially compatible = with 3066 and yet let him do precisely what he wanted to beyond this = compatibility, without needing to bother the draft document with it? If the answer is "yes", perhaps everybody can be happy. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 13:59:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2YOJ-00065Z-KP; Tue, 09 Aug 2005 13:59:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2YOH-00065F-KT for ltru@megatron.ietf.org; Tue, 09 Aug 2005 13:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26304 for ; Tue, 9 Aug 2005 13:59:51 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2YwE-0007yJ-HS for ltru@ietf.org; Tue, 09 Aug 2005 14:34:58 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E2YOB-0002Cv-J6; Tue, 09 Aug 2005 10:59:48 -0700 Message-Id: <6.2.1.2.2.20050809175900.04eb0bd0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 09 Aug 2005 19:59:42 +0200 To: "Peter Constable" From: r&d afrac Subject: RE: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETF RFCs) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 17:34 09/08/2005, Peter Constable said: > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On > > Behalf Of r&d afrac Dear Peter, thank you for your comments. Always a pleasure. >This is a pretty empty critique. You assert that the draft fails to >"bridge the gap...", but that is not a measurable technical >specification. What specifically is the requirement -- what are the >scenarios in which beneficial functionality is lacking? You have not >identified any. Difficult to list what is missing since it is precisely all the missing debate I am calling for. What would be easier is to list what in this Draft is IETF specifc, addressing the network aspects. For example, as I listed it, the missing term definitions do not permit the Draft to indicate what it actually talk about. >Further, you assert that the authors have >"'constrain[ed]' the network" to the requirements of >typographers/printers, but there is nothing in the draft that reflects >that, and furthermore it has been shown all along that the draft >provides for tags for not-textual content equally with textual content. The Draft intends to constrain RFC 3066. This is not only visible in comparing the two texts. But has been fully documented by Addison. I am always interested in reading you. But even if we have now reached the point where you now have to "sell" your document and for the rest of us to buy it or not, I suggest you do not engage in a salesman pitch saying that your deliverable does not do what it has been designed for, just because you know that your prospects do not like it. > > The second problem is that the customers needs are outdated and the >book > > industry does not know how to match our time's challenge. > >Another empty critique since, as mentioned, there is nothing about this >draft that limits it to use for textual content, let alone books in >particular. Moreover, you have failed to acknowledge that this WG >includes members of the non-print media industry, and those members are >in support of the draft. The people of this WG have been called to say they support the Draft. A very few shown up, BTW. May be can you make their list and point out which one(s) are for non-print media industry. Or would you have been privy to informations reserved to co-Chairs? Randy gave such reference on the eitf main list which were declined by the quoted persons. > > The supposed retrocompatibility obligation with a never used format is > > only a bluff. > >Everyone else here seems to think otherwise. These is the very nature of a bluff. That people start saying they support it. But to tell that "everyone" supports it is part of it. > > Another problem with Jefsey: he is no English mother-tongue. So he >knows > > more > >There's a fine bit of prejudice. If two people speak both English and >French, one mother-tongue French and the other mother-tongue English, >then the former is on that basis more knowledgeable? It's pretty >arrogant to assert that you know more, and even discount the knowledge >of others here who support the draft yet are not mother-tongue English >speakers. Deep apologies. This is obviously not what I intended to say. A part has been removed during editing (problem in not being an English mother-tongue person is that editing is more complex. But this is the very nature of a multilingual WG: you should have guess it?) The text said "So, he knows more about multilingualism from a non-English speaker perspective, what is 70% of the demand." This will be corrected in copies. And I certainly stand this. > > and he is engaged into structures, solutions, propositions that do > > not > > want to use English as the language of reference. This is quite >worrying > > for several reasons. > >Since we are discussing a specification for protocol elements that are >themselves non-linguistic, abstract identifiers, this is irrelevant >except in perhaps in regard to the language or languages in which the >specification and documentation of the identifiers is provided. Anyone >is free to translate these. It is not an IETF requirement that >development of specifications be conducted in a multilingual manner. By itself this comment documents the pertinence of what you first comment opposed. I will not engage in discussing this. I just want you to accept that positions like this one are by themselves a problem both in term of multilingualism and networking. Your culture of the two subject is ... not mine. > > - One reason is that industry is mainly US driven and has no >collective > > knowledge, experience and practice of languages at this level. > > Multilingualism is a difficult and complex area. Stakeholders prefer >to > > address it as an internationalisation+localisation > >Internationalization and localization are simply two aspects of product >development in response to a multilingual environment. The fact that >industry identifies these two items as significant in their own right >does not make industry, or even US industries, ignorant of >multilingualism. Same comment as above. I do not want to discuss this kind of point. You are perfectly entitled to submit them. But you should understand at your level of expertise why they may be questionned. > > Another problem with Jefsey is that he only considers the "Web" as one > > application on the network and not as the main system. > >There is nothing about this draft that limits its focus of application >to the Web. It would be surprising it would, since its purpose is to apply a solution to the web in order to extend it to the entire Internet architecture. What I find delightful is your capacity to not respond. But this capacity is not ignored. Have great vacations. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 13:59:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2YOJ-00065x-VK; Tue, 09 Aug 2005 13:59:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2YOH-00065K-SJ for ltru@megatron.ietf.org; Tue, 09 Aug 2005 13:59:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26307 for ; Tue, 9 Aug 2005 13:59:52 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2YwE-0007yM-HO for ltru@ietf.org; Tue, 09 Aug 2005 14:34:59 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E2YOC-0002Cv-R2; Tue, 09 Aug 2005 10:59:49 -0700 Message-Id: <6.2.1.2.2.20050809184203.05a84900@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 09 Aug 2005 19:09:45 +0200 To: "Addison Phillips" , From: r&d afrac Subject: RE: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersand IETF RFCs) In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C6792C9@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C6792C9@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA26307 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 18:05 09/08/2005, Addison Phillips wrote: >There is nothing preventing the creation of a tagging scheme that is not= =20 >compatible with RFC 3066. There is no reason why one cannot create a new= =20 >and potentially better scheme, using whatever requirements one feels=20 >compelling: I have proposed one myself in the past. Dear Addison, this wording is correct: this is the case of Kindberg/Hawse RFC. However, the claim of the Draft to replace RFC 3066 and therefore to beco= me=20 BCP 47 strictly forbides to use another _language_ tagging system that yo= ur=20 ABNF. Your draft MUST be the _best_ to address the needs it is to address. If y= ou=20 think there are a better one (what I also believe) you cannot honnestly=20 present it to an IESG review. >I do not insist on the primacy of any particular design, Yes you do, in claiming replacing by your sole own the clumsy RFC 3066. >but Jefsey's design and proposed text do not meet a fundamental=20 >requirement for a specification compatible with RFC 3066, which is one o= f=20 >the requirements this Working Group has chosen to impose upon ourselves. Reference of this consensual decision? This WG would then have opposed its Charter to improve rather than=20 downgrade RFC 3066 :-) >It would be poor practice to encourage malformed data to be transmitted=20 >using existing RFC 3066 implementations and protocols, since we do not=20 >know the full impact on interoperability. Please stop this non-sense. The only result is that we are going to keep=20 chatting now and then during the next two next years in blocking a draft=20 your industry needs, >Therefore: >- I oppose the last call suggestion to put in text reserving the digit 0= =20 >to introduce malformed tags. Agreed. The "0-" is to escape the Draft ABNF and to permit to introduce=20 "better schemes", like the one you introduced in the past. May be will yo= u=20 be kind enough to give the reference. I see we agree now: maformed tags a= re=20 to be before "0-" and tags after "0-", MUST be correctly informed tags,=20 following the K/H RFC. >- I support fixing the text where it says "letter" to say "character" in= =20 >reference to singletons. I support that. The clearer it is that you want to exclude "better=20 schemes", the best it is for everyone. jfc >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org= ] On > > Behalf Of r&d afrac > > Sent: Tuesday, August 09, 2005 6:05 AM > > To: Frank Ellermann; ltru@ietf.org > > Subject: Re: [Ltru] singleton DIGIT (was: W3C tag policy disclaimersa= nd > > IETF RFCs) > > > > Structural comment below. For Members' coporate people. > > > > At 08:02 09/08/2005, Frank Ellermann wrote: > > >Doug Ewell wrote: > > > > > > >> Fair enough, 3066bis doesn't allow a digit as singleton > > > > Yes it does: > > > > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > > > > > >Sigh, and I thought that I know the ABNF by heart. So far for > > >that idea. Jefsey has to pick another "escape" character for > > >his "not-3066bis-scheme". Maybe "!" or "$". > > > > > > > left over from the days before the ABNF was expanded to allow > > > > digits (I forget when this was). > > > > > >Added in -01, in -00 it was still without DIGIT. No idea what > > >the old pre-LTRU drafts did, I don't find them anymore on > > >Addison's pages. > > > > > > > Judging from all the attention this ABNF has gotten, I'd say > > > > the correct move is to trust the ABNF over the prose. > > > > > >Yes, although I must admit that I don't recall _why_ DIGIT was > > >added. John proposed to sort extensions alphabetically, and > > >IIRC we discussed to exclude "y" and "z" - both ideas were > > >rejected. I wanted "x" instead of "x" / "X" because in ABNF > > >"x" is already case insensitive, also rejected, and that's all > > >I can say without digging through the archive. > > > > Dear Frank, > > RFC 3066 permitted digits in subtags. What Doug says is "I cannot sup= port > > it in the document I write since I did not write that I would". This = kind > > of position will obviously not hold for ever in front of IESG, IAB, G= AC, > > WTO, but if can confuse people enough to hold for years. This is why = I am > > spending so much time explaining the obvious again and again. To give > > "lawyers" quotes enough to discuss the bad or the good faith of the > > authors. > > > > ABNF is not the point. You may note that only you and Lee, who are > > motivated in finding a technical solution, in an IETF fashion, are > > seriously following this technical thread. The point is political and > > commercial. > > > > Why? And is it bad or not? > > > > > > Just try to figure out who are the customers here. Who has money in > > language related industries? Who print, sell and buy books? Typograph= ers, > > Publishers and Libraries. What is their common target? To sell/rent b= ooks > > to readers. Who are the readers? More and more Internet users. The > > customers of the book industries evade books. Two things to do: cheap= er > > books and to move the book industry into the internet (and in so doin= g try > > to protect the existing market repartition and to invade the share of= the > > slow movers) with the minimum of compromise with the natives (Yahoo!, > > Google, etc.) > > > > Study http://www.unicode.org/history/boardmembers.html and > > http://www.unicode.org/consortium/directors.html. Unicode is certainl= y the > > most active and talented (*) place where this concerns can be discuss= ed > > and > > acted upon. It certainly gathers representatives from the market and > > customer leaders. It is likely that its propositions carry enormous w= eight, > > but also call for serious political attention. This attention is from= the > > competition and the partners of its Directors and Executives corporat= ions, > > from cultural authorities. It is from Governments, due to this weight= and > > the possible direct or indirect impact on the most sensitive human ar= eas: > > culture, civilisation memory, political influence, religion, human > > relations, etc. You may have noted the force and the speed of the Eur= opean > > reactions to the Google digital library announcement. > > > > (*) Some individual members are: Harald Alvestrand, John Cowan, Marti= n > > D=FCrst, Doug Ewell, Jean-Fran=E7ois Morfin; some corporate Members (= whose > > employees also form the broad majority of the consortium directors an= d > > executives) are: RLG (whose BoD Member is the only one to stay from t= he > > very beginning), Microsoft, IBM, Apple, Cisco. Verisign just joined a= s a > > Member. > > > > What is the target of the people gathered in Unicode? "The Unicode > > Consortium is a non-profit organisation founded to develop, extend an= d > > promote use of the Unicode Standard, which specifies the representati= on of > > text in modern software products and standards." Unicode is therefore= an > > active participant to the W3C (web standards) and to ISO (internation= al > > standards). > > > > > > Now, read http://ietf.org/overview.html. It starts saying "The Intern= et > > Engineering Task Force (IETF) is a large open international community= of > > network designers, operators, vendors, and researchers concerned with= the > > evolution of the Internet architecture and the smooth operation of th= e > > Internet." > > > > The first problem is here. Unicode (Mark Davis' culture) is about > > characters in texts and W3C (Addison Philips' cultures) is about Web > > i.e. modern software to print/display/speak texts. But IETF is about > > Internet architecture and the Draft does not bridge the huge gap betw= een > > one of the network application, however big it is and however histori= cally > > rooted it is, and the network architecture. The only way they have to= keep > > them together is to "constrain" the network into their typographer/pr= inter > > culture. This obviously cannot work. Typographer, printer and booksto= res > > chains are different trades. > > > > > > The second problem is that the customers needs are outdated and the b= ook > > industry does not know how to match our time's challenge. People like > > Peter > > Constable and me certainly try to help in our own ways - him as an > > employee, me as an applied searcher. This is the very same problem as > > Telcos and music publishers. Book publishers and Libraries have been > > impacted more slowly and for a longer time than Music publishers and = Media, > > but the problem is similar. Music publishers introduced RPM, iPod, et= c. > > Book Publishers and Libraries introduce RFIDs and langtags. > > > > Is that a bad idea? No. > > > > It even looks very promising both for Libraries and Publishers, and f= or > > software and service providers. A unique basis to build good organisa= tion > > and market protection control. Every text can be tagged with a langta= g; we > > will find them everywhere (RFID on the books in bookstores, Libraries= , > > Colleges, etc. Operating System locales - Windows and Linux alike) wi= th an > > easy to add ISSN when printed. The catalogues, management, organisati= on > > savings can be huge for publishers, libraries etc. This is very urgen= t > > while the printer increasingly challenges the book. The need is to le= vel > > the practical cost of satisfaction of a book and of a printout; and t= o get > > the copyrights paid in both cases. Same problem as Sony and Napster. = The > > solution is like iPod: the library of Congress on an USB iLib, which = can > > plug on any bookprinter to come, and stay compatible whatever the ver= sion > > of text over the centuries. > > > > At the same time, the langtags makes it easier to rush down the web, > > reading every web page, sorting them by langtags, reading them for > > incorrect words, copyright infringement, etc. and printing the daily > > police/lawyer report for copyright actions. > > > > I obviously only give rough lines and do not go into the details of t= he > > way > > it helps reducing costs, improving quality, increasing security etc. > > through system convergence, simplification, etc. > > > > > > So, you understand why this Jefsey is a very bad/poor stupid troll, m= aking > > "industry" to waste huge amounts of money with his "delaying practice= s". > > > > You also understand that if his "0-" were to be accepted the whole sc= heme > > would be useless. The whole thing is format exclusiveness, so _every_= book > > and page in the world can fit in a unique industry controlled format. > > > > Every other attempt MUST be excluded. And here is the huge "but". Bec= ause > > it scale and stay. > > > > The supposed retrocompatibility obligation with a never used format i= s > > only > > a bluff. This is probably one of the reasons why the WG-ltru never wa= nted > > to consider its Charter. The Charter says something quite different: = "It > > is > > expected to specify a mechanism for easily identifying the role of ea= ch > > subtag in the language tag, so that, for example, whenever a script c= ode > > or > > country code is present in the tag it can be extracted, even without > > access > > to a current version of the registry. Such a mechanism would clearly > > distinguish between well-formed and valid language tags, to allow for > > maximal compatibility between implementations released at different t= imes, > > and thus using different versions of the registry." > > > > Jefsey is also quite worrying. Because he works on the matter for 30 = years > > (among other things, I came to networking in 1976 in discussing with = Xerox, > > Compugraphic, etc. about an international network to print books. I > > studied > > in 1979 with all the large newspapers not printing photos - Le Monde,= la > > Stampa, Die Welt, etc. - simultaneous locale editions over the > > international public network. I managed my own daily economical newsf= axer > > during five years, with editions on Minitel, professional papers, etc= .). > > He > > knows networks (I am first a Navy communication officer dealing with > > secure > > world networks since 1971). He possibly has the technical user-centri= c > > architecture to change all that (I do). He knows the future; and the > > future > > he knows is probably quite different from the past the industry wants= to > > protect (it extends it, it does not kill it). No way to permit his id= eas > > and demands through. He must be excluded. Whatever the way (including > > anonymous telephone threads, what next?). > > > > Another problem with Jefsey: he is no English mother-tongue. So he kn= ows > > more and he is engaged into structures, solutions, propositions that = do > > not > > want to use English as the language of reference. This is quite worry= ing > > for several reasons. > > > > - One reason is that industry is mainly US driven and has no collecti= ve > > knowledge, experience and practice of languages at this level. > > Multilingualism is a difficult and complex area. Stakeholders prefer = to > > address it as an internationalisation+localisation > > http://www.w3.org/TR/2005/WD-itsreq-20050805 which permits them (the= y > > think, but this is one of the main technical error by lack of complet= e > > analysis and modelisation) to simplify the issue and to control it fr= om > > the > > computer root (via CLDR: the control of locale files). > > > > - Another reason is that the industry is also conducted by market lea= ders > > which happen to be Americans and therefore to benefit from the Americ= an > > commercial environment, and which are under European scrutiny for pos= sible > > market dominant position. > > > > - Multilingualism is also a threat of balkanisation of the network wh= ich > > would kill the acquired vision of the network and would remove the pa= rtial > > protection provided by "an American built Internet" Hollywood story > > (Jefsey > > knows the truth: danger). You can sue a Chinese in the US for having > > violated a copyright on the Internet. This is more difficult if the > > violation was on the "Chinese Internet", with Chinese domain names. T= he > > law > > will be the same, the eventual decision will be the same, but the cos= t > > balance will switch: it will be cheaper to the Chinese user, and mor= e > > expansive to the multinational stakeholder. > > > > Another problem with Jefsey is that he only considers the "Web" as on= e > > application on the network and not as the main system. The langtags M= UST > > be > > the internal core of the Internet system to be on every text. Or the > > scheme > > will never be powerfull enough to work. > > > > There are obviously many other problems with Jefsey. I just wanted to > > quote > > some. A last worrying one: he is impressed by technical pertinence an= d > > vision, not by corporate positions. > > > > > > Now, I explained the why, may be interesting to discuss the bad/good = issue. > > > > As often in period of dramatic industrial changes, industries fight f= or > > survival in making incorrect short-sighted choices based upon immedia= te > > self-protection (innovative quick consensus is quite unusual). The wa= y to > > best help them is to accompany their change, in first trying to under= stand > > its reasons. Often, as in this case, the change proceed in several ph= ases > > due to the hysteresis of the interaction with technology and users: t= iming > > is important. In fighting my graduated propositions to carefully move= from > > one step to an other, the Draft affinity group actually represents a = huge > > danger for the industry it wants to protect. They waste time and mode= rn > > solutions in fighting the last war. One can easily see that by the la= ck of > > definition of the terms they use: it would show they confuse the cont= exts. > > As a consequence their resulting proposition will not be acceptable = to > > their competition, to their market partners, to governments etc. and = is of > > no real interest to their "end-users" (an old notion they have not ye= t > > departed from). > > > > It is not far. But it is not acceptable. A simple explanation is that= they > > start from where they come from (typographers) instead of considering > > where > > they want to arrive (distributed networks). Also, that they have a wr= ong > > economical model. Their model is to reduce costs through simplificati= on, > > what means rigidity. This could work if the market was dwindling. But= the > > market is exploding. But not exploding in the way they see it > > (publishing/rending stocked books), but in the way the users see it > > (multimedia access to knowledge). Scalability and simplicity are conf= used > > with limitation: they do not mean less options; they mean an infinite > > number of easy to get options and only a few built-in defaults. > > > > I must say they are not helped by the current status of the world thi= nking. > > The WSIS is a major misconception for them. "Information" is currentl= y > > understood as a mix between technical data and French 1960 "informati= que". > > The WSIS was initially a first attempt by librarians to address their > > problem. It went out of their control. For the same reason why langta= gs > > are > > to escape them. The problem is new, complex and a past protection app= roach > > can only be increasingly inadequate. What they need is a solid, open, > > stable, innovative and secure generalised network framework, where th= ey > > can > > lodge their own solutions. Unfortunately the Internet does not fully > > deliver it, yet. This is why before addressing the book industry need= s the > > International Network system must first become a Multilingual Global = NGN. > > The advantage of Majors over Unicode is that Music is a unique univer= sal > > languages. But pictures are multilingual - with a larger possible > > diversity > > of languages than texts. MPEG should be included in the analysis. > > > > > > The solution IMHO is to proceed step by step. Considering immediate > > interests, ending with exclusion but carefully discussing timing, > > experimentation and deployment areas. Until one can agree on a future > > economical model. We can discuss that too. > > > > It will necessarily include the convergence of various forms of > > data-providers (search engines, domain names, libraries, mail, etc.),= of > > content structures (architexts, multimedia, services), storing > > (memorisation technologies are a key issue), o payment means (probabl= y a > > secure micro payment support). etc. Then the common standard MUST add= ress > > the need of EVERYONE. Because it is legal, the IETF objective, but mo= st of > > all because it is business efficient in a network. > > > > And, what if Jefsey finds a trick to proceed otherwise? > > Take care. > > jfc > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 09 19:46:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2dnw-0000kS-Dv; Tue, 09 Aug 2005 19:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2dnu-0000kN-Un for ltru@megatron.ietf.org; Tue, 09 Aug 2005 19:46:43 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24175 for ; Tue, 9 Aug 2005 19:46:36 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E2dnC-0007XM-AY for ltru@lists.ietf.org; Wed, 10 Aug 2005 01:45:58 +0200 Received: from c-134-88-96.hh.dial.de.ignite.net ([62.134.88.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Aug 2005 01:45:58 +0200 Received: from nobody by c-134-88-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Aug 2005 01:45:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 10 Aug 2005 01:38:31 +0200 Organization: Lines: 102 Message-ID: <42F93E77.1489@xyzzy.claranet.de> References: <001401c59c99$86292560$030aa8c0@DEWELL> <42F846F5.7121@xyzzy.claranet.de> <6.2.1.2.2.20050809104838.04ae66a0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-96.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA24175 Cc: Subject: [Ltru] Re: singleton DIGIT X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org r&d afrac wrote: > RFC 3066 permitted digits in subtags. We're talking about singletons, RfC 3066 says: [primary subtag] | The value "i" is reserved for IANA-defined registrations | The value "x" is reserved for private use. Subtags of "x" | shall not be registered by the IANA. | Other values shall not be assigned except by revision of | this standard. Either "i-" or "x-" or more letters, no single DIGIT. [secondary subtag] | Tags with 1-letter second subtags may not be assigned | except after revision of this standard. No single letter or DIGIT. The first position where a single letter or DIGIT was allowed was the third subtag. I recall it now, we discused it here, that's why the single DIGIT was added for future extension subtags. And because 3066bis is a revision of "this standard" - wow, a sure kill for any 3066 last call - we're free to allow it also in the second position. But not in the first, exactly as the 3066bis ABNF does, it's correct. Addison could s/letter/letter or digit/ exactly where Doug found it in the prose. > What Doug says is "I cannot support it in the document I > write since I did not write that I would". After five months you're supposed to know who writes which document. Addison or Mark fixed the missing DIGIT, not Doug. > This kind of position will obviously not hold for ever in > front of IESG, IAB, GAC, WTO It might also cause serious problems with the KERC (Klingon Equal Rights Commission), they'll insist on a singleton =80 ;-) > This is why I am spending so much time explaining the > obvious again and again. To give "lawyers" quotes enough > to discuss the bad or the good faith of the authors. There's nothing wrong with the authors, aim higher. > ABNF is not the point. IBTD. Sometimes I can see the ideas behind the ABNF, where the prose is only MUSTardized irrelevant whishful thinking (that remark wasn't about the drafts here). > The point is political and commercial. It's technically sound and causes no harm, unlike this beast: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dprint_ballot= &ballot_id=3D1573&filename=3Ddraft-lyon-senderid-core > Study http://www.unicode.org/history/boardmembers.html and > http://www.unicode.org/consortium/directors.html Thanks, I didn't know these links. I sometiems check corporate members for DoubleClick or SpamCast (guess why). Unicode is a white hat, see http://www.unicode.org/consortium/memblist.html > So, you understand why this Jefsey is a very bad/poor stupid > troll, making "industry" to waste huge amounts of money with > his "delaying practices". I'm not worried about your activities, but I do get angry if you insult or even harrass others as you tried it with John. Each WG needs its resident kook, it helps to focus - without you we could be tempted to get arried away inventing wild and wonderful things that nobody wants or needs. Disclaimer: It was less useful when you wasted Martin's or Randy's time, they're not free to click NEXT whenever they feel like it. Your articles tend to be too long (nothing personal, I have the same problem, but it's bad, after 50 lines readers give up and click NEXT). > The whole thing is format exclusiveness, so _every_ book > and page in the world can fit in a unique industry controlled > format. While we're "not" discussing personal problems, if somebody is apparently more paranoid than I am I think it's a bit too much. > The supposed retrocompatibility obligation with a never used > format is only a bluff. IBTD. Ira, Ned, and I insisted on the "Suppress-Script" for maximal backwards compatibility, _not_ Addison or Mark, they hated it. And JFTR, nobody paid me for my opinions here. It is just what I think how this stuff could work in all contexts I'm somewhat familiar with. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 01:07:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Rl7-0003A1-CJ; Fri, 12 Aug 2005 01:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Rl3-00039r-SX for ltru@megatron.ietf.org; Fri, 12 Aug 2005 01:07:07 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19054 for ; Fri, 12 Aug 2005 01:07:04 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050812050634.KHCO24042.mta11.adelphia.net@DEWELL> for ; Fri, 12 Aug 2005 01:06:34 -0400 Message-ID: <001f01c59efb$96a1e760$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 11 Aug 2005 22:06:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Test X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Please ignore this test message. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 18:58:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3iU1-0008CT-2M; Fri, 12 Aug 2005 18:58:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3iTz-0008CO-RO for ltru@megatron.ietf.org; Fri, 12 Aug 2005 18:58:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09371 for ; Fri, 12 Aug 2005 18:58:29 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3j2Y-000536-A3 for ltru@ietf.org; Fri, 12 Aug 2005 19:34:19 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 15:58:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Aug 2005 15:58:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B547@irvmbxw01.quest.com> Thread-Topic: new editor's copy online Thread-Index: AcWfkU6PVZHyb2C4SIiEWzOGdFAqiQ== From: "Addison Phillips" To: X-OriginalArrivalTime: 12 Aug 2005 22:58:18.0138 (UTC) FILETIME=[542F2FA0:01C59F91] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] new editor's copy online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1596241994==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1596241994== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYXZlIHByZXBwZWQgYSBuZXcgZWRpdG9yJ3MgY29weSAoZHJhZnQtMTEpIG9mIHRoZSBkcmFm dC1yZWdpc3RyeSBkb2N1bWVudCwgaW4gYW50aWNpcGF0aW9uIG9mIExhc3QgQ2FsbCBjbG9zaW5n Lg0KDQpJbiB0aGlzIGRyYWZ0IGFyZSB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQoNCjEuIENoYW5n ZXMgaW5zdGFuY2VzIG9mICJzaW5nbGUtbGV0dGVyIiB0byAic2luZ2xlIGNoYXJhY3RlciIgb3Ig InNpbmdsZXRvbiIgYXMgYXBwcm9wcmlhdGUgdG8gc3VwcG9ydCB0aGUgQUJORiAoYW5kIG90aGVy KSBkZXNjcmlwdGlvbnMgb2YgZXh0ZW5zaW9uIGlkZW50aWZpZXJzLg0KDQoyLiBDaGFuZ2VkICJT dGF0aXN0aWNhbCBEaXZpc2lvbiIgdG8gIlN0YXRpc3RpY3MgRGl2aXNpb24iDQoNCjMuIFJlbW92 ZWQgdGhlIGFkZGl0aW9uYWwganVuayBmcm9tIHRoZSBuYW1lIG9mIElTTyAxMDY0NjoyMDA0Lg0K DQogICBhLiBSZW1vdmVkIGF1dGhvciAiSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0 YW5kYXJkaXphdGlvbiIgZnJvbSBhbGwgSVNPIHZhbHVlcy4NCg0KVGhlIHJlc3VsdHMgYW5kIGEg ZGlmZiBmcm9tIGRyYWZ0LTEwIGFyZSBhdDoNCg0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29t L0lEL2RyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0xMS50eHQNCmh0dHA6Ly93d3cuaW50ZXItbG9j YWxlLmNvbS9JRC9kcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTEuaHRtbA0KaHR0cDovL3d3dy5p bnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LXJlZ2lzdHJ5LTEwLTExLWRpZmYuaHRtbA0KDQpBZGRp c29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVz dCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlv bmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0 aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFu IGFyY2hpdGVjdHVyZS4gDQoNCg0K --===============1596241994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1596241994==-- From ltru-bounces@lists.ietf.org Fri Aug 12 19:09:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ien-0002UW-VS; Fri, 12 Aug 2005 19:09:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3iem-0002UO-NT for ltru@megatron.ietf.org; Fri, 12 Aug 2005 19:09:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09821 for ; Fri, 12 Aug 2005 19:09:35 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3jDF-0005Io-Ly for ltru@ietf.org; Fri, 12 Aug 2005 19:45:25 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3ieR-000082-00 for ltru@ietf.org; Fri, 12 Aug 2005 19:09:24 -0400 Message-ID: <003801c59f93$0f2acfc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlink.net> <61590.83.248.26.202.1123243586.squirrel@webmail.chalmers.se> Date: Fri, 12 Aug 2005 16:10:40 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] [psg.com #1096] "nb" versus "no" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Kent Karlsson" > To: "Randy Presuhn" > Cc: > Sent: Friday, August 05, 2005 5:06 AM > Subject: Re: [Ltru] Second WG last call on draft-ietf-ltru-initial-03.txt ends 2005-08-08 ... > 1. 'no' should be deprecated in favor of 'nb'. That is, > one should assume 'nb' if 'no' is used. > > 'no' is is (now) in theory a language group code, but all > languages in that group have individual codes (nb and nn); > not counting dialects. But effectively, in practice, 'nb' > *replaces* 'no' ('nn' is much rarer than 'nb'). > > But I guess this can be dealt with later on (I hope I did not > miss any provision preventing such a fix). ... Based on the even split of the discussion, let's not make any changes here, and leave the issue to the ietf-languages@iana.org list. I've created a ticket (issue number #1096) with a status of "rejected" for this item. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 19:38:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3j6T-0000v7-PB; Fri, 12 Aug 2005 19:38:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3j6S-0000uz-Lb for ltru@megatron.ietf.org; Fri, 12 Aug 2005 19:38:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10663 for ; Fri, 12 Aug 2005 19:38:16 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3jf1-0005sj-EN for ltru@ietf.org; Fri, 12 Aug 2005 20:14:06 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3j6N-0000gx-00 for ltru@ietf.org; Fri, 12 Aug 2005 19:38:15 -0400 Message-ID: <006801c59f97$167b8900$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C72B547@irvmbxw01.quest.com> Date: Fri, 12 Aug 2005 16:39:30 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] [psg.com #1095] reference section cleanup X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: > Sent: Friday, August 12, 2005 3:58 PM > Subject: [Ltru] new editor's copy online ... > a. Removed author "International Organization for Standardization" from all ISO values. ... I am surprised by this change. I don't believe there was anything like a consensus to make it. It's a departure from the style of http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt, and I would not be surprised if the RFC editor restores the "author" fields. Though I'm content to consider layout a matter of editorial discretion, I think abusing the xml2rfc fields (putting the standard number into the author field) is just asking for trouble. I *thought* you had agreed to use the reference.ISO files (where possible). Did I miss something? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 19:45:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jDd-0002pU-Fw; Fri, 12 Aug 2005 19:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jDc-0002pO-1j for ltru@megatron.ietf.org; Fri, 12 Aug 2005 19:45:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10973 for ; Fri, 12 Aug 2005 19:45:39 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3jmD-00064a-T8 for ltru@ietf.org; Fri, 12 Aug 2005 20:21:30 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3jDZ-0002it-00 for ltru@ietf.org; Fri, 12 Aug 2005 19:45:42 -0400 Message-ID: <007501c59f98$21ec3220$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> <60591.83.248.26.202.1122996239.squirrel@webmail.chalmers.se> Date: Fri, 12 Aug 2005 16:46:33 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [Ltru] [psg.com #1097] ABNF cleanup in matching draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've added this as issue #1097 to the issue tracker at https://rt.psg.com/ (user and password "ietf") Randy, ltru co-chair ----- Original Message ----- From: "Kent Karlsson" To: "Addison Phillips" Cc: "LTRU Working Group" Sent: Tuesday, August 02, 2005 8:23 AM Subject: Re: [Ltru] ABNF beautification... ... I guess that means that the -matching ABNF should look like (I don't see how it is sensible to just delete the "extension" part): Language-Tag = langtag / privateuse ; private use tag / grandfathered ; grandfathered registrations langtag = (language ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse]) language = (2*3ALPHA extlang) ; shortest ISO 639 code / 4ALPHA ; reserved for future use / 5*8ALPHA ; registered language subtag / "*" extlang = *3("-" 3ALPHA) ; reserved for future use / *2("-" 3ALPHA) "-*" script = 4ALPHA ; ISO 15924 code / "*" region = 2ALPHA ; ISO 3166 code / 3DIGIT ; UN M.49 code / "*" variant = 5*8alphanum ; registered variants / (DIGIT 3alphanum) / "*" extension = singleton 1*("-" (2*8alphanum)) / "*" singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" ; Single letters: x/X is reserved for private use privateuse = ("x"/"X") 1*("-" (1*8alphanum)) grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered registration ; Note: i is the only singleton ; that starts a grandfathered tag alphanum = (ALPHA / DIGIT) ; letters and numbers Figure 3: Language Tag Pattern ABNF _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 20:06:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jXS-0007jR-98; Fri, 12 Aug 2005 20:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jXR-0007jM-MA for ltru@megatron.ietf.org; Fri, 12 Aug 2005 20:06:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11825 for ; Fri, 12 Aug 2005 20:06:11 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3k62-0006Yf-VF for ltru@ietf.org; Fri, 12 Aug 2005 20:42:00 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3jXL-0001A3-00 for ltru@ietf.org; Fri, 12 Aug 2005 20:06:07 -0400 Message-ID: <000601c59f9a$fc252580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 12 Aug 2005 17:07:24 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] [psg.com #1094] WGLC add internationalization considerations section X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - catching up on email and data entry... > ------------------------------------------------------------------------- > Message > http://www1.ietf.org/mail-archive/web/ltru/current/msg03152.html > suggests that an internationalization considerations section is needed. > > Follow-up, in the thread beginning with message > http://www1.ietf.org/mail-archive/web/ltru/current/msg03155.html > found no support and much opposition, so this item is marked > "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 20:06:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jY7-0007mR-Fh; Fri, 12 Aug 2005 20:06:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jY6-0007mJ-2L for ltru@megatron.ietf.org; Fri, 12 Aug 2005 20:06:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11833 for ; Fri, 12 Aug 2005 20:06:49 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3k6g-0006Z6-9f for ltru@ietf.org; Fri, 12 Aug 2005 20:42:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 17:06:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1095] reference section cleanup Date: Fri, 12 Aug 2005 17:06:35 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B57C@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1095] reference section cleanup Thread-Index: AcWflySrqFFHnUjXTrWoJhorGnnLuAAAEg7g From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 13 Aug 2005 00:06:36.0133 (UTC) FILETIME=[DEC79950:01C59F9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I can't use the reference.ISO files directly: they don't reference the = right things. I can ape their style (I did so in draft-10). Kent's comments seemed reasonable and I found a way to make the XML work = that is consistent with many extant RFCs. Having six references in a row = with the same superfluous author seems odd, but I suppose I could resort = to making the author Mr. Ibid :-)... I can put it back too. Note that I did NOT put the standard into the author or organization = element or abuse the XML. (FWIW I had to revise the CSS that a certain co-chair and I both use in = XMetal--it hid the organization element). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?12? 16:40 > To: ltru@ietf.org > Subject: [Ltru] [psg.com #1095] reference section cleanup >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: > > Sent: Friday, August 12, 2005 3:58 PM > > Subject: [Ltru] new editor's copy online > ... > > a. Removed author "International Organization for = Standardization" > from all ISO values. > ... >=20 > I am surprised by this change. I don't believe there was anything = like > a consensus to make it. It's a departure from the style of > = http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt, > and > I would not be surprised if the RFC editor restores the "author" = fields. > Though I'm content to consider layout a matter of editorial = discretion, > I think abusing the xml2rfc fields (putting the standard number into = the > author field) is just asking for trouble. I *thought* you had agreed > to use the reference.ISO files (where possible). Did I miss = something? >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 20:17:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jip-0002JY-Mo; Fri, 12 Aug 2005 20:17:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jio-0002JT-H3 for ltru@megatron.ietf.org; Fri, 12 Aug 2005 20:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12093 for ; Fri, 12 Aug 2005 20:17:56 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3kHP-0006mC-Pv for ltru@ietf.org; Fri, 12 Aug 2005 20:53:45 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 17:17:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1097] ABNF cleanup in matching draft Date: Fri, 12 Aug 2005 17:17:47 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B583@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1097] ABNF cleanup in matching draft Thread-Index: AcWfmD4U6bd1RJQlQH6GU9vCy1l/3gAA5QJg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 13 Aug 2005 00:17:47.0903 (UTC) FILETIME=[6F2F90F0:01C59F9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Extension matching is a separate issue and may have arcane rules. = Draft-registry and draft-matching both say that. We can, of course, = including singletons into the ABNF, if anyone feels strongly about it. Modifying the matching ABNF requires adding wildcards in just the right = way. Here is what I have so far: extended-language-range =3D range ; a range / privateuse ; private use tag / grandfathered ; grandfathered registrations range =3D (language ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse]) language =3D "*" ; wildcard or... / (2*3ALPHA [ extlang ]) ; shortest ISO 639 code / 4ALPHA ; reserved for future use / 5*8ALPHA ; registered language subtag extlang =3D *2("-" 3ALPHA) ("-" ( 3ALPHA / "*")) ; reserved for future use ; wildcard can only appear ; at the end script =3D "*" ; wildcard or... / 4ALPHA ; ISO 15924 code region =3D "*" ; wildcard or... / 2ALPHA ; ISO 3166 code / 3DIGIT ; UN M.49 code variant =3D "*" ; wildcard or... / 5*8alphanum ; registered variants / (DIGIT 3alphanum) privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered registration ; Note: i is the only singleton ; that starts a grandfathered tag alphanum =3D (ALPHA / DIGIT) ; letters and numbers Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?12? 16:47 > To: LTRU Working Group > Subject: [Ltru] [psg.com #1097] ABNF cleanup in matching draft >=20 > Hi - >=20 > I've added this as issue #1097 to the issue tracker at > https://rt.psg.com/ (user and password "ietf") >=20 > Randy, ltru co-chair >=20 > ----- Original Message ----- > From: "Kent Karlsson" > To: "Addison Phillips" > Cc: "LTRU Working Group" > Sent: Tuesday, August 02, 2005 8:23 AM > Subject: Re: [Ltru] ABNF beautification... > ... >=20 > I guess that means that the -matching ABNF should look like > (I don't see how it is sensible to just delete the "extension" part): >=20 > Language-Tag =3D langtag > / privateuse ; private use tag > / grandfathered ; grandfathered registrations >=20 > langtag =3D (language > ["-" script] > ["-" region] > *("-" variant) > *("-" extension) > ["-" privateuse]) >=20 > language =3D (2*3ALPHA extlang) ; shortest ISO 639 code > / 4ALPHA ; reserved for future use > / 5*8ALPHA ; registered language subtag > / "*" >=20 > extlang =3D *3("-" 3ALPHA) ; reserved for future use > / *2("-" 3ALPHA) "-*" >=20 > script =3D 4ALPHA ; ISO 15924 code > / "*" >=20 > region =3D 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN M.49 code > / "*" >=20 > variant =3D 5*8alphanum ; registered variants > / (DIGIT 3alphanum) > / "*" >=20 > extension =3D singleton 1*("-" (2*8alphanum)) > / "*" >=20 > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > ; Single letters: x/X is reserved for private use >=20 > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) >=20 > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > ; grandfathered registration > ; Note: i is the only singleton > ; that starts a grandfathered tag >=20 > alphanum =3D (ALPHA / DIGIT) ; letters and numbers >=20 > Figure 3: Language Tag Pattern ABNF >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 20:26:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jqd-0004Ka-Fs; Fri, 12 Aug 2005 20:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jqb-0004Hc-Qv for ltru@megatron.ietf.org; Fri, 12 Aug 2005 20:26:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12313 for ; Fri, 12 Aug 2005 20:25:59 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3kPD-0006vP-02 for ltru@ietf.org; Fri, 12 Aug 2005 21:01:48 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3jqY-0000Es-00 for ltru@ietf.org; Fri, 12 Aug 2005 20:25:58 -0400 Message-ID: <000d01c59f9d$c2127ac0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Date: Fri, 12 Aug 2005 17:27:11 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [Ltru] [psg.com #1027] ISO 11173 (non) alignment in main draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've seen no support for Jefsey's latest proposal, so this issue remains closed with a "rejected" status. Randy, ltru co-chair ----- Original Message ----- From: "Peter Constable" To: Sent: Friday, August 05, 2005 7:41 AM Subject: RE: [Ltru] ISO 11173 (non) alignment in main draft > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of r&d afrac > Proposed choice (or anyone can better the texts if respecting their > intent). The target is clarity. > > (a) "Even if the registry documented in this memo relates in part to ISO > codes it is not aligned on ISO 11173 provisions." > > (b) "The registry documented in this memo relates in part to ISO codes and > SHOULD respect their alignment on ISO 11173 provisions as they develop." I strongly object to both wordings. Apart from the typo (referring to a standard on plastics), "aligned on ISO 11179 provisions" is thoroughly ambiguous, and nothing of particular use is contributed. Indeed, I find both to introduce problems: - The first wording contributes nothing other than to inform users of how this registry relates to ISO 11179, which assessment should not be stated unless this or a subsequent WG reviews a written analysis of the same. - The second wording imposes a requirement on IANA with no guidance whatsoever on how it should be fulfilled; moreover, it imposes a vaguely-stated requirement that could permit future interpretation requiring changes in the specification in which it would be contained in ways that are completely unforeseen. We have been over the role of ISO 11179 in relation to this draft before and concluded that no reference to it was required. I would like to see this matter put to rest. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 20:32:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jwe-0005rL-Pe; Fri, 12 Aug 2005 20:32:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jwd-0005rG-Eo for ltru@megatron.ietf.org; Fri, 12 Aug 2005 20:32:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12535 for ; Fri, 12 Aug 2005 20:32:12 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3kVF-00074f-Ez for ltru@ietf.org; Fri, 12 Aug 2005 21:08:01 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3jwb-0002Jn-00 for ltru@ietf.org; Fri, 12 Aug 2005 20:32:13 -0400 Message-ID: <001801c59f9e$a065c340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C72B57C@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #1095] reference section cleanup Date: Fri, 12 Aug 2005 17:33:28 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; > Sent: Friday, August 12, 2005 5:06 PM > Subject: RE: [Ltru] [psg.com #1095] reference section cleanup .. > Kent's comments seemed reasonable and I found a way to make the XML > work that is consistent with many extant RFCs. Having six references in a > row with the same superfluous author seems odd, but I suppose I could > resort to making the author Mr. Ibid :-)... I can put it back too. Please, no Ibid. > Note that I did NOT put the standard into the author or organization element or abuse the XML. Strange, when I look at http://www.inter-locale.com/ID/draft-ietf-ltru-registry-11.xml I see: ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts That's a rather odd fullname for an author to have. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 12 20:43:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3k7e-000053-6L; Fri, 12 Aug 2005 20:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3k7c-00004x-US for ltru@megatron.ietf.org; Fri, 12 Aug 2005 20:43:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12930 for ; Fri, 12 Aug 2005 20:43:32 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3kgC-0007Kd-HC for ltru@ietf.org; Fri, 12 Aug 2005 21:19:21 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 17:43:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1095] reference section cleanup Date: Fri, 12 Aug 2005 17:43:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B58B@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1095] reference section cleanup Thread-Index: AcWfnpbmgq9RyeFiRUGBEzaPdwhC1wAAKejQ From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 13 Aug 2005 00:43:18.0147 (UTC) FILETIME=[FF484530:01C59F9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > > > ISO 15924:2004. Information and > documentation -- Codes for the representation of names of > scripts > > >=20 > > > >=20 > That's a rather odd fullname for an author to have. Hm... I don't recall putting those in. Must have pasted them from = somewhere. I'll remove that for sure. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?12? 17:33 > To: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #1095] reference section cleanup >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Randy Presuhn" ; > > Sent: Friday, August 12, 2005 5:06 PM > > Subject: RE: [Ltru] [psg.com #1095] reference section cleanup > .. > > Kent's comments seemed reasonable and I found a way to make the XML > > work that is consistent with many extant RFCs. Having six references = in > a > > row with the same superfluous author seems odd, but I suppose I = could > > resort to making the author Mr. Ibid :-)... I can put it back too. >=20 > Please, no Ibid. >=20 > > Note that I did NOT put the standard into the author or organization > element or abuse the XML. >=20 > Strange, when I look at > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-11.xml > I see: >=20 > > > ISO 15924:2004. Information and > documentation -- Codes for the representation of names of > scripts > > >=20 > > > >=20 > That's a rather odd fullname for an author to have. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 01:26:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3oX8-0003P1-QG; Sat, 13 Aug 2005 01:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3oX7-0003Oe-8T for ltru@megatron.ietf.org; Sat, 13 Aug 2005 01:26:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21581 for ; Sat, 13 Aug 2005 01:26:12 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3p5k-0004ke-B9 for ltru@ietf.org; Sat, 13 Aug 2005 02:02:02 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3oWx-0000n8-00 for ltru@ietf.org; Sat, 13 Aug 2005 01:26:03 -0400 Message-ID: <007001c59fc7$a7738040$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 12 Aug 2005 22:27:09 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] [psg.com #1098] WGLC distinguish subtag and extensions registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > ------------------------------------------------------------------------- > Issue raised in messages > http://www1.ietf.org/mail-archive/web/ltru/current/msg03195.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg03202.html So far, two (Doug and Kent) have spoken in favor of making the distinction clearer. Is any more discussion needed before directing the editors to make appropriate changes in the registry i-d? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 01:28:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3oYy-0003eD-CK; Sat, 13 Aug 2005 01:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3oYs-0003do-Vc for ltru@megatron.ietf.org; Sat, 13 Aug 2005 01:28:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21632 for ; Sat, 13 Aug 2005 01:28:02 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3p7Y-0004nP-A4 for ltru@ietf.org; Sat, 13 Aug 2005 02:03:52 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3oYs-0001Dk-00 for ltru@ietf.org; Sat, 13 Aug 2005 01:28:02 -0400 Message-ID: <007501c59fc7$effef920$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 12 Aug 2005 22:29:11 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] [psg.com #1099] WGLC add empty extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > ------------------------------------------------------------------------- > Issue raised in messages > http://www1.ietf.org/mail-archive/web/ltru/current/msg03195.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg03202.html > Kent and Doug have commented on the omission of the initial (empty) extension registry. Doug has made a proposal for its content. Are there any objections to adding this material to the initial registry i-d? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 01:48:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3osD-0000RS-UP; Sat, 13 Aug 2005 01:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3osB-0000RH-SK for ltru@megatron.ietf.org; Sat, 13 Aug 2005 01:48:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22174 for ; Sat, 13 Aug 2005 01:47:56 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3pQo-0005CA-Qc for ltru@ietf.org; Sat, 13 Aug 2005 02:23:47 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3os7-0005FR-00 for ltru@ietf.org; Sat, 13 Aug 2005 01:47:55 -0400 Message-ID: <008101c59fca$b6729560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 12 Aug 2005 22:49:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Wrapping up the second WG last calls on the registry and initial registry drafts X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I've finally managed to get through all the mail from the ltru WG mailing list, and have added the new issues to the issue tracker at https://rt.psg.com/ (user and password "ietf"). Please review the lists to make sure I didn't miss anything that you believe is important enough to merit giving an issue number. At this time, there are two open issues we need to close before closing the WG last call on these documents: #1098 (on the registry i-d), and #1099 (on the initial registry i-d). I would hope that we can polish these off very quickly (in a day or so); I think we're past the point of diminishing returns. When we've reached a rough consensus on what to do about these two, we'll instruct the editors to issue updated drafts. Then Martin and I will start the process of shepherding these through the IESG, using the http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt procedures as directed by our AD. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 01:51:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ova-0001Lv-SV; Sat, 13 Aug 2005 01:51:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ovZ-0001Lj-7d for ltru@megatron.ietf.org; Sat, 13 Aug 2005 01:51:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22259 for ; Sat, 13 Aug 2005 01:51:24 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3pUA-0005G3-Hl for ltru@ietf.org; Sat, 13 Aug 2005 02:27:14 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3ovT-0005vO-00 for ltru@ietf.org; Sat, 13 Aug 2005 01:51:24 -0400 Message-ID: <008601c59fcb$333647e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <007001c59fc7$a7738040$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1098] WGLC distinguish subtag and extensionsregistries Date: Fri, 12 Aug 2005 22:52:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Randy Presuhn" > To: "LTRU Working Group" > Sent: Friday, August 12, 2005 10:27 PM > Subject: [Ltru] [psg.com #1098] WGLC distinguish subtag and extensionsregistries ... > So far, two (Doug and Kent) have spoken in favor of making the distinction > clearer. Is any more discussion needed before directing the editors to > make appropriate changes in the registry i-d? ... As a technical contributor, I don't believe a change is technically needed. Being even more explicit wouldn't hurt, but I didn't find the current text ambiguous in any way that would affect the operation of the registry. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 12:04:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3yV1-0007to-N7; Sat, 13 Aug 2005 12:04:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3yV0-0007tg-HN for ltru@megatron.ietf.org; Sat, 13 Aug 2005 12:04:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27881 for ; Sat, 13 Aug 2005 12:04:38 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3z3h-0001bQ-3h for ltru@ietf.org; Sat, 13 Aug 2005 12:40:35 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 13 Aug 2005 09:04:24 -0700 Subject: RE: [Ltru] [psg.com #1098] WGLC distinguish subtag andextensionsregistries MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Aug 2005 09:04:23 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B5B2@irvmbxw01.quest.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Thread-Topic: [Ltru] [psg.com #1098] WGLC distinguish subtag andextensionsregistries Thread-Index: AcWfy0jhBHCkWhTkSwG6iLNy9MvLWQAVD0hQ From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 13 Aug 2005 16:04:24.0313 (UTC) FILETIME=[AC7BF690:01C5A020] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org To resolve this issue, I propose: 1. A minor modification in section 2.2 (to say "Subtag Registry" the = first time). 2. A change in the title of section 3 (to say "Subtag Registry Format = and Maintenance") 3. A change in the title of section 3.6 (to "Extensions and Extensions = Registry") 4. A change in the title of section 3.7 (to "Initialization of the = Registries") 5. The modification of the first sentence in section 3.7 to say: "... an = initial version of the Language Subtag Registry containing..." 6. The addition of this paragraph at the end of section 3.7: - Adoption of this document will also REQUIRE an initial version of the = Language Extension Registry described in Section 3.6. This registry is = initially expected to contain no records. It MUST be initialized with = the following text: # Language Tag Extensions Registry (see RFC XXXX) File-Date: 2005-08-13 - Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?12? 22:53 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #1098] WGLC distinguish subtag > andextensionsregistries >=20 > Hi - >=20 > > From: "Randy Presuhn" > > To: "LTRU Working Group" > > Sent: Friday, August 12, 2005 10:27 PM > > Subject: [Ltru] [psg.com #1098] WGLC distinguish subtag and > extensionsregistries > ... > > So far, two (Doug and Kent) have spoken in favor of making the > distinction > > clearer. Is any more discussion needed before directing the editors = to > > make appropriate changes in the registry i-d? > ... >=20 > As a technical contributor, I don't believe a change is technically = needed. > Being even more explicit wouldn't hurt, but I didn't find the current = text > ambiguous in any way that would affect the operation of the registry. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 13:00:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3zN8-0000pS-4V; Sat, 13 Aug 2005 13:00:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3zN5-0000pK-B6 for ltru@megatron.ietf.org; Sat, 13 Aug 2005 13:00:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29690 for ; Sat, 13 Aug 2005 13:00:32 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3zvp-0002ky-M6 for ltru@ietf.org; Sat, 13 Aug 2005 13:36:30 -0400 Received: from h-64-105-35-210.snvacaid.dynamic.covad.net ([64.105.35.210] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3zN2-0007Gp-00 for ltru@ietf.org; Sat, 13 Aug 2005 13:00:32 -0400 Message-ID: <000c01c5a028$b29878c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C72B5B2@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #1098] WGLC distinguish subtag andextensionsregistries Date: Sat, 13 Aug 2005 10:00:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - As a technical contributor: This looks ok to me, except that "REQUIRE" isn't a 2119 keyword. I suggest: Adoption of this document will also entails initialization of the Language Extension Registry described in Section 3.6. This registry SHALL be initialized with the following text: I have a slight preference to put the initializing text in the initial registry draft, rather than the registry draft. Randy ----- Original Message ----- From: "Addison Phillips" To: "Randy Presuhn" ; "LTRU Working Group" Sent: Saturday, August 13, 2005 9:04 AM Subject: RE: [Ltru] [psg.com #1098] WGLC distinguish subtag andextensionsregistries To resolve this issue, I propose: 1. A minor modification in section 2.2 (to say "Subtag Registry" the first time). 2. A change in the title of section 3 (to say "Subtag Registry Format and Maintenance") 3. A change in the title of section 3.6 (to "Extensions and Extensions Registry") 4. A change in the title of section 3.7 (to "Initialization of the Registries") 5. The modification of the first sentence in section 3.7 to say: "... an initial version of the Language Subtag Registry containing..." 6. The addition of this paragraph at the end of section 3.7: - Adoption of this document will also REQUIRE an initial version of the Language Extension Registry described in Section 3.6. This registry is initially expected to contain no records. It MUST be initialized with the following text: # Language Tag Extensions Registry (see RFC XXXX) File-Date: 2005-08-13 - Addison ... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 13:36:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3zvp-0006fe-AI; Sat, 13 Aug 2005 13:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3zvl-0006fD-7h for ltru@megatron.ietf.org; Sat, 13 Aug 2005 13:36:27 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01272 for ; Sat, 13 Aug 2005 13:36:23 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E3zvB-0005bD-Cm for ltru@lists.ietf.org; Sat, 13 Aug 2005 19:35:49 +0200 Received: from c-134-88-46.hh.dial.de.ignite.net ([62.134.88.46]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Aug 2005 19:35:49 +0200 Received: from nobody by c-134-88-46.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Aug 2005 19:35:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 13 Aug 2005 19:33:41 +0200 Organization: Lines: 19 Message-ID: <42FE2EF5.1091@xyzzy.claranet.de> References: <007501c59fc7$effef920$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-46.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1099] WGLC add empty extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > any objections No. If I got it right it doesn't need dummy entries for i- or x- The old i- is only used to start grandfathered tags, never as extension, x- is explained in the core document, and formally it's also no extension tag. BTW, apparently... draft-ietf-proto-wgchair-doc-shepherding-05.txt ...is not yet an RfC. Have fun with testing it. Will the questionnaire you're supposed to send to Scott be published in the tracker ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 13:59:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E40I8-0001nO-3G; Sat, 13 Aug 2005 13:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E40I6-0001mU-6f for ltru@megatron.ietf.org; Sat, 13 Aug 2005 13:59:30 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02212 for ; Sat, 13 Aug 2005 13:59:28 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050813175836.NKIY19267.mta10.adelphia.net@DEWELL> for ; Sat, 13 Aug 2005 13:58:36 -0400 Message-ID: <007a01c5a030$7d3c37e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 13 Aug 2005 10:57:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1098] WGLC distinguish subtag and extensions registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Adoption of this document will also REQUIRE an initial version of the > Language Extension Registry described in Section 3.6. This registry is > initially expected to contain no records. It absolutely MUST contain no records initially. The chain of events guarantees it. In order to exist in the registry, extensions must be defined in approved RFCs that were written in accordance with the (already-approved) RFC 3066bis. Or maybe I've got this wrong. Is there any provision for an extension RFC to be written and approved before RFC 3066bis goes live? > It MUST be initialized with the following text: > > # Language Tag Extensions Registry (see RFC XXXX) > File-Date: 2005-08-13 We decided against having a comment-header like this for the main Language Subtag Registry. I think it would be quite odd and hard to justify why we have such a header for one registry but not for the other. We could resolve this by adding a comparable one-line header for the main registry, or by deleting the one Addison proposes here. Either would be fine with me. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 14:00:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E40Ib-0001sD-C6; Sat, 13 Aug 2005 14:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E40Ia-0001s3-Dz for ltru@megatron.ietf.org; Sat, 13 Aug 2005 14:00:00 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02235 for ; Sat, 13 Aug 2005 13:59:59 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E40HQ-0007KL-Df for ltru@lists.ietf.org; Sat, 13 Aug 2005 19:58:48 +0200 Received: from c-134-88-46.hh.dial.de.ignite.net ([62.134.88.46]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Aug 2005 19:58:48 +0200 Received: from nobody by c-134-88-46.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Aug 2005 19:58:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 13 Aug 2005 19:57:12 +0200 Organization: Lines: 15 Message-ID: <42FE3478.5315@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72B547@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-46.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: new editor's copy online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I have prepped a new editor's copy (draft-11) of the > draft-registry document You forgot to move 2047 to the same section as 2231 as proposed by Kent. 2231 introduced 1766-language-tags in 2047-encoded-words, 2047 states the length limit 76. If you know the URN scheme for ISBNs you could add the ISBN: 0131429019 to {record-jar]. And maybe you could try "Addison-Wesley Professional" as "series" (?) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 15:13:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E41S9-0005CE-TZ; Sat, 13 Aug 2005 15:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E41S9-0005C9-IW for ltru@megatron.ietf.org; Sat, 13 Aug 2005 15:13:57 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06833 for ; Sat, 13 Aug 2005 15:13:54 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050813191324.QEWM19267.mta10.adelphia.net@DEWELL> for ; Sat, 13 Aug 2005 15:13:24 -0400 Message-ID: <008001c5a03a$d6895940$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 13 Aug 2005 12:11:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1099] WGLC add empty extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > If I got it right it doesn't need dummy entries for i- or x- > > The old i- is only used to start grandfathered tags, never as > extension, "i" certainly can be used for an extension. There is no ambiguity between "i-ami", which is a grandfathered tag meaning 'Amis, and "de-i-ami", which means whatever the authors of the "i" extension mechanism intended it to mean. > x- is explained in the core document, and formally > it's also no extension tag. The difference here is that "x" always means "private use" regardless of its position, so it could not be an extension singleton. "i" has no such restriction. > BTW, apparently... > > draft-ietf-proto-wgchair-doc-shepherding-05.txt > > ...is not yet an RfC. Have fun with testing it. Will the > questionnaire you're supposed to send to Scott be published > in the tracker ? I think Randy has established by now that he understands which draft documents may be used in the process, or referenced in another draft, and under what circumstances. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 17:00:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E436x-0001ot-PX; Sat, 13 Aug 2005 17:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E436q-0001nV-MV for ltru@megatron.ietf.org; Sat, 13 Aug 2005 17:00:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11394 for ; Sat, 13 Aug 2005 17:00:02 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E43fc-00085u-M8 for ltru@ietf.org; Sat, 13 Aug 2005 17:36:02 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 13 Aug 2005 13:59:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message Subject: RE: [Ltru] [psg.com #1098] WGLC distinguish subtagandextensionsregistries MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Aug 2005 13:59:38 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B5BE@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1098] WGLC distinguish subtagandextensionsregistries Thread-Index: AcWgKNKAnWtK3Je6RP+E81M4U1oO2gAIOm6Q From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 13 Aug 2005 20:59:38.0681 (UTC) FILETIME=[EB120290:01C5A049] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I copied the sentence just above it, hence the normative REQUIRE. I will = fix both. I don't mind having the initial registry appear in the other draft, = although it seems small enough to put into this draft and save some = cross referencing. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?13? 10:01 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #1098] WGLC distinguish > subtagandextensionsregistries >=20 > Hi - >=20 > As a technical contributor: >=20 > This looks ok to me, except that "REQUIRE" isn't a 2119 keyword. I = suggest: >=20 > Adoption of this document will also entails initialization of the = Language > Extension Registry described in Section 3.6. This registry SHALL be > initialized > with the following text: >=20 > I have a slight preference to put the initializing text in the = initial > registry draft, > rather than the registry draft. >=20 > Randy >=20 > ----- Original Message ----- > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working = Group" > > Sent: Saturday, August 13, 2005 9:04 AM > Subject: RE: [Ltru] [psg.com #1098] WGLC distinguish subtag > andextensionsregistries >=20 >=20 > To resolve this issue, I propose: >=20 > 1. A minor modification in section 2.2 (to say "Subtag Registry" the = first > time). >=20 > 2. A change in the title of section 3 (to say "Subtag Registry Format = and > Maintenance") >=20 > 3. A change in the title of section 3.6 (to "Extensions and Extensions > Registry") >=20 > 4. A change in the title of section 3.7 (to "Initialization of the > Registries") >=20 > 5. The modification of the first sentence in section 3.7 to say: "... = an > initial version of the Language Subtag Registry > containing..." >=20 > 6. The addition of this paragraph at the end of section 3.7: >=20 > - > Adoption of this document will also REQUIRE an initial version of the > Language Extension Registry described in Section 3.6. This > registry is initially expected to contain no records. It MUST be > initialized with the following text: >=20 > # Language Tag Extensions Registry (see RFC XXXX) > File-Date: 2005-08-13 > - >=20 > Addison > ... >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 17:16:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E43MO-0003w4-ID; Sat, 13 Aug 2005 17:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E43MM-0003vj-8s for ltru@megatron.ietf.org; Sat, 13 Aug 2005 17:16:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12399 for ; Sat, 13 Aug 2005 17:16:04 -0400 (EDT) Received: from eastrmmtao06.cox.net ([68.230.240.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E43v8-0008My-LV for ltru@ietf.org; Sat, 13 Aug 2005 17:52:03 -0400 Received: from A31P ([68.100.55.187]) by eastrmmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050813211535.GVUE28616.eastrmmtao06.cox.net@A31P>; Sat, 13 Aug 2005 17:15:35 -0400 From: "Scott Hollenbeck" To: "'Frank Ellermann'" , Subject: RE: [Ltru] Re: [psg.com #1099] WGLC add empty extension registry Date: Sat, 13 Aug 2005 17:15:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42FE2EF5.1091@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWgLdNdYRSqtrsCQD+4Zc/P4eJFfwAHht0Q Message-Id: <20050813211535.GVUE28616.eastrmmtao06.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > The old i- is only used to start grandfathered tags, never as > extension, x- is explained in the core document, and > formally it's also no extension tag. BTW, apparently... > > draft-ietf-proto-wgchair-doc-shepherding-05.txt > > ...is not yet an RfC. Have fun with testing it. Will the > questionnaire you're supposed to send to Scott be published > in the tracker ? I'll add the answers as a comment. The last bits will be included in the IESG ballot. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 18:27:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E44T3-0005gm-5n; Sat, 13 Aug 2005 18:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E44T1-0005eW-As for ltru@megatron.ietf.org; Sat, 13 Aug 2005 18:27:03 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15696 for ; Sat, 13 Aug 2005 18:26:59 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E44S1-00038U-3V for ltru@lists.ietf.org; Sun, 14 Aug 2005 00:26:01 +0200 Received: from c-134-88-65.hh.dial.de.ignite.net ([62.134.88.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Aug 2005 00:26:01 +0200 Received: from nobody by c-134-88-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Aug 2005 00:26:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 14 Aug 2005 00:14:01 +0200 Organization: Lines: 19 Message-ID: <42FE70A9.2D47@xyzzy.claranet.de> References: <008001c5a03a$d6895940$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1099] WGLC add empty extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > "i" certainly can be used for an extension. Yes, I only was thinking loud - i.e. why is there no "X" in the initial extension registry. > I think Randy has established by now that he > understands which draft documents may be used in > the process Pardon ? Somewhat unrelated to my question, it's me who doesn't know how PROTO will work, but Scott already answered it. We can see it at http://purl.net/xyzzy/-ietf/ltru Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 19:55:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E45ql-0000lO-UQ; Sat, 13 Aug 2005 19:55:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E45qk-0000lG-GX for ltru@megatron.ietf.org; Sat, 13 Aug 2005 19:55:38 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18544 for ; Sat, 13 Aug 2005 19:55:35 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050813235504.IJUA29002.mta9.adelphia.net@DEWELL> for ; Sat, 13 Aug 2005 19:55:04 -0400 Message-ID: <002201c5a062$5ea5f1e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050813160103.MGXE29598.mta4.adelphia.net@megatron.ietf.org> Date: Sat, 13 Aug 2005 16:54:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1098] WGLC distinguish subtag and extensions registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > So far, two (Doug and Kent) have spoken in favor of making the > distinction clearer. Is any more discussion needed before directing > the editors to make appropriate changes in the registry i-d? To clarify, here is the passage from Kent to which I responded: > [Kent Karlsson] >> I would suggest that each >> occurrence of "registry" in the -registry document be clarified >> to "(IANA) Language subtag registry", "(IANA) Language tag extension >> registry", or "(IANA) Language subtag and tag extensions registries" >> (with suitable unambiguous short forms) as appropriate. > > [Doug Ewell] > Perhaps Kent could identify the particular spots that seemed > troublesome, and the group can decide whether appropriate editorial > changes are needed. I suspect that changing every reference > throughout the entire document would be excessive (just as I believe > it would be excessive in draft-initial, which only deals with one > registry). The references to "registry" in sections 3.6 and 5.2 would > be most likely to benefit from clarification. In other words, there *might* be specific spots in draft-registry where the word "registry" might be misunderstood, and might benefit from being qualified as "subtag registry" or "extension(s) registry." Those are the only changes I would propose, and if the group agrees that those spots are not really ambiguous either, except through willful misreading, then I would agree with Randy that these minor changes are unnecessary. Adding the extension(s) registry to draft-initial (I prefer "extension" without the "s", parallel to "subtag registry," but others seem to like it) definitely will require some rewording to resolve newly created ambiguities. If we go that route, group review of the new wording will be essential. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 20:05:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E460e-0002IH-61; Sat, 13 Aug 2005 20:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E460c-0002IC-Th for ltru@megatron.ietf.org; Sat, 13 Aug 2005 20:05:50 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18804 for ; Sat, 13 Aug 2005 20:05:49 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050814000519.XXJG14360.mta13.adelphia.net@DEWELL> for ; Sat, 13 Aug 2005 20:05:19 -0400 Message-ID: <002901c5a063$cc2af160$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050813235609.BRPM29598.mta4.adelphia.net@megatron.ietf.org> Date: Sat, 13 Aug 2005 17:04:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1098] WGLC distinguish subtag and extensions registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >> I have a slight preference to put the initializing text in the >> initial registry draft, rather than the registry draft. > ... > I don't mind having the initial registry appear in the other draft, > although it seems small enough to put into this draft and save some > cross referencing. Initially I was in favor of having the (vestigial) initial extension registry appear in draft-initial, rather than draft-registry. But based on: * the size of the initial extension registry, * the size of the two drafts, * the ease with which Addison showed he could add it to draft-registry, * the effort I estimate would be needed to add it to draft-initial, and * the editorial-only nature of Second WGLC changes, I've come to prefer adding it to draft-registry instead. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 20:26:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E46KA-00056H-Uy; Sat, 13 Aug 2005 20:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E46K9-000567-AA for ltru@megatron.ietf.org; Sat, 13 Aug 2005 20:26:01 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19224 for ; Sat, 13 Aug 2005 20:25:59 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050814002530.JNVR29002.mta9.adelphia.net@DEWELL> for ; Sat, 13 Aug 2005 20:25:30 -0400 Message-ID: <003b01c5a066$a3cf3020$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050813235609.BRPM29598.mta4.adelphia.net@megatron.ietf.org> Date: Sat, 13 Aug 2005 17:25:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1098] WGLC distinguish subtag and extensions registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > This looks ok to me, except that "REQUIRE" isn't a 2119 keyword. I > suggest: > > Adoption of this document will also entails initialization of the > Language Extension Registry described in Section 3.6... Recte: "will also entail," or "also entails." -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Aug 13 21:01:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E46s3-0001uE-Mv; Sat, 13 Aug 2005 21:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E46s1-0001tz-ON for ltru@megatron.ietf.org; Sat, 13 Aug 2005 21:01:01 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20334 for ; Sat, 13 Aug 2005 21:01:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050814010018.TAGA24042.mta11.adelphia.net@DEWELL> for ; Sat, 13 Aug 2005 21:00:18 -0400 Message-ID: <006501c5a06b$7f097c00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050813235609.BRPM29598.mta4.adelphia.net@megatron.ietf.org> Date: Sat, 13 Aug 2005 17:59:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1099] WGLC add empty extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> "i" certainly can be used for an extension. > > Yes, I only was thinking loud - i.e. why is there > no "X" in the initial extension registry. Because "x" is a special case, as you've probably answered yourself. >> I think Randy has established by now that he >> understands which draft documents may be used in >> the process > > Pardon ? Somewhat unrelated to my question, it's > me who doesn't know how PROTO will work, but Scott > already answered it. Sorry, I think I misunderstood you. There have been various complaints through the months that draft documents could not be referenced in an RFC, and Randy has replied that in some cases -- for example, RFC 2234bis -- it is OK because the draft is scheduled to be approved in the very near future, and the RFC editor will fix things up. I thought you were making a similar statement about Randy's use of draft-ietf-proto-wgchair-doc-shepherding-05, and I apologize for my response if that was not the case. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 14 04:14:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4DdZ-0008SL-BB; Sun, 14 Aug 2005 04:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4DdX-0008SG-H2 for ltru@megatron.ietf.org; Sun, 14 Aug 2005 04:14:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15711 for ; Sun, 14 Aug 2005 04:14:29 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ECP-0007qD-Oa for ltru@ietf.org; Sun, 14 Aug 2005 04:50:35 -0400 X-Medic-Info: 2aad.42fefd5f.0 SAzjvmNNGkXN0pe5 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id F18D58AC8 for ; Sun, 14 Aug 2005 10:14:23 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Sun, 14 Aug 2005 10:14:23 +0200 (CEST) Message-ID: <60357.83.248.26.202.1124007263.squirrel@webmail.chalmers.se> In-Reply-To: <42FE3478.5315@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72B547@irvmbxw01.quest.com> <42FE3478.5315@xyzzy.claranet.de> Date: Sun, 14 Aug 2005 10:14:23 +0200 (CEST) Subject: Re: [Ltru] Re: new editor's copy online From: "Kent Karlsson" To: ltru@ietf.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I still find [RFC2047] in the list of normative references. I cannot find any reason whatsoever to have that as a *normative* reference. Likewise do [RFC2434], [RFC2781], and [RFC3552] NOT belong in the *normative* references list (which I have pointed out several times before). The list of normative references should be kept at an absolute minimum. Can we please have the normative references list cleared up (i.e. minimised); it's not a purely editoral issue. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 14 10:39:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4JeW-00029f-9N; Sun, 14 Aug 2005 10:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4JeS-00029O-Ko for ltru@megatron.ietf.org; Sun, 14 Aug 2005 10:39:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29151 for ; Sun, 14 Aug 2005 10:39:49 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4KDM-0006Se-8T for ltru@ietf.org; Sun, 14 Aug 2005 11:15:59 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E4JeK-00073X-62; Sun, 14 Aug 2005 07:39:44 -0700 Message-Id: <6.2.1.2.2.20050814152250.04080180@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 14 Aug 2005 16:03:58 +0200 To: "Randy Presuhn" , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Wrapping up the second WG last calls on the registry and initial registry drafts In-Reply-To: <008101c59fca$b6729560$7f1afea9@oemcomputer> References: <008101c59fca$b6729560$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 07:49 13/08/2005, Randy Presuhn said: > Then Martin and I will start the process of shepherding these through > the IESG, using the >http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt >procedures as directed by our AD. Interesting. FYI: 1) I have a pending proposition to the authors of this draft to make every Sheperding WG Chair work copied to the WG, including the separate mails reporting on formal oppositions, as a LC not subject to consensus, for transparency and editing assistance (this is the WG sales pitch). 2) I have also proposed two additional questions (the Charter which is the Contact with the IESG/IAB is not considered, COI and chapel and status quo effects are only partly addressed): - has the WG initially well understood its Charter? Has it adhered to it? Has it extended it in some manner? Has the WG used a working road map of some sort? Does the presented document fulfills the corresponding part(s) of the WG Charter? Has the WG identified relations with the Charter of other WGs? In such a case have you discussed the matter with the concerned ADs and WG Chairs? - do you feel comfortable that this document is free from competition between technical chapels and represents a genuine, inclusive and open effort to best support all the needs of the state of the art protocols, applications, procedures, of the current or of the documented common practices, and of the disclosed R&D projects? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 14 10:54:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4JsP-0003wO-Qt; Sun, 14 Aug 2005 10:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4JsO-0003wE-6Y for ltru@megatron.ietf.org; Sun, 14 Aug 2005 10:54:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29540 for ; Sun, 14 Aug 2005 10:54:13 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4KRL-0006gj-1p for ltru@ietf.org; Sun, 14 Aug 2005 11:30:23 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E4JsM-0000lp-Os for ltru@ietf.org; Sun, 14 Aug 2005 07:54:15 -0700 Message-Id: <6.2.1.2.2.20050814165223.0307be00@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 14 Aug 2005 16:54:06 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Subject: [Ltru] non-script support X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear all, It is interesting to note that this WG claims to deliver general purpose language tags. Several times members underlined that it did not only support the printing industry but every language related issue, whatever the medium/media (except the odd restriction concerning artificial and machine languages - what will be a major a problem since the WG does not want to define what is a language in a distributed network context (this leaves specialists perplex). Is a "computer script" part of human language (architexts are computer languages, HTML and XML are computer languages)? Is a "Pink Minitel" automated program using a human (at least an adult) language? I also regret it does not want to be bilingual: French uses two different terms ("langue" and "language"] what certainly helps the analysis. However the Draft ABNF says: range = (language ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse]) "script" here is confusing for the average layman, if it also to mean voice, bel canto, alarms, content mix. All the more than all this fuss about langtags (rather than voiding illegal RFC 3066) is for XML (not CLDRs, says Mark Davis; not official W3C says Addison Philips) while the W3C calls for positions on internationalizing the Speech Synthesis Markup Language (SSML). The topics under consideration seem to belong this debate, as the very equivalent for non written language usage to what script is for a written usage: pronunciation, volume, pitch and rate among others like sex, accent, age, speed, style, referent, etc. If Members are interested the can read about the W3C effort at: http://www.w3.org/2005/08/SSML/ssml-workshop-cfp http://www.w3.org/2003/08/Workshops/ http://www.w3.org/Voice/ The WG-ltru Draft is only written by individuals not representing the position of the W3C (however it does not include a disclaimer like the K/H RFC). Key non-Member SDOs such MPEG, ITU which are concerned or influencing the international network technology, and key non-Members concerned organisations such as UNESCO, MINC, ISO, GAC,are not represented in this debate or their members ignored. Considering this, I think it would be inappropriate at this stage to impose the premature load of reviewing an incomplete and contested Draft , even in helping with its document write-up, to the IESG. At least, - the Draft should also documents the support of the voice subtags in parallel to script subtags, and create an ad-hoc registry until ISO or another SDO can come with an acceptable registry. - there is a position request sent to the W3C/IETF joint committee. - there is a coordination exchange with ITU, MPEG, UNESCO, MINC, ISO, GAC, ccTLDs, ICANN, as the current most concerned entities I can think off. I note that, should this Draft be accepted and confirmed in appeal by the IESG, my appeal to the IAB will include among many other things, a call for an IAB guidance over the missing analysis and descriptions of what is a text, a script, a language, a mode, a referent, a context in a computer network environment [which is essentially differ from printed and past centuries document by usage, by technology, type of exchanges and relations and by the functions of each of these elements in the communication]. More generally guidance will also be called concerning the exact bearing (identification, definition, authentication, negotiation?) of the proposed langtags, the required competence and authoritativeness to discuss their registration, the management of their possible conflicts with other elements (parameters, names, tags, ccTLD, voice descriptions, icons, charsets, etc.), etc. I am glad the W3C approaches these questions seriously. But the W3C is an application oriented consortium, like several others: they need to rely on a stable and open network architecture basis, the IETF is to provide. I am afraid that IETF and IAB are not supporting their effort adequately at that network architecture level. We must provide the building blocks (protocols, concepts, tools, elements, etc.) they will build upon. I am afraid the script oriented Draft and its IANA Registry Management is only a small part of their whole need to describe and usefully support lingual channels. This calls for a global consensual (the whole intergovernance of the world digital ecosystem) framework, for the [at least 5 main subtags plus date] I ask, for the analysis this WG refused to carry through a serious reading of the Charter (which should be submitted to an IAB review since the WG-ltru did not prompt by itself the amendment and extensions this Charter require), for an ISO 11179 approach permitting the extensibility and the scalability the users need, whatever the ISO inter TCs feuds which are of no interest to IETF. The Draft is now probably mature in its ABNF part (except its attempts at format exclusion). The corresponding filter should be finalised. This should satisfy the librarians, the political censors/police (cf. security section), the corporate strategists and some developers. I doubt however this theoretical simplification of the lingual reality will match the needs of the users, of the search engines, of the sales people (they want to satisfy their customers, not to curb them to unrealistic standards). So, the authors have completed the work they were assigned by the Chairs. The WG should now initiate the real work required by the IESG and expected from the expertise it claims to gather. For that we only need to make sure the Draft only claims to complete RFC 3066, and to jointly write a consensual BCP 47 Multilingual Internet framework which will support it - and the many other more pragmatic propositions we can expect. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 14 16:30:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4P7f-0004bR-4g; Sun, 14 Aug 2005 16:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4P7e-0004bM-Cb for ltru@megatron.ietf.org; Sun, 14 Aug 2005 16:30:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10992 for ; Sun, 14 Aug 2005 16:30:19 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4Pgb-0004Em-SG for ltru@ietf.org; Sun, 14 Aug 2005 17:06:32 -0400 X-Medic-Info: 4bc2.42ffa9d5.0 hvM8CobEtvC09g47 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id BD22443A7; Sun, 14 Aug 2005 22:30:13 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Sun, 14 Aug 2005 22:30:13 +0200 (CEST) Message-ID: <60132.83.248.26.202.1124051413.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C72B5B2@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0C72B5B2@irvmbxw01.quest.com> Date: Sun, 14 Aug 2005 22:30:13 +0200 (CEST) Subject: RE: [Ltru] [psg.com #1098] WGLC distinguish subtagandextensionsregistries From: "Kent Karlsson" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Ok, with Doug's improvements (and make the naming consistent; here without plural s, as Doug suggested). I like the self-declaration leading comment; there should be one for the subtag registry too. > To resolve this issue, I propose: > > 1. A minor modification in section 2.2 (to say "Subtag Registry" the fi= rst > time). > > 2. A change in the title of section 3 (to say "Subtag Registry Format a= nd > Maintenance") > > 3. A change in the title of section 3.6 (to "Extensions and Extensions > Registry") > > 4. A change in the title of section 3.7 (to "Initialization of the > Registries") > > 5. The modification of the first sentence in section 3.7 to say: "... a= n > initial version of the Language Subtag Registry containing..." > > 6. The addition of this paragraph at the end of section 3.7: > > - > Adoption of this document will also REQUIRE an initial version of the > Language Extension Registry described in Section 3.6. This registry is > initially expected to contain no records. It MUST be initialized with t= he > following text: > > # Language Tag Extensions Registry (see RFC XXXX) > File-Date: 2005-08-13 > - > > Addison _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 14 17:13:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4PnS-0000wZ-KD; Sun, 14 Aug 2005 17:13:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4PnR-0000wR-3Z for ltru@megatron.ietf.org; Sun, 14 Aug 2005 17:13:33 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12891 for ; Sun, 14 Aug 2005 17:13:29 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4Pml-0005a0-E9 for ltru@lists.ietf.org; Sun, 14 Aug 2005 23:12:51 +0200 Received: from c-180-161-139.hh.dial.de.ignite.net ([62.180.161.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Aug 2005 23:12:51 +0200 Received: from nobody by c-180-161-139.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Aug 2005 23:12:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 14 Aug 2005 23:09:37 +0200 Organization: Lines: 36 Message-ID: <42FFB311.2D4@xyzzy.claranet.de> References: <20050813235609.BRPM29598.mta4.adelphia.net@megatron.ietf.org> <006501c5a06b$7f097c00$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-139.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1099] WGLC add empty extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > Randy has replied that in some cases -- for example, RFC > 2234bis -- it is OK because the draft is scheduled to be > approved in the very near future, and the RFC editor will > fix things up. Yes, actually it was Scott, and 2234bis is already approved. It's high IETF drama, from my POV more amusing than serious. But confusing for innocent bystanders, see also the end of > I thought you were making a similar statement about Randy's > use of draft-ietf-proto-wgchair-doc-shepherding-05 No, and that's different, it's not yet approved, you can see see the status of I-Ds in the tracker (redirection, because the complete minimal URL is a royal PITA): http://purl.net/xyzzy/-draft/draft-ietf-proto-wgchair http://purl.net/xyzzy/-draft/draft-crocker-abnf The former is in state "I-D exists", the latter has been sent to the "RFC-Ed-queue" (for more details like "approved" click "DETAIL"). > I apologize for my response if that was not the case. No problem, probably Randy and Scott want to test the proposed procedure. It's not really needed in our case, the PROTO I-D is apparently based on the assumption that the AD has no clear idea what the WG did and why the Chair thinks that a particular document is ready. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 14 17:30:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Q3u-0002qf-Ua; Sun, 14 Aug 2005 17:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Q3u-0002qX-2t for ltru@megatron.ietf.org; Sun, 14 Aug 2005 17:30:34 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13522 for ; Sun, 14 Aug 2005 17:30:30 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4Q2b-00077X-14 for ltru@lists.ietf.org; Sun, 14 Aug 2005 23:29:13 +0200 Received: from c-180-161-139.hh.dial.de.ignite.net ([62.180.161.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Aug 2005 23:29:13 +0200 Received: from nobody by c-180-161-139.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Aug 2005 23:29:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 14 Aug 2005 23:27:00 +0200 Organization: Lines: 17 Message-ID: <42FFB724.3544@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72B5B2@irvmbxw01.quest.com> <60132.83.248.26.202.1124051413.squirrel@webmail.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-139.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1098] WGLC distinguish subtagandextensionsregistries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: > I like the self-declaration leading comment; there should be > one for the subtag registry too. There are no such comments in section 3.1, the ABNF >> # Language Tag Extensions Registry (see RFC XXXX) >> File-Date: 2005-08-13 So that's wrong, the line starting with "#" is no record, and the first record must be a File-Date. In another article you said that [RFC2434], [RFC2781], and [RFC3552] (like 2047) shouldn't be normative, that's not yet fixed in the public editor's copy of -11 (Aug 12). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 14 21:02:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4TMe-0008TT-DV; Sun, 14 Aug 2005 21:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4TMd-0008TO-4N for ltru@megatron.ietf.org; Sun, 14 Aug 2005 21:02:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21662 for ; Sun, 14 Aug 2005 21:02:04 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4Tvf-0000rM-22 for ltru@ietf.org; Sun, 14 Aug 2005 21:38:19 -0400 Received: from h-68-165-3-43.snvacaid.dynamic.covad.net ([68.165.3.43] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4TMV-0006PY-00 for ltru@ietf.org; Sun, 14 Aug 2005 21:01:59 -0400 Message-ID: <001601c5a135$215feb00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050813235609.BRPM29598.mta4.adelphia.net@megatron.ietf.org><006501c5a06b$7f097c00$030aa8c0@DEWELL> <42FFB311.2D4@xyzzy.claranet.de> Date: Sun, 14 Aug 2005 18:03:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Ltru] Use of shepherding procedures X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I *REALLY* wish the folks in this WG would stick to one topic per message, and use appropriate subject lines! > From: "Frank Ellermann" > To: > Sent: Sunday, August 14, 2005 2:09 PM > Subject: [Ltru] Re: [psg.com #1099] WGLC add empty extension registry ... > No problem, probably Randy and Scott want to test the proposed > procedure. It's not really needed in our case, the PROTO I-D > is apparently based on the assumption that the AD has no clear > idea what the WG did and why the Chair thinks that a particular > document is ready. ... That's not my perception at all. These procedures have been use in other areas, e.g. Operations & Management, for quite a while. I don't know how long they've been used in the Applications area, but I strongly suspect they've been in use here for some time, too. It's not (at least in this case) motivated by a desire to "test" the procedures. The primary motivations for these procedures are to get documents through the IESG more quickly by offloading the ADs somewhat and ensuring a tighter feedback loop between the IESG and the WG for handling any DISCUSS comments that might arise. Before these procedures were written down, many of the elements of these procedures were informally in place. For example, ad hoc exchanges between WG chairs and ADs during the process of handing a document to the IESG would usually cover all the "questionaire" points. We haven't yet decided whether Martin or I will do the shepherding for these two documents while the WG finishes up the matching draft. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Aug 14 21:21:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4TfJ-0001jC-5h; Sun, 14 Aug 2005 21:21:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4TfI-0001j7-B1 for ltru@megatron.ietf.org; Sun, 14 Aug 2005 21:21:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22176 for ; Sun, 14 Aug 2005 21:21:21 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4UEK-0001Bb-PY for ltru@ietf.org; Sun, 14 Aug 2005 21:57:37 -0400 Received: from h-68-165-3-43.snvacaid.dynamic.covad.net ([68.165.3.43] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4TfG-0005KK-00 for ltru@ietf.org; Sun, 14 Aug 2005 21:21:22 -0400 Message-ID: <004701c5a137$d86fb580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C72B547@irvmbxw01.quest.com><42FE3478.5315@xyzzy.claranet.de> <60357.83.248.26.202.1124007263.squirrel@webmail.chalmers.se> Date: Sun, 14 Aug 2005 18:22:46 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Ltru] [psg.com #1095] continued discussion of references section X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - (Note that I changed the subject line to something meaningful.) As a technical contributor... > From: "Kent Karlsson" > To: > Sent: Sunday, August 14, 2005 1:14 AM > Subject: Re: [Ltru] Re: new editor's copy online > > I still find [RFC2047] in the list of normative references. > I cannot find any reason whatsoever to have that as a > *normative* reference. Agreed. RFC 2047 appears to be a typical example of an informative reference. > Likewise do [RFC2434], [RFC2781], and [RFC3552] NOT belong in > the *normative* references list (which I have pointed out > several times before). The reference to RFC 2434 is clearly normative, since in section 3.6 it defines the process to be used for single-letter subtag assignments. Consequently, it shoudl stay in the normative references section. I agree that the reference to RFC 2781 is clearly informative, since it is only cited in the context of an example. RFC 3552 is one of those difficult borderline cases, and there are reasonable arguments both ways. However, I'm inclined to agree that it should be treated as an informative reference, rather than as a normative one, given the level of indirection in the context in which it is cited. > The list of normative references should be kept at an absolute > minimum. > > Can we please have the normative references list cleared up > (i.e. minimised); it's not a purely editoral issue. ... To me this would mean moving 2047, 2781, and 3552 to the informative references, but retaining 2434 in the normative ones. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 00:48:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Wu8-00041M-LH; Mon, 15 Aug 2005 00:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Wu5-00041H-JT for ltru@megatron.ietf.org; Mon, 15 Aug 2005 00:48:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29518 for ; Mon, 15 Aug 2005 00:48:49 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4Wsx-0003VI-2O for ltru@lists.ietf.org; Mon, 15 Aug 2005 06:47:43 +0200 Received: from c-180-161-139.hh.dial.de.ignite.net ([62.180.161.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 06:47:43 +0200 Received: from nobody by c-180-161-139.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 06:47:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 15 Aug 2005 06:45:34 +0200 Organization: Lines: 39 Message-ID: <43001DEE.3CD4@xyzzy.claranet.de> References: <20050813235609.BRPM29598.mta4.adelphia.net@megatron.ietf.org><006501c5a06b$7f097c00$030aa8c0@DEWELL> <42FFB311.2D4@xyzzy.claranet.de> <001601c5a135$215feb00$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-139.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Use of shepherding procedures X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I *REALLY* wish the folks in this WG would stick to one > topic per message, and use appropriate subject lines! The Re: [psg.com #1099] tags were certainly not my idea, I dare not touch them, because you wanted them. We had normal threads with Subject: new (was: old) before the ticket flood. After that I gave up to look at subjects. [draft-ietf-proto-wgchair] > I don't know how long they've been used in the Applications > area, but I strongly suspect they've been in use here for > some time, too. I haven't seen any IETF WG actually producing an RfC from the inside, therefore I thought that this I-D is a new idea, and you want to test it. > The primary motivations for these procedures are to get > documents through the IESG more quickly by offloading the > ADs somewhat Yes, I got that idea from a quick look into it. If you use it for real it should be an RfC. Or it should be noted in [TAObis], "some really important documents are only available as drafts", in a section where it also explains "recursion". > For example, ad hoc exchanges between WG chairs and ADs > during the process of handing a document to the IESG would > usually cover all the "questionaire" points. Apparently you're supposed to post a copy here (excluding 1F), and a reply with open questions would be also posted here (2E). The MUST in 2G in conjunction with 2I sounds like a potential dead loop, does that happen ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 01:24:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4XSd-0007k8-Rr; Mon, 15 Aug 2005 01:24:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4XSc-0007jx-MU for ltru@megatron.ietf.org; Mon, 15 Aug 2005 01:24:34 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00801 for ; Mon, 15 Aug 2005 01:24:33 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050815052400.QZFR29002.mta9.adelphia.net@DEWELL> for ; Mon, 15 Aug 2005 01:24:00 -0400 Message-ID: <001801c5a159$7b0f78e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 14 Aug 2005 22:23:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] [psg.com #1099] WGLC add empty extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org (switching to the correct Subject line) Frank Ellermann wrote: >> I like the self-declaration leading comment; there should be >> one for the subtag registry too. > > There are no such comments in section 3.1, the ABNF > >> # Language Tag Extensions Registry (see RFC XXXX) >> File-Date: 2005-08-13 > > So that's wrong, the line starting with "#" is no record, and > the first record must be a File-Date. Sadly, what Frank says is true. There is no provision in the record-jar ABNF for a header or other file-level comment, introduced by # or anything else. We can't do this without amending the ABNF. Furthermore, now that I notice it, there is also no provision in Section 3.6 for a File-Date record in the extension registry. It is defined as consisting solely of records in the format shown in Figure 6. (I would suggest, however, that the leading and trailing %% in Figure 6 be treated as examples only, and that %% be used only as a separator between records, as in the subtag registry.) -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 02:18:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4YJD-0004oK-QV; Mon, 15 Aug 2005 02:18:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4YJC-0004oF-Iq for ltru@megatron.ietf.org; Mon, 15 Aug 2005 02:18:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15039 for ; Mon, 15 Aug 2005 02:18:53 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4YsH-0006fG-8p for ltru@ietf.org; Mon, 15 Aug 2005 02:55:09 -0400 Received: from h-68-165-3-43.snvacaid.dynamic.covad.net ([68.165.3.43] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4YJ2-0001Uw-00 for ltru@ietf.org; Mon, 15 Aug 2005 02:18:44 -0400 Message-ID: <000e01c5a161$61860580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050813235609.BRPM29598.mta4.adelphia.net@megatron.ietf.org><006501c5a06b$7f097c00$030aa8c0@DEWELL><42FFB311.2D4@xyzzy.claranet.de><001601c5a135$215feb00$7f1afea9@oemcomputer> <43001DEE.3CD4@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Use of shepherding procedures Date: Sun, 14 Aug 2005 23:19:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Sunday, August 14, 2005 9:45 PM > Subject: [Ltru] Re: Use of shepherding procedures ... > I haven't seen any IETF WG actually producing an RfC from the > inside, therefore I thought that this I-D is a new idea, and > you want to test it. As I said, it's been in use in Operations & Management area for some time, and I know several RFCs have been produced using these procedures. For me it's a matter of some indifference whether we use these procedures; the decision to apply them is the AD's. > > The primary motivations for these procedures are to get > > documents through the IESG more quickly by offloading the > > ADs somewhat > > Yes, I got that idea from a quick look into it. If you use > it for real it should be an RfC. Or it should be noted in > [TAObis], "some really important documents are only available > as drafts", in a section where it also explains "recursion". That's outside this WG's scope. I guess ietf@ietf.org would be the place for followups, or you could go directly to the authors of http://www.ietf.org/internet-drafts/draft-hoffman-taobis-03.txt My experience here as well as in ISO/ITU, ANSI, and DMTF-land is that the procedures and guidelines and organizational culture are constantly evolving ("continuous improvement") and that the process documentation, while immensely helpful, often just provides snapshots from which one might estimate a trajectory. By the time something is "done", it's already time for an update. 2223bis is a classic example of this. (Perfection precludes completion, and vice versa. See also "Optimization hinders evolution." :-) > > For example, ad hoc exchanges between WG chairs and ADs > > during the process of handing a document to the IESG would > > usually cover all the "questionaire" points. > > Apparently you're supposed to post a copy here (excluding 1F), > and a reply with open questions would be also posted here (2E). That will happen once Martin and I have agreed who is handling it. The time difference between San Jose and Japan, as well as our travel schedules, sometimes makes it difficult to sync up. > The MUST in 2G in conjunction with 2I sounds like a potential > dead loop, does that happen ? ... Not in my experience. I have heard of horror stories, but every time I been through this process myself, whether as a chair, editor, reviewer, or WG participant, things have worked out to a mutually satisfactory conclusion. Anyway, this discussion is getting outside the scope of this particular WG; these higher-level process concerns belong on ietf@ietf.org, discussion with the authors of the shepherding draft, or possibly the newtrk working group. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 02:32:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4YWW-0006PD-8G; Mon, 15 Aug 2005 02:32:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4YWU-0006P8-QM for ltru@megatron.ietf.org; Mon, 15 Aug 2005 02:32:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16084 for ; Mon, 15 Aug 2005 02:32:37 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4Z5a-0006vH-0r for ltru@ietf.org; Mon, 15 Aug 2005 03:08:54 -0400 Received: from h-68-165-3-43.snvacaid.dynamic.covad.net ([68.165.3.43] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4YWT-0003lk-00 for ltru@ietf.org; Mon, 15 Aug 2005 02:32:37 -0400 Message-ID: <001701c5a163$52d8c7a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001801c5a159$7b0f78e0$030aa8c0@DEWELL> Subject: Re: [Ltru] [psg.com #1099] WGLC add empty extension registry Date: Sun, 14 Aug 2005 23:34:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - As a technical contributor... > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Sunday, August 14, 2005 10:23 PM > Subject: [Ltru] [psg.com #1099] WGLC add empty extension registry ... > Sadly, what Frank says is true. There is no provision in the record-jar > ABNF for a header or other file-level comment, introduced by # or > anything else. We can't do this without amending the ABNF. > > Furthermore, now that I notice it, there is also no provision in Section > 3.6 for a File-Date record in the extension registry. It is defined as > consisting solely of records in the format shown in Figure 6. (I would > suggest, however, that the leading and trailing %% in Figure 6 be > treated as examples only, and that %% be used only as a separator > between records, as in the subtag registry.) ... I disagree. Section 3.6 says "[t]his registry MUST use the record-jar format described by the ABNF in Section 3.1." That would give it a File-Date record. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 03:59:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ZsS-0007a4-J7; Mon, 15 Aug 2005 03:59:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ZsQ-0007Zr-Pz for ltru@megatron.ietf.org; Mon, 15 Aug 2005 03:59:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19058 for ; Mon, 15 Aug 2005 03:59:21 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4aRW-0000A0-Me for ltru@ietf.org; Mon, 15 Aug 2005 04:35:39 -0400 X-Medic-Info: 1f6d.43004b4c.0 cr5GezPZb84vXXJa Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 34804467C; Mon, 15 Aug 2005 09:59:08 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Mon, 15 Aug 2005 09:59:08 +0200 (CEST) Message-ID: <61696.83.248.26.202.1124092748.squirrel@webmail.chalmers.se> In-Reply-To: <001701c5a163$52d8c7a0$7f1afea9@oemcomputer> References: <001801c5a159$7b0f78e0$030aa8c0@DEWELL> <001701c5a163$52d8c7a0$7f1afea9@oemcomputer> Date: Mon, 15 Aug 2005 09:59:08 +0200 (CEST) Subject: Re: [Ltru] [psg.com #1099] WGLC add empty extension registry From: "Kent Karlsson" To: "Randy Presuhn" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > I disagree. Section 3.6 says "[t]his registry MUST use the record-jar > format described by the ABNF in Section 3.1." That would give it a > File-Date record. Not directly by the ABNF, but by the text following it. Since I like the file self declarations, I would suggest to make the following text replacement, with obvious consequences: ---------------------OLD TEXT----------------- The first record in the file contains the single field whose field-name i= s "File-Date". The field-body of this record contains the last modification date of this copy of the registry, making it possible to compare different versions of the registry. The registry on the IANA website is the most current. Versions with an older date than that one ar= e not up-to-date. File-Date: 2004-06-28 %% ---------------------NEW TEXT----------------- The first record in the file SHALL contain two fields whose field-names are "File-Date" and "Description". The field-body of the "File-Date" field of this record SHALL contain the last modification date of this copy of the registry. This makes it possible to compare different versions of the registry. The registry on the IANA website is the most current. Versions with an older date than that one are not up-to-date. The field-body of the "Description" field SHALL contain a short comment o= n what the content of the registry is. For example, File-Date: 2004-06-28 Description: IANA Language subtag registry (see RFC XXXX) ----------------------------------------- This would then apply to both registries. (Maybe some other sentence need= s to be amended too.) Note the introduction of the "SHALL"s above, to make it proper standardese. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 10:33:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4g27-0000Xg-6r; Mon, 15 Aug 2005 10:33:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4g26-0000Xa-9G for ltru@megatron.ietf.org; Mon, 15 Aug 2005 10:33:46 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06392 for ; Mon, 15 Aug 2005 10:33:44 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050815143314.VXZU19267.mta10.adelphia.net@DEWELL> for ; Mon, 15 Aug 2005 10:33:14 -0400 Message-ID: <001001c5a1a6$2bdd65a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 15 Aug 2005 07:32:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Proposed file-level "Description" field (was: Re: [psg.com #1099] WGLC add empty extension registry) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I disagree. Section 3.6 says "[t]his registry MUST use the record-jar > format described by the ABNF in Section 3.1." That would give it a > File-Date record. Kent Karlsson replied: > Not directly by the ABNF, but by the text following it. I agree with Kent. The ABNF doesn't say anything about a File-Date record. Kent continued: > Since I like the file self declarations, I would suggest to > make the following text replacement, with obvious consequences: > ... > The first record in the file SHALL contain two fields whose field- > names are "File-Date" and "Description". The field-body of the "File- > Date" field of this record SHALL contain the last modification date of > this copy of the registry. This makes it possible to compare different > versions of the registry. The registry on the IANA website is the most > current. Versions with an older date than that one are not up-to-date. > The field-body of the "Description" field SHALL contain a short > comment on what the content of the registry is. For example, > > File-Date: 2004-06-28 > Description: IANA Language subtag registry (see RFC XXXX) For reasons specific to my implementation, I don't like using "Description" for both the file-level description shown here and the record-level description we already have. But the implementation can be changed easily. That's not a big deal. I would say, "The field-body of the "Description" field SHALL contain a short description of the contents of the registry." > This would then apply to both registries. (Maybe some other sentence > needs to be amended too.) Note the introduction of the "SHALL"s above, > to make it proper standardese. Definitely, any such change would need to apply to both registries. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 12:24:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hla-0006vD-Bx; Mon, 15 Aug 2005 12:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hlZ-0006v8-2J for ltru@megatron.ietf.org; Mon, 15 Aug 2005 12:24:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11643 for ; Mon, 15 Aug 2005 12:24:46 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4iKi-0002pm-3l for ltru@ietf.org; Mon, 15 Aug 2005 13:01:09 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 09:24:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] comments in the registries ( was [psg.com #1099] WGLC add empty extension registry) Date: Mon, 15 Aug 2005 09:24:29 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B801@irvmbxw01.quest.com> Thread-Topic: [Ltru] comments in the registries ( was [psg.com #1099] WGLC add empty extension registry) Thread-Index: AcWhb2jDKr+n6KBNQO2gHtqW6ljGbgARFbhA From: "Addison Phillips" To: "Kent Karlsson" , "Randy Presuhn" X-OriginalArrivalTime: 15 Aug 2005 16:24:30.0115 (UTC) FILETIME=[D0063F30:01C5A1B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I hate it. I dislike the additional normative language, which is unnecessary (we = had a thread on that topic). MUSTardizing that section consistently = would produce an unreadable mess. Admittedly the comment in the empty extensions registration was = incorrect. Hmm... the idea of allowing comments into the file that are = not part of the records is a good one, I believe. Nearly every text = format I am familiar with provides a mechanism of this nature and their = uses are quite extensive. This would require a very small modification in the ABNF of record-jar, = as follows: -- was -- registry =3D record *("%%" CRLF record) record =3D 1*( field-name *SP ":" *SP field-body CRLF ) field-name =3D (ALPHA / DIGIT)[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] field-body =3D *(ASCCHAR/LWSP) ASCCHAR =3D %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 UNICHAR =3D "&#x" 2*6HEXDIG ";" -- -- proposed -- registry =3D *( 1*(separator) record) separator =3D "%%" *ASCCHAR CRLF record =3D 1*( field-name *SP ":" *SP field-body CRLF ) field-name =3D (ALPHA / DIGIT)[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] field-body =3D *(ASCCHAR/LWSP) ASCCHAR =3D %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 UNICHAR =3D "&#x" 2*6HEXDIG ";" -- We then add one sentence to explain this: -- Characters appearing on the same line as a separator are comments that = are not part of any particular record. -- This would allow (require, actually) the introducing comment, as well as = allowing editorial notes: %% IANA Language Subtag Registry File-Date: 2005-08-15 %% %% derived from ISO 639-1 %% Subtag: ... Comments? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Kent Karlsson > Sent: 2005?8?15? 0:59 > To: Randy Presuhn > Cc: LTRU Working Group > Subject: Re: [Ltru] [psg.com #1099] WGLC add empty extension registry >=20 > > I disagree. Section 3.6 says "[t]his registry MUST use the = record-jar > > format described by the ABNF in Section 3.1." That would give it a > > File-Date record. >=20 > Not directly by the ABNF, but by the text following it. >=20 > Since I like the file self declarations, I would suggest to > make the following text replacement, with obvious consequences: >=20 > ---------------------OLD TEXT----------------- > The first record in the file contains the single field whose = field-name is > "File-Date". > The field-body of this record contains the last modification date of = this > copy of the registry, > making it possible to compare different versions of the registry. The > registry on the IANA > website is the most current. Versions with an older date than that one = are > not up-to-date. >=20 > File-Date: 2004-06-28 > %% > ---------------------NEW TEXT----------------- > The first record in the file SHALL contain two fields whose = field-names > are "File-Date" and "Description". > The field-body of the "File-Date" field of this record SHALL contain = the > last modification date of this copy > of the registry. This makes it possible to compare different versions = of > the registry. The registry on the > IANA website is the most current. Versions with an older date than = that > one are not up-to-date. > The field-body of the "Description" field SHALL contain a short = comment on > what the content of the > registry is. For example, >=20 > File-Date: 2004-06-28 > Description: IANA Language subtag registry (see RFC XXXX) > ----------------------------------------- >=20 > This would then apply to both registries. (Maybe some other sentence = needs > to be amended too.) Note the introduction of the "SHALL"s above, to = make > it proper standardese. >=20 > /kent k >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 14:31:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jjm-0001HK-UA; Mon, 15 Aug 2005 14:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jjl-0001G4-Hh for ltru@megatron.ietf.org; Mon, 15 Aug 2005 14:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18285 for ; Mon, 15 Aug 2005 14:31:04 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4kIv-0006Eb-RO for ltru@ietf.org; Mon, 15 Aug 2005 15:07:27 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 11:30:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1098] WGLC distinguish subtagandextensionsregistries Date: Mon, 15 Aug 2005 11:30:47 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B8F3@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1098] WGLC distinguish subtagandextensionsregistries Thread-Index: AcWgKNKAnWtK3Je6RP+E81M4U1oO2gBnK6Pg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 15 Aug 2005 18:30:48.0154 (UTC) FILETIME=[74E33BA0:01C5A1C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I made these changes to my copy of draft-11. Some additional minor = word-smithing was necessary in the introduction to section 3. I have not yet modified the ABNF for record-jar (to permit the change in = section 3.7). I did update the references as requested in the other = thread(s) (to which I'll reply separately). NB> I ran the diff posted on the site before setting today's date and = restoring the author of the ISO standards to "International Organization = for Standardization". Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?13? 10:01 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #1098] WGLC distinguish > subtagandextensionsregistries >=20 > Hi - >=20 > As a technical contributor: >=20 > This looks ok to me, except that "REQUIRE" isn't a 2119 keyword. I = suggest: >=20 > Adoption of this document will also entails initialization of the = Language > Extension Registry described in Section 3.6. This registry SHALL be > initialized > with the following text: >=20 > I have a slight preference to put the initializing text in the = initial > registry draft, > rather than the registry draft. >=20 > Randy >=20 > ----- Original Message ----- > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working = Group" > > Sent: Saturday, August 13, 2005 9:04 AM > Subject: RE: [Ltru] [psg.com #1098] WGLC distinguish subtag > andextensionsregistries >=20 >=20 > To resolve this issue, I propose: >=20 > 1. A minor modification in section 2.2 (to say "Subtag Registry" the = first > time). >=20 > 2. A change in the title of section 3 (to say "Subtag Registry Format = and > Maintenance") >=20 > 3. A change in the title of section 3.6 (to "Extensions and Extensions > Registry") >=20 > 4. A change in the title of section 3.7 (to "Initialization of the > Registries") >=20 > 5. The modification of the first sentence in section 3.7 to say: "... = an > initial version of the Language Subtag Registry > containing..." >=20 > 6. The addition of this paragraph at the end of section 3.7: >=20 > - > Adoption of this document will also REQUIRE an initial version of the > Language Extension Registry described in Section 3.6. This > registry is initially expected to contain no records. It MUST be > initialized with the following text: >=20 > # Language Tag Extensions Registry (see RFC XXXX) > File-Date: 2005-08-13 > - >=20 > Addison > ... >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 14:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4k2C-0003QH-64; Mon, 15 Aug 2005 14:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4k27-0003MD-UW for ltru@megatron.ietf.org; Mon, 15 Aug 2005 14:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19119 for ; Mon, 15 Aug 2005 14:50:02 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4kbJ-0006ba-DP for ltru@ietf.org; Mon, 15 Aug 2005 15:26:25 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 11:49:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1095] continued discussion of references section Date: Mon, 15 Aug 2005 11:49:53 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B916@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1095] continued discussion of references section Thread-Index: AcWhN+tIYHePWvfSQ6ieSWXs6QSXbAAkiGqw From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 15 Aug 2005 18:49:54.0389 (UTC) FILETIME=[2018D050:01C5A1CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I made these changes exactly as Randy noted below and for the reasons = cited. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?14? 18:23 > To: ltru@ietf.org > Subject: [Ltru] [psg.com #1095] continued discussion of references = section >=20 > Hi - >=20 > (Note that I changed the subject line to something meaningful.) > As a technical contributor... >=20 > > From: "Kent Karlsson" > > To: > > Sent: Sunday, August 14, 2005 1:14 AM > > Subject: Re: [Ltru] Re: new editor's copy online > > > > I still find [RFC2047] in the list of normative references. > > I cannot find any reason whatsoever to have that as a > > *normative* reference. >=20 > Agreed. RFC 2047 appears to be a typical example of an informative > reference. >=20 > > Likewise do [RFC2434], [RFC2781], and [RFC3552] NOT belong in > > the *normative* references list (which I have pointed out > > several times before). >=20 > The reference to RFC 2434 is clearly normative, since in section 3.6 > it defines the process to be used for single-letter subtag = assignments. > Consequently, it shoudl stay in the normative references section. >=20 > I agree that the reference to RFC 2781 is clearly informative, since = it > is only cited in the context of an example. >=20 > RFC 3552 is one of those difficult borderline cases, and there are > reasonable > arguments both ways. However, I'm inclined to agree that it should be > treated > as an informative reference, rather than as a normative one, given the > level of > indirection in the context in which it is cited. >=20 > > The list of normative references should be kept at an absolute > > minimum. > > > > Can we please have the normative references list cleared up > > (i.e. minimised); it's not a purely editoral issue. > ... >=20 > To me this would mean moving 2047, 2781, and 3552 to the informative > references, but retaining 2434 in the normative ones. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 14:51:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4k3f-0003Xz-RA; Mon, 15 Aug 2005 14:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4k3e-0003Xu-AT for ltru@megatron.ietf.org; Mon, 15 Aug 2005 14:51:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19191 for ; Mon, 15 Aug 2005 14:51:36 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4kco-0006eO-Ja for ltru@ietf.org; Mon, 15 Aug 2005 15:27:59 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4k3a-0002ER-00 for ltru@ietf.org; Mon, 15 Aug 2005 14:51:34 -0400 Message-ID: <005101c5a1ca$8e9dd020$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C72B8F3@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #1098] WGLC distinguish subtagandextensionsregistries Date: Mon, 15 Aug 2005 11:52:59 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - It looks like we have a rough consensus how to handle issue #1098, so I've marked it "resolved" in the issue tracker at https://rt.psg.com/ (user and password "ietf"). Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 14:58:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kA9-0004Md-9l; Mon, 15 Aug 2005 14:58:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kA7-0004MY-Tg for ltru@megatron.ietf.org; Mon, 15 Aug 2005 14:58:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19475 for ; Mon, 15 Aug 2005 14:58:18 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4kjI-0006n6-DC for ltru@ietf.org; Mon, 15 Aug 2005 15:34:41 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4kA5-00048w-00 for ltru@ietf.org; Mon, 15 Aug 2005 14:58:17 -0400 Message-ID: <005801c5a1cb$7e9eda60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Mon, 15 Aug 2005 11:59:41 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] LTRU Milestones past due X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - We're behind schedule on all of our remaining milestones. Current: May 05 Submit registry structure draft for IETF Last Call Aug 05 Submit matching algorithms draft for IETF Last Call I propose that we ask our ADs to permit the following updates: Aug 05 Submit registry structure draft for IETF Last Call Oct 05 Submit matching algorithms draft for IETF Last Call I think these are realistic if we stop lilly-gilding. Objections? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:01:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kCt-0004l7-M0; Mon, 15 Aug 2005 15:01:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kCr-0004gh-A2 for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:01:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19684 for ; Mon, 15 Aug 2005 15:01:05 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4km0-0006sV-Dg for ltru@ietf.org; Mon, 15 Aug 2005 15:37:28 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 12:00:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] comments in the registries ( was [psg.com #1099] WGLC addempty extension registry) Date: Mon, 15 Aug 2005 12:00:51 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B929@irvmbxw01.quest.com> Thread-Topic: [Ltru] comments in the registries ( was [psg.com #1099] WGLC addempty extension registry) Thread-Index: AcWhb2jDKr+n6KBNQO2gHtqW6ljGbgARFbhAAAXke9A= From: "Addison Phillips" To: "Addison Phillips" , "Kent Karlsson" , "Randy Presuhn" X-OriginalArrivalTime: 15 Aug 2005 19:00:52.0510 (UTC) FILETIME=[A85E1BE0:01C5A1CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Note: a trip to the ABNF validator produces a minor change in the = proposed ABNF for record-jar: registry =3D *( 1*separator record ) separator =3D "%%" *ASCCHAR CRLF record =3D 1*( field-name *SP ":" *SP field-body CRLF ) field-name =3D (ALPHA / DIGIT) [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) = ] field-body =3D *(ASCCHAR/LWSP) ASCCHAR =3D %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 UNICHAR =3D "&#x" 2*6HEXDIG ";" Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: 2005?8?15? 9:24 > To: Kent Karlsson; Randy Presuhn > Cc: LTRU Working Group > Subject: RE: [Ltru] comments in the registries ( was [psg.com #1099] = WGLC > addempty extension registry) >=20 > I hate it. >=20 > I dislike the additional normative language, which is unnecessary (we = had > a thread on that topic). MUSTardizing that section consistently would > produce an unreadable mess. >=20 > Admittedly the comment in the empty extensions registration was = incorrect. > Hmm... the idea of allowing comments into the file that are not part = of > the records is a good one, I believe. Nearly every text format I am > familiar with provides a mechanism of this nature and their uses are = quite > extensive. >=20 > This would require a very small modification in the ABNF of = record-jar, as > follows: >=20 > -- was -- > registry =3D record *("%%" CRLF record) > record =3D 1*( field-name *SP ":" *SP field-body CRLF ) > field-name =3D (ALPHA / DIGIT)[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] > field-body =3D *(ASCCHAR/LWSP) > ASCCHAR =3D %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 > UNICHAR =3D "&#x" 2*6HEXDIG ";" > -- >=20 > -- proposed -- > registry =3D *( 1*(separator) record) > separator =3D "%%" *ASCCHAR CRLF > record =3D 1*( field-name *SP ":" *SP field-body CRLF ) > field-name =3D (ALPHA / DIGIT)[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] > field-body =3D *(ASCCHAR/LWSP) > ASCCHAR =3D %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 > UNICHAR =3D "&#x" 2*6HEXDIG ";" > -- >=20 > We then add one sentence to explain this: >=20 > -- > Characters appearing on the same line as a separator are comments that = are > not part of any particular record. > -- >=20 > This would allow (require, actually) the introducing comment, as well = as > allowing editorial notes: >=20 > %% IANA Language Subtag Registry > File-Date: 2005-08-15 > %% > %% derived from ISO 639-1 > %% > Subtag: ... >=20 >=20 > Comments? >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Kent Karlsson > > Sent: 2005?8?15? 0:59 > > To: Randy Presuhn > > Cc: LTRU Working Group > > Subject: Re: [Ltru] [psg.com #1099] WGLC add empty extension = registry > > > > > I disagree. Section 3.6 says "[t]his registry MUST use the = record-jar > > > format described by the ABNF in Section 3.1." That would give it = a > > > File-Date record. > > > > Not directly by the ABNF, but by the text following it. > > > > Since I like the file self declarations, I would suggest to > > make the following text replacement, with obvious consequences: > > > > ---------------------OLD TEXT----------------- > > The first record in the file contains the single field whose = field-name > is > > "File-Date". > > The field-body of this record contains the last modification date of > this > > copy of the registry, > > making it possible to compare different versions of the registry. = The > > registry on the IANA > > website is the most current. Versions with an older date than that = one > are > > not up-to-date. > > > > File-Date: 2004-06-28 > > %% > > ---------------------NEW TEXT----------------- > > The first record in the file SHALL contain two fields whose = field-names > > are "File-Date" and "Description". > > The field-body of the "File-Date" field of this record SHALL contain = the > > last modification date of this copy > > of the registry. This makes it possible to compare different = versions of > > the registry. The registry on the > > IANA website is the most current. Versions with an older date than = that > > one are not up-to-date. > > The field-body of the "Description" field SHALL contain a short = comment > on > > what the content of the > > registry is. For example, > > > > File-Date: 2004-06-28 > > Description: IANA Language subtag registry (see RFC XXXX) > > ----------------------------------------- > > > > This would then apply to both registries. (Maybe some other sentence > needs > > to be amended too.) Note the introduction of the "SHALL"s above, to = make > > it proper standardese. > > > > /kent k > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:01:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kCw-0004lo-RY; Mon, 15 Aug 2005 15:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kCs-0004kM-5A for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:01:10 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19690 for ; Mon, 15 Aug 2005 15:01:08 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4kAj-0003VY-IL for ltru@lists.ietf.org; Mon, 15 Aug 2005 20:58:57 +0200 Received: from c-180-160-193.hh.dial.de.ignite.net ([62.180.160.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 20:58:57 +0200 Received: from nobody by c-180-160-193.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 20:58:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 15 Aug 2005 20:51:50 +0200 Organization: Lines: 41 Message-ID: <4300E446.75C8@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72B801@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-193.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: comments in the registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I dislike the additional normative language, which is > unnecessary (we had a thread on that topic). Add me. Kent said "proper standardese", but the 2119 keywords are used for different degrees of (potential) trouble, they are not used to mark everything that is normative. > the idea of allowing comments into the file that are > not part of the records is a good one, I believe. [...] > registry = *( 1*(separator) record) > separator = "%%" *ASCCHAR CRLF I'm not convinced, we don't need "separator decorations" everywhere, or a hint in prose that the first separator "must" be special. Kent's idea "Description:" was clear, but this confuses Doug's implementation. You and others proposed XML for the registry, let's just copy an idea we all know, and add a "Title:" to the intro-record. Kent didn't mention it, do we have a mandatory order of fields per record anywhere ? Now after some months I *SHOULD* really know this, but admittedly I'm too lazy to check it now. Without a mandatory order the intro record could also have the form... Title: Extension tag registry as per RFC 3066bis File-Date: 2005-09-01 ...without "%%" as third line. There is no separator in the ABNF if there's only one record. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:11:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kMk-0005tt-Df; Mon, 15 Aug 2005 15:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kMj-0005tl-UR for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:11:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20601 for ; Mon, 15 Aug 2005 15:11:20 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4kvu-00075l-E0 for ltru@ietf.org; Mon, 15 Aug 2005 15:47:43 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4kMh-0007NU-00 for ltru@ietf.org; Mon, 15 Aug 2005 15:11:19 -0400 Message-ID: <007501c5a1cd$50bf2940$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Mon, 15 Aug 2005 12:12:43 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] [psg.com #1103] WGLC Add File-level Description field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > ------------------------------------------------------------------------- > This issue was raised in several related messages on issues #1098 and > #1099, including: > http://www1.ietf.org/mail-archive/web/ltru/current/msg03285.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg03284.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg03286.html > > The idea is that the ABNF and following text in section 3.1 should > result in both the subtag and the extension registries having > some additional, human-readable information describing the file > as a whole, in addition to the file-date field. Please include the issue number (#1103) in you subject line as you continue to discuss this issue. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:16:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kRa-0006Qn-4F; Mon, 15 Aug 2005 15:16:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kRY-0006Qi-AZ for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21068 for ; Mon, 15 Aug 2005 15:16:18 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4l0j-0007DW-8j for ltru@ietf.org; Mon, 15 Aug 2005 15:52:42 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4kRW-0000uH-00 for ltru@ietf.org; Mon, 15 Aug 2005 15:16:18 -0400 Message-ID: <008201c5a1ce$030ac6e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 15 Aug 2005 12:17:42 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] [psg.com #1104] WGLC ensure that extension registry has File-Date X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > ------------------------------------------------------------------------- > Message > http://www1.ietf.org/mail-archive/web/ltru/current/msg03281.html > requests that it be made explicit that the extension registry > would have a File-Date field. Please include the issue number #1104 in your subject lines as you discuss this question. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:19:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kUH-0006lf-Hu; Mon, 15 Aug 2005 15:19:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kUG-0006kK-PF for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:19:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21311 for ; Mon, 15 Aug 2005 15:19:07 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4l3R-0007Ge-Is for ltru@ietf.org; Mon, 15 Aug 2005 15:55:30 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4kUE-0001X1-00 for ltru@ietf.org; Mon, 15 Aug 2005 15:19:06 -0400 Message-ID: <008b01c5a1ce$673fda60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001001c5a1a6$2bdd65a0$030aa8c0@DEWELL> Subject: Re: [Ltru] [psg.com #1103] WGLC Add File-level Description field Date: Mon, 15 Aug 2005 12:20:31 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - As a technical contributor, > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, August 15, 2005 7:32 AM > Subject: [Ltru] Proposed file-level "Description" field (was: Re: [psg.com#1099] WGLC add empty extension registry) ... > For reasons specific to my implementation, I don't like using > "Description" for both the file-level description shown here and the > record-level description we already have. But the implementation can be > changed easily. That's not a big deal. ... To avoid confusing humans, and not just tools, perhaps "File-Description" would make sense. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:26:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kba-0007co-AR; Mon, 15 Aug 2005 15:26:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kbY-0007cj-Gq for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:26:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21941 for ; Mon, 15 Aug 2005 15:26:38 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4lAj-0007aJ-4w for ltru@ietf.org; Mon, 15 Aug 2005 16:03:02 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4kbR-0003X0-00 for ltru@ietf.org; Mon, 15 Aug 2005 15:26:33 -0400 Message-ID: <009401c5a1cf$719c5460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [ltru][psg.com #1099] WGLC add empty extension registry Date: Mon, 15 Aug 2005 12:27:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Based on the discussion, it seems to me that the rough consensus on this item is to handle the addition of the "empty" (whatever that now means) extension registry entirely in the registry draft, and not in the initial registry draft. So, this ticket, which is on the initial registry, will be closed with a "rejected" status. The rest of the discussion of how to add the initial empty extension registry will be under issues #1098, #1103, and #1104 as needed. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:44:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ktH-00014x-DK; Mon, 15 Aug 2005 15:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ktG-00014s-Qn for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22743 for ; Mon, 15 Aug 2005 15:44:57 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4lSR-0007y0-Rj for ltru@ietf.org; Mon, 15 Aug 2005 16:21:21 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 12:44:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1103] WGLC Add File-level Description field Date: Mon, 15 Aug 2005 12:44:43 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B97A@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1103] WGLC Add File-level Description field Thread-Index: AcWhzUDAWWuG2ef9T5y5heAyYaGsgQAA7MsA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 15 Aug 2005 19:44:43.0941 (UTC) FILETIME=[C8D29D50:01C5A1D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org In response to Frank's email... There is no explicit field ordering in a record. We can provide a file description as a field or as a comment. I feel = that this type of information is not actual data and thus shouldn't be = inside a record. Other such information may exist or prove useful. Why = not provide for comments in the file format. I note that our reference = to record-jar says this nearby: Use # as an introducer for comments. It is good to have a way to = embed annotations and comments in data files. It's best if they're = actually part of the file structure, and so will be preserved by tools = that know its format. For comments that are not preserved during = parsing, # is the conventional start character. In any case, I'm not religious about it. "File-Description" will do it = in this singular case (although I'll have to add a whole paragraph about = it instead of just saying "here is what a comment looks like" and = letting Doug deal with writing the comment) Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?15? 12:13 > To: LTRU Working Group > Subject: [Ltru] [psg.com #1103] WGLC Add File-level Description field >=20 > Hi - >=20 > > = ------------------------------------------------------------------------ > - > > This issue was raised in several related messages on issues #1098 = and > > #1099, including: > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03285.html > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03284.html > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03286.html > > > > The idea is that the ABNF and following text in section 3.1 should > > result in both the subtag and the extension registries having > > some additional, human-readable information describing the file > > as a whole, in addition to the file-date field. >=20 > Please include the issue number (#1103) in you subject line as you > continue to discuss this issue. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:46:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kuT-0001Dh-Vt; Mon, 15 Aug 2005 15:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kuS-0001DZ-HJ for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:46:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22802 for ; Mon, 15 Aug 2005 15:46:10 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4lTe-0007zT-Oj for ltru@ietf.org; Mon, 15 Aug 2005 16:22:35 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 12:46:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1104] WGLC ensure that extension registry hasFile-Date Date: Mon, 15 Aug 2005 12:46:02 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72B97F@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1104] WGLC ensure that extension registry hasFile-Date Thread-Index: AcWhzgZd0p1BjF+BStqror/smFKlUgAA8esw From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 15 Aug 2005 19:46:03.0346 (UTC) FILETIME=[F826DB20:01C5A1D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I don't know what this item is. If you mean this to be the "initial the = registry this way" paragraph I already inserted, I think you can mark = this resolved pace our dealing with the comment at the top of the file = (which has its own issue number #1103) Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?15? 12:18 > To: LTRU Working Group > Subject: [Ltru] [psg.com #1104] WGLC ensure that extension registry > hasFile-Date >=20 > Hi - >=20 > > = ------------------------------------------------------------------------ > - > > Message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03281.html > > requests that it be made explicit that the extension registry > > would have a File-Date field. >=20 > Please include the issue number #1104 in your subject lines as you > discuss this question. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 15:56:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4l4H-0002x9-Jm; Mon, 15 Aug 2005 15:56:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4l4G-0002wp-Lb for ltru@megatron.ietf.org; Mon, 15 Aug 2005 15:56:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24165 for ; Mon, 15 Aug 2005 15:56:18 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ldQ-00005a-EY for ltru@ietf.org; Mon, 15 Aug 2005 16:32:42 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4l48-0001b8-00 for ltru@ietf.org; Mon, 15 Aug 2005 15:56:12 -0400 Message-ID: <001a01c5a1d3$967441e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C72B97F@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #1104] WGLC ensure that extension registry hasFile-Date Date: Mon, 15 Aug 2005 12:57:04 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - If there are no objections, I'll mark this item "resolved". Randy, ltru co-chair --------------------------- From: "Addison Phillips" To: "Randy Presuhn" ; "LTRU Working Group" Sent: Monday, August 15, 2005 12:46 PM Subject: RE: [Ltru] [psg.com #1104] WGLC ensure that extension registry hasFile-Date I don't know what this item is. If you mean this to be the "initial the registry this way" paragraph I already inserted, I think you can mark this resolved pace our dealing with the comment at the top of the file (which has its own issue number #1103) Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: 2005?8?15? 12:18 > To: LTRU Working Group > Subject: [Ltru] [psg.com #1104] WGLC ensure that extension registry > hasFile-Date > > Hi - > > > ------------------------------------------------------------------------ > - > > Message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg03281.html > > requests that it be made explicit that the extension registry > > would have a File-Date field. > > Please include the issue number #1104 in your subject lines as you > discuss this question. > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 16:33:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4leU-0004Xr-Gb; Mon, 15 Aug 2005 16:33:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4leT-0004Xd-T9 for ltru@megatron.ietf.org; Mon, 15 Aug 2005 16:33:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03264 for ; Mon, 15 Aug 2005 16:33:43 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4mDf-0003YX-Br for ltru@ietf.org; Mon, 15 Aug 2005 17:10:08 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Mon, 15 Aug 2005 20:33:23 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0ILA002HL6F3E2@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Mon, 15 Aug 2005 21:33:03 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Mon, 15 Aug 2005 21:33:02 +0100 Date: Mon, 15 Aug 2005 21:33:02 +0100 From: Misha Wolf Subject: RE: [Ltru] LTRU Milestones past due To: LTRU Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF78045236CE@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] LTRU Milestones past due Thread-Index: AcWhy5ufyo2ELgZVQqi2qZ+TNGVfhwADMuBA content-class: urn:content-classes:message X-OriginalArrivalTime: 15 Aug 2005 20:33:02.0492 (UTC) FILETIME=[887E65C0:01C5A1D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > I propose that we ask our ADs to permit the following updates: > Aug 05 Submit registry structure draft for IETF Last Call Should that be Sep 05? Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 16:41:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lmI-000662-09; Mon, 15 Aug 2005 16:41:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lm8-00065e-Da for ltru@megatron.ietf.org; Mon, 15 Aug 2005 16:41:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03760 for ; Mon, 15 Aug 2005 16:41:37 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4lkF-0002mW-GF for ltru@lists.ietf.org; Mon, 15 Aug 2005 22:39:43 +0200 Received: from c-180-160-193.hh.dial.de.ignite.net ([62.180.160.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 22:39:43 +0200 Received: from nobody by c-180-160-193.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 22:39:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 15 Aug 2005 22:37:15 +0200 Organization: Lines: 26 Message-ID: <4300FCFB.28A@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72B97A@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-193.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I note that our reference to record-jar says this nearby: >| Use # as an introducer for comments. It is good to have >| a way to embed annotations and comments in data files. And is that in a variant were lines starting with "#" are also used like our "%%" ? You wanted to specify a general ABNF for "record-jar plus UTF-8". Now that you have done this I'm reluctant to destroy it. If you say that it's still in the spirit of your original idea it's okay, but if you only do it for "lilly-gilding" as Randy said it's dubious. > In any case, I'm not religious about it. Nor me. If you do it you can also add a dummy "%%" after the File-Date of the "empty" extension registry. It's more work for Doug if he invents some kind of "sub- titles" for the various sections of the initial registry. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 17:02:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4m64-0000RR-II; Mon, 15 Aug 2005 17:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4m60-0000PD-Ba for ltru@megatron.ietf.org; Mon, 15 Aug 2005 17:02:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04543 for ; Mon, 15 Aug 2005 17:02:09 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4mfA-0004BW-SF for ltru@ietf.org; Mon, 15 Aug 2005 17:38:35 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4m5s-0001GJ-00 for ltru@ietf.org; Mon, 15 Aug 2005 17:02:04 -0400 Message-ID: <082a01c5a1dc$c9de6700$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <1987416CA83AC7499AC772F92E2DBF78045236CE@LONSMSXM02.emea.ime.reuters.com> Subject: Re: [Ltru] LTRU Milestones past due Date: Mon, 15 Aug 2005 14:02:37 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Misha Wolf" > To: "LTRU Working Group" > Sent: Monday, August 15, 2005 1:33 PM > Subject: RE: [Ltru] LTRU Milestones past due > > > I propose that we ask our ADs to permit the following updates: > > Aug 05 Submit registry structure draft for IETF Last Call > > Should that be Sep 05? ... I hope not, but we're not going to get there until this WG decides that the drafts are good enough to request publication. The current discussion of ABNF changes worries me that we might be on the verge of needing a third WG last call, though that decision is up to the co-chairs' discretion. As a technical contributor, I think we passed the point of diminishing returns some time ago. I've been in standards long enough to realize that any non-trivial specification will probably have errors and benefit from clearer text, but I've also seen too many documents where too much time has been spent on items that really have no impact at all on the interoperability of implementations. The WG needs to ask itself: - are the procedures for running the registry sufficiently clear so that IANA will be able to carry them out? - are the procedures for requesting the registration of new tags sufficiently clear so that registrants will be able to provide the necessary information to ietf-languages@iana.org? - is the syntax and semantics of language tags sufficiently well specified to address the requirements stated in the WG charter? I believe the answer to all of these is "yes", and has been for quite some time. As a co-chair, though we can set deadlines for WG last calls, if the WG decides to address some in-scope issue, it is better in my opinion to deal with it in the WG last call, rather than risk its resurrection in IETF last call, even if in my technical judgement the issue does not warrant the delay. Of course, by dallying like this, we run the risk that our ADs might shut us down for failure to meet our milestones. I've seen this happen in the Operations & Management area, so I know that this is not merely a theoretical possibility. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 17:11:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mF6-00028Y-4W; Mon, 15 Aug 2005 17:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mF4-00028T-EH for ltru@megatron.ietf.org; Mon, 15 Aug 2005 17:11:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04878 for ; Mon, 15 Aug 2005 17:11:32 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4moG-0004MM-4u for ltru@ietf.org; Mon, 15 Aug 2005 17:47:57 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 14:11:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field Date: Mon, 15 Aug 2005 14:11:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BA38@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field Thread-Index: AcWh2dNgoXVfe975QsSMHwtU/wBIIAAA2hSw X-Priority: 1 Priority: Urgent Importance: high From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 15 Aug 2005 21:11:18.0281 (UTC) FILETIME=[E0E3FF90:01C5A1DD] X-Spam-Score: 1.3 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Based on Randy's email back to Misha, I would say: let's reject this = issue outright. We don't need a human readable comment in the header of = either file. Adding either comment syntax or a File-Description field = will require changes to the text (neither of which I think is very = substantial, since they both are about providing a single human-readable = comment in the top of the file). To deal with the extensions registry we can put this paragraph in = instead of the text for the registry: -- An initial version of the Language Extension Registry described in is also needed. The Language Extension = Registry SHALL be initialized with a single record containing a single = field of type "File-Date" as a placeholder for future assignments. -- That way we can be done. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?8?15? 13:37 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description = field >=20 > Addison Phillips wrote: >=20 > > I note that our reference to record-jar says this nearby: >=20 > >| Use # as an introducer for comments. It is good to have > >| a way to embed annotations and comments in data files. >=20 > And is that in a variant were lines starting with "#" are > also used like our "%%" ? You wanted to specify a general > ABNF for "record-jar plus UTF-8". Now that you have done > this I'm reluctant to destroy it. >=20 > If you say that it's still in the spirit of your original > idea it's okay, but if you only do it for "lilly-gilding" > as Randy said it's dubious. >=20 > > In any case, I'm not religious about it. >=20 > Nor me. If you do it you can also add a dummy "%%" after > the File-Date of the "empty" extension registry. >=20 > It's more work for Doug if he invents some kind of "sub- > titles" for the various sections of the initial registry. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 17:19:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mN6-0003Ue-Cm; Mon, 15 Aug 2005 17:19:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mN5-0003UZ-BP for ltru@megatron.ietf.org; Mon, 15 Aug 2005 17:19:51 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05226 for ; Mon, 15 Aug 2005 17:19:48 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4mLv-0004HQ-4E for ltru@lists.ietf.org; Mon, 15 Aug 2005 23:18:39 +0200 Received: from c-180-160-193.hh.dial.de.ignite.net ([62.180.160.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 23:18:39 +0200 Received: from nobody by c-180-160-193.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 23:18:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 15 Aug 2005 23:16:58 +0200 Organization: Lines: 14 Message-ID: <4301064A.4355@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72B97A@irvmbxw01.quest.com> <4300FCFB.28A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-193.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > It's more work for Doug if he invents some kind of "sub- > titles" for the various sections of the initial registry. BTW, it's also more work for IANA if they try to follow the initial structure. At the moment they can simply add all new records at the end. Sorry Randy, but that could be a bit beyond "lilly-gilding", we never said that IANA should keep Doug's organization - therefore adding obscure "comments" suggesting a certain sort order might be A Bad Thing. Doug, please don't try it. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 17:29:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mW9-0004vY-Le; Mon, 15 Aug 2005 17:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mW7-0004vQ-Pn for ltru@megatron.ietf.org; Mon, 15 Aug 2005 17:29:12 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05544 for ; Mon, 15 Aug 2005 17:29:09 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4mUU-0006Ey-J0 for ltru@lists.ietf.org; Mon, 15 Aug 2005 23:27:30 +0200 Received: from c-180-160-193.hh.dial.de.ignite.net ([62.180.160.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 23:27:30 +0200 Received: from nobody by c-180-160-193.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2005 23:27:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 15 Aug 2005 23:26:25 +0200 Organization: Lines: 6 Message-ID: <43010881.5DAF@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BA38@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-193.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > That way we can be done. +1 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 17:44:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ml6-0007YC-5Z; Mon, 15 Aug 2005 17:44:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ml5-0007Xy-32 for ltru@megatron.ietf.org; Mon, 15 Aug 2005 17:44:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06270 for ; Mon, 15 Aug 2005 17:44:32 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4nKD-00058x-Cg for ltru@ietf.org; Mon, 15 Aug 2005 18:20:58 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 14:44:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field Date: Mon, 15 Aug 2005 14:44:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field Thread-Index: AcWh4MMdNv6QP8cfRtyIeLGjfggK9gAAVEJA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 15 Aug 2005 21:44:22.0490 (UTC) FILETIME=[7F9243A0:01C5A1E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org All of these changes are in the editor's copy, along with a fresh diff. Randy and Martin: we done now? This would be: #1103 reject, #1104 = accepted (resolved). Editor's Copies: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-11.txt http://www.inter-locale.com/ID/draft-ietf-ltru-registry-11.html Diff: http://www.inter-locale.com/ID/draft-registry-10-11-diff.html Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?8?15? 14:26 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description = field >=20 > Addison Phillips wrote: >=20 > > That way we can be done. >=20 > +1 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 18:35:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nYP-0007Ow-KD; Mon, 15 Aug 2005 18:35:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nYO-0007Oo-Uo for ltru@megatron.ietf.org; Mon, 15 Aug 2005 18:35:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09674 for ; Mon, 15 Aug 2005 18:35:34 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4o7b-0006H8-AX for ltru@ietf.org; Mon, 15 Aug 2005 19:12:00 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Aug 2005 15:35:25 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Aug 2005 15:35:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1096] "nb" versus "no" Date: Mon, 15 Aug 2005 15:35:24 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #1096] "nb" versus "no" Thread-Index: AcWfkx32Lve8m90fTdOs2lcHBYPWNwCVeBGg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 15 Aug 2005 22:35:25.0787 (UTC) FILETIME=[A1704AB0:01C5A1E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > > From: "Kent Karlsson" > > 1. 'no' should be deprecated in favor of 'nb'. That is, > > one should assume 'nb' if 'no' is used. > > > > 'no' is is (now) in theory a language group code, but all > > languages in that group have individual codes (nb and nn); > > not counting dialects. But effectively, in practice, 'nb' > > *replaces* 'no' ('nn' is much rarer than 'nb'). In ISO 639-3, nor (the alpha-3 equivalent to no) is considered a macrolanguage encompassing both nob and nno (equivalents to nb and nn). In theory, that *might* suggest that in 3066ter that we could recommend no-nob / no-nno be used. This is a special case, though, in two respects: the macrolanguage categories pre-exist ISO 639-3, and the macrolanguage categories have their own alpha-2 IDs. Thus, it seems reasonably to me that this set of categories might have exceptional handling. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 18:36:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nZf-0007VN-U7; Mon, 15 Aug 2005 18:36:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nZe-0007VF-7e for ltru@megatron.ietf.org; Mon, 15 Aug 2005 18:36:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09740 for ; Mon, 15 Aug 2005 18:36:51 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4nYM-0003e4-4m for ltru@lists.ietf.org; Tue, 16 Aug 2005 00:35:34 +0200 Received: from c-180-160-193.hh.dial.de.ignite.net ([62.180.160.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 00:35:34 +0200 Received: from nobody by c-180-160-193.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 00:35:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 16 Aug 2005 00:33:47 +0200 Organization: Lines: 34 Message-ID: <4301184B.4F3E@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-193.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] URN:ISBN (was:: [psg.com #1103] WGLC Add File-level Description field) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Randy and Martin: we done now? While they think about it; URN:ISBN is explained in RfC 3187. At the moment you have... [...] ...all in one line without spaces. I've tested this (once), you could try something like this: [...] For the hyphenation I _hope_ that I got... http://www.isbn.org/standards/home/isbn/international/hyphenation-instructions.asp ...right. But it's not too important, RfC 3187 says that the hyphens are ignored in comparisons. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 18:40:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nck-0007xq-Ui; Mon, 15 Aug 2005 18:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ncj-0007xe-IJ for ltru@megatron.ietf.org; Mon, 15 Aug 2005 18:40:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09913 for ; Mon, 15 Aug 2005 18:40:00 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4oBs-0006N2-SS for ltru@ietf.org; Mon, 15 Aug 2005 19:16:27 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 15:39:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1096] "nb" versus "no" Date: Mon, 15 Aug 2005 15:39:46 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BAC9@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1096] "nb" versus "no" Thread-Index: AcWfkx32Lve8m90fTdOs2lcHBYPWNwCVeBGgAABFfIA= From: "Addison Phillips" To: "Peter Constable" , "LTRU Working Group" X-OriginalArrivalTime: 15 Aug 2005 22:39:46.0869 (UTC) FILETIME=[3D0E3E50:01C5A1EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org ... in RFC 3066ter. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: 2005?8?15? 15:35 > To: LTRU Working Group > Subject: RE: [Ltru] [psg.com #1096] "nb" versus "no" >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of > > Randy Presuhn >=20 >=20 > > > From: "Kent Karlsson" >=20 > > > 1. 'no' should be deprecated in favor of 'nb'. That is, > > > one should assume 'nb' if 'no' is used. > > > > > > 'no' is is (now) in theory a language group code, but all > > > languages in that group have individual codes (nb and nn); > > > not counting dialects. But effectively, in practice, 'nb' > > > *replaces* 'no' ('nn' is much rarer than 'nb'). >=20 > In ISO 639-3, nor (the alpha-3 equivalent to no) is considered a > macrolanguage encompassing both nob and nno (equivalents to nb and = nn). > In theory, that *might* suggest that in 3066ter that we could = recommend > no-nob / no-nno be used. This is a special case, though, in two > respects: the macrolanguage categories pre-exist ISO 639-3, and the > macrolanguage categories have their own alpha-2 IDs. Thus, it seems > reasonably to me that this set of categories might have exceptional > handling. >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 18:50:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nn9-0001Kc-BP; Mon, 15 Aug 2005 18:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nn8-0001KX-Uu for ltru@megatron.ietf.org; Mon, 15 Aug 2005 18:50:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10346 for ; Mon, 15 Aug 2005 18:50:47 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4oML-0006b1-FG for ltru@ietf.org; Mon, 15 Aug 2005 19:27:14 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4nms-0004Ul-00 for ltru@ietf.org; Mon, 15 Aug 2005 18:50:34 -0400 Message-ID: <003d01c5a1eb$f1aa8d40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> <4301184B.4F3E@xyzzy.claranet.de> Date: Mon, 15 Aug 2005 15:51:58 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Ltru] [psg.com #1095]] URN:ISBN X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I assume this was intended as continued commentary on issue #1095 on the references section. As a technical contributor, I suggest leaving this to the editors' discretion, as this is editorial in the extreme, and I can't see prolonging WG last call on this detail. Randy ----- Original Message ----- > From: "Frank Ellermann" > To: > Sent: Monday, August 15, 2005 3:33 PM > Subject: [Ltru] URN:ISBN (was:: [psg.com #1103] WGLC Add File-levelDescription field) ... > URN:ISBN is explained in RfC 3187. > > At the moment you have... > > > > [...] > > > > ...all in one line without spaces. I've tested this (once), > you could try something like this: > > > > [...] > > > > > For the hyphenation I _hope_ that I got... > > http://www.isbn.org/standards/home/isbn/international/hyphenation-instructions.asp > > ...right. But it's not too important, RfC 3187 says that the > hyphens are ignored in comparisons. > Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 18:50:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nnB-0001LQ-Gd; Mon, 15 Aug 2005 18:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nn9-0001Ke-Hz for ltru@megatron.ietf.org; Mon, 15 Aug 2005 18:50:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10349 for ; Mon, 15 Aug 2005 18:50:48 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4oMN-0006b4-7l for ltru@ietf.org; Mon, 15 Aug 2005 19:27:15 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 15:50:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] URN:ISBN (was:: [psg.com #1103] WGLC Add File-levelDescription field) Date: Mon, 15 Aug 2005 15:50:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BADA@irvmbxw01.quest.com> Thread-Topic: [Ltru] URN:ISBN (was:: [psg.com #1103] WGLC Add File-levelDescription field) Thread-Index: AcWh6gAUAnAkYHWcRyOGy7i92H/IDQAAEjKg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 15 Aug 2005 22:50:41.0579 (UTC) FILETIME=[C34B0FB0:01C5A1EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org You got the hyphenation correct. In a (very) past life I wrote POS and inventory management systems for = bookstores. I can hyphenate an ISBN by looking at it :-). I can add the ISBN and publisher to the reference, although I had hoped = we were really done....... (laughing) going to have to pull the bottle = of champagne back for five minutes. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?8?15? 15:34 > To: ltru@ietf.org > Subject: [Ltru] URN:ISBN (was:: [psg.com #1103] WGLC Add File- > levelDescription field) >=20 > Addison Phillips wrote: >=20 > > Randy and Martin: we done now? >=20 > While they think about it; >=20 > URN:ISBN is explained in RfC 3187. >=20 > At the moment you have... >=20 > > > [...] > > >=20 > ...all in one line without spaces. I've tested this (once), > you could try something like this: >=20 > > > [...] > > > >=20 > For the hyphenation I _hope_ that I got... >=20 > http://www.isbn.org/standards/home/isbn/international/hyphenation- > instructions.asp >=20 > ...right. But it's not too important, RfC 3187 says that the > hyphens are ignored in comparisons. > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 19:12:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4o7k-0004x7-1X; Mon, 15 Aug 2005 19:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4o7h-0004tB-Md for ltru@megatron.ietf.org; Mon, 15 Aug 2005 19:12:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11896 for ; Mon, 15 Aug 2005 19:12:02 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ogv-0007G1-P6 for ltru@ietf.org; Mon, 15 Aug 2005 19:48:29 -0400 Received: from h-64-105-34-228.snvacaid.dynamic.covad.net ([64.105.34.228] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4o7g-0001JU-00 for ltru@ietf.org; Mon, 15 Aug 2005 19:12:04 -0400 Message-ID: <007701c5a1ee$f284b940$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field Date: Mon, 15 Aug 2005 16:13:19 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Frank Ellermann" ; > Sent: Monday, August 15, 2005 2:44 PM > Subject: RE: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field ... > Randy and Martin: we done now? This would be: #1103 reject, #1104 accepted (resolved). ... I'm comfortable with marking #1104 "resolved", and have done so. I'd like to give others time to speak on the proposal to mark #1103 rejected, whether understood as adding a "FileDescription" field or a "#" convention for comments. I'll give folks until 10:00 a.m. (California time) on Tuesday, August 16 2005 for further comment. That will give all our active participants a chance to comment on this, since at least some of the Europeans are probably asleep right now. The presumption will be that the issue #1103 would be rejected due to lack of rough consensus support. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 19:14:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4oA9-0005eM-3k; Mon, 15 Aug 2005 19:14:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4oA7-0005e9-OI for ltru@megatron.ietf.org; Mon, 15 Aug 2005 19:14:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12145 for ; Mon, 15 Aug 2005 19:14:32 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ojJ-0007M2-PF for ltru@ietf.org; Mon, 15 Aug 2005 19:51:00 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Aug 2005 16:14:23 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Aug 2005 16:14:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] LTRU Milestones past due Date: Mon, 15 Aug 2005 16:14:22 -0700 Message-ID: Thread-Topic: [Ltru] LTRU Milestones past due Thread-Index: AcWh3KzXSVVZ6JRTSbeq8mBtssQdNQAEj/3A From: "Peter Constable" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 15 Aug 2005 23:14:23.0670 (UTC) FILETIME=[12ECED60:01C5A1EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > The WG needs to ask itself: > - are the procedures for running the registry sufficiently clear so > that IANA will be able to carry them out? > - are the procedures for requesting the registration of new tags > sufficiently clear so that registrants will be able to provide the > necessary information to ietf-languages@iana.org? > - is the syntax and semantics of language tags sufficiently well > specified to address the requirements stated in the WG charter? >=20 > I believe the answer to all of these is "yes", and has been for quite > some time. +1 Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 20:56:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pkl-0004kW-Cq; Mon, 15 Aug 2005 20:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pkj-0004kD-RV for ltru@megatron.ietf.org; Mon, 15 Aug 2005 20:56:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17103 for ; Mon, 15 Aug 2005 20:56:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4qJy-0001G8-GQ for ltru@ietf.org; Mon, 15 Aug 2005 21:32:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E4pke-0006bm-OI; Mon, 15 Aug 2005 17:56:25 -0700 Message-Id: <6.2.1.2.2.20050816011043.03bc8910@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 16 Aug 2005 01:22:19 +0200 To: "Addison Phillips" , "Peter Constable" , "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] [psg.com #1096] "nb" versus "no" In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C72BAC9@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C72BAC9@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 00:39 16/08/2005, Addison Phillips wrote: >... in RFC 3066ter. By 3066 AD? So interested in restricting the 3066 ABNF that you cannot think how to support this without needing another RFC ... Why not just to foresee it now (at three years at least the Draft)? I do not see your problem? Obviously I am biaised: I want to favor the best interests of the users. There is an obvious COI. Take care. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 20:56:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pkl-0004ku-J3; Mon, 15 Aug 2005 20:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pkk-0004kC-16 for ltru@megatron.ietf.org; Mon, 15 Aug 2005 20:56:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17104 for ; Mon, 15 Aug 2005 20:56:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4qJy-0001GD-GM for ltru@ietf.org; Mon, 15 Aug 2005 21:32:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E4pkh-0006bm-BX; Mon, 15 Aug 2005 17:56:27 -0700 Message-Id: <6.2.1.2.2.20050816022623.04c0bc00@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 16 Aug 2005 02:51:17 +0200 To: "Randy Presuhn" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field In-Reply-To: <007701c5a1ee$f284b940$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> <007701c5a1ee$f284b940$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 01:13 16/08/2005, Randy Presuhn said: >I'd like to give others time to speak on the proposal to mark #1103 >rejected, whether understood as adding a "FileDescription" field >or a "#" convention for comments. I'll give folks until 10:00 a.m. >(California time) on Tuesday, August 16 2005 for further comment. >That will give all our active participants a chance to comment on this, >since at least some of the Europeans are probably asleep right now. I obviously hate this. But it must be said. After consensus by exhaustion: this is exclusion by the clock! Difficult to better document an American (Californian?) oriented bias. Asians, Middle-East, Africans, etc. are not even considered! As if Drafts were a competition between American and European positions (as suggested by a WG Draft author), instead of a common work striving towards the best solutions for all. This attitude also denotes a childish confusion between an IETF-WG and a wooden horse toy. USA had Minute Men, they seem now to have Minute Last Calls. I am not to judge this, so I will not call for the resignation of the co-Chair. But I would think his apologies to all the members of this WG would be appropriate to maintain a decent image of the IETF. Sorry. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 20:56:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pkl-0004lI-Ot; Mon, 15 Aug 2005 20:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pkj-0004kE-Uq for ltru@megatron.ietf.org; Mon, 15 Aug 2005 20:56:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17106 for ; Mon, 15 Aug 2005 20:56:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4qJy-0001G6-GU for ltru@ietf.org; Mon, 15 Aug 2005 21:32:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E4pkd-0006bm-6V; Mon, 15 Aug 2005 17:56:23 -0700 Message-Id: <6.2.1.2.2.20050815212418.03b0f4e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 15 Aug 2005 21:37:26 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] rt.psg.fun In-Reply-To: <005101c5a1ca$8e9dd020$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C72B8F3@irvmbxw01.quest.com> <005101c5a1ca$8e9dd020$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.7 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Randy, The processus you use, if I am correct, is as follows: 1. there is a mail exchange which may lead to a request of change not approved by the authors 2. you insert it in a system you quote as http://rt.psg.com with a strange number and a new subject wording 3. you claim there is no support to the proposition and ask for comments 4. a few hours or a few days later on you claim the strange number resolved as opposed, asking people who object to address that unknown number case. I must say I do not have time to waste with this delaying system. You will not have it in appeal, so... But I thought I had to try it once to understand its mechnism. 1. I used the URL and the password. Took a lot of time. System busy? 2. got a proposition to enter something in a monkey-somethikng and a long menu where among others there was an "ltru" sequence. I clicked it. There is now 10 minutes that my browser is repeatedly blocked with the following URL, producing a blank page. https://rt.psg.com/Search/Listing.html?ValueOfStatus=open&ValueOfStatus=new&StatusOp=%3D&QueueOp=%3D&ValueOfQueue=45&RowsPerPage=50&NewSearch=1 I suggest that you only use your rt.psg.com system when relating with IESG. They will love it. Good trick anyway. All the best. jfc At 20:52 15/08/2005, Randy Presuhn wrote: >Hi - > >It looks like we have a rough consensus how to handle issue #1098, >so I've marked it "resolved" in the issue tracker at https://rt.psg.com/ >(user and password "ietf"). > >Randy, ltru co-chair > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 21:39:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4qQJ-0003Kp-Fh; Mon, 15 Aug 2005 21:39:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4qQH-0003KU-Ps for ltru@megatron.ietf.org; Mon, 15 Aug 2005 21:39:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18597 for ; Mon, 15 Aug 2005 21:39:24 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4qzV-00027Q-3X for ltru@ietf.org; Mon, 15 Aug 2005 22:15:51 -0400 Received: from h-68-165-4-72.snvacaid.dynamic.covad.net ([68.165.4.72] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4qQ4-0005b3-00 for ltru@ietf.org; Mon, 15 Aug 2005 21:39:12 -0400 Message-ID: <000001c5a203$7e2235e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> <007701c5a1ee$f284b940$7f1afea9@oemcomputer> <6.2.1.2.2.20050816022623.04c0bc00@mail.afrac.org> Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field Date: Mon, 15 Aug 2005 18:38:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "r&d afrac" > To: "Randy Presuhn" > Cc: ; "Scott Hollenbeck" > Sent: Monday, August 15, 2005 5:51 PM > Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field > > On 01:13 16/08/2005, Randy Presuhn said: > >I'd like to give others time to speak on the proposal to mark #1103 > >rejected, whether understood as adding a "FileDescription" field > >or a "#" convention for comments. I'll give folks until 10:00 a.m. > >(California time) on Tuesday, August 16 2005 for further comment. > >That will give all our active participants a chance to comment on this, > >since at least some of the Europeans are probably asleep right now. > > I obviously hate this. But it must be said. > > After consensus by exhaustion: this is exclusion by the clock! Difficult > to better document an American (Californian?) oriented bias. Asians, > Middle-East, Africans, etc. are not even considered! As if Drafts were a > competition between American and European positions (as suggested by a WG > Draft author), instead of a common work striving towards the best solutions > for all. This attitude also denotes a childish confusion between an IETF-WG > and a wooden horse toy. USA had Minute Men, they seem now to have Minute > Last Calls. > > I am not to judge this, so I will not call for the resignation of the > co-Chair. But I would think his apologies to all the members of this WG > would be appropriate to maintain a decent image of the IETF. ... I'll apologize to anyone on the list whose time zone lacks a 9am-5pm period overlapping the interval in question, since it was deliberately chosen to give everyone a reasonable chance to respond. Let's see, where would that be? Not the Americas, not Australia, not Asia, not Africa, not Europe, not even Antarctica. Useful comments from Remulac don't appear to be forthcoming, so I won't worry about them. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 22:18:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4r2E-00019b-0y; Mon, 15 Aug 2005 22:18:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4r2C-00019W-To for ltru@megatron.ietf.org; Mon, 15 Aug 2005 22:18:37 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00624 for ; Mon, 15 Aug 2005 22:18:34 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4r1C-0000zv-HK for ltru@lists.ietf.org; Tue, 16 Aug 2005 04:17:34 +0200 Received: from c-180-160-193.hh.dial.de.ignite.net ([62.180.160.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 04:17:34 +0200 Received: from nobody by c-180-160-193.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 04:17:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 16 Aug 2005 04:13:35 +0200 Organization: Lines: 38 Message-ID: <43014BCF.7662@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> <007701c5a1ee$f284b940$7f1afea9@oemcomputer> <6.2.1.2.2.20050816022623.04c0bc00@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-193.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org r&d afrac wrote: >> some of the Europeans are probably asleep right now. > I obviously hate this. But it must be said. Sigh. > Difficult to better document an American (Californian?) > oriented bias. Asians, Middle-East, Africans, etc. are > not even considered! | From: "Randy Presuhn" | Date: Mon, 15 Aug 2005 16:13:19 -0700 ..................................^^^^^ Seven hours away from GMT. 10:00am in his local time is 10:00 in his local time, is 17:00 GMT, is 19:00 our local time. That's about 16 hours from "now", and if somebody sleeps for 16 hours he has more pressing problems than trouble ticket #1103 about "LTRU separator decorations". > This attitude also denotes a childish confusion between > an IETF-WG and a wooden horse toy. You're crazy. All you need is a simple bookmark, take one of mine: http://nist.time.gov/ http://tycho.usno.navy.mil/cgi-bin/dater.sh http://www.timeanddate.com/worldclock/custom.html?cities=103,18,165,61,307,352,397,237&fla=1&fti=503&fds=503 > apologies to all the members of this WG would be > appropriate to maintain a decent image of the IETF. That's a hopeless case, some IETF members are unable to add 7+2 to a given local time, it can't get worse. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 22:45:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4rS1-0005Ng-1P; Mon, 15 Aug 2005 22:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4rRz-0005NX-KM for ltru@megatron.ietf.org; Mon, 15 Aug 2005 22:45:16 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01424 for ; Mon, 15 Aug 2005 22:45:13 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4rQw-0005Az-39 for ltru@lists.ietf.org; Tue, 16 Aug 2005 04:44:10 +0200 Received: from c-180-160-193.hh.dial.de.ignite.net ([62.180.160.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 04:44:10 +0200 Received: from nobody by c-180-160-193.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 04:44:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 16 Aug 2005 04:42:43 +0200 Organization: Lines: 6 Message-ID: <430152A3.9FA@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> <007701c5a1ee$f284b940$7f1afea9@oemcomputer> <6.2.1.2.2.20050816022623.04c0bc00@mail.afrac.org> <43014BCF.7662@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-193.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Timeout X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > http://tycho.usno.navy.mil/cgi-bin/dater.sh Screw that, it's broken, here's a better link: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 23:25:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4s5N-0003Vq-EY; Mon, 15 Aug 2005 23:25:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4s5L-0003Vi-Uc for ltru@megatron.ietf.org; Mon, 15 Aug 2005 23:25:56 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02891 for ; Mon, 15 Aug 2005 23:25:53 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050816032524.TAEW19267.mta10.adelphia.net@DEWELL> for ; Mon, 15 Aug 2005 23:25:24 -0400 Message-ID: <000a01c5a212$1c33e040$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050815190425.ZLIQ6870.mta1.adelphia.net@megatron.ietf.org> Date: Mon, 15 Aug 2005 20:25:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: comments in the registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > This would require a very small modification in the ABNF of record- > jar, as follows: > > -- was -- > registry = record *("%%" CRLF record) > ... > -- proposed -- > registry = *( 1*(separator) record) > separator = "%%" *ASCCHAR CRLF > ... I realize the core issue that this was supposed to solve is in line to be solved in a different way, but I did want to point out that I would have opposed any change that *required* a %% comment before the first record. Such a thing should always be optional. (Perhaps this belongs on the record-jar mailing list, which is a bit less active than this one. :-) -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 23:36:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sFp-0005bF-W3; Mon, 15 Aug 2005 23:36:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sFo-0005b7-NQ for ltru@megatron.ietf.org; Mon, 15 Aug 2005 23:36:44 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03304 for ; Mon, 15 Aug 2005 23:36:42 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050816033609.TNXE19267.mta10.adelphia.net@DEWELL> for ; Mon, 15 Aug 2005 23:36:09 -0400 Message-ID: <001101c5a213$99a171e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050815190425.ZLIQ6870.mta1.adelphia.net@megatron.ietf.org> Date: Mon, 15 Aug 2005 20:35:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: LTRU Milestones past due X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I propose that we ask our ADs to permit the following updates: > Aug 05 Submit registry structure draft for IETF Last Call > Oct 05 Submit matching algorithms draft for IETF Last Call > > I think these are realistic if we stop lilly-gilding. To help reduce the lily-gilding phenomenon, I'd like to ask the co-chairs to adopt the following guidelines: 1. ABNF No further requests to change the ABNF in draft-registry or draft-matching should be entertained unless it can be demonstrated that the existing ABNF (a) contradicts the text of the draft, (b) fails when run through a validator, or (c) must be changed to reflect a new technical decision (which we should not be having at this point anyway). Changes to the ABNF for cosmetic reasons should be discouraged. "Contradiction" between text and ABNF refers only to context-free syntax. 2. References All requests to add or delete references, change them from Normative to Informative status or vice versa, or change their format or style should be directed to the co-chair(s), not the editors, and should contain proposed replacement text, preferably in xml2rfc format. All changes need to be at the direction of the co-chair(s). -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 23:39:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sIp-000627-61; Mon, 15 Aug 2005 23:39:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sIn-00061x-3X for ltru@megatron.ietf.org; Mon, 15 Aug 2005 23:39:49 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03392 for ; Mon, 15 Aug 2005 23:39:46 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050816033913.PLOB14360.mta13.adelphia.net@DEWELL> for ; Mon, 15 Aug 2005 23:39:13 -0400 Message-ID: <001601c5a214$0c049640$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050815190425.ZLIQ6870.mta1.adelphia.net@megatron.ietf.org> Date: Mon, 15 Aug 2005 20:39:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: comments in the registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > Kent's idea "Description:" was clear, but this confuses > Doug's implementation. I did say that it was not a big deal to tweak my implementation, if the group decided to go ahead with the file-level "Description" field. Probably I should not have mentioned it at all. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 15 23:47:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sPy-0007Tv-Id; Mon, 15 Aug 2005 23:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sPx-0007TT-Ku for ltru@megatron.ietf.org; Mon, 15 Aug 2005 23:47:13 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03631 for ; Mon, 15 Aug 2005 23:47:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050816034640.CNVW24042.mta11.adelphia.net@DEWELL> for ; Mon, 15 Aug 2005 23:46:40 -0400 Message-ID: <001f01c5a215$16504760$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050815231347.EQUB20176.mta3.adelphia.net@megatron.ietf.org> Date: Mon, 15 Aug 2005 20:46:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Based on Randy's email back to Misha, I would say: let's reject this > issue outright. We don't need a human readable comment in the header > of either file. Adding either comment syntax or a File-Description > field will require changes to the text (neither of which I think is > very substantial, since they both are about providing a single human- > readable comment in the top of the file). > > To deal with the extensions registry we can put this paragraph in > instead of the text for the registry: > > -- > An initial version of the Language Extension Registry described in > is also needed. The Language > Extension Registry SHALL be initialized with a single record > containing a single field of type "File-Date" as a placeholder for > future assignments. > -- > > That way we can be done. Sounds good to me. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 00:07:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sjj-0002fv-CM; Tue, 16 Aug 2005 00:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sji-0002fq-NH for ltru@megatron.ietf.org; Tue, 16 Aug 2005 00:07:38 -0400 Received: from mta3.adelphia.net (mta3.adelphia.net [68.168.78.181]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04311 for ; Tue, 16 Aug 2005 00:07:35 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050816035349.IEPZ29002.mta9.adelphia.net@DEWELL> for ; Mon, 15 Aug 2005 23:53:49 -0400 Message-ID: <002401c5a216$15abfba0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050815231347.EQUB20176.mta3.adelphia.net@megatron.ietf.org> Date: Mon, 15 Aug 2005 20:53:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I'd like to give others time to speak on the proposal to mark #1103 > rejected, whether understood as adding a "FileDescription" field > or a "#" convention for comments. I'll give folks until 10:00 a.m. > (California time) on Tuesday, August 16 2005 for further comment. > That will give all our active participants a chance to comment on > this, since at least some of the Europeans are probably asleep right > now. And at least one of the Americans was unable to post to the list until now. > The presumption will be that the issue #1103 would be rejected > due to lack of rough consensus support. It might be nice to have these comments, but at this late stage, that's all they are -- "nice to have." Let's leave this particular lily alone. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 00:22:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4syT-0004u6-DU; Tue, 16 Aug 2005 00:22:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4syR-0004u1-OM for ltru@megatron.ietf.org; Tue, 16 Aug 2005 00:22:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04749 for ; Tue, 16 Aug 2005 00:22:48 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4tXi-0005GI-53 for ltru@ietf.org; Tue, 16 Aug 2005 00:59:18 -0400 Received: from h-68-165-3-47.snvacaid.dynamic.covad.net ([68.165.3.47] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E4syH-0006W0-00 for ltru@ietf.org; Tue, 16 Aug 2005 00:22:42 -0400 Message-ID: <000401c5a21a$560bf200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050815190425.ZLIQ6870.mta1.adelphia.net@megatron.ietf.org> <001101c5a213$99a171e0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: LTRU Milestones past due Date: Mon, 15 Aug 2005 21:24:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, August 15, 2005 8:35 PM > Subject: [Ltru] Re: LTRU Milestones past due > > Randy Presuhn wrote: > > > I propose that we ask our ADs to permit the following updates: > > Aug 05 Submit registry structure draft for IETF Last Call > > Oct 05 Submit matching algorithms draft for IETF Last Call > > > > I think these are realistic if we stop lilly-gilding. > > To help reduce the lily-gilding phenomenon, I'd like to ask the > co-chairs to adopt the following guidelines: > > 1. ABNF > > No further requests to change the ABNF in draft-registry or > draft-matching should be entertained unless it can be demonstrated that > the existing ABNF (a) contradicts the text of the draft, (b) fails when > run through a validator, or (c) must be changed to reflect a new > technical decision (which we should not be having at this point anyway). > Changes to the ABNF for cosmetic reasons should be discouraged. > "Contradiction" between text and ABNF refers only to context-free > syntax. > > 2. References > > All requests to add or delete references, change them from Normative to > Informative status or vice versa, or change their format or style should > be directed to the co-chair(s), not the editors, and should contain > proposed replacement text, preferably in xml2rfc format. All changes > need to be at the direction of the co-chair(s). ... Tempting though these suggestions might be, the Working Group is the responsible entity. The co-chairs' job is to guage consensus and to attend to other process-related functions. We can beg, cajole, and try to persuade, but if the working group clearly wants to do something and it's within the scope of our charter and not otherwise forbidden by IETF processes, we can't override it. Let's wrap up this part of our work so we can get on with the metching draft. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 00:54:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4tSl-00017p-17; Tue, 16 Aug 2005 00:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4tSf-00017S-5B for ltru@megatron.ietf.org; Tue, 16 Aug 2005 00:54:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06545 for ; Tue, 16 Aug 2005 00:54:02 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4u1u-00062x-0w for ltru@ietf.org; Tue, 16 Aug 2005 01:30:32 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 21:53:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: LTRU Milestones past due Date: Mon, 15 Aug 2005 21:53:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BB6E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: LTRU Milestones past due Thread-Index: AcWiGkNCd02JzGorTDmKREh6klJXZAAA47UA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 16 Aug 2005 04:53:42.0320 (UTC) FILETIME=[79A06300:01C5A21E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Based on today's discussion, I don't think anything is left over. I'm = patiently awaiting Randy and Martin declaring any additional changes to = draft-11.=20 A fine quality French champagne is in the refrigerator pending their = decision. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?15? 21:24 > To: LTRU Working Group > Subject: Re: [Ltru] Re: LTRU Milestones past due >=20 > Hi - >=20 > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Monday, August 15, 2005 8:35 PM > > Subject: [Ltru] Re: LTRU Milestones past due > > > > Randy Presuhn = wrote: > > > > > I propose that we ask our ADs to permit the following updates: > > > Aug 05 Submit registry structure draft for IETF Last Call > > > Oct 05 Submit matching algorithms draft for IETF Last Call > > > > > > I think these are realistic if we stop lilly-gilding. > > > > To help reduce the lily-gilding phenomenon, I'd like to ask the > > co-chairs to adopt the following guidelines: > > > > 1. ABNF > > > > No further requests to change the ABNF in draft-registry or > > draft-matching should be entertained unless it can be demonstrated = that > > the existing ABNF (a) contradicts the text of the draft, (b) fails = when > > run through a validator, or (c) must be changed to reflect a new > > technical decision (which we should not be having at this point = anyway). > > Changes to the ABNF for cosmetic reasons should be discouraged. > > "Contradiction" between text and ABNF refers only to context-free > > syntax. > > > > 2. References > > > > All requests to add or delete references, change them from Normative = to > > Informative status or vice versa, or change their format or style = should > > be directed to the co-chair(s), not the editors, and should contain > > proposed replacement text, preferably in xml2rfc format. All = changes > > need to be at the direction of the co-chair(s). > ... >=20 > Tempting though these suggestions might be, the Working Group is > the responsible entity. The co-chairs' job is to guage consensus > and to attend to other process-related functions. We can beg, cajole, > and try to persuade, but if the working group clearly wants to do > something and it's within the scope of our charter and not otherwise > forbidden by IETF processes, we can't override it. >=20 > Let's wrap up this part of our work so we can get on with the metching > draft. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 02:42:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4v9d-0006ru-LM; Tue, 16 Aug 2005 02:42:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4v9b-0006rh-Ia for ltru@megatron.ietf.org; Tue, 16 Aug 2005 02:42:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23914 for ; Tue, 16 Aug 2005 02:42:30 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4vis-00088x-Ca for ltru@ietf.org; Tue, 16 Aug 2005 03:18:59 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13ED8320099; Tue, 16 Aug 2005 08:42:18 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31683-01; Tue, 16 Aug 2005 08:42:14 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4224E32009A; Tue, 16 Aug 2005 08:42:13 +0200 (CEST) Date: Tue, 16 Aug 2005 08:32:04 +0200 From: Harald Tveit Alvestrand To: Randy Presuhn , LTRU Working Group Subject: Re: [Ltru] [psg.com #1096] "nb" versus "no" Message-ID: <3ED1103BB93E5D36ACA0CBA9@B50854F0A9192E8EC6CDA126> In-Reply-To: <003801c59f93$0f2acfc0$7f1afea9@oemcomputer> References: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlin k.net> <61590.83.248.26.202.1123243586.squirrel@webmail.chalmers.se> <003801c59f93$0f2acfc0$7f1afea9@oemcomputer> X-Mailer: Mulberry/4.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I support rejecting the change. The decision to standardize "nb" and "nn" without a viable theory of macrolanguages after "no" had been well established in industry was IMHO one of the most stupid things ISO 639 has done in recent history. We should not compound their error. And agreed - this is an ietf-languages matter, not an ltru matter, and is possible to fix later. Harald --On 12. august 2005 16:10 -0700 Randy Presuhn wrote: > Hi - > >> From: "Kent Karlsson" >> To: "Randy Presuhn" >> Cc: >> Sent: Friday, August 05, 2005 5:06 AM >> Subject: Re: [Ltru] Second WG last call on >> draft-ietf-ltru-initial-03.txt ends 2005-08-08 > ... >> 1. 'no' should be deprecated in favor of 'nb'. That is, >> one should assume 'nb' if 'no' is used. >> >> 'no' is is (now) in theory a language group code, but all >> languages in that group have individual codes (nb and nn); >> not counting dialects. But effectively, in practice, 'nb' >> *replaces* 'no' ('nn' is much rarer than 'nb'). >> >> But I guess this can be dealt with later on (I hope I did not >> miss any provision preventing such a fix). > ... > > Based on the even split of the discussion, let's not make any changes > here, and leave the issue to the ietf-languages@iana.org list. I've > created a ticket (issue number #1096) with a status of "rejected" for > this item. > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 02:59:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4vPf-0000X5-MD; Tue, 16 Aug 2005 02:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4vPd-0000Wm-W8 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 02:59:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24528 for ; Tue, 16 Aug 2005 02:59:04 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4vyu-0008VX-I6 for ltru@ietf.org; Tue, 16 Aug 2005 03:35:34 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j7G6wtpX022266 for ; Tue, 16 Aug 2005 09:58:55 +0300 (EEST) Message-ID: <43018EAE.5070106@kotus.fi> Date: Tue, 16 Aug 2005 09:58:54 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: LTRU Working Group Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field References: <20050815231347.EQUB20176.mta3.adelphia.net@megatron.ietf.org> <002401c5a216$15abfba0$030aa8c0@DEWELL> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org (As a European) I agree with this. Regards, Erkki I. Kolehmainen Doug Ewell wrote: > Randy Presuhn wrote: > > >>I'd like to give others time to speak on the proposal to mark #1103 >>rejected, whether understood as adding a "FileDescription" field >>or a "#" convention for comments. I'll give folks until 10:00 a.m. >>(California time) on Tuesday, August 16 2005 for further comment. >>That will give all our active participants a chance to comment on >>this, since at least some of the Europeans are probably asleep right >>now. >> > > And at least one of the Americans was unable to post to the list until > now. > > >>The presumption will be that the issue #1103 would be rejected >>due to lack of rough consensus support. >> > > It might be nice to have these comments, but at this late stage, that's > all they are -- "nice to have." Let's leave this particular lily alone. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 07:52:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zzG-0007Bu-FW; Tue, 16 Aug 2005 07:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zzE-0007Bo-GL for ltru@megatron.ietf.org; Tue, 16 Aug 2005 07:52:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04794 for ; Tue, 16 Aug 2005 07:52:07 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E50YW-0006tO-S4 for ltru@ietf.org; Tue, 16 Aug 2005 08:28:39 -0400 X-Medic-Info: 44dc.4301d362.0 6nbrjbhoeLSAJR65 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 0474C3FB3 for ; Tue, 16 Aug 2005 13:52:02 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Tue, 16 Aug 2005 13:52:02 +0200 (CEST) Message-ID: <63576.83.248.26.202.1124193122.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C72B583@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0C72B583@irvmbxw01.quest.com> Date: Tue, 16 Aug 2005 13:52:02 +0200 (CEST) Subject: RE: [Ltru] [psg.com #1097] ABNF cleanup in matching draft From: "Kent Karlsson" To: "LTRU Working Group" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Extension matching is a separate issue and may have arcane rules. > Draft-registry and draft-matching both say that. We can, of course, > including singletons into the ABNF, if anyone feels strongly about it. > > Modifying the matching ABNF requires adding wildcards in just the right > way. Here is what I have so far: :: Note that one comment below also refers to the -registry draft. > extended-language-range =3D range ; a range > / privateuse ; private use tag > / grandfathered ; grandfathered registrations :: Oddly this one got a strange name change for the lhs nonterminal. :: If we are to change the names of nonterminals whose formal language :: is changed, I'd suggest doing so more systematically (P for Pattern): ::Language-TagP =3D langtag-p :: / privateuse ; private use tag :: / grandfathered ; grandfathered registrations > range =3D (language > ["-" script] > ["-" region] > *("-" variant) > *("-" extension) > ["-" privateuse]) :: This one too got a strange name change for the lhs nonterminal. :: If we are to change the names of nonterminals whose formal language :: is changed, I'd suggest doing so more systematically. It also has :: "*("-" extension)" though Addison has removed the productions for :: the nonterminal "extension". Though still odd to me, if "extension" :: is not to be covered in any way, it must also be removed here. ::langtag-p =3D (language-p :: ["-" script-p] :: ["-" region-p] :: *("-" variant-p) :: ["-" privateuse]) > language =3D "*" ; wildcard or... > / (2*3ALPHA [ extlang ]) ; shortest ISO 639 code > / 4ALPHA ; reserved for future use > / 5*8ALPHA ; registered language subtag :: This one did not get a name change for the lhs nonterminal. :: But if we are to change the names of nonterminals whose formal languag= e :: is changed, I'd suggest doing so systematically, also for this one. :: Further, I like to have the wildcard as the last alternative (like it was). :: AND, the [] around extlang are superfluous, as I think Frank already :: pointed out FOR THE -REGISTRY DRAFT, with an "of course" from Addison. ::language-p =3D (2*3ALPHA extlang-p) ; shortest ISO 639 code :: / 4ALPHA ; reserved for future use :: / 5*8ALPHA ; registered language subtag :: / "*" ; wildcard > extlang =3D *2("-" 3ALPHA) ("-" ( 3ALPHA / "*")) > ; reserved for future use > ; wildcard can only appear > ; at the end :: This one did not get a name change for the lhs nonterminal. :: But if we are to change the names of nonterminals whose formal languag= e :: is changed, I'd suggest doing so systematically, also for this one. :: Further, I like to have the wildcard as a separate last alternative. ::extlang-p =3D *3("-" 3ALPHA) ; reserved for future use :: / *2("-" 3ALPHA) "-*" ; wildcard, can only appear :: ; at the end > script =3D "*" ; wildcard or... > / 4ALPHA ; ISO 15924 code :: This one did not get a name change for the lhs nonterminal. :: But if we are to change the names of nonterminals whose formal languag= e :: is changed, I'd suggest doing so systematically, also for this one. :: Further, I like to have the wildcard as the last alternative (as it wa= s). ::script-p =3D 4ALPHA ; ISO 15924 code :: / "*" ; wildcard > region =3D "*" ; wildcard or... > / 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN M.49 code :: This one did not get a name change for the lhs nonterminal. :: But if we are to change the names of nonterminals whose formal languag= e :: is changed, I'd suggest doing so systematically, also for this one. :: Further, I like to have the wildcard as the last alternative (as it wa= s). ::region-p =3D 2ALPHA ; ISO 3166 code :: / 3DIGIT ; UN M.49 code :: / "*" ; wildcard > variant =3D "*" ; wildcard or... > / 5*8alphanum ; registered variants > / (DIGIT 3alphanum) :: This one did not get a name change for the lhs nonterminal. :: But if we are to change the names of nonterminals whose formal languag= e :: is changed, I'd suggest doing so systematically, also for this one. :: Further, I like to have the wildcard as the last alternative (as it wa= s). ::variant-p =3D 5*8alphanum ; registered variants :: / (DIGIT 3alphanum) :: / "*" ; wildcard > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) > > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > ; grandfathered registration > ; Note: i is the only singleton > ; that starts a grandfathered tag > > alphanum =3D (ALPHA / DIGIT) ; letters and numbers /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 08:46:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50pz-0007X7-C3; Tue, 16 Aug 2005 08:46:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50px-0007Wq-Mi for ltru@megatron.ietf.org; Tue, 16 Aug 2005 08:46:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07815 for ; Tue, 16 Aug 2005 08:46:36 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E51PF-0008Hi-Ud for ltru@ietf.org; Tue, 16 Aug 2005 09:23:09 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E50pq-0008L0-Hu; Tue, 16 Aug 2005 05:46:30 -0700 Message-Id: <6.2.1.2.2.20050816133320.04bb1520@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 16 Aug 2005 13:37:29 +0200 To: Harald Tveit Alvestrand , Randy Presuhn , LTRU Working Group From: r&d afrac Subject: Re: [Ltru] [psg.com #1096] "nb" versus "no" In-Reply-To: <3ED1103BB93E5D36ACA0CBA9@B50854F0A9192E8EC6CDA126> References: <17125119.1123146692737.JavaMail.root@wamui-cedar.atl.sa.earthlin k.net> <61590.83.248.26.202.1123243586.squirrel@webmail.chalmers.se> <003801c59f93$0f2acfc0$7f1afea9@oemcomputer> <3ED1103BB93E5D36ACA0CBA9@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 08:32 16/08/2005, Harald Tveit Alvestrand wrote: >And agreed - this is an ietf-languages matter, not an ltru matter, and is >possible to fix later. I am sorry to disagree on two points: - if you mean this is an "ietf-languages@alverstrand.no" matter. - at this stage the ietf-languages@iana.org is not multimode and fully multimedia oriented what still need to be corrected. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 08:46:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50py-0007Wv-Vf; Tue, 16 Aug 2005 08:46:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50pw-0007Wl-TR for ltru@megatron.ietf.org; Tue, 16 Aug 2005 08:46:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07812 for ; Tue, 16 Aug 2005 08:46:35 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E51PF-0008Hh-Uh for ltru@ietf.org; Tue, 16 Aug 2005 09:23:08 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E50pp-0008L0-3L; Tue, 16 Aug 2005 05:46:29 -0700 Message-Id: <6.2.1.2.2.20050816120148.04bece10@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 16 Aug 2005 13:19:55 +0200 To: "Randy Presuhn" , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field In-Reply-To: <000001c5a203$7e2235e0$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> <007701c5a1ee$f284b940$7f1afea9@oemcomputer> <6.2.1.2.2.20050816022623.04c0bc00@mail.afrac.org> <000001c5a203$7e2235e0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Randy, Here is my understanding of the exchange over your "reasonable chance to respond given to active Members from 9am to 5pm". "Facts are sacred, comments are free": I would thank you to let me know if I misquoted or missed some facts. My intent was only to expose our difference of point of view about the role of an IETF WG and the respect of the Internet users. I will attach your comments to this note if you provide some, so readers may get a whole report under a single URL I will probably use in appeals. This being said, I consider the incident as closed. jfc ------- In the following exchange, the by far most list-active Chair of the WG-ltru documents that: 1. he builds his rough consensus evaluation during a WGLC on the lack of opposition from "active" participants 2. he seems to define an "active" participant as a person who will, over a short period of time during 9am-5pm be paid (working hours) to: - access his mail, - consider an issue described by a mark on a process under the active Chair's control, - respond to the WG mailing list without delay. 3. he does this "deliberately". 4. this is to give "everyone" a "reasonable" chance to respond, (not an equal opportunity to do it) 5. this "everyone" seems to exclude: - people not full time dedicated to respond within the hour to this WG mails - people needing to think over the response they want to make and possibly concert with others - people needing someone to translate the WG exchanges - people having difficulty accessing the referenced system's mark (url, login and password not documented in his mail) - Open Source people, who by nature volunteer off-working hours - etc. who are qualified of "Remulac", he will not worry about. Some "active" participants have expressed their support to this practice. NB. REMULAC: Network-aware applications can adjust their resource demands in response to changes in the availability of resources. The Remulac project (Resource Management under Language and Application Control) investigates the design, specification, implementation and evaluation of a software platform for network-aware applications. Such applications must be able to obtain information about the current status of the network resources. The Remulac project was carried by Carnegie Mellon as DARPA order J342. This is probably not the Remulac which was alluded to, but ... it turns to be the main missing consideration of this WG: to deliver a language tag appropriate to network-aware applications' and users' resource (inluding language availability) management - whatever the language, the media and the mode. At 11:59 16/08/2005, r&d afrac wrote: >At 02:51 16/08/2005, r&d afrac wrote: >>On 01:13 16/08/2005, Randy Presuhn said: >>>I'd like to give others time to speak on the proposal to mark #1103 >>>rejected, whether understood as adding a "FileDescription" field >>>or a "#" convention for comments. I'll give folks until 10:00 a.m. >>>(California time) on Tuesday, August 16 2005 for further comment. >>>That will give all our active participants a chance to comment on this, >>>since at least some of the Europeans are probably asleep right now. >> >>I obviously hate this. But it must be said. >> >>After consensus by exhaustion: this is exclusion by the clock! Difficult >>to better document an American (Californian?) oriented bias. Asians, >>Middle-East, Africans, etc. are not even considered! As if Drafts were a >>competition between American and European positions (as suggested by a WG >>Draft author), instead of a common work striving towards the best >>solutions for all. This attitude also denotes a childish confusion >>between an IETF-WG and a wooden horse toy. USA had Minute Men, they seem >>now to have Minute Last Calls. >> >>I am not to judge this, so I will not call for the resignation of the >>co-Chair. But I would think his apologies to all the members of this WG >>would be appropriate to maintain a decent image of the IETF. >> >>Sorry. >>jfc On 03:38 16/08/2005, Randy Presuhn said: >I'll apologize to anyone on the list whose time zone lacks a 9am-5pm >period overlapping the interval in question, since it was deliberately >chosen to give everyone a reasonable chance to respond. Let's see, >where would that be? Not the Americas, not Australia, not Asia, not >Africa, not Europe, not even Antarctica. Useful comments from >Remulac don't appear to be forthcoming, so I won't worry about them. >Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 09:53:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51sX-0001yS-5g; Tue, 16 Aug 2005 09:53:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51sV-0001yN-4v for ltru@megatron.ietf.org; Tue, 16 Aug 2005 09:53:19 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11842 for ; Tue, 16 Aug 2005 09:53:16 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050816135244.UXCH24042.mta11.adelphia.net@DEWELL> for ; Tue, 16 Aug 2005 09:52:44 -0400 Message-ID: <006101c5a269$af2f36e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050816124834.FKIX1660.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 16 Aug 2005 06:52:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > No further requests to change the ABNF in draft-registry or > draft-matching should be entertained unless it can be demonstrated > that the existing ABNF (a) contradicts the text of the draft, (b) > fails when run through a validator, or (c) must be changed to reflect > a new technical decision (which we should not be having at this point > anyway). Changes to the ABNF for cosmetic reasons should be > discouraged. "Contradiction" between text and ABNF refers only to > context-free syntax. > :: Further, I like to have the wildcard as the last alternative (like > :: it was). > :: AND, the [] around extlang are superfluous, as I think Frank > :: already pointed out FOR THE -REGISTRY DRAFT, with an "of course" > :: from Addison. Oh well, I tried. :-( -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 12:15:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E544A-0002uu-Bn; Tue, 16 Aug 2005 12:13:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5448-0002sz-SO for ltru@megatron.ietf.org; Tue, 16 Aug 2005 12:13:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20607 for ; Tue, 16 Aug 2005 12:13:25 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54dU-0005U0-Jx for ltru@ietf.org; Tue, 16 Aug 2005 12:50:01 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 09:13:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1097] ABNF cleanup in matching draft Date: Tue, 16 Aug 2005 09:13:12 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BCD8@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1097] ABNF cleanup in matching draft Thread-Index: AcWiWRWaLJpiife6S2OqTOBqisteNwAGdrAw From: "Addison Phillips" To: "Kent Karlsson" , "LTRU Working Group" X-OriginalArrivalTime: 16 Aug 2005 16:13:13.0725 (UTC) FILETIME=[674712D0:01C5A27D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Comments interlinear, extra text removed. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- >=20 > > Extension matching is a separate issue and may have arcane rules. > > Draft-registry and draft-matching both say that. We can, of course, > > including singletons into the ABNF, if anyone feels strongly about = it. > > > > Modifying the matching ABNF requires adding wildcards in just the = right > > way. Here is what I have so far: >=20 > :: Note that one comment below also refers to the -registry draft. [Addison Phillips]=20 This refers to the square brackets around [ extlang ], about which I = comment below. I think the change is purely editorial and does not have = an effect on the draft-registry. >=20 > > extended-language-range =3D range ; a range > > / privateuse ; private use tag > > / grandfathered ; grandfathered = registrations > :: Oddly this one got a strange name change for the lhs nonterminal. [Addison Phillips]=20 I don't understand this comment, nor ones like it lower in the document. = Are you saying you don't like the rule names (left-hand side IDs)? = Please specify what it should say. > :: If we are to change the names of nonterminals whose formal language > :: is changed, I'd suggest doing so more systematically (P for = Pattern): > ::Language-TagP =3D langtag-p [Addison Phillips]=20 The matching document refers to an "Extended Language Range". It is not, = emphatically, a "Language Tag"; it can have wildcards, for example. I don't like mysterious suffix letters. I don't see why the names can't = be exactly alike here. >=20 > > range =3D (language > > ["-" script] > > ["-" region] > > *("-" variant) > > *("-" extension) > > ["-" privateuse]) > :: This one too got a strange name change for the lhs nonterminal. [Addison Phillips]=20 This is actually the range (the document is talking about ranges). I = don't see that as "strange". > :: If we are to change the names of nonterminals whose formal language > :: is changed, I'd suggest doing so more systematically. It also has > :: "*("-" extension)" though Addison has removed the productions for > :: the nonterminal "extension". Though still odd to me, if "extension" > :: is not to be covered in any way, it must also be removed here. [Addison Phillips]=20 The document is in a draft mode. I didn't modify text yet, pending = discussion on the list. >=20 > > language =3D "*" ; wildcard or... > > / (2*3ALPHA [ extlang ]) ; shortest ISO 639 code > > / 4ALPHA ; reserved for future use > > / 5*8ALPHA ; registered language subtag > :: This one did not get a name change for the lhs nonterminal. > :: But if we are to change the names of nonterminals whose formal = language > :: is changed, I'd suggest doing so systematically, also for this one. [Addison Phillips]=20 The subtag names I purposely did not change. > :: Further, I like to have the wildcard as the last alternative (like = it > was). [Addison Phillips]=20 I do too, and will make the change... > :: AND, the [] around extlang are superfluous, as I think Frank = already > :: pointed out FOR THE -REGISTRY DRAFT, with an "of course" from = Addison. [Addison Phillips]=20 They are superfluous, but I deliberately chose to keep them, since they = make the optional nature of extlangs clear. Bill Fenner's ABNF validator = likes them, so I kept them. >=20 > > extlang =3D *2("-" 3ALPHA) ("-" ( 3ALPHA / "*")) > > ; reserved for future use > > ; wildcard can only appear > > ; at the end > :: Further, I like to have the wildcard as a separate last = alternative. > ::extlang-p =3D *3("-" 3ALPHA) ; reserved for future use > :: / *2("-" 3ALPHA) "-*" ; wildcard, can only appear > :: ; at the end [Addison Phillips]=20 These are semantically equivalent and neither is very pleasing: both = ABNF versions are non-obvious, which I think it bad. Your change is more = consistent with the style of the rest of the ABNF, though, so I'll make = that change. >=20 [Addison Phillips]=20 Remaining comments removed, as they are repetitions of the above. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 12:18:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E548u-0004Ns-ED; Tue, 16 Aug 2005 12:18:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E548t-0004Nn-IW for ltru@megatron.ietf.org; Tue, 16 Aug 2005 12:18:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21109 for ; Tue, 16 Aug 2005 12:18:20 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54iE-0005cu-F1 for ltru@ietf.org; Tue, 16 Aug 2005 12:54:56 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7GGI5I9097522 for ; Tue, 16 Aug 2005 12:18:05 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7GGI8sX145548 for ; Tue, 16 Aug 2005 10:18:08 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7GGI4Fo016496 for ; Tue, 16 Aug 2005 10:18:04 -0600 Received: from markdavis (sig-9-48-114-40.mts.ibm.com [9.48.114.40]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j7GGI3tB016422; Tue, 16 Aug 2005 10:18:04 -0600 Message-ID: <025801c5a27e$1386af60$0e783009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , "Randy Presuhn" , "LTRU Working Group" References: Subject: Re: [Ltru] LTRU Milestones past due Date: Tue, 16 Aug 2005 09:18:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j7GGI5I9097522 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: "Randy Presuhn" ; "LTRU Working Group" Sent: Monday, August 15, 2005 16:14 Subject: RE: [Ltru] LTRU Milestones past due > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > The WG needs to ask itself: > - are the procedures for running the registry sufficiently clear so > that IANA will be able to carry them out? > - are the procedures for requesting the registration of new tags > sufficiently clear so that registrants will be able to provide the > necessary information to ietf-languages@iana.org? > - is the syntax and semantics of language tags sufficiently well > specified to address the requirements stated in the WG charter? > > I believe the answer to all of these is "yes", and has been for quite > some time. +1 Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 12:58:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54m1-0003ct-FN; Tue, 16 Aug 2005 12:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54kh-0003Jr-Ma for ltru@megatron.ietf.org; Tue, 16 Aug 2005 12:57:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23234 for ; Tue, 16 Aug 2005 12:57:24 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E55K3-0006lF-WA for ltru@ietf.org; Tue, 16 Aug 2005 13:34:01 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E54ka-00020P-8E for ltru@ietf.org; Tue, 16 Aug 2005 09:57:20 -0700 Message-Id: <6.2.1.2.2.20050816165420.04bc4910@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 16 Aug 2005 18:57:14 +0200 To: ltru@ietf.org From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Tue, 16 Aug 2005 12:58:48 -0400 Cc: Subject: [Ltru] WGLC security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The current text in security section says: "Language tags used in content negotiation, like any other information exchanged on the Internet, might be a source of concern because they might be used to infer the nationality of the sender, and thus identify potential targets for surveillance." The concern of security is only related in this text to the sending host - which is the least threat since it may be identified in many other ways. This text does not consider the intelligence which may be gathered on the receiver and the impact on the content. I think the following text would be more appropriate: "Language tags used in content negotiation, or in many other circumstances, like any other information exchanged on the Internet, might be a source of concern because they might be used to infer the nationality of the sender, the interest of the receiver, the nature of the content and thus identify, help select potential targets for surveillance, gather statistics, information and intelligence on users and community exchanges, censor contents, block access to information and knowledge, fight national cultures, in particular in using OPES, etc." jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 13:14:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E551Q-0006JV-ET; Tue, 16 Aug 2005 13:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E551O-0006JQ-8B for ltru@megatron.ietf.org; Tue, 16 Aug 2005 13:14:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23926 for ; Tue, 16 Aug 2005 13:14:37 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E54za-0006lc-H0 for ltru@lists.ietf.org; Tue, 16 Aug 2005 19:12:50 +0200 Received: from c-180-160-118.hh.dial.de.ignite.net ([62.180.160.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 19:12:50 +0200 Received: from nobody by c-180-160-118.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 19:12:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 16 Aug 2005 19:09:45 +0200 Organization: Lines: 6 Message-ID: <43021DD9.5BBC@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BADA@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-118.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] 1095 or whatever (was: URN:ISBN) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > pull the bottle of champagne back for five minutes. It's now ten minutes after Randy's deadline, cheers, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 14:06:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55pQ-0006k4-H0; Tue, 16 Aug 2005 14:06:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55pO-0006gN-N2 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 14:06:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26219 for ; Tue, 16 Aug 2005 14:06:21 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56Oj-0008SU-Lh for ltru@ietf.org; Tue, 16 Aug 2005 14:42:57 -0400 Received: from h-68-165-6-190.snvacaid.dynamic.covad.net ([68.165.6.190] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E55pF-0006Q7-00 for ltru@ietf.org; Tue, 16 Aug 2005 14:06:13 -0400 Message-ID: <003801c5a28d$63bdd1c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> <007701c5a1ee$f284b940$7f1afea9@oemcomputer> <6.2.1.2.2.20050816022623.04c0bc00@mail.afrac.org> <000001c5a203$7e2235e0$7f1afea9@oemcomputer> <6.2.1.2.2.20050816120148.04bece10@mail.afrac.org> Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field Date: Tue, 16 Aug 2005 11:07:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - "Remulac" is a reference to old comedic sketches featuring Dan Aykroyd and Jane Curtin. They help me make sense of some of the postings on this list. :-) Others have addressed the question of whether there was adequate time to wrap up this item. Randy ----- Original Message ----- > From: "r&d afrac" > To: "Randy Presuhn" ; > Sent: Tuesday, August 16, 2005 4:19 AM > Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field > > Dear Randy, > Here is my understanding of the exchange over your "reasonable chance to > respond given to active Members from 9am to 5pm". "Facts are sacred, > comments are free": I would thank you to let me know if I misquoted or > missed some facts. > > My intent was only to expose our difference of point of view about the role > of an IETF WG and the respect of the Internet users. I will attach your > comments to this note if you provide some, so readers may get a whole > report under a single URL I will probably use in appeals. > > This being said, I consider the incident as closed. > jfc > > ------- > > In the following exchange, the by far most list-active Chair of the WG-ltru > documents that: > > 1. he builds his rough consensus evaluation during a WGLC on the lack of > opposition from "active" participants > 2. he seems to define an "active" participant as a person who will, over a > short period of time during 9am-5pm be paid (working hours) to: > - access his mail, > - consider an issue described by a mark on a process under the active > Chair's control, > - respond to the WG mailing list without delay. > 3. he does this "deliberately". > 4. this is to give "everyone" a "reasonable" chance to respond, (not an > equal opportunity to do it) > 5. this "everyone" seems to exclude: > - people not full time dedicated to respond within the hour to this WG > mails > - people needing to think over the response they want to make and > possibly concert with others > - people needing someone to translate the WG exchanges > - people having difficulty accessing the referenced system's mark > (url, login and password not documented in his mail) > - Open Source people, who by nature volunteer off-working hours > - etc. > who are qualified of "Remulac", he will not worry about. > > Some "active" participants have expressed their support to this practice. > > NB. REMULAC: Network-aware applications can adjust their resource demands > in response to changes in the availability of resources. The Remulac > project (Resource Management under Language and Application Control) > investigates the design, specification, implementation and evaluation of a > software platform for network-aware applications. Such applications must be > able to obtain information about the current status of the network > resources. The Remulac project was carried by Carnegie Mellon as DARPA > order J342. This is probably not the Remulac which was alluded to, but ... > it turns to be the main missing consideration of this WG: to deliver a > language tag appropriate to network-aware applications' and users' resource > (inluding language availability) management - whatever the language, the > media and the mode. > > At 11:59 16/08/2005, r&d afrac wrote: > >At 02:51 16/08/2005, r&d afrac wrote: > >>On 01:13 16/08/2005, Randy Presuhn said: > >>>I'd like to give others time to speak on the proposal to mark #1103 > >>>rejected, whether understood as adding a "FileDescription" field > >>>or a "#" convention for comments. I'll give folks until 10:00 a.m. > >>>(California time) on Tuesday, August 16 2005 for further comment. > >>>That will give all our active participants a chance to comment on this, > >>>since at least some of the Europeans are probably asleep right now. > >> > >>I obviously hate this. But it must be said. > >> > >>After consensus by exhaustion: this is exclusion by the clock! Difficult > >>to better document an American (Californian?) oriented bias. Asians, > >>Middle-East, Africans, etc. are not even considered! As if Drafts were a > >>competition between American and European positions (as suggested by a WG > >>Draft author), instead of a common work striving towards the best > >>solutions for all. This attitude also denotes a childish confusion > >>between an IETF-WG and a wooden horse toy. USA had Minute Men, they seem > >>now to have Minute Last Calls. > >> > >>I am not to judge this, so I will not call for the resignation of the > >>co-Chair. But I would think his apologies to all the members of this WG > >>would be appropriate to maintain a decent image of the IETF. > >> > >>Sorry. > >>jfc > > On 03:38 16/08/2005, Randy Presuhn said: > >I'll apologize to anyone on the list whose time zone lacks a 9am-5pm > >period overlapping the interval in question, since it was deliberately > >chosen to give everyone a reasonable chance to respond. Let's see, > >where would that be? Not the Americas, not Australia, not Asia, not > >Africa, not Europe, not even Antarctica. Useful comments from > >Remulac don't appear to be forthcoming, so I won't worry about them. > >Randy > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 14:08:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55r1-00074I-OO; Tue, 16 Aug 2005 14:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55r0-00073f-15 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 14:08:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26326 for ; Tue, 16 Aug 2005 14:08:00 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56QN-0008Vq-6W for ltru@ietf.org; Tue, 16 Aug 2005 14:44:36 -0400 Received: from h-68-165-6-190.snvacaid.dynamic.covad.net ([68.165.6.190] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E55qy-0006zQ-00 for ltru@ietf.org; Tue, 16 Aug 2005 14:08:00 -0400 Message-ID: <003d01c5a28d$a3f10fa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050815231347.EQUB20176.mta3.adelphia.net@megatron.ietf.org><002401c5a216$15abfba0$030aa8c0@DEWELL> <43018EAE.5070106@kotus.fi> Subject: Re: [Ltru] [psg.com #1103] WGLC Add File-level Description field Date: Tue, 16 Aug 2005 11:09:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Bsed on the discussion, I'm marking this issue "rejected." The issue tracker is at https://rt.psg.com/ (user and password "ietf") Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 14:19:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E561w-0000U9-Ri; Tue, 16 Aug 2005 14:19:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E561u-0000U0-M4 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 14:19:19 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26809 for ; Tue, 16 Aug 2005 14:19:16 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E560J-0004HL-Hk for ltru@lists.ietf.org; Tue, 16 Aug 2005 20:17:39 +0200 Received: from c-180-160-118.hh.dial.de.ignite.net ([62.180.160.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 20:17:39 +0200 Received: from nobody by c-180-160-118.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 20:17:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 16 Aug 2005 20:15:25 +0200 Organization: Lines: 57 Message-ID: <43022D3D.4436@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BCD8@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-118.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Are you saying you don't like the rule names (left-hand side > IDs)? Please specify what it should say. Apparently Kent proposes to refelect the tag ABNF as closely a possible, add -p to all names (LHS) where you add "-*" to the RHS. If possible it's a consitent approach. Of course you can also use -range instead of -p. > I don't see why the names can't be exactly alike here. You'd need different names for a hypothetical combined ABNF: With a "-*" anywhere a parser would say "range" (if it's correct), without "-*" it would get a normal language tag. I'm not sure if that's Kent's idea. If yes I doubt that it works as expected, a range without any wildcard is still a range, the hypothetical combined grammar would be ambiguous for this case. > Bill Fenner's ABNF validator likes them, so I kept them. Are you talking about the following ? extracted = (2*3ALPHA [ extlang ]) extlang = *2("-" 3ALPHA) ("-" ( 3ALPHA / "*")) These square brackets are not superfluous, in this version can't be empty. They are unnecessary in the registry draft. With Kent's strategy "make the grammars as similar as possible" your only option is to keep them also in the registry draft. Besides that draft is now *FROZEN* unless the IESG or IETF last call finds a serious issue. >>> extlang = *2("-" 3ALPHA) ("-" ( 3ALPHA / "*")) [...] >> Further, I like to have the wildcard as a separate last >> alternative. >> extlang-p = *3("-" 3ALPHA) >> / *2("-" 3ALPHA) "-*" > These are semantically equivalent and neither is very > pleasing: both ABNF versions are non-obvious, which I think | is bad. > Your change is more consistent with the style of the rest of > the ABNF, though, so I'll make that change. Please use a grouping as recomended in 2234(bis): extlang = *3("-" 3ALPHA) / ( *2("-" 3ALPHA) "-*" ) After you've done that the result isn't much better than what you have, so maybe just keep it as it is... ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 14:23:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E566D-0001bg-7g; Tue, 16 Aug 2005 14:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E566A-0001bV-W1 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 14:23:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27005 for ; Tue, 16 Aug 2005 14:23:40 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56fY-0000SC-NV for ltru@ietf.org; Tue, 16 Aug 2005 15:00:16 -0400 Received: from h-68-165-6-190.snvacaid.dynamic.covad.net ([68.165.6.190] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5668-0003WF-00 for ltru@ietf.org; Tue, 16 Aug 2005 14:23:40 -0400 Message-ID: <004501c5a28f$d4953b20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 16 Aug 2005 11:25:07 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] End of ltru WG last calls on registry and initial registry i-ds X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - We've closed out the last of the open issues on the issue tracker (https://rt.psg.com/ (user and password "ietf")), and the rough consensus of those who have posted saying that they've read the draft is of approval. The ltru working group last call of the documents http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-10.txt and http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt is now complete. The Editors are instructed to submit updated drafts, incorporating agreed changes, at their earliest convenience. A third last call will not be needed. When the updated drafts are available, Martin and I will submit the publication requests to the IESG. The working group will receive copies of the requests, and will be kept in the loop for any IESG review comments and IETF last call comments. I'd like to thank the working group, and especially the editors, Mark Davis, Doug Ewell, and Addison Phillips, for their hard work, constructive comments, and patience during this effort. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 14:29:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56BM-0002TK-Mx; Tue, 16 Aug 2005 14:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56BG-0002Sm-U6; Tue, 16 Aug 2005 14:29:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27222; Tue, 16 Aug 2005 14:28:51 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56kW-0000Zg-P7; Tue, 16 Aug 2005 15:05:27 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 11:28:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5A290.5034B1A1" Date: Tue, 16 Aug 2005 11:28:35 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BE16@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: Submission: draft-ietf-ltru-registry draft #11 Thread-Index: AcWikEfUteKFKHykSM2wLFp9dNsdyA== From: "Addison Phillips" To: X-OriginalArrivalTime: 16 Aug 2005 18:28:36.0517 (UTC) FILETIME=[50D6C550:01C5A290] X-Spam-Score: 0.0 (/) X-Scan-Signature: d57eadf689833cdaf5ee100ba6525cf9 Cc: LTRU Working Group Subject: [Ltru] Submission: draft-ietf-ltru-registry draft #11 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A290.5034B1A1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGluIHRleHQgZm9ybWF0IGRyYWZ0 LTExIG9mICdkcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnknLg0KDQpCZXN0IFJlZ2FyZHMgKGZvciB0 aGUgZWRpdG9ycyksDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXph dGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpD aGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDov L3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3Qg YSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= ------_=_NextPart_001_01C5A290.5034B1A1 Content-Type: text/plain; name="draft-ietf-ltru-registry-11.txt" Content-Description: draft-ietf-ltru-registry-11.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-11.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IEZlYnJ1YXJ5 IDE2LCAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBdWd1c3QgMTUsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTENCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBGZWJydWFyeSAxNiwgMjAwNi4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5 cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4NCg0KQWJzdHJhY3QNCg0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHN0cnVjdHVyZSwgY29udGVudCwgY29uc3RydWN0 aW9uLCBhbmQNCiAgIHNlbWFudGljcyBvZiBsYW5ndWFnZSB0YWdzIGZvciB1c2UgaW4gY2FzZXMg d2hlcmUgaXQgaXMgZGVzaXJhYmxlIHRvDQogICBpbmRpY2F0ZSB0aGUgbGFuZ3VhZ2UgdXNlZCBp biBhbiBpbmZvcm1hdGlvbiBvYmplY3QuICBJdCBhbHNvDQogICBkZXNjcmliZXMgaG93IHRvIHJl Z2lzdGVyIHZhbHVlcyBmb3IgdXNlIGluIGxhbmd1YWdlIHRhZ3MgYW5kIHRoZQ0KICAgY3JlYXRp b24gb2YgdXNlciBkZWZpbmVkIGV4dGVuc2lvbnMgZm9yIHByaXZhdGUgaW50ZXJjaGFuZ2UuDQoN Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAw NiAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQpUYWJsZSBv ZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIuICBUaGUgTGFuZ3VhZ2UgVGFnIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgICAyLjEg ICBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA0DQogICAgIDIuMiAgIExhbmd1YWdlIFN1YnRhZyBTb3VyY2VzIGFuZCBJbnRlcnByZXRh dGlvbiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgICAyLjIuMSAgIFByaW1hcnkgTGFuZ3VhZ2Ug U3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAgIDIuMi4yICAg RXh0ZW5kZWQgTGFuZ3VhZ2UgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEw DQogICAgICAgMi4yLjMgICBTY3JpcHQgU3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTANCiAgICAgICAyLjIuNCAgIFJlZ2lvbiBTdWJ0YWcgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICAgIDIuMi41ICAgVmFyaWFu dCBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICAg ICAgMi4yLjYgICBFeHRlbnNpb24gU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTQNCiAgICAgICAyLjIuNyAgIFByaXZhdGUgVXNlIFN1YnRhZ3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQ0KICAgICAgIDIuMi44ICAgUHJlLUV4aXN0aW5n IFJGQyAzMDY2IFJlZ2lzdHJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQogICAgICAgMi4y LjkgICBDbGFzc2VzIG9mIENvbmZvcm1hbmNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTYNCiAgIDMuICBSZWdpc3RyeSBGb3JtYXQgYW5kIE1haW50ZW5hbmNlICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICAzLjEgICBGb3JtYXQgb2YgdGhlIElBTkEgTGFu Z3VhZ2UgU3VidGFnIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIDE4DQogICAgIDMuMiAgIE1haW50 ZW5hbmNlIG9mIHRoZSBSZWdpc3RyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMN CiAgICAgMy4zICAgU3RhYmlsaXR5IG9mIElBTkEgUmVnaXN0cnkgRW50cmllcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyNA0KICAgICAzLjQgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlIGZvciBT dWJ0YWdzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4DQogICAgIDMuNSAgIFBvc3NpYmlsaXRp ZXMgZm9yIFJlZ2lzdHJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzENCiAgICAg My42ICAgRXh0ZW5zaW9ucyBhbmQgRXh0ZW5zaW9ucyBSZWdpc3RyeSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzMw0KICAgICAzLjcgICBJbml0aWFsaXphdGlvbiBvZiB0aGUgUmVnaXN0cmllcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM2DQogICA0LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNz aW5nIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcNCiAgICAgNC4xICAg Q2hvaWNlIG9mIExhbmd1YWdlIFRhZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzNw0KICAgICA0LjIgICBNZWFuaW5nIG9mIHRoZSBMYW5ndWFnZSBUYWcgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDM5DQogICAgIDQuMyAgIExlbmd0aCBDb25zaWRlcmF0aW9ucyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDANCiAgICAgICA0LjMuMSAgIFdv cmtpbmcgd2l0aCBMaW1pdGVkIEJ1ZmZlciBTaXplcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiA0MA0K ICAgICAgIDQuMy4yICAgVHJ1bmNhdGlvbiBvZiBMYW5ndWFnZSBUYWdzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDQyDQogICAgIDQuNCAgIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2Ug VGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDINCiAgICAgNC41ICAgQ29uc2lkZXJhdGlv bnMgZm9yIFByaXZhdGUgVXNlIFN1YnRhZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiA0NA0KICAgNS4g IElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDQ2DQogICAgIDUuMSAgIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDYNCiAgICAgNS4yICAgRXh0ZW5zaW9ucyBSZWdpc3Ry eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Nw0KICAgNi4gIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQ4DQogICA3LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDkNCiAgIDguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MA0KICAgOS4gIFJlZmVyZW5jZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUzDQog ICAgIDkuMSAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNTMNCiAgICAgOS4yICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NA0KICAgICAgIEF1dGhvcnMnIEFkZHJlc3Nl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1DQogICBBLiAg QWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNTYNCiAgIEIuICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBUYWdzIChJbmZvcm1hdGl2ZSkg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Nw0KICAgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBh bmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIDYwDQoNCg0KDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAg ICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KMS4gIEludHJvZHVjdGlv bg0KDQogICBIdW1hbiBiZWluZ3Mgb24gb3VyIHBsYW5ldCBoYXZlLCBwYXN0IGFuZCBwcmVzZW50 LCB1c2VkIGEgbnVtYmVyIG9mDQogICBsYW5ndWFnZXMuICBUaGVyZSBhcmUgbWFueSByZWFzb25z IHdoeSBvbmUgd291bGQgd2FudCB0byBpZGVudGlmeSB0aGUNCiAgIGxhbmd1YWdlIHVzZWQgd2hl biBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3JtYXRpb24uDQoNCiAgIFVzZXIncyBsYW5n dWFnZSBwcmVmZXJlbmNlcyBvZnRlbiBuZWVkIHRvIGJlIGlkZW50aWZpZWQgc28gdGhhdA0KICAg YXBwcm9wcmlhdGUgcHJvY2Vzc2luZyBjYW4gYmUgYXBwbGllZC4gIEZvciBleGFtcGxlLCB0aGUg dXNlcidzDQogICBsYW5ndWFnZSBwcmVmZXJlbmNlcyBpbiBhIFdlYiBicm93c2VyIGNhbiBiZSB1 c2VkIHRvIHNlbGVjdCBXZWIgcGFnZXMNCiAgIGFwcHJvcHJpYXRlbHkuICBMYW5ndWFnZSBwcmVm ZXJlbmNlcyBjYW4gYWxzbyBiZSB1c2VkIHRvIHNlbGVjdCBhbW9uZw0KICAgdG9vbHMgKHN1Y2gg YXMgZGljdGlvbmFyaWVzKSB0byBhc3Npc3QgaW4gdGhlIHByb2Nlc3Npbmcgb3INCiAgIHVuZGVy c3RhbmRpbmcgb2YgY29udGVudCBpbiBkaWZmZXJlbnQgbGFuZ3VhZ2VzLg0KDQogICBJbiBhZGRp dGlvbiwga25vd2xlZGdlIGFib3V0IHRoZSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHVzZWQgYnkgc29t ZQ0KICAgcGllY2Ugb2YgaW5mb3JtYXRpb24gY29udGVudCBtaWdodCBiZSB1c2VmdWwgb3IgZXZl biByZXF1aXJlZCBieSBzb21lDQogICB0eXBlcyBvZiBwcm9jZXNzaW5nOyBmb3IgZXhhbXBsZSBz cGVsbC1jaGVja2luZywgY29tcHV0ZXItc3ludGhlc2l6ZWQNCiAgIHNwZWVjaCwgQnJhaWxsZSB0 cmFuc2NyaXB0aW9uLCBvciBoaWdoLXF1YWxpdHkgcHJpbnQgcmVuZGVyaW5ncy4NCg0KICAgT25l IG1lYW5zIG9mIGluZGljYXRpbmcgdGhlIGxhbmd1YWdlIHVzZWQgaXMgYnkgbGFiZWxpbmcgdGhl DQogICBpbmZvcm1hdGlvbiBjb250ZW50IHdpdGggYW4gaWRlbnRpZmllciBvciAidGFnIi4gIFRo ZXNlIHRhZ3MgY2FuIGJlDQogICB1c2VkIHRvIHNwZWNpZnkgdXNlciBwcmVmZXJlbmNlcyB3aGVu IHNlbGVjdGluZyBpbmZvcm1hdGlvbiBjb250ZW50LA0KICAgb3IgZm9yIGxhYmVsaW5nIGFkZGl0 aW9uYWwgYXR0cmlidXRlcyBvZiBjb250ZW50IGFuZCBhc3NvY2lhdGVkDQogICByZXNvdXJjZXMu DQoNCiAgIFRhZ3MgY2FuIGFsc28gYmUgdXNlZCB0byBpbmRpY2F0ZSBhZGRpdGlvbmFsIGxhbmd1 YWdlIGF0dHJpYnV0ZXMgb2YNCiAgIGNvbnRlbnQuICBGb3IgZXhhbXBsZSwgaW5kaWNhdGluZyBz cGVjaWZpYyBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCiAgIGRpYWxlY3QsIHdyaXRpbmcgc3lzdGVt LCBvciBvcnRob2dyYXBoeSB1c2VkIGluIGEgZG9jdW1lbnQgb3INCiAgIHJlc291cmNlIG1heSBl bmFibGUgdGhlIHVzZXIgdG8gb2J0YWluIGluZm9ybWF0aW9uIGluIGEgZm9ybSB0aGF0DQogICB0 aGV5IGNhbiB1bmRlcnN0YW5kLCBvciBpbXBvcnRhbnQgaW4gcHJvY2Vzc2luZyBvciByZW5kZXJp bmcgdGhlDQogICBnaXZlbiBjb250ZW50IGludG8gYW4gYXBwcm9wcmlhdGUgZm9ybSBvciBzdHls ZS4NCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBwYXJ0aWN1bGFyIGlkZW50aWZpZXIg bWVjaGFuaXNtICh0aGUNCiAgIGxhbmd1YWdlIHRhZykgYW5kIGEgcmVnaXN0cmF0aW9uIGZ1bmN0 aW9uIGZvciB2YWx1ZXMgdG8gYmUgdXNlZCB0bw0KICAgZm9ybSB0YWdzLiAgSXQgYWxzbyBkZWZp bmVzIGEgbWVjaGFuaXNtIGZvciBwcml2YXRlIHVzZSB2YWx1ZXMgYW5kDQogICBmdXR1cmUgZXh0 ZW5zaW9uLg0KDQogICBUaGlzIGRvY3VtZW50IHJlcGxhY2VzIFtSRkMzMDY2XSwgd2hpY2ggcmVw bGFjZWQgW1JGQzE3NjZdLiAgRm9yIGENCiAgIGxpc3Qgb2YgY2hhbmdlcyBpbiB0aGlzIGRvY3Vt ZW50LCBzZWUgU2VjdGlvbiA4Lg0KDQogICBUaGUga2V5d29yZHMgIk1VU1QiLCAiTVVTVCBOT1Qi LCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxE IE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4N Cg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMTYsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoN Cg0KMi4gIFRoZSBMYW5ndWFnZSBUYWcNCg0KICAgTGFuZ3VhZ2UgdGFncyBhcmUgdXNlZCB0byBo ZWxwIGlkZW50aWZ5IGxhbmd1YWdlcywgd2hldGhlciBzcG9rZW4sDQogICB3cml0dGVuLCBzaWdu ZWQsIG9yIG90aGVyd2lzZSBzaWduYWxlZCwgZm9yIHRoZSBwdXJwb3NlIG9mDQogICBjb21tdW5p Y2F0aW9uLiAgVGhpcyBpbmNsdWRlcyBjb25zdHJ1Y3RlZCBhbmQgYXJ0aWZpY2lhbCBsYW5ndWFn ZXMsDQogICBidXQgZXhjbHVkZXMgbGFuZ3VhZ2VzIG5vdCBpbnRlbmRlZCBwcmltYXJpbHkgZm9y IGh1bWFuDQogICBjb21tdW5pY2F0aW9uLCBzdWNoIGFzIHByb2dyYW1taW5nIGxhbmd1YWdlcy4N Cg0KMi4xICBTeW50YXgNCg0KICAgVGhlIGxhbmd1YWdlIHRhZyBpcyBjb21wb3NlZCBvZiBvbmUg b3IgbW9yZSBwYXJ0cyBvciAic3VidGFncyIuICBFYWNoDQogICBzdWJ0YWcgY29uc2lzdHMgb2Yg YSBzZXF1ZW5jZSBvZiBhbHBoYS1udW1lcmljIGNoYXJhY3RlcnMuICBTdWJ0YWdzDQogICBhcmUg ZGlzdGluZ3Vpc2hlZCBhbmQgc2VwYXJhdGVkIGZyb20gb25lIGFub3RoZXIgYnkgYSBoeXBoZW4g KCItIiwNCiAgIEFCTkYgW1JGQzIyMzRiaXNdICV4MkQpLiAgQSBsYW5ndWFnZSB0YWcgY29uc2lz dHMgb2YgYSAicHJpbWFyeQ0KICAgbGFuZ3VhZ2UiIHN1YnRhZyBhbmQgYSAocG9zc2libHkgZW1w dHkpIHNlcmllcyBvZiBzdWJzZXF1ZW50IHN1YnRhZ3MsDQogICBlYWNoIG9mIHdoaWNoIHJlZmlu ZXMgb3IgbmFycm93cyB0aGUgcmFuZ2Ugb2YgbGFuZ3VhZ2UgaWRlbnRpZmllZCBieQ0KICAgdGhl IG92ZXJhbGwgdGFnLg0KDQogICBFYWNoIHR5cGUgb2Ygc3VidGFnIGlzIGRpc3Rpbmd1aXNoZWQg YnkgbGVuZ3RoLCBwb3NpdGlvbiBpbiB0aGUgdGFnLA0KICAgYW5kIGNvbnRlbnQ6IHN1YnRhZ3Mg Y2FuIGJlIHJlY29nbml6ZWQgc29sZWx5IGJ5IHRoZXNlIGZlYXR1cmVzLg0KICAgVGhpcyBtYWtl cyBpdCBwb3NzaWJsZSB0byBjb25zdHJ1Y3QgYSBwYXJzZXIgdGhhdCBjYW4gZXh0cmFjdCBhbmQN CiAgIGFzc2lnbiBzb21lIHNlbWFudGljIGluZm9ybWF0aW9uIHRvIHRoZSBzdWJ0YWdzLCBldmVu IGlmIHRoZSBzcGVjaWZpYw0KICAgc3VidGFnIHZhbHVlcyBhcmUgbm90IHJlY29nbml6ZWQuICBU aHVzIGEgcGFyc2VyIG5lZWQgbm90IGhhdmUgYW4gdXAtDQogICB0by1kYXRlIGNvcHkgKG9yIGFu eSBjb3B5IGF0IGFsbCkgb2YgdGhlIHN1YnRhZyByZWdpc3RyeSB0byBwZXJmb3JtDQogICBtb3N0 IHNlYXJjaGluZyBhbmQgbWF0Y2hpbmcgb3BlcmF0aW9ucy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBB dWd1c3QgMjAwNQ0KDQoNCiAgIFRoZSBzeW50YXggb2YgdGhlIGxhbmd1YWdlIHRhZyBpbiBBQk5G IFtSRkMyMjM0YmlzXSBpczoNCg0KICAgTGFuZ3VhZ2UtVGFnICA9IGxhbmd0YWcNCiAgICAgICAg ICAgICAgICAgLyBwcml2YXRldXNlICAgICAgICAgICAgIDsgcHJpdmF0ZSB1c2UgdGFnDQogICAg ICAgICAgICAgICAgIC8gZ3JhbmRmYXRoZXJlZCAgICAgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVn aXN0cmF0aW9ucw0KDQogICBsYW5ndGFnICAgICAgID0gKGxhbmd1YWdlDQogICAgICAgICAgICAg ICAgICAgIFsiLSIgc2NyaXB0XQ0KICAgICAgICAgICAgICAgICAgICBbIi0iIHJlZ2lvbl0NCiAg ICAgICAgICAgICAgICAgICAgKigiLSIgdmFyaWFudCkNCiAgICAgICAgICAgICAgICAgICAgKigi LSIgZXh0ZW5zaW9uKQ0KICAgICAgICAgICAgICAgICAgICBbIi0iIHByaXZhdGV1c2VdKQ0KDQog ICBsYW5ndWFnZSAgICAgID0gKDIqM0FMUEhBIFsgZXh0bGFuZyBdKSA7IHNob3J0ZXN0IElTTyA2 MzkgY29kZQ0KICAgICAgICAgICAgICAgICAvIDRBTFBIQSAgICAgICAgICAgICAgICAgOyByZXNl cnZlZCBmb3IgZnV0dXJlIHVzZQ0KICAgICAgICAgICAgICAgICAvIDUqOEFMUEhBICAgICAgICAg ICAgICAgOyByZWdpc3RlcmVkIGxhbmd1YWdlIHN1YnRhZw0KDQogICBleHRsYW5nICAgICAgID0g KjMoIi0iIDNBTFBIQSkgICAgICAgICA7IHJlc2VydmVkIGZvciBmdXR1cmUgdXNlDQoNCiAgIHNj cmlwdCAgICAgICAgPSA0QUxQSEEgICAgICAgICAgICAgICAgIDsgSVNPIDE1OTI0IGNvZGUNCg0K ICAgcmVnaW9uICAgICAgICA9IDJBTFBIQSAgICAgICAgICAgICAgICAgOyBJU08gMzE2NiBjb2Rl DQogICAgICAgICAgICAgICAgIC8gM0RJR0lUICAgICAgICAgICAgICAgICA7IFVOIE0uNDkgY29k ZQ0KDQogICB2YXJpYW50ICAgICAgID0gNSo4YWxwaGFudW0gICAgICAgICAgICA7IHJlZ2lzdGVy ZWQgdmFyaWFudHMNCiAgICAgICAgICAgICAgICAgLyAoRElHSVQgM2FscGhhbnVtKQ0KDQogICBl eHRlbnNpb24gICAgID0gc2luZ2xldG9uIDEqKCItIiAoMio4YWxwaGFudW0pKQ0KDQogICBzaW5n bGV0b24gICAgID0gJXg0MS01NyAvICV4NTktNUEgLyAleDYxLTc3IC8gJXg3OS03QSAvIERJR0lU DQogICAgICAgICAgICAgICAgIDsgImEiLSJ3IiAvICJ5Ii0ieiIgLyAiQSItIlciIC8gIlkiLSJa IiAvICIwIi0iOSINCiAgICAgICAgICAgICAgICAgOyBTaW5nbGUgbGV0dGVyczogeC9YIGlzIHJl c2VydmVkIGZvciBwcml2YXRlIHVzZQ0KDQogICBwcml2YXRldXNlICAgID0gKCJ4Ii8iWCIpIDEq KCItIiAoMSo4YWxwaGFudW0pKQ0KDQogICBncmFuZGZhdGhlcmVkID0gMSozQUxQSEEgMSoyKCIt IiAoMio4YWxwaGFudW0pKQ0KICAgICAgICAgICAgICAgICAgIDsgZ3JhbmRmYXRoZXJlZCByZWdp c3RyYXRpb24NCiAgICAgICAgICAgICAgICAgICA7IE5vdGU6IGkgaXMgdGhlIG9ubHkgc2luZ2xl dG9uDQogICAgICAgICAgICAgICAgICAgOyB0aGF0IHN0YXJ0cyBhIGdyYW5kZmF0aGVyZWQgdGFn DQoNCiAgIGFscGhhbnVtICAgICAgPSAoQUxQSEEgLyBESUdJVCkgICAgICAgOyBsZXR0ZXJzIGFu ZCBudW1iZXJzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBMYW5ndWFnZSBU YWcgQUJORg0KDQogICBOb3RlOiBUaGVyZSBpcyBhIHN1YnRsZXR5IGluIHRoZSBBQk5GIGZvciAn dmFyaWFudCc6IHZhcmlhbnRzDQogICBzdGFydGluZyB3aXRoIGEgZGlnaXQgTUFZIGJlIGZvdXIg Y2hhcmFjdGVycyBsb25nLCB3aGlsZSB0aG9zZQ0KICAgc3RhcnRpbmcgd2l0aCBhIGxldHRlciBN VVNUIGJlIGF0IGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICAgW1Bh Z2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIEFsbCBzdWJ0YWdzIGhhdmUgYSBtYXhp bXVtIGxlbmd0aCBvZiBlaWdodCBjaGFyYWN0ZXJzIGFuZCB3aGl0ZXNwYWNlDQogICBpcyBub3Qg cGVybWl0dGVkIGluIGEgbGFuZ3VhZ2UgdGFnLiAgRm9yIGV4YW1wbGVzIG9mIGxhbmd1YWdlIHRh Z3MsDQogICBzZWUgQXBwZW5kaXggQi4NCg0KICAgTm90ZSB0aGF0IGFsdGhvdWdoIFtSRkMyMjM0 YmlzXSByZWZlcnMgdG8gb2N0ZXRzLCB0aGUgbGFuZ3VhZ2UgdGFncw0KICAgZGVzY3JpYmVkIGlu IHRoaXMgZG9jdW1lbnQgYXJlIHNlcXVlbmNlcyBvZiBjaGFyYWN0ZXJzIGZyb20gdGhlIFVTLQ0K ICAgQVNDSUkgW0lTTzY0Nl0gcmVwZXJ0b2lyZS4gIExhbmd1YWdlIHRhZ3MgTUFZIGJlIHVzZWQg aW4gZG9jdW1lbnRzDQogICBhbmQgYXBwbGljYXRpb25zIHRoYXQgdXNlIG90aGVyIGVuY29kaW5n cywgc28gbG9uZyBhcyB0aGVzZSBlbmNvbXBhc3MNCiAgIHRoZSBVUy1BU0NJSSByZXBlcnRvaXJl LiAgQW4gZXhhbXBsZSBvZiB0aGlzIHdvdWxkIGJlIGFuIFhNTCBkb2N1bWVudA0KICAgdGhhdCB1 c2VzIHRoZSBVVEYtMTZMRSBbUkZDMjc4MV0gZW5jb2Rpbmcgb2YgW1VuaWNvZGVdLg0KDQogICBU aGUgdGFncyBhbmQgdGhlaXIgc3VidGFncywgaW5jbHVkaW5nIHByaXZhdGUgdXNlIGFuZCBleHRl bnNpb25zLCBhcmUNCiAgIHRvIGJlIHRyZWF0ZWQgYXMgY2FzZSBpbnNlbnNpdGl2ZTogdGhlcmUg ZXhpc3QgY29udmVudGlvbnMgZm9yIHRoZQ0KICAgY2FwaXRhbGl6YXRpb24gb2Ygc29tZSBvZiB0 aGUgc3VidGFncywgYnV0IHRoZXNlIE1VU1QgTk9UIGJlIHRha2VuIHRvDQogICBjYXJyeSBtZWFu aW5nLg0KDQogICBGb3IgZXhhbXBsZToNCg0KICAgbyAgW0lTTzYzOS0xXSByZWNvbW1lbmRzIHRo YXQgbGFuZ3VhZ2UgY29kZXMgYmUgd3JpdHRlbiBpbiBsb3dlciBjYXNlDQogICAgICAoJ21uJyBN b25nb2xpYW4pLg0KDQogICBvICBbSVNPMzE2Ni0xXSByZWNvbW1lbmRzIHRoYXQgY291bnRyeSBj b2RlcyBiZSBjYXBpdGFsaXplZCAoJ01OJw0KICAgICAgTW9uZ29saWEpLg0KDQogICBvICBbSVNP MTU5MjRdIHJlY29tbWVuZHMgdGhhdCBzY3JpcHQgY29kZXMgdXNlIGxvd2VyIGNhc2Ugd2l0aCB0 aGUNCiAgICAgIGluaXRpYWwgbGV0dGVyIGNhcGl0YWxpemVkICgnQ3lybCcgQ3lyaWxsaWMpLg0K DQogICBIb3dldmVyLCBpbiB0aGUgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIHRoZSB1 cHBlcmNhc2UgVVMtQVNDSUkNCiAgIGxldHRlcnMgaW4gdGhlIHJhbmdlICdBJyB0aHJvdWdoICda JyBhcmUgY29uc2lkZXJlZCBlcXVpdmFsZW50IGFuZA0KICAgbWFwcGVkIGRpcmVjdGx5IHRvIHRo ZWlyIFVTLUFTQ0lJIGxvd2VyY2FzZSBlcXVpdmFsZW50cyBpbiB0aGUgcmFuZ2UNCiAgICdhJyB0 aHJvdWdoICd6Jy4gIFRodXMgdGhlIHRhZyAibW4tQ3lybC1NTiIgaXMgbm90IGRpc3RpbmN0IGZy b20gIk1OLQ0KICAgY1lSTC1tbiIgb3IgIm1OLWNZckwtTW4iIChvciBhbnkgb3RoZXIgY29tYmlu YXRpb24pIGFuZCBlYWNoIG9mIHRoZXNlDQogICB2YXJpYXRpb25zIGNvbnZleXMgdGhlIHNhbWUg bWVhbmluZzogTW9uZ29saWFuIHdyaXR0ZW4gaW4gdGhlDQogICBDeXJpbGxpYyBzY3JpcHQgYXMg dXNlZCBpbiBNb25nb2xpYS4NCg0KMi4yICBMYW5ndWFnZSBTdWJ0YWcgU291cmNlcyBhbmQgSW50 ZXJwcmV0YXRpb24NCg0KICAgVGhlIG5hbWVzcGFjZSBvZiBsYW5ndWFnZSB0YWdzIGFuZCB0aGVp ciBzdWJ0YWdzIGlzIGFkbWluaXN0ZXJlZCBieQ0KICAgdGhlIEludGVybmV0IEFzc2lnbmVkIE51 bWJlcnMgQXV0aG9yaXR5IChJQU5BKSBbUkZDMjg2MF0gYWNjb3JkaW5nIHRvDQogICB0aGUgcnVs ZXMgaW4gU2VjdGlvbiA1IG9mIHRoaXMgZG9jdW1lbnQuICBUaGUgTGFuZ3VhZ2UgU3VidGFnDQog ICBSZWdpc3RyeSBtYWludGFpbmVkIGJ5IElBTkEgaXMgdGhlIHNvdXJjZSBmb3IgdmFsaWQgc3Vi dGFnczogb3RoZXINCiAgIHN0YW5kYXJkcyByZWZlcmVuY2VkIGluIHRoaXMgc2VjdGlvbiBwcm92 aWRlIHRoZSBzb3VyY2UgbWF0ZXJpYWwgZm9yDQogICB0aGF0IHJlZ2lzdHJ5Lg0KDQogICBUZXJt aW5vbG9neSBpbiB0aGlzIHNlY3Rpb246DQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIG8gIFRhZyBvciB0YWdzIHJlZmVycyB0byBhIGNvbXBs ZXRlIGxhbmd1YWdlIHRhZywgc3VjaCBhcw0KICAgICAgImZyLUxhdG4tQ0EiLiAgRXhhbXBsZXMg b2YgdGFncyBpbiB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbg0KICAgICAgZG91YmxlLXF1 b3RlcyAoImVuLVVTIikuDQoNCiAgIG8gIFN1YnRhZyByZWZlcnMgdG8gYSBzcGVjaWZpYyBzZWN0 aW9uIG9mIGEgdGFnLCBkZWxpbWl0ZWQgYnkgaHlwaGVuLA0KICAgICAgc3VjaCBhcyB0aGUgc3Vi dGFnICdMYXRuJyBpbiAiZnItTGF0bi1DQSIuICBFeGFtcGxlcyBvZiBzdWJ0YWdzIGluDQogICAg ICB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgnTGF0bicpLg0K DQogICBvICBDb2RlIG9yIGNvZGVzIHJlZmVycyB0byB2YWx1ZXMgZGVmaW5lZCBpbiBleHRlcm5h bCBzdGFuZGFyZHMgKGFuZA0KICAgICAgd2hpY2ggYXJlIHVzZWQgYXMgc3VidGFncyBpbiB0aGlz IGRvY3VtZW50KS4gIEZvciBleGFtcGxlLCAnTGF0bicNCiAgICAgIGlzIGFuIFtJU08xNTkyNF0g c2NyaXB0IGNvZGUgd2hpY2ggd2FzIHVzZWQgdG8gZGVmaW5lIHRoZSAnTGF0bicNCiAgICAgIHNj cmlwdCBzdWJ0YWcgZm9yIHVzZSBpbiBhIGxhbmd1YWdlIHRhZy4gIEV4YW1wbGVzIG9mIGNvZGVz IGluDQogICAgICB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgn ZW4nLCAnTGF0bicpLg0KDQogICBUaGUgZGVmaW5pdGlvbnMgaW4gdGhpcyBzZWN0aW9uIGFwcGx5 IHRvIHRoZSB2YXJpb3VzIHN1YnRhZ3Mgd2l0aGluDQogICB0aGUgbGFuZ3VhZ2UgdGFncyBkZWZp bmVkIGJ5IHRoaXMgZG9jdW1lbnQsIGV4Y2VwdGluZyB0aG9zZQ0KICAgImdyYW5kZmF0aGVyZWQi IHRhZ3MgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMi44Lg0KDQogICBMYW5ndWFnZSB0YWdzIGFyZSBk ZXNpZ25lZCBzbyB0aGF0IGVhY2ggc3VidGFnIHR5cGUgaGFzIHVuaXF1ZSBsZW5ndGgNCiAgIGFu ZCBjb250ZW50IHJlc3RyaWN0aW9ucy4gIFRoZXNlIG1ha2UgaWRlbnRpZmljYXRpb24gb2YgdGhl IHN1YnRhZydzDQogICB0eXBlIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBjb250ZW50IG9mIHRoZSBz dWJ0YWcgaXRzZWxmIGlzDQogICB1bnJlY29nbml6ZWQuICBUaGlzIGFsbG93cyB0YWdzIHRvIGJl IHBhcnNlZCBhbmQgcHJvY2Vzc2VkIHdpdGhvdXQNCiAgIHJlZmVyZW5jZSB0byB0aGUgbGF0ZXN0 IHZlcnNpb24gb2YgdGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzIG9yIHRoZQ0KICAgSUFOQSByZWdp c3RyeSBhbmQgbWFrZXMgdGhlIGFzc29jaWF0ZWQgZXhjZXB0aW9uIGhhbmRsaW5nIHdoZW4NCiAg IHBhcnNpbmcgdGFncyBzaW1wbGVyLg0KDQogICBTdWJ0YWdzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5 IHRoYXQgZG8gbm90IGNvbWUgZnJvbSBhbiB1bmRlcmx5aW5nDQogICBzdGFuZGFyZCBjYW4gb25s eSBhcHBlYXIgaW4gc3BlY2lmaWMgcG9zaXRpb25zIGluIGEgdGFnLg0KICAgU3BlY2lmaWNhbGx5 LCB0aGV5IGNhbiBvbmx5IG9jY3VyIGFzIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBvciBhcw0K ICAgdmFyaWFudCBzdWJ0YWdzLg0KDQogICBOb3RlIHRoYXQgc2VxdWVuY2VzIG9mIHByaXZhdGUg dXNlIGFuZCBleHRlbnNpb24gc3VidGFncyBNVVNUIG9jY3VyDQogICBhdCB0aGUgZW5kIG9mIHRo ZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFuZCBNVVNUIE5PVCBiZSBpbnRlcnNwZXJzZWQNCiAgIHdp dGggc3VidGFncyBkZWZpbmVkIGVsc2V3aGVyZSBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBTaW5n bGUgbGV0dGVyIGFuZCBkaWdpdCBzdWJ0YWdzIGFyZSByZXNlcnZlZCBmb3IgY3VycmVudCBvciBm dXR1cmUNCiAgIHVzZS4gIFRoZXNlIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBjdXJyZW50IHVzZXM6 DQoNCiAgIG8gIFRoZSBzaW5nbGUgbGV0dGVyIHN1YnRhZyAneCcgaXMgcmVzZXJ2ZWQgdG8gaW50 cm9kdWNlIGEgc2VxdWVuY2UNCiAgICAgIG9mIHByaXZhdGUgdXNlIHN1YnRhZ3MuICBUaGUgaW50 ZXJwcmV0YXRpb24gb2YgYW55IHByaXZhdGUgdXNlDQogICAgICBzdWJ0YWdzIGlzIGRlZmluZWQg c29sZWx5IGJ5IHByaXZhdGUgYWdyZWVtZW50IGFuZCBpcyBub3QgZGVmaW5lZA0KICAgICAgYnkg dGhlIHJ1bGVzIGluIHRoaXMgc2VjdGlvbiBvciBpbiBhbnkgc3RhbmRhcmQgb3IgcmVnaXN0cnkN CiAgICAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgbyAgQWxsIG90aGVyIHNpbmds ZSBsZXR0ZXIgc3VidGFncyBhcmUgcmVzZXJ2ZWQgdG8gaW50cm9kdWNlDQogICAgICBzdGFuZGFy ZGl6ZWQgZXh0ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZXMgYXMgZGVzY3JpYmVkIGluDQogICAgICBT ZWN0aW9uIDMuNi4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUN Cg0KDQogICBUaGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29tZSBncmFu ZGZhdGhlcmVkIHRhZ3MsIHN1Y2gNCiAgIGFzICJpLWVub2NoaWFuIiwgd2hlcmUgaXQgYWx3YXlz IGFwcGVhcnMgaW4gdGhlIGZpcnN0IHBvc2l0aW9uIGFuZA0KICAgY2Fubm90IGJlIGNvbmZ1c2Vk IHdpdGggYW4gZXh0ZW5zaW9uLg0KDQoyLjIuMSAgUHJpbWFyeSBMYW5ndWFnZSBTdWJ0YWcNCg0K ICAgVGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHRoZSBmaXJzdCBzdWJ0YWcgaW4gYSBs YW5ndWFnZSB0YWcNCiAgICh3aXRoIHRoZSBleGNlcHRpb24gb2YgcHJpdmF0ZSB1c2UgYW5kIGNl cnRhaW4gZ3JhbmRmYXRoZXJlZCB0YWdzKQ0KICAgYW5kIGNhbm5vdCBiZSBvbWl0dGVkLiAgVGhl IGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3VidGFn Og0KDQogICAxLiAgQWxsIHR3byBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3VidGFncyB3ZXJlIGRlZmlu ZWQgaW4gdGhlIElBTkENCiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1l bnRzIGZvdW5kIGluIHRoZSBzdGFuZGFyZCBJU08NCiAgICAgICA2MzkgUGFydCAxLCAiSVNPIDYz OS0xOjIwMDIsIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YNCiAgICAgICBuYW1lcyBv ZiBsYW5ndWFnZXMgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiIFtJU082MzktMV0sIG9yIHVzaW5n DQogICAgICAgYXNzaWdubWVudHMgc3Vic2VxdWVudGx5IG1hZGUgYnkgdGhlIElTTyA2MzkgUGFy dCAxIG1haW50ZW5hbmNlDQogICAgICAgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRp b24gYm9kaWVzLg0KDQogICAyLiAgQWxsIHRocmVlIGNoYXJhY3RlciBsYW5ndWFnZSBzdWJ0YWdz IHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0 aGUgYXNzaWdubWVudHMgZm91bmQgaW4gSVNPIDYzOSBQYXJ0IDIsDQogICAgICAgIklTTyA2Mzkt MjoxOTk4IC0gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZg0KICAgICAg IGxhbmd1YWdlcyAtLSBQYXJ0IDI6IEFscGhhLTMgY29kZSAtIGVkaXRpb24gMSIgW0lTTzYzOS0y XSwgb3INCiAgICAgICBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDYz OSBQYXJ0IDIgbWFpbnRlbmFuY2UNCiAgICAgICBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5kYXJk aXphdGlvbiBib2RpZXMuDQoNCiAgIDMuICBUaGUgc3VidGFncyBpbiB0aGUgcmFuZ2UgJ3FhYScg dGhyb3VnaCAncXR6JyBhcmUgcmVzZXJ2ZWQgZm9yDQogICAgICAgcHJpdmF0ZSB1c2UgaW4gbGFu Z3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MgY29ycmVzcG9uZCB0byBjb2Rlcw0KICAgICAgIHJl c2VydmVkIGJ5IElTTyA2MzktMiBmb3IgcHJpdmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUg dXNlZA0KICAgICAgIGZvciBub24tcmVnaXN0ZXJlZCBwcmltYXJ5LWxhbmd1YWdlIHN1YnRhZ3Mg KGluc3RlYWQgb2YgdXNpbmcNCiAgICAgICBwcml2YXRlIHVzZSBzdWJ0YWdzIGZvbGxvd2luZyAn eC0nKS4gIFBsZWFzZSByZWZlciB0byBTZWN0aW9uIDQuNQ0KICAgICAgIGZvciBtb3JlIGluZm9y bWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgIDQuICBBbGwgZm91ciBjaGFyYWN0 ZXIgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgcmVzZXJ2ZWQgZm9yIHBvc3NpYmxlDQogICAgICAgZnV0 dXJlIHN0YW5kYXJkaXphdGlvbi4NCg0KICAgNS4gIEFsbCBsYW5ndWFnZSBzdWJ0YWdzIG9mIDUg dG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IHdl cmUgZGVmaW5lZCB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGluIFNlY3Rpb24gMy40DQog ICAgICAgYW5kIE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFn LiAgQXQgdGhlIHRpbWUNCiAgICAgICB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCB0aGVyZSB3 ZXJlIG5vIGV4YW1wbGVzIG9mIHRoaXMga2luZCBvZg0KICAgICAgIHN1YnRhZyBhbmQgZnV0dXJl IHJlZ2lzdHJhdGlvbnMgb2YgdGhpcyB0eXBlIHdpbGwgYmUgZGlzY291cmFnZWQ6DQogICAgICAg cHJpbWFyeSBsYW5ndWFnZXMgYXJlIHN0cm9uZ2x5IFJFQ09NTUVOREVEIGZvciByZWdpc3RyYXRp b24gd2l0aA0KICAgICAgIElTTyA2MzkgYW5kIHByb3Bvc2FscyByZWplY3RlZCBieSBJU08gNjM5 L1JBIHdpbGwgYmUgY2xvc2VseQ0KICAgICAgIHNjcnV0aW5pemVkIGJlZm9yZSB0aGV5IGFyZSBy ZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KICAgNi4gIFRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRh ZyAneCcgYXMgdGhlIHByaW1hcnkgc3VidGFnIGluZGljYXRlcw0KICAgICAgIHRoYXQgdGhlIGxh bmd1YWdlIHRhZyBjb25zaXN0cyBzb2xlbHkgb2Ygc3VidGFncyB3aG9zZSBtZWFuaW5nIGlzDQog ICAgICAgZGVmaW5lZCBieSBwcml2YXRlIGFncmVlbWVudC4gIEZvciBleGFtcGxlLCBpbiB0aGUg dGFnICJ4LWZyLUNIIiwNCiAgICAgICB0aGUgc3VidGFncyAnZnInIGFuZCAnQ0gnIFNIT1VMRCBO T1QgYmUgdGFrZW4gdG8gcmVwcmVzZW50IHRoZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAgRnJlbmNoIGxhbmd1YWdlIG9yIHRoZSBjb3VudHJ5 IG9mIFN3aXR6ZXJsYW5kIChvciBhbnkgb3RoZXIgdmFsdWUNCiAgICAgICBpbiB0aGUgSUFOQSBy ZWdpc3RyeSkgdW5sZXNzIHRoZXJlIGlzIGEgcHJpdmF0ZSBhZ3JlZW1lbnQgaW4NCiAgICAgICBw bGFjZSB0byBkbyBzby4gIFNlZSBTZWN0aW9uIDQuNS4NCg0KICAgNy4gIFRoZSBzaW5nbGUgY2hh cmFjdGVyIHN1YnRhZyAnaScgaXMgdXNlZCBieSBzb21lIGdyYW5kZmF0aGVyZWQNCiAgICAgICB0 YWdzIChzZWUgU2VjdGlvbiAyLjIuOCkgc3VjaCBhcyAiaS1rbGluZ29uIiBhbmQgImktYm5uIi4g IChPdGhlcg0KICAgICAgIGdyYW5kZmF0aGVyZWQgdGFncyBoYXZlIGEgcHJpbWFyeSBsYW5ndWFn ZSBzdWJ0YWcgaW4gdGhlaXIgZmlyc3QNCiAgICAgICBwb3NpdGlvbikNCg0KICAgOC4gIE90aGVy IHZhbHVlcyBNVVNUIE5PVCBiZSBhc3NpZ25lZCB0byB0aGUgcHJpbWFyeSBzdWJ0YWcgZXhjZXB0 IGJ5DQogICAgICAgcmV2aXNpb24gb3IgdXBkYXRlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5v dGU6IEZvciBsYW5ndWFnZXMgdGhhdCBoYXZlIGJvdGggYW4gSVNPIDYzOS0xIHR3byBjaGFyYWN0 ZXIgY29kZQ0KICAgYW5kIGFuIElTTyA2MzktMiB0aHJlZSBjaGFyYWN0ZXIgY29kZSwgb25seSB0 aGUgSVNPIDYzOS0xIHR3bw0KICAgY2hhcmFjdGVyIGNvZGUgaXMgZGVmaW5lZCBpbiB0aGUgSUFO QSByZWdpc3RyeS4NCg0KICAgTm90ZTogRm9yIGxhbmd1YWdlcyB0aGF0IGhhdmUgbm8gSVNPIDYz OS0xIHR3byBjaGFyYWN0ZXIgY29kZSBhbmQgZm9yDQogICB3aGljaCB0aGUgSVNPIDYzOS0yL1Qg KFRlcm1pbm9sb2d5KSBjb2RlIGFuZCB0aGUgSVNPIDYzOS0yL0INCiAgIChCaWJsaW9ncmFwaGlj KSBjb2RlcyBkaWZmZXIsIG9ubHkgdGhlIFRlcm1pbm9sb2d5IGNvZGUgaXMgZGVmaW5lZCBpbg0K ICAgdGhlIElBTkEgcmVnaXN0cnkuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVh dGVkLCBhbGwNCiAgIGxhbmd1YWdlcyB0aGF0IGhhZCBib3RoIGtpbmRzIG9mIHRocmVlIGNoYXJh Y3RlciBjb2RlIHdlcmUgYWxzbw0KICAgYXNzaWduZWQgYSB0d28gY2hhcmFjdGVyIGNvZGU7IGl0 IGlzIG5vdCBleHBlY3RlZCB0aGF0IGZ1dHVyZQ0KICAgYXNzaWdubWVudHMgb2YgdGhpcyBuYXR1 cmUgd2lsbCBvY2N1ci4NCg0KICAgTm90ZTogVG8gYXZvaWQgcHJvYmxlbXMgd2l0aCB2ZXJzaW9u aW5nIGFuZCBzdWJ0YWcgY2hvaWNlIGFzDQogICBleHBlcmllbmNlZCBkdXJpbmcgdGhlIHRyYW5z aXRpb24gYmV0d2VlbiBSRkMgMTc2NiBhbmQgUkZDIDMwNjYsIGFzDQogICB3ZWxsIGFzIHRoZSBj YW5vbmljYWwgbmF0dXJlIG9mIHN1YnRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50LCB0aGUN CiAgIElTTyA2MzkgUmVnaXN0cmF0aW9uIEF1dGhvcml0eSBKb2ludCBBZHZpc29yeSBDb21taXR0 ZWUgKElTTyA2MzkvDQogICBSQS1KQUMpIGhhcyBpbmNsdWRlZCB0aGUgZm9sbG93aW5nIHN0YXRl bWVudCBpbiBbaXNvNjM5LnByaW5jaXBsZXNdOg0KDQogICAiQSBsYW5ndWFnZSBjb2RlIGFscmVh ZHkgaW4gSVNPIDYzOS0yIGF0IHRoZSBwb2ludCBvZiBmcmVlemluZyBJU08NCiAgIDYzOS0xIHNo YWxsIG5vdCBsYXRlciBiZSBhZGRlZCB0byBJU08gNjM5LTEuICBUaGlzIGlzIHRvIGVuc3VyZQ0K ICAgY29uc2lzdGVuY3kgaW4gdXNhZ2Ugb3ZlciB0aW1lLCBzaW5jZSB1c2VycyBhcmUgZGlyZWN0 ZWQgaW4gSW50ZXJuZXQNCiAgIGFwcGxpY2F0aW9ucyB0byBlbXBsb3kgdGhlIGFscGhhLTMgY29k ZSB3aGVuIGFuIGFscGhhLTIgY29kZSBmb3IgdGhhdA0KICAgbGFuZ3VhZ2UgaXMgbm90IGF2YWls YWJsZS4iDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIGluc3RhYmlsaXR5IGluIHRoZSBjYW5vbmlj YWwgZm9ybSBvZiB0YWdzLCBpZiBhIHR3bw0KICAgY2hhcmFjdGVyIGNvZGUgaXMgYWRkZWQgdG8g SVNPIDYzOS0xIGZvciBhIGxhbmd1YWdlIGZvciB3aGljaCBhIHRocmVlDQogICBjaGFyYWN0ZXIg Y29kZSB3YXMgYWxyZWFkeSBpbmNsdWRlZCBpbiBJU08gNjM5LTIsIHRoZSB0d28gY2hhcmFjdGVy DQogICBjb2RlIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQuICBTZWUgU2VjdGlvbiAzLjMuDQoNCiAg IEZvciBleGFtcGxlLCBpZiBzb21lIGNvbnRlbnQgd2VyZSB0YWdnZWQgd2l0aCAnaGF3JyAoSGF3 YWlpYW4pLCB3aGljaA0KICAgY3VycmVudGx5IGhhcyBubyB0d28gY2hhcmFjdGVyIGNvZGUsIHRo ZSB0YWcgd291bGQgbm90IGJlIGludmFsaWRhdGVkDQogICBpZiBJU08gNjM5LTEgd2VyZSB0byBh c3NpZ24gYSB0d28gY2hhcmFjdGVyIGNvZGUgdG8gdGhlIEhhd2FpaWFuDQogICBsYW5ndWFnZSBh dCBhIGxhdGVyIGRhdGUuDQoNCiAgIEZvciBleGFtcGxlLCBvbmUgb2YgdGhlIGdyYW5kZmF0aGVy ZWQgSUFOQSByZWdpc3RyYXRpb25zIGlzDQogICAiaS1lbm9jaGlhbiIuICBUaGUgc3VidGFnICdl bm9jaGlhbicgY291bGQgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQQ0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgIFtQ YWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICByZWdpc3RyeSBhcyBhIHByaW1hcnkg bGFuZ3VhZ2Ugc3VidGFnIChhc3N1bWluZyB0aGF0IElTTyA2MzkgZG9lcyBub3QNCiAgIHJlZ2lz dGVyIHRoaXMgbGFuZ3VhZ2UgZmlyc3QpLCBtYWtpbmcgdGFncyBzdWNoIGFzICJlbm9jaGlhbi1B USIgYW5kDQogICAiZW5vY2hpYW4tTGF0biIgdmFsaWQuDQoNCjIuMi4yICBFeHRlbmRlZCBMYW5n dWFnZSBTdWJ0YWdzDQoNCiAgIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIGV4dGVu ZGVkIGxhbmd1YWdlIHN1YnRhZ3M6DQoNCiAgIDEuICBUaHJlZSBsZXR0ZXIgc3VidGFncyBpbW1l ZGlhdGVseSBmb2xsb3dpbmcgdGhlIHByaW1hcnkgc3VidGFnIGFyZQ0KICAgICAgIHJlc2VydmVk IGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9uLCBhbnRpY2lwYXRpbmcgd29yayB0aGF0IGlzDQog ICAgICAgY3VycmVudGx5IHVuZGVyIHdheSBvbiBJU08gNjM5Lg0KDQogICAyLiAgRXh0ZW5kZWQg bGFuZ3VhZ2Ugc3VidGFncyBNVVNUIGZvbGxvdyB0aGUgcHJpbWFyeSBzdWJ0YWcgYW5kDQogICAg ICAgcHJlY2VkZSBhbnkgb3RoZXIgc3VidGFncy4NCg0KICAgMy4gIFRoZXJlIE1BWSBiZSB1cCB0 byB0aHJlZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzLg0KDQogICA0LiAgRXh0ZW5kZWQgbGFu Z3VhZ2Ugc3VidGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIG9yIHVzZWQgdG8gZm9ybQ0KICAg ICAgIGxhbmd1YWdlIHRhZ3MuICBUaGVpciBzeW50YXggaXMgZGVzY3JpYmVkIGhlcmUgc28gdGhh dA0KICAgICAgIGltcGxlbWVudGF0aW9ucyBjYW4gYmUgY29tcGF0aWJsZSB3aXRoIGFueSBmdXR1 cmUgcmV2aXNpb24gb2YNCiAgICAgICB0aGlzIGRvY3VtZW50IHdoaWNoIGRvZXMgcHJvdmlkZSBm b3IgdGhlaXIgcmVnaXN0cmF0aW9uLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcgcmVj b3Jkcywgb25jZSB0aGV5IGFwcGVhciBpbiB0aGUgcmVnaXN0cnksDQogICBNVVNUIGluY2x1ZGUg ZXhhY3RseSBvbmUgJ1ByZWZpeCcgZmllbGQgaW5kaWNhdGluZyBhbiBhcHByb3ByaWF0ZQ0KICAg bGFuZ3VhZ2Ugc3VidGFnIG9yIHNlcXVlbmNlIG9mIHN1YnRhZ3MgdGhhdCBNVVNUIGFsd2F5cyBh cHBlYXIgYXMgYQ0KICAgcHJlZml4IHRvIHRoZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcuDQoN CiAgIEV4YW1wbGU6IEluIGEgZnV0dXJlIHJldmlzaW9uIG9yIHVwZGF0ZSBvZiB0aGlzIGRvY3Vt ZW50LCB0aGUgdGFnDQogICAiemgtZ2FuIiAocmVnaXN0ZXJlZCB1bmRlciBSRkMgMzA2NikgbWln aHQgYmVjb21lIGEgdmFsaWQgbm9uLQ0KICAgZ3JhbmRmYXRoZXJlZCAodGhhdCBpcywgcmVkdW5k YW50KSB0YWcgaW4gd2hpY2ggdGhlIHN1YnRhZyAnZ2FuJw0KICAgbWlnaHQgcmVwcmVzZW50IHRo ZSBDaGluZXNlIGRpYWxlY3QgJ0dhbicuDQoNCjIuMi4zICBTY3JpcHQgU3VidGFnDQoNCiAgIFNj cmlwdCBzdWJ0YWdzIGFyZSB1c2VkIHRvIGluZGljYXRlIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBz eXN0ZW0NCiAgIHZhcmlhdGlvbnMgdGhhdCBkaXN0aW5ndWlzaCB0aGUgd3JpdHRlbiBmb3JtcyBv ZiBhIGxhbmd1YWdlIG9yIGl0cw0KICAgZGlhbGVjdHMuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFw cGx5IHRvIHRoZSBzY3JpcHQgc3VidGFnczoNCg0KICAgMS4gIEFsbCBmb3VyIGNoYXJhY3RlciBz dWJ0YWdzIHdlcmUgZGVmaW5lZCBhY2NvcmRpbmcgdG8NCiAgICAgICBbSVNPMTU5MjRdLS0iQ29k ZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgbmFtZXMgb2YNCiAgICAgICBzY3JpcHRz IjogYWxwaGEtNCBzY3JpcHQgY29kZXMsIG9yIHN1YnNlcXVlbnRseSBhc3NpZ25lZCBieSB0aGUN CiAgICAgICBJU08gMTU5MjQgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFy ZGl6YXRpb24gYm9kaWVzLA0KICAgICAgIGRlbm90aW5nIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBz eXN0ZW0gdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoDQogICAgICAgdGhpcyBsYW5ndWFnZS4NCg0K ICAgMi4gIFNjcmlwdCBzdWJ0YWdzIE1VU1QgaW1tZWRpYXRlbHkgZm9sbG93IHRoZSBwcmltYXJ5 IGxhbmd1YWdlDQogICAgICAgc3VidGFnIGFuZCBhbGwgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFn cyBhbmQgTVVTVCBvY2N1ciBiZWZvcmUNCiAgICAgICBhbnkgb3RoZXIgdHlwZSBvZiBzdWJ0YWcg ZGVzY3JpYmVkIGJlbG93Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIw MDUNCg0KDQogICAzLiAgVGhlIHNjcmlwdCBzdWJ0YWdzICdRYWFhJyB0aHJvdWdoICdRYWJ4JyBh cmUgcmVzZXJ2ZWQgZm9yIHByaXZhdGUNCiAgICAgICB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRo ZXNlIHN1YnRhZ3MgY29ycmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZA0KICAgICAgIGJ5IElTTyAx NTkyNCBmb3IgcHJpdmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZCBmb3Igbm9uLQ0K ICAgICAgIHJlZ2lzdGVyZWQgc2NyaXB0IHZhbHVlcy4gIFBsZWFzZSByZWZlciB0byBTZWN0aW9u IDQuNSBmb3IgbW9yZQ0KICAgICAgIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3Mu DQoNCiAgIDQuICBTY3JpcHQgc3VidGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIHVzaW5nIHRo ZSBwcm9jZXNzIGluDQogICAgICAgU2VjdGlvbiAzLjQgb2YgdGhpcyBkb2N1bWVudC4gIFZhcmlh bnQgc3VidGFncyBNQVkgYmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdpc3RyYXRpb24gZm9y IHRoYXQgcHVycG9zZS4NCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgc2NyaXB0 IHN1YnRhZyBpbiBhIGxhbmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgc2NyaXB0IHN1YnRhZyBT SE9VTEQgYmUgb21pdHRlZCB3aGVuIGl0IGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcNCiAgICAgICB2 YWx1ZSB0byB0aGUgdGFnIG9yIHdoZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnJ3MgcmVj b3JkDQogICAgICAgaW5jbHVkZXMgYSBTdXBwcmVzcy1TY3JpcHQgZmllbGQgbGlzdGluZyB0aGUg YXBwbGljYWJsZSBzY3JpcHQNCiAgICAgICBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6ICJzci1MYXRu IiByZXByZXNlbnRzIFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0Lg0KDQoy LjIuNCAgUmVnaW9uIFN1YnRhZw0KDQogICBSZWdpb24gc3VidGFncyBhcmUgdXNlZCB0byBpbmRp Y2F0ZSBsaW5ndWlzdGljIHZhcmlhdGlvbnMgYXNzb2NpYXRlZA0KICAgd2l0aCBvciBhcHByb3By aWF0ZSB0byBhIHNwZWNpZmljIGNvdW50cnksIHRlcnJpdG9yeSwgb3IgcmVnaW9uLg0KICAgVHlw aWNhbGx5LCBhIHJlZ2lvbiBzdWJ0YWcgaXMgdXNlZCB0byBpbmRpY2F0ZSByZWdpb25hbCBkaWFs ZWN0cyBvcg0KICAgdXNhZ2UsIG9yIHJlZ2lvbi1zcGVjaWZpYyBzcGVsbGluZyBjb252ZW50aW9u cy4gIEEgcmVnaW9uIHN1YnRhZyBjYW4NCiAgIGFsc28gYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGF0 IGNvbnRlbnQgaXMgZXhwcmVzc2VkIGluIGEgd2F5IHRoYXQgaXMNCiAgIGFwcHJvcHJpYXRlIGZv ciB1c2UgdGhyb3VnaG91dCBhIHJlZ2lvbjsgZm9yIGluc3RhbmNlLCBTcGFuaXNoDQogICBjb250 ZW50IHRhaWxvcmVkIHRvIGJlIHVzZWZ1bCB0aHJvdWdob3V0IExhdGluIEFtZXJpY2EuDQoNCiAg IFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIHJlZ2lvbiBzdWJ0YWdzOg0KDQogICAx LiAgUmVnaW9uIHN1YnRhZ3MgTVVTVCBmb2xsb3cgYW55IGxhbmd1YWdlLCBleHRlbmRlZCBsYW5n dWFnZSwgb3INCiAgICAgICBzY3JpcHQgc3VidGFncyBhbmQgTVVTVCBwcmVjZWRlIGFsbCBvdGhl ciBzdWJ0YWdzLg0KDQogICAyLiAgQWxsIHR3byBjaGFyYWN0ZXIgc3VidGFncyBmb2xsb3dpbmcg dGhlIHByaW1hcnkgc3VidGFnIHdlcmUNCiAgICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lz dHJ5IGFjY29yZGluZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQNCiAgICAgICBpbiBbSVNPMzE2 Ni0xXSAoIkNvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YNCiAgICAgICBj b3VudHJpZXMgYW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAtLSBQYXJ0IDE6IENvdW50cnkgY29kZXMi KSB1c2luZw0KICAgICAgIHRoZSBsaXN0IG9mIGFscGhhLTIgY291bnRyeSBjb2Rlcywgb3IgdXNp bmcgYXNzaWdubWVudHMNCiAgICAgICBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDMxNjYg bWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZw0KICAgICAgIHN0YW5kYXJkaXphdGlvbiBi b2RpZXMuDQoNCiAgIDMuICBBbGwgdGhyZWUgY2hhcmFjdGVyIHN1YnRhZ3MgY29uc2lzdGluZyBv ZiBkaWdpdCAobnVtZXJpYykNCiAgICAgICBjaGFyYWN0ZXJzIGZvbGxvd2luZyB0aGUgcHJpbWFy eSBzdWJ0YWcgd2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgYWNjb3Jk aW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiBVTiBTdGFuZGFyZA0KICAgICAgIENvdW50 cnkgb3IgQXJlYSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgIFVzZSBbVU5fTS40OV0gb3INCiAgICAg ICBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgZ292ZXJuaW5nIHN0YW5kYXJk cyBib2R5Lg0KICAgICAgIE5vdGUgdGhhdCBub3QgYWxsIG9mIHRoZSBVTiBNLjQ5IGNvZGVzIGFy ZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkuICBUaGUgZm9sbG93aW5nIHJ1 bGVzIGRlZmluZSB3aGljaCBjb2RlcyBhcmUgZW50ZXJlZA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAgaW50byB0aGUgcmVnaXN0cnkgYXMgdmFs aWQgc3VidGFnczoNCg0KICAgICAgIEEuICBVTiBudW1lcmljIGNvZGVzIGFzc2lnbmVkIHRvICdt YWNyby1nZW9ncmFwaGljYWwNCiAgICAgICAgICAgKGNvbnRpbmVudGFsKScgb3Igc3ViLXJlZ2lv bnMgTVVTVCBiZSByZWdpc3RlcmVkIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeS4gIFRoZXNl IGNvZGVzIGFyZSBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbmVkDQogICAgICAgICAgIElT TyAzMTY2IGFscGhhLTIgY29kZSBhbmQgcmVwcmVzZW50IHN1cHJhLW5hdGlvbmFsIGFyZWFzLA0K ICAgICAgICAgICB1c3VhbGx5IGNvdmVyaW5nIG1vcmUgdGhhbiBvbmUgbmF0aW9uLCBzdGF0ZSwg cHJvdmluY2UsIG9yDQogICAgICAgICAgIHRlcnJpdG9yeS4NCg0KICAgICAgIEIuICBVTiBudW1l cmljIGNvZGVzIGZvciAnZWNvbm9taWMgZ3JvdXBpbmdzJyBvciAnb3RoZXINCiAgICAgICAgICAg Z3JvdXBpbmdzJyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFu ZA0KICAgICAgICAgICBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0K ICAgICAgIEMuICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMgd2l0aCBh bWJpZ3VvdXMgSVNPDQogICAgICAgICAgIDMxNjYgYWxwaGEtMiBjb2Rlcywgd2hlbiBlbnRlcmVk IGludG8gdGhlIHJlZ2lzdHJ5LCBNVVNUIGJlDQogICAgICAgICAgIGRlZmluZWQgYWNjb3JkaW5n IHRvIHRoZSBydWxlcyBpbiBTZWN0aW9uIDMuMyBhbmQgTVVTVCBiZQ0KICAgICAgICAgICB1c2Vk IHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB0aGF0IHJlcHJlc2VudCB0aGUgY291bnRyeSBvcg0KICAg ICAgICAgICByZWdpb24gZm9yIHdoaWNoIHRoZXkgYXJlIGRlZmluZWQuDQoNCiAgICAgICBELiAg VU4gbnVtZXJpYyBjb2RlcyBmb3IgY291bnRyaWVzIG9yIGFyZWFzIGZvciB3aGljaCB0aGVyZSBp cyBhbg0KICAgICAgICAgICBhc3NvY2lhdGVkIElTTyAzMTY2IGFscGhhLTIgY29kZSBpbiB0aGUg cmVnaXN0cnkgTVVTVCBOT1QgYmUNCiAgICAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3Ry eSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0byBmb3JtDQogICAgICAgICAgIGxhbmd1YWdlIHRhZ3Mu ICBOb3RlIHRoYXQgdGhlIElTTyAzMTY2LWJhc2VkIHN1YnRhZyBpbiB0aGUNCiAgICAgICAgICAg cmVnaXN0cnkgTVVTVCBhY3R1YWxseSBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIFVOIE0uNDkgY29k ZSBpbg0KICAgICAgICAgICBxdWVzdGlvbi4NCg0KICAgICAgIEUuICBVTiBudW1lcmljIGNvZGVz IGFuZCBJU08gMzE2NiBhbHBoYS0yIGNvZGVzIGZvciBjb3VudHJpZXMgb3INCiAgICAgICAgICAg YXJlYXMgbGlzdGVkIGFzIGVsaWdpYmxlIGZvciByZWdpc3RyYXRpb24gaW4gW2luaXRpYWwtDQog ICAgICAgICAgIHJlZ2lzdHJ5XSBidXQgbm90IHByZXNlbnRseSByZWdpc3RlcmVkIE1BWSBiZSBl bnRlcmVkIGludG8NCiAgICAgICAgICAgdGhlIElBTkEgcmVnaXN0cnkgdmlhIHRoZSBwcm9jZXNz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNC4NCiAgICAgICAgICAgT25jZSByZWdpc3RlcmVkLCB0 aGVzZSBjb2RlcyBNQVkgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlDQogICAgICAgICAgIHRhZ3Mu DQoNCiAgICAgICBGLiAgQWxsIG90aGVyIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBv ciBhcmVhcyB3aGljaCBkbw0KICAgICAgICAgICBub3QgaGF2ZSBhbiBhc3NvY2lhdGVkIElTTyAz MTY2IGFscGhhLTIgY29kZSBNVVNUIE5PVCBiZQ0KICAgICAgICAgICBlbnRlcmVkIGludG8gdGhl IHJlZ2lzdHJ5IGFuZCBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0NCiAgICAgICAgICAgbGFuZ3Vh Z2UgdGFncy4gIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZXNlIGNvZGVzLCBzZWUNCiAg ICAgICAgICAgU2VjdGlvbiAzLjMuDQoNCiAgIDQuICBOb3RlOiBUaGUgYWxwaGFudW1lcmljIGNv ZGVzIGluIEFwcGVuZGl4IFggb2YgdGhlIFVOIGRvY3VtZW50DQogICAgICAgTVVTVCBOT1QgYmUg ZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0bw0KICAgICAg IGZvcm0gbGFuZ3VhZ2UgdGFncy4gIChBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVh dGVkIHRoZXNlDQogICAgICAgdmFsdWVzIG1hdGNoIHRoZSBJU08gMzE2NiBhbHBoYS0yIGNvZGVz LikNCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgcmVnaW9uIHN1YnRhZyBpbiBh IGxhbmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgcmVnaW9uIHN1YnRhZyBNQVkgYmUgb21pdHRl ZCwgYXMgd2hlbiBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQogICAgICAgdmFsdWUgdG8gdGhl IHRhZy4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAx NiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQog ICA2LiAgVGhlIHJlZ2lvbiBzdWJ0YWdzICdBQScsICdRTSctJ1FaJywgJ1hBJy0nWFonLCBhbmQg J1paJyBhcmUNCiAgICAgICByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1c2UgaW4gbGFuZ3VhZ2UgdGFn cy4gIFRoZXNlIHN1YnRhZ3MNCiAgICAgICBjb3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkIGJ5 IElTTyAzMTY2IGZvciBwcml2YXRlIHVzZS4gIFRoZXNlDQogICAgICAgY29kZXMgTUFZIGJlIHVz ZWQgZm9yIHByaXZhdGUgdXNlIHJlZ2lvbiBzdWJ0YWdzIChpbnN0ZWFkIG9mDQogICAgICAgdXNp bmcgYSBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2UpLiAgUGxlYXNlIHJlZmVyIHRvDQogICAg ICAgU2VjdGlvbiA0LjUgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gcHJpdmF0ZSB1c2Ugc3VidGFn cy4NCg0KICAgImRlLUNIIiByZXByZXNlbnRzIEdlcm1hbiAoJ2RlJykgYXMgdXNlZCBpbiBTd2l0 emVybGFuZCAoJ0NIJykuDQoNCiAgICJzci1MYXRuLUNTIiByZXByZXNlbnRzIFNlcmJpYW4gKCdz cicpIHdyaXR0ZW4gdXNpbmcgTGF0aW4gc2NyaXB0DQogICAoJ0xhdG4nKSBhcyB1c2VkIGluIFNl cmJpYSBhbmQgTW9udGVuZWdybyAoJ0NTJykuDQoNCiAgICJlcy00MTkiIHJlcHJlc2VudHMgU3Bh bmlzaCAoJ2VzJykgYXBwcm9wcmlhdGUgdG8gdGhlIFVOLWRlZmluZWQNCiAgIExhdGluIEFtZXJp Y2EgYW5kIENhcmliYmVhbiByZWdpb24gKCc0MTknKS4NCg0KMi4yLjUgIFZhcmlhbnQgU3VidGFn cw0KDQogICBWYXJpYW50IHN1YnRhZ3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgYWRkaXRpb25hbCwg d2VsbC1yZWNvZ25pemVkDQogICB2YXJpYXRpb25zIHRoYXQgZGVmaW5lIGEgbGFuZ3VhZ2Ugb3Ig aXRzIGRpYWxlY3RzIHdoaWNoIGFyZSBub3QNCiAgIGNvdmVyZWQgYnkgb3RoZXIgYXZhaWxhYmxl IHN1YnRhZ3MuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZQ0KICAgdmFyaWFudCBz dWJ0YWdzOg0KDQogICAxLiAgVmFyaWFudCBzdWJ0YWdzIGFyZSBub3QgYXNzb2NpYXRlZCB3aXRo IGFueSBleHRlcm5hbCBzdGFuZGFyZC4NCiAgICAgICBWYXJpYW50IHN1YnRhZ3MgYW5kIHRoZWly IG1lYW5pbmdzIGFyZSBkZWZpbmVkIGJ5IHRoZQ0KICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNz IGRlZmluZWQgaW4gU2VjdGlvbiAzLjQuDQoNCiAgIDIuICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBm b2xsb3cgYWxsIG9mIHRoZSBvdGhlciBkZWZpbmVkIHN1YnRhZ3MsIGJ1dA0KICAgICAgIHByZWNl ZGUgYW55IGV4dGVuc2lvbiBvciBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAz LiAgTW9yZSB0aGFuIG9uZSB2YXJpYW50IE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIGxhbmd1YWdl IHRhZy4NCg0KICAgNC4gIFZhcmlhbnQgc3VidGFncyBNVVNUIGJlIHJlZ2lzdGVyZWQgd2l0aCBJ QU5BIGFjY29yZGluZyB0byB0aGUNCiAgICAgICBydWxlcyBpbiBTZWN0aW9uIDMuNCBvZiB0aGlz IGRvY3VtZW50IGJlZm9yZSBiZWluZyB1c2VkIHRvIGZvcm0NCiAgICAgICBsYW5ndWFnZSB0YWdz LiAgSW4gb3JkZXIgdG8gZGlzdGluZ3Vpc2ggdmFyaWFudHMgZnJvbSBvdGhlciB0eXBlcw0KICAg ICAgIG9mIHN1YnRhZ3MsIHJlZ2lzdHJhdGlvbnMgTVVTVCBtZWV0IHRoZSBmb2xsb3dpbmcgbGVu Z3RoIGFuZA0KICAgICAgIGNvbnRlbnQgcmVzdHJpY3Rpb25zOg0KDQogICAgICAgMS4gIFZhcmlh bnQgc3VidGFncyB0aGF0IGJlZ2luIHdpdGggYSBsZXR0ZXIgKGEteiwgQS1aKSBNVVNUIGJlDQog ICAgICAgICAgIGF0IGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0KDQogICAgICAgMi4gIFZh cmlhbnQgc3VidGFncyB0aGF0IGJlZ2luIHdpdGggYSBkaWdpdCAoMC05KSBNVVNUIGJlIGF0DQog ICAgICAgICAgIGxlYXN0IGZvdXIgY2hhcmFjdGVycyBsb25nLg0KDQogICBWYXJpYW50IHN1YnRh ZyByZWNvcmRzIGluIHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkgTUFZIGluY2x1ZGUNCiAg IG9uZSBvciBtb3JlICdQcmVmaXgnIGZpZWxkcywgd2hpY2ggaW5kaWNhdGVzIHRoZSBsYW5ndWFn ZSB0YWcgb3IgdGFncw0KICAgdGhhdCB3b3VsZCBtYWtlIGEgc3VpdGFibGUgcHJlZml4ICh3aXRo IG90aGVyIHN1YnRhZ3MsIGFzDQogICBhcHByb3ByaWF0ZSkgaW4gZm9ybWluZyBhIGxhbmd1YWdl IHRhZyB3aXRoIHRoZSB2YXJpYW50LiAgRm9yDQogICBleGFtcGxlLCB0aGUgc3VidGFnICduZWRp cycgaGFzIGEgUHJlZml4IG9mICJzbCIsIG1ha2luZyBpdCBzdWl0YWJsZQ0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICB0byBmb3JtIGxhbmd1YWdlIHRh Z3Mgc3VjaCBhcyAic2wtbmVkaXMiIGFuZCAic2wtSVQtbmVkaXMiLCBidXQgbm90DQogICBzdWl0 YWJsZSBmb3IgdXNlIGluIGEgdGFnIHN1Y2ggYXMgInpoLW5lZGlzIiBvciAiaXQtSVQtbmVkaXMi Lg0KDQogICAic2wtbmVkaXMiIHJlcHJlc2VudHMgdGhlIE5hdGlzb25lIG9yIE5hZGl6YSBkaWFs ZWN0IG9mIFNsb3Zlbmlhbi4NCg0KICAgImRlLUNILTE5OTYiIHJlcHJlc2VudHMgR2VybWFuIGFz IHVzZWQgaW4gU3dpdHplcmxhbmQgYW5kIGFzIHdyaXR0ZW4NCiAgIHVzaW5nIHRoZSBzcGVsbGlu ZyByZWZvcm0gYmVnaW5uaW5nIGluIHRoZSB5ZWFyIDE5OTYgQy5FLg0KDQogICBNb3N0IHZhcmlh bnRzIHRoYXQgc2hhcmUgYSBwcmVmaXggYXJlIG11dHVhbGx5IGV4Y2x1c2l2ZS4gIEZvcg0KICAg ZXhhbXBsZSwgdGhlIEdlcm1hbiBvcnRob2dyYXBoaWMgdmFyaWF0aW9ucyAnMTk5NicgYW5kICcx OTAxJyBTSE9VTEQNCiAgIE5PVCBiZSB1c2VkIGluIHRoZSBzYW1lIHRhZywgYXMgdGhleSByZXBy ZXNlbnQgdGhlIGRhdGVzIG9mIGRpZmZlcmVudA0KICAgc3BlbGxpbmcgcmVmb3Jtcy4gIEEgdmFy aWFudCB0aGF0IGNhbiBtZWFuaW5nZnVsbHkgYmUgdXNlZCBpbg0KICAgY29tYmluYXRpb24gd2l0 aCBhbm90aGVyIHZhcmlhbnQgU0hPVUxEIGluY2x1ZGUgYSAnUHJlZml4JyBmaWVsZCBpbg0KICAg aXRzIHJlZ2lzdHJ5IHJlY29yZCB0aGF0IGxpc3RzIHRoYXQgb3RoZXIgdmFyaWFudC4gIEZvciBl eGFtcGxlLCBpZg0KICAgYW5vdGhlciBHZXJtYW4gdmFyaWFudCAnZXhhbXBsZScgd2VyZSBjcmVh dGVkIHRoYXQgbWFkZSBzZW5zZSB0byB1c2UNCiAgIHdpdGggJzE5OTYnLCB0aGVuICdleGFtcGxl JyBzaG91bGQgaW5jbHVkZSB0d28gUHJlZml4IGZpZWxkczogImRlIg0KICAgYW5kICJkZS0xOTk2 Ii4NCg0KMi4yLjYgIEV4dGVuc2lvbiBTdWJ0YWdzDQoNCiAgIEV4dGVuc2lvbnMgcHJvdmlkZSBh IG1lY2hhbmlzbSBmb3IgZXh0ZW5kaW5nIGxhbmd1YWdlIHRhZ3MgZm9yIHVzZSBpbg0KICAgdmFy aW91cyBhcHBsaWNhdGlvbnMuICBTZWU6IFNlY3Rpb24gMy42LiAgVGhlIGZvbGxvd2luZyBydWxl cyBhcHBseQ0KICAgdG8gZXh0ZW5zaW9uczoNCg0KICAgMS4gICBFeHRlbnNpb24gc3VidGFncyBh cmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0KICAgICAgICBpbiB0 aGlzIGRvY3VtZW50IGJ5IGEgc2luZ2xlIGNoYXJhY3RlciBzdWJ0YWcgKCJzaW5nbGV0b24iKS4N CiAgICAgICAgVGhlIHNpbmdsZXRvbiBNVVNUIGJlIG9uZSBhbGxvY2F0ZWQgdG8gYSByZWdpc3Ry YXRpb24gYXV0aG9yaXR5DQogICAgICAgIHZpYSB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDMuNiBhbmQgTVVTVCBOT1QgYmUgdGhlDQogICAgICAgIGxldHRlciAneCcsIHdoaWNo IGlzIHJlc2VydmVkIGZvciBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAyLiAg IE5vdGU6IFByaXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5jZXMgc3RhcnRpbmcgd2l0aCB0aGUgc2lu Z2xldG9uDQogICAgICAgIHN1YnRhZyAneCcgYXJlIGRlc2NyaWJlZCBiZWxvdy4NCg0KICAgMy4g ICBBbiBleHRlbnNpb24gTVVTVCBmb2xsb3cgYXQgbGVhc3QgYSBwcmltYXJ5IGxhbmd1YWdlIHN1 YnRhZy4NCiAgICAgICAgVGhhdCBpcywgYSBsYW5ndWFnZSB0YWcgY2Fubm90IGJlZ2luIHdpdGgg YW4gZXh0ZW5zaW9uLg0KICAgICAgICBFeHRlbnNpb25zIGV4dGVuZCBsYW5ndWFnZSB0YWdzLCB0 aGV5IGRvIG5vdCBvdmVycmlkZSBvciByZXBsYWNlDQogICAgICAgIHRoZW0uICBGb3IgZXhhbXBs ZSwgImEtdmFsdWUiIGlzIG5vdCBhIHdlbGwtZm9ybWVkIGxhbmd1YWdlIHRhZywNCiAgICAgICAg d2hpbGUgImRlLWEtdmFsdWUiIGlzLg0KDQogICA0LiAgIEVhY2ggc2luZ2xldG9uIHN1YnRhZyBN VVNUIGFwcGVhciBhdCBtb3N0IG9uZSB0aW1lIGluIGVhY2ggdGFnDQogICAgICAgIChvdGhlciB0 aGFuIGFzIGEgcHJpdmF0ZSB1c2Ugc3VidGFnKS4gIFRoYXQgaXMsIHNpbmdsZXRvbg0KICAgICAg ICBzdWJ0YWdzIE1VU1QgTk9UIGJlIHJlcGVhdGVkLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImVu LWEtYmJiLWEtDQogICAgICAgIGNjYyIgaXMgaW52YWxpZCBiZWNhdXNlIHRoZSBzdWJ0YWcgJ2En IGFwcGVhcnMgdHdpY2UuICBOb3RlIHRoYXQNCiAgICAgICAgdGhlIHRhZyAiZW4tYS1iYmIteC1h LWNjYyIgaXMgdmFsaWQgYmVjYXVzZSB0aGUgc2Vjb25kDQogICAgICAgIGFwcGVhcmFuY2Ugb2Yg dGhlIHNpbmdsZXRvbiAnYScgaXMgaW4gYSBwcml2YXRlIHVzZSBzZXF1ZW5jZS4NCg0KICAgNS4g ICBFeHRlbnNpb24gc3VidGFncyBNVVNUIG1lZXQgYWxsIG9mIHRoZSByZXF1aXJlbWVudHMgZm9y IHRoZQ0KICAgICAgICBjb250ZW50IGFuZCBmb3JtYXQgb2Ygc3VidGFncyBkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnQuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0K DQoNCiAgIDYuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IHdoYXRldmVyIHJlcXVpcmVt ZW50cyBhcmUgc2V0IGJ5IHRoZQ0KICAgICAgICBkb2N1bWVudCB0aGF0IGRlZmluZXMgdGhlaXIg c2luZ2xldG9uIHByZWZpeCBhbmQgd2hhdGV2ZXINCiAgICAgICAgcmVxdWlyZW1lbnRzIGFyZSBw cm92aWRlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5Lg0KDQogICA3LiAgIEVhY2ggZXh0 ZW5zaW9uIHN1YnRhZyBNVVNUIGJlIGZyb20gdHdvIHRvIGVpZ2h0IGNoYXJhY3RlcnMgbG9uZw0K ICAgICAgICBhbmQgY29uc2lzdCBzb2xlbHkgb2YgbGV0dGVycyBvciBkaWdpdHMsIHdpdGggZWFj aCBzdWJ0YWcNCiAgICAgICAgc2VwYXJhdGVkIGJ5IGEgc2luZ2xlICctJy4NCg0KICAgOC4gICBF YWNoIHNpbmdsZXRvbiBNVVNUIGJlIGZvbGxvd2VkIGJ5IGF0IGxlYXN0IG9uZSBleHRlbnNpb24N CiAgICAgICAgc3VidGFnLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgInRsaC1hLWItZm9vIiBpcyBp bnZhbGlkIGJlY2F1c2UNCiAgICAgICAgdGhlIGZpcnN0IHNpbmdsZXRvbiAnYScgaXMgZm9sbG93 ZWQgaW1tZWRpYXRlbHkgYnkgYW5vdGhlcg0KICAgICAgICBzaW5nbGV0b24gJ2InLg0KDQogICA5 LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1QgZm9sbG93IGFsbCBsYW5ndWFnZSwgZXh0ZW5kZWQg bGFuZ3VhZ2UsDQogICAgICAgIHNjcmlwdCwgcmVnaW9uIGFuZCB2YXJpYW50IHN1YnRhZ3MgaW4g YSB0YWcuDQoNCiAgIDEwLiAgQWxsIHN1YnRhZ3MgZm9sbG93aW5nIHRoZSBzaW5nbGV0b24gYW5k IGJlZm9yZSBhbm90aGVyIHNpbmdsZXRvbg0KICAgICAgICBhcmUgcGFydCBvZiB0aGUgZXh0ZW5z aW9uLiAgRXhhbXBsZTogSW4gdGhlIHRhZyAiZnItYS1MYXRuIiwgdGhlDQogICAgICAgIHN1YnRh ZyAnTGF0bicgZG9lcyBub3QgcmVwcmVzZW50IHRoZSBzY3JpcHQgc3VidGFnICdMYXRuJw0KICAg ICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4gIEl0cyBt ZWFuaW5nIGlzDQogICAgICAgIGRlZmluZWQgYnkgdGhlIGV4dGVuc2lvbiAnYScuDQoNCiAgIDEx LiAgSW4gdGhlIGV2ZW50IHRoYXQgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24gYXBwZWFycyBpbiBh IHNpbmdsZQ0KICAgICAgICB0YWcsIHRoZSB0YWcgU0hPVUxEIGJlIGNhbm9uaWNhbGl6ZWQgYXMg ZGVzY3JpYmVkIGluDQogICAgICAgIFNlY3Rpb24gNC40Lg0KDQogICBGb3IgZXhhbXBsZSwgaWYg dGhlIHByZWZpeCBzaW5nbGV0b24gJ3InIGFuZCB0aGUgc2hvd24gc3VidGFncyB3ZXJlDQogICBk ZWZpbmVkLCB0aGVuIHRoZSBmb2xsb3dpbmcgdGFnIHdvdWxkIGJlIGEgdmFsaWQgZXhhbXBsZTog ImVuLUxhdG4tDQogICBHQi1ib29udC1yLWV4dGVuZGVkLXNlcXVlbmNlLXgtcHJpdmF0ZSINCg0K Mi4yLjcgIFByaXZhdGUgVXNlIFN1YnRhZ3MNCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFncyBhcmUg dXNlZCB0byBpbmRpY2F0ZSBkaXN0aW5jdGlvbnMgaW4gbGFuZ3VhZ2UNCiAgIGltcG9ydGFudCBp biBhIGdpdmVuIGNvbnRleHQgYnkgcHJpdmF0ZSBhZ3JlZW1lbnQuICBUaGUgZm9sbG93aW5nDQog ICBydWxlcyBhcHBseSB0byBwcml2YXRlIHVzZSBzdWJ0YWdzOg0KDQogICAxLiAgUHJpdmF0ZSB1 c2Ugc3VidGFncyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0K ICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgdGhlIHJlc2VydmVkIHNpbmdsZS1jaGFyYWN0ZXIg c3VidGFnICd4Jy4NCg0KICAgMi4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgTVVTVCBjb25mb3JtIHRv IHRoZSBmb3JtYXQgYW5kIGNvbnRlbnQNCiAgICAgICBjb25zdHJhaW50cyBkZWZpbmVkIGluIHRo ZSBBQk5GIGZvciBhbGwgc3VidGFncy4NCg0KICAgMy4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgTVVT VCBmb2xsb3cgYWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwNCiAgICAgICBzY3JpcHQs IHJlZ2lvbiwgdmFyaWFudCwgYW5kIGV4dGVuc2lvbiBzdWJ0YWdzIGluIHRoZSB0YWcuDQogICAg ICAgQW5vdGhlciB3YXkgb2Ygc2F5aW5nIHRoaXMgaXMgdGhhdCBhbGwgc3VidGFncyBmb2xsb3dp bmcgdGhlDQogICAgICAgc2luZ2xldG9uICd4JyBNVVNUIGJlIGNvbnNpZGVyZWQgcHJpdmF0ZSB1 c2UuICBFeGFtcGxlOiBUaGUNCiAgICAgICBzdWJ0YWcgJ1VTJyBpbiB0aGUgdGFnICJlbi14LVVT IiBpcyBhIHByaXZhdGUgdXNlIHN1YnRhZy4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgQXVndXN0IDIwMDUNCg0KDQogICA0LiAgQSB0YWcgTUFZIGNvbnNpc3QgZW50aXJlbHkgb2Yg cHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0KICAgNS4gIE5vIHNvdXJjZSBpcyBkZWZpbmVkIGZvciBw cml2YXRlIHVzZSBzdWJ0YWdzLiAgVXNlIG9mIHByaXZhdGUgdXNlDQogICAgICAgc3VidGFncyBp cyBieSBwcml2YXRlIGFncmVlbWVudCBvbmx5Lg0KDQogICA2LiAgUHJpdmF0ZSB1c2Ugc3VidGFn cyBhcmUgTk9UIFJFQ09NTUVOREVEIHdoZXJlIGFsdGVybmF0aXZlcyBleGlzdA0KICAgICAgIG9y IGZvciBnZW5lcmFsIGludGVyY2hhbmdlLiAgU2VlIFNlY3Rpb24gNC41IGZvciBtb3JlIGluZm9y bWF0aW9uDQogICAgICAgb24gcHJpdmF0ZSB1c2Ugc3VidGFnIGNob2ljZS4NCg0KICAgRm9yIGV4 YW1wbGU6IFVzZXJzIHdobyB3aXNoZWQgdG8gdXRpbGl6ZSBjb2RlcyBmcm9tIHRoZSBFdGhub2xv Z3VlDQogICBwdWJsaWNhdGlvbiBvZiBTSUwgSW50ZXJuYXRpb25hbCBmb3IgbGFuZ3VhZ2UgaWRl bnRpZmljYXRpb24gbWlnaHQNCiAgIGFncmVlIHRvIGV4Y2hhbmdlIHRhZ3Mgc3VjaCBhcyAiYXot QXJhYi14LUFaRS1kZXJiZW5kIi4gIFRoaXMgZXhhbXBsZQ0KICAgY29udGFpbnMgdHdvIHByaXZh dGUgdXNlIHN1YnRhZ3MuICBUaGUgZmlyc3QgaXMgJ0FaRScgYW5kIHRoZSBzZWNvbmQNCiAgIGlz ICdkZXJiZW5kJy4NCg0KMi4yLjggIFByZS1FeGlzdGluZyBSRkMgMzA2NiBSZWdpc3RyYXRpb25z DQoNCiAgIEV4aXN0aW5nIElBTkEtcmVnaXN0ZXJlZCBsYW5ndWFnZSB0YWdzIGZyb20gUkZDIDE3 NjYgYW5kL29yIFJGQyAzMDY2DQogICBtYWludGFpbiB0aGVpciB2YWxpZGl0eS4gIFRoZXNlIHRh Z3Mgd2lsbCBiZSBtYWludGFpbmVkIGluIHRoZQ0KICAgcmVnaXN0cnkgaW4gcmVjb3JkcyBvZiBl aXRoZXIgdGhlICJncmFuZGZhdGhlcmVkIiBvciAicmVkdW5kYW50Ig0KICAgdHlwZS4gIEZvciBt b3JlIGluZm9ybWF0aW9uIHNlZSBTZWN0aW9uIDMuNy4NCg0KICAgSXQgaXMgaW1wb3J0YW50IHRv IG5vdGUgdGhhdCBhbGwgbGFuZ3VhZ2UgdGFncyBmb3JtZWQgdW5kZXIgdGhlDQogICBndWlkZWxp bmVzIGluIHRoaXMgZG9jdW1lbnQgd2VyZSBlaXRoZXIgbGVnYWwsIHdlbGwtZm9ybWVkIHRhZ3Mg b3INCiAgIGNvdWxkIGhhdmUgYmVlbiByZWdpc3RlcmVkIHVuZGVyIFJGQyAzMDY2Lg0KDQoyLjIu OSAgQ2xhc3NlcyBvZiBDb25mb3JtYW5jZQ0KDQogICBJbXBsZW1lbnRhdGlvbnMgc29tZXRpbWVz IG5lZWQgdG8gZGVzY3JpYmUgdGhlaXIgY2FwYWJpbGl0aWVzIHdpdGgNCiAgIHJlZ2FyZCB0byB0 aGUgcnVsZXMgYW5kIHByYWN0aWNlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZXJl DQogICBhcmUgdHdvIGNsYXNzZXMgb2YgY29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbnMgZGVzY3Jp YmVkIGJ5IHRoaXMNCiAgIGRvY3VtZW50OiAid2VsbC1mb3JtZWQiIHByb2Nlc3NvcnMgYW5kICJ2 YWxpZGF0aW5nIiBwcm9jZXNzb3JzLg0KICAgQ2xhaW1zIG9mIGNvbmZvcm1hbmNlIFNIT1VMRCBl eHBsaWNpdGx5IHJlZmVyZW5jZSBvbmUgb2YgdGhlc2UNCiAgIGRlZmluaXRpb25zLg0KDQogICBB biBpbXBsZW1lbnRhdGlvbiB0aGF0IGNsYWltcyB0byBjaGVjayBmb3Igd2VsbC1mb3JtZWQgbGFu Z3VhZ2UgdGFncw0KICAgTVVTVDoNCg0KICAgbyAgQ2hlY2sgdGhhdCB0aGUgdGFnIGFuZCBhbGwg b2YgaXRzIHN1YnRhZ3MsIGluY2x1ZGluZyBleHRlbnNpb24gYW5kDQogICAgICBwcml2YXRlIHVz ZSBzdWJ0YWdzLCBjb25mb3JtIHRvIHRoZSBBQk5GIG9yIHRoYXQgdGhlIHRhZyBpcyBvbiB0aGUN CiAgICAgIGxpc3Qgb2YgZ3JhbmRmYXRoZXJlZCB0YWdzLg0KDQogICBvICBDaGVjayB0aGF0IHNp bmdsZXRvbiBzdWJ0YWdzIHRoYXQgaWRlbnRpZnkgZXh0ZW5zaW9ucyBkbyBub3QNCiAgICAgIHJl cGVhdC4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJlbi1hLXh4LWIteXktYS16eiIgaXMgbm90IHdl bGwtDQogICAgICBmb3JtZWQuDQoNCiAgIFdlbGwtZm9ybWVkIHByb2Nlc3NvcnMgYXJlIHN0cm9u Z2x5IGVuY291cmFnZWQgdG8gaW1wbGVtZW50IHRoZQ0KICAgY2Fub25pY2FsaXphdGlvbiBydWxl cyBjb250YWluZWQgaW4gU2VjdGlvbiA0LjQuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICBBdWd1c3QgMjAwNQ0KDQoNCiAgIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgY2xhaW1zIHRvIGJl IHZhbGlkYXRpbmcgTVVTVDoNCg0KICAgbyAgQ2hlY2sgdGhhdCB0aGUgdGFnIGlzIHdlbGwtZm9y bWVkLg0KDQogICBvICBTcGVjaWZ5IHRoZSBwYXJ0aWN1bGFyIHJlZ2lzdHJ5IGRhdGUgZm9yIHdo aWNoIHRoZSBpbXBsZW1lbnRhdGlvbg0KICAgICAgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBzdWJ0 YWdzLg0KDQogICBvICBDaGVjayB0aGF0IGVpdGhlciB0aGUgdGFnIGlzIGEgZ3JhbmRmYXRoZXJl ZCB0YWcsIG9yIHRoYXQgYWxsDQogICAgICBsYW5ndWFnZSwgc2NyaXB0LCByZWdpb24sIGFuZCB2 YXJpYW50IHN1YnRhZ3MgY29uc2lzdCBvZiB2YWxpZA0KICAgICAgY29kZXMgZm9yIHVzZSBpbiBs YW5ndWFnZSB0YWdzIGFjY29yZGluZyB0byB0aGUgSUFOQSByZWdpc3RyeSBhcw0KICAgICAgb2Yg dGhlIHBhcnRpY3VsYXIgZGF0ZSBzcGVjaWZpZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uLg0KDQog ICBvICBTcGVjaWZ5IHdoaWNoLCBpZiBhbnksIGV4dGVuc2lvbiBSRkNzIGFzIGRlZmluZWQgaW4g U2VjdGlvbiAzLjYNCiAgICAgIGFyZSBzdXBwb3J0ZWQsIGluY2x1ZGluZyB2ZXJzaW9uLCByZXZp c2lvbiwgYW5kIGRhdGUuDQoNCiAgIG8gIEZvciBhbnkgc3VjaCBleHRlbnNpb25zIHN1cHBvcnRl ZCwgY2hlY2sgdGhhdCBhbGwgc3VidGFncyB1c2VkIGluDQogICAgICB0aGF0IGV4dGVuc2lvbiBh cmUgdmFsaWQuDQoNCiAgIG8gIEZvciB2YXJpYW50IGFuZCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0 YWdzLCBpZiB0aGUgcmVnaXN0cnkNCiAgICAgIGNvbnRhaW5zIG9uZSBvciBtb3JlICdQcmVmaXgn IGZpZWxkcyBmb3IgdGhhdCBzdWJ0YWcsIGNoZWNrIHRoYXQNCiAgICAgIHRoZSB0YWcgbWF0Y2hl cyBhdCBsZWFzdCBvbmUgcHJlZml4LiAgVGhlIHRhZyBtYXRjaGVzIGlmIGFsbCB0aGUNCiAgICAg IHN1YnRhZ3MgaW4gdGhlICdQcmVmaXgnIGFsc28gYXBwZWFyIGluIHRoZSB0YWcuICBGb3IgZXhh bXBsZSwgdGhlDQogICAgICBwcmVmaXggImVzLUNPIiBtYXRjaGVzIHRoZSB0YWcgImVzLUxhdG4t Q08teC1wcml2YXRlIiBiZWNhdXNlIGJvdGgNCiAgICAgIHRoZSAnZXMnIGxhbmd1YWdlIHN1YnRh ZyBhbmQgJ0NPJyByZWdpb24gc3VidGFnIGFwcGVhciBpbiB0aGUgdGFnLg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTdd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQozLiAgUmVnaXN0cnkgRm9ybWF0IGFuZCBNYWludGVu YW5jZQ0KDQogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lz dHJ5IGFuZCB0aGUgbWFpbnRlbmFuY2UNCiAgIGFuZCB1cGRhdGUgcHJvY2VkdXJlcyBhc3NvY2lh dGVkIHdpdGggaXQsIGFzIHdlbGwgYXMgYSByZWdpc3RyeSBmb3INCiAgIGV4dGVuc2lvbnMgdG8g bGFuZ3VhZ2UgdGFncyAoU2VjdGlvbiAzLjYpLg0KDQogICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJl Z2lzdHJ5IGNvbnRhaW5zIGEgY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGFsbCBvZg0KICAgdGhlIHN1 YnRhZ3MgdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoaXMgYWxsb3dzIGltcGxlbWVudGVycyBh DQogICBzdHJhaWdodGZvcndhcmQgYW5kIHJlbGlhYmxlIHdheSB0byB2YWxpZGF0ZSBsYW5ndWFn ZSB0YWdzLiAgVGhlDQogICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgd2lsbCBiZSBtYWludGFp bmVkIHNvIHRoYXQsIGV4Y2VwdCBmb3INCiAgIGV4dGVuc2lvbiBzdWJ0YWdzLCBpdCBpcyBwb3Nz aWJsZSB0byB2YWxpZGF0ZSBhbGwgb2YgdGhlIHN1YnRhZ3MgdGhhdA0KICAgYXBwZWFyIGluIGEg bGFuZ3VhZ2UgdGFnIHVuZGVyIHRoZSBwcm92aXNpb25zIG9mIHRoaXMgZG9jdW1lbnQgb3IgaXRz DQogICByZXZpc2lvbnMgb3Igc3VjY2Vzc29ycy4gIEluIGFkZGl0aW9uLCB0aGUgbWVhbmluZyBv ZiB0aGUgdmFyaW91cw0KICAgc3VidGFncyB3aWxsIGJlIHVuYW1iaWd1b3VzIGFuZCBzdGFibGUg b3ZlciB0aW1lLiAgKFRoZSBtZWFuaW5nIG9mDQogICBwcml2YXRlIHVzZSBzdWJ0YWdzLCBvZiBj b3Vyc2UsIGlzIG5vdCBkZWZpbmVkIGJ5IHRoZSBJQU5BIHJlZ2lzdHJ5LikNCg0KMy4xICBGb3Jt YXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5DQoNCiAgIFRoZSBJQU5BIExh bmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAoInRoZSByZWdpc3RyeSIpIGNvbnNpc3RzIG9mIGEgdGV4 dA0KICAgZmlsZSB0aGF0IGlzIG1hY2hpbmUgcmVhZGFibGUgaW4gdGhlIGZvcm1hdCBkZXNjcmli ZWQgaW4gdGhpcw0KICAgc2VjdGlvbiwgcGx1cyBjb3BpZXMgb2YgdGhlIHJlZ2lzdHJhdGlvbiBm b3JtcyBhcHByb3ZlZCBieSB0aGUNCiAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBpbiBhY2Nv cmRhbmNlIHdpdGggdGhlIHByb2Nlc3MgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDMuNC4gIFdp dGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUgcmVnaXN0cmF0aW9uIGZvcm1zIGZvcg0KICAgZ3JhbmRm YXRoZXJlZCBhbmQgcmVkdW5kYW50IHRhZ3MsIG5vIHJlZ2lzdHJhdGlvbiByZWNvcmRzIHdpbGwg YmUNCiAgIG1haW50YWluZWQgZm9yIHRoZSBpbml0aWFsIHNldCBvZiBzdWJ0YWdzLg0KDQogICBU aGUgcmVnaXN0cnkgaXMgaW4gYSBtb2RpZmllZCByZWNvcmQtamFyIGZvcm1hdCB0ZXh0IGZpbGUg W3JlY29yZC0NCiAgIGphcl0uICBMaW5lcyBhcmUgbGltaXRlZCB0byA3MiBjaGFyYWN0ZXJzLCBp bmNsdWRpbmcgYWxsIHdoaXRlc3BhY2UuDQoNCiAgIFJlY29yZHMgYXJlIHNlcGFyYXRlZCBieSBs aW5lcyBjb250YWluaW5nIG9ubHkgdGhlIHNlcXVlbmNlICIlJSINCiAgICgleDI1LjI1KS4NCg0K ICAgRWFjaCBmaWVsZCBjYW4gYmUgdmlld2VkIGFzIGEgc2luZ2xlLCBsb2dpY2FsIGxpbmUgIG9m IEFTQ0lJDQogICBjaGFyYWN0ZXJzLCAgY29tcHJpc2luZyBhIGZpZWxkLW5hbWUgYW5kIGEgZmll bGQtYm9keSBzZXBhcmF0ZWQgYnkgYQ0KICAgQ09MT04gY2hhcmFjdGVyICgleDNBKS4gIEZvciBj b252ZW5pZW5jZSwgdGhlIGZpZWxkLWJvZHkgcG9ydGlvbiAgb2YNCiAgIHRoaXMgIGNvbmNlcHR1 YWwgZW50aXR5ICBjYW4gYmUgc3BsaXQgaW50byBhIG11bHRpcGxlLWxpbmUNCiAgIHJlcHJlc2Vu dGF0aW9uOyB0aGlzIGlzIGNhbGxlZCAiZm9sZGluZyIuICBUaGUgZm9ybWF0IG9mIHRoZSByZWdp c3RyeQ0KICAgaXMgZGVzY3JpYmVkIGJ5IHRoZSBmb2xsb3dpbmcgQUJORiAocGVyIFtSRkMyMjM0 YmlzXSk6DQoNCiAgIHJlZ2lzdHJ5ICAgPSByZWNvcmQgKigiJSUiIENSTEYgcmVjb3JkKQ0KICAg cmVjb3JkICAgICA9IDEqKCBmaWVsZC1uYW1lICpTUCAiOiIgKlNQIGZpZWxkLWJvZHkgQ1JMRiAp DQogICBmaWVsZC1uYW1lID0gKEFMUEhBIC8gRElHSVQpWyooQUxQSEEgLyBESUdJVCAvICItIikg KEFMUEhBIC8gRElHSVQpXQ0KICAgZmllbGQtYm9keSA9ICooQVNDQ0hBUi9MV1NQKQ0KICAgQVND Q0hBUiAgICA9ICV4MjEtMjUgLyAleDI3LTdFIC8gVU5JQ0hBUiA7IE5vdGU6IEFNUEVSU0FORCBp cyAleDI2DQogICBVTklDSEFSICAgID0gIiYjeCIgMio2SEVYRElHICI7Ig0KDQogICBUaGUgc2Vx dWVuY2UgJy4uJyAoJXgyRS4yRSkgaW4gYSBmaWVsZC1ib2R5IGRlbm90ZXMgYSByYW5nZSBvZg0K ICAgdmFsdWVzLiAgU3VjaCBhIHJhbmdlIHJlcHJlc2VudHMgYWxsIHN1YnRhZ3Mgb2YgdGhlIHNh bWUgbGVuZ3RoIHRoYXQNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1 DQoNCg0KICAgYXJlIGFscGhhYmV0aWNhbGx5IHdpdGhpbiB0aGF0IHJhbmdlLCBpbmNsdWRpbmcg dGhlIHZhbHVlcyBleHBsaWNpdGx5DQogICBtZW50aW9uZWQuICBGb3IgZXhhbXBsZSAnYS4uYycg ZGVub3RlcyB0aGUgdmFsdWVzICdhJywgJ2InLCBhbmQgJ2MnLg0KDQogICBDaGFyYWN0ZXJzIGZy b20gb3V0c2lkZSB0aGUgVVMtQVNDSUlbSVNPNjQ2XSByZXBlcnRvaXJlLCBhcyB3ZWxsIGFzDQog ICB0aGUgQU1QRVJTQU5EIGNoYXJhY3RlciAoIiYiLCAleDI2KSB3aGVuIGl0IG9jY3VycyBpbiBh IGZpZWxkLWJvZHkNCiAgIGFyZSByZXByZXNlbnRlZCBieSBhICJOdW1lcmljIENoYXJhY3RlciBS ZWZlcmVuY2UiIHVzaW5nIGhleGFkZWNpbWFsDQogICBub3RhdGlvbiBpbiB0aGUgc3R5bGUgdXNl ZCBieSBbWE1MMTBdIChzZWUNCiAgIDxodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMteG1sLyNkdC1j aGFycmVmPikuICBUaGlzIGNvbnNpc3RzIG9mIHRoZQ0KICAgc2VxdWVuY2UgIiYjeCIgKCV4MjYu MjMuNzgpIGZvbGxvd2VkIGJ5IGEgaGV4YWRlY2ltYWwgcmVwcmVzZW50YXRpb24NCiAgIG9mIHRo ZSBjaGFyYWN0ZXIncyBjb2RlIHBvaW50IGluIFtJU08xMDY0Nl0gZm9sbG93ZWQgYnkgYSBjbG9z aW5nDQogICBzZW1pY29sb24gKCV4M0IpLiAgRm9yIGV4YW1wbGUsIHRoZSBFVVJPIFNJR04sIFUr MjBBQywgd291bGQgYmUNCiAgIHJlcHJlc2VudGVkIGJ5IHRoZSBzZXF1ZW5jZSAiJiN4MjBBQzsi LiAgTm90ZSB0aGF0IHRoZSBoZXhhZGVjaW1hbA0KICAgbm90YXRpb24gTUFZIGhhdmUgYmV0d2Vl biB0d28gYW5kIHNpeCBkaWdpdHMuDQoNCiAgIEFsbCBmaWVsZHMgd2hvc2UgZmllbGQtYm9keSBj b250YWlucyBhIGRhdGUgdmFsdWUgdXNlIHRoZSAiZnVsbC1kYXRlIg0KICAgZm9ybWF0IHNwZWNp ZmllZCBpbiBbUkZDMzMzOV0uICBGb3IgZXhhbXBsZTogIjIwMDQtMDYtMjgiIHJlcHJlc2VudHMN CiAgIEp1bmUgMjgsIDIwMDQgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhci4NCg0KICAgVGhlIGZp cnN0IHJlY29yZCBpbiB0aGUgZmlsZSBjb250YWlucyB0aGUgc2luZ2xlIGZpZWxkIHdob3NlIGZp ZWxkLQ0KICAgbmFtZSBpcyAiRmlsZS1EYXRlIi4gIFRoZSBmaWVsZC1ib2R5IG9mIHRoaXMgcmVj b3JkIGNvbnRhaW5zIHRoZSBsYXN0DQogICBtb2RpZmljYXRpb24gZGF0ZSBvZiB0aGlzIGNvcHkg b2YgdGhlIHJlZ2lzdHJ5LCBtYWtpbmcgaXQgcG9zc2libGUgdG8NCiAgIGNvbXBhcmUgZGlmZmVy ZW50IHZlcnNpb25zIG9mIHRoZSByZWdpc3RyeS4gIFRoZSByZWdpc3RyeSBvbiB0aGUgSUFOQQ0K ICAgd2Vic2l0ZSBpcyB0aGUgbW9zdCBjdXJyZW50LiAgVmVyc2lvbnMgd2l0aCBhbiBvbGRlciBk YXRlIHRoYW4gdGhhdA0KICAgb25lIGFyZSBub3QgdXAtdG8tZGF0ZS4NCg0KICAgRmlsZS1EYXRl OiAyMDA0LTA2LTI4DQogICAlJQ0KDQogICBTdWJzZXF1ZW50IHJlY29yZHMgcmVwcmVzZW50IHN1 YnRhZ3MgaW4gdGhlIHJlZ2lzdHJ5LiAgRWFjaCBvZiB0aGUNCiAgIGZpZWxkcyBpbiBlYWNoIHJl Y29yZCBNVVNUIG9jY3VyIG5vIG1vcmUgdGhhbiBvbmNlLCB1bmxlc3Mgb3RoZXJ3aXNlDQogICBu b3RlZCBiZWxvdy4gIEVhY2ggcmVjb3JkIE1VU1QgY29udGFpbiB0aGUgZm9sbG93aW5nIGZpZWxk czoNCg0KICAgbyAgJ1R5cGUnDQoNCiAgICAgICogIFR5cGUncyBmaWVsZC12YWx1ZSBNVVNUIGNv bnNpc3Qgb2Ygb25lIG9mIHRoZSBmb2xsb3dpbmcNCiAgICAgICAgIHN0cmluZ3M6ICJsYW5ndWFn ZSIsICJleHRsYW5nIiwgInNjcmlwdCIsICJyZWdpb24iLCAidmFyaWFudCIsDQogICAgICAgICAi Z3JhbmRmYXRoZXJlZCIsIGFuZCAicmVkdW5kYW50IiBhbmQgZGVub3RlcyB0aGUgdHlwZSBvZiB0 YWcgb3INCiAgICAgICAgIHN1YnRhZy4NCg0KICAgbyAgRWl0aGVyICdTdWJ0YWcnIG9yICdUYWcn DQoNCiAgICAgICogIFN1YnRhZydzIGZpZWxkLXZhbHVlIGNvbnRhaW5zIHRoZSBzdWJ0YWcgYmVp bmcgZGVmaW5lZC4gIFRoaXMNCiAgICAgICAgIGZpZWxkIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVj b3JkcyBvZiB3aG9zZSAnVHlwZScgaGFzIG9uZSBvZg0KICAgICAgICAgdGhlc2UgdmFsdWVzOiAi bGFuZ3VhZ2UiLCAiZXh0bGFuZyIsICJzY3JpcHQiLCAicmVnaW9uIiwgb3INCiAgICAgICAgICJ2 YXJpYW50Ii4NCg0KICAgICAgKiAgVGFnJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBjb21wbGV0 ZSBsYW5ndWFnZSB0YWcuICBUaGlzIGZpZWxkDQogICAgICAgICBNVVNUIG9ubHkgYXBwZWFyIGlu IHJlY29yZHMgd2hvc2UgJ1R5cGUnIGhhcyBvbmUgb2YgdGhlc2UNCg0KDQoNClBoaWxsaXBzICYg RGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdl IDE5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgICAgdmFsdWVzOiAiZ3JhbmRmYXRo ZXJlZCIgb3IgInJlZHVuZGFudCIuDQoNCiAgIG8gIERlc2NyaXB0aW9uDQoNCiAgICAgICogIERl c2NyaXB0aW9uJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBub24tbm9ybWF0aXZlIGRlc2NyaXB0 aW9uDQogICAgICAgICBvZiB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgQWRkZWQNCg0KICAg ICAgKiAgQWRkZWQncyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdh cyBhZGRlZCB0bw0KICAgICAgICAgdGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgJ1N1YnRhZycgb3Ig J1RhZycgZmllbGQgTVVTVCB1c2UgbG93ZXJjYXNlIGxldHRlcnMgdG8gZm9ybSB0aGUNCiAgIHN1 YnRhZyBvciB0YWcsIHdpdGggdHdvIGV4Y2VwdGlvbnMuICBTdWJ0YWdzIHdob3NlICdUeXBlJyBm aWVsZCBpcw0KICAgJ3NjcmlwdCcgKGluIG90aGVyIHdvcmRzLCBzdWJ0YWdzIGRlZmluZWQgYnkg SVNPIDE1OTI0KSBNVVNUIHVzZQ0KICAgdGl0bGVjYXNlLiAgU3VidGFncyB3aG9zZSAnVHlwZScg ZmllbGQgaXMgJ3JlZ2lvbicgKGluIG90aGVyIHdvcmRzLA0KICAgc3VidGFncyBkZWZpbmVkIGJ5 IElTTyAzMTY2KSBNVVNUIHVzZSB1cHBlcmNhc2UuICBUaGVzZSBleGNlcHRpb25zDQogICBtaXJy b3IgdGhlIHVzZSBvZiBjYXNlIGluIHRoZSB1bmRlcmx5aW5nIHN0YW5kYXJkcy4NCg0KICAgVGhl IGZpZWxkICdEZXNjcmlwdGlvbicgTUFZIGFwcGVhciBtb3JlIHRoYW4gb25lIHRpbWUuICBBdCBs ZWFzdCBvbmUNCiAgIG9mIHRoZSAgJ0Rlc2NyaXB0aW9uJyBmaWVsZHMgTVVTVCBjb250YWluIGEg ZGVzY3JpcHRpb24gb2YgdGhlIHRhZw0KICAgYmVpbmcgcmVnaXN0ZXJlZCB3cml0dGVuIG9yIHRy YW5zY3JpYmVkIGludG8gdGhlIExhdGluIHNjcmlwdDsgdGhlDQogICBzYW1lIG9yIGFkZGl0aW9u YWwgZmllbGRzIE1BWSBhbHNvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5vbi0NCiAgIExh dGluIHNjcmlwdC4gIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGlzIHVzZWQgZm9yIGlkZW50aWZp Y2F0aW9uDQogICBwdXJwb3NlcyBhbmQgU0hPVUxEIE5PVCBiZSB0YWtlbiB0byByZXByZXNlbnQg dGhlIGFjdHVhbCBuYXRpdmUgbmFtZQ0KICAgb2YgdGhlIGxhbmd1YWdlIG9yIHZhcmlhdGlvbiBv ciB0byBiZSBpbiBhbnkgcGFydGljdWxhciBsYW5ndWFnZS4NCiAgIE1vc3QgZGVzY3JpcHRpb25z IGFyZSB0YWtlbiBkaXJlY3RseSBmcm9tIHNvdXJjZSBzdGFuZGFyZHMgc3VjaCBhcw0KICAgSVNP IDYzOSBvciBJU08gMzE2Ni4NCg0KICAgTm90ZTogRGVzY3JpcHRpb25zIGluIHJlZ2lzdHJ5IGVu dHJpZXMgdGhhdCBjb3JyZXNwb25kIHRvIElTTyA2MzksDQogICBJU08gMTU5MjQsICBJU08gMzE2 NiBvciBVTiBNLjQ5IGNvZGVzIGFyZSBpbnRlbmRlZCBvbmx5IHRvIGluZGljYXRlDQogICB0aGUg bWVhbmluZyBvZiB0aGF0IGlkZW50aWZpZXIgYXMgZGVmaW5lZCBpbiB0aGUgc291cmNlIHN0YW5k YXJkIGF0DQogICB0aGUgdGltZSBpdCB3YXMgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5LiAgVGhlIGRl c2NyaXB0aW9uIGRvZXMgbm90DQogICByZXBsYWNlIHRoZSBjb250ZW50IG9mIHRoZSBzb3VyY2Ug c3RhbmRhcmQgaXRzZWxmLiAgVGhlIGRlc2NyaXB0aW9ucw0KICAgYXJlIG5vdCBpbnRlbmRlZCB0 byBiZSB0aGUgRW5nbGlzaCBsb2NhbGl6ZWQgbmFtZXMgZm9yIHRoZSBzdWJ0YWdzLg0KICAgTG9j YWxpemF0aW9uIG9yIHRyYW5zbGF0aW9uIG9mIGxhbmd1YWdlIHRhZyBhbmQgc3VidGFnIGRlc2Ny aXB0aW9ucw0KICAgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIEVhY2gg cmVjb3JkIE1BWSBhbHNvIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoNCiAgIG8gIFBy ZWZlcnJlZC1WYWx1ZQ0KDQogICAgICAqICBGb3IgZmllbGRzIG9mIHR5cGUgJ2xhbmd1YWdlJywg J2V4dGxhbmcnLCAnc2NyaXB0JywgJ3JlZ2lvbicsDQogICAgICAgICBhbmQgJ3ZhcmlhbnQnLCAn UHJlZmVycmVkLVZhbHVlJyBjb250YWlucyBhIHN1YnRhZyBvZiB0aGUgc2FtZQ0KICAgICAgICAg J1R5cGUnIHdoaWNoIGlzIHByZWZlcnJlZCBmb3IgZm9ybWluZyB0aGUgbGFuZ3VhZ2UgdGFnLg0K DQogICAgICAqICBGb3IgZmllbGRzIG9mIHR5cGUgJ2dyYW5kZmF0aGVyZWQnIGFuZCAncmVkdW5k YW50JywgYSBjYW5vbmljYWwNCiAgICAgICAgIG1hcHBpbmcgdG8gYSBjb21wbGV0ZSBsYW5ndWFn ZSB0YWcuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2 LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAg IG8gIERlcHJlY2F0ZWQNCg0KICAgICAgKiAgRGVwcmVjYXRlZCdzIGZpZWxkLXZhbHVlIGNvbnRh aW5zIHRoZSBkYXRlIHRoZSByZWNvcmQgd2FzDQogICAgICAgICBkZXByZWNhdGVkLg0KDQogICBv ICBQcmVmaXgNCg0KICAgICAgKiAgUHJlZml4J3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBsYW5n dWFnZSB0YWcgd2l0aCB3aGljaCB0aGlzDQogICAgICAgICBzdWJ0YWcgTUFZIGJlIHVzZWQgdG8g Zm9ybSBhIG5ldyBsYW5ndWFnZSB0YWcsIHBlcmhhcHMgd2l0aA0KICAgICAgICAgb3RoZXIgc3Vi dGFncyBhcyB3ZWxsLiAgVGhpcyBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMNCiAg ICAgICAgIHdob3NlICdUeXBlJyBmaWVsZC12YWx1ZSBpcyAndmFyaWFudCcgb3IgJ2V4dGxhbmcn LiAgRm9yDQogICAgICAgICBleGFtcGxlLCB0aGUgJ1ByZWZpeCcgZm9yIHRoZSB2YXJpYW50ICdu ZWRpcycgaXMgJ3NsJywgbWVhbmluZw0KICAgICAgICAgdGhhdCB0aGUgdGFncyAic2wtbmVkaXMi IGFuZCAic2wtSVQtbmVkaXMiIG1pZ2h0IGJlIGFwcHJvcHJpYXRlDQogICAgICAgICB3aGlsZSB0 aGUgdGFnICJpcy1uZWRpcyIgaXMgbm90Lg0KDQogICBvICBDb21tZW50cw0KDQogICAgICAqICBD b21tZW50cyBjb250YWlucyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdWJ0YWcs IGFzDQogICAgICAgICBkZWVtZWQgYXBwcm9wcmlhdGUgZm9yIHVuZGVyc3RhbmRpbmcgdGhlIHJl Z2lzdHJ5IGFuZA0KICAgICAgICAgaW1wbGVtZW50aW5nIGxhbmd1YWdlIHRhZ3MgdXNpbmcgdGhl IHN1YnRhZyBvciB0YWcuDQoNCiAgIG8gIFN1cHByZXNzLVNjcmlwdA0KDQogICAgICAqICBTdXBw cmVzcy1TY3JpcHQgY29udGFpbnMgYSBzY3JpcHQgc3VidGFnIHRoYXQgU0hPVUxEIE5PVCBiZQ0K ICAgICAgICAgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mgd2l0aCB0aGUgYXNzb2NpYXRlZCBw cmltYXJ5IGxhbmd1YWdlDQogICAgICAgICBzdWJ0YWcuICBUaGlzIGZpZWxkIE1VU1Qgb25seSBh cHBlYXIgaW4gcmVjb3JkcyB3aG9zZSAnVHlwZScNCiAgICAgICAgIGZpZWxkLXZhbHVlIGlzICds YW5ndWFnZScuICBTZWUgU2VjdGlvbiA0LjEuDQoNCiAgIFRoZSBmaWVsZCAnRGVwcmVjYXRlZCcg TUFZIGJlIGFkZGVkIHRvIGFueSByZWNvcmQgdmlhIHRoZSBtYWludGVuYW5jZQ0KICAgcHJvY2Vz cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIgb3IgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vz cw0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LiAgVXN1YWxseSB0aGUgYWRkaXRpb24gb2Yg YSAnRGVwcmVjYXRlZCcNCiAgIGZpZWxkIGlzIGR1ZSB0byB0aGUgYWN0aW9uIG9mIG9uZSBvZiB0 aGUgc3RhbmRhcmRzIGJvZGllcywgc3VjaCBhcw0KICAgSVNPIDMxNjYsIHdpdGhkcmF3aW5nIGEg Y29kZS4gIEluIHNvbWUgaGlzdG9yaWNhbCBjYXNlcyBpdCBtaWdodCBub3QNCiAgIGhhdmUgYmVl biBwb3NzaWJsZSB0byByZWNvbnN0cnVjdCB0aGUgb3JpZ2luYWwgZGVwcmVjYXRpb24gZGF0ZS4g IEZvcg0KICAgdGhlc2UgY2FzZXMsIGFuIGFwcHJveGltYXRlIGRhdGUgYXBwZWFycyBpbiB0aGUg cmVnaXN0cnkuICBBbHRob3VnaA0KICAgdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncywgc3VidGFncyBh bmQgdGFncyB3aXRoIGEgJ0RlcHJlY2F0ZWQnIGZpZWxkDQogICBhcmUgZGVwcmVjYXRlZCBhbmQg dmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VMRCBOT1QgZ2VuZXJhdGUgdGhlc2UNCiAgIHN1YnRh Z3MuICBOb3RlIHRoYXQgYSByZWNvcmQgdGhhdCBjb250YWlucyBhICdEZXByZWNhdGVkJyBmaWVs ZCBhbmQNCiAgIG5vIGNvcnJlc3BvbmRpbmcgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQgaGFzIG5v IHJlcGxhY2VtZW50IG1hcHBpbmcuDQoNCiAgIFRoZSBmaWVsZCAnUHJlZmVycmVkLVZhbHVlJyBj b250YWlucyBhIG1hcHBpbmcgYmV0d2VlbiB0aGUgcmVjb3JkIGluDQogICB3aGljaCBpdCBhcHBl YXJzIGFuZCBhIHRhZyBvciBzdWJ0YWcgd2hpY2ggU0hPVUxEIGJlIHByZWZlcnJlZCB3aGVuDQog ICBzZWxlY3RlZCBsYW5ndWFnZSB0YWdzLiAgVGhlc2UgdmFsdWVzIGZvcm0gdGhyZWUgZ3JvdXBz Og0KDQogICAgICBJU08gNjM5IGxhbmd1YWdlIGNvZGVzIHdoaWNoIHdlcmUgbGF0ZXIgd2l0aGRy YXduIGluIGZhdm9yIG9mDQogICAgICBvdGhlciBjb2Rlcy4gIFRoZXNlIHZhbHVlcyBhcmUgbW9z dGx5IGEgaGlzdG9yaWNhbCBjdXJpb3NpdHkuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICBJU08gMzE2NiByZWdpb24gY29kZXMgd2hpY2gg aGF2ZSBiZWVuIHdpdGhkcmF3biBpbiBmYXZvciBvZiBhIG5ldw0KICAgICAgY29kZS4gIFRoaXMg c29tZXRpbWVzIGhhcHBlbnMgd2hlbiBhIGNvdW50cnkgY2hhbmdlcyBpdHMgbmFtZSBvcg0KICAg ICAgYWRtaW5pc3RyYXRpb24gaW4gc3VjaCBhIHdheSB0aGF0IHdhcnJhbnRzIGEgbmV3IHJlZ2lv biBjb2RlLg0KDQogICAgICBUYWdzIGdyYW5kZmF0aGVyZWQgZnJvbSBSRkMgMzA2Ni4gIEluIG1h bnkgY2FzZXMgdGhlc2UgdGFncyBoYXZlDQogICAgICBiZWNvbWUgb2Jzb2xldGUgYmVjYXVzZSB0 aGUgdmFsdWVzIHRoZXkgcmVwcmVzZW50IHdlcmUgbGF0ZXINCiAgICAgIGVuY29kZWQgYnkgSVNP IDYzOS4NCg0KICAgUmVjb3JkcyB0aGF0IGNvbnRhaW4gYSAnUHJlZmVycmVkLVZhbHVlJyBmaWVs ZCBNVVNUIGFsc28gaGF2ZSBhDQogICAnRGVwcmVjYXRlZCcgZmllbGQuICBUaGlzIGZpZWxkIGNv bnRhaW5zIGEgZGF0ZSBvZiBkZXByZWNhdGlvbi4gIFRodXMNCiAgIGEgbGFuZ3VhZ2UgdGFnIHBy b2Nlc3NvciBjYW4gdXNlIHRoZSByZWdpc3RyeSB0byBjb25zdHJ1Y3QgdGhlIHZhbGlkLA0KICAg bm9uLWRlcHJlY2F0ZWQgc2V0IG9mIHN1YnRhZ3MgZm9yIGEgZ2l2ZW4gZGF0ZS4gIEluIGFkZGl0 aW9uLCBmb3IgYW55DQogICBnaXZlbiB0YWcsIGEgcHJvY2Vzc29yIGNhbiBjb25zdHJ1Y3QgdGhl IHNldCBvZiB2YWxpZCBsYW5ndWFnZSB0YWdzDQogICB0aGF0IGNvcnJlc3BvbmQgdG8gdGhhdCB0 YWcgZm9yIGFsbCBkYXRlcyB1cCB0byB0aGUgZGF0ZSBvZiB0aGUNCiAgIHJlZ2lzdHJ5LiAgVGhl IGFiaWxpdHkgdG8gZG8gdGhlc2UgbWFwcGluZ3MgTUFZIGJlIGJlbmVmaWNpYWwgdG8NCiAgIGFw cGxpY2F0aW9ucyB0aGF0IGFyZSBtYXRjaGluZywgc2VsZWN0aW5nLCBmb3IgZmlsdGVyaW5nIGNv bnRlbnQNCiAgIGJhc2VkIG9uIGl0cyBsYW5ndWFnZSB0YWdzLg0KDQogICBOb3RlIHRoYXQgJ1By ZWZlcnJlZC1WYWx1ZScgbWFwcGluZ3MgaW4gcmVjb3JkcyBvZiB0eXBlICdyZWdpb24nDQogICBz b21ldGltZXMgZG8gbm90IHJlcHJlc2VudCBleGFjdGx5IHRoZSBzYW1lIG1lYW5pbmcgYXMgdGhl IG9yaWdpbmFsDQogICB2YWx1ZS4gIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgZm9yIGEgY291bnRy eSBjb2RlIHRvIGJlIGNoYW5nZWQgYW5kDQogICB0aGUgZWZmZWN0IHRoaXMgaGFzIG9uIHRoZSBm b3JtYXRpb24gb2YgbGFuZ3VhZ2UgdGFncyB3aWxsIGRlcGVuZCBvbg0KICAgdGhlIG5hdHVyZSBv ZiB0aGUgY2hhbmdlIGluIHF1ZXN0aW9uLg0KDQogICBJbiBwYXJ0aWN1bGFyLCB0aGUgJ1ByZWZl cnJlZC1WYWx1ZScgZmllbGQgZG9lcyBub3QgaW1wbHkgcmV0YWdnaW5nDQogICBjb250ZW50IHRo YXQgdXNlcyB0aGUgYWZmZWN0ZWQgc3VidGFnLg0KDQogICBUaGUgZmllbGQgJ1ByZWZlcnJlZC1W YWx1ZScgTVVTVCBOT1QgYmUgbW9kaWZpZWQgb25jZSBjcmVhdGVkIGluIHRoZQ0KICAgcmVnaXN0 cnkuICBUaGUgZmllbGQgTUFZIGJlIGFkZGVkIHRvIHJlY29yZHMgb2YgdHlwZSAiZ3JhbmRmYXRo ZXJlZCINCiAgIGFuZCAicmVnaW9uIiBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGluIFNlY3Rpb24g My4yLiAgT3RoZXJ3aXNlIHRoZQ0KICAgZmllbGQgTVVTVCBOT1QgYmUgYWRkZWQgdG8gYW55IHJl Y29yZCBhbHJlYWR5IGluIHRoZSByZWdpc3RyeS4NCg0KICAgVGhlICdQcmVmZXJyZWQtVmFsdWUn IGZpZWxkIGluIHJlY29yZHMgb2YgdHlwZSAiZ3JhbmRmYXRoZXJlZCIgYW5kDQogICAicmVkdW5k YW50IiBjb250YWlucyB3aG9sZSBsYW5ndWFnZSB0YWdzIHRoYXQgYXJlIHN0cm9uZ2x5DQogICBS RUNPTU1FTkRFRCBmb3IgdXNlIGluIHBsYWNlIG9mIHRoZSByZWNvcmQncyB2YWx1ZS4gIEluIG1h bnkgY2FzZXMNCiAgIHRoZSBtYXBwaW5ncyB3ZXJlIGNyZWF0ZWQgYnkgZGVwcmVjYXRpb24gb2Yg dGhlIHRhZ3MgZHVyaW5nIHRoZQ0KICAgcGVyaW9kIGJlZm9yZSB0aGlzIGRvY3VtZW50IHdhcyBh ZG9wdGVkLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgIm5vLQ0KICAgbnluIiB3YXMgZGVwcmVjYXRl ZCBpbiBmYXZvciBvZiB0aGUgSVNPIDYzOS0xIGRlZmluZWQgbGFuZ3VhZ2UgY29kZQ0KICAgJ25u Jy4NCg0KICAgUmVjb3JkcyBvZiB0eXBlICd2YXJpYW50JyBNQVkgaGF2ZSBtb3JlIHRoYW4gb25l IGZpZWxkIG9mIHR5cGUNCiAgICdQcmVmaXgnLiAgQWRkaXRpb25hbCBmaWVsZHMgb2YgdGhpcyB0 eXBlIE1BWSBiZSBhZGRlZCB0byBhICd2YXJpYW50Jw0KICAgcmVjb3JkIHZpYSB0aGUgcmVnaXN0 cmF0aW9uIHByb2Nlc3MuDQoNCiAgIFJlY29yZHMgb2YgdHlwZSAnZXh0bGFuZycgTVVTVCBoYXZl IF9leGFjdGx5XyBvbmUgJ1ByZWZpeCcgZmllbGQuDQoNCiAgIFRoZSBmaWVsZC12YWx1ZSBvZiB0 aGUgJ1ByZWZpeCcgZmllbGQgY29uc2lzdHMgb2YgYSBsYW5ndWFnZSB0YWcNCiAgIHdob3NlIHN1 YnRhZ3MgYXJlIGFwcHJvcHJpYXRlIHRvIHVzZSB3aXRoIHRoaXMgc3VidGFnLiAgRm9yIGV4YW1w bGUsDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAy MDA2ICAgICAgICAgICAgICBbUGFnZSAyMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIHRo ZSB2YXJpYW50IHN1YnRhZyAnMTk5NicgaGFzIGEgUHJlZml4IGZpZWxkIG9mICJkZSIuICBUaGlz IG1lYW5zDQogICB0aGF0IHRhZ3Mgc3RhcnRpbmcgd2l0aCB0aGUgc2VxdWVuY2UgImRlLSIgYXJl IGFwcHJvcHJpYXRlIHdpdGggdGhpcw0KICAgc3VidGFnLCBzbyAiZGUtTGF0Zy0xOTk2IiBhbmQg ImRlLUNILTE5OTYiIGFyZSBib3RoIGFjY2VwdGFibGUsIHdoaWxlDQogICB0aGUgdGFnICJmci0x OTk2IiBpcyBhbiBpbmFwcHJvcHJpYXRlIGNob2ljZS4NCg0KICAgVGhlIGZpZWxkIG9mIHR5cGUg J1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZCBmcm9tIGFueSByZWNvcmQuICBUaGUNCiAgIGZp ZWxkLXZhbHVlIGZvciB0aGlzIHR5cGUgb2YgZmllbGQgTVVTVCBOT1QgYmUgbW9kaWZpZWQuDQoN CiAgIFRoZSBmaWVsZCAnQ29tbWVudHMnIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgcGVyIHJl Y29yZC4gIFRoaXMNCiAgIGZpZWxkIE1BWSBiZSBpbnNlcnRlZCBvciBjaGFuZ2VkIHZpYSB0aGUg cmVnaXN0cmF0aW9uIHByb2Nlc3MgYW5kIG5vDQogICBndWFyYW50ZWUgb2Ygc3RhYmlsaXR5IGlz IHByb3ZpZGVkLiAgVGhlIGNvbnRlbnQgb2YgdGhpcyBmaWVsZCBpcyBub3QNCiAgIHJlc3RyaWN0 ZWQsIGV4Y2VwdCBieSB0aGUgbmVlZCB0byByZWdpc3RlciB0aGUgaW5mb3JtYXRpb24sIHRoZQ0K ICAgc3VpdGFiaWxpdHkgb2YgdGhlIHJlcXVlc3QsIGFuZCBieSByZWFzb25hYmxlIHByYWN0aWNh bCBzaXplDQogICBsaW1pdGF0aW9ucy4gIExvbmcgdGV4dHMgYWJvdXQgYSBwYXJ0aWN1bGFyIHN1 YnRhZyBhcmUgZnJvd25lZCB1cG9uLg0KDQogICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcg TVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgZmllbGQtdmFsdWUg aXMgJ2xhbmd1YWdlJy4gIFRoaXMgZmllbGQgTVVTVCBOT1QgYXBwZWFyIG1vcmUgdGhhbiBvbmUN CiAgIHRpbWUgaW4gYSByZWNvcmQuICBUaGlzIGZpZWxkIGluZGljYXRlcyBhIHNjcmlwdCB1c2Vk IHRvIHdyaXRlIHRoZQ0KICAgb3ZlcndoZWxtaW5nIG1ham9yaXR5IG9mIGRvY3VtZW50cyBmb3Ig dGhlIGdpdmVuIGxhbmd1YWdlIGFuZCB3aGljaA0KICAgdGhlcmVmb3JlIGFkZHMgbm8gZGlzdGlu Z3Vpc2hpbmcgaW5mb3JtYXRpb24gdG8gYSBsYW5ndWFnZSB0YWcuICBJdA0KICAgaGVscHMgZW5z dXJlIGdyZWF0ZXIgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFnZSB0YWdzDQogICBn ZW5lcmF0ZWQgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBpbiB0aGlzIGRvY3VtZW50IGFuZCBsYW5n dWFnZSB0YWdzDQogICBhbmQgdGFnIHByb2Nlc3NvcnMgb3IgY29uc3VtZXJzIGJhc2VkIG9uIFJG QyAzMDY2LiAgRm9yIGV4YW1wbGUsDQogICB2aXJ0dWFsbHkgYWxsIEljZWxhbmRpYyBkb2N1bWVu dHMgYXJlIHdyaXR0ZW4gaW4gdGhlIExhdGluIHNjcmlwdCwNCiAgIG1ha2luZyB0aGUgc3VidGFn ICdMYXRuJyByZWR1bmRhbnQgaW4gdGhlIHRhZyAiaXMtTGF0biIuDQoNCjMuMiAgTWFpbnRlbmFu Y2Ugb2YgdGhlIFJlZ2lzdHJ5DQoNCiAgIE1haW50ZW5hbmNlIG9mIHRoZSByZWdpc3RyeSByZXF1 aXJlcyB0aGF0IGFzIGNvZGVzIGFyZSBhc3NpZ25lZCBvcg0KICAgd2l0aGRyYXduIGJ5IElTTyA2 MzksIElTTyAxNTkyNCwgSVNPIDMxNjYsIGFuZCBVTiBNLjQ5LCB0aGUgTGFuZ3VhZ2UNCiAgIFN1 YnRhZyBSZXZpZXdlciBNVVNUIGV2YWx1YXRlIGVhY2ggY2hhbmdlLCBkZXRlcm1pbmUgd2hldGhl ciBpdA0KICAgY29uZmxpY3RzIHdpdGggZXhpc3RpbmcgcmVnaXN0cnkgZW50cmllcywgYW5kIHN1 Ym1pdCB0aGUgaW5mb3JtYXRpb24NCiAgIHRvIElBTkEgZm9yIGluY2x1c2lvbiBpbiB0aGUgcmVn aXN0cnkuICBJZiBhbiBjaGFuZ2UgdGFrZXMgcGxhY2UgYW5kDQogICB0aGUgTGFuZ3VhZ2UgU3Vi dGFnIFJldmlld2VyIGRvZXMgbm90IGRvIHRoaXMgaW4gYSB0aW1lbHkgbWFubmVyLA0KICAgdGhl biBhbnkgaW50ZXJlc3RlZCBwYXJ0eSBNQVkgdXNlIHRoZSBwcm9jZWR1cmUgaW4gU2VjdGlvbiAz LjQgdG8NCiAgIHJlZ2lzdGVyIHRoZSBhcHByb3ByaWF0ZSB1cGRhdGUuDQoNCiAgIE5vdGU6IFRo ZSByZWR1bmRhbnQgYW5kIGdyYW5kZmF0aGVyZWQgZW50cmllcyB0b2dldGhlciBhcmUgdGhlDQog ICBjb21wbGV0ZSBsaXN0IG9mIHRhZ3MgcmVnaXN0ZXJlZCB1bmRlciBbUkZDMzA2Nl0uICBUaGUg cmVkdW5kYW50IHRhZ3MNCiAgIGFyZSB0aG9zZSB0aGF0IGNhbiBub3cgYmUgZm9ybWVkIHVzaW5n IHRoZSBzdWJ0YWdzIGRlZmluZWQgaW4gdGhlDQogICByZWdpc3RyeSB0b2dldGhlciB3aXRoIHRo ZSBydWxlcyBvZiAgU2VjdGlvbiAyLjIuICBUaGUgZ3JhbmRmYXRoZXJlZA0KICAgZW50cmllcyBh cmUgdGhvc2UgdGhhdCBjYW4gbmV2ZXIgYmUgbGVnYWwgdW5kZXIgdGhvc2Ugc2FtZQ0KICAgcHJv dmlzaW9ucy4NCg0KICAgVGhlIHNldCBvZiByZWR1bmRhbnQgYW5kIGdyYW5kZmF0aGVyZWQgdGFn cyBpcyBwZXJtYW5lbnQgYW5kIHN0YWJsZToNCiAgIG5ldyBlbnRyaWVzIGluIHRoaXMgc2VjdGlv biBNVVNUIE5PVCBiZSBhZGRlZCBhbmQgZXhpc3RpbmcgZW50cmllcw0KICAgTVVTVCBOT1QgYmUg cmVtb3ZlZC4gIFJlY29yZHMgb2YgdHlwZSAnZ3JhbmRmYXRoZXJlZCcgTUFZIGhhdmUgdGhlaXIN CiAgIHR5cGUgY29udmVydGVkIHRvICdyZWR1bmRhbnQnOiBzZWUgIFNlY3Rpb24gMy43IGZvciBt b3JlIGluZm9ybWF0aW9uLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIw MDUNCg0KDQogICBSRkMgMzA2NiB0YWdzIHRoYXQgd2VyZSBkZXByZWNhdGVkIHByaW9yIHRvIHRo ZSBhZG9wdGlvbiBvZiB0aGlzDQogICBkb2N1bWVudCBhcmUgcGFydCBvZiB0aGUgbGlzdCBvZiBn cmFuZGZhdGhlcmVkIHRhZ3MgYW5kIHRoZWlyDQogICBjb21wb25lbnQgc3VidGFncyB3ZXJlIG5v dCBpbmNsdWRlZCBhcyByZWdpc3RlcmVkIHZhcmlhbnRzIChhbHRob3VnaA0KICAgdGhleSByZW1h aW4gZWxpZ2libGUgZm9yIHJlZ2lzdHJhdGlvbikuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAiYXJ0 LQ0KICAgbG9qYmFuIiB3YXMgZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgbGFuZ3VhZ2Ugc3Vi dGFnICdqYm8nLg0KDQogICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIE1VU1QgZW5zdXJl IHRoYXQgbmV3IHN1YnRhZ3MgbWVldCB0aGUNCiAgIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDQu MSBvciBzdWJtaXQgYW4gYXBwcm9wcmlhdGUgYWx0ZXJuYXRlIHN1YnRhZw0KICAgYXMgZGVzY3Jp YmVkIGluIHRoYXQgc2VjdGlvbi4gIFdoZW4gZWl0aGVyIGEgY2hhbmdlIG9yIGFkZGl0aW9uIHRv DQogICB0aGUgcmVnaXN0cnkgaXMgbmVlZGVkLCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2Vy IE1VU1QgcHJlcGFyZSB0aGUNCiAgIGNvbXBsZXRlIHJlY29yZCwgaW5jbHVkaW5nIGFsbCBmaWVs ZHMsIGFuZCBmb3J3YXJkIGl0IHRvIElBTkEgZm9yDQogICBpbnNlcnRpb24gaW50byB0aGUgcmVn aXN0cnkuDQoNCiAgIElmIHJlY29yZCByZXByZXNlbnRzIGEgbmV3IHN1YnRhZyB0aGF0IGRvZXMg bm90IGN1cnJlbnRseSBleGlzdCBpbg0KICAgdGhlIHJlZ2lzdHJ5LCB0aGVuIHRoZSBtZXNzYWdl J3Mgc3ViamVjdCBsaW5lIE1VU1QgaW5jbHVkZSB0aGUgd29yZA0KICAgIklOU0VSVCIuICBJZiB0 aGUgcmVjb3JkIHJlcHJlc2VudHMgYSBjaGFuZ2UgdG8gYW4gZXhpc3Rpbmcgc3VidGFnLA0KICAg dGhlbiB0aGUgc3ViamVjdCBsaW5lIG9mIHRoZSBtZXNzYWdlIE1VU1QgaW5jbHVkZSB0aGUgd29y ZCAiTU9ESUZZIi4NCiAgIFRoZSBtZXNzYWdlIE1VU1QgY29udGFpbiBib3RoIHRoZSByZWNvcmQg Zm9yIHRoZSBzdWJ0YWcgYmVpbmcNCiAgIGluc2VydGVkIG9yIG1vZGlmaWVkIGFuZCB0aGUgbmV3 IEZpbGUtRGF0ZSByZWNvcmQuICBIZXJlIGlzIGFuDQogICBleGFtcGxlIG9mIHdoYXQgdGhlIGJv ZHkgb2YgdGhlIG1lc3NhZ2UgbWlnaHQgY29udGFpbjoNCg0KICAgTEFOR1VBR0UgU1VCVEFHIE1P RElGSUNBVElPTg0KICAgRmlsZS1EYXRlOiAyMDA1LTAxLTAyDQogICAlJQ0KICAgVHlwZTogdmFy aWFudA0KICAgU3VidGFnOiBuZWRpcw0KICAgRGVzY3JpcHRpb246IE5hdGlzb25lIGRpYWxlY3QN CiAgIERlc2NyaXB0aW9uOiBOYWRpemEgZGlhbGVjdA0KICAgQWRkZWQ6IDIwMDMtMTAtMDkNCiAg IFByZWZpeDogc2wNCiAgIENvbW1lbnRzOiBUaGlzIGlzIGEgY29tbWVudCBzaG93bg0KICAgICBh cyBhbiBleGFtcGxlLg0KICAgJSUNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RmlndXJlIDQNCg0KICAgV2hlbmV2ZXIgYW4gZW50cnkgaXMgY3JlYXRlZCBvciBtb2RpZmllZCBp biB0aGUgcmVnaXN0cnksIHRoZSAnRmlsZS0NCiAgIERhdGUnIHJlY29yZCBhdCB0aGUgc3RhcnQg b2YgdGhlIHJlZ2lzdHJ5IGlzIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUNCiAgIG1vc3QgcmVjZW50 IG1vZGlmaWNhdGlvbiBkYXRlIGluIHRoZSBbUkZDMzMzOV0gImZ1bGwtZGF0ZSIgZm9ybWF0Lg0K DQogICBWYWx1ZXMgaW4gdGhlICdTdWJ0YWcnIGZpZWxkIE1VU1QgYmUgbG93ZXJjYXNlIGV4Y2Vw dCBhcyBwcm92aWRlZCBmb3INCiAgIGluIFNlY3Rpb24gMy4xLg0KDQozLjMgIFN0YWJpbGl0eSBv ZiBJQU5BIFJlZ2lzdHJ5IEVudHJpZXMNCg0KICAgVGhlIHN0YWJpbGl0eSBvZiBlbnRyaWVzIGFu ZCB0aGVpciBtZWFuaW5nIGluIHRoZSByZWdpc3RyeSBpcw0KICAgY3JpdGljYWwgdG8gdGhlIGxv bmcgdGVybSBzdGFiaWxpdHkgb2YgbGFuZ3VhZ2UgdGFncy4gIFRoZSBydWxlcyBpbg0KICAgdGhp cyBzZWN0aW9uIGd1YXJhbnRlZSB0aGF0IGEgc3BlY2lmaWMgbGFuZ3VhZ2UgdGFnJ3MgbWVhbmlu ZyBpcw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwg MjAwNiAgICAgICAgICAgICAgW1BhZ2UgMjRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICBz dGFibGUgb3ZlciB0aW1lIGFuZCB3aWxsIG5vdCBjaGFuZ2UuDQoNCiAgIFRoZXNlIHJ1bGVzIHNw ZWNpZmljYWxseSBkZWFsIHdpdGggaG93IGNoYW5nZXMgdG8gY29kZXMgKGluY2x1ZGluZw0KICAg d2l0aGRyYXdhbCBhbmQgZGVwcmVjYXRpb24gb2YgY29kZXMpIG1haW50YWluZWQgYnkgSVNPIDYz OSwgSVNPDQogICAxNTkyNCwgSVNPIDMxNjYsIGFuZCBVTiBNLjQ5IGFyZSByZWZsZWN0ZWQgaW4g dGhlIElBTkEgTGFuZ3VhZ2UNCiAgIFN1YnRhZyBSZWdpc3RyeS4gIEFzc2lnbm1lbnRzIHRvIHRo ZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQ0KICAgTVVTVCBmb2xsb3cgdGhlIGZvbGxv d2luZyBzdGFiaWxpdHkgcnVsZXM6DQoNCiAgIDEuICAgVmFsdWVzIGluIHRoZSBmaWVsZHMgJ1R5 cGUnLCAnU3VidGFnJywgJ1RhZycsICdBZGRlZCcsDQogICAgICAgICdEZXByZWNhdGVkJyBhbmQg J1ByZWZlcnJlZC1WYWx1ZScgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlDQogICAgICAgIGd1 YXJhbnRlZWQgdG8gYmUgc3RhYmxlIG92ZXIgdGltZS4NCg0KICAgMi4gICBWYWx1ZXMgaW4gdGhl ICdEZXNjcmlwdGlvbicgZmllbGQgTVVTVCBOT1QgYmUgY2hhbmdlZCBpbiBhIHdheQ0KICAgICAg ICB0aGF0IHdvdWxkIGludmFsaWRhdGUgcHJldmlvdXNseS1leGlzdGluZyB0YWdzLiAgVGhleSBN QVkgYmUNCiAgICAgICAgYnJvYWRlbmVkIHNvbWV3aGF0IGluIHNjb3BlLCBjaGFuZ2VkIHRvIGFk ZCBpbmZvcm1hdGlvbiwgb3INCiAgICAgICAgYWRhcHRlZCB0byB0aGUgbW9zdCBjb21tb24gbW9k ZXJuIHVzYWdlLiAgRm9yIGV4YW1wbGUsIGNvdW50cmllcw0KICAgICAgICBvY2Nhc2lvbmFsbHkg Y2hhbmdlIHRoZWlyIG9mZmljaWFsIG5hbWVzOiBhbiBoaXN0b3JpY2FsIGV4YW1wbGUNCiAgICAg ICAgb2YgdGhpcyB3b3VsZCBiZSAiVXBwZXIgVm9sdGEiIGNoYW5naW5nIHRvICJCdXJraW5hIEZh c28iLg0KDQogICAzLiAgIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcgTUFZIGJlIGFkZGVk IHRvIHJlY29yZHMgb2YgdHlwZQ0KICAgICAgICAndmFyaWFudCcgdmlhIHRoZSByZWdpc3RyYXRp b24gcHJvY2Vzcy4NCg0KICAgNC4gICBWYWx1ZXMgaW4gdGhlIGZpZWxkICdQcmVmaXgnIE1BWSBi ZSBtb2RpZmllZCwgc28gbG9uZyBhcyB0aGUNCiAgICAgICAgbW9kaWZpY2F0aW9ucyBicm9hZGVu IHRoZSBzZXQgb2YgcHJlZml4ZXMuICBUaGF0IGlzLCBhIHByZWZpeA0KICAgICAgICBNQVkgYmUg cmVwbGFjZWQgYnkgb25lIG9mIGl0cyBvd24gcHJlZml4ZXMuICBGb3IgZXhhbXBsZSwgdGhlDQog ICAgICAgIHByZWZpeCAiZW4tVVMiIGNvdWxkIGJlIHJlcGxhY2VkIGJ5ICJlbiIsIGJ1dCBub3Qg YnkgdGhlDQogICAgICAgIHByZWZpeGVzICJlbi1MYXRuIiwgImZyIiwgb3IgImVuLVVTLWJvb250 Ii4gIElmIG9uZSBvZiB0aG9zZQ0KICAgICAgICBwcmVmaXhlcyB3ZXJlIG5lZWRlZCwgYSBuZXcg UHJlZml4IFNIT1VMRCBiZSByZWdpc3RlcmVkLg0KDQogICA1LiAgIFZhbHVlcyBpbiB0aGUgZmll bGQgJ1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZC4NCg0KICAgNi4gICBUaGUgZmllbGQgJ0Nv bW1lbnRzJyBNQVkgYmUgYWRkZWQsIGNoYW5nZWQsIG1vZGlmaWVkLCBvciByZW1vdmVkDQogICAg ICAgIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3IgYW55IG9mIHRoZSBwcm9jZXNzZXMg b3INCiAgICAgICAgY29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbi4NCg0K ICAgNy4gICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTUFZIGJlIGFkZGVkIG9yIHJlbW92 ZWQgdmlhIHRoZQ0KICAgICAgICByZWdpc3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgOC4gICBDb2Rl cyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIGFuZCBJU08gMzE2NiB0aGF0IGRvIG5v dA0KICAgICAgICBjb25mbGljdCB3aXRoIGV4aXN0aW5nIHN1YnRhZ3Mgb2YgdGhlIGFzc29jaWF0 ZWQgdHlwZSBhbmQgd2hvc2UNCiAgICAgICAgbWVhbmluZyBpcyBub3QgdGhlIHNhbWUgYXMgYW4g ZXhpc3Rpbmcgc3VidGFnIG9mIHRoZSBzYW1lIHR5cGUNCiAgICAgICAgYXJlIGVudGVyZWQgaW50 byB0aGUgSUFOQSByZWdpc3RyeSBhcyBuZXcgcmVjb3Jkcy4NCg0KICAgOS4gICBDb2RlcyBhc3Np Z25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIG9yIElTTyAzMTY2IHRoYXQgYXJlDQogICAgICAg IHdpdGhkcmF3biBieSB0aGVpciByZXNwZWN0aXZlIG1haW50ZW5hbmNlIG9yIHJlZ2lzdHJhdGlv bg0KICAgICAgICBhdXRob3JpdHkgcmVtYWluIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MuICBBICdE ZXByZWNhdGVkJyBmaWVsZA0KICAgICAgICBjb250YWluaW5nIHRoZSBkYXRlIG9mIHdpdGhkcmF3 YWwgaXMgYWRkZWQgdG8gdGhlIHJlY29yZC4gIElmIGENCiAgICAgICAgbmV3IHJlY29yZCBvZiB0 aGUgc2FtZSB0eXBlIGlzIGFkZGVkIHRoYXQgcmVwcmVzZW50cyBhDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFn ZSAyNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgICAgICAgcmVwbGFjZW1lbnQgdmFsdWUs IHRoZW4gYSAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBNQVkgYWxzbyBiZQ0KICAgICAgICBhZGRl ZC4gIFRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBNQVkgYmUgdXNlZCB0byBhZGQgY29tbWVudHMN CiAgICAgICAgYWJvdXQgdGhlIHdpdGhkcmF3YWwgb2YgdGhlIGNvZGUgYnkgdGhlIHJlc3BlY3Rp dmUgc3RhbmRhcmQuDQoNCiAgICAgICAgRXhhbXBsZSBUaGUgcmVnaW9uIGNvZGUgJ1RMJyB3YXMg YXNzaWduZWQgdG8gdGhlIGNvdW50cnkgJ1RpbW9yLQ0KICAgICAgICAgICBMZXN0ZScsIHJlcGxh Y2luZyB0aGUgY29kZSAnVFAnICh3aGljaCB3YXMgYXNzaWduZWQgdG8gJ0Vhc3QNCiAgICAgICAg ICAgVGltb3InIHdoZW4gaXQgd2FzIHVuZGVyIGFkbWluaXN0cmF0aW9uIGJ5IFBvcnR1Z2FsKS4g IFRoZQ0KICAgICAgICAgICBzdWJ0YWcgJ1RQJyByZW1haW5zIHZhbGlkIGluIGxhbmd1YWdlIHRh Z3MsIGJ1dCBpdHMgcmVjb3JkDQogICAgICAgICAgIGNvbnRhaW5zIHRoZSBhICdQcmVmZXJyZWQt VmFsdWUnIG9mICdUTCcgYW5kIGl0cyBmaWVsZA0KICAgICAgICAgICAnRGVwcmVjYXRlZCcgY29u dGFpbnMgdGhlIGRhdGUgdGhlIG5ldyBjb2RlIHdhcyBhc3NpZ25lZA0KICAgICAgICAgICAoJzIw MDQtMDctMDYnKS4NCg0KICAgMTAuICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5 MjQsIG9yIElTTyAzMTY2IHRoYXQgY29uZmxpY3QNCiAgICAgICAgd2l0aCBleGlzdGluZyBzdWJ0 YWdzIG9mIHRoZSBhc3NvY2lhdGVkIHR5cGUsIGluY2x1ZGluZyBzdWJ0YWdzDQogICAgICAgIHRo YXQgYXJlIGRlcHJlY2F0ZWQsIE1VU1QgTk9UIGJlIGVudGVyZWQgaW50byB0aGUgcmVnaXN0cnku ICBUaGUNCiAgICAgICAgZm9sbG93aW5nIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgYXBwbHkg dG8gc3VidGFnIHZhbHVlcyB0aGF0DQogICAgICAgIGFyZSByZWFzc2lnbmVkOg0KDQogICAgICAg IEEuICBGb3IgSVNPIDYzOSBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFu aW5nIGlzDQogICAgICAgICAgICBub3QgcmVwcmVzZW50ZWQgYnkgYSBzdWJ0YWcgaW4gdGhlIElB TkEgcmVnaXN0cnksIHRoZQ0KICAgICAgICAgICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQsIFNIQUxMDQogICAgICAgICAgICBwcmVwYXJlIGEg cHJvcG9zYWwgZm9yIGVudGVyaW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIHNvb24NCiAgICAg ICAgICAgIGFzIHByYWN0aWNhbCBhIHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFnIGFzIGFuIGFs dGVybmF0ZQ0KICAgICAgICAgICAgdmFsdWUgZm9yIHRoZSBuZXcgY29kZS4gIFRoZSBmb3JtIG9m IHRoZSByZWdpc3RlcmVkIGxhbmd1YWdlDQogICAgICAgICAgICBzdWJ0YWcgd2lsbCBiZSBhdCB0 aGUgZGlzY3JldGlvbiBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnDQogICAgICAgICAgICBSZXZpZXdl ciBhbmQgTVVTVCBjb25mb3JtIHRvIG90aGVyIHJlc3RyaWN0aW9ucyBvbiBsYW5ndWFnZQ0KICAg ICAgICAgICAgc3VidGFncyBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICAgICAgIEIuICBGb3IgYWxs IHN1YnRhZ3Mgd2hvc2UgbWVhbmluZyBpcyBkZXJpdmVkIGZyb20gYW4gZXh0ZXJuYWwNCiAgICAg ICAgICAgIHN0YW5kYXJkIChpLmUuICBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBvciBV TiBNLjQ5KSwNCiAgICAgICAgICAgIGlmIGEgbmV3IG1lYW5pbmcgaXMgYXNzaWduZWQgdG8gYW4g ZXhpc3RpbmcgY29kZSBhbmQgdGhlIG5ldw0KICAgICAgICAgICAgbWVhbmluZyBicm9hZGVucyB0 aGUgbWVhbmluZyBvZiB0aGF0IGNvZGUsIHRoZW4gdGhlIG1lYW5pbmcNCiAgICAgICAgICAgIGZv ciB0aGUgYXNzb2NpYXRlZCBzdWJ0YWcgTUFZIGJlIGNoYW5nZWQgdG8gbWF0Y2guICBUaGUNCiAg ICAgICAgICAgIG1lYW5pbmcgb2YgYSBzdWJ0YWcgTVVTVCBOT1QgYmUgbmFycm93ZWQsIGhvd2V2 ZXIsIGFzIHRoaXMNCiAgICAgICAgICAgIGNhbiByZXN1bHQgaW4gYW4gdW5rbm93biBwcm9wb3J0 aW9uIG9mIHRoZSBleGlzdGluZyB1c2VzIG9mDQogICAgICAgICAgICBhIHN1YnRhZyBiZWNvbWlu ZyBpbnZhbGlkLiAgTm90ZTogSVNPIDYzOSBNQS9SQSBoYXMgYWRvcHRlZA0KICAgICAgICAgICAg YSBzaW1pbGFyIHN0YWJpbGl0eSBwb2xpY3kuDQoNCiAgICAgICAgQy4gIEZvciBJU08gMTU5MjQg Y29kZXMsIGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAg ICAgbm90IHJlcHJlc2VudGVkIGJ5IGEgc3VidGFnIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LCB0aGUN CiAgICAgICAgICAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciwgYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMy40LCBTSEFMTA0KICAgICAgICAgICAgcHJlcGFyZSBhIHByb3Bvc2FsIGZvciBlbnRl cmluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBzb29uDQogICAgICAgICAgICBhcyBwcmFjdGlj YWwgYSByZWdpc3RlcmVkIHZhcmlhbnQgc3VidGFnIGFzIGFuIGFsdGVybmF0ZQ0KICAgICAgICAg ICAgdmFsdWUgZm9yIHRoZSBuZXcgY29kZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVkIHZh cmlhbnQNCiAgICAgICAgICAgIHN1YnRhZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRo ZSBMYW5ndWFnZSBTdWJ0YWcNCiAgICAgICAgICAgIFJldmlld2VyIGFuZCBNVVNUIGNvbmZvcm0g dG8gb3RoZXIgcmVzdHJpY3Rpb25zIG9uIHZhcmlhbnQNCiAgICAgICAgICAgIHN1YnRhZ3MgaW4g dGhpcyBkb2N1bWVudC4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIw MDUNCg0KDQogICAgICAgIEQuICBGb3IgSVNPIDMxNjYgY29kZXMsIGlmIHRoZSBuZXdseSBhc3Np Z25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBz YW1lIFVOIE0uNDkgY29kZSBhcyBhbm90aGVyICdyZWdpb24nDQogICAgICAgICAgICBzdWJ0YWcs IHRoZW4gdGhlIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcgcmVtYWlucyBhcyB0aGUNCiAgICAgICAg ICAgIHByZWZlcnJlZCB2YWx1ZSBmb3IgdGhhdCByZWdpb24gYW5kIG5vIG5ldyBlbnRyeSBpcyBj cmVhdGVkLg0KICAgICAgICAgICAgQSBjb21tZW50IE1BWSBiZSBhZGRlZCB0byB0aGUgZXhpc3Rp bmcgcmVnaW9uIHN1YnRhZw0KICAgICAgICAgICAgaW5kaWNhdGluZyB0aGUgcmVsYXRpb25zaGlw IHRvIHRoZSBuZXcgSVNPIDMxNjYgY29kZS4NCg0KICAgICAgICBFLiAgRm9yIElTTyAzMTY2IGNv ZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgICAg IGFzc29jaWF0ZWQgd2l0aCBhIFVOIE0uNDkgY29kZSB0aGF0IGlzIG5vdCByZXByZXNlbnRlZCBi eSBhbg0KICAgICAgICAgICAgZXhpc3RpbmcgcmVnaW9uIHN1YnRhZywgdGhlbiB0aGUgTGFuZ3Vh Z2UgU3VidGFnIFJldmlld2VyLA0KICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g My40LCBTSEFMTCBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yDQogICAgICAgICAgICBlbnRlcmluZyB0 aGUgYXBwcm9wcmlhdGUgVU4gTS40OSBjb3VudHJ5IGNvZGUgYXMgYW4gZW50cnkgaW4NCiAgICAg ICAgICAgIHRoZSBJQU5BIHJlZ2lzdHJ5Lg0KDQogICAgICAgIEYuICBGb3IgSVNPIDMxNjYgY29k ZXMsIGlmIHRoZXJlIGlzIG5vIGFzc29jaWF0ZWQgVU4gbnVtZXJpYw0KICAgICAgICAgICAgY29k ZSwgdGhlbiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIFNIQUxMIHBldGl0aW9uIHRoZQ0K ICAgICAgICAgICAgVU4gdG8gY3JlYXRlIG9uZS4gIElmIHRoZXJlIGlzIG5vIHJlc3BvbnNlIGZy b20gdGhlIFVODQogICAgICAgICAgICB3aXRoaW4gbmluZXR5IGRheXMgb2YgdGhlIHJlcXVlc3Qg YmVpbmcgc2VudCwgdGhlIExhbmd1YWdlDQogICAgICAgICAgICBTdWJ0YWcgUmV2aWV3ZXIgU0hB TEwgcHJlcGFyZSBhIHByb3Bvc2FsIGZvciBlbnRlcmluZyBpbiB0aGUNCiAgICAgICAgICAgIElB TkEgcmVnaXN0cnkgYXMgc29vbiBhcyBwcmFjdGljYWwgYSByZWdpc3RlcmVkIHZhcmlhbnQNCiAg ICAgICAgICAgIHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUgdmFsdWUgZm9yIHRoZSBuZXcgY29kZS4g IFRoZSBmb3JtIG9mDQogICAgICAgICAgICB0aGUgcmVnaXN0ZXJlZCB2YXJpYW50IHN1YnRhZyB3 aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mDQogICAgICAgICAgICB0aGUgTGFuZ3VhZ2UgU3Vi dGFnIFJldmlld2VyIGFuZCBNVVNUIGNvbmZvcm0gdG8gb3RoZXINCiAgICAgICAgICAgIHJlc3Ry aWN0aW9ucyBvbiB2YXJpYW50IHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVudC4gIFRoaXMNCiAgICAg ICAgICAgIHNpdHVhdGlvbiBpcyB2ZXJ5IHVubGlrZWx5IHRvIGV2ZXIgb2NjdXIuDQoNCiAgIDEx LiAgVU4gTS40OSBoYXMgY29kZXMgZm9yIGJvdGggY291bnRyaWVzIGFuZCBhcmVhcyAoc3VjaCBh cyAnMjc2Jw0KICAgICAgICBmb3IgR2VybWFueSkgYW5kIGdlb2dyYXBoaWNhbCByZWdpb25zIGFu ZCBzdWItcmVnaW9ucyAoc3VjaCBhcw0KICAgICAgICAnMTUwJyBmb3IgRXVyb3BlKS4gIFVOIE0u NDkgY291bnRyeSBvciBhcmVhIGNvZGVzIGZvciB3aGljaA0KICAgICAgICB0aGVyZSBpcyBubyBj b3JyZXNwb25kaW5nIElTTyAzMTY2IGNvZGUgU0hPVUxEIE5PVCBiZQ0KICAgICAgICByZWdpc3Rl cmVkLCBleGNlcHQgYXMgYSBzdXJyb2dhdGUgZm9yIGFuIElTTyAzMTY2IGNvZGUgdGhhdCBpcw0K ICAgICAgICBibG9ja2VkIGZyb20gcmVnaXN0cmF0aW9uIGJ5IGFuIGV4aXN0aW5nIHN1YnRhZy4g IElmIHN1Y2ggYSBjb2RlDQogICAgICAgIGJlY29tZXMgbmVjZXNzYXJ5LCB0aGVuIHRoZSByZWdp c3RyYXRpb24gYXV0aG9yaXR5IGZvciBJU08gMzE2Ng0KICAgICAgICBTSE9VTEQgZmlyc3QgYmUg cGV0aXRpb25lZCB0byBhc3NpZ24gYSBjb2RlIHRvIHRoZSByZWdpb24uICBJZg0KICAgICAgICB0 aGUgcGV0aXRpb24gZm9yIGEgY29kZSBhc3NpZ25tZW50IGJ5IElTTyAzMTY2IGlzIHJlZnVzZWQg b3Igbm90DQogICAgICAgIGFjdGVkIG9uIGluIGEgdGltZWx5IG1hbm5lciwgdGhlIHJlZ2lzdHJh dGlvbiBwcm9jZXNzIGRlc2NyaWJlZA0KICAgICAgICBpbiBTZWN0aW9uIDMuNCBNQVkgdGhlbiBi ZSB1c2VkIHRvIHJlZ2lzdGVyIHRoZSBjb3JyZXNwb25kaW5nIFVODQogICAgICAgIE0uNDkgY29k ZS4gIEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQgd2FzIHdyaXR0ZW4sIHRoZXJlIHdlcmUNCiAg ICAgICAgb25seSBmb3VyIHN1Y2ggY29kZXM6IDgzMCAoQ2hhbm5lbCBJc2xhbmRzKSwgODMxIChH dWVybnNleSksIDgzMg0KICAgICAgICAoSmVyc2V5KSwgYW5kIDgzMyAoSXNsZSBvZiBNYW4pLiAg VGhpcyB3YXkgVU4gTS40OSBjb2RlcyByZW1haW4NCiAgICAgICAgYXZhaWxhYmxlIGFzIHRoZSB2 YWx1ZSBvZiBsYXN0IHJlc29ydCBpbiBjYXNlcyB3aGVyZSBJU08gMzE2Ng0KICAgICAgICByZWFz c2lnbnMgYSBkZXByZWNhdGVkIHZhbHVlIGluIHRoZSByZWdpc3RyeS4NCg0KICAgMTIuICBTdGFi aWxpdHkgcHJvdmlzaW9ucyBhcHBseSB0byBncmFuZGZhdGhlcmVkIHRhZ3Mgd2l0aCB0aGlzDQog ICAgICAgIGV4Y2VwdGlvbjogc2hvdWxkIGFsbCBvZiB0aGUgc3VidGFncyBpbiBhIGdyYW5kZmF0 aGVyZWQgdGFnDQogICAgICAgIGJlY29tZSB2YWxpZCBzdWJ0YWdzIGluIHRoZSBJQU5BIHJlZ2lz dHJ5LCB0aGVuIHRoZSBmaWVsZCAnVHlwZScNCiAgICAgICAgaW4gdGhhdCByZWNvcmQgaXMgY2hh bmdlZCBmcm9tICdncmFuZGZhdGhlcmVkJyB0byAncmVkdW5kYW50Jy4NCiAgICAgICAgTm90ZSB0 aGF0IHRoaXMgd2lsbCBub3QgYWZmZWN0IGxhbmd1YWdlIHRhZ3MgdGhhdCBtYXRjaCB0aGUNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAg ICAgICAgICAgIFtQYWdlIDI3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgICBncmFu ZGZhdGhlcmVkIHRhZywgc2luY2UgdGhlc2UgdGFncyB3aWxsIG5vdyBtYXRjaCB2YWxpZA0KICAg ICAgICBnZW5lcmF0aXZlIHN1YnRhZyBzZXF1ZW5jZXMuICBGb3IgZXhhbXBsZSwgaWYgdGhlIHN1 YnRhZyAnZ2FuJw0KICAgICAgICBpbiB0aGUgbGFuZ3VhZ2UgdGFnICJ6aC1nYW4iIHdlcmUgdG8g YmUgcmVnaXN0ZXJlZCBhcyBhbg0KICAgICAgICBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcsIHRo ZW4gdGhlIGdyYW5kZmF0aGVyZWQgdGFnICJ6aC1nYW4iDQogICAgICAgIHdvdWxkIGJlIGRlcHJl Y2F0ZWQgKGJ1dCBleGlzdGluZyBjb250ZW50IG9yIGltcGxlbWVudGF0aW9ucw0KICAgICAgICB0 aGF0IHVzZSAiemgtZ2FuIiB3b3VsZCByZW1haW4gdmFsaWQpLg0KDQoNCjMuNCAgUmVnaXN0cmF0 aW9uIFByb2NlZHVyZSBmb3IgU3VidGFncw0KDQogICBUaGUgcHJvY2VkdXJlIGdpdmVuIGhlcmUg TVVTVCBiZSB1c2VkIGJ5IGFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGENCiAgIHN1YnRhZyBub3Qg Y3VycmVudGx5IGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4NCg0KICAgT25s eSBzdWJ0YWdzICBvZiB0eXBlICdsYW5ndWFnZScgYW5kICd2YXJpYW50JyB3aWxsIGJlIGNvbnNp ZGVyZWQgZm9yDQogICBpbmRlcGVuZGVudCByZWdpc3RyYXRpb24gb2YgbmV3IHN1YnRhZ3MuICBI YW5kbGluZyBvZiBzdWJ0YWdzIG5lZWRlZA0KICAgZm9yIHN0YWJpbGl0eSBhbmQgc3VidGFncyBu ZWNlc3NhcnkgdG8ga2VlcCB0aGUgcmVnaXN0cnkgc3luY2hyb25pemVkDQogICB3aXRoIElTTyA2 MzksIElTTyAxNTkyNCwgSVNPIDMxNjYsIGFuZCBVTiBNLjQ5IHdpdGhpbiB0aGUgbGltaXRzDQog ICBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMi4g IFN0YWJpbGl0eQ0KICAgcHJvdmlzaW9ucyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLg0K DQogICBUaGlzIHByb2NlZHVyZSBNQVkgYWxzbyBiZSB1c2VkIHRvIHJlZ2lzdGVyIG9yIGFsdGVy IHRoZSBpbmZvcm1hdGlvbg0KICAgZm9yIHRoZSAiRGVzY3JpcHRpb24iLCAiQ29tbWVudHMiLCAi RGVwcmVjYXRlZCIsIG9yICJQcmVmaXgiIGZpZWxkcw0KICAgaW4gYSBzdWJ0YWcncyByZWNvcmQg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLiAgQ2hhbmdlcyB0byBhbGwNCiAgIG90aGVyIGZp ZWxkcyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcmUgTk9UIHBlcm1pdHRlZC4NCg0KICAgUmVnaXN0 ZXJpbmcgYSBuZXcgc3VidGFnIG9yIHJlcXVlc3RpbmcgbW9kaWZpY2F0aW9ucyB0byBhbiBleGlz dGluZw0KICAgdGFnIG9yIHN1YnRhZyBzdGFydHMgd2l0aCB0aGUgcmVxdWVzdGVyIGZpbGxpbmcg b3V0IHRoZSByZWdpc3RyYXRpb24NCiAgIGZvcm0gcmVwcm9kdWNlZCBiZWxvdy4gIE5vdGUgdGhh dCBlYWNoIHJlc3BvbnNlIGlzIG5vdCBsaW1pdGVkIGluDQogICBzaXplIHNvIHRoYXQgdGhlIHJl cXVlc3QgY2FuIGFkZXF1YXRlbHkgZGVzY3JpYmUgdGhlIHJlZ2lzdHJhdGlvbi4NCiAgIFRoZSBm aWVsZHMgaW4gdGhlICJSZWNvcmQgUmVxdWVzdGVkIiBzZWN0aW9uIFNIT1VMRCBmb2xsb3cgdGhl DQogICByZXF1aXJlbWVudHMgaW4gU2VjdGlvbiAzLjEuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0K DQogICBMQU5HVUFHRSBTVUJUQUcgUkVHSVNUUkFUSU9OIEZPUk0NCiAgIDEuIE5hbWUgb2YgcmVx dWVzdGVyOg0KICAgMi4gRS1tYWlsIGFkZHJlc3Mgb2YgcmVxdWVzdGVyOg0KICAgMy4gUmVjb3Jk IFJlcXVlc3RlZDoNCg0KICAgICAgVHlwZToNCiAgICAgIFN1YnRhZzoNCiAgICAgIERlc2NyaXB0 aW9uOg0KICAgICAgUHJlZml4Og0KICAgICAgUHJlZmVycmVkLVZhbHVlOg0KICAgICAgRGVwcmVj YXRlZDoNCiAgICAgIFN1cHByZXNzLVNjcmlwdDoNCiAgICAgIENvbW1lbnRzOg0KDQogICA0LiBJ bnRlbmRlZCBtZWFuaW5nIG9mIHRoZSBzdWJ0YWc6DQogICA1LiBSZWZlcmVuY2UgdG8gcHVibGlz aGVkIGRlc2NyaXB0aW9uDQogICAgICBvZiB0aGUgbGFuZ3VhZ2UgKGJvb2sgb3IgYXJ0aWNsZSk6 DQogICA2LiBBbnkgb3RoZXIgcmVsZXZhbnQgaW5mb3JtYXRpb246DQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA1DQoNCiAgIFRoZSBzdWJ0YWcgcmVnaXN0cmF0aW9u IGZvcm0gTVVTVCBiZSBzZW50IHRvDQogICA8aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmc+IGZvciBh IHR3byB3ZWVrIHJldmlldyBwZXJpb2QgYmVmb3JlIGl0IGNhbg0KICAgYmUgc3VibWl0dGVkIHRv IElBTkEuICAoVGhpcyBpcyBhbiBvcGVuIGxpc3QgYW5kIGNhbiBiZSBqb2luZWQgYnkNCiAgIHNl bmRpbmcgYSByZXF1ZXN0IHRvIDxpZXRmLWxhbmd1YWdlcy1yZXF1ZXN0QGlhbmEub3JnPi4pDQoN CiAgIFZhcmlhbnQgYW5kIGV4dGxhbmcgc3VidGFncyBhcmUgYWx3YXlzIHJlZ2lzdGVyZWQgZm9y IHVzZSB3aXRoIGENCiAgIHBhcnRpY3VsYXIgcmFuZ2Ugb2YgbGFuZ3VhZ2UgdGFncy4gIEZvciBl eGFtcGxlLCB0aGUgc3VidGFnICdyb3phaicNCiAgIGlzIGludGVuZGVkIGZvciB1c2Ugd2l0aCBs YW5ndWFnZSB0YWdzIHRoYXQgc3RhcnQgd2l0aCB0aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3Vi dGFnICJzbCIsIHNpbmNlIFJlc2lhbiBpcyBhIGRpYWxlY3Qgb2YgU2xvdmVuaWFuLiAgVGh1cw0K ICAgdGhlIHN1YnRhZyAncm96YWonIGNvdWxkIGJlIGluY2x1ZGVkIGluIHRhZ3Mgc3VjaCBhcyAi c2wtTGF0bi1yb3phaiINCiAgIG9yICJzbC1JVC1yb3phaiIuICBUaGlzIGluZm9ybWF0aW9uIGlz IHN0b3JlZCBpbiB0aGUgIlByZWZpeCIgZmllbGQNCiAgIGluIHRoZSByZWdpc3RyeS4gIFZhcmlh bnQgcmVnaXN0cmF0aW9uIHJlcXVlc3RzIGFyZSBSRVFVSVJFRCB0bw0KICAgaW5jbHVkZSBhdCBs ZWFzdCBvbmUgIlByZWZpeCIgZmllbGQgaW4gdGhlIHJlZ2lzdHJhdGlvbiBmb3JtLg0KDQogICBU aGUgJ1ByZWZpeCcgZmllbGQgZm9yIGEgZ2l2ZW4gcmVnaXN0ZXJlZCBzdWJ0YWcgZXhpc3RzIGlu IHRoZSBJQU5BDQogICByZWdpc3RyeSBhcyBhIGd1aWRlIHRvIHVzYWdlLiAgQWRkaXRpb25hbCBw cmVmaXhlcyBNQVkgYmUgYWRkZWQgYnkNCiAgIGZpbGluZyBhbiBhZGRpdGlvbmFsIHJlZ2lzdHJh dGlvbiBmb3JtLiAgSW4gdGhhdCBmb3JtLCB0aGUgIkFueSBvdGhlcg0KICAgcmVsZXZhbnQgaW5m b3JtYXRpb246IiBmaWVsZCBNVVNUIGluZGljYXRlIHRoYXQgaXQgaXMgdGhlIGFkZGl0aW9uIG9m DQogICBhIHByZWZpeC4NCg0KICAgUmVxdWVzdHMgdG8gYWRkIGEgcHJlZml4IHRvIGEgdmFyaWFu dCBzdWJ0YWcgdGhhdCBpbXBseSBhIGRpZmZlcmVudA0KICAgc2VtYW50aWMgbWVhbmluZyB3aWxs IHByb2JhYmx5IGJlIHJlamVjdGVkLiAgRm9yIGV4YW1wbGUsIGEgcmVxdWVzdA0KICAgdG8gYWRk IHRoZSBwcmVmaXggImRlIiB0byB0aGUgc3VidGFnICduZWRpcycgc28gdGhhdCB0aGUgdGFnICJk ZS0NCiAgIG5lZGlzIiByZXByZXNlbnRlZCBzb21lIEdlcm1hbiBkaWFsZWN0IHdvdWxkIGJlIHJl amVjdGVkLiAgVGhlDQogICAnbmVkaXMnIHN1YnRhZyByZXByZXNlbnRzIGEgcGFydGljdWxhciBT bG92ZW5pYW4gZGlhbGVjdCBhbmQgdGhlDQogICBhZGRpdGlvbmFsIHJlZ2lzdHJhdGlvbiB3b3Vs ZCBjaGFuZ2UgdGhlIHNlbWFudGljIG1lYW5pbmcgYXNzaWduZWQgdG8NCiAgIHRoZSBzdWJ0YWcu ICBBIHNlcGFyYXRlIHN1YnRhZyBTSE9VTEQgYmUgcHJvcG9zZWQgaW5zdGVhZC4NCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAg ICAgIFtQYWdlIDI5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgVGhlICdEZXNjcmlwdGlv bicgZmllbGQgTVVTVCBjb250YWluIGEgZGVzY3JpcHRpb24gb2YgdGhlIHRhZyBiZWluZw0KICAg cmVnaXN0ZXJlZCB3cml0dGVuIG9yIHRyYW5zY3JpYmVkIGludG8gdGhlIExhdGluIHNjcmlwdDsg aXQgTUFZIGFsc28NCiAgIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5vbi1MYXRpbiBzY3Jp cHQuICBOb24tQVNDSUkgY2hhcmFjdGVycw0KICAgTVVTVCBiZSBlc2NhcGVkIHVzaW5nIHRoZSBz eW50YXggZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLiAgVGhlDQogICAnRGVzY3JpcHRpb24nIGZp ZWxkIGlzIHVzZWQgZm9yIGlkZW50aWZpY2F0aW9uIHB1cnBvc2VzIGFuZCBkb2Vzbid0DQogICBu ZWNlc3NhcmlseSAgcmVwcmVzZW50IHRoZSBhY3R1YWwgbmF0aXZlIG5hbWUgb2YgdGhlIGxhbmd1 YWdlIG9yDQogICB2YXJpYXRpb24gb3IgdG8gYmUgaW4gYW55IHBhcnRpY3VsYXIgbGFuZ3VhZ2Uu DQoNCiAgIFdoaWxlIHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGl0c2VsZiBpcyBub3QgZ3VhcmFu dGVlZCB0byBiZSBzdGFibGUNCiAgIGFuZCBlcnJhdGEgY29ycmVjdGlvbnMgTUFZIGJlIHVuZGVy dGFrZW4gZnJvbSB0aW1lIHRvIHRpbWUsIGF0dGVtcHRzDQogICB0byBwcm92aWRlIHRyYW5zbGF0 aW9ucyBvciB0cmFuc2NyaXB0aW9ucyBvZiBlbnRyaWVzIGluIHRoZSByZWdpc3RyeQ0KICAgaXRz ZWxmIHdpbGwgcHJvYmFibHkgYmUgZnJvd25lZCB1cG9uIGJ5IHRoZSBjb21tdW5pdHkgb3IgcmVq ZWN0ZWQNCiAgIG91dHJpZ2h0LCBhcyBjaGFuZ2VzIG9mIHRoaXMgbmF0dXJlIGhhdmUgYW4gaW1w YWN0IG9uIHRoZSBwcm92aXNpb25zDQogICBpbiBTZWN0aW9uIDMuMy4NCg0KICAgVGhlIExhbmd1 YWdlIFN1YnRhZyBSZXZpZXdlciBpcyByZXNwb25zaWJsZSBmb3IgcmVzcG9uZGluZyB0bw0KICAg cmVxdWVzdHMgZm9yIHRoZSByZWdpc3RyYXRpb24gb2Ygc3VidGFncyB0aHJvdWdoIHRoZSByZWdp c3RyYXRpb24NCiAgIHByb2Nlc3MgIGFuZCBpcyBhcHBvaW50ZWQgYnkgdGhlIElFU0cuDQoNCiAg IFdoZW4gdGhlIHR3byB3ZWVrIHBlcmlvZCBoYXMgcGFzc2VkIHRoZSBMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXINCiAgIGVpdGhlciBmb3J3YXJkcyB0aGUgcmVjb3JkIHRvIGJlIGluc2VydGVkIG9y IG1vZGlmaWVkIHRvDQogICBpYW5hQGlhbmEub3JnIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJl IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMiwgb3INCiAgIHJlamVjdHMgdGhlIHJlcXVlc3QgYmVj YXVzZSBvZiBzaWduaWZpY2FudCBvYmplY3Rpb25zIHJhaXNlZCBvbiB0aGUNCiAgIGxpc3Qgb3Ig ZHVlIHRvIHByb2JsZW1zIHdpdGggY29uc3RyYWludHMgaW4gdGhpcyBkb2N1bWVudCAod2hpY2gg TVVTVA0KICAgYmUgZXhwbGljaXRseSBjaXRlZCkuICBUaGUgcmV2aWV3ZXIgTUFZIGFsc28gZXh0 ZW5kIHRoZSByZXZpZXcgcGVyaW9kDQogICBpbiB0d28gd2VlayBpbmNyZW1lbnRzIHRvIHBlcm1p dCBmdXJ0aGVyIGRpc2N1c3Npb24uICBUaGUgcmV2aWV3ZXINCiAgIE1VU1QgaW5kaWNhdGUgb24g dGhlIGxpc3Qgd2hldGhlciB0aGUgcmVnaXN0cmF0aW9uIGhhcyBiZWVuIGFjY2VwdGVkLA0KICAg cmVqZWN0ZWQsIG9yIGV4dGVuZGVkIGZvbGxvd2luZyBlYWNoIHR3byB3ZWVrIHBlcmlvZC4NCg0K ICAgTm90ZSB0aGF0IHRoZSByZXZpZXdlciBNQVkgcmFpc2Ugb2JqZWN0aW9ucyBvbiB0aGUgbGlz dCBpZiBoZSBvciBzaGUNCiAgIHNvIGRlc2lyZXMuICBUaGUgaW1wb3J0YW50IHRoaW5nIGlzIHRo YXQgdGhlIG9iamVjdGlvbiBNVVNUIGJlIG1hZGUNCiAgIHB1YmxpY2x5Lg0KDQogICBUaGUgYXBw bGljYW50IGlzIGZyZWUgdG8gbW9kaWZ5IGEgcmVqZWN0ZWQgYXBwbGljYXRpb24gd2l0aA0KICAg YWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhbmQgc3VibWl0IGl0IGFnYWluOyB0aGlzIHJlc3RhcnRz IHRoZSB0d28NCiAgIHdlZWsgY29tbWVudCBwZXJpb2QuDQoNCiAgIERlY2lzaW9ucyBtYWRlIGJ5 IHRoZSByZXZpZXdlciBNQVkgYmUgYXBwZWFsZWQgdG8gdGhlIElFU0cgW1JGQzIwMjhdDQogICB1 bmRlciB0aGUgc2FtZSBydWxlcyBhcyBvdGhlciBJRVRGIGRlY2lzaW9ucyBbUkZDMjAyNl0uDQoN CiAgIEFsbCBhcHByb3ZlZCByZWdpc3RyYXRpb24gZm9ybXMgYXJlIGF2YWlsYWJsZSBvbmxpbmUg aW4gdGhlIGRpcmVjdG9yeQ0KICAgaHR0cDovL3d3dy5pYW5hLm9yZy9udW1iZXJzLmh0bWwgdW5k ZXIgImxhbmd1YWdlcyIuDQoNCiAgIFVwZGF0ZXMgb3IgY2hhbmdlcyB0byBleGlzdGluZyByZWNv cmRzIGZvbGxvdyB0aGUgc2FtZSBwcm9jZWR1cmUgYXMNCiAgIG5ldyByZWdpc3RyYXRpb25zLiAg VGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBkZWNpZGVzIHdoZXRoZXINCiAgIHRoZXJlIGlz IGNvbnNlbnN1cyB0byB1cGRhdGUgdGhlIHJlZ2lzdHJhdGlvbiBmb2xsb3dpbmcgdGhlIHR3byB3 ZWVrDQogICByZXZpZXcgcGVyaW9kOyBub3JtYWxseSBvYmplY3Rpb25zIGJ5IHRoZSBvcmlnaW5h bCByZWdpc3RyYW50IHdpbGwNCiAgIGNhcnJ5IGV4dHJhIHdlaWdodCBpbiBmb3JtaW5nIHN1Y2gg YSBjb25zZW5zdXMuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAzMF0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0K DQoNCiAgIFJlZ2lzdHJhdGlvbnMgYXJlIHBlcm1hbmVudCBhbmQgc3RhYmxlLiAgT25jZSByZWdp c3RlcmVkLCBzdWJ0YWdzDQogICB3aWxsIG5vdCBiZSByZW1vdmVkIGZyb20gdGhlIHJlZ2lzdHJ5 IGFuZCB3aWxsIHJlbWFpbiBhIHZhbGlkIHdheSBpbg0KICAgd2hpY2ggdG8gc3BlY2lmeSBhIHNw ZWNpZmljIGxhbmd1YWdlIG9yIHZhcmlhbnQuDQoNCiAgIE5vdGU6IFRoZSBwdXJwb3NlIG9mIHRo ZSAiRGVzY3JpcHRpb24iIGluIHRoZSByZWdpc3RyYXRpb24gZm9ybSBpcw0KICAgaW50ZW5kZWQg YXMgYW4gYWlkIHRvIHBlb3BsZSB0cnlpbmcgdG8gdmVyaWZ5IHdoZXRoZXIgYSBsYW5ndWFnZSBp cw0KICAgcmVnaXN0ZXJlZCBvciB3aGF0IGxhbmd1YWdlIG9yIGxhbmd1YWdlIHZhcmlhdGlvbiBh IHBhcnRpY3VsYXIgc3VidGFnDQogICByZWZlcnMgdG8uICBJbiBtb3N0IGNhc2VzLCByZWZlcmVu Y2UgdG8gYW4gYXV0aG9yaXRhdGl2ZSBncmFtbWFyIG9yDQogICBkaWN0aW9uYXJ5IG9mIHRoYXQg bGFuZ3VhZ2Ugd2lsbCBiZSB1c2VmdWw7IGluIGNhc2VzIHdoZXJlIG5vIHN1Y2gNCiAgIHdvcmsg ZXhpc3RzLCBvdGhlciB3ZWxsIGtub3duIHdvcmtzIGRlc2NyaWJpbmcgdGhhdCBsYW5ndWFnZSBv ciBpbg0KICAgdGhhdCBsYW5ndWFnZSBNQVkgYmUgYXBwcm9wcmlhdGUuICBUaGUgc3VidGFnIHJl dmlld2VyIGRlY2lkZXMgd2hhdA0KICAgY29uc3RpdHV0ZXMgImdvb2QgZW5vdWdoIiByZWZlcmVu Y2UgbWF0ZXJpYWwuICBUaGlzIHJlcXVpcmVtZW50IGlzDQogICBub3QgaW50ZW5kZWQgdG8gZXhj bHVkZSBwYXJ0aWN1bGFyIGxhbmd1YWdlcyBvciBkaWFsZWN0cyBkdWUgdG8gdGhlDQogICBzaXpl IG9mIHRoZSBzcGVha2VyIHBvcHVsYXRpb24gb3IgbGFjayBvZiBhIHN0YW5kYXJkaXplZCBvcnRo b2dyYXBoeS4NCiAgIE1pbm9yaXR5IGxhbmd1YWdlcyB3aWxsIGJlIGNvbnNpZGVyZWQgZXF1YWxs eSBvbiB0aGVpciBvd24gbWVyaXRzLg0KDQozLjUgIFBvc3NpYmlsaXRpZXMgZm9yIFJlZ2lzdHJh dGlvbg0KDQogICBQb3NzaWJpbGl0aWVzIGZvciByZWdpc3RyYXRpb24gb2Ygc3VidGFncyBvciBp bmZvcm1hdGlvbiBhYm91dA0KICAgc3VidGFncyBpbmNsdWRlOg0KDQogICBvICBQcmltYXJ5IGxh bmd1YWdlIHN1YnRhZ3MgZm9yIGxhbmd1YWdlcyBub3QgbGlzdGVkIGluIElTTyA2MzkgdGhhdA0K ICAgICAgYXJlIG5vdCB2YXJpYW50cyBvZiBhbnkgbGlzdGVkIG9yIHJlZ2lzdGVyZWQgbGFuZ3Vh Z2UgTUFZIGJlDQogICAgICByZWdpc3RlcmVkLiAgQXQgdGhlIHRpbWUgdGhpcyBkb2N1bWVudCB3 YXMgY3JlYXRlZCB0aGVyZSB3ZXJlIG5vDQogICAgICBleGFtcGxlcyBvZiB0aGlzIGZvcm0gb2Yg c3VidGFnLiAgQmVmb3JlIGF0dGVtcHRpbmcgdG8gcmVnaXN0ZXIgYQ0KICAgICAgbGFuZ3VhZ2Ug c3VidGFnLCB0aGVyZSBNVVNUIGJlIGFuIGF0dGVtcHQgdG8gcmVnaXN0ZXIgdGhlIGxhbmd1YWdl DQogICAgICB3aXRoIElTTyA2MzkuICBTdWJ0YWdzIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQgZm9y IGNvZGVzIHRoYXQgZXhpc3QNCiAgICAgIGluIElTTyA2MzktMSBvciBJU08gNjM5LTIsIHdoaWNo IGFyZSB1bmRlciBjb25zaWRlcmF0aW9uIGJ5IHRoZQ0KICAgICAgSVNPIDYzOSBtYWludGVuYW5j ZSBvciByZWdpc3RyYXRpb24gYXV0aG9yaXRpZXMsIG9yIHdoaWNoIGhhdmUNCiAgICAgIG5ldmVy IGJlZW4gYXR0ZW1wdGVkIGZvciByZWdpc3RyYXRpb24gd2l0aCB0aG9zZSBhdXRob3JpdGllcy4g IElmDQogICAgICBJU08gNjM5IGhhcyBwcmV2aW91c2x5IHJlamVjdGVkIGEgbGFuZ3VhZ2UgZm9y IHJlZ2lzdHJhdGlvbiwgaXQgaXMNCiAgICAgIHJlYXNvbmFibGUgdG8gYXNzdW1lIHRoYXQgdGhl cmUgbXVzdCBiZSBhZGRpdGlvbmFsIHZlcnkgY29tcGVsbGluZw0KICAgICAgZXZpZGVuY2Ugb2Yg bmVlZCBiZWZvcmUgaXQgd2lsbCBiZSByZWdpc3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5DQog ICAgICAodG8gdGhlIGV4dGVudCB0aGF0IGl0IGlzIHZlcnkgdW5saWtlbHkgdGhhdCBhbnkgc3Vi dGFncyB3aWxsIGJlDQogICAgICByZWdpc3RlcmVkIG9mIHRoaXMgdHlwZSkuDQoNCiAgIG8gIERp YWxlY3Qgb3Igb3RoZXIgZGl2aXNpb25zIG9yIHZhcmlhdGlvbnMgd2l0aGluIGEgbGFuZ3VhZ2Us IGl0cw0KICAgICAgb3J0aG9ncmFwaHksIHdyaXRpbmcgc3lzdGVtLCByZWdpb25hbCBvciBoaXN0 b3JpY2FsIHVzYWdlLA0KICAgICAgdHJhbnNsaXRlcmF0aW9uIG9yIG90aGVyIHRyYW5zZm9ybWF0 aW9uLCBvciBkaXN0aW5ndWlzaGluZw0KICAgICAgdmFyaWF0aW9uIE1BWSBiZSByZWdpc3RlcmVk IGFzIHZhcmlhbnQgc3VidGFncy4gIEFuIGV4YW1wbGUgaXMgdGhlDQogICAgICAncm96YWonIHN1 YnRhZyAodGhlIFJlc2lhbiBkaWFsZWN0IG9mIFNsb3ZlbmlhbikuDQoNCiAgIG8gIFRoZSBhZGRp dGlvbiBvciBtYWludGVuYW5jZSBvZiBmaWVsZHMgKGdlbmVyYWxseSBvZiBhbg0KICAgICAgaW5m b3JtYXRpb25hbCBuYXR1cmUpIGluIFRhZyBvciBTdWJ0YWcgcmVjb3JkcyBhcyBkZXNjcmliZWQg aW4NCiAgICAgIFNlY3Rpb24gMy4xIGFuZCBzdWJqZWN0IHRvIHRoZSBzdGFiaWxpdHkgcHJvdmlz aW9ucyBpbg0KICAgICAgU2VjdGlvbiAzLjMuICBUaGlzIGluY2x1ZGVzICBkZXNjcmlwdGlvbnM7 IGNvbW1lbnRzOyBkZXByZWNhdGlvbg0KICAgICAgYW5kIHByZWZlcnJlZCB2YWx1ZXMgZm9yIG9i c29sZXRlIG9yIHdpdGhkcmF3biBjb2Rlczsgb3IgdGhlDQogICAgICBhZGRpdGlvbiBvZiBzY3Jp cHQgb3IgZXh0bGFuZyBpbmZvcm1hdGlvbiB0byBwcmltYXJ5IGxhbmd1YWdlDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAg ICBbUGFnZSAzMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgICAgIHN1YnRhZ3MuDQoNCiAg IG8gIFRoZSBhZGRpdGlvbiBvZiByZWNvcmRzIGFuZCByZWxhdGVkIGZpZWxkIHZhbHVlIGNoYW5n ZXMgbmVjZXNzYXJ5DQogICAgICB0byByZWZsZWN0IGFzc2lnbm1lbnRzIG1hZGUgYnkgSVNPIDYz OSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kDQogICAgICBVTiAgTS40OSBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiAzLjMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgbGVhdmVzIHRoZSBkZWNpc2lvbiBv biB3aGF0IHN1YnRhZ3MgIG9yIGNoYW5nZXMgdG8NCiAgIHN1YnRhZ3MgYXJlIGFwcHJvcHJpYXRl IChvciBub3QpIHRvIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMy40Lg0KDQogICBOb3RlOiBmb3VyIGNoYXJhY3RlciBwcmltYXJ5IGxhbmd1YWdlIHN1 YnRhZ3MgYXJlIHJlc2VydmVkIHRvIGFsbG93DQogICBmb3IgdGhlIHBvc3NpYmlsaXR5IG9mICBh bHBoYTQgY29kZXMgaW4gc29tZSBmdXR1cmUgYWRkaXRpb24gdG8gdGhlDQogICBJU08gNjM5IGZh bWlseSBvZiBzdGFuZGFyZHMuDQoNCiAgIElTTyA2MzkgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFn ZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzIGluDQogICB0aGUgbGlzdCBvZiBsYW5n dWFnZXMgaW4gSVNPIDYzOS4gIFRoaXMgYWdlbmN5IGlzOg0KDQogICBJbnRlcm5hdGlvbmFsIElu Zm9ybWF0aW9uIENlbnRyZSBmb3IgVGVybWlub2xvZ3kgKEluZm90ZXJtKQ0KICAgQWljaGhvbHpn YXNzZSA2LzEyLCBBVC0xMTIwDQogICBXaWVuLCBBdXN0cmlhDQogICBQaG9uZTogKzQzIDEgMjYg NzUgMzUgRXh0LiAzMTIgRmF4OiArNDMgMSAyMTYgMzIgNzINCg0KICAgSVNPIDYzOS0yIGRlZmlu ZXMgYSBtYWludGVuYW5jZSBhZ2VuY3kgZm9yIGFkZGl0aW9ucyB0byBhbmQgY2hhbmdlcw0KICAg aW4gdGhlIGxpc3Qgb2YgbGFuZ3VhZ2VzIGluIElTTyA2MzktMi4gIFRoaXMgYWdlbmN5IGlzOg0K DQogICBMaWJyYXJ5IG9mIENvbmdyZXNzDQogICBOZXR3b3JrIERldmVsb3BtZW50IGFuZCBNQVJD IFN0YW5kYXJkcyBPZmZpY2UNCiAgIFdhc2hpbmd0b24sIEQuQy4gMjA1NDAgVVNBDQogICBQaG9u ZTogKzEgMjAyIDcwNyA2MjM3ICBGYXg6ICsxIDIwMiA3MDcgMDExNQ0KICAgVVJMOiBodHRwOi8v d3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOQ0KDQogICBUaGUgbWFpbnRlbmFuY2UgYWdlbmN5 IGZvciBJU08gMzE2NiAoY291bnRyeSBjb2RlcykgaXM6DQoNCiAgIElTTyAzMTY2IE1haW50ZW5h bmNlIEFnZW5jeQ0KICAgYy9vIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFy ZGl6YXRpb24NCiAgIENhc2UgcG9zdGFsZSA1Ng0KICAgQ0gtMTIxMSBHZW5ldmEgMjAgU3dpdHpl cmxhbmQNCiAgIFBob25lOiArNDEgMjIgNzQ5IDcyIDMzICBGYXg6ICs0MSAyMiA3NDkgNzMgNDkN CiAgIFVSTDogaHR0cDovL3d3dy5pc28ub3JnL2lzby9lbi9wcm9kcy1zZXJ2aWNlcy9pc28zMTY2 bWEvaW5kZXguaHRtbA0KDQogICBUaGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBmb3IgSVNPIDE1 OTI0IChzY3JpcHQgY29kZXMpIGlzOg0KDQogICBVbmljb2RlIENvbnNvcnRpdW0gQm94IDM5MTQ3 Ng0KICAgTW91bnRhaW4gVmlldywgQ0EgOTQwMzktMTQ3NiwgVVNBDQogICBVUkw6IGh0dHA6Ly93 d3cudW5pY29kZS5vcmcvaXNvMTU5MjQNCg0KICAgVGhlIFN0YXRpc3RpY3MgRGl2aXNpb24gb2Yg dGhlIFVuaXRlZCBOYXRpb25zIFNlY3JldGFyaWF0IG1haW50YWlucw0KICAgdGhlIFN0YW5kYXJk IENvdW50cnkgb3IgQXJlYSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgVXNlIGFuZCBjYW4gYmUNCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAg ICAgICAgICAgIFtQYWdlIDMyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgcmVhY2hlZCBh dDoNCg0KICAgU3RhdGlzdGljYWwgU2VydmljZXMgQnJhbmNoDQogICBTdGF0aXN0aWNzIERpdmlz aW9uDQogICBVbml0ZWQgTmF0aW9ucywgUm9vbSBEQzItMTYyMA0KICAgTmV3IFlvcmssIE5ZIDEw MDE3LCBVU0ENCg0KICAgRmF4OiArMS0yMTItOTYzLTA2MjMNCiAgIEUtbWFpbDogc3RhdGlzdGlj c0B1bi5vcmcNCiAgIFVSTDogaHR0cDovL3Vuc3RhdHMudW4ub3JnL3Vuc2QvbWV0aG9kcy9tNDkv bTQ5YWxwaGEuaHRtDQoNCjMuNiAgRXh0ZW5zaW9ucyBhbmQgRXh0ZW5zaW9ucyBSZWdpc3RyeQ0K DQogICBFeHRlbnNpb24gc3VidGFncyBhcmUgdGhvc2UgaW50cm9kdWNlZCBieSBzaW5nbGUgY2hh cmFjdGVyIHN1YnRhZ3MNCiAgICgic2luZ2xldG9ucyIpIG90aGVyIHRoYW4gJ3gnLiAgVGhleSBh cmUgcmVzZXJ2ZWQgZm9yIHRoZSBnZW5lcmF0aW9uDQogICBvZiBpZGVudGlmaWVycyB3aGljaCBj b250YWluIGEgbGFuZ3VhZ2UgY29tcG9uZW50LCBhbmQgYXJlIGNvbXBhdGlibGUNCiAgIHdpdGgg YXBwbGljYXRpb25zIHRoYXQgdW5kZXJzdGFuZCBsYW5ndWFnZSB0YWdzLg0KDQogICBUaGUgc3Ry dWN0dXJlIGFuZCBmb3JtIG9mIGV4dGVuc2lvbnMgYXJlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVu dCBzbw0KICAgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY2FuIGJlIGNyZWF0ZWQgdGhhdCBhcmUgZm9y d2FyZCBjb21wYXRpYmxlIHdpdGgNCiAgIGFwcGxpY2F0aW9ucyB0aGF0IG1pZ2h0IGJlIGNyZWF0 ZWQgdXNpbmcgc2luZ2xldG9ucyBpbiB0aGUgZnV0dXJlLg0KICAgSW4gYWRkaXRpb24sIGRlZmlu aW5nIGEgbWVjaGFuaXNtIGZvciBtYWludGFpbmluZyBzaW5nbGV0b25zIHdpbGwNCiAgIGxlbmQg c3RhYmlsaXR5IHRvIHRoaXMgZG9jdW1lbnQgYnkgcmVkdWNpbmcgdGhlIGxpa2VseSBuZWVkIGZv cg0KICAgZnV0dXJlIHJldmlzaW9ucyBvciB1cGRhdGVzLg0KDQogICBTaW5nbGUgY2hhcmFjdGVy IHN1YnRhZ3MgYXJlIGFzc2lnbmVkIGJ5IElBTkEgdXNpbmcgdGhlICJJRVRGDQogICBDb25zZW5z dXMiIHBvbGljeSBkZWZpbmVkIGJ5IFtSRkMyNDM0XS4gIFRoaXMgcG9saWN5IHJlcXVpcmVzIHRo ZQ0KICAgZGV2ZWxvcG1lbnQgb2YgYW4gUkZDLCB3aGljaCBTSEFMTCBkZWZpbmUgdGhlIG5hbWUs IHB1cnBvc2UsDQogICBwcm9jZXNzZXMsIGFuZCBwcm9jZWR1cmVzIGZvciBtYWludGFpbmluZyB0 aGUgc3VidGFncy4gIFRoZQ0KICAgbWFpbnRhaW5pbmcgb3IgcmVnaXN0ZXJpbmcgYXV0aG9yaXR5 LCBpbmNsdWRpbmcgbmFtZSwgY29udGFjdCBlbWFpbCwNCiAgIGRpc2N1c3Npb24gbGlzdCBlbWFp bCwgYW5kIFVSTCBsb2NhdGlvbiBvZiB0aGUgcmVnaXN0cnkgTVVTVCBiZQ0KICAgaW5kaWNhdGVk IGNsZWFybHkgaW4gdGhlIFJGQy4gIFRoZSBSRkMgTVVTVCBzcGVjaWZ5IG9yIGluY2x1ZGUgZWFj aA0KICAgb2YgdGhlIGZvbGxvd2luZzoNCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBy ZWZlcmVuY2UgdGhlIHNwZWNpZmljIHZlcnNpb24gb3IgcmV2aXNpb24NCiAgICAgIG9mIHRoaXMg ZG9jdW1lbnQgdGhhdCBnb3Zlcm5zIGl0cyBjcmVhdGlvbiBhbmQgTVVTVCByZWZlcmVuY2UgdGhp cw0KICAgICAgc2VjdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBUaGUgc3BlY2lmaWNh dGlvbiBhbmQgYWxsIHN1YnRhZ3MgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbg0KICAgICAg TVVTVCBmb2xsb3cgdGhlIEFCTkYgYW5kIG90aGVyIHJ1bGVzIGZvciB0aGUgZm9ybWF0aW9uIG9m IHRhZ3MgYW5kDQogICAgICBzdWJ0YWdzIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIElu IHBhcnRpY3VsYXIgaXQgTVVTVA0KICAgICAgc3BlY2lmeSB0aGF0IGNhc2UgaXMgbm90IHNpZ25p ZmljYW50IGFuZCB0aGF0IHN1YnRhZ3MgTVVTVCBOT1QNCiAgICAgIGV4Y2VlZCBlaWdodCBjaGFy YWN0ZXJzIGluIGxlbmd0aC4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBzcGVjaWZ5 IGEgY2Fub25pY2FsIHJlcHJlc2VudGF0aW9uLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBv ZiB2YWxpZCBzdWJ0YWdzIE1VU1QgYmUgYXZhaWxhYmxlIG92ZXIgdGhlDQogICAgICBJbnRlcm5l dCBhbmQgYXQgbm8gY29zdC4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDMzXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA1DQoNCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBiZSBpbiB0aGUgcHVibGljIGRv bWFpbiBvciBhdmFpbGFibGUgdmlhIGENCiAgICAgIHJveWFsdHktZnJlZSBsaWNlbnNlIGFjY2Vw dGFibGUgdG8gdGhlIElFVEYgYW5kIHNwZWNpZmllZCBpbiB0aGUNCiAgICAgIFJGQy4NCg0KICAg byAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBiZSB2ZXJzaW9uZWQgYW5kIGVhY2ggdmVyc2lvbiBv ZiB0aGUNCiAgICAgIHNwZWNpZmljYXRpb24gTVVTVCBiZSBudW1iZXJlZCwgZGF0ZWQsIGFuZCBz dGFibGUuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgc3RhYmxlLiAgVGhhdCBp cywgZXh0ZW5zaW9uIHN1YnRhZ3MsDQogICAgICBvbmNlIGRlZmluZWQgYnkgYSBzcGVjaWZpY2F0 aW9uLCBNVVNUIE5PVCBiZSByZXRyYWN0ZWQgb3IgY2hhbmdlDQogICAgICBpbiBtZWFuaW5nIGlu IGFueSBzdWJzdGFudGlhbCB3YXkuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgaW5j bHVkZSBpbiBhIHNlcGFyYXRlIHNlY3Rpb24gdGhlDQogICAgICByZWdpc3RyYXRpb24gZm9ybSBy ZXByb2R1Y2VkIGluIHRoaXMgc2VjdGlvbiAoYmVsb3cpIHRvIGJlIHVzZWQgaW4NCiAgICAgIHJl Z2lzdGVyaW5nIHRoZSBleHRlbnNpb24gdXBvbiBwdWJsaWNhdGlvbiBhcyBhbiBSRkMuDQoNCiAg IG8gIElBTkEgTVVTVCBiZSBpbmZvcm1lZCBvZiBjaGFuZ2VzIHRvIHRoZSBjb250YWN0IGluZm9y bWF0aW9uIGFuZA0KICAgICAgVVJMIGZvciB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KICAgSUFOQSB3 aWxsIG1haW50YWluIGEgcmVnaXN0cnkgb2YgYWxsb2NhdGVkIHNpbmdsZSBjaGFyYWN0ZXINCiAg IChzaW5nbGV0b24pIHN1YnRhZ3MuICBUaGlzIHJlZ2lzdHJ5IE1VU1QgdXNlIHRoZSByZWNvcmQt amFyIGZvcm1hdA0KICAgZGVzY3JpYmVkIGJ5IHRoZSBBQk5GIGluIFNlY3Rpb24gMy4xLiAgVXBv biBwdWJsaWNhdGlvbiBvZiBhbg0KICAgZXh0ZW5zaW9uIGFzIGFuIFJGQywgdGhlIG1haW50YWlu aW5nIGF1dGhvcml0eSBkZWZpbmVkIGluIHRoZSBSRkMNCiAgIE1VU1QgZm9yd2FyZCB0aGlzIHJl Z2lzdHJhdGlvbiBmb3JtIHRvIGllc2dAaWV0Zi5vcmcsIHdobyBNVVNUDQogICBmb3J3YXJkIHRo ZSByZXF1ZXN0IHRvIGlhbmFAaWFuYS5vcmcuICBUaGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IG9m DQogICB0aGUgZXh0ZW5zaW9uIE1VU1QgbWFpbnRhaW4gdGhlIGFjY3VyYWN5IG9mIHRoZSByZWNv cmQgYnkgc2VuZGluZyBhbg0KICAgdXBkYXRlZCBmdWxsIGNvcHkgb2YgdGhlIHJlY29yZCB0byBp YW5hQGlhbmEub3JnIHdpdGggdGhlIHN1YmplY3QNCiAgIGxpbmUgIkxBTkdVQUdFIFRBRyBFWFRF TlNJT04gVVBEQVRFIiB3aGVuZXZlciBjb250ZW50IGNoYW5nZXMuICBPbmx5DQogICB0aGUgJ0Nv bW1lbnRzJywgJ0NvbnRhY3RfRW1haWwnLCAnTWFpbGluZ19MaXN0JywgYW5kICdVUkwnIGZpZWxk cyBNQVkNCiAgIGJlIG1vZGlmaWVkIGluIHRoZXNlIHVwZGF0ZXMuDQoNCiAgIEZhaWx1cmUgdG8g bWFpbnRhaW4gdGhpcyByZWNvcmQsIHRoZSBjb3JyZXNwb25kaW5nIHJlZ2lzdHJ5LCBvciBtZWV0 DQogICBvdGhlciBjb25kaXRpb25zIGltcG9zZWQgYnkgdGhpcyBzZWN0aW9uIG9mIHRoaXMgZG9j dW1lbnQgTUFZIGJlDQogICBhcHBlYWxlZCB0byB0aGUgSUVTRyBbUkZDMjAyOF0gdW5kZXIgdGhl IHNhbWUgcnVsZXMgYXMgb3RoZXIgSUVURg0KICAgZGVjaXNpb25zIChzZWUgW1JGQzIwMjZdKSBh bmQgTUFZIHJlc3VsdCBpbiB0aGUgYXV0aG9yaXR5IHRvIG1haW50YWluDQogICB0aGUgZXh0ZW5z aW9uIGJlaW5nIHdpdGhkcmF3biBvciByZWFzc2lnbmVkIGJ5IHRoZSBJRVNHLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAzNF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAw NQ0KDQoNCiAgICUlDQogICBJZGVudGlmaWVyOg0KICAgRGVzY3JpcHRpb246DQogICBDb21tZW50 czoNCiAgIEFkZGVkOg0KICAgUkZDOg0KICAgQXV0aG9yaXR5Og0KICAgQ29udGFjdF9FbWFpbDoN CiAgIE1haWxpbmdfTGlzdDoNCiAgIFVSTDoNCiAgICUlDQoNCiAgICBGaWd1cmUgNjogRm9ybWF0 IG9mIFJlY29yZHMgaW4gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5DQoNCiAg ICdJZGVudGlmaWVyJyBjb250YWlucyB0aGUgc2luZ2xlIGNoYXJhY3RlciBzdWJ0YWcgKHNpbmds ZXRvbikNCiAgIGFzc2lnbmVkIHRvIHRoZSBleHRlbnNpb24uICBUaGUgSW50ZXJuZXQtRHJhZnQg c3VibWl0dGVkIHRvIGRlZmluZQ0KICAgdGhlIGV4dGVuc2lvbiBTSE9VTEQgc3BlY2lmeSB3aGlj aCBsZXR0ZXIgb3IgZGlnaXQgdG8gdXNlLCBhbHRob3VnaA0KICAgdGhlIElFU0cgTUFZIGNoYW5n ZSB0aGUgYXNzaWdubWVudCB3aGVuIGFwcHJvdmluZyB0aGUgUkZDLg0KDQogICAnRGVzY3JpcHRp b24nIGNvbnRhaW5zIHRoZSBuYW1lIGFuZCBkZXNjcmlwdGlvbiBvZiB0aGUgZXh0ZW5zaW9uLg0K DQogICAnQ29tbWVudHMnIGlzIGFuIE9QVElPTkFMIGZpZWxkIGFuZCBNQVkgY29udGFpbiBhIGJy b2FkZXIgZGVzY3JpcHRpb24NCiAgIG9mIHRoZSBleHRlbnNpb24uDQoNCiAgICdBZGRlZCcgY29u dGFpbnMgdGhlIGRhdGUgdGhlIFJGQyB3YXMgcHVibGlzaGVkIGluIHRoZSAiZnVsbC1kYXRlIg0K ICAgZm9ybWF0IHNwZWNpZmllZCBpbiBbUkZDMzMzOV0uICBGb3IgZXhhbXBsZTogMjAwNC0wNi0y OCByZXByZXNlbnRzDQogICBKdW5lIDI4LCAyMDA0LCBpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFy Lg0KDQogICAnUkZDJyBjb250YWlucyB0aGUgUkZDIG51bWJlciBhc3NpZ25lZCB0byB0aGUgZXh0 ZW5zaW9uLg0KDQogICAnQXV0aG9yaXR5JyBjb250YWlucyB0aGUgbmFtZSBvZiB0aGUgbWFpbnRh aW5pbmcgYXV0aG9yaXR5IGZvciB0aGUNCiAgIGV4dGVuc2lvbi4NCg0KICAgJ0NvbnRhY3RfRW1h aWwnIGNvbnRhaW5zIHRoZSBlbWFpbCBhZGRyZXNzIHVzZWQgdG8gY29udGFjdCB0aGUNCiAgIG1h aW50YWluaW5nIGF1dGhvcml0eS4NCg0KICAgJ01haWxpbmdfTGlzdCcgY29udGFpbnMgdGhlIFVS TCBvciBzdWJzY3JpcHRpb24gZW1haWwgYWRkcmVzcyBvZiB0aGUNCiAgIG1haWxpbmcgbGlzdCB1 c2VkIGJ5IHRoZSBtYWludGFpbmluZyBhdXRob3JpdHkuDQoNCiAgICdVUkwnIGNvbnRhaW5zIHRo ZSBVUkwgb2YgdGhlIHJlZ2lzdHJ5IGZvciB0aGlzIGV4dGVuc2lvbi4NCg0KICAgVGhlIGRldGVy bWluYXRpb24gb2Ygd2hldGhlciBhbiBJbnRlcm5ldC1EcmFmdCBtZWV0cyB0aGUgYWJvdmUNCiAg IGNvbmRpdGlvbnMgYW5kIHRoZSBkZWNpc2lvbiB0byBncmFudCBvciB3aXRoaG9sZCBzdWNoIGF1 dGhvcml0eSByZXN0cw0KICAgc29sZWx5IHdpdGggdGhlIElFU0csIGFuZCBpcyBzdWJqZWN0IHRv IHRoZSBub3JtYWwgcmV2aWV3IGFuZCBhcHBlYWxzDQogICBwcm9jZXNzIGFzc29jaWF0ZWQgd2l0 aCB0aGUgUkZDIHByb2Nlc3MuDQoNCiAgIEV4dGVuc2lvbiBhdXRob3JzIGFyZSBzdHJvbmdseSBj YXV0aW9uZWQgdGhhdCBtYW55IChpbmNsdWRpbmcgbW9zdA0KICAgd2VsbC1mb3JtZWQpIHByb2Nl c3NvcnMgd2lsbCBiZSB1bmF3YXJlIG9mIGFueSBzcGVjaWFsIHJlbGF0aW9uc2hpcHMNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAg ICAgICAgIFtQYWdlIDM1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgb3IgbWVhbmluZyBp bmhlcmVudCBpbiB0aGUgb3JkZXIgb2YgZXh0ZW5zaW9uIHN1YnRhZ3MuICBFeHRlbnNpb24NCiAg IGF1dGhvcnMgU0hPVUxEIGF2b2lkIHN1YnRhZyByZWxhdGlvbnNoaXBzIG9yIGNhbm9uaWNhbGl6 YXRpb24NCiAgIG1lY2hhbmlzbXMgdGhhdCBpbnRlcmZlcmUgd2l0aCBtYXRjaGluZyBvciB3aXRo IGxlbmd0aCByZXN0cmljdGlvbnMNCiAgIHRoYXQgc29tZXRpbWVzIGV4aXN0IGluIGNvbW1vbiBw cm90b2NvbHMgd2hlcmUgdGhlIGV4dGVuc2lvbiBpcyB1c2VkLg0KICAgSW4gcGFydGljdWxhciwg YXBwbGljYXRpb25zIE1BWSB0cnVuY2F0ZSB0aGUgc3VidGFncyBpbiBkb2luZw0KICAgbWF0Y2hp bmcgb3IgaW4gZml0dGluZyBpbnRvIGxpbWl0ZWQgbGVuZ3Rocywgc28gaXQgaXMgUkVDT01NRU5E RUQNCiAgIHRoYXQgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgaW5mb3JtYXRpb24gYmUgaW4gdGhlIG1v c3Qgc2lnbmlmaWNhbnQNCiAgIChsZWZ0LW1vc3QpIHN1YnRhZ3MsIGFuZCB0aGF0IHRoZSBzcGVj aWZpY2F0aW9uIGdyYWNlZnVsbHkgaGFuZGxlDQogICB0cnVuY2F0ZWQgc3VidGFncy4NCg0KICAg V2hlbiBhIGxhbmd1YWdlIHRhZyBpcyB0byBiZSB1c2VkIGluIGEgc3BlY2lmaWMsIGtub3duLCBw cm90b2NvbCwgaXQNCiAgIGlzIFJFQ09NTUVOREVEIHRoYXQgdGhhdCB0aGUgbGFuZ3VhZ2UgdGFn IG5vdCBjb250YWluIGV4dGVuc2lvbnMgbm90DQogICBzdXBwb3J0ZWQgYnkgdGhhdCBwcm90b2Nv bC4gIEluIGFkZGl0aW9uLCBub3RlIHRoYXQgc29tZSBwcm90b2NvbHMNCiAgIE1BWSBpbXBvc2Ug dXBwZXIgbGltaXRzIG9uIHRoZSBsZW5ndGggb2YgdGhlIHN0cmluZ3MgdXNlZCB0byBzdG9yZSBv cg0KICAgdHJhbnNwb3J0IHRoZSBsYW5ndWFnZSB0YWcuDQoNCjMuNyAgSW5pdGlhbGl6YXRpb24g b2YgdGhlIFJlZ2lzdHJpZXMNCg0KICAgVXBvbiBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFu IGluaXRpYWwgdmVyc2lvbiBvZiB0aGUgTGFuZ3VhZ2UNCiAgIFN1YnRhZyBSZWdpc3RyeSBjb250 YWluaW5nIHRoZSB2YXJpb3VzIHN1YnRhZ3MgaW5pdGlhbGx5IHZhbGlkIGluIGENCiAgIGxhbmd1 YWdlIHRhZyBpcyBuZWNlc3NhcnkuICBUaGlzIGNvbGxlY3Rpb24gb2Ygc3VidGFncywgYWxvbmcg d2l0aCBhDQogICBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvY2VzcyB1c2VkIHRvIGNyZWF0ZSBpdCwg aXMgZGVzY3JpYmVkIGJ5DQogICBbaW5pdGlhbC1yZWdpc3RyeV0uDQoNCiAgIFJlZ2lzdHJhdGlv bnMgdGhhdCBhcmUgaW4gcHJvY2VzcyB1bmRlciB0aGUgcnVsZXMgZGVmaW5lZCBpbg0KICAgW1JG QzMwNjZdIHdoZW4gdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIE1BWSBiZSBjb21wbGV0ZWQgdW5k ZXIgdGhlDQogICBmb3JtZXIgcnVsZXMsIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBsYW5ndWFn ZSB0YWcgcmV2aWV3ZXIuICBBbnkNCiAgIG5ldyByZWdpc3RyYXRpb25zIHN1Ym1pdHRlZCBhZnRl ciB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBNVVNUDQogICBiZSByZWplY3RlZC4NCg0K ICAgQW4gaW5pdGlhbCB2ZXJzaW9uIG9mIHRoZSBMYW5ndWFnZSBFeHRlbnNpb24gUmVnaXN0cnkg ZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDMuNiBpcyBhbHNvIG5lZWRlZC4gIFRoZSBMYW5ndWFn ZSBFeHRlbnNpb24gUmVnaXN0cnkgU0hBTEwgYmUNCiAgIGluaXRpYWxpemVkIHdpdGggYSBzaW5n bGUgcmVjb3JkIGNvbnRhaW5pbmcgYSBzaW5nbGUgZmllbGQgb2YgdHlwZQ0KICAgIkZpbGUtRGF0 ZSIgYXMgYSBwbGFjZWhvbGRlciBmb3IgZnV0dXJlIGFzc2lnbm1lbnRzLg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDM2XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1 DQoNCg0KNC4gIEZvcm1hdGlvbiBhbmQgUHJvY2Vzc2luZyBvZiBMYW5ndWFnZSBUYWdzDQoNCiAg IFRoaXMgc2VjdGlvbiBhZGRyZXNzZXMgaG93IHRvIHVzZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhl IHJlZ2lzdHJ5DQogICB3aXRoIHRoZSB0YWcgc3ludGF4IHRvIGNob29zZSwgZm9ybSBhbmQgcHJv Y2VzcyBsYW5ndWFnZSB0YWdzLg0KDQo0LjEgIENob2ljZSBvZiBMYW5ndWFnZSBUYWcNCg0KICAg T25lIGlzIHNvbWV0aW1lcyBmYWNlZCB3aXRoIHRoZSBjaG9pY2UgYmV0d2VlbiBzZXZlcmFsIHBv c3NpYmxlIHRhZ3MNCiAgIGZvciB0aGUgc2FtZSBib2R5IG9mIHRleHQuDQoNCiAgIEludGVyb3Bl cmFiaWxpdHkgaXMgYmVzdCBzZXJ2ZWQgd2hlbiBhbGwgdXNlcnMgdXNlIHRoZSBzYW1lIGxhbmd1 YWdlDQogICB0YWcgaW4gb3JkZXIgdG8gcmVwcmVzZW50IHRoZSBzYW1lIGxhbmd1YWdlLiAgSWYg YW4gYXBwbGljYXRpb24gaGFzDQogICByZXF1aXJlbWVudHMgdGhhdCBtYWtlIHRoZSBydWxlcyBo ZXJlIGluYXBwbGljYWJsZSwgdGhlbiB0aGF0DQogICBhcHBsaWNhdGlvbiByaXNrcyBkYW1hZ2lu ZyBpbnRlcm9wZXJhYmlsaXR5LiAgSXQgaXMgc3Ryb25nbHkNCiAgIFJFQ09NTUVOREVEIHRoYXQg dXNlcnMgbm90IGRlZmluZSB0aGVpciBvd24gcnVsZXMgZm9yIGxhbmd1YWdlIHRhZw0KICAgY2hv aWNlLg0KDQogICBTdWJ0YWdzIFNIT1VMRCBvbmx5IGJlIHVzZWQgIHdoZXJlIHRoZXkgYWRkIHVz ZWZ1bCBkaXN0aW5ndWlzaGluZw0KICAgaW5mb3JtYXRpb247IGV4dHJhbmVvdXMgc3VidGFncyBp bnRlcmZlcmUgd2l0aCB0aGUgbWVhbmluZywNCiAgIHVuZGVyc3RhbmRpbmcsIGFuZCBwcm9jZXNz aW5nIG9mIGxhbmd1YWdlIHRhZ3MuICBJbiBwYXJ0aWN1bGFyLCB1c2Vycw0KICAgYW5kIGltcGxl bWVudGF0aW9ucyBTSE9VTEQgZm9sbG93IHRoZSAnUHJlZml4JyBhbmQgJ1N1cHByZXNzLVNjcmlw dCcNCiAgIGZpZWxkcyBpbiB0aGUgcmVnaXN0cnkgKGRlZmluZWQgaW4gU2VjdGlvbiAzLjEpOiB0 aGVzZSBmaWVsZHMgcHJvdmlkZQ0KICAgZ3VpZGFuY2Ugb24gd2hlbiBzcGVjaWZpYyBhZGRpdGlv bmFsIHN1YnRhZ3MgU0hPVUxEIChhbmQgU0hPVUxEIE5PVCkNCiAgIGJlIHVzZWQgaW4gYSBsYW5n dWFnZSB0YWcuDQoNCiAgIE9mIHBhcnRpY3VsYXIgbm90ZSwgbWFueSBhcHBsaWNhdGlvbnMgY2Fu IGJlbmVmaXQgZnJvbSB0aGUgdXNlIG9mDQogICBzY3JpcHQgc3VidGFncyBpbiBsYW5ndWFnZSB0 YWdzLCBhcyBsb25nIGFzIHRoZSB1c2UgaXMgY29uc2lzdGVudCBmb3INCiAgIGEgZ2l2ZW4gY29u dGV4dC4gIFNjcmlwdCBzdWJ0YWdzIHdlcmUgbm90IGZvcm1hbGx5IGRlZmluZWQgaW4gUkZDDQog ICAzMDY2IGFuZCB0aGVpciB1c2UgY2FuIGFmZmVjdCBtYXRjaGluZyBhbmQgc3VidGFnIGlkZW50 aWZpY2F0aW9uIGJ5DQogICBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDIDMwNjYsIGFzIHRoZXNlIHN1 YnRhZ3MgYXBwZWFyIGJldHdlZW4gdGhlDQogICBwcmltYXJ5IGxhbmd1YWdlIGFuZCByZWdpb24g c3VidGFncy4gIEZvciBleGFtcGxlLCBpZiBhIHVzZXIgcmVxdWVzdHMNCiAgIGNvbnRlbnQgaW4g YW4gaW1wbGVtZW50YXRpb24gb2YgU2VjdGlvbiAyLjUgb2YgW1JGQzMwNjZdIHVzaW5nIHRoZQ0K ICAgbGFuZ3VhZ2UgcmFuZ2UgImVuLVVTIiwgY29udGVudCBsYWJlbGVkICJlbi1MYXRuLVVTIiB3 aWxsIG5vdCBtYXRjaA0KICAgdGhlIHJlcXVlc3QuICBUaGVyZWZvcmUgaXQgaXMgaW1wb3J0YW50 IHRvIGtub3cgd2hlbiBzY3JpcHQgc3VidGFncw0KICAgd2lsbCBjdXN0b21hcmlseSBiZSB1c2Vk IGFuZCB3aGVuIHRoZXkgb3VnaHQgbm90IGJlIHVzZWQuICBJbiB0aGUNCiAgIHJlZ2lzdHJ5LCB0 aGUgU3VwcHJlc3MtU2NyaXB0IGZpZWxkIGhlbHBzIGVuc3VyZSBncmVhdGVyDQogICBjb21wYXRp YmlsaXR5IGJldHdlZW4gdGhlIGxhbmd1YWdlIHRhZ3MgZ2VuZXJhdGVkIGFjY29yZGluZyB0byB0 aGUNCiAgIHJ1bGVzIGluIHRoaXMgZG9jdW1lbnQgYW5kIGxhbmd1YWdlIHRhZ3MgYW5kIHRhZyBw cm9jZXNzb3JzIG9yDQogICBjb25zdW1lcnMgYmFzZWQgb24gUkZDIDMwNjYgYnkgZGVmaW5pbmcg d2hlbiB1c2VycyBTSE9VTEQgTk9UIGluY2x1ZGUNCiAgIGEgc2NyaXB0IHN1YnRhZyB3aXRoIGEg cGFydGljdWxhciBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZy4NCg0KICAgRXh0ZW5kZWQgbGFuZ3Vh Z2Ugc3VidGFncyAodHlwZSAnZXh0bGFuZycgaW4gdGhlIHJlZ2lzdHJ5LCBzZWUNCiAgIFNlY3Rp b24gMy4xKSBhbHNvIGFwcGVhciBiZXR3ZWVuIHRoZSBwcmltYXJ5IGxhbmd1YWdlIGFuZCByZWdp b24NCiAgIHN1YnRhZ3MgYW5kIGFyZSByZXNlcnZlZCBmb3IgZnV0dXJlIHN0YW5kYXJkaXphdGlv bi4gIEFwcGxpY2F0aW9ucw0KICAgbWlnaHQgYmVuZWZpdCBmcm9tIHRoZWlyIGp1ZGljaW91cyB1 c2UgaW4gZm9ybWluZyBsYW5ndWFnZSB0YWdzIGluDQogICB0aGUgZnV0dXJlLiAgU2ltaWxhciBy ZWNvbW1lbmRhdGlvbnMgYXJlIGV4cGVjdGVkIHRvIGFwcGx5IHRvIHRoZWlyDQogICB1c2UgYXMg YXBwbHkgdG8gc2NyaXB0IHN1YnRhZ3MuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDM3XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg IEF1Z3VzdCAyMDA1DQoNCg0KICAgU3RhbmRhcmRzLCBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9u cyB0aGF0IHJlZmVyZW5jZSB0aGlzIGRvY3VtZW50DQogICBub3JtYXRpdmVseSBidXQgYXBwbHkg ZGlmZmVyZW50IHJ1bGVzIHRvIHRoZSBvbmVzIGdpdmVuIGluIHRoaXMNCiAgIHNlY3Rpb24gTVVT VCBzcGVjaWZ5IGhvdyB0aGUgcHJvY2VkdXJlIHZhcmllcyBmcm9tIHRoZSBvbmUgZ2l2ZW4NCiAg IGhlcmUuDQoNCiAgIFRoZSBjaG9pY2Ugb2Ygc3VidGFncyB1c2VkIHRvIGZvcm0gYSBsYW5ndWFn ZSB0YWcgU0hPVUxEIGJlIGd1aWRlZCBieQ0KICAgdGhlIGZvbGxvd2luZyBydWxlczoNCg0KICAg MS4gIFVzZSBhcyBwcmVjaXNlIGEgdGFnIGFzIHBvc3NpYmxlLCBidXQgbm8gbW9yZSBzcGVjaWZp YyB0aGFuIGlzDQogICAgICAganVzdGlmaWVkLiAgQXZvaWQgdXNpbmcgc3VidGFncyB0aGF0IGFy ZSBub3QgaW1wb3J0YW50IGZvcg0KICAgICAgIGRpc3Rpbmd1aXNoaW5nIGNvbnRlbnQgaW4gYW4g YXBwbGljYXRpb24uDQoNCiAgICAgICAqICBGb3IgZXhhbXBsZSwgJ2RlJyBtaWdodCBzdWZmaWNl IGZvciB0YWdnaW5nIGFuIGVtYWlsIHdyaXR0ZW4NCiAgICAgICAgICBpbiBHZXJtYW4sIHdoaWxl ICJkZS1DSC0xOTk2IiBpcyBwcm9iYWJseSB1bm5lY2Vzc2FyaWx5DQogICAgICAgICAgcHJlY2lz ZSBmb3Igc3VjaCBhIHRhc2suDQoNCiAgIDIuICBUaGUgc2NyaXB0IHN1YnRhZyBTSE9VTEQgTk9U IGJlIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHVubGVzcw0KICAgICAgIHRoZSBzY3JpcHQg YWRkcyBzb21lIGRpc3Rpbmd1aXNoaW5nIGluZm9ybWF0aW9uIHRvIHRoZSB0YWcuICBUaGUNCiAg ICAgICBmaWVsZCAnU3VwcHJlc3MtU2NyaXB0JyBpbiB0aGUgcHJpbWFyeSBsYW5ndWFnZSByZWNv cmQgaW4gdGhlDQogICAgICAgcmVnaXN0cnkgaW5kaWNhdGVzIHdoaWNoIHNjcmlwdCBzdWJ0YWdz IGRvIG5vdCBhZGQgZGlzdGluZ3Vpc2hpbmcNCiAgICAgICBpbmZvcm1hdGlvbiBmb3IgbW9zdCBh cHBsaWNhdGlvbnMuDQoNCiAgICAgICAqICBGb3IgZXhhbXBsZSwgdGhlIHN1YnRhZyAnTGF0bicg c2hvdWxkIG5vdCBiZSB1c2VkIHdpdGggdGhlDQogICAgICAgICAgcHJpbWFyeSBsYW5ndWFnZSAn ZW4nIGJlY2F1c2UgbmVhcmx5IGFsbCBFbmdsaXNoIGRvY3VtZW50cyBhcmUNCiAgICAgICAgICB3 cml0dGVuIGluIHRoZSBMYXRpbiBzY3JpcHQgYW5kIGl0IGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcN CiAgICAgICAgICBpbmZvcm1hdGlvbi4gIEhvd2V2ZXIsIGlmIGEgZG9jdW1lbnQgd2VyZSB3cml0 dGVuIGluIEVuZ2xpc2gNCiAgICAgICAgICBtaXhpbmcgTGF0aW4gc2NyaXB0IHdpdGggYW5vdGhl ciBzY3JpcHQgc3VjaCBhcyBCcmFpbGxlDQogICAgICAgICAgKCdCcmFpJyksIHRoZW4gaXQgbWln aHQgYmUgYXBwcm9wcmlhdGUgdG8gY2hvb3NlIHRvIGluZGljYXRlDQogICAgICAgICAgYm90aCBz Y3JpcHRzIHRvIGFpZCBpbiBjb250ZW50IHNlbGVjdGlvbiwgc3VjaCBhcyB0aGUNCiAgICAgICAg ICBhcHBsaWNhdGlvbiBvZiBhIHN0eWxlIHNoZWV0Lg0KDQogICAzLiAgSWYgYSB0YWcgb3Igc3Vi dGFnIGhhcyBhICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIGluIGl0cyByZWdpc3RyeQ0KICAgICAg IGVudHJ5LCB0aGVuIHRoZSAgdmFsdWUgb2YgdGhhdCBmaWVsZCBTSE9VTEQgYmUgdXNlZCB0byBm b3JtIHRoZQ0KICAgICAgIGxhbmd1YWdlIHRhZyBpbiBwcmVmZXJlbmNlIHRvIHRoZSB0YWcgb3Ig c3VidGFnIGluIHdoaWNoIHRoZQ0KICAgICAgIHByZWZlcnJlZCB2YWx1ZSBhcHBlYXJzLg0KDQog ICAgICAgKiAgRm9yIGV4YW1wbGUsIHVzZSAnaGUnIGZvciBIZWJyZXcgaW4gcHJlZmVyZW5jZSB0 byAnaXcnLg0KDQogICA0LiAgVGhlICd1bmQnIChVbmRldGVybWluZWQpIHByaW1hcnkgbGFuZ3Vh Z2Ugc3VidGFnIFNIT1VMRCBOT1QgYmUNCiAgICAgICB1c2VkIHRvIGxhYmVsIGNvbnRlbnQsIGV2 ZW4gaWYgdGhlIGxhbmd1YWdlIGlzIHVua25vd24uICBPbWl0dGluZw0KICAgICAgIHRoZSBsYW5n dWFnZSB0YWcgYWx0b2dldGhlciBpcyBwcmVmZXJyZWQgdG8gdXNpbmcgYSB0YWcgd2l0aCBhDQog ICAgICAgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgb2YgJ3VuZCcuICBUaGUgJ3VuZCcgc3VidGFn IE1BWSBiZSB1c2VmdWwNCiAgICAgICBmb3IgcHJvdG9jb2xzIHRoYXQgcmVxdWlyZSBhIGxhbmd1 YWdlIHRhZyB0byBiZSBwcm92aWRlZC4gIFRoZQ0KICAgICAgICd1bmQnIHN1YnRhZyBNQVkgYWxz byBiZSB1c2VmdWwgd2hlbiBtYXRjaGluZyBsYW5ndWFnZSB0YWdzIGluDQogICAgICAgY2VydGFp biBzaXR1YXRpb25zLg0KDQogICA1LiAgVGhlICdtdWwnIChNdWx0aXBsZSkgcHJpbWFyeSBsYW5n dWFnZSBzdWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2VkDQogICAgICAgd2hlbmV2ZXIgdGhlIHByb3Rv Y29sIGFsbG93cyB0aGUgc2VwYXJhdGUgdGFncyBmb3IgbXVsdGlwbGUNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQ YWdlIDM4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgIGxhbmd1YWdlcywgYXMgaXMg dGhlIGNhc2UgZm9yIHRoZSBDb250ZW50LUxhbmd1YWdlIGhlYWRlciBpbg0KICAgICAgIEhUVFAu ICBUaGUgJ211bCcgc3VidGFnIGNvbnZleXMgbGl0dGxlIHVzZWZ1bCBpbmZvcm1hdGlvbjoNCiAg ICAgICBjb250ZW50IGluIG11bHRpcGxlIGxhbmd1YWdlcyBTSE9VTEQgaW5kaXZpZHVhbGx5IHRh ZyB0aGUNCiAgICAgICBsYW5ndWFnZXMgd2hlcmUgdGhleSBhcHBlYXIgb3Igb3RoZXJ3aXNlIGlu ZGljYXRlIHRoZSBhY3R1YWwNCiAgICAgICBsYW5ndWFnZSBpbiBwcmVmZXJlbmNlIHRvIHRoZSAn bXVsJyBzdWJ0YWcuDQoNCiAgIDYuICBUaGUgc2FtZSB2YXJpYW50IHN1YnRhZyBTSE9VTEQgTk9U IGJlIHVzZWQgbW9yZSB0aGFuIG9uY2Ugd2l0aGluDQogICAgICAgYSBsYW5ndWFnZSB0YWcuDQoN CiAgICAgICAqICBGb3IgZXhhbXBsZSwgZG8gbm90IHVzZSAiZGUtREUtMTkwMS0xOTAxIi4NCg0K ICAgVG8gZW5zdXJlIGNvbnNpc3RlbnQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgdGhpcyBkb2N1 bWVudCBjb250YWlucw0KICAgc2V2ZXJhbCBwcm92aXNpb25zIHRvIGFjY291bnQgZm9yIHBvdGVu dGlhbCBpbnN0YWJpbGl0eSBpbiB0aGUNCiAgIHN0YW5kYXJkcyB1c2VkIHRvIGRlZmluZSB0aGUg c3VidGFncyB0aGF0IG1ha2UgdXAgbGFuZ3VhZ2UgdGFncy4NCiAgIFRoZXNlIHByb3Zpc2lvbnMg bWVhbiB0aGF0IG5vIGxhbmd1YWdlIHRhZyBjcmVhdGVkIHVuZGVyIHRoZSBydWxlcyBpbg0KICAg dGhpcyBkb2N1bWVudCB3aWxsIGJlY29tZSBvYnNvbGV0ZS4NCg0KNC4yICBNZWFuaW5nIG9mIHRo ZSBMYW5ndWFnZSBUYWcNCg0KICAgVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB0YWcgYW5k IHRoZSBpbmZvcm1hdGlvbiBpdCByZWxhdGVzIHRvIGlzDQogICBkZWZpbmVkIGJ5IHRoZSBjb250 ZXh0IGluIHdoaWNoIHRoZSB0YWcgYXBwZWFycy4gIEFjY29yZGluZ2x5LCB0aGlzDQogICBzZWN0 aW9uIGdpdmVzIG9ubHkgcG9zc2libGUgZXhhbXBsZXMgb2YgaXRzIHVzYWdlLg0KDQogICBvICBG b3IgYSBzaW5nbGUgaW5mb3JtYXRpb24gb2JqZWN0LCB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0 YWdzDQogICAgICBtaWdodCBiZSBpbnRlcnByZXRlZCBhcyB0aGUgc2V0IG9mIGxhbmd1YWdlcyB0 aGF0IGlzIG5lY2Vzc2FyeSBmb3INCiAgICAgIGEgY29tcGxldGUgY29tcHJlaGVuc2lvbiBvZiB0 aGUgY29tcGxldGUgb2JqZWN0LiAgRXhhbXBsZTogUGxhaW4NCiAgICAgIHRleHQgZG9jdW1lbnRz Lg0KDQogICBvICBGb3IgYW4gYWdncmVnYXRpb24gb2YgaW5mb3JtYXRpb24gb2JqZWN0cywgdGhl IGFzc29jaWF0ZWQgbGFuZ3VhZ2UNCiAgICAgIHRhZ3MgY291bGQgYmUgdGFrZW4gYXMgdGhlIHNl dCBvZiBsYW5ndWFnZXMgdXNlZCBpbnNpZGUgY29tcG9uZW50cw0KICAgICAgb2YgdGhhdCBhZ2dy ZWdhdGlvbi4gIEV4YW1wbGVzOiBEb2N1bWVudCBzdG9yZXMgYW5kIGxpYnJhcmllcy4NCg0KICAg byAgRm9yIGluZm9ybWF0aW9uIG9iamVjdHMgd2hvc2UgcHVycG9zZSBpcyB0byBwcm92aWRlIGFs dGVybmF0aXZlcywNCiAgICAgIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MgY291bGQgYmUg cmVnYXJkZWQgYXMgYSBoaW50IHRoYXQgdGhlDQogICAgICBjb250ZW50IGlzIHByb3ZpZGVkIGlu IHNldmVyYWwgbGFuZ3VhZ2VzLCBhbmQgdGhhdCBvbmUgaGFzIHRvDQogICAgICBpbnNwZWN0IGVh Y2ggb2YgdGhlIGFsdGVybmF0aXZlcyBpbiBvcmRlciB0byBmaW5kIGl0cyBsYW5ndWFnZSBvcg0K ICAgICAgbGFuZ3VhZ2VzLiAgSW4gdGhpcyBjYXNlLCB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUg dGFncyBtaWdodCBub3QNCiAgICAgIG1lYW4gdGhhdCBvbmUgbmVlZHMgdG8gYmUgbXVsdGktbGlu Z3VhbCB0byBnZXQgY29tcGxldGUNCiAgICAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRvY3VtZW50 LiAgRXhhbXBsZTogTUlNRSBtdWx0aXBhcnQvDQogICAgICBhbHRlcm5hdGl2ZS4NCg0KICAgbyAg SW4gbWFya3VwIGxhbmd1YWdlcywgc3VjaCBhcyBIVE1MIGFuZCBYTUwsIGxhbmd1YWdlIGluZm9y bWF0aW9uDQogICAgICBjYW4gYmUgYWRkZWQgdG8gZWFjaCBwYXJ0IG9mIHRoZSBkb2N1bWVudCBp ZGVudGlmaWVkIGJ5IHRoZSBtYXJrdXANCiAgICAgIHN0cnVjdHVyZSAoaW5jbHVkaW5nIHRoZSB3 aG9sZSBkb2N1bWVudCBpdHNlbGYpLiAgRm9yIGV4YW1wbGUsIG9uZQ0KICAgICAgY291bGQgd3Jp dGUgPHNwYW4gbGFuZz0iZnIiPkMnZXN0IGxhIHZpZS48L3NwYW4+IGluc2lkZSBhDQogICAgICBO b3J3ZWdpYW4gZG9jdW1lbnQ7IHRoZSBOb3J3ZWdpYW4tc3BlYWtpbmcgdXNlciBjb3VsZCB0aGVu IGFjY2Vzcw0KICAgICAgYSBGcmVuY2gtTm9yd2VnaWFuIGRpY3Rpb25hcnkgdG8gZmluZCBvdXQg d2hhdCB0aGUgbWFya2VkIHNlY3Rpb24NCiAgICAgIG1lYW50LiAgSWYgdGhlIHVzZXIgd2VyZSBs aXN0ZW5pbmcgdG8gdGhhdCBkb2N1bWVudCB0aHJvdWdoIGENCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDM5 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgc3BlZWNoIHN5bnRoZXNpcyBpbnRlcmZh Y2UsIHRoaXMgZm9ybWF0aW9uIGNvdWxkIGJlIHVzZWQgdG8gc2lnbmFsDQogICAgICB0aGUgc3lu dGhlc2l6ZXIgdG8gYXBwcm9wcmlhdGVseSBhcHBseSBGcmVuY2ggdGV4dC10by1zcGVlY2gNCiAg ICAgIHByb251bmNpYXRpb24gcnVsZXMgdG8gdGhhdCBzcGFuIG9mIHRleHQsIGluc3RlYWQgb2Yg YXBwbHlpbmcgdGhlDQogICAgICBpbmFwcHJvcHJpYXRlIE5vcndlZ2lhbiBydWxlcy4NCg0KICAg TGFuZ3VhZ2UgdGFncyBhcmUgcmVsYXRlZCB3aGVuIHRoZXkgY29udGFpbiBhIHNpbWlsYXIgc2Vx dWVuY2Ugb2YNCiAgIHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwgaWYgYSBsYW5ndWFnZSB0YWcgQiBj b250YWlucyBsYW5ndWFnZSB0YWcgQSBhcw0KICAgYSBwcmVmaXgsIHRoZW4gQiBpcyB0eXBpY2Fs bHkgIm5hcnJvd2VyIiBvciAibW9yZSBzcGVjaWZpYyIgdGhhbiBBLg0KICAgVGh1cyAiemgtSGFu dC1UVyIgaXMgbW9yZSBzcGVjaWZpYyB0aGFuICJ6aC1IYW50Ii4NCg0KICAgVGhpcyByZWxhdGlv bnNoaXAgaXMgbm90IGd1YXJhbnRlZWQgaW4gYWxsIGNhc2VzOiBzcGVjaWZpY2FsbHksDQogICBs YW5ndWFnZXMgdGhhdCBiZWdpbiB3aXRoIHRoZSBzYW1lIHNlcXVlbmNlIG9mIHN1YnRhZ3MgYXJl IE5PVA0KICAgZ3VhcmFudGVlZCB0byBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUsIGFsdGhvdWdo IHRoZXkgbWlnaHQgYmUuICBGb3INCiAgIGV4YW1wbGUsIHRoZSB0YWcgImF6IiBzaGFyZXMgYSBw cmVmaXggd2l0aCBib3RoICJhei1MYXRuIg0KICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4gdXNpbmcg dGhlIExhdGluIHNjcmlwdCkgYW5kICJhei1DeXJsIg0KICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4g dXNpbmcgdGhlIEN5cmlsbGljIHNjcmlwdCkuICBBIHBlcnNvbiBmbHVlbnQgaW4NCiAgIG9uZSBz Y3JpcHQgbWlnaHQgbm90IGJlIGFibGUgdG8gcmVhZCB0aGUgb3RoZXIsIGV2ZW4gdGhvdWdoIHRo ZSB0ZXh0DQogICBtaWdodCBiZSBpZGVudGljYWwuICBDb250ZW50IHRhZ2dlZCBhcyAiYXoiIG1v c3QgcHJvYmFibHkgaXMgd3JpdHRlbg0KICAgaW4ganVzdCBvbmUgc2NyaXB0IGFuZCB0aHVzIG1p Z2h0IG5vdCBiZSBpbnRlbGxpZ2libGUgdG8gYSByZWFkZXINCiAgIGZhbWlsaWFyIHdpdGggdGhl IG90aGVyIHNjcmlwdC4NCg0KNC4zICBMZW5ndGggQ29uc2lkZXJhdGlvbnMNCg0KICAgW1JGQzMw NjZdIGRpZCBub3QgcHJvdmlkZSBhbiB1cHBlciBsaW1pdCBvbiB0aGUgc2l6ZSBvZiBsYW5ndWFn ZQ0KICAgdGFncy4gIFdoaWxlIFJGQyAzMDY2IGRpZCBkZWZpbmUgdGhlIHNlbWFudGljcyBvZiBw YXJ0aWN1bGFyIHN1YnRhZ3MNCiAgIGluIHN1Y2ggYSB3YXkgdGhhdCBtb3N0IGxhbmd1YWdlIHRh Z3MgY29uc2lzdGVkIG9mIGxhbmd1YWdlIGFuZA0KICAgcmVnaW9uIHN1YnRhZ3Mgd2l0aCBhIGNv bWJpbmVkIHRvdGFsIGxlbmd0aCBvZiB1cCB0byBzaXggY2hhcmFjdGVycywNCiAgIGxhcmdlciBy ZWdpc3RlcmVkIHRhZ3Mgd2VyZSBub3Qgb25seSBwb3NzaWJsZSBidXQgd2VyZSBhY3R1YWxseQ0K ICAgcmVnaXN0ZXJlZC4NCg0KICAgTmVpdGhlciB0aGUgbGFuZ3VhZ2UgdGFnIHN5bnRheCBub3Ig b3RoZXIgcmVxdWlyZW1lbnRzIGluIHRoaXMNCiAgIGRvY3VtZW50ICBpbXBvc2UgYSBmaXhlZCB1 cHBlciBsaW1pdCBvbiB0aGUgbnVtYmVyIG9mIHN1YnRhZ3MgaW4gYQ0KICAgbGFuZ3VhZ2UgdGFn IChhbmQgdGh1cyBhbiB1cHBlciBib3VuZCBvbiB0aGUgc2l6ZSBvZiBhIHRhZykuICBUaGUNCiAg IGxhbmd1YWdlIHRhZyBzeW50YXggc3VnZ2VzdHMgdGhhdCwgZGVwZW5kaW5nIG9uIHRoZSBzcGVj aWZpYw0KICAgbGFuZ3VhZ2UsIG1vcmUgc3VidGFncyAoYW5kIHRodXMgYSBsb25nZXIgdGFnKSBh cmUgc29tZXRpbWVzDQogICBuZWNlc3NhcnkgdG8gY29tcGxldGVseSBpZGVudGlmeSB0aGUgbGFu Z3VhZ2UgZm9yIGNlcnRhaW4NCiAgIGFwcGxpY2F0aW9uczsgdGh1cyBpdCBpcyBwb3NzaWJsZSB0 byBlbnZpc2lvbiBsb25nIG9yIGNvbXBsZXggc3VidGFnDQogICBzZXF1ZW5jZXMuDQoNCjQuMy4x ICBXb3JraW5nIHdpdGggTGltaXRlZCBCdWZmZXIgU2l6ZXMNCg0KICAgU29tZSBhcHBsaWNhdGlv bnMgYW5kIHByb3RvY29scyBhcmUgZm9yY2VkIHRvIGFsbG9jYXRlIGZpeGVkIGJ1ZmZlcg0KICAg c2l6ZXMgb3Igb3RoZXJ3aXNlIGxpbWl0IHRoZSBsZW5ndGggb2YgYSBsYW5ndWFnZSB0YWcuICBB IGNvbmZvcm1hbnQNCiAgIGltcGxlbWVudGF0aW9uIG9yIHNwZWNpZmljYXRpb24gTUFZIHJlZnVz ZSB0byBzdXBwb3J0IHRoZSBzdG9yYWdlIG9mDQogICBsYW5ndWFnZSB0YWdzIHdoaWNoIGV4Y2Vl ZCBhIHNwZWNpZmllZCBsZW5ndGguICBBbnkgc3VjaCBsaW1pdGF0aW9uDQogICBTSE9VTEQgYmUg Y2xlYXJseSBkb2N1bWVudGVkLCBhbmQgc3VjaCBkb2N1bWVudGF0aW9uIFNIT1VMRCBpbmNsdWRl DQogICB3aGF0IGhhcHBlbnMgdG8gbG9uZ2VyIHRhZ3MgKGZvciBleGFtcGxlLCB3aGV0aGVyIGFu IGVycm9yIHZhbHVlIGlzDQogICBnZW5lcmF0ZWQgb3IgdGhlIGxhbmd1YWdlIHRhZyBpcyB0cnVu Y2F0ZWQpLiAgQSBwcm90b2NvbCB0aGF0IGFsbG93cw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgNDBdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgQXVndXN0IDIwMDUNCg0KDQogICB0YWdzIHRvIGJlIHRydW5jYXRlZCBhdCBhbiBhcmJp dHJhcnkgbGltaXQsIHdpdGhvdXQgZ2l2aW5nIGFueQ0KICAgaW5kaWNhdGlvbiBvZiB3aGF0IHRo YXQgbGltaXQgaXMsIGhhcyB0aGUgcG90ZW50aWFsIGZvciBjYXVzaW5nIGhhcm0NCiAgIGJ5IGNo YW5naW5nIHRoZSBtZWFuaW5nIG9mIHRhZ3MgaW4gc3Vic3RhbnRpYWwgd2F5cy4NCg0KICAgSW4g cHJhY3RpY2UsIG1vc3QgbGFuZ3VhZ2UgdGFncyBkbyBub3QgcmVxdWlyZSBtb3JlIHRoYW4gYSBm ZXcNCiAgIHN1YnRhZ3MgYW5kIHdpbGwgbm90IGFwcHJvYWNoIHJlYXNvbmFibHkgc2l6ZWQgYnVm ZmVyIGxpbWl0YXRpb25zOg0KICAgc2VlIFNlY3Rpb24gNC4xLg0KDQogICBTb21lIHNwZWNpZmlj YXRpb25zIG9yIHByb3RvY29scyBoYXZlIGxpbWl0cyBvbiB0YWcgbGVuZ3RoIGJ1dCBkbyBub3QN CiAgIGhhdmUgYSBmaXhlZCBsZW5ndGggbGltaXRhdGlvbi4gIEZvciBleGFtcGxlLCBbUkZDMjIz MV0gIGhhcyBubw0KICAgZXhwbGljaXQgbGVuZ3RoIGxpbWl0YXRpb246IHRoZSBsZW5ndGggYXZh aWxhYmxlIGZvciB0aGUgbGFuZ3VhZ2UgdGFnDQogICBpcyBjb25zdHJhaW5lZCBieSB0aGUgbGVu Z3RoIG9mIG90aGVyIGhlYWRlciBjb21wb25lbnRzIChzdWNoIGFzIHRoZQ0KICAgY2hhcnNldCdz IG5hbWUpIGNvdXBsZWQgd2l0aCB0aGUgNzYgY2hhcmFjdGVyIGxpbWl0IGluIFtSRkMyMDQ3XS4N CiAgIFRodXMgdGhlICJsaW1pdCIgbWlnaHQgYmUgNTAgb3IgbW9yZSBjaGFyYWN0ZXJzLCBidXQg aXQgY291bGQNCiAgIHBvdGVudGlhbGx5IGJlIHF1aXRlIHNtYWxsLg0KDQogICBUaGUgY29uc2lk ZXJhdGlvbnMgZm9yIGFzc2lnbmluZyBhIGJ1ZmZlciBsaW1pdCBhcmU6DQoNCiAgICAgIEltcGxl bWVudGF0aW9ucyBTSE9VTEQgTk9UIHRydW5jYXRlIGxhbmd1YWdlIHRhZ3MgdW5sZXNzIHRoZQ0K ICAgICAgbWVhbmluZyBvZiB0aGUgdGFnIGlzIHB1cnBvc2VmdWxseSBiZWluZyBjaGFuZ2VkLCBv ciB1bmxlc3MgdGhlDQogICAgICB0YWcgZG9lcyBub3QgZml0IGludG8gYSBsaW1pdGVkIGJ1ZmZl ciBzaXplIHNwZWNpZmllZCBieSBhDQogICAgICBwcm90b2NvbCBmb3Igc3RvcmFnZSBvciB0cmFu c21pc3Npb24uDQoNCiAgICAgIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgd2FybiB0aGUgdXNlciB3 aGVuIGEgdGFnIGlzIHRydW5jYXRlZCBzaW5jZQ0KICAgICAgdHJ1bmNhdGlvbiBjaGFuZ2VzIHRo ZSBzZW1hbnRpYyBtZWFuaW5nIG9mIHRoZSB0YWcuDQoNCiAgICAgIEltcGxlbWVudGF0aW9ucyBv ZiBwcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBhcmUgc3BhY2UNCiAgICAgIGNvbnN0 cmFpbmVkIGJ1dCBkbyBub3QgaGF2ZSBhIGZpeGVkIGxpbWl0IFNIT1VMRCB1c2UgdGhlIGxvbmdl c3QNCiAgICAgIHBvc3NpYmxlIHRhZyBpbiBwcmVmZXJlbmNlIHRvIHRydW5jYXRpb24uDQoNCiAg ICAgIFByb3RvY29scyBvciBzcGVjaWZpY2F0aW9ucyB0aGF0IHNwZWNpZnkgbGltaXRlZCBidWZm ZXIgc2l6ZXMgZm9yDQogICAgICBsYW5ndWFnZSB0YWdzIE1VU1QgYWxsb3cgZm9yIGxhbmd1YWdl IHRhZ3Mgb2YgdXAgdG8gMzMgY2hhcmFjdGVycy4NCg0KICAgICAgUHJvdG9jb2xzIG9yIHNwZWNp ZmljYXRpb25zIHRoYXQgc3BlY2lmeSBsaW1pdGVkIGJ1ZmZlciBzaXplcyBmb3INCiAgICAgIGxh bmd1YWdlIHRhZ3MgU0hPVUxEIGFsbG93IGZvciBsYW5ndWFnZSB0YWdzIG9mIGF0IGxlYXN0IDQy DQogICAgICBjaGFyYWN0ZXJzLg0KDQogICBUaGUgZm9sbG93aW5nIGlsbHVzdHJhdGlvbiBzaG93 cyBob3cgdGhlIDQyLWNoYXJhY3RlciByZWNvbW1lbmRhdGlvbg0KICAgd2FzIGRlcml2ZWQuICBU aGUgY29tYmluYXRpb24gb2YgbGFuZ3VhZ2UgYW5kIGV4dGVuZGVkIGxhbmd1YWdlDQogICBzdWJ0 YWdzIHdhcyBjaG9zZW4gZm9yIGZ1dHVyZSBjb21wYXRpYmlsaXR5LiAgQXQgdXAgdG8gMTUgY2hh cmFjdGVycywNCiAgIHRoaXMgY29tYmluYXRpb24gaXMgbG9uZ2VyIHRoYW4gdGhlIGxvbmdlc3Qg cG9zc2libGUgcHJpbWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnICg4IGNoYXJhY3RlcnMpOg0KDQoN Cg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAx NiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgNDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQog ICBsYW5ndWFnZSAgICAgID0gIDMgKElTTyA2MzktMjsgSVNPIDYzOS0xIHJlcXVpcmVzIDIpDQog ICBleHRsYW5nMSAgICAgID0gIDQgKGVhY2ggc3Vic2VxdWVudCBzdWJ0YWcgaW5jbHVkZXMgJy0n KQ0KICAgZXh0bGFuZzIgICAgICA9ICA0ICh1bmxpa2VseTogbmVlZHMgcHJlZml4PSJsYW5ndWFn ZS1leHRsYW5nMSIpDQogICBleHRsYW5nMyAgICAgID0gIDQgKGV4dHJlbWVseSB1bmxpa2VseSkN CiAgIHNjcmlwdCAgICAgICAgPSAgNSAoaWYgbm90IHN1cHByZXNzZWQ6IHNlZSBTZWN0aW9uIDQu MSkNCiAgIHJlZ2lvbiAgICAgICAgPSAgNCAoVU4gTS40OTsgSVNPIDMxNjYgcmVxdWlyZXMgMykN CiAgIHZhcmlhbnQxICAgICAgPSAgOSAoTVVTVCBoYXZlIGxhbmd1YWdlIGFzIGEgcHJlZml4KQ0K ICAgdmFyaWFudDIgICAgICA9ICA5IChNVVNUIGhhdmUgbGFuZ3VhZ2UtdmFyaWFudDEgYXMgYSBw cmVmaXgpDQoNCiAgIHRvdGFsICAgICAgICAgPSA0MiBjaGFyYWN0ZXJzDQoNCiAgICAgICAgICAg ICAgRmlndXJlIDc6IERlcml2YXRpb24gb2YgdGhlIExpbWl0IG9uIFRhZyBMZW5ndGgNCg0KDQo0 LjMuMiAgVHJ1bmNhdGlvbiBvZiBMYW5ndWFnZSBUYWdzDQoNCiAgIFRydW5jYXRpb24gb2YgYSBs YW5ndWFnZSB0YWcgYWx0ZXJzIHRoZSBtZWFuaW5nIG9mIHRoZSB0YWcsIGFuZCB0aHVzDQogICBT SE9VTEQgYmUgYXZvaWRlZC4gIEhvd2V2ZXIsIHRydW5jYXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBp cyBzb21ldGltZXMNCiAgIG5lY2Vzc2FyeSBkdWUgdG8gbGltaXRlZCBidWZmZXIgc2l6ZXMuICBT dWNoIHRydW5jYXRpb24gTVVTVCBOT1QNCiAgIHBlcm1pdCBhIHN1YnRhZyB0byBiZSBjaG9wcGVk IG9mZiBpbiB0aGUgbWlkZGxlIG9yIHRoZSBmb3JtYXRpb24gb2YNCiAgIGludmFsaWQgdGFncyAo Zm9yIGV4YW1wbGUsIG9uZSBlbmRpbmcgd2l0aCB0aGUgIi0iIGNoYXJhY3RlcikuDQoNCiAgIFRo aXMgbWVhbnMgdGhhdCBhcHBsaWNhdGlvbnMgb3IgcHJvdG9jb2xzIHdoaWNoIHRydW5jYXRlIHRh Z3MgTVVTVCBkbw0KICAgc28gYnkgcHJvZ3Jlc3NpdmVseSByZW1vdmluZyBzdWJ0YWdzIGFsb25n IHdpdGggdGhlaXIgcHJlY2VkaW5nICItIg0KICAgZnJvbSB0aGUgcmlnaHQgc2lkZSBvZiB0aGUg bGFuZ3VhZ2UgdGFnIHVudGlsIHRoZSB0YWcgaXMgc2hvcnQgZW5vdWdoDQogICBmb3IgdGhlIGdp dmVuIGJ1ZmZlci4gIElmIHRoZSByZXN1bHRpbmcgdGFnIGVuZHMgd2l0aCBhIHNpbmdsZS0NCiAg IGNoYXJhY3RlciBzdWJ0YWcsIHRoYXQgc3VidGFnIGFuZCBpdHMgcHJlY2VkaW5nICItIiBNVVNU IGFsc28gYmUNCiAgIHJlbW92ZWQuICBGb3IgZXhhbXBsZToNCg0KICAgVGFnIHRvIHRydW5jYXRl OiB6aC1IYW50LUNOLXZhcmlhbnQxLWEtZXh0ZW5kMS14LXdhZGVnaWxlLXByaXZhdGUxDQogICAx LiB6aC1MYXRuLUNOLXZhcmlhbnQxLWEtZXh0ZW5kMS14LXdhZGVnaWxlDQogICAyLiB6aC1MYXRu LUNOLXZhcmlhbnQxLWEtZXh0ZW5kMQ0KICAgMy4gemgtTGF0bi1DTi12YXJpYW50MQ0KICAgNC4g emgtTGF0bi1DTg0KICAgNS4gemgtTGF0bg0KICAgNi4gemgNCg0KICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgODogRXhhbXBsZSBvZiBUYWcgVHJ1bmNhdGlvbg0KDQoNCjQuNCAgQ2Fub25pY2Fs aXphdGlvbiBvZiBMYW5ndWFnZSBUYWdzDQoNCiAgIFNpbmNlIGEgcGFydGljdWxhciBsYW5ndWFn ZSB0YWcgaXMgc29tZXRpbWVzIHVzZWQgYnkgbWFueSBwcm9jZXNzZXMsDQogICBsYW5ndWFnZSB0 YWdzIFNIT1VMRCBhbHdheXMgYmUgY3JlYXRlZCBvciBnZW5lcmF0ZWQgaW4gYSBjYW5vbmljYWwN CiAgIGZvcm0uDQoNCiAgIEEgbGFuZ3VhZ2UgdGFnIGlzIGluIGNhbm9uaWNhbCBmb3JtIHdoZW46 DQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIw MDYgICAgICAgICAgICAgIFtQYWdlIDQyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgMS4g IFRoZSB0YWcgaXMgd2VsbC1mb3JtZWQgYWNjb3JkaW5nIHRoZSBydWxlcyBpbiBTZWN0aW9uIDIu MSBhbmQNCiAgICAgICBTZWN0aW9uIDIuMi4NCg0KICAgMi4gIFN1YnRhZ3Mgb2YgdHlwZSAnUmVn aW9uJyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUgbWFwcGluZyBpbg0KICAgICAgIHRoZSBJ QU5BIHJlZ2lzdHJ5IChzZWUgU2VjdGlvbiAzLjEpIFNIT1VMRCBiZSByZXBsYWNlZCB3aXRoIHRo ZWlyDQogICAgICAgbWFwcGVkIHZhbHVlLiAgTm90ZTogSW4gcmFyZSBjYXNlcyB0aGUgbWFwcGVk IHZhbHVlIHdpbGwgYWxzbw0KICAgICAgIGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUuDQoNCiAgIDMu ICBSZWR1bmRhbnQgb3IgZ3JhbmRmYXRoZXJlZCB0YWdzIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1W YWx1ZQ0KICAgICAgIG1hcHBpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMu MSkgTVVTVCBiZSByZXBsYWNlZA0KICAgICAgIHdpdGggdGhlaXIgbWFwcGVkIHZhbHVlLiAgVGhl c2UgaXRlbXMgYXJlIGVpdGhlciBkZXByZWNhdGVkDQogICAgICAgbWFwcGluZ3MgY3JlYXRlZCBi ZWZvcmUgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKHN1Y2ggYXMNCiAgICAgICB0aGUg bWFwcGluZyBvZiAibm8tbnluIiB0byAibm4iIG9yICJpLWtsaW5nb24iIHRvICJ0bGgiKSBvciBh cmUNCiAgICAgICB0aGUgcmVzdWx0IG9mIGxhdGVyIHJlZ2lzdHJhdGlvbnMgb3IgYWRkaXRpb25z IHRvIHRoaXMgZG9jdW1lbnQNCiAgICAgICAoZm9yIGV4YW1wbGUsICJ6aC1ndW95dSIgbWlnaHQg YmUgbWFwcGVkIHRvIGEgbGFuZ3VhZ2UtZXh0bGFuZw0KICAgICAgIGNvbWJpbmF0aW9uIHN1Y2gg YXMgInpoLWNtbiIgYnkgc29tZSBmdXR1cmUgdXBkYXRlIG9mIHRoaXMNCiAgICAgICBkb2N1bWVu dCkuDQoNCiAgIDQuICBPdGhlciBzdWJ0YWdzIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1ZSBt YXBwaW5nIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMuMSkgTVVT VCBiZSByZXBsYWNlZCB3aXRoIHRoZWlyIG1hcHBlZA0KICAgICAgIHZhbHVlLiAgVGhlc2UgaXRl bXMgY29uc2lzdCBlbnRpcmVseSBvZiBjbGVyaWNhbCBjb3JyZWN0aW9ucyB0bw0KICAgICAgIElT TyA2MzktMSBpbiB3aGljaCB0aGUgZGVwcmVjYXRlZCBzdWJ0YWdzIGhhdmUgYmVlbiBtYWludGFp bmVkDQogICAgICAgZm9yIGNvbXBhdGliaWxpdHkgcHVycG9zZXMuDQoNCiAgIDUuICBJZiBtb3Jl IHRoYW4gb25lIGV4dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2UgZXhpc3RzLCB0aGUgZXh0ZW5zaW9u DQogICAgICAgc2VxdWVuY2VzIGFyZSBvcmRlcmVkIGludG8gY2FzZS1pbnNlbnNpdGl2ZSBBU0NJ SSBvcmRlciBieQ0KICAgICAgIHNpbmdsZXRvbiBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6IFRoZSBs YW5ndWFnZSB0YWcgImVuLUEtYWFhLUItY2NjLWJiYi14LXh5eiIgaXMgaW4gY2Fub25pY2FsDQog ICBmb3JtLCB3aGlsZSAiZW4tQi1jY2MtYmJiLUEtYWFhLVgteHl6IiBpcyB3ZWxsLWZvcm1lZCBi dXQgbm90IGluDQogICBjYW5vbmljYWwgZm9ybS4NCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdl IHRhZyAiZW4tQlUiIChFbmdsaXNoIGFzIHVzZWQgaW4gQnVybWEpIGlzIG5vdA0KICAgY2Fub25p Y2FsIGJlY2F1c2UgdGhlICdCVScgc3VidGFnIGhhcyBhIGNhbm9uaWNhbCBtYXBwaW5nIHRvICdN TScNCiAgIChNeWFubWFyKSwgYWx0aG91Z2ggdGhlIHRhZyAiZW4tQlUiIG1haW50YWlucyBpdHMg dmFsaWRpdHkuDQoNCiAgIENhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBkb2VzIG5v dCBpbXBseSBhbnl0aGluZyBhYm91dCB0aGUNCiAgIHVzZSBvZiB1cHBlciBvciBsb3dlcmNhc2Ug bGV0dGVycyB3aGVuIHByb2Nlc3Npbmcgb3IgY29tcGFyaW5nDQogICBzdWJ0YWdzIChhbmQgYXMg ZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xKS4gIEFsbCBjb21wYXJpc29ucyBNVVNUIGJlDQogICBw ZXJmb3JtZWQgaW4gYSBjYXNlLWluc2Vuc2l0aXZlIG1hbm5lci4NCg0KICAgV2hlbiBwZXJmb3Jt aW5nIGNhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncywgcHJvY2Vzc29ycyBNQVkNCiAg IHJlZ3VsYXJpemUgdGhlIGNhc2Ugb2YgdGhlIHN1YnRhZ3MgKHRoYXQgaXMsIHRoaXMgcHJvY2Vz cyBpcw0KICAgT1BUSU9OQUwpLCBmb2xsb3dpbmcgdGhlIGNhc2UgdXNlZCBpbiB0aGUgcmVnaXN0 cnkuICBOb3RlIHRoYXQgdGhpcw0KICAgY29ycmVzcG9uZHMgdG8gdGhlIGZvbGxvd2luZyBjYXNp bmcgcnVsZXM6IHVwcGVyY2FzZSBhbGwgbm9uLWluaXRpYWwNCiAgIHR3by1sZXR0ZXIgc3VidGFn czsgdGl0bGVjYXNlIGFsbCBub24taW5pdGlhbCBmb3VyLWxldHRlciBzdWJ0YWdzOw0KICAgbG93 ZXJjYXNlIGV2ZXJ5dGhpbmcgZWxzZS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgNDNdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg QXVndXN0IDIwMDUNCg0KDQogICBOb3RlOiBDYXNlIGZvbGRpbmcgb2YgQVNDSUkgbGV0dGVycyBp biBjZXJ0YWluIGxvY2FsZXMsIHVubGVzcw0KICAgY2FyZWZ1bGx5IGhhbmRsZWQsIHNvbWV0aW1l cyBwcm9kdWNlcyBub24tQVNDSUkgY2hhcmFjdGVyIHZhbHVlcy4NCiAgIFRoZSBVbmljb2RlIENo YXJhY3RlciBEYXRhYmFzZSBmaWxlICJTcGVjaWFsQ2FzaW5nLnR4dCIgZGVmaW5lcyB0aGUNCiAg IHNwZWNpZmljIGNhc2VzIHRoYXQgYXJlIGtub3duIHRvIGNhdXNlIHByb2JsZW1zIHdpdGggdGhp cy4gIEluDQogICBwYXJ0aWN1bGFyLCB0aGUgbGV0dGVyICdpJyAoVSswMDY5KSBpbiBUdXJraXNo IGFuZCBBemVyYmFpamFuaSBpcw0KICAgdXBwZXJjYXNlZCB0byBVKzAxMzAgKExBVElOIENBUElU QUwgTEVUVEVSIEkgV0lUSCBET1QgQUJPVkUpLg0KICAgSW1wbGVtZW50ZXJzIFNIT1VMRCBzcGVj aWZ5IGEgbG9jYWxlLW5ldXRyYWwgY2FzaW5nIG9wZXJhdGlvbiB0bw0KICAgZW5zdXJlIHRoYXQg Y2FzZSBmb2xkaW5nIG9mIHN1YnRhZ3MgZG9lcyBub3QgcHJvZHVjZSB0aGlzIHZhbHVlLA0KICAg d2hpY2ggaXMgaWxsZWdhbCBpbiBsYW5ndWFnZSB0YWdzLiAgRm9yIGV4YW1wbGUsIGlmIG9uZSB3 ZXJlIHRvDQogICB1cHBlcmNhc2UgdGhlIHJlZ2lvbiBzdWJ0YWcgJ2luJyB1c2luZyBUdXJraXNo IGxvY2FsZSBydWxlcywgdGhlDQogICBzZXF1ZW5jZSBVKzAxMzAgVSswMDRFIHdvdWxkIHJlc3Vs dCBpbnN0ZWFkIG9mIHRoZSBleHBlY3RlZCAnSU4nLg0KDQogICBOb3RlOiBpZiB0aGUgZmllbGQg J0RlcHJlY2F0ZWQnIGFwcGVhcnMgaW4gYSByZWdpc3RyeSByZWNvcmQgd2l0aG91dA0KICAgYW4g YWNjb21wYW55aW5nICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkLCB0aGVuIHRoYXQgdGFnIG9yIHN1 YnRhZyBpcw0KICAgZGVwcmVjYXRlZCB3aXRob3V0IGEgcmVwbGFjZW1lbnQuICBWYWxpZGF0aW5n IHByb2Nlc3NvcnMgU0hPVUxEIE5PVA0KICAgZ2VuZXJhdGUgdGFncyB0aGF0IGluY2x1ZGUgdGhl c2UgdmFsdWVzLCBhbHRob3VnaCB0aGUgdmFsdWVzIGFyZQ0KICAgY2Fub25pY2FsIHdoZW4gdGhl eSBhcHBlYXIgaW4gYSBsYW5ndWFnZSB0YWcuDQoNCiAgIEFuIGV4dGVuc2lvbiBNVVNUIGRlZmlu ZSBhbnkgcmVsYXRpb25zaGlwcyB0aGF0IGV4aXN0IGJldHdlZW4gdGhlDQogICB2YXJpb3VzIHN1 YnRhZ3MgaW4gdGhlIGV4dGVuc2lvbiBhbmQgdGh1cyBNQVkgZGVmaW5lIGFuIGFsdGVybmF0ZQ0K ICAgY2Fub25pY2FsaXphdGlvbiBzY2hlbWUgZm9yIHRoZSBleHRlbnNpb24ncyBzdWJ0YWdzLiAg RXh0ZW5zaW9ucyBNQVkNCiAgIGRlZmluZSBob3cgdGhlIG9yZGVyIG9mIHRoZSBleHRlbnNpb24n cyBzdWJ0YWdzIGFyZSBpbnRlcnByZXRlZC4gIEZvcg0KICAgZXhhbXBsZSwgYW4gZXh0ZW5zaW9u IGNvdWxkIGRlZmluZSB0aGF0IGl0cyBzdWJ0YWdzIGFyZSBpbiBjYW5vbmljYWwNCiAgIG9yZGVy IHdoZW4gdGhlIHN1YnRhZ3MgYXJlIHBsYWNlZCBpbnRvIEFTQ0lJIG9yZGVyOiB0aGF0IGlzLCAi ZW4tYS0NCiAgIGFhYS1iYmItY2NjIiBpbnN0ZWFkIG9mICJlbi1hLWNjYy1iYmItYWFhIi4gIEFu b3RoZXIgZXh0ZW5zaW9uIG1pZ2h0DQogICBkZWZpbmUgdGhhdCB0aGUgb3JkZXIgb2YgdGhlIHN1 YnRhZ3MgaW5mbHVlbmNlcyB0aGVpciBzZW1hbnRpYw0KICAgbWVhbmluZyAoc28gdGhhdCAiZW4t Yi1jY2MtYmJiLWFhYSIgaGFzIGEgZGlmZmVyZW50IHZhbHVlIGZyb20gImVuLWItDQogICBhYWEt YmJiLWNjYyIpLiAgSG93ZXZlciwgZXh0ZW5zaW9uIHNwZWNpZmljYXRpb25zIFNIT1VMRCBiZSBk ZXNpZ25lZA0KICAgc28gdGhhdCB0aGV5IGFyZSB0b2xlcmFudCBvZiB0aGUgdHlwaWNhbCBwcm9j ZXNzZXMgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDMuNi4NCg0KNC41ICBDb25zaWRlcmF0aW9u cyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncw0KDQogICBQcml2YXRlIHVzZSBzdWJ0YWdzLCBsaWtl IGFsbCBvdGhlciBzdWJ0YWdzLCBNVVNUIGNvbmZvcm0gdG8gdGhlDQogICBmb3JtYXQgYW5kIGNv bnRlbnQgY29uc3RyYWludHMgaW4gdGhlIEFCTkYuICBQcml2YXRlIHVzZSBzdWJ0YWdzIGhhdmUN CiAgIG5vIG1lYW5pbmcgb3V0c2lkZSB0aGUgcHJpdmF0ZSBhZ3JlZW1lbnQgYmV0d2VlbiB0aGUg cGFydGllcyB0aGF0DQogICBpbnRlbmQgdG8gdXNlIG9yIGV4Y2hhbmdlIGxhbmd1YWdlIHRhZ3Mg dGhhdCBlbXBsb3kgdGhlbS4gIFRoZSBzYW1lDQogICBzdWJ0YWdzIE1BWSBiZSB1c2VkIHdpdGgg YSBkaWZmZXJlbnQgbWVhbmluZyB1bmRlciBhIHNlcGFyYXRlIHByaXZhdGUNCiAgIGFncmVlbWVu dC4gIFRoZXkgU0hPVUxEIE5PVCBiZSB1c2VkIHdoZXJlIGFsdGVybmF0aXZlcyBleGlzdCBhbmQN CiAgIFNIT1VMRCBOT1QgYmUgdXNlZCBpbiBjb250ZW50IG9yIHByb3RvY29scyBpbnRlbmRlZCBm b3IgZ2VuZXJhbCB1c2UuDQoNCiAgIFByaXZhdGUgdXNlIHN1YnRhZ3MgYXJlIHNpbXBseSB1c2Vs ZXNzIGZvciBpbmZvcm1hdGlvbiBleGNoYW5nZQ0KICAgd2l0aG91dCBwcmlvciBhcnJhbmdlbWVu dC4gIFRoZSB2YWx1ZSBhbmQgc2VtYW50aWMgbWVhbmluZyBvZiBwcml2YXRlDQogICB1c2UgdGFn cyBhbmQgb2YgdGhlIHN1YnRhZ3MgdXNlZCB3aXRoaW4gc3VjaCBhIGxhbmd1YWdlIHRhZyBhcmUg bm90DQogICBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQuDQoNCiAgIFN1YnRhZ3MgZGVmaW5lZCBp biB0aGUgSUFOQSByZWdpc3RyeSBhcyBoYXZpbmcgYSBzcGVjaWZpYyBwcml2YXRlIHVzZQ0KICAg bWVhbmluZyBjb252ZXkgbW9yZSBpbmZvcm1hdGlvbiB0aGF0IGEgcHVyZWx5IHByaXZhdGUgdXNl IHRhZw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwg MjAwNiAgICAgICAgICAgICAgW1BhZ2UgNDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICBw cmVmaXhlZCBieSB0aGUgc2luZ2xldG9uIHN1YnRhZyAneCcuICBGb3IgYXBwbGljYXRpb25zIHRo aXMNCiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gTUFZIGJlIHVzZWZ1bC4NCg0KICAgRm9yIGV4 YW1wbGUsIHRoZSByZWdpb24gc3VidGFncyAnQUEnLCAnWlonIGFuZCBpbiB0aGUgcmFuZ2VzDQog ICAnUU0nLSdRWicgYW5kICdYQSctJ1haJyAoZGVyaXZlZCBmcm9tIElTTyAzMTY2IHByaXZhdGUg dXNlIGNvZGVzKSBNQVkNCiAgIGJlIHVzZWQgdG8gZm9ybSBhIGxhbmd1YWdlIHRhZy4gIEEgdGFn IHN1Y2ggYXMgInpoLUhhbnMtWFEiIGNvbnZleXMgYQ0KICAgZ3JlYXQgZGVhbCBvZiBwdWJsaWMs IGludGVyY2hhbmdlYWJsZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGFuZ3VhZ2UNCiAgIG1hdGVy aWFsICh0aGF0IGl0IGlzIENoaW5lc2UgaW4gdGhlIHNpbXBsaWZpZWQgQ2hpbmVzZSBzY3JpcHQg YW5kIGlzDQogICBzdWl0YWJsZSBmb3Igc29tZSBnZW9ncmFwaGljIHJlZ2lvbiAnWFEnKS4gIFdo aWxlIHRoZSBwcmVjaXNlDQogICBnZW9ncmFwaGljIHJlZ2lvbiBpcyBub3Qga25vd24gb3V0c2lk ZSBvZiBwcml2YXRlIGFncmVlbWVudCwgdGhlIHRhZw0KICAgY29udmV5cyBmYXIgbW9yZSBpbmZv cm1hdGlvbiB0aGFuIGFuIG9wYXF1ZSB0YWcgc3VjaCBhcyAieC1zb21lTGFuZyIsDQogICB3aGlj aCBjb250YWlucyBubyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGFuZ3VhZ2Ugc3VidGFnIG9yIHNj cmlwdA0KICAgc3VidGFnIG91dHNpZGUgb2YgdGhlIHByaXZhdGUgYWdyZWVtZW50Lg0KDQogICBI b3dldmVyLCBpbiBzb21lIGNhc2VzIGNvbnRlbnQgdGFnZ2VkIHdpdGggcHJpdmF0ZSB1c2Ugc3Vi dGFncyBNQVkNCiAgIGludGVyYWN0IHdpdGggb3RoZXIgc3lzdGVtcyBpbiBhIGRpZmZlcmVudCBh bmQgcG9zc2libHkgdW5zdWl0YWJsZQ0KICAgbWFubmVyIGNvbXBhcmVkIHRvIHRhZ3MgdGhhdCB1 c2Ugb3BhcXVlLCBwcml2YXRlbHkgZGVmaW5lZCBzdWJ0YWdzLA0KICAgc28gdGhlIGNob2ljZSBv ZiB0aGUgYmVzdCBhcHByb2FjaCBzb21ldGltZXMgZGVwZW5kcyBvbiB0aGUNCiAgIHBhcnRpY3Vs YXIgZG9tYWluIGluIHF1ZXN0aW9uLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDQ1XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1DQoNCg0KNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBzZWN0aW9u IGRlYWxzIHdpdGggdGhlIHByb2Nlc3NlcyBhbmQgcmVxdWlyZW1lbnRzIG5lY2Vzc2FyeSBmb3IN CiAgIElBTkEgdG8gdW5kZXJ0YWtlIHRvIG1haW50YWluIHRoZSBzdWJ0YWcgYW5kIGV4dGVuc2lv biByZWdpc3RyaWVzIGFzDQogICBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgYW5kIGluIGFjY29y ZGFuY2Ugd2l0aCB0aGUgcmVxdWlyZW1lbnRzIG9mDQogICBbUkZDMjQzNF0uDQoNCiAgIFRoZSBp bXBhY3Qgb24gdGhlIElBTkEgbWFpbnRhaW5lcnMgb2YgdGhlIHR3byByZWdpc3RyaWVzIGRlZmlu ZWQgYnkNCiAgIHRoaXMgZG9jdW1lbnQgd2lsbCBiZSBhIHNtYWxsIGluY3JlYXNlIGluIHRoZSBm cmVxdWVuY3kgb2YgbmV3DQogICBlbnRyaWVzIG9yIHVwZGF0ZXMuDQoNCjUuMSAgTGFuZ3VhZ2Ug U3VidGFnIFJlZ2lzdHJ5DQoNCiAgIFVwb24gYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCwgdGhl IHJlZ2lzdHJ5IHdpbGwgYmUgaW5pdGlhbGl6ZWQgYnkgYQ0KICAgY29tcGFuaW9uIGRvY3VtZW50 OiBbaW5pdGlhbC1yZWdpc3RyeV0uICBUaGUgY3JpdGVyaWEgYW5kIHByb2Nlc3MgZm9yDQogICBz ZWxlY3RpbmcgdGhlIGluaXRpYWwgc2V0IG9mIHJlY29yZHMgaXMgZGVzY3JpYmVkIGluIHRoYXQg ZG9jdW1lbnQuDQogICBUaGUgaW5pdGlhbCBzZXQgb2YgcmVjb3JkcyByZXByZXNlbnRzIG5vIGlt cGFjdCBvbiBJQU5BLCBzaW5jZSB0aGUNCiAgIHdvcmsgdG8gY3JlYXRlIGl0IHdpbGwgYmUgcGVy Zm9ybWVkIGV4dGVybmFsbHkuDQoNCiAgIFRoZSBuZXcgcmVnaXN0cnkgTVVTVCBiZSBsaXN0ZWQg dW5kZXIgIkxhbmd1YWdlIFRhZ3MiIGF0DQogICA8aHR0cDovL3d3dy5pYW5hLm9yZy9udW1iZXJz Lmh0bWw+LCByZXBsYWNpbmcgdGhlIGV4aXN0aW5nDQogICByZWdpc3RyYXRpb25zIGRlZmluZWQg YnkgW1JGQzMwNjZdLiAgVGhlIGV4aXN0aW5nIHNldCBvZiByZWdpc3RyYXRpb24NCiAgIGZvcm1z IGFuZCBSRkMgMzA2NiByZWdpc3RyYXRpb25zIE1VU1QgYmUgcmVsYWJlbGVkIGFzICJMYW5ndWFn ZSBUYWdzDQogICAoT2Jzb2xldGUpIiBhbmQgbWFpbnRhaW5lZCAoYnV0IG5vdCBhZGRlZCB0byBv ciBtb2RpZmllZCkuDQoNCiAgIEZ1dHVyZSB3b3JrIG9uIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVn aXN0cnkgU0hBTEwgYmUgbGltaXRlZCB0bw0KICAgaW5zZXJ0aW5nIG9yIHJlcGxhY2luZyB3aG9s ZSByZWNvcmRzIHByZWZvcm1hdHRlZCBmb3IgSUFOQSBieSB0aGUNCiAgIExhbmd1YWdlIFN1YnRh ZyBSZXZpZXdlciBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIgb2YgdGhpcw0KICAgZG9jdW1l bnQuICBUaGlzIHNpbXBsaWZpZXMgSUFOQSdzIHdvcmsgYnkgbGltaXRpbmcgaXQgdG8gcGxhY2lu ZyB0aGUNCiAgIHRleHQgaW4gdGhlIGFwcHJvcHJpYXRlIGxvY2F0aW9uIGluIHRoZSByZWdpc3Ry eS4NCg0KICAgRWFjaCByZWNvcmQgTVVTVCBiZSBzZW50IHRvIGlhbmFAaWFuYS5vcmcgd2l0aCBh IHN1YmplY3QgbGluZQ0KICAgaW5kaWNhdGluZyB3aGV0aGVyIHRoZSBlbmNsb3NlZCByZWNvcmQg aXMgYW4gaW5zZXJ0aW9uIG9mIGEgbmV3DQogICByZWNvcmQgKGluZGljYXRlZCBieSB0aGUgd29y ZCAiSU5TRVJUIiBpbiB0aGUgc3ViamVjdCBsaW5lKSBvciBhDQogICByZXBsYWNlbWVudCBvZiBh biBleGlzdGluZyByZWNvcmQgKGluZGljYXRlZCBieSB0aGUgd29yZCAiTU9ESUZZIiBpbg0KICAg dGhlIHN1YmplY3QgbGluZSkuICBSZWNvcmRzIE1VU1QgTk9UIGJlIGRlbGV0ZWQgZnJvbSB0aGUg cmVnaXN0cnkuDQogICBJQU5BIE1VU1QgcGxhY2UgYW55IGluc2VydGVkIG9yIG1vZGlmaWVkIHJl Y29yZHMgaW50byB0aGUgYXBwcm9wcmlhdGUNCiAgIHNlY3Rpb24gb2YgdGhlIGxhbmd1YWdlIHN1 YnRhZyByZWdpc3RyeSwgZ3JvdXBpbmcgdGhlIHJlY29yZHMgYnkNCiAgIHRoZWlyICdUeXBlJyBm aWVsZC4gIEluc2VydGVkIHJlY29yZHMgTUFZIGJlIHBsYWNlZCBhbnl3aGVyZSBpbiB0aGUNCiAg IGFwcHJvcHJpYXRlIHNlY3Rpb247IHRoZXJlIGlzIG5vIGd1YXJhbnRlZSBvZiB0aGUgb3JkZXIg b2YgdGhlDQogICByZWNvcmRzIGJleW9uZCBncm91cGluZyB0aGVtIHRvZ2V0aGVyIGJ5ICdUeXBl Jy4gIE1vZGlmaWVkIHJlY29yZHMNCiAgIE1VU1Qgb3ZlcndyaXRlIHRoZSByZWNvcmQgdGhleSBy ZXBsYWNlLg0KDQogICBJbmNsdWRlZCBpbiBhbnkgcmVxdWVzdCB0byBpbnNlcnQgb3IgbW9kaWZ5 IHJlY29yZHMgTVVTVCBiZSBhIG5ldw0KICAgRmlsZS1EYXRlIHJlY29yZC4gIFRoaXMgcmVjb3Jk IE1VU1QgYmUgcGxhY2VkIGZpcnN0IGluIHRoZSByZWdpc3RyeS4NCiAgIEluIHRoZSBldmVudCB0 aGF0IHRoZSBGaWxlLURhdGUgcmVjb3JkIHByZXNlbnQgaW4gdGhlIHJlZ2lzdHJ5IGhhcyBhDQog ICBsYXRlciBkYXRlIHRoZW4gdGhlIHJlY29yZCBiZWluZyBpbnNlcnRlZCBvciBtb2RpZmllZCwg dGhlIGV4aXN0aW5nDQogICByZWNvcmQgTVVTVCBiZSBwcmVzZXJ2ZWQuDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBb UGFnZSA0Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3Ry eSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCjUuMiAgRXh0ZW5zaW9ucyBSZWdpc3Ry eQ0KDQogICBUaGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgcmVnaXN0cnkgd2lsbCBhbHNvIGJl IGdlbmVyYXRlZCBhbmQgc2VudA0KICAgdG8gSUFOQSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAz LjYuICBUaGlzIHJlZ2lzdHJ5IGNhbiBjb250YWluIGF0DQogICBtb3N0IDM1IHJlY29yZHMgYW5k IHRodXMgY2hhbmdlcyB0byB0aGlzIHJlZ2lzdHJ5IGFyZSBleHBlY3RlZCB0byBiZQ0KICAgdmVy eSBpbmZyZXF1ZW50Lg0KDQogICBGdXR1cmUgd29yayBieSBJQU5BIG9uIHRoZSBMYW5ndWFnZSBU YWcgRXh0ZW5zaW9ucyBSZWdpc3RyeSBpcw0KICAgbGltaXRlZCB0byB0d28gY2FzZXMuICBGaXJz dCwgdGhlIElFU0cgTUFZIHJlcXVlc3QgdGhhdCBuZXcgcmVjb3Jkcw0KICAgYmUgaW5zZXJ0ZWQg aW50byB0aGlzIHJlZ2lzdHJ5IGZyb20gdGltZSB0byB0aW1lLiAgVGhlc2UgcmVxdWVzdHMNCiAg IE1VU1QgaW5jbHVkZSB0aGUgcmVjb3JkIHRvIGluc2VydCBpbiB0aGUgZXhhY3QgZm9ybWF0IGRl c2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjYuICBJbiBhZGRpdGlvbiwgdGhlcmUgTUFZIGJlIG9j Y2FzaW9uYWwgcmVxdWVzdHMgZnJvbSB0aGUNCiAgIG1haW50YWluaW5nIGF1dGhvcml0eSBmb3Ig YSBzcGVjaWZpYyBleHRlbnNpb24gdG8gdXBkYXRlIHRoZSBjb250YWN0DQogICBpbmZvcm1hdGlv biBvciBVUkxzIGluIHRoZSByZWNvcmQuICBUaGVzZSByZXF1ZXN0cyBNVVNUIGluY2x1ZGUgdGhl DQogICBjb21wbGV0ZSwgdXBkYXRlZCByZWNvcmQuICBJQU5BIGlzIG5vdCByZXNwb25zaWJsZSBm b3IgdmFsaWRhdGluZyB0aGUNCiAgIGluZm9ybWF0aW9uIHByb3ZpZGVkLCBvbmx5IHRoYXQgaXQg aXMgcHJvcGVybHkgZm9ybWF0dGVkLiAgSXQgc2hvdWxkDQogICByZWFzb25hYmx5IGJlIHNlZW4g dG8gY29tZSBmcm9tIHRoZSBtYWludGFpbmluZyBhdXRob3JpdHkgbmFtZWQgaW4NCiAgIHRoZSBy ZWNvcmQgcHJlc2VudCBpbiB0aGUgcmVnaXN0cnkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA0N10N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQog ICBMYW5ndWFnZSB0YWdzIHVzZWQgaW4gY29udGVudCBuZWdvdGlhdGlvbiwgbGlrZSBhbnkgb3Ro ZXIgaW5mb3JtYXRpb24NCiAgIGV4Y2hhbmdlZCBvbiB0aGUgSW50ZXJuZXQsIG1pZ2h0IGJlIGEg c291cmNlIG9mIGNvbmNlcm4gYmVjYXVzZSB0aGV5DQogICBtaWdodCBiZSB1c2VkIHRvIGluZmVy IHRoZSBuYXRpb25hbGl0eSBvZiB0aGUgc2VuZGVyLCBhbmQgdGh1cw0KICAgaWRlbnRpZnkgcG90 ZW50aWFsIHRhcmdldHMgZm9yIHN1cnZlaWxsYW5jZS4NCg0KICAgVGhpcyBpcyBhIHNwZWNpYWwg Y2FzZSBvZiB0aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcgc2VudCBpcw0KICAgdmlz aWJsZSB0byB0aGUgcmVjZWl2aW5nIHBhcnR5IGFuZCBwb3NzaWJseSB0byB0aGlyZCBwYXJ0aWVz IGFzIHdlbGwuDQogICBJdCBpcyB1c2VmdWwgdG8gYmUgYXdhcmUgdGhhdCBzdWNoIGNvbmNlcm5z IGNhbiBleGlzdCBpbiBzb21lIGNhc2VzLg0KDQogICBUaGUgZXZhbHVhdGlvbiBvZiB0aGUgZXhh Y3QgbWFnbml0dWRlIG9mIHRoZSB0aHJlYXQsIGFuZCBhbnkgcG9zc2libGUNCiAgIGNvdW50ZXJt ZWFzdXJlcywgaXMgbGVmdCB0byBlYWNoIGFwcGxpY2F0aW9uIHByb3RvY29sIChzZWUgQkNQIDcy DQogICBbUkZDMzU1Ml0gZm9yIGJlc3QgY3VycmVudCBwcmFjdGljZSBndWlkYW5jZSBvbiBzZWN1 cml0eSB0aHJlYXRzIGFuZA0KICAgZGVmZW5zZXMpLg0KDQogICBUaGUgbGFuZ3VhZ2UgdGFnIGFz c29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgaW5mb3JtYXRpb24gaXRlbSBpcyBvZg0KICAgbm8g Y29uc2VxdWVuY2Ugd2hhdHNvZXZlciBpbiBkZXRlcm1pbmluZyB3aGV0aGVyIHRoYXQgY29udGVu dCBtaWdodA0KICAgY29udGFpbiBwb3NzaWJsZSBob21vZ3JhcGhzLiAgVGhlIGZhY3QgdGhhdCBh IHRleHQgaXMgdGFnZ2VkIGFzIGJlaW5nDQogICBpbiBvbmUgbGFuZ3VhZ2Ugb3IgdXNpbmcgYSBw YXJ0aWN1bGFyIHNjcmlwdCBzdWJ0YWcgcHJvdmlkZXMgbm8NCiAgIGFzc3VyYW5jZSB3aGF0c29l dmVyIHRoYXQgaXQgZG9lcyBub3QgY29udGFpbiBjaGFyYWN0ZXJzIGZyb20gc2NyaXB0cw0KICAg b3RoZXIgdGhhbiB0aGUgb25lKHMpIGFzc29jaWF0ZWQgd2l0aCBvciBzcGVjaWZpZWQgYnkgdGhh dCBsYW5ndWFnZQ0KICAgdGFnLg0KDQogICBTaW5jZSB0aGVyZSBpcyBubyBsaW1pdCB0byB0aGUg bnVtYmVyIG9mIHZhcmlhbnQsIHByaXZhdGUgdXNlLCBhbmQNCiAgIGV4dGVuc2lvbiBzdWJ0YWdz LCBhbmQgY29uc2VxdWVudGx5IG5vIGxpbWl0IG9uIHRoZSBwb3NzaWJsZSBsZW5ndGgNCiAgIG9m IGEgdGFnLCBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBndWFyZCBhZ2FpbnN0IGJ1ZmZlciBvdmVy Zmxvdw0KICAgYXR0YWNrcy4gIFNlZSBTZWN0aW9uIDQuMyBmb3IgZGV0YWlscyBvbiBsYW5ndWFn ZSB0YWcgdHJ1bmNhdGlvbiwNCiAgIHdoaWNoIGNhbiBvY2N1ciBhcyBhIGNvbnNlcXVlbmNlIG9m IGRlZmVuc2VzIGFnYWluc3QgYnVmZmVyIG92ZXJmbG93Lg0KDQogICBBbHRob3VnaCB0aGUgc3Bl Y2lmaWNhdGlvbiBvZiB2YWxpZCBzdWJ0YWdzIGZvciBhbiBleHRlbnNpb24gKHNlZToNCiAgIFNl Y3Rpb24gMy42KSBNVVNUIGJlIGF2YWlsYWJsZSBvdmVyIHRoZSBJbnRlcm5ldCwgaW1wbGVtZW50 YXRpb25zDQogICBTSE9VTEQgTk9UIG1lY2hhbmljYWxseSBkZXBlbmQgb24gaXQgYmVpbmcgYWx3 YXlzIGFjY2Vzc2libGUsIHRvDQogICBwcmV2ZW50IGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFja3Mu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgNDhdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgQXVndXN0IDIwMDUNCg0KDQo3LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucw0KDQog ICBUaGUgc3ludGF4IGluIHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMgdGhhdCBsYW5ndWFnZSB0YWdz IHVzZSBvbmx5IHRoZQ0KICAgY2hhcmFjdGVycyBBLVosIGEteiwgMC05LCBhbmQgSFlQSEVOLU1J TlVTLCB3aGljaCBhcmUgcHJlc2VudCBpbiBtb3N0DQogICBjaGFyYWN0ZXIgc2V0cywgc28gdGhl IGNvbXBvc2l0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgc2hvdWxkIG5vdCBoYXZlDQogICBhbnkgY2hh cmFjdGVyIHNldCBpc3N1ZXMuDQoNCiAgIFJlbmRlcmluZyBvZiBjaGFyYWN0ZXJzIGJhc2VkIG9u IHRoZSBjb250ZW50IG9mIGEgbGFuZ3VhZ2UgdGFnIGlzIG5vdA0KICAgYWRkcmVzc2VkIGluIHRo aXMgbWVtby4gIEhpc3RvcmljYWxseSwgc29tZSBsYW5ndWFnZXMgaGF2ZSByZWxpZWQgb24NCiAg IHRoZSB1c2Ugb2Ygc3BlY2lmaWMgY2hhcmFjdGVyIHNldHMgb3Igb3RoZXIgaW5mb3JtYXRpb24g aW4gb3JkZXIgdG8NCiAgIGluZmVyIGhvdyBhIHNwZWNpZmljIGNoYXJhY3RlciBzaG91bGQgYmUg cmVuZGVyZWQgKG5vdGFibHkgdGhpcw0KICAgYXBwbGllcyB0byBsYW5ndWFnZSBhbmQgY3VsdHVy ZSBzcGVjaWZpYyB2YXJpYXRpb25zIG9mIEhhbiBpZGVvZ3JhcGhzDQogICBhcyB1c2VkIGluIEph cGFuZXNlLCBDaGluZXNlLCBhbmQgS29yZWFuKS4gIFdoZW4gbGFuZ3VhZ2UgdGFncyBhcmUNCiAg IGFwcGxpZWQgdG8gc3BhbnMgb2YgdGV4dCwgcmVuZGVyaW5nIGVuZ2luZXMgc29tZXRpbWVzIHVz ZSB0aGF0DQogICBpbmZvcm1hdGlvbiBpbiBkZWNpZGluZyB3aGljaCBmb250IHRvIHVzZSBpbiB0 aGUgYWJzZW5jZSBvZiBvdGhlcg0KICAgaW5mb3JtYXRpb24sIHBhcnRpY3VsYXJseSB3aGVyZSBs YW5ndWFnZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5nDQogICB0cmFkaXRpb25zIHVzZSB0aGUgc2Ft ZSBjaGFyYWN0ZXJzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVz IEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA0OV0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3Qg MjAwNQ0KDQoNCjguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYNCg0KICAgVGhlIG1haW4gZ29hbHMg Zm9yIHRoaXMgcmV2aXNpb24gb2YgbGFuZ3VhZ2UgdGFncyB3ZXJlIHRoZSBmb2xsb3dpbmc6DQoN CiAgICpDb21wYXRpYmlsaXR5LiogQWxsIFJGQyAzMDY2IGxhbmd1YWdlIHRhZ3MgIChpbmNsdWRp bmcgdGhvc2UgaW4gdGhlDQogICBJQU5BIHJlZ2lzdHJ5KSAgcmVtYWluIHZhbGlkIGluIHRoaXMg c3BlY2lmaWNhdGlvbi4gIFRoZSBjaGFuZ2VzIGluDQogICB0aGlzIGRvY3VtZW50IHJlcHJlc2Vu dCBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIG9uIGxhbmd1YWdlIHRhZ3MuDQogICBUaGF0IGlzLCBp biBubyBjYXNlIGlzIHRoZSBzeW50YXggbW9yZSBwZXJtaXNzaXZlIGFuZCBwcm9jZXNzb3JzDQog ICBiYXNlZCBvbiB0aGUgQUJORiBhbmQgb3RoZXIgcHJvdmlzaW9ucyBvZiBSRkMgMzA2NiAoc3Vj aCBhcyB0aG9zZQ0KICAgZGVzY3JpYmVkIGluIFtYTUxTY2hlbWFdKSB3aWxsIGJlIGFibGUgdG8g cHJvY2VzcyB0aGUgdGFncyBkZXNjcmliZWQNCiAgIGJ5IHRoaXMgZG9jdW1lbnQuICBJbiBhZGRp dGlvbiwgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGxhbmd1YWdlIHRhZ3MNCiAgIGluIHN1Y2ggYXMg d2F5IGFzIHRvIGVuc3VyZSBmdXR1cmUgY29tcGF0aWJpbGl0eS4NCg0KICAgKlN0YWJpbGl0eS4q IEJlY2F1c2Ugb2YgY2hhbmdlcyBpbiB0aGUgcGFzdCBpbiB0aGUgdW5kZXJseWluZyBJU08NCiAg IHN0YW5kYXJkcywgYSB2YWxpZCBSRkMgMzA2NiBsYW5ndWFnZSB0YWcgY291bGQgYmVjb21lIGlu dmFsaWQgb3IgaGF2ZQ0KICAgaXRzIG1lYW5pbmcgY2hhbmdlLiAgVGhpcyBoYXMgdGhlIHBvdGVu dGlhbCBvZiBpbnZhbGlkYXRpbmcgY29udGVudA0KICAgdGhhdCBtYXkgaGF2ZSBhbiBleHRlbnNp dmUgc2hlbGYtbGlmZS4gIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgb25jZSBhDQogICBsYW5ndWFn ZSB0YWcgaXMgdmFsaWQsIGl0IHJlbWFpbnMgdmFsaWQgZm9yZXZlci4NCg0KICAgKlZhbGlkaXR5 LiogIFRoZSBzdHJ1Y3R1cmUgb2YgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1l bnQNCiAgIG1ha2VzIGl0IHBvc3NpYmxlIHRvIGRldGVybWluZSBpZiBhIHBhcnRpY3VsYXIgdGFn IGlzIHdlbGwtZm9ybWVkDQogICB3aXRob3V0IHJlZ2FyZCBmb3IgdGhlIGFjdHVhbCBjb250ZW50 IG9yICJtZWFuaW5nIiBvZiB0aGUgdGFnIGFzIGENCiAgIHdob2xlLiAgVGhpcyBpcyBpbXBvcnRh bnQgYmVjYXVzZSB0aGUgcmVnaXN0cnkgZ3Jvd3MgYW5kIHVuZGVybHlpbmcNCiAgIHN0YW5kYXJk cyAgY2hhbmdlIG92ZXIgdGltZS4gIEluIGFkZGl0aW9uLCBpdCBtdXN0IGJlIHBvc3NpYmxlIHRv DQogICBkZXRlcm1pbmUgaWYgYSB0YWcgaXMgdmFsaWQgKG9yIG5vdCkgZm9yIGEgZ2l2ZW4gcG9p bnQgaW4gdGltZSBpbg0KICAgb3JkZXIgIHRvIHByb3ZpZGUgcmVwcm9kdWNpYmxlLCB0ZXN0YWJs ZSByZXN1bHRzLiAgVGhpcyBwcm9jZXNzIG11c3QNCiAgIG5vdCBiZSBlcnJvci1wcm9uZTsgb3Ro ZXJ3aXNlIGltcGxlbWVudGF0aW9ucyBtaWdodCBnaXZlIGRpZmZlcmVudA0KICAgcmVzdWx0cy4g IEJ5IGhhdmluZyBhbiBhdXRob3JpdGF0aXZlIHJlZ2lzdHJ5IHdpdGggc3BlY2lmaWMNCiAgIHZl cnNpb25pbmcgaW5mb3JtYXRpb24sIHRoZSB2YWxpZGl0eSBvZiBsYW5ndWFnZSB0YWdzIGF0IGFu eSBwb2ludCBpbg0KICAgdGltZSBjYW4gYmUgcHJlY2lzZWx5IGRldGVybWluZWQgKGluc3RlYWQg b2YgaW50ZXJwb2xhdGluZyB2YWx1ZXMNCiAgIGZyb20gbWFueSBzZXBhcmF0ZSBzb3VyY2VzKS4N Cg0KICAgKlV0aWxpdHkuKiBJdCBpcyBzb21ldGltZXMgaW1wb3J0YW50IHRvIGJlIGFibGUgdG8g ZGlmZmVyZW50aWF0ZQ0KICAgYmV0d2VlbiB3cml0dGVuIGZvcm1zIG9mIGEgbGFuZ3VhZ2UgLS0g Zm9yIG1hbnkgaW1wbGVtZW50YXRpb25zIHRoaXMNCiAgIGlzIG1vcmUgaW1wb3J0YW50IHRoYW4g ZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiB0aGUgc3Bva2VuIHZhcmlhbnRzIG9mDQogICBhIGxhbmd1 YWdlLiAgTGFuZ3VhZ2VzIGFyZSB3cml0dGVuIGluIGEgd2lkZSB2YXJpZXR5IG9mIGRpZmZlcmVu dA0KICAgc2NyaXB0cywgc28gdGhpcyBkb2N1bWVudCBwcm92aWRlcyBmb3IgdGhlIGdlbmVyYXRp dmUgdXNlIG9mIElTTw0KICAgMTU5MjQgc2NyaXB0IGNvZGVzLiAgTGlrZSB0aGUgZ2VuZXJhdGl2 ZSB1c2Ugb2YgSVNPIGxhbmd1YWdlIGFuZA0KICAgY291bnRyeSBjb2RlcyBpbiBSRkMgMzA2Niwg dGhpcyBhbGxvd3MgY29tYmluYXRpb25zIHRvIGJlIHByb2R1Y2VkDQogICB3aXRob3V0IHJlc29y dGluZyB0byB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuICBUaGUgYWRkaXRpb24gb2YgVU4NCiAg IE0uNDkgY29kZXMgcHJvdmlkZXMgZm9yIHRoZSBnZW5lcmF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mg d2l0aCByZWdpb25hbA0KICAgc2NvcGUsIHdoaWNoIGlzIGFsc28gcmVxdWlyZWQgYnkgc29tZSBh cHBsaWNhdGlvbnMuDQoNCiAgIFRoZSByZWNhc3Qgb2YgdGhlIHJlZ2lzdHJ5IGZyb20gY29udGFp bmluZyB3aG9sZSBsYW5ndWFnZSB0YWdzIHRvDQogICBzdWJ0YWdzIGlzIGEga2V5IHBhcnQgb2Yg dGhpcy4gIEFuIGltcG9ydGFudCBmZWF0dXJlIG9mIFJGQyAzMDY2IHdhcw0KICAgdGhhdCBpdCBh bGxvd2VkIGdlbmVyYXRpdmUgdXNlIG9mIHN1YnRhZ3MuICBUaGlzIGFsbG93cyBwZW9wbGUgdG8N CiAgIG1lYW5pbmdmdWxseSB1c2UgZ2VuZXJhdGVkIHRhZ3MsIHdpdGhvdXQgdGhlIGRlbGF5cyBp biByZWdpc3RlcmluZw0KICAgd2hvbGUgdGFncyBvciB0aGUgbmVlZCB0byByZWdpc3RlciBhbGwg b2YgdGhlIGNvbWJpbmF0aW9ucyB0aGF0IG1pZ2h0DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA1MF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIGJlIHVzZWZ1bC4NCg0KICAgVGhlIGNob2ljZSBvZiBw bGFjaW5nIHRoZSBleHRlbmRlZCBsYW5ndWFnZSBhbmQgc2NyaXB0IHN1YnRhZ3MNCiAgIGJldHdl ZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2UgYW5kIHJlZ2lvbiBzdWJ0YWdzIHdhcyB3aWRlbHkgZGVi YXRlZC4NCiAgIFRoaXMgZGVzaWduIHdhcyBjaG9zZW4gYmVjYXVzZSB0aGUgcHJldmFsZW50IG1h dGNoaW5nIGFuZCBjb250ZW50DQogICBuZWdvdGlhdGlvbiBzY2hlbWVzIHJlbHkgb24gdGhlIHN1 YnRhZ3MgYmVpbmcgYXJyYW5nZWQgaW4gb3JkZXIgb2YNCiAgIGluY3JlYXNpbmcgc3BlY2lmaWNp dHkuICBUaGF0IGlzLCB0aGUgc3VidGFncyB0aGF0IG1hcmsgYSBncmVhdGVyDQogICBiYXJyaWVy IHRvIG11dHVhbCBpbnRlbGxpZ2liaWxpdHkgYXBwZWFyIGxlZnQtbW9zdCBpbiBhIHRhZy4gIEZv cg0KICAgZXhhbXBsZSwgd2hlbiBzZWxlY3RpbmcgY29udGVudCB3cml0dGVuIGluIEF6ZXJiYWlq YW5pLCB0aGUgc2NyaXB0DQogICAoQXJhYmljLCBDeXJpbGxpYywgb3IgTGF0aW4pIHJlcHJlc2Vu dHMgYSBncmVhdGVyIGJhcnJpZXIgdG8NCiAgIHVuZGVyc3RhbmRpbmcgdGhhbiBhbnkgcmVnaW9u YWwgdmFyaWF0aW9ucyAodGhvc2UgYXNzb2NpYXRlZCB3aXRoDQogICBBemVyYmFpamFuIG9yIEly YW4sIGZvciBleGFtcGxlKS4gIEluZGl2aWR1YWxzIHdobyBwcmVmZXIgZG9jdW1lbnRzDQogICBp biBhIHBhcnRpY3VsYXIgc2NyaXB0LCBidXQgY2FuIGRlYWwgd2l0aCB0aGUgbWlub3IgcmVnaW9u YWwNCiAgIGRpZmZlcmVuY2VzLCBjYW4gdGhlcmVmb3JlIHNlbGVjdCBhcHByb3ByaWF0ZSBjb250 ZW50LiAgQXBwbGljYXRpb25zDQogICB0aGF0IGRvIG5vdCBkZWFsIHdpdGggd3JpdHRlbiBjb250 ZW50IHdpbGwgY29udGludWUgdG8gb21pdCB0aGVzZQ0KICAgc3VidGFncy4NCg0KICAgKkV4dGVu c2liaWxpdHkuKiBCZWNhdXNlIG9mIHRoZSB3aWRlc3ByZWFkIHVzZSBvZiBsYW5ndWFnZSB0YWdz LCBpdA0KICAgaXMgZGlzcnVwdGl2ZSB0byBoYXZlIHBlcmlvZGljIHJldmlzaW9ucyBvZiB0aGUg Y29yZSBzcGVjaWZpY2F0aW9uLA0KICAgZXZlbiBpbiB0aGUgZmFjZSBvZiBkZW1vbnN0cmF0ZWQg bmVlZC4gIFRoZSBleHRlbnNpb24gbWVjaGFuaXNtDQogICBwcm92aWRlcyBmb3IgYSB3YXkgZm9y IGluZGVwZW5kZW50IFJGQ3MgdG8gZGVmaW5lIGV4dGVuc2lvbnMgdG8NCiAgIGxhbmd1YWdlIHRh Z3MuICBUaGVzZSBleHRlbnNpb25zIGhhdmUgYSB2ZXJ5IGNvbnN0cmFpbmVkLCB3ZWxsLQ0KICAg ZGVmaW5lZCBzdHJ1Y3R1cmUgdGhhdCBwcmV2ZW50IGV4dGVuc2lvbnMgZnJvbSBpbnRlcmZlcmlu ZyB3aXRoDQogICBpbXBsZW1lbnRhdGlvbnMgb2YgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnQuDQoNCiAgIFRoZSBkb2N1bWVudCBhbHNvIGFudGljaXBhdGVzIGZlYXR1cmVz IG9mIElTTyA2MzktMyB3aXRoIHRoZSBhZGRpdGlvbg0KICAgb2YgdGhlIGV4dGVuZGVkIGxhbmd1 YWdlIHN1YnRhZ3MsIGFzIHdlbGwgYXMgdGhlIHBvc3NpYmlsaXR5IG9mIG90aGVyDQogICBJU08g NjM5IHBhcnRzIGJlY29taW5nIHVzZWZ1bCBmb3IgdGhlIGZvcm1hdGlvbiBvZiBsYW5ndWFnZSB0 YWdzIGluDQogICB0aGUgZnV0dXJlLg0KDQogICBUaGUgdXNlIGFuZCBkZWZpbml0aW9uIG9mIHBy aXZhdGUgdXNlIHRhZ3MgaGFzIGFsc28gYmVlbiBtb2RpZmllZCwgdG8NCiAgIGFsbG93IHBlb3Bs ZSB0byB1c2UgcHJpdmF0ZSB1c2Ugc3VidGFncyB0byBleHRlbmQgb3IgbW9kaWZ5IGRlZmluZWQN CiAgIHRhZ3MgYW5kIHRvIG1vdmUgYXMgbXVjaCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSBvdXQg b2YgcHJpdmF0ZSB1c2UNCiAgIGFuZCBpbnRvIHRoZSByZWd1bGFyIHN0cnVjdHVyZS4NCg0KICAg VGhlIGdvYWwgZm9yIGVhY2ggb2YgdGhlc2UgbW9kaWZpY2F0aW9ucyBpcyB0byByZWR1Y2Ugb3Ig ZWxpbWluYXRlDQogICB0aGUgbmVlZCBmb3IgZnV0dXJlIHJldmlzaW9ucyBvZiB0aGlzIGRvY3Vt ZW50Lg0KDQogICBUaGUgc3BlY2lmaWMgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50IHRvIG1lZXQg dGhlc2UgZ29hbHMgYXJlOg0KDQogICBvICBEZWZpbmVzIHRoZSBBQk5GIGFuZCBydWxlcyBmb3Ig c3VidGFncyBzbyB0aGF0IHRoZSBjYXRlZ29yeSBvZiBhbGwNCiAgICAgIHN1YnRhZ3MgY2FuIGJl IGRldGVybWluZWQgd2l0aG91dCByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5Lg0KDQogICBvICBB ZGRzIHRoZSBjb25jZXB0IG9mIHdlbGwtZm9ybWVkIHZzLiB2YWxpZGF0aW5nIHByb2Nlc3NvcnMs DQogICAgICBkZWZpbmluZyB0aGUgcnVsZXMgYnkgd2hpY2ggYW4gaW1wbGVtZW50YXRpb24gY2Fu IGNsYWltIHRvIGJlIG9uZQ0KICAgICAgb3IgdGhlIG90aGVyLg0KDQoNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQ YWdlIDUxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgbyAgUmVwbGFjZXMgdGhlIElBTkEg bGFuZ3VhZ2UgdGFnIHJlZ2lzdHJ5IHdpdGggYSBsYW5ndWFnZSBzdWJ0YWcNCiAgICAgIHJlZ2lz dHJ5IHRoYXQgcHJvdmlkZXMgYSBjb21wbGV0ZSBsaXN0IG9mIHZhbGlkIHN1YnRhZ3MgaW4gdGhl DQogICAgICBJQU5BIHJlZ2lzdHJ5LiAgVGhpcyBhbGxvd3MgZm9yIHJvYnVzdCBpbXBsZW1lbnRh dGlvbiBhbmQgZWFzZSBvZg0KICAgICAgbWFpbnRlbmFuY2UuICBUaGUgbGFuZ3VhZ2Ugc3VidGFn IHJlZ2lzdHJ5IGJlY29tZXMgdGhlIGNhbm9uaWNhbA0KICAgICAgc291cmNlIGZvciBmb3JtaW5n IGxhbmd1YWdlIHRhZ3MuDQoNCiAgIG8gIFByb3ZpZGVzIGEgcHJvY2VzcyB0aGF0IGd1YXJhbnRl ZXMgc3RhYmlsaXR5IG9mIGxhbmd1YWdlIHRhZ3MsIGJ5DQogICAgICBoYW5kbGluZyByZXVzZSBv ZiB2YWx1ZXMgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYgaW4NCiAgICAgIHRo ZSBldmVudCB0aGF0IHRoZXkgcmVnaXN0ZXIgYSBwcmV2aW91c2x5IHVzZWQgdmFsdWUgZm9yIGEg bmV3DQogICAgICBwdXJwb3NlLg0KDQogICBvICBBbGxvd3MgSVNPIDE1OTI0IHNjcmlwdCBjb2Rl IHN1YnRhZ3MgYW5kIGFsbG93cyB0aGVtIHRvIGJlIHVzZWQNCiAgICAgIGdlbmVyYXRpdmVseS4g IERlZmluZXMgYSBtZXRob2QgZm9yIGluZGljYXRpbmcgaW4gdGhlIHJlZ2lzdHJ5DQogICAgICB3 aGVuIHNjcmlwdCBzdWJ0YWdzIGFyZSBuZWNlc3NhcnkgZm9yIGEgZ2l2ZW4gbGFuZ3VhZ2UgdGFn Lg0KDQogICBvICBBZGRzIHRoZSBjb25jZXB0IG9mIGEgdmFyaWFudCBzdWJ0YWcgYW5kIGFsbG93 cyB2YXJpYW50cyB0byBiZQ0KICAgICAgdXNlZCBnZW5lcmF0aXZlbHkuDQoNCiAgIG8gIEFkZHMg dGhlIGFiaWxpdHkgdG8gdXNlIGEgY2xhc3Mgb2YgVU4gTS40OSB0YWdzIGZvciAgc3VwcmEtDQog ICAgICBuYXRpb25hbCByZWdpb25zIGFuZCB0byByZXNvbHZlIGNvbmZsaWN0cyBpbiB0aGUgYXNz aWdubWVudCBvZiBJU08NCiAgICAgIDMxNjYgY29kZXMuDQoNCiAgIG8gIERlZmluZXMgdGhlIHBy aXZhdGUgdXNlIHRhZ3MgaW4gSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYNCiAgICAg IGFzIHRoZSBtZWNoYW5pc20gZm9yIGNyZWF0aW5nIHByaXZhdGUgdXNlIGxhbmd1YWdlLCBzY3Jp cHQsIGFuZA0KICAgICAgcmVnaW9uIHN1YnRhZ3MgcmVzcGVjdGl2ZWx5Lg0KDQogICBvICBBZGRz IGEgd2VsbC1kZWZpbmVkIGV4dGVuc2lvbiBtZWNoYW5pc20uDQoNCiAgIG8gIERlZmluZXMgYW4g ZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnLCBwb3NzaWJseSBmb3IgdXNlIHdpdGggY2VydGFpbg0K ICAgICAgYW50aWNpcGF0ZWQgZmVhdHVyZXMgb2YgSVNPIDYzOS0zLg0KDQogICBFZCBOb3RlOiBU aGUgZm9sbG93aW5nIGl0ZW1zIGFyZSBwcm92aWRlZCBmb3IgdGhlIGNvbnZlbmllbmNlIG9mDQog ICByZXZpZXdlcnMgYW5kIHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSBmaW5hbCBkb2N1bWVudC4N Cg0KICAgQ2hhbmdlcyBiZXR3ZWVuIGRyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0xMCBhbmQgdGhp cyB2ZXJzaW9uIGFyZToNCg0KICAgbyAgQ2hhbmdlZCB0aGUgdGV4dCBkZXNjcmliaW5nIGV4dGVu c2lvbnMgZnJvbSAic2luZ2xlLWxldHRlciIgdG8NCiAgICAgICJzaW5nbGUgY2hhcmFjdGVyIiBv ciAic2luZ2xldG9uIiB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIEFCTkYNCiAgICAgIGFuZCB0 aGUgV0cncyBpbnRlbnRpb25zIChELkV3ZWxsKQ0KDQogICBvICBNYWRlIFJGQyAyMDQ3LCBSRkMg Mjc4MSwgYW5kIFJGQyAzNTUyIGludG8gaW5mb3JtYXRpdmUgcmVmZXJlbmNlcw0KICAgICAgKCMx MDk1KShLLkthcmxzc29uKQ0KDQogICBvICBNYWRlIG1vZGlmaWNhdGlvbnMgdG8gY2xhcmlmeSB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBMYW5ndWFnZQ0KICAgICAgU3VidGFnIFJlZ2lzdHJ5 IGFuZCB0aGUgTGFuZ3VhZ2UgRXh0ZW5zaW9ucyBSZWdpc3RyeSAoSy5LYXJsc3NvbikNCg0KICAg byAgSW5zZXJ0ZWQgc29tZSB0ZXh0IHRvIGVuc3VyZSB0aGF0IHRoZSBMYW5ndWFnZSBFeHRlbnNp b25zIFJlZ2lzdHJ5DQogICAgICBpcyBpbml0aWFsaXplZCBwcm9wZXJseSAoIzExMDMpIChLLkth cmxzc29uKQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAx NiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgNTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQo5 LiAgUmVmZXJlbmNlcw0KDQo5LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtJU08xMDY0 Nl0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJk aXphdGlvbiwgIklTTy9JRUMNCiAgICAgICAgICAgICAgMTA2NDY6MjAwMy4gCUluZm9ybWF0aW9u IHRlY2hub2xvZ3kgLS0gVW5pdmVyc2FsIE11bHRpcGxlLQ0KICAgICAgICAgICAgICBPY3RldCBD b2RlZCBDaGFyYWN0ZXIgU2V0IChVQ1MpIiwgMjAwMy4NCg0KICAgW0lTTzE1OTI0XQ0KICAgICAg ICAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAi SVNPDQogICAgICAgICAgICAgIDE1OTI0OjIwMDQuIEluZm9ybWF0aW9uIGFuZCBkb2N1bWVudGF0 aW9uIC0tIENvZGVzIGZvciB0aGUNCiAgICAgICAgICAgICAgcmVwcmVzZW50YXRpb24gb2YgbmFt ZXMgb2Ygc2NyaXB0cyIsIEphbnVhcnkgMjAwNC4NCg0KICAgW0lTTzMxNjYtMV0NCiAgICAgICAg ICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklT TyAzMTY2LQ0KICAgICAgICAgICAgICAxOjE5OTcuIAlDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0 aW9uIG9mIG5hbWVzIG9mDQogICAgICAgICAgICAgIGNvdW50cmllcyBhbmQgdGhlaXIgc3ViZGl2 aXNpb25zIC0tIFBhcnQgMTogQ291bnRyeQ0KICAgICAgICAgICAgICBjb2RlcyIsIDE5OTcuDQoN CiAgIFtJU082MzktMV0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24g Zm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyA2MzktDQogICAgICAgICAgICAgIDE6MjAwMi4gQ29k ZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBsYW5ndWFnZXMNCiAgICAgICAg ICAgICAgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiLCAyMDAyLg0KDQogICBbSVNPNjM5LTJdDQog ICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRp b24sICJJU08gNjM5LQ0KICAgICAgICAgICAgICAyOjE5OTguIENvZGVzIGZvciB0aGUgcmVwcmVz ZW50YXRpb24gb2YgbmFtZXMgb2YgbGFuZ3VhZ2VzDQogICAgICAgICAgICAgIC0tIFBhcnQgMjog QWxwaGEtMyBjb2RlLCBmaXJzdCBlZGl0aW9uIiwgMTk5OC4NCg0KICAgW0lTTzY0Nl0gICBJbnRl cm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPL0lFQw0KICAg ICAgICAgICAgICA2NDY6MTk5MSwgSW5mb3JtYXRpb24gdGVjaG5vbG9neSAtLSBJU08gNy1iaXQg Y29kZWQNCiAgICAgICAgICAgICAgY2hhcmFjdGVyIHNldCBmb3IgaW5mb3JtYXRpb24gaW50ZXJj aGFuZ2UuIiwgMTk5MS4NCg0KICAgW1JGQzIwMjZdICBCcmFkbmVyLCBTLiwgIlRoZSBJbnRlcm5l dCBTdGFuZGFyZHMgUHJvY2VzcyAtLSBSZXZpc2lvbg0KICAgICAgICAgICAgICAzIiwgQkNQIDks IFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuDQoNCiAgIFtSRkMyMDI4XSAgSG92ZXksIFIuIGFuZCBT LiBCcmFkbmVyLCAiVGhlIE9yZ2FuaXphdGlvbnMgSW52b2x2ZWQgaW4NCiAgICAgICAgICAgICAg dGhlIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MiLCBCQ1AgMTEsIFJGQyAyMDI4LA0KICAgICAgICAg ICAgICBPY3RvYmVyIDE5OTYuDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29y ZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50 IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkMyMjM0Ymlz XQ0KICAgICAgICAgICAgICBDcm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBC TkYgZm9yIFN5bnRheA0KICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIsIGRyYWZ0 LWNyb2NrZXItYWJuZi1yZmMyMjM0YmlzLTAwDQogICAgICAgICAgICAgICh3b3JrIGluIHByb2dy ZXNzKSwgTWFyY2ggMjAwNS4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDUzXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA1DQoNCg0KICAgW1JGQzI0MzRdICBOYXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAiR3Vp ZGVsaW5lcyBmb3IgV3JpdGluZyBhbg0KICAgICAgICAgICAgICBJQU5BIENvbnNpZGVyYXRpb25z IFNlY3Rpb24gaW4gUkZDcyIsIEJDUCAyNiwgUkZDIDI0MzQsDQogICAgICAgICAgICAgIE9jdG9i ZXIgMTk5OC4NCg0KICAgW1JGQzI4NjBdICBDYXJwZW50ZXIsIEIuLCBCYWtlciwgRi4sIGFuZCBN LiBSb2JlcnRzLCAiTWVtb3JhbmR1bSBvZg0KICAgICAgICAgICAgICBVbmRlcnN0YW5kaW5nIENv bmNlcm5pbmcgdGhlIFRlY2huaWNhbCBXb3JrIG9mIHRoZQ0KICAgICAgICAgICAgICBJbnRlcm5l dCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSIsIFJGQyAyODYwLCBKdW5lIDIwMDAuDQoNCiAg IFtSRkMzMzM5XSAgS2x5bmUsIEcuIGFuZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1lIG9uIHRo ZSBJbnRlcm5ldDoNCiAgICAgICAgICAgICAgVGltZXN0YW1wcyIsIFJGQyAzMzM5LCBKdWx5IDIw MDIuDQoNCiAgIFtVTl9NLjQ5XSAgU3RhdGlzdGljcyBEaXZpc2lvbiwgVW5pdGVkIE5hdGlvbnMs ICJTdGFuZGFyZCBDb3VudHJ5IG9yDQogICAgICAgICAgICAgIEFyZWEgQ29kZXMgZm9yIFN0YXRp c3RpY2FsIFVzZSIsIFVOIFN0YW5kYXJkIENvdW50cnkgb3INCiAgICAgICAgICAgICAgQXJlYSBD b2RlcyBmb3IgU3RhdGlzdGljYWwgVXNlLCBSZXZpc2lvbiA0IChVbml0ZWQgTmF0aW9ucw0KICAg ICAgICAgICAgICBwdWJsaWNhdGlvbiwgU2FsZXMgTm8uIDk4LlhWSUkuOSwgSnVuZSAxOTk5Lg0K DQo5LjIgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzE3NjZdICBBbHZlc3RyYW5k LCBILiwgIlRhZ3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBvZg0KICAgICAgICAgICAgICBMYW5n dWFnZXMiLCBSRkMgMTc2NiwgTWFyY2ggMTk5NS4NCg0KICAgW1JGQzIwNDddICBNb29yZSwgSy4s ICJNSU1FIChNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCBFeHRlbnNpb25zKQ0KICAgICAgICAg ICAgICBQYXJ0IFRocmVlOiBNZXNzYWdlIEhlYWRlciBFeHRlbnNpb25zIGZvciBOb24tQVNDSUkg VGV4dCIsDQogICAgICAgICAgICAgIFJGQyAyMDQ3LCBOb3ZlbWJlciAxOTk2Lg0KDQogICBbUkZD MjIzMV0gIEZyZWVkLCBOLiBhbmQgSy4gTW9vcmUsICJNSU1FIFBhcmFtZXRlciBWYWx1ZSBhbmQg RW5jb2RlZA0KICAgICAgICAgICAgICBXb3JkIEV4dGVuc2lvbnM6IENoYXJhY3RlciBTZXRzLCBM YW5ndWFnZXMsIGFuZA0KICAgICAgICAgICAgICBDb250aW51YXRpb25zIiwgUkZDIDIyMzEsIE5v dmVtYmVyIDE5OTcuDQoNCiAgIFtSRkMyNzgxXSAgSG9mZm1hbiwgUC4gYW5kIEYuIFllcmdlYXUs ICJVVEYtMTYsIGFuIGVuY29kaW5nIG9mIElTTw0KICAgICAgICAgICAgICAxMDY0NiIsIFJGQyAy NzgxLCBGZWJydWFyeSAyMDAwLg0KDQogICBbUkZDMzA2Nl0gIEFsdmVzdHJhbmQsIEguLCAiVGFn cyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mDQogICAgICAgICAgICAgIExhbmd1YWdlcyIsIEJD UCA0NywgUkZDIDMwNjYsIEphbnVhcnkgMjAwMS4NCg0KICAgW1JGQzM1NTJdICBSZXNjb3JsYSwg RS4gYW5kIEIuIEtvcnZlciwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgUkZDDQogICAgICAgICAg ICAgIFRleHQgb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLCBCQ1AgNzIsIFJGQyAzNTUyLA0K ICAgICAgICAgICAgICBKdWx5IDIwMDMuDQoNCiAgIFtVbmljb2RlXSAgVW5pY29kZSBDb25zb3J0 aXVtLCAiVGhlIFVuaWNvZGUgQ29uc29ydGl1bS4gVGhlIFVuaWNvZGUNCiAgICAgICAgICAgICAg U3RhbmRhcmQsIFZlcnNpb24gNC4xLjAsIGRlZmluZWQgYnk6IFRoZSBVbmljb2RlIFN0YW5kYXJk LA0KICAgICAgICAgICAgICBWZXJzaW9uIDQuMCAoQm9zdG9uLCBNQSwgQWRkaXNvbi1XZXNsZXks IDIwMDMuIElTQk4gMC0zMjEtDQogICAgICAgICAgICAgIDE4NTc4LTEpLCBhcyBhbWVuZGVkIGJ5 IFVuaWNvZGUgNC4wLjENCiAgICAgICAgICAgICAgKGh0dHA6Ly93d3cudW5pY29kZS5vcmcvdmVy c2lvbnMvVW5pY29kZTQuMC4xKSBhbmQgYnkNCiAgICAgICAgICAgICAgVW5pY29kZSA0LjEuMA0K ICAgICAgICAgICAgICAoaHR0cDovL3d3dy51bmljb2RlLm9yZy92ZXJzaW9ucy9Vbmljb2RlNC4x LjApLiIsDQogICAgICAgICAgICAgIE1hcmNoIDIwMDUuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDU0 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgW1hNTDEwXSAgICBCcmF5IChldCBhbCksIFQu LCAiRXh0ZW5zaWJsZSBNYXJrdXAgTGFuZ3VhZ2UgKFhNTCkgMS4wIiwNCiAgICAgICAgICAgICAg MDIgMjAwNC4NCg0KICAgW1hNTFNjaGVtYV0NCiAgICAgICAgICAgICAgQmlyb24sIFAuLCBFZC4g YW5kIEEuIE1hbGhvdHJhLCBFZC4sICJYTUwgU2NoZW1hIFBhcnQgMjoNCiAgICAgICAgICAgICAg RGF0YXR5cGVzIFNlY29uZCBFZGl0aW9uIiwgMTAgMjAwNCwgPA0KICAgICAgICAgICAgICBodHRw Oi8vd3d3LnczLm9yZy9UUi94bWxzY2hlbWEtMi8+Lg0KDQogICBbaW5pdGlhbC1yZWdpc3RyeV0N CiAgICAgICAgICAgICAgRXdlbGwsIEQuLCBFZC4sICJJbml0aWFsIExhbmd1YWdlIFN1YnRhZyBS ZWdpc3RyeSIsDQogICAgICAgICAgICAgIEp1bmUgMjAwNSwgPGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLWx0cnUtaW5pdGlhbC1y ZWdpc3RyeS0wMC50eHQ+Lg0KDQogICBbaXNvNjM5LnByaW5jaXBsZXNdDQogICAgICAgICAgICAg IElTTyA2MzkgSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlLCAiSVNPIDYzOSBKb2ludCBBZHZpc29y eQ0KICAgICAgICAgICAgICBDb21taXR0ZWU6ICBXb3JraW5nIHByaW5jaXBsZXMgZm9yIElTTyA2 MzkgbWFpbnRlbmFuY2UiLA0KICAgICAgICAgICAgICBNYXJjaCAyMDAwLA0KICAgICAgICAgICAg ICA8aHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi8NCiAgICAgICAgICAgICAg aXNvNjM5amFjX24zci5odG1sPi4NCg0KICAgW3JlY29yZC1qYXJdDQogICAgICAgICAgICAgIFJh eW1vbmQsIEUuLCAiVGhlIEFydCBvZiBVbml4IFByb2dyYW1taW5nIiwgMjAwMy4NCg0KDQpBdXRo b3JzJyBBZGRyZXNzZXMNCg0KICAgQWRkaXNvbiBQaGlsbGlwcyAoZWRpdG9yKQ0KICAgUXVlc3Qg U29mdHdhcmUNCg0KICAgRW1haWw6IGFkZGlzb24ucGhpbGxpcHNAcXVlc3QuY29tDQogICBVUkk6 ICAgaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tDQoNCg0KICAgTWFyayBEYXZpcyAoZWRpdG9y KQ0KICAgSUJNDQoNCiAgIEVtYWlsOiBtYXJrLmRhdmlzQHVzLmlibS5jb20NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDE2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA1NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoN CkFwcGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIEFueSBsaXN0IG9mIGNvbnRyaWJ1 dG9ycyBpcyBib3VuZCB0byBiZSBpbmNvbXBsZXRlOyBwbGVhc2UgcmVnYXJkIHRoZQ0KICAgZm9s bG93aW5nIGFzIG9ubHkgYSBzZWxlY3Rpb24gZnJvbSB0aGUgZ3JvdXAgb2YgcGVvcGxlIHdobyBo YXZlDQogICBjb250cmlidXRlZCB0byBtYWtlIHRoaXMgZG9jdW1lbnQgd2hhdCBpdCBpcyB0b2Rh eS4NCg0KICAgVGhlIGNvbnRyaWJ1dG9ycyB0byBSRkMgMzA2NiBhbmQgUkZDIDE3NjYsIHRoZSBw cmVjdXJzb3JzIG9mIHRoaXMNCiAgIGRvY3VtZW50LCBtYWRlIGVub3Jtb3VzIGNvbnRyaWJ1dGlv bnMgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSB0byB0aGlzDQogICBkb2N1bWVudCBhbmQgYXJlIGdl bmVyYWxseSByZXNwb25zaWJsZSBmb3IgdGhlIHN1Y2Nlc3Mgb2YgbGFuZ3VhZ2UNCiAgIHRhZ3Mu DQoNCiAgIFRoZSBmb2xsb3dpbmcgcGVvcGxlIChpbiBhbHBoYWJldGljYWwgb3JkZXIpIGNvbnRy aWJ1dGVkIHRvIHRoaXMNCiAgIGRvY3VtZW50IG9yIHRvIFJGQ3MgMTc2NiBhbmQgMzA2NjoNCg0K ICAgR2xlbm4gQWRhbXMsIEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCBUaW0gQmVybmVycy1MZWUs IE1hcmMgQmxhbmNoZXQsDQogICBOYXRoYW5pZWwgQm9yZW5zdGVpbiwgS2FyZW4gQnJvb21lLCBF cmljIEJydW5uZXIsIFNlYW4gTS4gQnVya2UsIE0uVC4NCiAgIENhcnJhc2NvIEJlbml0ZXosIEpl cmVteSBDYXJyb2xsLCBKb2huIENsZXdzLCBKaW0gQ29ua2xpbiwgUGV0ZXINCiAgIENvbnN0YWJs ZSwgSm9obiBDb3dhbiwgTWFyayBDcmlzcGluLCBEYXZlIENyb2NrZXIsIE1hcnRpbiBEdWVyc3Qs DQogICBGcmFuayBFbGxlcm1hbiwgTWljaGFlbCBFdmVyc29uLCBEb3VnIEV3ZWxsLCBOZWQgRnJl ZWQsIFRpbSBHb29kd2luLA0KICAgRGlyay1XaWxsZW0gdmFuIEd1bGlrLCBNYXJpb24gR3Vubiwg Sm9lbCBIYWxwcmVuLCBFbGxpb3R0ZSBSdXN0eQ0KICAgSGFyb2xkLCBQYXVsIEhvZmZtYW4sIFNj b3R0IEhvbGxlbmJlY2ssIFJpY2hhcmQgSXNoaWRhLCBPbGxlDQogICBKYXJuZWZvcnMsIEtlbnQg S2FybHNzb24sIEpvaG4gS2xlbnNpbiwgRXJra2kgS29sZWhtYWluZW4sIEFsYWluDQogICBMYUJv bnRlLCBFcmljIE1hZGVyLCBJcmEgTWNEb25hbGQsIEtlaXRoIE1vb3JlLCBDaHJpcyBOZXdtYW4s DQogICBNYXNhdGFrYSBPaHRhLCBEeWxhbiBQaWVyY2UsIFJhbmR5IFByZXN1aG4sIEdlb3JnZSBS aG90ZW4sIEZlbGl4DQogICBTYXNha2ksIE1hcmt1cyBTY2hlcmVyLCBLZWxkIEpvcm4gU2ltb25z ZW4sIFRoaWVycnkgU291cmJpZXIsIE90dG8NCiAgIFN0b2x6LCBUZXggVGV4aW4sIEFuZHJlYSBW aW5lLCBSaHlzIFdlYXRoZXJsZXksIE1pc2hhIFdvbGYsIEZyYW5jb2lzDQogICBZZXJnZWF1IGFu ZCBtYW55LCBtYW55IG90aGVycy4NCg0KICAgVmVyeSBzcGVjaWFsIHRoYW5rcyBtdXN0IGdvIHRv IEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCB3aG8NCiAgIG9yaWdpbmF0ZWQgUkZDcyAxNzY2IGFu ZCAzMDY2LCBhbmQgd2l0aG91dCB3aG9tIHRoaXMgZG9jdW1lbnQgd291bGQNCiAgIG5vdCBoYXZl IGJlZW4gcG9zc2libGUuICBTcGVjaWFsIHRoYW5rcyBtdXN0IGdvIHRvIE1pY2hhZWwgRXZlcnNv biwNCiAgIHdobyBoYXMgc2VydmVkIGFzIGxhbmd1YWdlIHRhZyByZXZpZXdlciBmb3IgYWxtb3N0 IHRoZSBjb21wbGV0ZQ0KICAgcGVyaW9kIHNpbmNlIHRoZSBwdWJsaWNhdGlvbiBvZiBSRkMgMTc2 Ni4gIFNwZWNpYWwgdGhhbmtzIHRvIERvdWcNCiAgIEV3ZWxsLCBmb3IgaGlzIHByb2R1Y3Rpb24g b2YgdGhlIGZpcnN0IGNvbXBsZXRlIHN1YnRhZyByZWdpc3RyeSwgYW5kDQogICBoaXMgd29yayBp biBwcm9kdWNpbmcgYSB0ZXN0IHBhcnNlciBmb3IgdmVyaWZ5aW5nIGxhbmd1YWdlIHRhZ3MuDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMTYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDU2XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1DQoNCg0KQXBwZW5kaXggQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3MgKElu Zm9ybWF0aXZlKQ0KDQogICBTaW1wbGUgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAgICBkZSAoR2Vy bWFuKQ0KDQogICAgICBmciAoRnJlbmNoKQ0KDQogICAgICBqYSAoSmFwYW5lc2UpDQoNCiAgICAg IGktZW5vY2hpYW4gKGV4YW1wbGUgb2YgYSBncmFuZGZhdGhlcmVkIHRhZykNCg0KICAgTGFuZ3Vh Z2Ugc3VidGFnIHBsdXMgU2NyaXB0IHN1YnRhZzoNCg0KICAgICAgemgtSGFudCAoQ2hpbmVzZSB3 cml0dGVuIHVzaW5nIHRoZSBUcmFkaXRpb25hbCBDaGluZXNlIHNjcmlwdCkNCg0KICAgICAgemgt SGFucyAoQ2hpbmVzZSB3cml0dGVuIHVzaW5nIHRoZSBTaW1wbGlmaWVkIENoaW5lc2Ugc2NyaXB0 KQ0KDQogICAgICBzci1DeXJsIChTZXJiaWFuIHdyaXR0ZW4gdXNpbmcgdGhlICBDeXJpbGxpYyBz Y3JpcHQpDQoNCiAgICAgIHNyLUxhdG4gKFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4g c2NyaXB0KQ0KDQogICBMYW5ndWFnZS1TY3JpcHQtUmVnaW9uOg0KDQogICAgICB6aC1IYW5zLUNO IChDaGluZXNlIHdyaXR0ZW4gdXNpbmcgdGhlIFNpbXBsaWZpZWQgc2NyaXB0IGFzIHVzZWQgaW4N CiAgICAgIG1haW5sYW5kIENoaW5hKQ0KDQogICAgICBzci1MYXRuLUNTIChTZXJiaWFuIHdyaXR0 ZW4gdXNpbmcgdGhlIExhdGluIHNjcmlwdCBhcyB1c2VkIGluDQogICAgICBTZXJiaWEgYW5kIE1v bnRlbmVncm8pDQoNCiAgIExhbmd1YWdlLVZhcmlhbnQ6DQoNCiAgICAgIHNsLXJvemFqIChSZXNp YW4gZGlhbGVjdCBvZiBTbG92ZW5pYW4NCg0KICAgICAgc2wtbmVkaXMgKE5hZGl6YSBkaWFsZWN0 IG9mIFNsb3ZlbmlhbikNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uLVZhcmlhbnQ6DQoNCiAgICAgIGRl LUNILTE5MDEgKEdlcm1hbiBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kIHVzaW5nIHRoZSAxOTAxIHZh cmlhbnQNCiAgICAgIFtvcnRob2dyYXBoeV0pDQoNCiAgICAgIHNsLUlULW5lZGlzIChTbG92ZW5p YW4gYXMgdXNlZCBpbiBJdGFseSwgTmFkaXphIGRpYWxlY3QpDQoNCiAgIExhbmd1YWdlLVNjcmlw dC1SZWdpb24tVmFyaWFudDoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgNTddDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg QXVndXN0IDIwMDUNCg0KDQogICAgICBzbC1MYXRuLUlULW5lZGlzIChOYWRpemEgZGlhbGVjdCBv ZiBTbG92ZW5pYW4gd3JpdHRlbiB1c2luZyB0aGUNCiAgICAgIExhdGluIHNjcmlwdCBhcyB1c2Vk IGluIEl0YWx5LiAgTm90ZSB0aGF0IHRoaXMgdGFnIGlzIE5PVA0KICAgICAgUkVDT01NRU5ERUQg YmVjYXVzZSBzdWJ0YWcgJ3NsJyBoYXMgYSBTdXBwcmVzcy1TY3JpcHQgdmFsdWUgb2YNCiAgICAg ICdMYXRuJykNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uOg0KDQogICAgICBkZS1ERSAoR2VybWFuIGZv ciBHZXJtYW55KQ0KDQogICAgICBlbi1VUyAoRW5nbGlzaCBhcyB1c2VkIGluIHRoZSBVbml0ZWQg U3RhdGVzKQ0KDQogICAgICBlcy00MTkgKFNwYW5pc2ggYXBwcm9wcmlhdGUgZm9yIHRoZSBMYXRp biBBbWVyaWNhIGFuZCBDYXJpYmJlYW4NCiAgICAgIHJlZ2lvbiB1c2luZyB0aGUgVU4gcmVnaW9u IGNvZGUpDQoNCiAgIFByaXZhdGUgdXNlIHN1YnRhZ3M6DQoNCiAgICAgIGRlLUNILXgtcGhvbmVi aw0KDQogICAgICBhei1BcmFiLXgtQVpFLWRlcmJlbmQNCg0KICAgRXh0ZW5kZWQgbGFuZ3VhZ2Ug c3VidGFncyAoZXhhbXBsZXMgT05MWTogZXh0ZW5kZWQgbGFuZ3VhZ2VzIE1VU1QgYmUNCiAgIGRl ZmluZWQgYnkgcmV2aXNpb24gb3IgdXBkYXRlIHRvIHRoaXMgZG9jdW1lbnQpOg0KDQogICAgICB6 aC1taW4NCg0KICAgICAgemgtbWluLW5hbi1IYW50LUNODQoNCiAgIFByaXZhdGUgdXNlIHJlZ2lz dHJ5IHZhbHVlczoNCg0KICAgICAgeC13aGF0ZXZlciAocHJpdmF0ZSB1c2UgdXNpbmcgdGhlIHNp bmdsZXRvbiAneCcpDQoNCiAgICAgIHFhYS1RYWFhLVFNLXgtc291dGhlcm4gKGFsbCBwcml2YXRl IHRhZ3MpDQoNCiAgICAgIGRlLVFhYWEgKEdlcm1hbiwgd2l0aCBhIHByaXZhdGUgc2NyaXB0KQ0K DQogICAgICBzci1MYXRuLVFNIChTZXJiaWFuLCBMYXRpbi1zY3JpcHQsIHByaXZhdGUgcmVnaW9u KQ0KDQogICAgICBzci1RYWFhLUNTIChTZXJiaWFuLCBwcml2YXRlIHNjcmlwdCwgZm9yIFNlcmJp YSBhbmQgTW9udGVuZWdybykNCg0KICAgVGFncyB0aGF0IHVzZSBleHRlbnNpb25zIChleGFtcGxl cyBPTkxZOiBleHRlbnNpb25zIE1VU1QgYmUgZGVmaW5lZA0KICAgYnkgcmV2aXNpb24gb3IgdXBk YXRlIHRvIHRoaXMgZG9jdW1lbnQgb3IgYnkgUkZDKToNCg0KICAgICAgZW4tVVMtdS1pc2xhbUNh bA0KDQogICAgICB6aC1DTi1hLW15RXh0LXgtcHJpdmF0ZQ0KDQoNCg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAgW1Bh Z2UgNThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICBlbi1hLW15RXh0LWItYW5vdGhl cg0KDQogICBTb21lIEludmFsaWQgVGFnczoNCg0KICAgICAgZGUtNDE5LURFICh0d28gcmVnaW9u IHRhZ3MpDQoNCiAgICAgIGEtREUgKHVzZSBvZiBhIHNpbmdsZSBjaGFyYWN0ZXIgc3VidGFnIGlu IHByaW1hcnkgcG9zaXRpb247IG5vdGUNCiAgICAgIHRoYXQgdGhlcmUgYXJlIGEgZmV3IGdyYW5k ZmF0aGVyZWQgdGFncyB0aGF0IHN0YXJ0IHdpdGggImktIiB0aGF0DQogICAgICBhcmUgdmFsaWQp DQoNCiAgICAgIGFyLWEtYWFhLWItYmJiLWEtY2NjICh0d28gZXh0ZW5zaW9ucyB3aXRoIHNhbWUg c2luZ2xlIGxldHRlcg0KICAgICAgcHJlZml4KQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNiwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgNTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkg U3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUg dmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRz IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8g dGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4N CiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRl ciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRv ZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZv cnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBw cm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUN CiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Ns b3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNl cyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0K ICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9u IGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRl cnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJv bSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYu b3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBi cmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRl bnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5 IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0 aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRG IGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpEaXNjbGFpbWVyIG9mIFZhbGlkaXR5DQoN CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFy ZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBU SEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkg KElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVOR0lO RUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1Q TElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQg VEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBB TlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU WSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpDb3B5cmlnaHQgU3Rh dGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLiAg VGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQg cmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZA0KICAgZXhjZXB0IGFzIHNldCBm b3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KDQpB Y2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBp cyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE2LCAyMDA2ICAgICAg ICAgICAgICBbUGFnZSA2MF0NCgwNCg== ------_=_NextPart_001_01C5A290.5034B1A1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C5A290.5034B1A1-- From ltru-bounces@lists.ietf.org Tue Aug 16 14:29:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56C4-0002Z0-8c; Tue, 16 Aug 2005 14:29:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56C2-0002YC-V7 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 14:29:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27250 for ; Tue, 16 Aug 2005 14:29:45 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56lQ-0000ak-5r for ltru@ietf.org; Tue, 16 Aug 2005 15:06:21 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 11:29:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] End of ltru WG last calls on registry and initial registryi-ds Date: Tue, 16 Aug 2005 11:29:36 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BE18@irvmbxw01.quest.com> Thread-Topic: [Ltru] End of ltru WG last calls on registry and initial registryi-ds Thread-Index: AcWij9k9sPXqgBLMTE6FiScxluS2NgAAHIYQ From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 16 Aug 2005 18:29:36.0783 (UTC) FILETIME=[74C2A1F0:01C5A290] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Draft-11 is submitted. It and its diff are on inter-locale (they are unchanged from last = night's version). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?16? 11:25 > To: LTRU Working Group > Subject: [Ltru] End of ltru WG last calls on registry and initial > registryi-ds >=20 > Hi - >=20 > We've closed out the last of the open issues on the issue > tracker (https://rt.psg.com/ (user and password "ietf")), and > the rough consensus of those who have posted saying > that they've read the draft is of approval. >=20 > The ltru working group last call of the documents > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-10.txt > and http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt > is now complete. The Editors are instructed to submit > updated drafts, incorporating agreed changes, at their > earliest convenience. A third last call will not be needed. >=20 > When the updated drafts are available, Martin and I will > submit the publication requests to the IESG. The working > group will receive copies of the requests, and will be kept > in the loop for any IESG review comments and IETF last > call comments. >=20 > I'd like to thank the working group, and especially the editors, > Mark Davis, Doug Ewell, and Addison Phillips, for their hard > work, constructive comments, and patience during this effort. >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 14:40:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56Mr-0004dE-PV; Tue, 16 Aug 2005 14:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56Mp-0004bt-7Y for ltru@megatron.ietf.org; Tue, 16 Aug 2005 14:40:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27930 for ; Tue, 16 Aug 2005 14:40:53 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56wB-0000uT-Gy for ltru@ietf.org; Tue, 16 Aug 2005 15:17:29 -0400 Received: from h-68-165-6-190.snvacaid.dynamic.covad.net ([68.165.6.190] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E56Ml-0000NC-00 for ltru@ietf.org; Tue, 16 Aug 2005 14:40:51 -0400 Message-ID: <005e01c5a292$3ab6a360$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.2.1.2.2.20050816165420.04bc4910@pop.online.fr> Subject: Re: [Ltru] WGLC security considerations Date: Tue, 16 Aug 2005 11:42:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This appears to be related to rejected issue issue tracker (https://rt.psg.com/ user and password "ietf") issue #966. Rather than artificially re-opening the WG last call, I suggest that if the poster believes strongly that this is important, it can be submitted as an IETF last call comment. In the meantime, the WG of course is free to determine whether there is merit to this comment, in order to minimize the time required to process the potential IETF last call comment, if it is made. That way, if necessary, we can include an appropriate note to the IESG in our publication request. Randy, ltru co-chair ----- Original Message ----- > From: "Jefsey Morfin" > To: > Sent: Tuesday, August 16, 2005 9:57 AM > Subject: [Ltru] WGLC security considerations > > The current text in security section says: > > "Language tags used in content negotiation, like any other information > exchanged on the Internet, might be a source of concern because they might > be used to infer the nationality of the sender, and thus identify potential > targets for surveillance." > > The concern of security is only related in this text to the sending host - > which is the least threat since it may be identified in many other ways. > This text does not consider the intelligence which may be gathered on the > receiver and the impact on the content. > > I think the following text would be more appropriate: > > "Language tags used in content negotiation, or in many other circumstances, > like any other information exchanged on the Internet, might be a source of > concern because they might be used to infer the nationality of the sender, > the interest of the receiver, the nature of the content and thus identify, > help select potential targets for surveillance, gather statistics, > information and intelligence on users and community exchanges, censor > contents, block access to information and knowledge, fight national > cultures, in particular in using OPES, etc." > > jfc > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 14:43:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56Pi-0005T2-7a; Tue, 16 Aug 2005 14:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56Pf-0005Su-VT for ltru@megatron.ietf.org; Tue, 16 Aug 2005 14:43:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28071 for ; Tue, 16 Aug 2005 14:43:50 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56z3-0000z4-3f for ltru@ietf.org; Tue, 16 Aug 2005 15:20:26 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 11:43:40 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 11:43:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] WGLC security considerations Date: Tue, 16 Aug 2005 11:43:38 -0700 Message-ID: Thread-Topic: [Ltru] WGLC security considerations Thread-Index: AcWig/vcrekOzHs1RFS5RAPJGrwLcgAB+wwg From: "Peter Constable" To: X-OriginalArrivalTime: 16 Aug 2005 18:43:40.0850 (UTC) FILETIME=[6BDD0920:01C5A292] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On Behalf Of > Jefsey Morfin > The concern of security is only related in this text to the sending = host - > which is the least threat since it may be identified in many other = ways. While I agree that there is greater concern in content negotiation in = relation to the requester than the provider, "sender" in this case may = be either party: the requester sends a request that includes a = particular language tag, and the provider sends a response (a = negotiation header or content) that includes a language tag. > This text does not consider the intelligence which may be gathered on = the > receiver and the impact on the content. True, inferences might also be made about the receiver. > I think the following text would be more appropriate: I'd be open to a change along the lines suggested.=FD I don't think a = change is essential for completion of this milestone, though. I agree = with Randy's recent comment that will always be improvements that can be = made, and we just need to cut things off at some point. =FDIf there are = other changes pending, I'd suggest the text below. If there are no other = =FDchanges to be made, however, I'd suggest the following text be used = for revision in =FD=FD3066ter.=FD =FD"Like any other information exchanged on the Internet, language tags = exchanged with content or in content negotiation may present a security = risk to the extent that they might be =FDused to infer information about = the sender or receiver. Specifically, they may be used to infer = linguistic, ethnic or national identity of users, or the interests of = users or content providers. They could be used as a basis for selecting = targets of information gathering, for controlling information exchange = for political or other such purposes, or for other actions outside of = the network context." Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 14:54:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56aK-0007cZ-Qn; Tue, 16 Aug 2005 14:54:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56aI-0007cO-Je for ltru@megatron.ietf.org; Tue, 16 Aug 2005 14:54:50 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28470 for ; Tue, 16 Aug 2005 14:54:48 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E56YQ-00037v-37 for ltru@lists.ietf.org; Tue, 16 Aug 2005 20:52:54 +0200 Received: from c-180-160-118.hh.dial.de.ignite.net ([62.180.160.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 20:52:54 +0200 Received: from nobody by c-180-160-118.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 20:52:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 16 Aug 2005 20:50:08 +0200 Organization: Lines: 19 Message-ID: <43023560.6123@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BCD8@irvmbxw01.quest.com> <43022D3D.4436@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-118.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > extlang = *2("-" 3ALPHA) ("-" ( 3ALPHA / "*")) [...] > extlang = *3("-" 3ALPHA) > / ( *2("-" 3ALPHA) "-*" ) Oops, there is a major difference, the latter can be empty, and then the square brackets would be in fact unnecessary in both grammars as Kent and you said. Still okay to keep them. For Kent's other vision "as similar a possible" the latter is better, it preserves "can be empty". Switching to hardcore nitpicking mode, what we really want is square brackets combined with 1*3( "-" 3ALPHA ) instead of *3( "-" 3ALPHA ) in the registry draft => "never empty". If "somehow" this "missing" 1 "appears" after your AUTH48 in 3066bis it would be a major step forward for humankind and the "lilly-guild" (not talking about Bruce). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 15:03:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56it-0000V6-MW; Tue, 16 Aug 2005 15:03:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56is-0000Uy-4k for ltru@megatron.ietf.org; Tue, 16 Aug 2005 15:03:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28941 for ; Tue, 16 Aug 2005 15:03:38 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E57ID-0001SH-Co for ltru@ietf.org; Tue, 16 Aug 2005 15:40:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 12:03:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] WGLC security considerations Date: Tue, 16 Aug 2005 12:03:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BE5A@irvmbxw01.quest.com> Thread-Topic: [Ltru] WGLC security considerations Thread-Index: AcWig/vcrekOzHs1RFS5RAPJGrwLcgAB+wwgAAH0XwA= From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 16 Aug 2005 19:03:23.0072 (UTC) FILETIME=[2C85CC00:01C5A295] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I agree that "sender" is not the most specific term and that it is = possible to envision, for example, DoS attacks on a site because of its = content (and that such attacks might be automated based on language tags = at that site). But the more we add, the less and less clear the text = becomes. Enumerating the reasons for malfeasance doesn't strike me as a = worthwhile exercise; such a list cannot be complete in any event. The matching draft can be more explicit about this, since ranges and = tags naturally must dovetail for any kind of surveillance or attack. I would tend to suggest that, if there were actually a need to modify = the text (and I don't really think there is: there isn't much difference = in what I'm about the propose), that the change could be the rather = plain text suggested below (insertions vs. draft-11 between /* */): -- Language tags used in content negotiation, like any other information = exchanged on the Internet, might be a source of concern because they = might be used to infer /*, for example, information about the content or = about */ the nationality of the sender, and thus identify potential = targets for surveillance /* or attack */. -- Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: 2005?8?16? 11:44 > To: ltru@ietf.org > Subject: RE: [Ltru] WGLC security considerations >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of > > Jefsey Morfin >=20 > > The concern of security is only related in this text to the sending = host > - > > which is the least threat since it may be identified in many other = ways. >=20 > While I agree that there is greater concern in content negotiation in > relation to the requester than the provider, "sender" in this case may = be > either party: the requester sends a request that includes a particular > language tag, and the provider sends a response (a negotiation header = or > content) that includes a language tag. >=20 >=20 > > This text does not consider the intelligence which may be gathered = on > the > > receiver and the impact on the content. >=20 > True, inferences might also be made about the receiver. >=20 >=20 > > I think the following text would be more appropriate: >=20 > I'd be open to a change along the lines suggested.=FD I don't think a = change > is essential for completion of this milestone, though. I agree with > Randy's recent comment that will always be improvements that can be = made, > and we just need to cut things off at some point. =FDIf there are = other > changes pending, I'd suggest the text below. If there are no other = =FDchanges > to be made, however, I'd suggest the following text be used for = revision > in =FD=FD3066ter.=FD >=20 >=20 > =FD"Like any other information exchanged on the Internet, language = tags > exchanged with content or in content negotiation may present a = security > risk to the extent that they might be =FDused to infer information = about the > sender or receiver. Specifically, they may be used to infer = linguistic, > ethnic or national identity of users, or the interests of users or = content > providers. They could be used as a basis for selecting targets of > information gathering, for controlling information exchange for = political > or other such purposes, or for other actions outside of the network > context." >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 15:09:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56o7-000102-NI; Tue, 16 Aug 2005 15:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56o6-0000za-B6 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 15:09:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29480 for ; Tue, 16 Aug 2005 15:09:04 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E57NR-0001a3-Ja for ltru@ietf.org; Tue, 16 Aug 2005 15:45:40 -0400 Received: from h-68-165-6-190.snvacaid.dynamic.covad.net ([68.165.6.190] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E56ns-00013T-00 for ltru@ietf.org; Tue, 16 Aug 2005 15:08:52 -0400 Message-ID: <008201c5a296$24dd3c80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C72BCD8@irvmbxw01.quest.com><43022D3D.4436@xyzzy.claranet.de> <43023560.6123@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Date: Tue, 16 Aug 2005 12:10:18 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Rather than artificially re-opening the WG last call, I suggest that if the poster believes strongly that this is important, it can be submitted as an IETF last call comment. In the meantime, the WG of course is free to determine whether there is merit to this comment, in order to minimize the time required to process the potential IETF last call comment, if it is made. That way, if necessary, we can include an appropriate note to the IESG in our publication request. Randy, ltru co-chair > From: "Frank Ellermann" > To: > Sent: Tuesday, August 16, 2005 11:50 AM > Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft > > > extlang = *2("-" 3ALPHA) ("-" ( 3ALPHA / "*")) > [...] > > extlang = *3("-" 3ALPHA) > > / ( *2("-" 3ALPHA) "-*" ) > > Oops, there is a major difference, the latter can be empty, > and then the square brackets would be in fact unnecessary > in both grammars as Kent and you said. Still okay to keep > them. For Kent's other vision "as similar a possible" the > latter is better, it preserves "can be empty". > > Switching to hardcore nitpicking mode, what we really want > is square brackets combined with 1*3( "-" 3ALPHA ) instead > of *3( "-" 3ALPHA ) in the registry draft => "never empty". > > If "somehow" this "missing" 1 "appears" after your AUTH48 > in 3066bis it would be a major step forward for humankind > and the "lilly-guild" (not talking about Bruce). Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 15:12:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56r2-0001xe-1i; Tue, 16 Aug 2005 15:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56r0-0001vR-PV for ltru@megatron.ietf.org; Tue, 16 Aug 2005 15:12:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29741 for ; Tue, 16 Aug 2005 15:12:04 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E57QP-0001d8-1a for ltru@ietf.org; Tue, 16 Aug 2005 15:48:41 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 12:11:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Date: Tue, 16 Aug 2005 12:11:56 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BE6B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Thread-Index: AcWilh+QyrBAxflhTr2LE4X/8JmbhwAACAPQ From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 16 Aug 2005 19:11:57.0097 (UTC) FILETIME=[5EE7C990:01C5A296] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I don't think it makes a difference to the registry draft. We might = change the matching draft (which is not covered by the closure of the = last call and the topic of this thread). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: 2005?8?16? 12:10 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft >=20 > Hi - >=20 > Rather than artificially re-opening the WG last call, I suggest that = if > the > poster believes strongly that this is important, it can be submitted > as an IETF last call comment. In the meantime, the WG of course > is free to determine whether there is merit to this comment, in > order to minimize the time required to process the potential IETF > last call comment, if it is made. That way, if necessary, we can > include an appropriate note to the IESG in our publication request. >=20 > Randy, ltru co-chair >=20 > > From: "Frank Ellermann" > > To: > > Sent: Tuesday, August 16, 2005 11:50 AM > > Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft > > > > > extlang =3D *2("-" 3ALPHA) ("-" ( 3ALPHA / "*")) > > [...] > > > extlang =3D *3("-" 3ALPHA) > > > / ( *2("-" 3ALPHA) "-*" ) > > > > Oops, there is a major difference, the latter can be empty, > > and then the square brackets would be in fact unnecessary > > in both grammars as Kent and you said. Still okay to keep > > them. For Kent's other vision "as similar a possible" the > > latter is better, it preserves "can be empty". > > > > Switching to hardcore nitpicking mode, what we really want > > is square brackets combined with 1*3( "-" 3ALPHA ) instead > > of *3( "-" 3ALPHA ) in the registry draft =3D> "never empty". > > > > If "somehow" this "missing" 1 "appears" after your AUTH48 > > in 3066bis it would be a major step forward for humankind > > and the "lilly-guild" (not talking about Bruce). Bye, Frank > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 15:15:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56tp-0002Fx-3Y; Tue, 16 Aug 2005 15:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56tm-0002Fm-Vj for ltru@megatron.ietf.org; Tue, 16 Aug 2005 15:14:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29979 for ; Tue, 16 Aug 2005 15:14:57 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E57TA-0001gn-Gn for ltru@ietf.org; Tue, 16 Aug 2005 15:51:33 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 12:14:40 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 12:14:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ltru] WGLC security considerations Date: Tue, 16 Aug 2005 12:14:38 -0700 Message-ID: Thread-Topic: Re: [Ltru] WGLC security considerations Thread-Index: AcWig/vcrekOzHs1RFS5RAPJGrwLcgAB+wwgAAHws/AAAMJUUA== From: "Peter Constable" To: X-OriginalArrivalTime: 16 Aug 2005 19:14:40.0542 (UTC) FILETIME=[C05383E0:01C5A296] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I sent my previous msg before seeing Randy's notice regarding closure of the WG last call. (I actually started writing it earlier, but was interrupted.) I do not wish to see the WG last call re-opened. I would be open to the revision I've suggested during the IETF last call. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 15:15:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56u4-0002Qj-Hi; Tue, 16 Aug 2005 15:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56u3-0002QX-0z for ltru@megatron.ietf.org; Tue, 16 Aug 2005 15:15:15 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00018 for ; Tue, 16 Aug 2005 15:15:12 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E56s1-00081H-Ru for ltru@lists.ietf.org; Tue, 16 Aug 2005 21:13:09 +0200 Received: from c-180-160-118.hh.dial.de.ignite.net ([62.180.160.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 21:13:09 +0200 Received: from nobody by c-180-160-118.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Aug 2005 21:13:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 16 Aug 2005 21:11:56 +0200 Organization: Lines: 17 Message-ID: <43023A7C.413D@xyzzy.claranet.de> References: <6.2.1.2.2.20050816165420.04bc4910@pop.online.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-118.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: WGLC security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Jefsey Morfin wrote: > I think the following text would be more appropriate: [...] The shorter version addresses the main issue more precisely. Your longer proposal is too broad, it covers more than only language tags, it's applicable to most kinds of information exchange. Putting vague threats related to many kinds of communication - not only language tags - in the "security considerations" would be a bad idea. We were supposed to identify _specific_ risks. not _general_ issues. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 15:17:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56w1-0002bJ-NF; Tue, 16 Aug 2005 15:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56w0-0002b8-FD for ltru@megatron.ietf.org; Tue, 16 Aug 2005 15:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00177 for ; Tue, 16 Aug 2005 15:17:14 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E57VM-0001jW-20 for ltru@ietf.org; Tue, 16 Aug 2005 15:53:48 -0400 Received: from h-68-165-6-190.snvacaid.dynamic.covad.net ([68.165.6.190] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E56vv-0003kI-00 for ltru@ietf.org; Tue, 16 Aug 2005 15:17:11 -0400 Message-ID: <008901c5a297$4e077480$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] WGLC security considerations Date: Tue, 16 Aug 2005 12:17:41 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Peter Constable" > To: > Sent: Tuesday, August 16, 2005 11:43 AM > Subject: RE: [Ltru] WGLC security considerations ... > ý"Like any other information exchanged on the Internet, language tags exchanged with > content or in content negotiation may present a security risk to the extent that they might > be ýused to infer information about the sender or receiver. Specifically, they may be used ... As a technical contributor, I strongly object to the addition of such text. The receipt of a language tag permits no inferences about the recipient. If I were to start posting to this list in, for example, Vietnamese, it would not support any inferences about the other members of this list unless someone were to respond in Vietnamese, in which case the inference would be about another sender, not a receiver. If security considerations need to include things like "attackers may draw unfounded conclusions from a monitored stream", we've gone to a truly surreal threat model. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 15:59:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57ah-0001BE-IC; Tue, 16 Aug 2005 15:59:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57ag-0001B9-NW for ltru@megatron.ietf.org; Tue, 16 Aug 2005 15:59:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02937 for ; Tue, 16 Aug 2005 15:59:16 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58A4-00035l-Nh for ltru@ietf.org; Tue, 16 Aug 2005 16:35:54 -0400 X-Medic-Info: 7f9.4302458d.0 elUBQy0CyKMMzayw Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 6F141446F for ; Tue, 16 Aug 2005 21:59:09 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Tue, 16 Aug 2005 21:59:09 +0200 (CEST) Message-ID: <64030.83.248.26.202.1124222349.squirrel@webmail.chalmers.se> In-Reply-To: <43023560.6123@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BCD8@irvmbxw01.quest.com><43022D3D.4436@xyzzy.claranet.de> <43023560.6123@xyzzy.claranet.de> Date: Tue, 16 Aug 2005 21:59:09 +0200 (CEST) Subject: Re: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft From: "Kent Karlsson" To: ltru@ietf.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank got the analysis of my message right. Yes, I want the grammars as similar as ever possible, but still combinable. Frank is also right about the [] and emptyness possibility. B.t.w. I don't like the term "range" for something that is more like what is usually called a "pattern". Further, in a language tag pattern like sr-* there is no way of telling if the * stands for "any 'extended language'", "any script", "any region", or "any variant". But for sr-*-Cyrl the * stands for "any 'extended language'". While in sr-*-1900 the * may stand for "any 'extended language'", "any script", or "any region". (But not combined?) Does this matter? Or are the patterns on purpose ambiguous? If not, the different kinds of wildcards need differing syntax, e.g. a script wildcard could be *s, and a region wildcard could be *r (or whatever other differing syntax strikes your fancy). /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 16:46:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58KB-0006Ps-UL; Tue, 16 Aug 2005 16:46:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58K6-0006Oq-4Z for ltru@megatron.ietf.org; Tue, 16 Aug 2005 16:46:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11675 for ; Tue, 16 Aug 2005 16:46:09 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58tS-0006e7-0i for ltru@ietf.org; Tue, 16 Aug 2005 17:22:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 13:45:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Date: Tue, 16 Aug 2005 13:45:53 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C72BF74@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Thread-Index: AcWinxt6NcCE7dAYR/Sx7eEjCQlVNQAAKQZA From: "Addison Phillips" To: "Kent Karlsson" , X-OriginalArrivalTime: 16 Aug 2005 20:45:54.0450 (UTC) FILETIME=[7F079720:01C5A2A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org RTFID (read the fine internet-draft). The name "range" is not our invention. It has existed for quite some = time in RFCs 1766 and 3066. Renaming it to pattern would likely confuse = existing users? The matching draft spells out what various kinds of range such as "sr-*" = mean.=20 The ranges are not ambiguous; the different matching schemes, however, = treat some missing values differently. It is the case that ranges have an in-built preference for = remove-from-right matching and that there is no way to say "en-US (no = script) but not en-xxxx-US (any script)". The matching draft is not as = mature as the other work here, and comments and ideas I think are very = much welcome. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Kent Karlsson > Sent: 2005?8?16? 12:59 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft >=20 >=20 > Frank got the analysis of my message right. >=20 > Yes, I want the grammars as similar as ever possible, > but still combinable. Frank is also right about the > [] and emptyness possibility. >=20 > B.t.w. I don't like the term "range" for something > that is more like what is usually called a "pattern". >=20 > Further, in a language tag pattern like >=20 > sr-* >=20 > there is no way of telling if the * stands for > "any 'extended language'", "any script", "any region", > or "any variant". >=20 > But for >=20 > sr-*-Cyrl >=20 > the * stands for "any 'extended language'". >=20 > While in >=20 > sr-*-1900 >=20 > the * may stand for "any 'extended language'", > "any script", or "any region". (But not combined?) >=20 >=20 > Does this matter? Or are the patterns on purpose ambiguous? > If not, the different kinds of wildcards need differing syntax, > e.g. a script wildcard could be *s, and a region wildcard could > be *r (or whatever other differing syntax strikes your fancy). >=20 > /kent k >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 16:51:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58Os-0007Md-JJ; Tue, 16 Aug 2005 16:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58On-0007Lx-13 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 16:51:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11848 for ; Tue, 16 Aug 2005 16:51:02 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58yA-0006kt-Eg for ltru@ietf.org; Tue, 16 Aug 2005 17:27:40 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 13:50:53 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 13:50:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] WGLC security considerations Date: Tue, 16 Aug 2005 13:50:44 -0700 Message-ID: Thread-Topic: [Ltru] WGLC security considerations Thread-Index: AcWil3ob/zX7broGR12Xd/qqIbORmQACjjKQ From: "Peter Constable" To: X-OriginalArrivalTime: 16 Aug 2005 20:50:53.0352 (UTC) FILETIME=[31306A80:01C5A2A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > As a technical contributor, I strongly object to the addition of such text. > The receipt of a language tag permits no inferences about the recipient. One cannot make a valid logical deduction, but one can certainly infer anything one wants to infer -- in the sense of merely drawing a conclusion (valid or not). See the fourth sense below: in*fer: =20 1. vti conclude something on the basis of reasoning: to conclude something on the basis of evidence or reasoning =20 2. vt suggest: to suggest or lead to something as a conclusion =20 3. vt imply: to imply or suggest something =20 4. vt guess something: to make a reasonable guess at something =20 The point is, if I discover that party X is receiving Vietnamese content, I may choose to conclude on that basis alone that X is Vietnamese and take actions based on that. To the extent that one cannot validly deduce anything about a recipient, the same is true of a sender: just because X sends out Vietnamese content doesn't tell us for certain that X is Vietnamese. X may be sending Vietnamese content for any number of reasons. Again, the point is that someone may choose to draw conclusions about X on that basis alone and take actions based on that. > If security considerations need to include things like "attackers may draw > unfounded conclusions from a monitored stream", we've gone to a truly > surreal threat model. Well, on that basis, perhaps we might as well revert to what RFC 1766 had to say about security: 6. Security Considerations Security issues are not discussed in this memo. :-) Actually, a better course would be to say: - nothing can be deduced with certainty about sender or receiver - nevertheless, some might make assumptions about sender or receiver and on that basis engage in targeted information gathering or attack Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 16:57:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58Us-0000V5-6s; Tue, 16 Aug 2005 16:57:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58Uq-0000V0-N6 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 16:57:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12071 for ; Tue, 16 Aug 2005 16:57:17 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E594E-0006u0-Tx for ltru@ietf.org; Tue, 16 Aug 2005 17:33:56 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 13:57:09 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 13:57:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Date: Tue, 16 Aug 2005 13:57:06 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Thread-Index: AcWinxt6NcCE7dAYR/Sx7eEjCQlVNQAAKQZAAAEgxhA= From: "Peter Constable" To: X-OriginalArrivalTime: 16 Aug 2005 20:57:09.0503 (UTC) FILETIME=[116480F0:01C5A2A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > The name "range" is not our invention. It has existed for quite some time in RFCs > 1766 and 3066. Renaming it to pattern would likely confuse existing users? Absolutely. Moreover, that term is used in dependent protocol specifications such as HTTP (RFC 2616 and its precursors). Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 17:57:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59Qx-0005Kq-Do; Tue, 16 Aug 2005 17:57:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59Qw-0005Ki-1V for ltru@megatron.ietf.org; Tue, 16 Aug 2005 17:57:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14768 for ; Tue, 16 Aug 2005 17:57:19 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5A0M-0008SL-2B for ltru@ietf.org; Tue, 16 Aug 2005 18:33:58 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E59Qq-00058p-CK for ltru@ietf.org; Tue, 16 Aug 2005 14:57:16 -0700 Message-Id: <6.2.1.2.2.20050816224041.05601450@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 16 Aug 2005 23:57:13 +0200 To: ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] LTRU Milestones past due Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org [sorry: I sent it by mistake without copying the WG] On 23:02 15/08/2005, Randy Presuhn said: >I hope not, but we're not going to get there until this WG decides >that the drafts are good enough to request publication. The current >discussion of ABNF changes worries me that we might be on the >verge of needing a third WG last call, though that decision is up >to the co-chairs' discretion. Dear Randy, oh! may be your mouth could advise your ears? >As a technical contributor, I think we passed the point of diminishing >returns some time ago. I've been in standards long enough to realize >that any non-trivial specification will probably have errors and benefit >from clearer text, but I've also seen too many documents where too >much time has been spent on items that really have no impact at all >on the interoperability of implementations. Exact. This applies to the whole document. >The WG needs to ask itself: > - are the procedures for running the registry sufficiently clear so > that IANA will be able to carry them out? > - are the procedures for requesting the registration of new tags > sufficiently clear so that registrants will be able to provide the > necessary information to ietf-languages@iana.org? > - is the syntax and semantics of language tags sufficiently well > specified to address the requirements stated in the WG charter? > >I believe the answer to all of these is "yes", and has been for quite >some time. I like your intox. The response is "no" for them all, with different rationales. All these rationales root however in the same initial disregard of the Charter. There are obviously many ways to document this position of mine you will have to explain to the IESG. I note that no one has commented yet my last remark about oral aspects. The debate at ietf-languages@alvestrand.no over the differences between Alsace and Lichenstein shown that the reviewers have difficulties with this non written languages or oral forms of written languages. May be should we complete Michael Everson with Pavarotti and George Lucas? These points might be better discussed by this WG before becoming endless IETF issues? >As a co-chair, though we can set deadlines for WG last calls, if the >WG decides to address some in-scope issue, it is better in my >opinion to deal with it in the WG last call, rather than risk its resurrection >in IETF last call, Agreed. But the second IETF Last Call permitted to add thousands of characters to the Draft and to better constrain the ABNF to oppose Open Source. IMHI (imagination) a forth Last Call is necessary: Open Source and users still have many ways to circumvent the Draft and create confusion (I know a few: but if you ban me for lack of cooperation in not documenting them, you will not get them). The assistance of the whole IETF is necessary to think of them. > even if in my technical judgement the issue does >not warrant the delay. Of course, by dallying like this, we run the risk >that our ADs might shut us down for failure to meet our milestones. Oh! do not worry. IDNA took more time! This kind of inadequate pre-decided proposition by nature takes time to build. If they were adequate and open everyone would see it and agree far more quickly (or disband). >I've seen this happen in the Operations & Management area, so >I know that this is not merely a theoretical possibility. Randy, in Operations & Management area - as you told us - they are also managed by a Draft which does not evaluate the deliverable of a WG in reference to its Charter. May be could we consider our area, our charter, our duty to the IETF and to the users. And try to make a good job. Right now the responsibility of the delays is due to the way this WG has worked until now. Had we started with a clean sheet review of the Charter, decided in common of objectives and of a road map, asked the necessary IAB guidance over the many thorny points resulting of confusion between an ISO typographer and a multimedia, multimode and multinlingual network architecture approaches, with the assistance of the key missing members to document the users and protocols needs, and some consideration to ISO/TC32 work, I am not sure we would have not closed a multilingual internet framework BCP 47 a long ago. But I am sure that before the IANA supports a change in the BCP 47 registry which is universally used by the Internet community, it will have to become simple, stupid, consistent with many other network aspects, multilingual, multimedia, multimode, network and architext oriented and most of all based upon a user-centric archtecture of usage - and to stop endangering users as documented in its security section. The Draft is a client/server timesharing 1974 approach. It still documents the way the server "speaks". Not even the way the client reads or program. And certainly not the way the users interculturally exchange and relate. This WG met its milestones: it stumbled over them. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 18:44:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AAJ-00086b-On; Tue, 16 Aug 2005 18:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AAH-00086S-Nc for ltru@megatron.ietf.org; Tue, 16 Aug 2005 18:44:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17892 for ; Tue, 16 Aug 2005 18:44:10 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Ajh-00013w-5T for ltru@ietf.org; Tue, 16 Aug 2005 19:20:50 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E5AAF-0004ML-2i for ltru@ietf.org; Tue, 16 Aug 2005 15:44:11 -0700 Message-Id: <6.2.1.2.2.20050817004329.0560c460@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 17 Aug 2005 00:44:07 +0200 To: ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: WGLC security considerations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 21:11 16/08/2005, Frank Ellermann said: >Jefsey Morfin wrote: > > I think the following text would be more appropriate: >[...] > >The shorter version addresses the main issue more precisely. > >Your longer proposal is too broad, it covers more than only >language tags, it's applicable to most kinds of information >exchange. > >Putting vague threats related to many kinds of communication >- not only language tags - in the "security considerations" >would be a bad idea. We were supposed to identify _specific_ >risks. not _general_ issues. Dear Frank, The specific risks due to the language tags are numerous. I will identify three of them: - risk of confusion as they introduce non network related information where network related information is needed. This risk is structural and may substantially delay the architectural development of the Internet due to its probable support by dominant actors. I doubt the authors will document it. This is the main risk I fight in opposing their Draft. - individual risks on content (filtering, censoring, etc.) and on persons (identification, privacy violation, etc.). This kind of risk is never absolute: it lies in its increase. There is a difference between sending an information on a post card and in a letter under envelope because opening all the envelopes costs time and money. Language tags greatly simplifies the intelligence gathering, filtering, spying, censoring ... and their errors. Not considering language tags in OPES context for example is big mistake. But the main issue is that the user cannot turn it down. (NB. This risks could have been greatly reduced through flexible "x-tags" and "0-" escape sequence. I have no doubt people will die and suffer because of the ABNF. Standardisation is also a risky activity.) - global risks. Let say the "9am-5pm" orientation of the Draft is well known and will be increasingly known. The irritation resulting from the limitations to cultural lifes and innovation all over the world this draft will lead to, and the probable impact on IANA and IETF image, may be a direct or indirect triggering factor in many nasty events to come (I am sure you do not need I dwell on that point). The chances of this risk have decreased. The ABNF rigidity against our Open Source/Standard proposition, the resulting delays in excluding us, the exposure of the commercial interests involved will most probably now lead the WSIS Internet Governance Forum to take over the issue. A related risk would be that all this would delay a serious Internet Multilingual Framework. This is a matter on which we now actively work. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 18:49:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AEv-0000Mu-L3; Tue, 16 Aug 2005 18:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AEr-0000MY-Sf for ltru@megatron.ietf.org; Tue, 16 Aug 2005 18:49:00 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18105 for ; Tue, 16 Aug 2005 18:48:53 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E5AEa-0004rg-4F for ltru@lists.ietf.org; Wed, 17 Aug 2005 00:48:40 +0200 Received: from du-001-121.access.de.clara.net ([212.82.227.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Aug 2005 00:48:40 +0200 Received: from nobody by du-001-121.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Aug 2005 00:48:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 17 Aug 2005 00:43:27 +0200 Organization: Lines: 53 Message-ID: <43026C0F.5311@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C72BCD8@irvmbxw01.quest.com><43022D3D.4436@xyzzy.claranet.de> <43023560.6123@xyzzy.claranet.de> <64030.83.248.26.202.1124222349.squirrel@webmail.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-121.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Kent Karlsson wrote: > in a language tag pattern like > sr-* > there is no way of telling if the * stands for > "any 'extended language'", "any script", "any region", > or "any variant". > But for > sr-*-Cyrl > the * stands for "any 'extended language'". > While in > sr-*-1900 > the * may stand for "any 'extended language'", > "any script", or "any region". (But not combined?) > Does this matter? Yes, the matching draft has to say what this means. We have three choices: left-to-right, the -*- would be for extended language in all your examples. left-to-right plus default -*-. With that approach we get sr-* = sr-*-*-*-*, dito sr-*-CYRL = sr-*-CYRL-*-*, dito sr-*-1900 = sr-*-*-*-1900 default -*-, then we get sr = sr-* and sr = sr-*-*-*-*, so sr-* is pointless, the same as sr (?!?) Reflecting the intended semantics in syntax could be a PITA, but it has to be done at least in prose. Addison said "RTFID", I do that later, maybe it's already clear. > a script wildcard could be *s, and a region wildcard > could be *r (or whatever other differing syntax strikes > your fancy). We're not supposed to update the HTTP RfC, so that could be difficult or impossible. With 3066, was it ever allowed or possible to have more than one -*- in a range ? If not, was it ever possible or allowed to have a -*- within a range (not at the end) ? If a * or -* was always at the end (and at most one) the project "matching-draft" could be really tricky. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 19:09:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AYk-0005Fj-JI; Tue, 16 Aug 2005 19:09:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AYj-0005EM-92 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 19:09:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19471 for ; Tue, 16 Aug 2005 19:09:25 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5B88-0001hl-SO for ltru@ietf.org; Tue, 16 Aug 2005 19:46:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 16:09:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Date: Tue, 16 Aug 2005 16:09:13 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C815FD0@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Thread-Index: AcWitN7XjcZrOv7fS36a2tNFHuTHkAAAGeJA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 16 Aug 2005 23:09:14.0279 (UTC) FILETIME=[84ED5B70:01C5A2B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Maybe a summary is in order. There are three matching schemes currently. The one in HTTP is called "Basic Matching" and uses a Basic Language = Range. A Basic Language Range is either "*" or a specific tag ("fr-CA"). = Wildcards are not permitted in a language range (that is, "fr-*" is = illegal). The ABNF for this is simple: Range =3D Tag / "*" Thus: > With 3066, was it ever allowed or possible to have more > than one -*- in a range ? If not, was it ever possible > or allowed to have a -*- within a range (not at the end) ? It wasn't possible to have ANY stars in a range. Either the range is = star or it is a prefix. "Extended Ranges" are the ones that can contain a mix of subtags and = wildcards and for which a more complex ABNF exists that Kent is = commenting on. They are an innovation coupled with draft-registry. In this scheme, there is a difference between "sr" and "sr-*". A tag = that ends with a concrete (non-wildcard) subtag must end with exactly = that subtag. Thus "sr" matches exactly one tag: "sr", while "sr-*" = matches a plethora of tags (all the ones that start with "sr", including = "sr"). This subtlety allows one to be specific: "en-US" matches many tags, but = never "en-US-boont". Kent and others might question why there is no need to have separate = wildcards (that is, why we allow the fields to be collapsed). There is a = simple reason for this: the subtags in an RFC 3066bis language tag (and = thus a range) are distinguishable by length and content. Any concrete = subtag that appears in a range is self-identifying. Thus users need not = be bothered with counting the stars. An open question is whether omitting a star should or should not match a = given tag (that is, whether "fr-CA" matches "fr-Brai-CA"). The draft = currently says that it does. The last form of matching is something called "scored matching". In that = scheme, each field must be specified, either with a subtag or a = wildcard. > If a * or -* was always at the end (and at most one) the > project "matching-draft" could be really tricky. Which is why it says the opposite. I hope this summary helps. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 >=20 > If a * or -* was always at the end (and at most one) the > project "matching-draft" could be really tricky. >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 19:11:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ab6-00060a-3Z; Tue, 16 Aug 2005 19:11:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ab5-0005z5-3e for ltru@megatron.ietf.org; Tue, 16 Aug 2005 19:11:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19626 for ; Tue, 16 Aug 2005 19:11:51 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5BAU-0001ln-UC for ltru@ietf.org; Tue, 16 Aug 2005 19:48:32 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E5Ab2-0000IY-91; Tue, 16 Aug 2005 16:11:52 -0700 Message-Id: <6.2.1.2.2.20050817004910.031432e0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 17 Aug 2005 01:11:49 +0200 To: "Randy Presuhn" From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org Subject: [Ltru] appeal intent report to ADs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Randy, you have adopted a procedure which makes you (or Martin) to report the ADs the documented motives of the appeals I announced, should the IETF Last Call lead to a positive IESG decision, regarding the Draft you made proposed by Addison Philips and Mark Davis. I am certainly ready to help reviewing this report, so the AD get a complete and clear picture. This may be an occasion for clarifications, and to agree on our disagreements. I think that this Draft would deeply harm the Internet should it continue to claim being a BCP documenting an exclusive global Internet language tagging. But I also think that if this Draft brings a transitional response to specific needs, it must go through as a standard track specific document (having not studied the Charter in common, I trusted blindly Addison on this until he said he did not spoke on behalf the W3C: this is the reason of my "if"). In such a case both the Internet standard process and the anti-open standard ABNF provisions parts should obviously be removed as out of the new scope. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 19:23:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Alt-0008Ed-Hc; Tue, 16 Aug 2005 19:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Alt-0008EY-22 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 19:23:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20127 for ; Tue, 16 Aug 2005 19:23:01 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5BLJ-00021p-Pe for ltru@ietf.org; Tue, 16 Aug 2005 19:59:42 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 16:22:55 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 16:22:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: WGLC security considerations Date: Tue, 16 Aug 2005 16:22:54 -0700 Message-ID: Thread-Topic: [Ltru] Re: WGLC security considerations Thread-Index: AcWitCCDIXoHBzX3TZ66tP3w3oHKpgAA/paA From: "Peter Constable" To: X-OriginalArrivalTime: 16 Aug 2005 23:22:55.0166 (UTC) FILETIME=[6E36C5E0:01C5A2B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC appears to be using this thread as an excuse to open up various topics on which he has a personal ax to grind. I wish to dissociate my qualified support for his original issue regarding specific text in section 6 of the draft from his further input, which I find to be at best not particularly good arguments for change to that section and at worst wholly off topic. Also, given that the WG last call is closed, I have no interest in nor see any particular value in extending this thread. As mentioned earlier, I think certain improvements to section could be made but that they not essential and certainly not worth any further delay of this draft. Peter Constable > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of r&d > afrac > Sent: Tuesday, August 16, 2005 3:44 PM > To: ltru@ietf.org > Subject: Re: [Ltru] Re: WGLC security considerations >=20 > On 21:11 16/08/2005, Frank Ellermann said: > >Jefsey Morfin wrote: > > > I think the following text would be more appropriate: > >[...] > > > >The shorter version addresses the main issue more precisely. > > > >Your longer proposal is too broad, it covers more than only > >language tags, it's applicable to most kinds of information > >exchange. > > > >Putting vague threats related to many kinds of communication > >- not only language tags - in the "security considerations" > >would be a bad idea. We were supposed to identify _specific_ > >risks. not _general_ issues. >=20 > Dear Frank, > The specific risks due to the language tags are numerous. I will identify > three of them: >=20 > - risk of confusion as they introduce non network related information where > network related information is needed. This risk is structural and may > substantially delay the architectural development of the Internet due to > its probable support by dominant actors. I doubt the authors will document > it. This is the main risk I fight in opposing their Draft. >=20 > - individual risks on content (filtering, censoring, etc.) and on persons > (identification, privacy violation, etc.). This kind of risk is never > absolute: it lies in its increase. There is a difference between sending an > information on a post card and in a letter under envelope because opening > all the envelopes costs time and money. Language tags greatly simplifies > the intelligence gathering, filtering, spying, censoring ... and their > errors. Not considering language tags in OPES context for example is big > mistake. But the main issue is that the user cannot turn it down. (NB. This > risks could have been greatly reduced through flexible "x-tags" and "0-" > escape sequence. I have no doubt people will die and suffer because of the > ABNF. Standardisation is also a risky activity.) >=20 > - global risks. Let say the "9am-5pm" orientation of the Draft is well > known and will be increasingly known. The irritation resulting from the > limitations to cultural lifes and innovation all over the world this draft > will lead to, and the probable impact on IANA and IETF image, may be a > direct or indirect triggering factor in many nasty events to come (I am > sure you do not need I dwell on that point). The chances of this risk have > decreased. The ABNF rigidity against our Open Source/Standard proposition, > the resulting delays in excluding us, the exposure of the commercial > interests involved will most probably now lead the WSIS Internet Governance > Forum to take over the issue. >=20 > A related risk would be that all this would delay a serious Internet > Multilingual Framework. This is a matter on which we now actively work. > jfc >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 19:47:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5B9I-0004zU-CT; Tue, 16 Aug 2005 19:47:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5B9G-0004yy-8z for ltru@megatron.ietf.org; Tue, 16 Aug 2005 19:47:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23194 for ; Tue, 16 Aug 2005 19:47:12 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Big-0002rl-9f for ltru@ietf.org; Tue, 16 Aug 2005 20:23:51 -0400 Received: from h-68-165-6-190.snvacaid.dynamic.covad.net ([68.165.6.190] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5B95-0006hE-00 for ltru@ietf.org; Tue, 16 Aug 2005 19:47:03 -0400 Message-ID: <037401c5a2bc$feae14e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050817004910.031432e0@pop.online.fr> Date: Tue, 16 Aug 2005 16:48:25 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Ltru] Re: appeal intent report to ADs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - If you're planning to appeal an IESG decision, this WG isn't the place to do it. Section 6.5.2 of RFC 2026 makes the IAB responsible for handling such appeals. The report Martin and I are required to provide to our responsible AD is in anticipation of likely appeals of working group decisions, per section 6.5.1 of RFC 2026 and section 3.1 (1.f) of http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt I do suggest you take a look at section 5 of RFC 2026, as your understanding of the significance of the "BCP" designation doesn't appear to be supported by its definition there. Randy, ltru co-chair > From: "r&d afrac" > To: "Randy Presuhn" > Cc: "Scott Hollenbeck" ; > Sent: Tuesday, August 16, 2005 4:11 PM > Subject: appeal intent report to ADs > > Dear Randy, > you have adopted a procedure which makes you (or Martin) to report the ADs > the documented motives of the appeals I announced, should the IETF Last > Call lead to a positive IESG decision, regarding the Draft you made > proposed by Addison Philips and Mark Davis. I am certainly ready to help > reviewing this report, so the AD get a complete and clear picture. This may > be an occasion for clarifications, and to agree on our disagreements. > > I think that this Draft would deeply harm the Internet should it continue > to claim being a BCP documenting an exclusive global Internet language > tagging. But I also think that if this Draft brings a transitional response > to specific needs, it must go through as a standard track specific document > (having not studied the Charter in common, I trusted blindly Addison on > this until he said he did not spoke on behalf the W3C: this is the reason > of my "if"). In such a case both the Internet standard process and the > anti-open standard ABNF provisions parts should obviously be removed as out > of the new scope. > > jfc > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 21:05:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5CMW-0006EG-I5; Tue, 16 Aug 2005 21:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5CMU-0006EB-CN for ltru@megatron.ietf.org; Tue, 16 Aug 2005 21:04:58 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28049 for ; Tue, 16 Aug 2005 21:04:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E5CL9-0007Wr-OA for ltru@lists.ietf.org; Wed, 17 Aug 2005 03:03:35 +0200 Received: from du-001-121.access.de.clara.net ([212.82.227.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Aug 2005 03:03:35 +0200 Received: from nobody by du-001-121.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Aug 2005 03:03:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 17 Aug 2005 03:02:43 +0200 Organization: Lines: 12 Message-ID: <43028CB3.1EEF@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C815FD0@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-121.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I hope this summary helps. Yes, thanks. So we have sr-* == sr-*-*-*-*, as soon as there's one star it's for all available positions. Same idea for sr-*-1900 == sr-*-*-*-1900. But sr-*-CYRL and sr-*-CYRL-*-* are different, correct ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 22:14:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5DRl-0003JH-Ni; Tue, 16 Aug 2005 22:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5DRk-0003J9-R2 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 22:14:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00696 for ; Tue, 16 Aug 2005 22:14:25 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E5DQb-000421-CE for ltru@lists.ietf.org; Wed, 17 Aug 2005 04:13:17 +0200 Received: from du-001-121.access.de.clara.net ([212.82.227.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Aug 2005 04:13:17 +0200 Received: from nobody by du-001-121.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Aug 2005 04:13:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 17 Aug 2005 04:10:39 +0200 Organization: Lines: 54 Message-ID: <43029C9F.3510@xyzzy.claranet.de> References: <6.2.1.2.2.20050817004329.0560c460@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-121.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: WGLC security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org r&d afrac wrote: > The specific risks due to the language tags are numerous. I > will identify three of them: > - risk of confusion as they introduce non network related > information where network related information is needed. > This risk is structural In other words it's a feature and no bug, unavoidable, if an evil party wants to censor say "ARAB" they can (try to) do this. I could also do it for completely harmless reasons, because I cannot read this script. That's nothing new, everybody knows it, it's also applicable on charsets. Your concept of "non network related information" makes no sense for me. Language tags and / or charsets are "network related". > Language tags greatly simplifies the intelligence gathering, > filtering, spying, censoring ... and their errors. Yes, I know that risk since I tried to "spamcop" a mail from Martin because it had a 2047 subject with a Japanese charset. There are uses, abuses, and errors. Not very surprising, that is obvious. > Not considering language tags in OPES context for example is > big mistake. Let the OPES folks address it in their documents, it's not different from the situation as it is today (before 3066bis). > But the main issue is that the user cannot turn it down. Of course you can, nothing forces you to spell out say "TW" if you think that this might hurt the propagation to "CN". > I have no doubt people will die and suffer because of the > ABNF. Assuming that the "TW" example is dangerous, then using x-tw1 to "avoid" this risk is 1) allowed 2) won't help. The worst you can do for privacy and anonymity are _false_ promises. IIRC we had this discussion already. > Let say the "9am-5pm" orientation of the Draft is well known Then we'd get Harry Potter for a "ridiculus" spell, that will show them. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Aug 16 23:47:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5EtO-0004PW-6M; Tue, 16 Aug 2005 23:47:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5EtM-0004OQ-6o for ltru@megatron.ietf.org; Tue, 16 Aug 2005 23:47:04 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04596 for ; Tue, 16 Aug 2005 23:46:59 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050817034622.LXXW19267.mta10.adelphia.net@DEWELL>; Tue, 16 Aug 2005 23:46:22 -0400 Message-ID: <004c01c5a2de$3427f340$030aa8c0@DEWELL> From: "Doug Ewell" To: Date: Tue, 16 Aug 2005 20:46:07 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0049_01C5A2A3.871079A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Cc: LTRU Working Group Subject: [Ltru] Submission: LTRU initial-registry draft-04 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C5A2A3.871079A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear Editor, Attached please find the fifth draft of the LTRU initial-registry document, "draft-ietf-ltru-initial-04", in text format. This draft was generated from XML source using xml2rfc, and has been scanned with idnits. The XML source is available at http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-04.xml, or via e-mail on request. Best regards, -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ------=_NextPart_000_0049_01C5A2A3.871079A0 Content-Type: text/plain; name="draft-ietf-ltru-initial-04.txt" Content-Disposition: attachment; filename="draft-ietf-ltru-initial-04.txt" Content-Transfer-Encoding: quoted-printable LTRU D. Ewell, Ed. Internet-Draft August 16, 2005 Expires: February 17, 2006 Initial Language Subtag Registry draft-ietf-ltru-initial-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. Ewell Expires February 17, 2006 [Page 1] =0C Internet-Draft Initial Language Subtag Registry August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Initialization of the Registry . . . . . . . . . . . . . . . 4 3. Initial Registry Contents . . . . . . . . . . . . . . . . . . 7 4. Omitted Code Elements . . . . . . . . . . . . . . . . . . . . 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.1. Normative References . . . . . . . . . . . . . . . . . . 116 7.2. Informative References . . . . . . . . . . . . . . . . . 116 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 117 Intellectual Property and Copyright Statements . . . . . . . . . 118 Ewell Expires February 17, 2006 [Page 2] =0C Internet-Draft Initial Language Subtag Registry August 2005 1. Introduction [I-D.ietf-ltru-registry] provides for a Language Subtag Registry and describes its format. This memo defines the initial contents of the IANA Language Subtag Registry, using the criteria described in Section 2. The Language Subtag Registry is formatted in a modified record-jar text format, as described in [record-jar]. The specific format of the registry, and the definition and intended purpose of each of the fields, are described in [I-D.ietf-ltru-registry]. The registry is expected to change over time, as new subtags are registered and existing subtags are modified or deprecated. The process of updating the registry is described in Section 3 of [I-D.ietf-ltru-registry]. This memo does not define the permanent contents of the registry and should not be represented as doing so. Many of the subtags defined in this registry are based on code elements defined in [ISO639-1], [ISO639-2], [ISO15924], [ISO3166-1], and [UN_M.49]. This registry is not a mirror of the code lists defined by these standards, and should not be used as one. Ewell Expires February 17, 2006 [Page 3] =0C Internet-Draft Initial Language Subtag Registry August 2005 2. Initialization of the Registry Section 3.7 of [I-D.ietf-ltru-registry] requires that the LTRU working group create an initial version of the Language Subtag Registry and populate it with the initial set of subtags. This involves converting the entries from the existing IANA language tag registry defined by [RFC3066] to the new format, as well as defining valid subtags from various source standards. This section describes the process that was used to create the initial registry entries. The initial set of records was based on the following standards: [ISO639-1], [ISO639-2], [ISO15924], and [ISO3166-1]. The following criteria were used to select and format the records of the subtags included in the initial Language Subtag Registry (hereafter "ILSR"): 1. For each source standard, the date of the standard referenced in [RFC1766] was selected as the starting date. Code elements that were valid on that date in the selected standard were added to the ILSR. Code elements that were previously assigned, but which were vacated or withdrawn before that date, were not added to the ILSR. 2. For each successive change to the standard, any additional assignments up to the date of the adoption of [I-D.ietf-ltru- registry] were added to the ILSR. Values that have been withdrawn are marked as deprecated, but not removed. Changes in meaning or assignment of a subtag were permitted during this process (for example, the [ISO3166-1] code element 'CS' was originally assigned to Czechoslovakia and is now assigned to Serbia and Montenegro). Code elements from [UN_M.49] were also included in the ILSR using the criteria above, with the following additional rules: 3. UN numeric code elements assigned to "macro-geographical (continental)" regions as of the date of adoption of [I-D.ietf- ltru-registry] were added to the ILSR and thereby made valid for use in language tags. 4. The UN numeric code elements for "economic groupings" or "other groupings," and the alphanumeric code elements in Appendix X of the UN document, were not added to the ILSR. 5. The UN numeric code elements for countries or areas not associated with an assigned [ISO3166-1] alpha-2 code element were not added to the ILSR. These values are listed in Section 4 and may be requested for registration by individuals using the process defined in [I-D.ietf-ltru-registry] and according to the rules described therein. Listing of these code elements in this section Ewell Expires February 17, 2006 [Page 4] =0C Internet-Draft Initial Language Subtag Registry August 2005 is not a guarantee of future registration. 6. Code elements that were withdrawn, vacated, or deprecated from [UN_M.49] as of the date of adoption of [I-D.ietf-ltru-registry] were not added to the ILSR. Using the initial set of subtags described above, the tags in the [RFC3066] registry were evaluated as follows: 7. Tags in the [RFC3066] registry that were not deprecated, consisted entirely of subtags already in this document, and have the correct form and format for tags defined by [I-D.ietf-ltru- registry] were converted to records of type "redundant" in the ILSR. For example, "zh-Hant" is now defined by [I-D.ietf-ltru- registry] because 'zh' is an [ISO639-1] code element and 'Hant' is an [ISO15924] code element, and both are defined as subtags in the ILSR. 8. Tags in the [RFC3066] registry that contained one or more subtags that either did not match the valid registration pattern or were not otherwise defined by [I-D.ietf-ltru-registry] were converted to corresponding records of type "grandfathered" in the ILSR. These records cannot become type "redundant" except by revision of [I-D.ietf-ltru-registry], but may have a "Deprecated" and "Preferred-Value" field added to them if a subsequent subtag assignment or combination of assignments renders the tag obsolete. 9. Tags in the [RFC3066] registry that had a notation that they were deprecated were converted to records of type "grandfathered" in the ILSR. The record for the grandfathered entry contains a "Deprecated" field with the most appropriate date that can be determined for when the [RFC3066] record was deprecated. The "Comments" field may optionally contain a reason for the deprecation. The "Preferred-Value" field contains a tag that replaces the value. For example, the [RFC3066] tag "art-lojban" is deprecated and thus appears as a grandfathered tag in the ILSR. Its "Deprecated" field contains the deprecation date (in this case "2003-09-02") and the "Preferred-Value" field the value "jbo". 10. The remaining tags in the [RFC3066] registry are not deprecated and have a format consistent with language tags as defined by [I-D.ietf-ltru-registry] but contain subtags which are not defined in the ILSR. These subtags are eligible for registration as variants. The ILSR contains appropriate variant records for the following list of subtags, and the registered [RFC3066] tags containing these subtags were entered into the ILSR as type "redundant": Ewell Expires February 17, 2006 [Page 5] =0C Internet-Draft Initial Language Subtag Registry August 2005 1901 (use with Prefix: de) 1996 (use with Prefix: de) nedis (use with Prefix: sl) rozaj (use with Prefix: sl) 11. All remaining [RFC3066] registered tags were converted to records of type "grandfathered" in the ILSR. Interested parties may use the registration process in [I-D.ietf-ltru-registry] to attempt to register the variant subtags not already present in the Language Subtag Registry. If all of the subtags in the original tag become fully defined by the resulting registrations, then the original tag is superseded. Such tags will have their record changed from type "grandfathered" to type "redundant" in the registry. Note that previous approval of a tag under [RFC3066] is not a guarantee of approval of a variant subtag under [I-D.ietf- ltru-registry]. The existing [RFC3066] tag maintains its validity, but the original reason for its registration might have become obsolete. Ewell Expires February 17, 2006 [Page 6] =0C Internet-Draft Initial Language Subtag Registry August 2005 3. Initial Registry Contents The initial Language Subtag Registry follows. The registry begins with the line that starts with the string "File-Date" and continues to the end of this section. Headers, footers, line breaks, and other vertical whitespace introduced by the RFC process are not significant. Leading horizontal whitespace relative to the "File- Date" line indicates a continued line in the record-jar format, and must not be deleted. File-Date: 2005-08-16 %% Type: language Subtag: aa Description: Afar Added: 2005-08-16 %% Type: language Subtag: ab Description: Abkhazian Added: 2005-08-16 Suppress-Script: Cyrl %% Type: language Subtag: ae Description: Avestan Added: 2005-08-16 %% Type: language Subtag: af Description: Afrikaans Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ak Description: Akan Added: 2005-08-16 %% Type: language Subtag: am Description: Amharic Added: 2005-08-16 Suppress-Script: Ethi %% Type: language Subtag: an Description: Aragonese Ewell Expires February 17, 2006 [Page 7] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: language Subtag: ar Description: Arabic Added: 2005-08-16 Suppress-Script: Arab %% Type: language Subtag: as Description: Assamese Added: 2005-08-16 Suppress-Script: Beng %% Type: language Subtag: av Description: Avaric Added: 2005-08-16 %% Type: language Subtag: ay Description: Aymara Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: az Description: Azerbaijani Added: 2005-08-16 %% Type: language Subtag: ba Description: Bashkir Added: 2005-08-16 %% Type: language Subtag: be Description: Belarusian Added: 2005-08-16 Suppress-Script: Cyrl %% Type: language Subtag: bg Description: Bulgarian Added: 2005-08-16 Suppress-Script: Cyrl %% Type: language Ewell Expires February 17, 2006 [Page 8] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: bh Description: Bihari Added: 2005-08-16 %% Type: language Subtag: bi Description: Bislama Added: 2005-08-16 %% Type: language Subtag: bm Description: Bambara Added: 2005-08-16 %% Type: language Subtag: bn Description: Bengali Added: 2005-08-16 Suppress-Script: Beng %% Type: language Subtag: bo Description: Tibetan Added: 2005-08-16 %% Type: language Subtag: br Description: Breton Added: 2005-08-16 %% Type: language Subtag: bs Description: Bosnian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ca Description: Catalan Description: Valencian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ce Description: Chechen Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 9] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: ch Description: Chamorro Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: co Description: Corsican Added: 2005-08-16 %% Type: language Subtag: cr Description: Cree Added: 2005-08-16 %% Type: language Subtag: cs Description: Czech Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: cu Description: Church Slavic Description: Old Slavonic Description: Church Slavonic Description: Old Bulgarian Description: Old Church Slavonic Added: 2005-08-16 %% Type: language Subtag: cv Description: Chuvash Added: 2005-08-16 %% Type: language Subtag: cy Description: Welsh Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: da Description: Danish Added: 2005-08-16 Suppress-Script: Latn %% Ewell Expires February 17, 2006 [Page 10] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: de Description: German Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: dv Description: Divehi Added: 2005-08-16 Suppress-Script: Thaa %% Type: language Subtag: dz Description: Dzongkha Added: 2005-08-16 Suppress-Script: Tibt %% Type: language Subtag: ee Description: Ewe Added: 2005-08-16 %% Type: language Subtag: el Description: Greek, Modern (1453-) Added: 2005-08-16 Suppress-Script: Grek %% Type: language Subtag: en Description: English Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: eo Description: Esperanto Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: es Description: Spanish Description: Castilian Added: 2005-08-16 Suppress-Script: Latn %% Ewell Expires February 17, 2006 [Page 11] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: et Description: Estonian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: eu Description: Basque Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: fa Description: Persian Added: 2005-08-16 Suppress-Script: Arab %% Type: language Subtag: ff Description: Fulah Added: 2005-08-16 %% Type: language Subtag: fi Description: Finnish Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: fj Description: Fijian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: fo Description: Faroese Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: fr Description: French Added: 2005-08-16 Suppress-Script: Latn %% Type: language Ewell Expires February 17, 2006 [Page 12] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: fy Description: Frisian Added: 2005-08-16 %% Type: language Subtag: ga Description: Irish Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: gd Description: Gaelic Description: Scottish Gaelic Added: 2005-08-16 %% Type: language Subtag: gl Description: Galician Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: gn Description: Guarani Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: gu Description: Gujarati Added: 2005-08-16 Suppress-Script: Gujr %% Type: language Subtag: gv Description: Manx Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ha Description: Hausa Added: 2005-08-16 %% Type: language Subtag: he Description: Hebrew Ewell Expires February 17, 2006 [Page 13] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 Suppress-Script: Hebr %% Type: language Subtag: hi Description: Hindi Added: 2005-08-16 Suppress-Script: Deva %% Type: language Subtag: ho Description: Hiri Motu Added: 2005-08-16 %% Type: language Subtag: hr Description: Croatian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ht Description: Haitian Description: Haitian Creole Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: hu Description: Hungarian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: hy Description: Armenian Added: 2005-08-16 Suppress-Script: Armn %% Type: language Subtag: hz Description: Herero Added: 2005-08-16 %% Type: language Subtag: ia Description: Interlingua (International Auxiliary Language Association) Ewell Expires February 17, 2006 [Page 14] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: language Subtag: id Description: Indonesian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ie Description: Interlingue Added: 2005-08-16 %% Type: language Subtag: ig Description: Igbo Added: 2005-08-16 %% Type: language Subtag: ii Description: Sichuan Yi Added: 2005-08-16 %% Type: language Subtag: ik Description: Inupiaq Added: 2005-08-16 %% Type: language Subtag: in Description: Indonesian Added: 2005-08-16 Preferred-Value: id Deprecated: 1989-01-01 Suppress-Script: Latn %% Type: language Subtag: io Description: Ido Added: 2005-08-16 %% Type: language Subtag: is Description: Icelandic Added: 2005-08-16 Suppress-Script: Latn %% Type: language Ewell Expires February 17, 2006 [Page 15] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: it Description: Italian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: iu Description: Inuktitut Added: 2005-08-16 %% Type: language Subtag: iw Description: Hebrew Added: 2005-08-16 Preferred-Value: he Deprecated: 1989-01-01 Suppress-Script: Hebr %% Type: language Subtag: ja Description: Japanese Added: 2005-08-16 %% Type: language Subtag: ji Description: Yiddish Added: 2005-08-16 Preferred-Value: yi Deprecated: 1989-01-01 %% Type: language Subtag: jv Description: Javanese Added: 2005-08-16 %% Type: language Subtag: jw Description: Javanese Added: 2005-08-16 Preferred-Value: jv Deprecated: 2001-08-13 Comments: published by error in Table 1 of ISO 639:1988 %% Type: language Subtag: ka Description: Georgian Added: 2005-08-16 Suppress-Script: Geor Ewell Expires February 17, 2006 [Page 16] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: kg Description: Kongo Added: 2005-08-16 %% Type: language Subtag: ki Description: Kikuyu Description: Gikuyu Added: 2005-08-16 %% Type: language Subtag: kj Description: Kuanyama Description: Kwanyama Added: 2005-08-16 %% Type: language Subtag: kk Description: Kazakh Added: 2005-08-16 Suppress-Script: Cyrl %% Type: language Subtag: kl Description: Kalaallisut Description: Greenlandic Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: km Description: Khmer Added: 2005-08-16 Suppress-Script: Khmr %% Type: language Subtag: kn Description: Kannada Added: 2005-08-16 Suppress-Script: Knda %% Type: language Subtag: ko Description: Korean Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 17] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: kr Description: Kanuri Added: 2005-08-16 %% Type: language Subtag: ks Description: Kashmiri Added: 2005-08-16 %% Type: language Subtag: ku Description: Kurdish Added: 2005-08-16 %% Type: language Subtag: kv Description: Komi Added: 2005-08-16 %% Type: language Subtag: kw Description: Cornish Added: 2005-08-16 %% Type: language Subtag: ky Description: Kirghiz Added: 2005-08-16 %% Type: language Subtag: la Description: Latin Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: lb Description: Luxembourgish Description: Letzeburgesch Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: lg Description: Ganda Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 18] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: li Description: Limburgan Description: Limburger Description: Limburgish Added: 2005-08-16 %% Type: language Subtag: ln Description: Lingala Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: lo Description: Lao Added: 2005-08-16 Suppress-Script: Laoo %% Type: language Subtag: lt Description: Lithuanian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: lu Description: Luba-Katanga Added: 2005-08-16 %% Type: language Subtag: lv Description: Latvian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: mg Description: Malagasy Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: mh Description: Marshallese Added: 2005-08-16 Suppress-Script: Latn %% Ewell Expires February 17, 2006 [Page 19] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: mi Description: Maori Added: 2005-08-16 %% Type: language Subtag: mk Description: Macedonian Added: 2005-08-16 Suppress-Script: Cyrl %% Type: language Subtag: ml Description: Malayalam Added: 2005-08-16 Suppress-Script: Mlym %% Type: language Subtag: mn Description: Mongolian Added: 2005-08-16 %% Type: language Subtag: mo Description: Moldavian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: mr Description: Marathi Added: 2005-08-16 Suppress-Script: Deva %% Type: language Subtag: ms Description: Malay Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: mt Description: Maltese Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: my Ewell Expires February 17, 2006 [Page 20] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Burmese Added: 2005-08-16 Suppress-Script: Mymr %% Type: language Subtag: na Description: Nauru Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: nb Description: Norwegian Bokmål Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: nd Description: Ndebele, North Description: North Ndebele Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ne Description: Nepali Added: 2005-08-16 Suppress-Script: Deva %% Type: language Subtag: ng Description: Ndonga Added: 2005-08-16 %% Type: language Subtag: nl Description: Dutch Description: Flemish Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: nn Description: Norwegian Nynorsk Added: 2005-08-16 Suppress-Script: Latn %% Type: language Ewell Expires February 17, 2006 [Page 21] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: no Description: Norwegian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: nr Description: Ndebele, South Description: South Ndebele Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: nv Description: Navajo Description: Navaho Added: 2005-08-16 %% Type: language Subtag: ny Description: Chichewa Description: Chewa Description: Nyanja Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: oc Description: Occitan (post 1500) Description: Provençal Added: 2005-08-16 %% Type: language Subtag: oj Description: Ojibwa Added: 2005-08-16 %% Type: language Subtag: om Description: Oromo Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: or Description: Oriya Added: 2005-08-16 Suppress-Script: Orya Ewell Expires February 17, 2006 [Page 22] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: os Description: Ossetian Description: Ossetic Added: 2005-08-16 %% Type: language Subtag: pa Description: Panjabi Description: Punjabi Added: 2005-08-16 Suppress-Script: Guru %% Type: language Subtag: pi Description: Pali Added: 2005-08-16 %% Type: language Subtag: pl Description: Polish Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ps Description: Pushto Added: 2005-08-16 Suppress-Script: Arab %% Type: language Subtag: pt Description: Portuguese Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: qu Description: Quechua Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: rm Description: Raeto-Romance Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 23] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: rn Description: Rundi Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ro Description: Romanian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ru Description: Russian Added: 2005-08-16 Suppress-Script: Cyrl %% Type: language Subtag: rw Description: Kinyarwanda Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: sa Description: Sanskrit Added: 2005-08-16 %% Type: language Subtag: sc Description: Sardinian Added: 2005-08-16 %% Type: language Subtag: sd Description: Sindhi Added: 2005-08-16 %% Type: language Subtag: se Description: Northern Sami Added: 2005-08-16 %% Type: language Subtag: sg Description: Sango Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 24] =0C Internet-Draft Initial Language Subtag Registry August 2005 Suppress-Script: Latn %% Type: language Subtag: sh Description: Serbo-Croatian Added: 2005-08-16 Deprecated: 2000-02-18 %% Type: language Subtag: si Description: Sinhala Description: Sinhalese Added: 2005-08-16 Suppress-Script: Sinh %% Type: language Subtag: sk Description: Slovak Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: sl Description: Slovenian Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: sm Description: Samoan Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: sn Description: Shona Added: 2005-08-16 %% Type: language Subtag: so Description: Somali Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: sq Description: Albanian Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 25] =0C Internet-Draft Initial Language Subtag Registry August 2005 Suppress-Script: Latn %% Type: language Subtag: sr Description: Serbian Added: 2005-08-16 %% Type: language Subtag: ss Description: Swati Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: st Description: Sotho, Southern Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: su Description: Sundanese Added: 2005-08-16 %% Type: language Subtag: sv Description: Swedish Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: sw Description: Swahili Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ta Description: Tamil Added: 2005-08-16 Suppress-Script: Taml %% Type: language Subtag: te Description: Telugu Added: 2005-08-16 Suppress-Script: Telu %% Ewell Expires February 17, 2006 [Page 26] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: tg Description: Tajik Added: 2005-08-16 %% Type: language Subtag: th Description: Thai Added: 2005-08-16 Suppress-Script: Thai %% Type: language Subtag: ti Description: Tigrinya Added: 2005-08-16 Suppress-Script: Ethi %% Type: language Subtag: tk Description: Turkmen Added: 2005-08-16 %% Type: language Subtag: tl Description: Tagalog Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: tn Description: Tswana Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: to Description: Tonga (Tonga Islands) Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: tr Description: Turkish Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ts Ewell Expires February 17, 2006 [Page 27] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Tsonga Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: tt Description: Tatar Added: 2005-08-16 %% Type: language Subtag: tw Description: Twi Added: 2005-08-16 %% Type: language Subtag: ty Description: Tahitian Added: 2005-08-16 %% Type: language Subtag: ug Description: Uighur Description: Uyghur Added: 2005-08-16 %% Type: language Subtag: uk Description: Ukrainian Added: 2005-08-16 Suppress-Script: Cyrl %% Type: language Subtag: ur Description: Urdu Added: 2005-08-16 Suppress-Script: Arab %% Type: language Subtag: uz Description: Uzbek Added: 2005-08-16 %% Type: language Subtag: ve Description: Venda Added: 2005-08-16 Suppress-Script: Latn %% Ewell Expires February 17, 2006 [Page 28] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: vi Description: Vietnamese Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: vo Description: Volapük Added: 2005-08-16 %% Type: language Subtag: wa Description: Walloon Added: 2005-08-16 %% Type: language Subtag: wo Description: Wolof Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: xh Description: Xhosa Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: yi Description: Yiddish Added: 2005-08-16 Suppress-Script: Hebr %% Type: language Subtag: yo Description: Yoruba Added: 2005-08-16 %% Type: language Subtag: za Description: Zhuang Description: Chuang Added: 2005-08-16 %% Type: language Subtag: zh Description: Chinese Ewell Expires February 17, 2006 [Page 29] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: language Subtag: zu Description: Zulu Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ace Description: Achinese Added: 2005-08-16 %% Type: language Subtag: ach Description: Acoli Added: 2005-08-16 %% Type: language Subtag: ada Description: Adangme Added: 2005-08-16 %% Type: language Subtag: ady Description: Adyghe Description: Adygei Added: 2005-08-16 %% Type: language Subtag: afa Description: Afro-Asiatic (Other) Added: 2005-08-16 %% Type: language Subtag: afh Description: Afrihili Added: 2005-08-16 %% Type: language Subtag: ain Description: Ainu Added: 2005-08-16 %% Type: language Subtag: akk Description: Akkadian Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 30] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: ale Description: Aleut Added: 2005-08-16 %% Type: language Subtag: alg Description: Algonquian languages Added: 2005-08-16 %% Type: language Subtag: alt Description: Southern Altai Added: 2005-08-16 %% Type: language Subtag: ang Description: English, Old (ca. 450-1100) Added: 2005-08-16 %% Type: language Subtag: apa Description: Apache languages Added: 2005-08-16 %% Type: language Subtag: arc Description: Aramaic Added: 2005-08-16 %% Type: language Subtag: arn Description: Araucanian Added: 2005-08-16 %% Type: language Subtag: arp Description: Arapaho Added: 2005-08-16 %% Type: language Subtag: art Description: Artificial (Other) Added: 2005-08-16 %% Type: language Subtag: arw Ewell Expires February 17, 2006 [Page 31] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Arawak Added: 2005-08-16 %% Type: language Subtag: ast Description: Asturian Description: Bable Added: 2005-08-16 %% Type: language Subtag: ath Description: Athapascan languages Added: 2005-08-16 %% Type: language Subtag: aus Description: Australian languages Added: 2005-08-16 %% Type: language Subtag: awa Description: Awadhi Added: 2005-08-16 %% Type: language Subtag: bad Description: Banda Added: 2005-08-16 %% Type: language Subtag: bai Description: Bamileke languages Added: 2005-08-16 %% Type: language Subtag: bal Description: Baluchi Added: 2005-08-16 %% Type: language Subtag: ban Description: Balinese Added: 2005-08-16 %% Type: language Subtag: bas Description: Basa Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 32] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: bat Description: Baltic (Other) Added: 2005-08-16 %% Type: language Subtag: bej Description: Beja Added: 2005-08-16 %% Type: language Subtag: bem Description: Bemba Added: 2005-08-16 %% Type: language Subtag: ber Description: Berber (Other) Added: 2005-08-16 %% Type: language Subtag: bho Description: Bhojpuri Added: 2005-08-16 %% Type: language Subtag: bik Description: Bikol Added: 2005-08-16 %% Type: language Subtag: bin Description: Bini Added: 2005-08-16 %% Type: language Subtag: bla Description: Siksika Added: 2005-08-16 %% Type: language Subtag: bnt Description: Bantu (Other) Added: 2005-08-16 %% Type: language Subtag: bra Ewell Expires February 17, 2006 [Page 33] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Braj Added: 2005-08-16 %% Type: language Subtag: btk Description: Batak (Indonesia) Added: 2005-08-16 %% Type: language Subtag: bua Description: Buriat Added: 2005-08-16 %% Type: language Subtag: bug Description: Buginese Added: 2005-08-16 %% Type: language Subtag: byn Description: Blin Description: Bilin Added: 2005-08-16 %% Type: language Subtag: cad Description: Caddo Added: 2005-08-16 %% Type: language Subtag: cai Description: Central American Indian (Other) Added: 2005-08-16 %% Type: language Subtag: car Description: Carib Added: 2005-08-16 %% Type: language Subtag: cau Description: Caucasian (Other) Added: 2005-08-16 %% Type: language Subtag: ceb Description: Cebuano Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 34] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: cel Description: Celtic (Other) Added: 2005-08-16 %% Type: language Subtag: chb Description: Chibcha Added: 2005-08-16 %% Type: language Subtag: chg Description: Chagatai Added: 2005-08-16 %% Type: language Subtag: chk Description: Chuukese Added: 2005-08-16 %% Type: language Subtag: chm Description: Mari Added: 2005-08-16 %% Type: language Subtag: chn Description: Chinook jargon Added: 2005-08-16 %% Type: language Subtag: cho Description: Choctaw Added: 2005-08-16 %% Type: language Subtag: chp Description: Chipewyan Added: 2005-08-16 %% Type: language Subtag: chr Description: Cherokee Added: 2005-08-16 %% Type: language Subtag: chy Ewell Expires February 17, 2006 [Page 35] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Cheyenne Added: 2005-08-16 %% Type: language Subtag: cmc Description: Chamic languages Added: 2005-08-16 %% Type: language Subtag: cop Description: Coptic Added: 2005-08-16 %% Type: language Subtag: cpe Description: Creoles and pidgins, English-based (Other) Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: cpf Description: Creoles and pidgins, French-based (Other) Added: 2005-08-16 %% Type: language Subtag: cpp Description: Creoles and pidgins, Portuguese-based (Other) Added: 2005-08-16 %% Type: language Subtag: crh Description: Crimean Tatar Description: Crimean Turkish Added: 2005-08-16 %% Type: language Subtag: crp Description: Creoles and pidgins (Other) Added: 2005-08-16 %% Type: language Subtag: csb Description: Kashubian Added: 2005-08-16 %% Type: language Subtag: cus Description: Cushitic (Other) Ewell Expires February 17, 2006 [Page 36] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: language Subtag: dak Description: Dakota Added: 2005-08-16 %% Type: language Subtag: dar Description: Dargwa Added: 2005-08-16 %% Type: language Subtag: day Description: Dayak Added: 2005-08-16 %% Type: language Subtag: del Description: Delaware Added: 2005-08-16 %% Type: language Subtag: den Description: Slave (Athapascan) Added: 2005-08-16 %% Type: language Subtag: dgr Description: Dogrib Added: 2005-08-16 %% Type: language Subtag: din Description: Dinka Added: 2005-08-16 %% Type: language Subtag: doi Description: Dogri Added: 2005-08-16 %% Type: language Subtag: dra Description: Dravidian (Other) Added: 2005-08-16 %% Type: language Ewell Expires February 17, 2006 [Page 37] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: dsb Description: Lower Sorbian Added: 2005-08-16 %% Type: language Subtag: dua Description: Duala Added: 2005-08-16 %% Type: language Subtag: dum Description: Dutch, Middle (ca. 1050-1350) Added: 2005-08-16 %% Type: language Subtag: dyu Description: Dyula Added: 2005-08-16 %% Type: language Subtag: efi Description: Efik Added: 2005-08-16 %% Type: language Subtag: egy Description: Egyptian (Ancient) Added: 2005-08-16 %% Type: language Subtag: eka Description: Ekajuk Added: 2005-08-16 %% Type: language Subtag: elx Description: Elamite Added: 2005-08-16 %% Type: language Subtag: enm Description: English, Middle (1100-1500) Added: 2005-08-16 %% Type: language Subtag: ewo Description: Ewondo Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 38] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: fan Description: Fang Added: 2005-08-16 %% Type: language Subtag: fat Description: Fanti Added: 2005-08-16 %% Type: language Subtag: fil Description: Filipino Description: Pilipino Added: 2005-08-16 %% Type: language Subtag: fiu Description: Finno-Ugrian (Other) Added: 2005-08-16 %% Type: language Subtag: fon Description: Fon Added: 2005-08-16 %% Type: language Subtag: frm Description: French, Middle (ca. 1400-1600) Added: 2005-08-16 %% Type: language Subtag: fro Description: French, Old (842-ca. 1400) Added: 2005-08-16 %% Type: language Subtag: fur Description: Friulian Added: 2005-08-16 %% Type: language Subtag: gaa Description: Ga Added: 2005-08-16 %% Type: language Ewell Expires February 17, 2006 [Page 39] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: gay Description: Gayo Added: 2005-08-16 %% Type: language Subtag: gba Description: Gbaya Added: 2005-08-16 %% Type: language Subtag: gem Description: Germanic (Other) Added: 2005-08-16 %% Type: language Subtag: gez Description: Geez Added: 2005-08-16 %% Type: language Subtag: gil Description: Gilbertese Added: 2005-08-16 %% Type: language Subtag: gmh Description: German, Middle High (ca. 1050-1500) Added: 2005-08-16 %% Type: language Subtag: goh Description: German, Old High (ca. 750-1050) Added: 2005-08-16 %% Type: language Subtag: gon Description: Gondi Added: 2005-08-16 %% Type: language Subtag: gor Description: Gorontalo Added: 2005-08-16 %% Type: language Subtag: got Description: Gothic Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 40] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: grb Description: Grebo Added: 2005-08-16 %% Type: language Subtag: grc Description: Greek, Ancient (to 1453) Added: 2005-08-16 %% Type: language Subtag: gwi Description: Gwich´in Added: 2005-08-16 %% Type: language Subtag: hai Description: Haida Added: 2005-08-16 %% Type: language Subtag: haw Description: Hawaiian Added: 2005-08-16 %% Type: language Subtag: hil Description: Hiligaynon Added: 2005-08-16 %% Type: language Subtag: him Description: Himachali Added: 2005-08-16 %% Type: language Subtag: hit Description: Hittite Added: 2005-08-16 %% Type: language Subtag: hmn Description: Hmong Added: 2005-08-16 %% Type: language Subtag: hsb Ewell Expires February 17, 2006 [Page 41] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Upper Sorbian Added: 2005-08-16 %% Type: language Subtag: hup Description: Hupa Added: 2005-08-16 %% Type: language Subtag: iba Description: Iban Added: 2005-08-16 %% Type: language Subtag: ijo Description: Ijo Added: 2005-08-16 %% Type: language Subtag: ilo Description: Iloko Added: 2005-08-16 %% Type: language Subtag: inc Description: Indic (Other) Added: 2005-08-16 %% Type: language Subtag: ine Description: Indo-European (Other) Added: 2005-08-16 %% Type: language Subtag: inh Description: Ingush Added: 2005-08-16 %% Type: language Subtag: ira Description: Iranian (Other) Added: 2005-08-16 %% Type: language Subtag: iro Description: Iroquoian languages Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 42] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: jbo Description: Lojban Added: 2005-08-16 %% Type: language Subtag: jpr Description: Judeo-Persian Added: 2005-08-16 %% Type: language Subtag: jrb Description: Judeo-Arabic Added: 2005-08-16 %% Type: language Subtag: kaa Description: Kara-Kalpak Added: 2005-08-16 %% Type: language Subtag: kab Description: Kabyle Added: 2005-08-16 %% Type: language Subtag: kac Description: Kachin Added: 2005-08-16 %% Type: language Subtag: kam Description: Kamba Added: 2005-08-16 %% Type: language Subtag: kar Description: Karen Added: 2005-08-16 %% Type: language Subtag: kaw Description: Kawi Added: 2005-08-16 %% Type: language Subtag: kbd Description: Kabardian Ewell Expires February 17, 2006 [Page 43] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: language Subtag: kha Description: Khasi Added: 2005-08-16 %% Type: language Subtag: khi Description: Khoisan (Other) Added: 2005-08-16 %% Type: language Subtag: kho Description: Khotanese Added: 2005-08-16 %% Type: language Subtag: kmb Description: Kimbundu Added: 2005-08-16 %% Type: language Subtag: kok Description: Konkani Added: 2005-08-16 Suppress-Script: Deva %% Type: language Subtag: kos Description: Kosraean Added: 2005-08-16 %% Type: language Subtag: kpe Description: Kpelle Added: 2005-08-16 %% Type: language Subtag: krc Description: Karachay-Balkar Added: 2005-08-16 %% Type: language Subtag: kro Description: Kru Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 44] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: kru Description: Kurukh Added: 2005-08-16 %% Type: language Subtag: kum Description: Kumyk Added: 2005-08-16 %% Type: language Subtag: kut Description: Kutenai Added: 2005-08-16 %% Type: language Subtag: lad Description: Ladino Added: 2005-08-16 %% Type: language Subtag: lah Description: Lahnda Added: 2005-08-16 %% Type: language Subtag: lam Description: Lamba Added: 2005-08-16 %% Type: language Subtag: lez Description: Lezghian Added: 2005-08-16 %% Type: language Subtag: lol Description: Mongo Added: 2005-08-16 %% Type: language Subtag: loz Description: Lozi Added: 2005-08-16 %% Type: language Subtag: lua Description: Luba-Lulua Ewell Expires February 17, 2006 [Page 45] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: language Subtag: lui Description: Luiseno Added: 2005-08-16 %% Type: language Subtag: lun Description: Lunda Added: 2005-08-16 %% Type: language Subtag: luo Description: Luo (Kenya and Tanzania) Added: 2005-08-16 %% Type: language Subtag: lus Description: Lushai Added: 2005-08-16 %% Type: language Subtag: mad Description: Madurese Added: 2005-08-16 %% Type: language Subtag: mag Description: Magahi Added: 2005-08-16 %% Type: language Subtag: mai Description: Maithili Added: 2005-08-16 Suppress-Script: Deva %% Type: language Subtag: mak Description: Makasar Added: 2005-08-16 %% Type: language Subtag: man Description: Mandingo Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 46] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: map Description: Austronesian (Other) Added: 2005-08-16 %% Type: language Subtag: mas Description: Masai Added: 2005-08-16 %% Type: language Subtag: mdf Description: Moksha Added: 2005-08-16 %% Type: language Subtag: mdr Description: Mandar Added: 2005-08-16 %% Type: language Subtag: men Description: Mende Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: mga Description: Irish, Middle (900-1200) Added: 2005-08-16 %% Type: language Subtag: mic Description: Mi'kmaq Description: Micmac Added: 2005-08-16 %% Type: language Subtag: min Description: Minangkabau Added: 2005-08-16 %% Type: language Subtag: mis Description: Miscellaneous languages Added: 2005-08-16 %% Type: language Ewell Expires February 17, 2006 [Page 47] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: mkh Description: Mon-Khmer (Other) Added: 2005-08-16 %% Type: language Subtag: mnc Description: Manchu Added: 2005-08-16 %% Type: language Subtag: mni Description: Manipuri Added: 2005-08-16 %% Type: language Subtag: mno Description: Manobo languages Added: 2005-08-16 %% Type: language Subtag: moh Description: Mohawk Added: 2005-08-16 %% Type: language Subtag: mos Description: Mossi Added: 2005-08-16 %% Type: language Subtag: mul Description: Multiple languages Added: 2005-08-16 %% Type: language Subtag: mun Description: Munda languages Added: 2005-08-16 %% Type: language Subtag: mus Description: Creek Added: 2005-08-16 %% Type: language Subtag: mwl Description: Mirandese Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 48] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: mwr Description: Marwari Added: 2005-08-16 %% Type: language Subtag: myn Description: Mayan languages Added: 2005-08-16 %% Type: language Subtag: myv Description: Erzya Added: 2005-08-16 %% Type: language Subtag: nah Description: Nahuatl Added: 2005-08-16 %% Type: language Subtag: nai Description: North American Indian Added: 2005-08-16 %% Type: language Subtag: nap Description: Neapolitan Added: 2005-08-16 %% Type: language Subtag: nds Description: Low German Description: Low Saxon Description: German, Low Description: Saxon, Low Added: 2005-08-16 %% Type: language Subtag: new Description: Nepal Bhasa Description: Newari Added: 2005-08-16 %% Type: language Subtag: nia Description: Nias Ewell Expires February 17, 2006 [Page 49] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: language Subtag: nic Description: Niger-Kordofanian (Other) Added: 2005-08-16 %% Type: language Subtag: niu Description: Niuean Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: nog Description: Nogai Added: 2005-08-16 %% Type: language Subtag: non Description: Norse, Old Added: 2005-08-16 %% Type: language Subtag: nso Description: Northern Sotho Description: Pedi Description: Sepedi Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: nub Description: Nubian languages Added: 2005-08-16 %% Type: language Subtag: nwc Description: Classical Newari Description: Old Newari Description: Classical Nepal Bhasa Added: 2005-08-16 %% Type: language Subtag: nym Description: Nyamwezi Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 50] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: nyn Description: Nyankole Added: 2005-08-16 %% Type: language Subtag: nyo Description: Nyoro Added: 2005-08-16 %% Type: language Subtag: nzi Description: Nzima Added: 2005-08-16 %% Type: language Subtag: osa Description: Osage Added: 2005-08-16 %% Type: language Subtag: ota Description: Turkish, Ottoman (1500-1928) Added: 2005-08-16 %% Type: language Subtag: oto Description: Otomian languages Added: 2005-08-16 %% Type: language Subtag: paa Description: Papuan (Other) Added: 2005-08-16 %% Type: language Subtag: pag Description: Pangasinan Added: 2005-08-16 %% Type: language Subtag: pal Description: Pahlavi Added: 2005-08-16 %% Type: language Subtag: pam Description: Pampanga Ewell Expires February 17, 2006 [Page 51] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: language Subtag: pap Description: Papiamento Added: 2005-08-16 %% Type: language Subtag: pau Description: Palauan Added: 2005-08-16 %% Type: language Subtag: peo Description: Persian, Old (ca. 600-400 B.C.) Added: 2005-08-16 %% Type: language Subtag: phi Description: Philippine (Other) Added: 2005-08-16 %% Type: language Subtag: phn Description: Phoenician Added: 2005-08-16 %% Type: language Subtag: pon Description: Pohnpeian Added: 2005-08-16 %% Type: language Subtag: pra Description: Prakrit languages Added: 2005-08-16 %% Type: language Subtag: pro Description: Provençal, Old (to 1500) Added: 2005-08-16 %% Type: language Subtag: qaa..qtz Description: PRIVATE USE Added: 2005-08-16 %% Type: language Ewell Expires February 17, 2006 [Page 52] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: raj Description: Rajasthani Added: 2005-08-16 %% Type: language Subtag: rap Description: Rapanui Added: 2005-08-16 %% Type: language Subtag: rar Description: Rarotongan Added: 2005-08-16 %% Type: language Subtag: roa Description: Romance (Other) Added: 2005-08-16 %% Type: language Subtag: rom Description: Romany Added: 2005-08-16 %% Type: language Subtag: sad Description: Sandawe Added: 2005-08-16 %% Type: language Subtag: sah Description: Yakut Added: 2005-08-16 %% Type: language Subtag: sai Description: South American Indian (Other) Added: 2005-08-16 %% Type: language Subtag: sal Description: Salishan languages Added: 2005-08-16 %% Type: language Subtag: sam Description: Samaritan Aramaic Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 53] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: language Subtag: sas Description: Sasak Added: 2005-08-16 %% Type: language Subtag: sat Description: Santali Added: 2005-08-16 %% Type: language Subtag: scn Description: Sicilian Added: 2005-08-16 %% Type: language Subtag: sco Description: Scots Added: 2005-08-16 %% Type: language Subtag: sel Description: Selkup Added: 2005-08-16 %% Type: language Subtag: sem Description: Semitic (Other) Added: 2005-08-16 %% Type: language Subtag: sga Description: Irish, Old (to 900) Added: 2005-08-16 %% Type: language Subtag: sgn Description: Sign Languages Added: 2005-08-16 %% Type: language Subtag: shn Description: Shan Added: 2005-08-16 %% Type: language Subtag: sid Ewell Expires February 17, 2006 [Page 54] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Sidamo Added: 2005-08-16 %% Type: language Subtag: sio Description: Siouan languages Added: 2005-08-16 %% Type: language Subtag: sit Description: Sino-Tibetan (Other) Added: 2005-08-16 %% Type: language Subtag: sla Description: Slavic (Other) Added: 2005-08-16 %% Type: language Subtag: sma Description: Southern Sami Added: 2005-08-16 %% Type: language Subtag: smi Description: Sami languages (Other) Added: 2005-08-16 %% Type: language Subtag: smj Description: Lule Sami Added: 2005-08-16 %% Type: language Subtag: smn Description: Inari Sami Added: 2005-08-16 %% Type: language Subtag: sms Description: Skolt Sami Added: 2005-08-16 %% Type: language Subtag: snk Description: Soninke Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 55] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: sog Description: Sogdian Added: 2005-08-16 %% Type: language Subtag: son Description: Songhai Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: srn Description: Sranan Tongo Added: 2005-08-16 %% Type: language Subtag: srr Description: Serer Added: 2005-08-16 %% Type: language Subtag: ssa Description: Nilo-Saharan (Other) Added: 2005-08-16 %% Type: language Subtag: suk Description: Sukuma Added: 2005-08-16 %% Type: language Subtag: sus Description: Susu Added: 2005-08-16 %% Type: language Subtag: sux Description: Sumerian Added: 2005-08-16 %% Type: language Subtag: syr Description: Syriac Added: 2005-08-16 %% Type: language Subtag: tai Ewell Expires February 17, 2006 [Page 56] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Tai (Other) Added: 2005-08-16 %% Type: language Subtag: tem Description: Timne Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: ter Description: Tereno Added: 2005-08-16 %% Type: language Subtag: tet Description: Tetum Added: 2005-08-16 %% Type: language Subtag: tig Description: Tigre Added: 2005-08-16 %% Type: language Subtag: tiv Description: Tiv Added: 2005-08-16 %% Type: language Subtag: tkl Description: Tokelau Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: tlh Description: Klingon Description: tlhIngan-Hol Added: 2005-08-16 %% Type: language Subtag: tli Description: Tlingit Added: 2005-08-16 %% Type: language Subtag: tmh Ewell Expires February 17, 2006 [Page 57] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Tamashek Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: tog Description: Tonga (Nyasa) Added: 2005-08-16 %% Type: language Subtag: tpi Description: Tok Pisin Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: tsi Description: Tsimshian Added: 2005-08-16 %% Type: language Subtag: tum Description: Tumbuka Added: 2005-08-16 %% Type: language Subtag: tup Description: Tupi languages Added: 2005-08-16 %% Type: language Subtag: tut Description: Altaic (Other) Added: 2005-08-16 %% Type: language Subtag: tvl Description: Tuvalu Added: 2005-08-16 Suppress-Script: Latn %% Type: language Subtag: tyv Description: Tuvinian Added: 2005-08-16 %% Type: language Subtag: udm Ewell Expires February 17, 2006 [Page 58] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Udmurt Added: 2005-08-16 %% Type: language Subtag: uga Description: Ugaritic Added: 2005-08-16 %% Type: language Subtag: umb Description: Umbundu Added: 2005-08-16 %% Type: language Subtag: und Description: Undetermined Added: 2005-08-16 %% Type: language Subtag: vai Description: Vai Added: 2005-08-16 %% Type: language Subtag: vot Description: Votic Added: 2005-08-16 %% Type: language Subtag: wak Description: Wakashan languages Added: 2005-08-16 %% Type: language Subtag: wal Description: Walamo Added: 2005-08-16 %% Type: language Subtag: war Description: Waray Added: 2005-08-16 %% Type: language Subtag: was Description: Washo Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 59] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: language Subtag: wen Description: Sorbian languages Added: 2005-08-16 %% Type: language Subtag: xal Description: Kalmyk Description: Oirat Added: 2005-08-16 %% Type: language Subtag: yao Description: Yao Added: 2005-08-16 %% Type: language Subtag: yap Description: Yapese Added: 2005-08-16 %% Type: language Subtag: ypk Description: Yupik languages Added: 2005-08-16 %% Type: language Subtag: zap Description: Zapotec Added: 2005-08-16 %% Type: language Subtag: zen Description: Zenaga Added: 2005-08-16 %% Type: language Subtag: znd Description: Zande Added: 2005-08-16 %% Type: language Subtag: zun Description: Zuni Added: 2005-08-16 %% Type: script Subtag: Arab Ewell Expires February 17, 2006 [Page 60] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Arabic Added: 2005-08-16 %% Type: script Subtag: Armn Description: Armenian Added: 2005-08-16 %% Type: script Subtag: Bali Description: Balinese Added: 2005-08-16 %% Type: script Subtag: Batk Description: Batak Added: 2005-08-16 %% Type: script Subtag: Beng Description: Bengali Added: 2005-08-16 %% Type: script Subtag: Blis Description: Blissymbols Added: 2005-08-16 %% Type: script Subtag: Bopo Description: Bopomofo Added: 2005-08-16 %% Type: script Subtag: Brah Description: Brahmi Added: 2005-08-16 %% Type: script Subtag: Brai Description: Braille Added: 2005-08-16 %% Type: script Subtag: Bugi Description: Buginese Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 61] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: script Subtag: Buhd Description: Buhid Added: 2005-08-16 %% Type: script Subtag: Cans Description: Unified Canadian Aboriginal Syllabics Added: 2005-08-16 %% Type: script Subtag: Cham Description: Cham Added: 2005-08-16 %% Type: script Subtag: Cher Description: Cherokee Added: 2005-08-16 %% Type: script Subtag: Cirt Description: Cirth Added: 2005-08-16 %% Type: script Subtag: Copt Description: Coptic Added: 2005-08-16 %% Type: script Subtag: Cprt Description: Cypriot Added: 2005-08-16 %% Type: script Subtag: Cyrl Description: Cyrillic Added: 2005-08-16 %% Type: script Subtag: Cyrs Description: Cyrillic (Old Church Slavonic variant) Added: 2005-08-16 %% Type: script Subtag: Deva Description: Devanagari (Nagari) Ewell Expires February 17, 2006 [Page 62] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: script Subtag: Dsrt Description: Deseret (Mormon) Added: 2005-08-16 %% Type: script Subtag: Egyd Description: Egyptian demotic Added: 2005-08-16 %% Type: script Subtag: Egyh Description: Egyptian hieratic Added: 2005-08-16 %% Type: script Subtag: Egyp Description: Egyptian hieroglyphs Added: 2005-08-16 %% Type: script Subtag: Ethi Description: Ethiopic (Ge‘ez) Added: 2005-08-16 %% Type: script Subtag: Geok Description: Khutsuri (Asomtavruli and Nuskhuri) Added: 2005-08-16 %% Type: script Subtag: Geor Description: Georgian (Mkhedruli) Added: 2005-08-16 %% Type: script Subtag: Glag Description: Glagolitic Added: 2005-08-16 %% Type: script Subtag: Goth Description: Gothic Added: 2005-08-16 %% Type: script Ewell Expires February 17, 2006 [Page 63] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: Grek Description: Greek Added: 2005-08-16 %% Type: script Subtag: Gujr Description: Gujarati Added: 2005-08-16 %% Type: script Subtag: Guru Description: Gurmukhi Added: 2005-08-16 %% Type: script Subtag: Hang Description: Hangul (Hangŭl, Hangeul) Added: 2005-08-16 %% Type: script Subtag: Hani Description: Han (Hanzi, Kanji, Hanja) Added: 2005-08-16 %% Type: script Subtag: Hano Description: Hanunoo (Hanunóo) Added: 2005-08-16 %% Type: script Subtag: Hans Description: Han (Simplified variant) Added: 2005-08-16 %% Type: script Subtag: Hant Description: Han (Traditional variant) Added: 2005-08-16 %% Type: script Subtag: Hebr Description: Hebrew Added: 2005-08-16 %% Type: script Subtag: Hira Description: Hiragana Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 64] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: script Subtag: Hmng Description: Pahawh Hmong Added: 2005-08-16 %% Type: script Subtag: Hrkt Description: (alias for Hiragana + Katakana) Added: 2005-08-16 %% Type: script Subtag: Hung Description: Old Hungarian Added: 2005-08-16 %% Type: script Subtag: Inds Description: Indus (Harappan) Added: 2005-08-16 %% Type: script Subtag: Ital Description: Old Italic (Etruscan, Oscan, etc.) Added: 2005-08-16 %% Type: script Subtag: Java Description: Javanese Added: 2005-08-16 %% Type: script Subtag: Kali Description: Kayah Li Added: 2005-08-16 %% Type: script Subtag: Kana Description: Katakana Added: 2005-08-16 %% Type: script Subtag: Khar Description: Kharoshthi Added: 2005-08-16 %% Type: script Subtag: Khmr Ewell Expires February 17, 2006 [Page 65] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Khmer Added: 2005-08-16 %% Type: script Subtag: Knda Description: Kannada Added: 2005-08-16 %% Type: script Subtag: Laoo Description: Lao Added: 2005-08-16 %% Type: script Subtag: Latf Description: Latin (Fraktur variant) Added: 2005-08-16 %% Type: script Subtag: Latg Description: Latin (Gaelic variant) Added: 2005-08-16 %% Type: script Subtag: Latn Description: Latin Added: 2005-08-16 %% Type: script Subtag: Lepc Description: Lepcha (Róng) Added: 2005-08-16 %% Type: script Subtag: Limb Description: Limbu Added: 2005-08-16 %% Type: script Subtag: Lina Description: Linear A Added: 2005-08-16 %% Type: script Subtag: Linb Description: Linear B Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 66] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: script Subtag: Mand Description: Mandaean Added: 2005-08-16 %% Type: script Subtag: Maya Description: Mayan hieroglyphs Added: 2005-08-16 %% Type: script Subtag: Mero Description: Meroitic Added: 2005-08-16 %% Type: script Subtag: Mlym Description: Malayalam Added: 2005-08-16 %% Type: script Subtag: Mong Description: Mongolian Added: 2005-08-16 %% Type: script Subtag: Mymr Description: Myanmar (Burmese) Added: 2005-08-16 %% Type: script Subtag: Nkoo Description: N’Ko Added: 2005-08-16 %% Type: script Subtag: Ogam Description: Ogham Added: 2005-08-16 %% Type: script Subtag: Orkh Description: Orkhon Added: 2005-08-16 %% Type: script Subtag: Orya Description: Oriya Ewell Expires February 17, 2006 [Page 67] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: script Subtag: Osma Description: Osmanya Added: 2005-08-16 %% Type: script Subtag: Perm Description: Old Permic Added: 2005-08-16 %% Type: script Subtag: Phag Description: Phags-pa Added: 2005-08-16 %% Type: script Subtag: Phnx Description: Phoenician Added: 2005-08-16 %% Type: script Subtag: Plrd Description: Pollard Phonetic Added: 2005-08-16 %% Type: script Subtag: Qaaa..Qabx Description: PRIVATE USE Added: 2005-08-16 %% Type: script Subtag: Roro Description: Rongorongo Added: 2005-08-16 %% Type: script Subtag: Runr Description: Runic Added: 2005-08-16 %% Type: script Subtag: Sara Description: Sarati Added: 2005-08-16 %% Type: script Ewell Expires February 17, 2006 [Page 68] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: Shaw Description: Shavian (Shaw) Added: 2005-08-16 %% Type: script Subtag: Sinh Description: Sinhala Added: 2005-08-16 %% Type: script Subtag: Sylo Description: Syloti Nagri Added: 2005-08-16 %% Type: script Subtag: Syrc Description: Syriac Added: 2005-08-16 %% Type: script Subtag: Syre Description: Syriac (Estrangelo variant) Added: 2005-08-16 %% Type: script Subtag: Syrj Description: Syriac (Western variant) Added: 2005-08-16 %% Type: script Subtag: Syrn Description: Syriac (Eastern variant) Added: 2005-08-16 %% Type: script Subtag: Tagb Description: Tagbanwa Added: 2005-08-16 %% Type: script Subtag: Tale Description: Tai Le Added: 2005-08-16 %% Type: script Subtag: Talu Description: New Tai Lue Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 69] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: script Subtag: Taml Description: Tamil Added: 2005-08-16 %% Type: script Subtag: Telu Description: Telugu Added: 2005-08-16 %% Type: script Subtag: Teng Description: Tengwar Added: 2005-08-16 %% Type: script Subtag: Tfng Description: Tifinagh (Berber) Added: 2005-08-16 %% Type: script Subtag: Tglg Description: Tagalog Added: 2005-08-16 %% Type: script Subtag: Thaa Description: Thaana Added: 2005-08-16 %% Type: script Subtag: Thai Description: Thai Added: 2005-08-16 %% Type: script Subtag: Tibt Description: Tibetan Added: 2005-08-16 %% Type: script Subtag: Ugar Description: Ugaritic Added: 2005-08-16 %% Type: script Subtag: Vaii Ewell Expires February 17, 2006 [Page 70] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Vai Added: 2005-08-16 %% Type: script Subtag: Visp Description: Visible Speech Added: 2005-08-16 %% Type: script Subtag: Xpeo Description: Old Persian Added: 2005-08-16 %% Type: script Subtag: Xsux Description: Cuneiform, Sumero-Akkadian Added: 2005-08-16 %% Type: script Subtag: Yiii Description: Yi Added: 2005-08-16 %% Type: script Subtag: Zxxx Description: Code for unwritten languages Added: 2005-08-16 %% Type: script Subtag: Zyyy Description: Code for undetermined script Added: 2005-08-16 %% Type: script Subtag: Zzzz Description: Code for uncoded script Added: 2005-08-16 %% Type: region Subtag: AA Description: PRIVATE USE Added: 2005-08-16 %% Type: region Subtag: AD Description: Andorra Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 71] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: AE Description: United Arab Emirates Added: 2005-08-16 %% Type: region Subtag: AF Description: Afghanistan Added: 2005-08-16 %% Type: region Subtag: AG Description: Antigua and Barbuda Added: 2005-08-16 %% Type: region Subtag: AI Description: Anguilla Added: 2005-08-16 %% Type: region Subtag: AL Description: Albania Added: 2005-08-16 %% Type: region Subtag: AM Description: Armenia Added: 2005-08-16 %% Type: region Subtag: AN Description: Netherlands Antilles Added: 2005-08-16 %% Type: region Subtag: AO Description: Angola Added: 2005-08-16 %% Type: region Subtag: AQ Description: Antarctica Added: 2005-08-16 %% Type: region Subtag: AR Description: Argentina Ewell Expires February 17, 2006 [Page 72] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: region Subtag: AS Description: American Samoa Added: 2005-08-16 %% Type: region Subtag: AT Description: Austria Added: 2005-08-16 %% Type: region Subtag: AU Description: Australia Added: 2005-08-16 %% Type: region Subtag: AW Description: Aruba Added: 2005-08-16 %% Type: region Subtag: AX Description: Åland Islands Added: 2005-08-16 %% Type: region Subtag: AZ Description: Azerbaijan Added: 2005-08-16 %% Type: region Subtag: BA Description: Bosnia and Herzegovina Added: 2005-08-16 %% Type: region Subtag: BB Description: Barbados Added: 2005-08-16 %% Type: region Subtag: BD Description: Bangladesh Added: 2005-08-16 %% Type: region Ewell Expires February 17, 2006 [Page 73] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: BE Description: Belgium Added: 2005-08-16 %% Type: region Subtag: BF Description: Burkina Faso Added: 2005-08-16 %% Type: region Subtag: BG Description: Bulgaria Added: 2005-08-16 %% Type: region Subtag: BH Description: Bahrain Added: 2005-08-16 %% Type: region Subtag: BI Description: Burundi Added: 2005-08-16 %% Type: region Subtag: BJ Description: Benin Added: 2005-08-16 %% Type: region Subtag: BM Description: Bermuda Added: 2005-08-16 %% Type: region Subtag: BN Description: Brunei Darussalam Added: 2005-08-16 %% Type: region Subtag: BO Description: Bolivia Added: 2005-08-16 %% Type: region Subtag: BR Description: Brazil Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 74] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: BS Description: Bahamas Added: 2005-08-16 %% Type: region Subtag: BT Description: Bhutan Added: 2005-08-16 %% Type: region Subtag: BU Description: Burma Added: 2005-08-16 Preferred-Value: MM Deprecated: 1989-12-05 %% Type: region Subtag: BV Description: Bouvet Island Added: 2005-08-16 %% Type: region Subtag: BW Description: Botswana Added: 2005-08-16 %% Type: region Subtag: BY Description: Belarus Added: 2005-08-16 %% Type: region Subtag: BZ Description: Belize Added: 2005-08-16 %% Type: region Subtag: CA Description: Canada Added: 2005-08-16 %% Type: region Subtag: CC Description: Cocos (Keeling) Islands Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 75] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: CD Description: Congo, The Democratic Republic of the Added: 2005-08-16 %% Type: region Subtag: CF Description: Central African Republic Added: 2005-08-16 %% Type: region Subtag: CG Description: Congo Added: 2005-08-16 %% Type: region Subtag: CH Description: Switzerland Added: 2005-08-16 %% Type: region Subtag: CI Description: Côte d'Ivoire Added: 2005-08-16 %% Type: region Subtag: CK Description: Cook Islands Added: 2005-08-16 %% Type: region Subtag: CL Description: Chile Added: 2005-08-16 %% Type: region Subtag: CM Description: Cameroon Added: 2005-08-16 %% Type: region Subtag: CN Description: China Added: 2005-08-16 %% Type: region Subtag: CO Description: Colombia Ewell Expires February 17, 2006 [Page 76] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: region Subtag: CR Description: Costa Rica Added: 2005-08-16 %% Type: region Subtag: CS Description: Serbia and Montenegro Added: 2005-08-16 %% Type: region Subtag: CU Description: Cuba Added: 2005-08-16 %% Type: region Subtag: CV Description: Cape Verde Added: 2005-08-16 %% Type: region Subtag: CX Description: Christmas Island Added: 2005-08-16 %% Type: region Subtag: CY Description: Cyprus Added: 2005-08-16 %% Type: region Subtag: CZ Description: Czech Republic Added: 2005-08-16 %% Type: region Subtag: DD Description: German Democratic Republic Added: 2005-08-16 Preferred-Value: DE Deprecated: 1990-10-30 %% Type: region Subtag: DE Description: Germany Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 77] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: DJ Description: Djibouti Added: 2005-08-16 %% Type: region Subtag: DK Description: Denmark Added: 2005-08-16 %% Type: region Subtag: DM Description: Dominica Added: 2005-08-16 %% Type: region Subtag: DO Description: Dominican Republic Added: 2005-08-16 %% Type: region Subtag: DZ Description: Algeria Added: 2005-08-16 %% Type: region Subtag: EC Description: Ecuador Added: 2005-08-16 %% Type: region Subtag: EE Description: Estonia Added: 2005-08-16 %% Type: region Subtag: EG Description: Egypt Added: 2005-08-16 %% Type: region Subtag: EH Description: Western Sahara Added: 2005-08-16 %% Type: region Subtag: ER Ewell Expires February 17, 2006 [Page 78] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Eritrea Added: 2005-08-16 %% Type: region Subtag: ES Description: Spain Added: 2005-08-16 %% Type: region Subtag: ET Description: Ethiopia Added: 2005-08-16 %% Type: region Subtag: FI Description: Finland Added: 2005-08-16 %% Type: region Subtag: FJ Description: Fiji Added: 2005-08-16 %% Type: region Subtag: FK Description: Falkland Islands (Malvinas) Added: 2005-08-16 %% Type: region Subtag: FM Description: Micronesia, Federated States of Added: 2005-08-16 %% Type: region Subtag: FO Description: Faroe Islands Added: 2005-08-16 %% Type: region Subtag: FR Description: France Added: 2005-08-16 %% Type: region Subtag: FX Description: Metropolitan France Added: 2005-08-16 Preferred-Value: FR Ewell Expires February 17, 2006 [Page 79] =0C Internet-Draft Initial Language Subtag Registry August 2005 Deprecated: 1997-07-14 %% Type: region Subtag: GA Description: Gabon Added: 2005-08-16 %% Type: region Subtag: GB Description: United Kingdom Added: 2005-08-16 %% Type: region Subtag: GD Description: Grenada Added: 2005-08-16 %% Type: region Subtag: GE Description: Georgia Added: 2005-08-16 %% Type: region Subtag: GF Description: French Guiana Added: 2005-08-16 %% Type: region Subtag: GH Description: Ghana Added: 2005-08-16 %% Type: region Subtag: GI Description: Gibraltar Added: 2005-08-16 %% Type: region Subtag: GL Description: Greenland Added: 2005-08-16 %% Type: region Subtag: GM Description: Gambia Added: 2005-08-16 %% Type: region Ewell Expires February 17, 2006 [Page 80] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: GN Description: Guinea Added: 2005-08-16 %% Type: region Subtag: GP Description: Guadeloupe Added: 2005-08-16 %% Type: region Subtag: GQ Description: Equatorial Guinea Added: 2005-08-16 %% Type: region Subtag: GR Description: Greece Added: 2005-08-16 %% Type: region Subtag: GS Description: South Georgia and the South Sandwich Islands Added: 2005-08-16 %% Type: region Subtag: GT Description: Guatemala Added: 2005-08-16 %% Type: region Subtag: GU Description: Guam Added: 2005-08-16 %% Type: region Subtag: GW Description: Guinea-Bissau Added: 2005-08-16 %% Type: region Subtag: GY Description: Guyana Added: 2005-08-16 %% Type: region Subtag: HK Description: Hong Kong Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 81] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: HM Description: Heard Island and McDonald Islands Added: 2005-08-16 %% Type: region Subtag: HN Description: Honduras Added: 2005-08-16 %% Type: region Subtag: HR Description: Croatia Added: 2005-08-16 %% Type: region Subtag: HT Description: Haiti Added: 2005-08-16 %% Type: region Subtag: HU Description: Hungary Added: 2005-08-16 %% Type: region Subtag: ID Description: Indonesia Added: 2005-08-16 %% Type: region Subtag: IE Description: Ireland Added: 2005-08-16 %% Type: region Subtag: IL Description: Israel Added: 2005-08-16 %% Type: region Subtag: IN Description: India Added: 2005-08-16 %% Type: region Subtag: IO Ewell Expires February 17, 2006 [Page 82] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: British Indian Ocean Territory Added: 2005-08-16 %% Type: region Subtag: IQ Description: Iraq Added: 2005-08-16 %% Type: region Subtag: IR Description: Iran, Islamic Republic of Added: 2005-08-16 %% Type: region Subtag: IS Description: Iceland Added: 2005-08-16 %% Type: region Subtag: IT Description: Italy Added: 2005-08-16 %% Type: region Subtag: JM Description: Jamaica Added: 2005-08-16 %% Type: region Subtag: JO Description: Jordan Added: 2005-08-16 %% Type: region Subtag: JP Description: Japan Added: 2005-08-16 %% Type: region Subtag: KE Description: Kenya Added: 2005-08-16 %% Type: region Subtag: KG Description: Kyrgyzstan Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 83] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: KH Description: Cambodia Added: 2005-08-16 %% Type: region Subtag: KI Description: Kiribati Added: 2005-08-16 %% Type: region Subtag: KM Description: Comoros Added: 2005-08-16 %% Type: region Subtag: KN Description: Saint Kitts and Nevis Added: 2005-08-16 %% Type: region Subtag: KP Description: Korea, Democratic People's Republic of Added: 2005-08-16 %% Type: region Subtag: KR Description: Korea, Republic of Added: 2005-08-16 %% Type: region Subtag: KW Description: Kuwait Added: 2005-08-16 %% Type: region Subtag: KY Description: Cayman Islands Added: 2005-08-16 %% Type: region Subtag: KZ Description: Kazakhstan Added: 2005-08-16 %% Type: region Subtag: LA Description: Lao People's Democratic Republic Ewell Expires February 17, 2006 [Page 84] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: region Subtag: LB Description: Lebanon Added: 2005-08-16 %% Type: region Subtag: LC Description: Saint Lucia Added: 2005-08-16 %% Type: region Subtag: LI Description: Liechtenstein Added: 2005-08-16 %% Type: region Subtag: LK Description: Sri Lanka Added: 2005-08-16 %% Type: region Subtag: LR Description: Liberia Added: 2005-08-16 %% Type: region Subtag: LS Description: Lesotho Added: 2005-08-16 %% Type: region Subtag: LT Description: Lithuania Added: 2005-08-16 %% Type: region Subtag: LU Description: Luxembourg Added: 2005-08-16 %% Type: region Subtag: LV Description: Latvia Added: 2005-08-16 %% Type: region Ewell Expires February 17, 2006 [Page 85] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: LY Description: Libyan Arab Jamahiriya Added: 2005-08-16 %% Type: region Subtag: MA Description: Morocco Added: 2005-08-16 %% Type: region Subtag: MC Description: Monaco Added: 2005-08-16 %% Type: region Subtag: MD Description: Moldova, Republic of Added: 2005-08-16 %% Type: region Subtag: MG Description: Madagascar Added: 2005-08-16 %% Type: region Subtag: MH Description: Marshall Islands Added: 2005-08-16 %% Type: region Subtag: MK Description: Macedonia, The Former Yugoslav Republic of Added: 2005-08-16 %% Type: region Subtag: ML Description: Mali Added: 2005-08-16 %% Type: region Subtag: MM Description: Myanmar Added: 2005-08-16 %% Type: region Subtag: MN Description: Mongolia Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 86] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: MO Description: Macao Added: 2005-08-16 %% Type: region Subtag: MP Description: Northern Mariana Islands Added: 2005-08-16 %% Type: region Subtag: MQ Description: Martinique Added: 2005-08-16 %% Type: region Subtag: MR Description: Mauritania Added: 2005-08-16 %% Type: region Subtag: MS Description: Montserrat Added: 2005-08-16 %% Type: region Subtag: MT Description: Malta Added: 2005-08-16 %% Type: region Subtag: MU Description: Mauritius Added: 2005-08-16 %% Type: region Subtag: MV Description: Maldives Added: 2005-08-16 %% Type: region Subtag: MW Description: Malawi Added: 2005-08-16 %% Type: region Subtag: MX Ewell Expires February 17, 2006 [Page 87] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Mexico Added: 2005-08-16 %% Type: region Subtag: MY Description: Malaysia Added: 2005-08-16 %% Type: region Subtag: MZ Description: Mozambique Added: 2005-08-16 %% Type: region Subtag: NA Description: Namibia Added: 2005-08-16 %% Type: region Subtag: NC Description: New Caledonia Added: 2005-08-16 %% Type: region Subtag: NE Description: Niger Added: 2005-08-16 %% Type: region Subtag: NF Description: Norfolk Island Added: 2005-08-16 %% Type: region Subtag: NG Description: Nigeria Added: 2005-08-16 %% Type: region Subtag: NI Description: Nicaragua Added: 2005-08-16 %% Type: region Subtag: NL Description: Netherlands Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 88] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: NO Description: Norway Added: 2005-08-16 %% Type: region Subtag: NP Description: Nepal Added: 2005-08-16 %% Type: region Subtag: NR Description: Nauru Added: 2005-08-16 %% Type: region Subtag: NT Description: Neutral Zone Added: 2005-08-16 Deprecated: 1993-07-12 %% Type: region Subtag: NU Description: Niue Added: 2005-08-16 %% Type: region Subtag: NZ Description: New Zealand Added: 2005-08-16 %% Type: region Subtag: OM Description: Oman Added: 2005-08-16 %% Type: region Subtag: PA Description: Panama Added: 2005-08-16 %% Type: region Subtag: PE Description: Peru Added: 2005-08-16 %% Type: region Subtag: PF Ewell Expires February 17, 2006 [Page 89] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: French Polynesia Added: 2005-08-16 %% Type: region Subtag: PG Description: Papua New Guinea Added: 2005-08-16 %% Type: region Subtag: PH Description: Philippines Added: 2005-08-16 %% Type: region Subtag: PK Description: Pakistan Added: 2005-08-16 %% Type: region Subtag: PL Description: Poland Added: 2005-08-16 %% Type: region Subtag: PM Description: Saint Pierre and Miquelon Added: 2005-08-16 %% Type: region Subtag: PN Description: Pitcairn Added: 2005-08-16 %% Type: region Subtag: PR Description: Puerto Rico Added: 2005-08-16 %% Type: region Subtag: PS Description: Palestinian Territory, Occupied Added: 2005-08-16 %% Type: region Subtag: PT Description: Portugal Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 90] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: PW Description: Palau Added: 2005-08-16 %% Type: region Subtag: PY Description: Paraguay Added: 2005-08-16 %% Type: region Subtag: QA Description: Qatar Added: 2005-08-16 %% Type: region Subtag: QM..QZ Description: PRIVATE USE Added: 2005-08-16 %% Type: region Subtag: RE Description: Réunion Added: 2005-08-16 %% Type: region Subtag: RO Description: Romania Added: 2005-08-16 %% Type: region Subtag: RU Description: Russian Federation Added: 2005-08-16 %% Type: region Subtag: RW Description: Rwanda Added: 2005-08-16 %% Type: region Subtag: SA Description: Saudi Arabia Added: 2005-08-16 %% Type: region Subtag: SB Description: Solomon Islands Ewell Expires February 17, 2006 [Page 91] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: region Subtag: SC Description: Seychelles Added: 2005-08-16 %% Type: region Subtag: SD Description: Sudan Added: 2005-08-16 %% Type: region Subtag: SE Description: Sweden Added: 2005-08-16 %% Type: region Subtag: SG Description: Singapore Added: 2005-08-16 %% Type: region Subtag: SH Description: Saint Helena Added: 2005-08-16 %% Type: region Subtag: SI Description: Slovenia Added: 2005-08-16 %% Type: region Subtag: SJ Description: Svalbard and Jan Mayen Added: 2005-08-16 %% Type: region Subtag: SK Description: Slovakia Added: 2005-08-16 %% Type: region Subtag: SL Description: Sierra Leone Added: 2005-08-16 %% Type: region Ewell Expires February 17, 2006 [Page 92] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: SM Description: San Marino Added: 2005-08-16 %% Type: region Subtag: SN Description: Senegal Added: 2005-08-16 %% Type: region Subtag: SO Description: Somalia Added: 2005-08-16 %% Type: region Subtag: SR Description: Suriname Added: 2005-08-16 %% Type: region Subtag: ST Description: Sao Tome and Principe Added: 2005-08-16 %% Type: region Subtag: SU Description: Union of Soviet Socialist Republics Added: 2005-08-16 Deprecated: 1992-08-30 %% Type: region Subtag: SV Description: El Salvador Added: 2005-08-16 %% Type: region Subtag: SY Description: Syrian Arab Republic Added: 2005-08-16 %% Type: region Subtag: SZ Description: Swaziland Added: 2005-08-16 %% Type: region Subtag: TC Description: Turks and Caicos Islands Ewell Expires February 17, 2006 [Page 93] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: region Subtag: TD Description: Chad Added: 2005-08-16 %% Type: region Subtag: TF Description: French Southern Territories Added: 2005-08-16 %% Type: region Subtag: TG Description: Togo Added: 2005-08-16 %% Type: region Subtag: TH Description: Thailand Added: 2005-08-16 %% Type: region Subtag: TJ Description: Tajikistan Added: 2005-08-16 %% Type: region Subtag: TK Description: Tokelau Added: 2005-08-16 %% Type: region Subtag: TL Description: Timor-Leste Added: 2005-08-16 %% Type: region Subtag: TM Description: Turkmenistan Added: 2005-08-16 %% Type: region Subtag: TN Description: Tunisia Added: 2005-08-16 %% Type: region Ewell Expires February 17, 2006 [Page 94] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: TO Description: Tonga Added: 2005-08-16 %% Type: region Subtag: TP Description: East Timor Added: 2005-08-16 Preferred-Value: TL Deprecated: 2002-11-15 %% Type: region Subtag: TR Description: Turkey Added: 2005-08-16 %% Type: region Subtag: TT Description: Trinidad and Tobago Added: 2005-08-16 %% Type: region Subtag: TV Description: Tuvalu Added: 2005-08-16 %% Type: region Subtag: TW Description: Taiwan, Province of China Added: 2005-08-16 %% Type: region Subtag: TZ Description: Tanzania, United Republic of Added: 2005-08-16 %% Type: region Subtag: UA Description: Ukraine Added: 2005-08-16 %% Type: region Subtag: UG Description: Uganda Added: 2005-08-16 %% Type: region Subtag: UM Ewell Expires February 17, 2006 [Page 95] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: United States Minor Outlying Islands Added: 2005-08-16 %% Type: region Subtag: US Description: United States Added: 2005-08-16 %% Type: region Subtag: UY Description: Uruguay Added: 2005-08-16 %% Type: region Subtag: UZ Description: Uzbekistan Added: 2005-08-16 %% Type: region Subtag: VA Description: Holy See (Vatican City State) Added: 2005-08-16 %% Type: region Subtag: VC Description: Saint Vincent and the Grenadines Added: 2005-08-16 %% Type: region Subtag: VE Description: Venezuela Added: 2005-08-16 %% Type: region Subtag: VG Description: Virgin Islands, British Added: 2005-08-16 %% Type: region Subtag: VI Description: Virgin Islands, U.S. Added: 2005-08-16 %% Type: region Subtag: VN Description: Viet Nam Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 96] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: VU Description: Vanuatu Added: 2005-08-16 %% Type: region Subtag: WF Description: Wallis and Futuna Added: 2005-08-16 %% Type: region Subtag: WS Description: Samoa Added: 2005-08-16 %% Type: region Subtag: XA..XZ Description: PRIVATE USE Added: 2005-08-16 %% Type: region Subtag: YD Description: Yemen, Democratic Added: 2005-08-16 Preferred-Value: YE Deprecated: 1990-08-14 %% Type: region Subtag: YE Description: Yemen Added: 2005-08-16 %% Type: region Subtag: YT Description: Mayotte Added: 2005-08-16 %% Type: region Subtag: YU Description: Yugoslavia Added: 2005-08-16 Preferred-Value: CS Deprecated: 2003-07-23 %% Type: region Subtag: ZA Description: South Africa Added: 2005-08-16 Ewell Expires February 17, 2006 [Page 97] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: region Subtag: ZM Description: Zambia Added: 2005-08-16 %% Type: region Subtag: ZR Description: Zaire Added: 2005-08-16 Preferred-Value: CD Deprecated: 1997-07-14 %% Type: region Subtag: ZW Description: Zimbabwe Added: 2005-08-16 %% Type: region Subtag: ZZ Description: PRIVATE USE Added: 2005-08-16 %% Type: region Subtag: 001 Description: World Added: 2005-08-16 %% Type: region Subtag: 002 Description: Africa Added: 2005-08-16 %% Type: region Subtag: 005 Description: South America Added: 2005-08-16 %% Type: region Subtag: 009 Description: Oceania Added: 2005-08-16 %% Type: region Subtag: 011 Description: Western Africa Added: 2005-08-16 %% Ewell Expires February 17, 2006 [Page 98] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: region Subtag: 013 Description: Central America Added: 2005-08-16 %% Type: region Subtag: 014 Description: Eastern Africa Added: 2005-08-16 %% Type: region Subtag: 015 Description: Northern Africa Added: 2005-08-16 %% Type: region Subtag: 017 Description: Middle Africa Added: 2005-08-16 %% Type: region Subtag: 018 Description: Southern Africa Added: 2005-08-16 %% Type: region Subtag: 019 Description: Americas Added: 2005-08-16 %% Type: region Subtag: 021 Description: Northern America Added: 2005-08-16 %% Type: region Subtag: 029 Description: Caribbean Added: 2005-08-16 %% Type: region Subtag: 030 Description: Eastern Asia Added: 2005-08-16 %% Type: region Subtag: 034 Description: Southern Asia Ewell Expires February 17, 2006 [Page 99] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 %% Type: region Subtag: 035 Description: South-Eastern Asia Added: 2005-08-16 %% Type: region Subtag: 039 Description: Southern Europe Added: 2005-08-16 %% Type: region Subtag: 053 Description: Australia and New Zealand Added: 2005-08-16 %% Type: region Subtag: 054 Description: Melanesia Added: 2005-08-16 %% Type: region Subtag: 057 Description: Micronesia Added: 2005-08-16 %% Type: region Subtag: 061 Description: Polynesia Added: 2005-08-16 %% Type: region Subtag: 142 Description: Asia Added: 2005-08-16 %% Type: region Subtag: 143 Description: Central Asia Added: 2005-08-16 %% Type: region Subtag: 145 Description: Western Asia Added: 2005-08-16 %% Type: region Ewell Expires February 17, 2006 [Page 100] =0C Internet-Draft Initial Language Subtag Registry August 2005 Subtag: 150 Description: Europe Added: 2005-08-16 %% Type: region Subtag: 151 Description: Eastern Europe Added: 2005-08-16 %% Type: region Subtag: 154 Description: Northern Europe Added: 2005-08-16 %% Type: region Subtag: 155 Description: Western Europe Added: 2005-08-16 %% Type: region Subtag: 419 Description: Latin America and the Caribbean Added: 2005-08-16 %% Type: variant Subtag: 1901 Description: Traditional German orthography Added: 2005-08-16 Prefix: de %% Type: variant Subtag: 1996 Description: German orthography of 1996 Added: 2005-08-16 Prefix: de %% Type: variant Subtag: nedis Description: Natisone dialect Description: Nadiza dialect Added: 2005-08-16 Prefix: sl %% Type: variant Subtag: rozaj Description: Resian Description: Resianic Description: Rezijan Ewell Expires February 17, 2006 [Page 101] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2005-08-16 Prefix: sl %% Type: grandfathered Tag: art-lojban Description: Lojban Added: 2001-11-11 Preferred-Value: jbo Deprecated: 2003-09-02 Comments: replaced by ISO code jbo %% Type: grandfathered Tag: cel-gaulish Description: Gaulish Added: 2001-05-25 %% Type: grandfathered Tag: en-boont Description: Boontling Added: 2003-02-14 %% Type: grandfathered Tag: en-GB-oed Description: English, Oxford English Dictionary spelling Added: 2003-07-09 %% Type: grandfathered Tag: en-scouse Description: Scouse Added: 2000-05-25 %% Type: grandfathered Tag: i-ami Description: 'Amis Added: 1999-05-25 %% Type: grandfathered Tag: i-bnn Description: Bunun Added: 1999-05-25 %% Type: grandfathered Tag: i-default Description: Default Language Added: 1998-03-10 %% Type: grandfathered Tag: i-enochian Ewell Expires February 17, 2006 [Page 102] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Enochian Added: 2002-07-03 %% Type: grandfathered Tag: i-hak Description: Hakka Added: 1999-01-31 Preferred-Value: zh-hakka Deprecated: 2000-01-10 %% Type: grandfathered Tag: i-klingon Description: Klingon Added: 1999-05-26 Preferred-Value: tlh Deprecated: 2004-02-24 Comments: replaced by ISO code tlh %% Type: grandfathered Tag: i-lux Description: Luxembourgish Added: 1997-09-19 Preferred-Value: lb Deprecated: 1998-09-09 Comments: replaced by ISO code lb %% Type: grandfathered Tag: i-mingo Description: Mingo Added: 1997-09-19 %% Type: grandfathered Tag: i-navajo Description: Navajo Added: 1997-09-19 Preferred-Value: nv Deprecated: 2000-02-18 Comments: replaced by ISO code nv %% Type: grandfathered Tag: i-pwn Description: Paiwan Added: 1999-05-25 %% Type: grandfathered Tag: i-tao Description: Tao Added: 1999-05-25 Ewell Expires February 17, 2006 [Page 103] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: grandfathered Tag: i-tay Description: Tayal Added: 1999-05-25 %% Type: grandfathered Tag: i-tsu Description: Tsou Added: 1999-05-25 %% Type: grandfathered Tag: no-bok Description: Norwegian Bokmal Added: 1995-08-23 Preferred-Value: nb Deprecated: 2000-02-18 Comments: replaced by ISO code nb %% Type: grandfathered Tag: no-nyn Description: Norwegian Nynorsk Added: 1995-08-23 Preferred-Value: nn Deprecated: 2000-02-18 Comments: replaced by ISO code nn %% Type: grandfathered Tag: sgn-BE-fr Description: Belgian-French Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: sgn-BE-nl Description: Belgian-Flemish Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: sgn-CH-de Description: Swiss German Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: zh-cmn Description: Mandarin Chinese Added: 2005-07-15 %% Type: grandfathered Ewell Expires February 17, 2006 [Page 104] =0C Internet-Draft Initial Language Subtag Registry August 2005 Tag: zh-cmn-Hans Description: Mandarin Chinese (Simplified) Added: 2005-07-15 %% Type: grandfathered Tag: zh-cmn-Hant Description: Mandarin Chinese (Traditional) Added: 2005-07-15 %% Type: grandfathered Tag: zh-gan Description: Kan or Gan Added: 1999-12-18 %% Type: grandfathered Tag: zh-guoyu Description: Mandarin or Standard Chinese Added: 1999-12-18 Preferred-Value: zh-cmn Deprecated: 2005-07-15 %% Type: grandfathered Tag: zh-hakka Description: Hakka Added: 1999-12-18 %% Type: grandfathered Tag: zh-min Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese Added: 1999-12-18 %% Type: grandfathered Tag: zh-min-nan Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern Fujian, Hoklo, Southern Fukien, Ho-lo Added: 2001-03-26 %% Type: grandfathered Tag: zh-wuu Description: Shanghaiese or Wu Added: 1999-12-18 %% Type: grandfathered Tag: zh-xiang Description: Xiang or Hunanese Added: 1999-12-18 %% Type: grandfathered Ewell Expires February 17, 2006 [Page 105] =0C Internet-Draft Initial Language Subtag Registry August 2005 Tag: zh-yue Description: Cantonese Added: 1999-12-18 %% Type: redundant Tag: az-Arab Description: Azerbaijani in Arabic script Added: 2003-05-30 %% Type: redundant Tag: az-Cyrl Description: Azerbaijani in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: az-Latn Description: Azerbaijani in Latin script Added: 2003-05-30 %% Type: redundant Tag: be-Latn Description: Belarusian in Latin script Added: 2005-01-06 %% Type: redundant Tag: bs-Cyrl Description: Bosnian in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: bs-Latn Description: Bosnian in Latin script Added: 2005-02-17 %% Type: redundant Tag: de-1901 Description: German, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-1996 Description: German, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-AT-1901 Description: German, Austrian variant, traditional orthography Added: 2001-07-17 Ewell Expires February 17, 2006 [Page 106] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: redundant Tag: de-AT-1996 Description: German, Austrian variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-CH-1901 Description: German, Swiss variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-CH-1996 Description: German, Swiss variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-DE-1901 Description: German, German variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-DE-1996 Description: German, German variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: es-419 Description: Latin American Spanish Added: 2005-07-15 %% Type: redundant Tag: iu-Cans Description: Inuktitut in Canadian Aboriginal Syllabic script Added: 2005-02-17 %% Type: redundant Tag: iu-Latn Description: Inuktitut in Latin script Added: 2005-02-17 %% Type: redundant Tag: mn-Cyrl Description: Mongolian in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: mn-Mong Ewell Expires February 17, 2006 [Page 107] =0C Internet-Draft Initial Language Subtag Registry August 2005 Description: Mongolian in Mongolian script Added: 2005-02-17 %% Type: redundant Tag: sgn-BR Description: Brazilian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-CO Description: Colombian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-DE Description: German Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-DK Description: Danish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-ES Description: Spanish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-FR Description: French Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-GB Description: British Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-GR Description: Greek Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-IE Description: Irish Sign Language Added: 2001-03-02 %% Ewell Expires February 17, 2006 [Page 108] =0C Internet-Draft Initial Language Subtag Registry August 2005 Type: redundant Tag: sgn-IT Description: Italian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-JP Description: Japanese Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-MX Description: Mexican Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-NI Description: Nicaraguan Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-NL Description: Dutch Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-NO Description: Norwegian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-PT Description: Portuguese Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-SE Description: Swedish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-US Description: American Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-ZA Description: South African Sign Language Ewell Expires February 17, 2006 [Page 109] =0C Internet-Draft Initial Language Subtag Registry August 2005 Added: 2001-11-11 %% Type: redundant Tag: sl-nedis Description: Natisone dialect, Nadiza dialect Added: 2004-06-01 %% Type: redundant Tag: sl-rozaj Description: Resian, Resianic, Rezijan Added: 2003-10-09 %% Type: redundant Tag: sr-Cyrl Description: Serbian in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: sr-Latn Description: Serbian in Latin script Added: 2003-05-30 %% Type: redundant Tag: tg-Arab Description: Tajik in Arabic script Added: 2005-02-17 %% Type: redundant Tag: tg-Cyrl Description: Tajik in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: uz-Cyrl Description: Uzbek in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: uz-Latn Description: Uzbek in Latin script Added: 2003-05-30 %% Type: redundant Tag: yi-latn Description: Yiddish, in Latin script Added: 2003-01-07 %% Type: redundant Ewell Expires February 17, 2006 [Page 110] =0C Internet-Draft Initial Language Subtag Registry August 2005 Tag: zh-Hans Description: simplified Chinese Added: 2003-05-30 %% Type: redundant Tag: zh-Hans-CN Description: PRC Mainland Chinese in simplified script Added: 2005-04-13 %% Type: redundant Tag: zh-Hans-HK Description: Hong Kong Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-MO Description: Macao Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-SG Description: Singapore Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-TW Description: Taiwan Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant Description: traditional Chinese Added: 2003-05-30 %% Type: redundant Tag: zh-Hant-CN Description: PRC Mainland Chinese in traditional script Added: 2005-04-13 %% Type: redundant Tag: zh-Hant-HK Description: Hong Kong Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-MO Description: Macao Chinese in traditional script Added: 2005-04-11 Ewell Expires February 17, 2006 [Page 111] =0C Internet-Draft Initial Language Subtag Registry August 2005 %% Type: redundant Tag: zh-Hant-SG Description: Singapore Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-TW Description: Taiwan Chinese in traditional script Added: 2005-04-11 Ewell Expires February 17, 2006 [Page 112] =0C Internet-Draft Initial Language Subtag Registry August 2005 4. Omitted Code Elements The following code elements from [UN_M.49] were not associated with [ISO3166-1] alpha-2 code elements. Consequently, they were not assigned as subtags in the initial Language Subtag Registry, but are valid candidates for registration as region subtags, using the process in [I-D.ietf-ltru-registry]: 830 Channel Islands 831 Guernsey 832 Jersey 833 Isle of Man Ewell Expires February 17, 2006 [Page 113] =0C Internet-Draft Initial Language Subtag Registry August 2005 5. Security Considerations This document specifies the initial contents to be used by IANA in populating the Language Subtag Registry. For security considerations relevant to that registry and the use of language tags, see [I-D.ietf-ltru-registry]. Ewell Expires February 17, 2006 [Page 114] =0C Internet-Draft Initial Language Subtag Registry August 2005 6. IANA Considerations This document provides the initial content for the Language Subtag Registry to be maintained by IANA. For details on the procedures for the format and ongoing maintenance of this registry, see [I-D.ietf- ltru-registry]. Ewell Expires February 17, 2006 [Page 115] =0C Internet-Draft Initial Language Subtag Registry August 2005 7. References 7.1. Normative References [I-D.ietf-ltru-registry] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", August 2005. 7.2. Informative References [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166: 1988. Codes for the representation of names of countries, 3rd edition", August 1988. [ISO639-1] International Organization for Standardization, "ISO 639- 1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", 2002. [ISO639-2] International Organization for Standardization, "ISO 639- 2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition", 1998. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", UN Standard Country or Area Codes for Statistical Use, Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. [record-jar] Raymond, E., "The Art of Unix Programming", 2003. Ewell Expires February 17, 2006 [Page 116] =0C Internet-Draft Initial Language Subtag Registry August 2005 Author's Address Doug Ewell (editor) Email: dewell@adelphia.net URI: http://users.adelphia.net/~dewell Ewell Expires February 17, 2006 [Page 117] =0C Internet-Draft Initial Language Subtag Registry August 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ewell Expires February 17, 2006 [Page 118] =0C ------=_NextPart_000_0049_01C5A2A3.871079A0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_0049_01C5A2A3.871079A0-- From ltru-bounces@lists.ietf.org Tue Aug 16 23:53:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ezv-0005de-Ti; Tue, 16 Aug 2005 23:53:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ezu-0005dY-21 for ltru@megatron.ietf.org; Tue, 16 Aug 2005 23:53:50 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04957 for ; Tue, 16 Aug 2005 23:53:46 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050817035317.UGIE14360.mta13.adelphia.net@DEWELL> for ; Tue, 16 Aug 2005 23:53:17 -0400 Message-ID: <005901c5a2df$2aab4000$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 16 Aug 2005 20:53:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Submission: LTRU initial-registry draft-04 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Please note that draft-initial-04 includes a primary language subtag for the new ISO 639 alpha-3 code "ain" (for Ainu) that was announced Tuesday. According to Section 2 of draft-initial-04, item 2, code elements assigned in the ISO source standards up to the date of adoption of draft-registry ("Date B") are added to the initial registry automatically. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 06:29:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5LAy-00073O-MP; Wed, 17 Aug 2005 06:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5LAw-000734-KU for ltru@megatron.ietf.org; Wed, 17 Aug 2005 06:29:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19747 for ; Wed, 17 Aug 2005 06:29:34 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5LkR-0002RL-0i for ltru@ietf.org; Wed, 17 Aug 2005 07:06:20 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j7HAT5u25915; Wed, 17 Aug 2005 19:29:05 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id c945d4c8_0f09_11da_9bc9_0030482533a1_16909; Wed, 17 Aug 2005 19:29:26 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO002C88; 17 Aug 05 19:29:42 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 17 Aug 05 19:29:33 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.66) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG002C82; 17 Aug 05 19:29:31 +0900 Message-Id: <6.0.0.20.2.20050817112633.07d7bd80@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 17 Aug 2005 11:49:35 +0900 To: r&d afrac , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: WGLC security considerations (mostly off topic) In-Reply-To: <6.2.1.2.2.20050817004329.0560c460@mail.afrac.org> References: <6.2.1.2.2.20050817004329.0560c460@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org [chair hat off, and mostly off topic] At 07:44 05/08/17, r&d afrac wrote: >The specific risks due to the language tags are numerous. I will identify three of them: > >- risk of confusion as they introduce non network related information where network related information is needed. This risk is structural and may substantially delay the architectural development of the Internet due to its probable support by dominant actors. I doubt the authors will document it. This is the main risk I fight in opposing their Draft. I'm very much affraid that the reason the authors won't document this 'risk' is because it does not exist, or if it exists, it hasn't been expressed in a way that is understandable. To reasonably claim that "the probable support of RFC 3066bis by dominant actors risks to substantially delay the architectural development of the Internet" needs quite a bit more than just to write down these words in an email. RFC 3066bis does not in any way prohibit any kind of community to get tags or subtags registered for their language(s). And I have no idea how RFC 3066bis could otherwise affect Internet architecture; surely it's totally unrelated to real architecture issues such as IP number allocation and network topology. >- individual risks on content (filtering, censoring, etc.) and on persons (identification, privacy violation, etc.). This kind of risk is never absolute: it lies in its increase. There is a difference between sending an information on a post card and in a letter under envelope because opening all the envelopes costs time and money. Language tags greatly simplifies the intelligence gathering, filtering, spying, censoring ... and their errors. Not considering language tags in OPES context for example is big mistake. But the main issue is that the user cannot turn it down. (NB. This risks could have been greatly reduced through flexible "x-tags" and "0-" escape sequence. Of course if e.g. everybody uses random or close to random tags for denoting languages, there is no risk that these random tags are used for identification (of persons). But the purpose of language tags is the identification of languages, and for that, random or privately assigned tags are no good. >I have no doubt people will die and suffer because of the ABNF. Standardisation is also a risky activity.) I'm sure people have died and suffered because Gutenberg invented printing, or because Tim Berners-Lee invented the Web. Should we prohibit these technologies? >- global risks. Let say the "9am-5pm" orientation of the Draft is well known and will be increasingly known. The irritation resulting from the limitations to cultural lifes and innovation all over the world this draft will lead to, There is some 9am-5pm aspect in the draft, in that it makes standard cases more straightforward that RFC 3066. In my view, that's a good thing. However, it's totally wrong to conclude from that that this will negatively affect cultural lives and innovation anywhere in the world. If there is any kind of language that doesn't have a tag yet, then the draft provides easy ways to register a tag for it. If there are new languages invented or emerging, the same applies. >and the probable impact on IANA and IETF image, may be a direct or indirect triggering factor in many nasty events to come (I am sure you do not need I dwell on that point). The chances of this risk have decreased. The ABNF rigidity against our Open Source/Standard proposition, This is the first time I have seen somebody claim that a clear ABNF is adverse to Open Source. A clear ABNF indeed is very helpful for Open Source, because it makes implementation straightforward rather than guesswork. >the resulting delays in excluding us, the exposure of the commercial interests involved will most probably now lead the WSIS Internet Governance Forum to take over the issue. > >A related risk would be that all this would delay a serious Internet Multilingual Framework. This is a matter on which we now actively work. I know people are using whatever language they please for Web pages, email, and so on. There are still many points where technology needs to be improved, but most of the basic framework is around. If you have something better, I very much hope it consists of more than just a few buzzwords and some "I want my tags the way I want them" implementation just for implementation's sake. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 06:29:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5LAy-00073k-RU; Wed, 17 Aug 2005 06:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5LAw-000735-KW for ltru@megatron.ietf.org; Wed, 17 Aug 2005 06:29:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19757 for ; Wed, 17 Aug 2005 06:29:35 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5LkR-0002RG-0i for ltru@ietf.org; Wed, 17 Aug 2005 07:06:21 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j7HAT4d06362; Wed, 17 Aug 2005 19:29:04 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id c8c13150_0f09_11da_9bc9_0030482533a1_16909; Wed, 17 Aug 2005 19:29:25 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO002C87; 17 Aug 05 19:29:42 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 17 Aug 05 19:29:33 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.66) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG002C81; 17 Aug 05 19:29:30 +0900 Message-Id: <6.0.0.20.2.20050817112458.073fd6b0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 17 Aug 2005 11:25:37 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: WGLC security considerations In-Reply-To: <43023A7C.413D@xyzzy.claranet.de> References: <6.2.1.2.2.20050816165420.04bc4910@pop.online.fr> <43023A7C.413D@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org (chair hat off) At 04:11 05/08/17, Frank Ellermann wrote: >Jefsey Morfin wrote: > >> I think the following text would be more appropriate: >[...] > >The shorter version addresses the main issue more precisely. I completely agree. >Your longer proposal is too broad, it covers more than only >language tags, it's applicable to most kinds of information >exchange. > >Putting vague threats related to many kinds of communication >- not only language tags - in the "security considerations" >would be a bad idea. We were supposed to identify _specific_ >risks. not _general_ issues. I agree again. Regards, Martin. > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 08:50:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNc-0005Y2-8B; Wed, 17 Aug 2005 08:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNY-0005WR-DD for ltru@megatron.ietf.org; Wed, 17 Aug 2005 08:50:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27765 for ; Wed, 17 Aug 2005 08:50:46 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Nx5-0006i7-Gu for ltru@ietf.org; Wed, 17 Aug 2005 09:27:32 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E5NNS-0000Y0-Ri; Wed, 17 Aug 2005 05:50:43 -0700 Message-Id: <6.2.1.2.2.20050817132719.056a2400@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 17 Aug 2005 13:37:20 +0200 To: "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1103] WGLC Add File-level Description field In-Reply-To: <003801c5a28d$63bdd1c0$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C72BA7D@irvmbxw01.quest.com> <007701c5a1ee$f284b940$7f1afea9@oemcomputer> <6.2.1.2.2.20050816022623.04c0bc00@mail.afrac.org> <000001c5a203$7e2235e0$7f1afea9@oemcomputer> <6.2.1.2.2.20050816120148.04bece10@mail.afrac.org> <003801c5a28d$63bdd1c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 20:07 16/08/2005, Randy Presuhn wrote: >"Remulac" is a reference to old comedic sketches featuring >Dan Aykroyd and Jane Curtin. They help me make sense >of some of the postings on this list. :-) Dear Randy, too bad you do not even read what you respond to ... > > NB. REMULAC: Network-aware applications can adjust their resource demands > > in response to changes in the availability of resources. The Remulac > > project (Resource Management under Language and Application Control) > > investigates the design, specification, implementation and evaluation of a > > software platform for network-aware applications. Such applications must be > > able to obtain information about the current status of the network > > resources. The Remulac project was carried by Carnegie Mellon as DARPA > > order J342. tst. tst ... > > This is probably not the Remulac which was alluded to, but ... confirming this way you have missed the whole issue: > > it turns to be the main missing consideration of this WG: to deliver a > > language tag appropriate to network-aware applications' and users' resource > > (inluding language availability) management - whatever the language, the > > media and the mode. Unless you expressly ask for it, I will not attach your response to the note on this incident, as I feel it would deserve your position? More Hollywood than digital network oriented culture? I cannot blame it as fantasy is more fun, but the later is more useful for standardisers. Take care: Tags Wars III will be interesting. "Je dis" we will see Dark Randy redeamed in Tag Wars VI ! jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 08:50:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNc-0005YY-La; Wed, 17 Aug 2005 08:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNY-0005WP-Dt for ltru@megatron.ietf.org; Wed, 17 Aug 2005 08:50:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27755 for ; Wed, 17 Aug 2005 08:50:46 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Nx5-0006i8-Gi for ltru@ietf.org; Wed, 17 Aug 2005 09:27:31 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E5NNR-0000Y0-NR; Wed, 17 Aug 2005 05:50:42 -0700 Message-Id: <6.2.1.2.2.20050817130022.045a73c0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 17 Aug 2005 13:24:36 +0200 To: Martin Duerst , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: WGLC security considerations (mostly off topic) In-Reply-To: <6.0.0.20.2.20050817112633.07d7bd80@itmail.it.aoyama.ac.jp> References: <6.2.1.2.2.20050817004329.0560c460@mail.afrac.org> <6.0.0.20.2.20050817112633.07d7bd80@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Martin, I am sorry but your considerations are actually mostly off topic of the current debate reality (except when you acknowledge people will die because of the Draft you do not want to warn through the Security Section). So I will not comment them (unless it means that you consider that the Draft drops its claim to become BCP 47?). I address that point in another mail. Now, I suggest you are assigned the job of Sheperding Chair. It would lead you to read the information we provided and you seem to have not read however a co-Chair...[but you had mail problems]. I am not sure that your mail enters into the normal conflict reduction effort a Chair must attempt - I am still waiting for your response to the questions you engaged. At 04:49 17/08/2005, Martin Duerst wrote: >I very much hope it consists of more than just a few buzzwords and some "I >want my tags the way I want them" implementation just for implementation's >sake. However, I am glad to find here a good definition of our positions. You (the WGAG [affinity group]) says: long out-of-scope text and "I want the Internet language tags the way I want them". My position is: let provide a simple, clear, scalable framework and "I want the users tags the way the users want them". Since Addison chose this to be a competition instead of an IETF consensus, let the users decide what is the best proposition. All the best. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 08:50:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNc-0005Yz-SE; Wed, 17 Aug 2005 08:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNY-0005WQ-DT for ltru@megatron.ietf.org; Wed, 17 Aug 2005 08:50:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27759 for ; Wed, 17 Aug 2005 08:50:46 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Nx5-0006hw-Gm for ltru@ietf.org; Wed, 17 Aug 2005 09:27:32 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E5NNP-0000Y0-Dm; Wed, 17 Aug 2005 05:50:39 -0700 Message-Id: <6.2.1.2.2.20050817120052.056417b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 17 Aug 2005 14:50:35 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: WGLC security considerations In-Reply-To: <43029C9F.3510@xyzzy.claranet.de> References: <6.2.1.2.2.20050817004329.0560c460@mail.afrac.org> <43029C9F.3510@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 04:10 17/08/2005, Frank Ellermann wrote: >r&d afrac wrote: > > > The specific risks due to the language tags are numerous. I > > will identify three of them: > > > - risk of confusion as they introduce non network related > > information where network related information is needed. > > This risk is structural > >In other words it's a feature and no bug, unavoidable, if an >evil party wants to censor say "ARAB" they can (try to) do >this. I could also do it for completely harmless reasons, >because I cannot read this script. > >That's nothing new, everybody knows it, it's also applicable >on charsets. Your concept of "non network related information" >makes no sense for me. Language tags and / or charsets are >"network related". Frank, I am afraid you miss the point here. What is considered is the nature of the information which does not match the needed nature. The information passed in langtags defined by the Draft necessarily consider a language as something probably totally different from the way a network-aware application or network user will consider it. Necessarily because it is related to ISO 639 which does not define language in a network environement and because the Draft does not say how it adapts the ISO lists to an IETF protocol. A simple example is that the computer languages are not supported. I do not know what is/is not a computer language. When I filter English with DoD programs to evaluate their complexity am I refering to plain English or to a computer acceptable language? When I use "English" as a programmation Language in an IA or Pick or else environment what is it? There are many computer scripts which are totally understandable by humans. What is "basic English"? Is it documented? The systems we work on are to support billions of language variations, to support every individual's avatars and computerised tools (not big deal, just standard internet architecture - but used in a distributed way, not in a centrally controlled way), how can the language tags support that in a human readable/mnemonic way? The risks of confusion, innovation blockage, etc. is not only for the Draft application. It has been fully documented by the way this WG has receieved our current work. > > Language tags greatly simplifies the intelligence gathering, > > filtering, spying, censoring ... and their errors. > >Yes, I know that risk since I tried to "spamcop" a mail from >Martin because it had a 2047 subject with a Japanese charset. > >There are uses, abuses, and errors. Not very surprising, that >is obvious. The purpose of the security section is to document all the risks increase a user may run into in applying the document. This has nothing to do with the fact the document is good or not. Except that the document is bad if it does not provide a full review of the risks increases. > > Not considering language tags in OPES context for example is > > big mistake. > >Let the OPES folks address it in their documents, it's not >different from the situation as it is today (before 3066bis). ??? I am afraid you have missed the purpose of the Draft then. And of the Security section. IRT OPES folks, if I am here it is because of the disregard of the OPES which are not an issue of the WG-OPES (which have published difficulties understanding the matter which is complex) but an issue related to the IAB RFC 3238 on the matter. This will certainly be a point to be risen in a request for IAB guidance in IAB level appeal. > > But the main issue is that the user cannot turn it down. > >Of course you can, nothing forces you to spell out say "TW" if >you think that this might hurt the propagation to "CN". ??? You are to receive the langtags sent by the sender, that you like it or not. To some extent, OPES are a danger used by a foe, and an help to remove them if used by a friend. > > I have no doubt people will die and suffer because of the > > ABNF. > >Assuming that the "TW" example is dangerous, then using x-tw1 >to "avoid" this risk is 1) allowed 2) won't help. The worst >you can do for privacy and anonymity are _false_ promises. Again, the point is not to address the problem. The point is to list it. Possibly document it. It is to the users to decide using it or not, considering its con and pros. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 08:50:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNd-0005ZN-1C; Wed, 17 Aug 2005 08:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNY-0005WU-Jd for ltru@megatron.ietf.org; Wed, 17 Aug 2005 08:50:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27768 for ; Wed, 17 Aug 2005 08:50:47 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Nx5-0006il-OA for ltru@ietf.org; Wed, 17 Aug 2005 09:27:32 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E5NNU-0000Y0-A0; Wed, 17 Aug 2005 05:50:44 -0700 Message-Id: <6.2.1.2.2.20050817134148.031935b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 17 Aug 2005 14:29:08 +0200 To: "Randy Presuhn" , duerst@itmail.it.aoyama.ac.jp, "Scott Hollenbeck" From: r&d afrac Subject: Re: [Ltru] Re: appeal intent report to ADs In-Reply-To: <037401c5a2bc$feae14e0$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050817004910.031432e0@pop.online.fr> <037401c5a2bc$feae14e0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 01:48 17/08/2005, Randy Presuhn wrote: >If you're planning to appeal an IESG decision, this WG isn't the >place to do it. Section 6.5.2 of RFC 2026 makes the IAB responsible >for handling such appeals. Dear Randy, I do not understand your answers since you quote the proper references. 1. RFC 2026 6.5 describes the appeal procedures. This mail is an attempt to help you start an effort towards a compromise you did not engage. >The report Martin and I are required to provide 2. The document you quote says that this report is by the Shepherding Chair. I will wait for his designation. >to our responsible AD >is in anticipation of likely appeals of working group decisions, per >section 6.5.1 of RFC 2026 and section 3.1 (1.f) of >http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt 3. This document says: "1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director." In the case you missed it, I fall in the category of this anyone. I suppose that an incorrect description of my positions will only delay the whole process and lower the WG credibility. This is why I proposed to help. I note that you refused that help. >I do suggest you take a look at section 5 of RFC 2026, as your >understanding of the significance of the "BCP" designation doesn't >appear to be supported by its definition there. A BCP can be: 1. good user service common guidelines for policies and operations different in scope and style from protocol standards. 2. a way for entities such as IAB/IESG to insert proposals into the consensus-building machinery of the IETF while gauging the community's view of that issue. 3. to document the operation of the IETF itself. For example, this document defines the IETF Standards Process and is published as a BCP. (1) seems unlikely since the Draft introduces standard track issues conflicting with open source/standard works and projects. (2) I thought it was a way for W3C and Unicode to introduce their proposals, but Addison Philip documented he did not represent the W3C (Mark Davis refused to comment and to inform the WG on the CLDR he directs and which is included in the Charter). (3) the title of the WG is "Language Tags Registry Update". The non-studied Charter says "It will describe the structure of the IANA registry and how the registered tags will relate to the generative mechanisms". I take that this intended BCP is to ascertain the control of this IANA registry to the benefit of the "ietf-languages@alvestrand.no" mailing list and through an excluding format, leading the users of other formats more appropriate to their needs to adopt non-IANA/IETF solutions, increasing the balkanisation of the Internet. I formally oppose this excluding proposition I consider as highly detrimental to the Internet. And will continue to engage every effort I can pursue to fight the internet balkanisation as a response to its partition necessity, all the more when I feel the motivation is not a common but a commercial interest for the very reasons documented by IAB in RFC 3869. jfc morfin > > From: "r&d afrac" > > To: "Randy Presuhn" > > Cc: "Scott Hollenbeck" ; > > Sent: Tuesday, August 16, 2005 4:11 PM > > Subject: appeal intent report to ADs > > > > Dear Randy, > > you have adopted a procedure which makes you (or Martin) to report the ADs > > the documented motives of the appeals I announced, should the IETF Last > > Call lead to a positive IESG decision, regarding the Draft you made > > proposed by Addison Philips and Mark Davis. I am certainly ready to help > > reviewing this report, so the AD get a complete and clear picture. This may > > be an occasion for clarifications, and to agree on our disagreements. > > > > I think that this Draft would deeply harm the Internet should it continue > > to claim being a BCP documenting an exclusive global Internet language > > tagging. But I also think that if this Draft brings a transitional response > > to specific needs, it must go through as a standard track specific document > > (having not studied the Charter in common, I trusted blindly Addison on > > this until he said he did not spoke on behalf the W3C: this is the reason > > of my "if"). In such a case both the Internet standard process and the > > anti-open standard ABNF provisions parts should obviously be removed as out > > of the new scope. > > > > jfc > > > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 08:50:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNc-0005YO-Fe; Wed, 17 Aug 2005 08:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NNY-0005WS-Dc for ltru@megatron.ietf.org; Wed, 17 Aug 2005 08:50:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27762 for ; Wed, 17 Aug 2005 08:50:46 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Nx5-0006i0-Gq for ltru@ietf.org; Wed, 17 Aug 2005 09:27:32 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E5NNQ-0000Y0-Ip; Wed, 17 Aug 2005 05:50:40 -0700 Message-Id: <6.2.1.2.2.20050817123041.045a0320@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 17 Aug 2005 12:57:42 +0200 To: "Peter Constable" , From: r&d afrac Subject: RE: [Ltru] Re: WGLC security considerations In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 01:22 17/08/2005, Peter Constable wrote: >JFC appears to be using this thread as an excuse to open up various >topics on which he has a personal ax to grind. Dear Peter, "x-" not "ax". I am afraid you confuse the origin and the result. The purpose of the Security Section is to detail the risk increases. You certainly are one of the originator of that risks. Your rationale is probably to consider that the return is worth them. And you should document why, in your own words. Hiding them, as you seem to want it, would only tend to prove that the return is for you and not for the user. >I wish to dissociate my >qualified support for his original issue regarding specific text in >section 6 of the draft from his further input, which I find to be at >best not particularly good arguments for change to that section and at >worst wholly off topic. As mentioned in my response, I consider that your text is a reasonable improvement over the current text. The problem in dissociating yourself now is that I will propose that text in appeal as an acceptable compromise. >Also, given that the WG last call is closed, I have no interest in nor >see any particular value in extending this thread. As mentioned earlier, >I think certain improvements to section could be made but that they not >essential and certainly not worth any further delay of this draft. This is a real and constant misunderstanding of the IETF process. Work on Drafts are to be carried in WGs. Not during the IETF last call as suggested by some and implicitly considered by you. The verdict will probably further DISCUSS and delays. I do not object, since I think that this Draft is to be discussed within the WSIS Multilingualisation Fora. But please do not claim that I delayed the process. Had we have followed a common sense approach I proposed we would most probably have a acceptable to all (except to you may be?) RFC by now. "Qui top embrasse mal etreint". jfc >Peter Constable > > > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On Behalf Of r&d > > afrac > > Sent: Tuesday, August 16, 2005 3:44 PM > > To: ltru@ietf.org > > Subject: Re: [Ltru] Re: WGLC security considerations > > > > On 21:11 16/08/2005, Frank Ellermann said: > > >Jefsey Morfin wrote: > > > > I think the following text would be more appropriate: > > >[...] > > > > > >The shorter version addresses the main issue more precisely. > > > > > >Your longer proposal is too broad, it covers more than only > > >language tags, it's applicable to most kinds of information > > >exchange. > > > > > >Putting vague threats related to many kinds of communication > > >- not only language tags - in the "security considerations" > > >would be a bad idea. We were supposed to identify _specific_ > > >risks. not _general_ issues. > > > > Dear Frank, > > The specific risks due to the language tags are numerous. I will >identify > > three of them: > > > > - risk of confusion as they introduce non network related information >where > > network related information is needed. This risk is structural and may > > substantially delay the architectural development of the Internet due >to > > its probable support by dominant actors. I doubt the authors will >document > > it. This is the main risk I fight in opposing their Draft. > > > > - individual risks on content (filtering, censoring, etc.) and on >persons > > (identification, privacy violation, etc.). This kind of risk is never > > absolute: it lies in its increase. There is a difference between >sending an > > information on a post card and in a letter under envelope because >opening > > all the envelopes costs time and money. Language tags greatly >simplifies > > the intelligence gathering, filtering, spying, censoring ... and their > > errors. Not considering language tags in OPES context for example is >big > > mistake. But the main issue is that the user cannot turn it down. (NB. >This > > risks could have been greatly reduced through flexible "x-tags" and >"0-" > > escape sequence. I have no doubt people will die and suffer because of >the > > ABNF. Standardisation is also a risky activity.) > > > > - global risks. Let say the "9am-5pm" orientation of the Draft is well > > known and will be increasingly known. The irritation resulting from >the > > limitations to cultural lifes and innovation all over the world this >draft > > will lead to, and the probable impact on IANA and IETF image, may be a > > direct or indirect triggering factor in many nasty events to come (I >am > > sure you do not need I dwell on that point). The chances of this risk >have > > decreased. The ABNF rigidity against our Open Source/Standard >proposition, > > the resulting delays in excluding us, the exposure of the commercial > > interests involved will most probably now lead the WSIS Internet >Governance > > Forum to take over the issue. > > > > A related risk would be that all this would delay a serious Internet > > Multilingual Framework. This is a matter on which we now actively >work. > > jfc > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 10:41:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5P6J-0007gM-F0; Wed, 17 Aug 2005 10:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5P6H-0007g5-Ox for ltru@megatron.ietf.org; Wed, 17 Aug 2005 10:41:06 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04922 for ; Wed, 17 Aug 2005 10:41:02 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E5P2y-0001yI-JB for ltru@lists.ietf.org; Wed, 17 Aug 2005 16:37:40 +0200 Received: from du-001-121.access.de.clara.net ([212.82.227.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Aug 2005 16:37:40 +0200 Received: from nobody by du-001-121.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Aug 2005 16:37:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 17 Aug 2005 16:28:41 +0200 Organization: Lines: 19 Message-ID: <43034999.7B4A@xyzzy.claranet.de> References: <6.2.1.2.2.20050817004329.0560c460@mail.afrac.org> <43029C9F.3510@xyzzy.claranet.de> <6.2.1.2.2.20050817120052.056417b0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-121.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: WGLC security considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org r&d afrac wrote: > I do not know what is/is not a computer language. We discussed that point here, nobody supported your position, the issue is addressed in the draft. If you still insist on it try to find support for your position in the last call and / or try to convince an IESG member. Snipping other known points, I've nothing new to say about it, and repeating my old arguments would be lame. > RFC 3238 Thanks, I didn't know that, it's interesting. For OPES. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 12:03:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QOQ-0004gP-A1; Wed, 17 Aug 2005 12:03:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QOO-0004gA-3s for ltru@megatron.ietf.org; Wed, 17 Aug 2005 12:03:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08838 for ; Wed, 17 Aug 2005 12:03:49 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Qxu-0003oa-Gp for ltru@ietf.org; Wed, 17 Aug 2005 12:40:37 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 09:03:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Date: Wed, 17 Aug 2005 09:03:21 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C816397@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft Thread-Index: AcWix9CeXUv6HEbqQ6uqf/sLyPdJOQAfQj5Q From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 17 Aug 2005 16:03:30.0365 (UTC) FILETIME=[35FB26D0:01C5A345] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Correct. As soon as there's one star, it is available for all = positions... up to the next concrete subtag. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?8?16? 18:03 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft >=20 > Addison Phillips wrote: >=20 > > I hope this summary helps. >=20 > Yes, thanks. So we have sr-* =3D=3D sr-*-*-*-*, as soon as > there's one star it's for all available positions. Same > idea for sr-*-1900 =3D=3D sr-*-*-*-1900. >=20 > But sr-*-CYRL and sr-*-CYRL-*-* are different, correct ? >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 15:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvM-0007l4-9d; Wed, 17 Aug 2005 15:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvH-0007f5-6q; Wed, 17 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21150; Wed, 17 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5UUs-0001di-BQ; Wed, 17 Aug 2005 16:26:50 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5TvG-0001wF-2H; Wed, 17 Aug 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Aug 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-11.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-registry-11.txt Pages : 60 Date : 2005-8-17 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-registry-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-registry-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-17143958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-17143958.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@lists.ietf.org Wed Aug 17 15:50:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvT-0007pw-FO; Wed, 17 Aug 2005 15:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvH-0007gB-Nc; Wed, 17 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21149; Wed, 17 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5UUs-0001dX-7j; Wed, 17 Aug 2005 16:26:50 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5TvF-0001vm-Sr; Wed, 17 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-initial-04.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Initial Language Subtag Registry Author(s) : D. Ewell Filename : draft-ietf-ltru-initial-04.txt Pages : 118 Date : 2005-8-17 This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-initial-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-initial-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-17115325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-initial-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-initial-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-17115325.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@lists.ietf.org Wed Aug 17 15:58:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5U3g-0001Wj-Qe; Wed, 17 Aug 2005 15:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5U3g-0001WZ-6l for ltru@megatron.ietf.org; Wed, 17 Aug 2005 15:58:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22578 for ; Wed, 17 Aug 2005 15:58:40 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5UdE-0002FE-Mv for ltru@ietf.org; Wed, 17 Aug 2005 16:35:29 -0400 Received: from h-64-105-136-26.snvacaid.dynamic.covad.net ([64.105.136.26] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5U3a-0002LH-00 for ltru@ietf.org; Wed, 17 Aug 2005 15:58:39 -0400 Message-ID: <001401c5a366$4432d1a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.2.1.2.2.20050817004329.0560c460@mail.afrac.org><43029C9F.3510@xyzzy.claranet.de><6.2.1.2.2.20050817120052.056417b0@mail.afrac.org> <43034999.7B4A@xyzzy.claranet.de> Subject: Re: [Ltru] Re: WGLC security considerations Date: Wed, 17 Aug 2005 13:00:06 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Reviewing the discussion on this thread, it looks like there is a rough consensus of the WG that no change to the security considerations section is necessary at this time. Thanks to all for taking the time to consider Jefsey's proposal. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 16:18:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5UMT-0004l7-5q; Wed, 17 Aug 2005 16:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5UMS-0004l2-Kj for ltru@megatron.ietf.org; Wed, 17 Aug 2005 16:18:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28940 for ; Wed, 17 Aug 2005 16:18:06 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Uw4-0004j2-D1 for ltru@ietf.org; Wed, 17 Aug 2005 16:54:56 -0400 Received: from h-64-105-136-26.snvacaid.dynamic.covad.net ([64.105.136.26] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5UMN-0002I5-00 for ltru@ietf.org; Wed, 17 Aug 2005 16:18:03 -0400 Message-ID: <002101c5a368$fa2e6d00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.2.1.2.2.20050817004910.031432e0@pop.online.fr> <037401c5a2bc$feae14e0$7f1afea9@oemcomputer> <6.2.1.2.2.20050817134148.031935b0@mail.afrac.org> Subject: Re: [Ltru] Re: appeal intent report to ADs Date: Wed, 17 Aug 2005 13:18:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Jefsey - Martin and I have decided that I'll be the shepherding AD for the two registry-related documents, while Martin handles the parallel work on completing the matching draft. I'll be sending in the publication requests today. As the document's shepherd, I'm in no position to make "compromises". My job is to ensure that the document makes it through the process. If issues arise from the IESG or from the IETF last call, any changes other than purely editorial ones will need to be approved by the working group. (There's a reason for the "DISCUSS" nomenclature.) I respectfully decline your kind offer to help produce the summary of potential appeals issues for the AD. Randy > From: "r&d afrac" > To: "Randy Presuhn" ; ; "Scott Hollenbeck" > Cc: > Sent: Wednesday, August 17, 2005 5:29 AM > Subject: Re: [Ltru] Re: appeal intent report to ADs > > At 01:48 17/08/2005, Randy Presuhn wrote: > >If you're planning to appeal an IESG decision, this WG isn't the > >place to do it. Section 6.5.2 of RFC 2026 makes the IAB responsible > >for handling such appeals. > > Dear Randy, > I do not understand your answers since you quote the proper references. > > 1. RFC 2026 6.5 describes the appeal procedures. This mail is an attempt to > help you start an effort towards a compromise you did not engage. > > >The report Martin and I are required to provide > > 2. The document you quote says that this report is by the Shepherding > Chair. I will wait for his designation. > > >to our responsible AD > >is in anticipation of likely appeals of working group decisions, per > >section 6.5.1 of RFC 2026 and section 3.1 (1.f) of > >http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt > > 3. This document says: "1.f) Has anyone threatened an appeal or otherwise > indicated extreme discontent? If so, please summarise the areas of > conflict in separate email to the Responsible Area Director." > > In the case you missed it, I fall in the category of this anyone. I suppose > that an incorrect description of my positions will only delay the whole > process and lower the WG credibility. This is why I proposed to help. I > note that you refused that help. > > >I do suggest you take a look at section 5 of RFC 2026, as your > >understanding of the significance of the "BCP" designation doesn't > >appear to be supported by its definition there. > > A BCP can be: > 1. good user service common guidelines for policies and operations > different in scope and style from protocol standards. > 2. a way for entities such as IAB/IESG to insert proposals into the > consensus-building machinery of the IETF while gauging the community's view > of that issue. > 3. to document the operation of the IETF itself. For example, this > document defines the IETF Standards Process and is published as a BCP. > > (1) seems unlikely since the Draft introduces standard track issues > conflicting with open source/standard works and projects. > (2) I thought it was a way for W3C and Unicode to introduce their > proposals, but Addison Philip documented he did not represent the W3C (Mark > Davis refused to comment and to inform the WG on the CLDR he directs and > which is included in the Charter). > (3) the title of the WG is "Language Tags Registry Update". The non-studied > Charter says "It will describe the structure of the IANA registry and how > the registered tags will relate to the generative mechanisms". > > I take that this intended BCP is to ascertain the control of this IANA > registry to the benefit of the "ietf-languages@alvestrand.no" mailing list > and through an excluding format, leading the users of other formats more > appropriate to their needs to adopt non-IANA/IETF solutions, increasing the > balkanisation of the Internet. > > I formally oppose this excluding proposition I consider as highly > detrimental to the Internet. And will continue to engage every effort I can > pursue to fight the internet balkanisation as a response to its partition > necessity, all the more when I feel the motivation is not a common but a > commercial interest for the very reasons documented by IAB in RFC 3869. > > jfc morfin > > > > From: "r&d afrac" > > > To: "Randy Presuhn" > > > Cc: "Scott Hollenbeck" ; > > > Sent: Tuesday, August 16, 2005 4:11 PM > > > Subject: appeal intent report to ADs > > > > > > Dear Randy, > > > you have adopted a procedure which makes you (or Martin) to report the ADs > > > the documented motives of the appeals I announced, should the IETF Last > > > Call lead to a positive IESG decision, regarding the Draft you made > > > proposed by Addison Philips and Mark Davis. I am certainly ready to help > > > reviewing this report, so the AD get a complete and clear picture. This may > > > be an occasion for clarifications, and to agree on our disagreements. > > > > > > I think that this Draft would deeply harm the Internet should it continue > > > to claim being a BCP documenting an exclusive global Internet language > > > tagging. But I also think that if this Draft brings a transitional response > > > to specific needs, it must go through as a standard track specific document > > > (having not studied the Charter in common, I trusted blindly Addison on > > > this until he said he did not spoke on behalf the W3C: this is the reason > > > of my "if"). In such a case both the Internet standard process and the > > > anti-open standard ABNF provisions parts should obviously be removed as out > > > of the new scope. > > > > > > jfc > > > > > > > > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 17:17:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5VHm-0003cG-Td; Wed, 17 Aug 2005 17:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5VHl-0003aU-DI for ltru@megatron.ietf.org; Wed, 17 Aug 2005 17:17:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02374 for ; Wed, 17 Aug 2005 17:17:19 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5VrM-0006UG-Q0 for ltru@ietf.org; Wed, 17 Aug 2005 17:54:10 -0400 Received: from h-64-105-136-26.snvacaid.dynamic.covad.net ([64.105.136.26] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5VHi-0005C4-00 for ltru@ietf.org; Wed, 17 Aug 2005 17:17:18 -0400 Message-ID: <003401c5a371$3f9e5460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] I-D ACTION:draft-ietf-ltru-registry-11.txt Date: Wed, 17 Aug 2005 14:18:43 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Arrrrgh. Purely editorial, must be fixed before I can give this to IESG. Output from http://ietf.levkowetz.com/tools/idnits/idnits.pyht : idnits 1.74 tmp/draft-ietf-ltru-registry-11.txt: tmp/draft-ietf-ltru-registry-11.txt(987): Line has weird spacing: '...al line of AS...' tmp/draft-ietf-ltru-registry-11.txt(989): Line has weird spacing: '...portion of...' tmp/draft-ietf-ltru-registry-11.txt(990): Line has weird spacing: '... this conce...' tmp/draft-ietf-ltru-registry-11.txt(1528): Line has weird spacing: '...subtags of ty...' tmp/draft-ietf-ltru-registry-11.txt(1632): Line has weird spacing: '...ssarily repre...' tmp/draft-ietf-ltru-registry-11.txt(1644): Line has weird spacing: '...process and i...' tmp/draft-ietf-ltru-registry-11.txt(1728): Line has weird spacing: '...ncludes descr...' tmp/draft-ietf-ltru-registry-11.txt(1745): Line has weird spacing: '...subtags or ch...' tmp/draft-ietf-ltru-registry-11.txt(1750): Line has weird spacing: '...lity of alpha...' tmp/draft-ietf-ltru-registry-11.txt(2036): Line has weird spacing: '...be used where...' tmp/draft-ietf-ltru-registry-11.txt(2107): Line has weird spacing: '...hen the value...' tmp/draft-ietf-ltru-registry-11.txt(2218): Line has weird spacing: '...ocument impos...' tmp/draft-ietf-ltru-registry-11.txt(2770): Line has weird spacing: '...andards chang...' tmp/draft-ietf-ltru-registry-11.txt(2772): Line has weird spacing: '... order to pr...' tmp/draft-ietf-ltru-registry-11.txt(2877): Line has weird spacing: '...ags for supra...' tmp/draft-ietf-ltru-registry-11.txt(2921): Line contains control character TAB in position 27. tmp/draft-ietf-ltru-registry-11.txt(2931): Line contains control character TAB in position 23. ... Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 17:26:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5VQI-0005eZ-64; Wed, 17 Aug 2005 17:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5VQG-0005Zp-9Q for ltru@megatron.ietf.org; Wed, 17 Aug 2005 17:26:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02760; Wed, 17 Aug 2005 17:26:05 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Vzr-0006ia-5S; Wed, 17 Aug 2005 18:02:56 -0400 Received: from h-64-105-136-26.snvacaid.dynamic.covad.net ([64.105.136.26] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5VQ9-0006pM-00; Wed, 17 Aug 2005 17:26:01 -0400 Message-ID: <000701c5a372$78559100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "The IESG" , "Scott Hollenbeck" Date: Wed, 17 Aug 2005 14:26:42 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: LTRU Working Group Subject: [Ltru] Publication request for as an Informational RFC X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This questionnaire and write-up is being sent to the responsible Applications Area Director, Scott Hollenbeck, , and to iesg-secretary@ietf.org as a request to publish as an Informational RFC, with a courtesy copy to the ltru WG at . The shepherding co-chair will be Randy Presuhn, . Here are the questions and answers per http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt: 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by several WG members. We have requested reviews from several WG non-members, but have not gotten any responses. We are not concerned about the depth or breadth of the reviews performed. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus of the active participants; have not seen any opposition to this document. However, see answers for closely related registry draft. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. However, see answers for the closely related registry draft. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Yes. 1.h) Is the document split into normative and informative references? Yes. Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? No. (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Items 1.i, 1.j, and 1.k are not directly applicable since this is publication request is for an "Informational" document. However, since this would provide the initial content for a registry, we offer the following, in case it would be useful: Technical Summary This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. This document was produced as part of the effort to develop a successor to RFC 3066. Working Group Summary This document is a necessary companion to the primary work item of the ltru working group, the specification of the IANA Language Subtag Registry. Protocol Quality As mentioned above, this document is merely the delivery vehicle for the initial content for the IANA Lanaguage Subtag Registry. At the time of this summary, likely additions ("language synonyms") had already been discussed, but the WG agreed that since such changes are part of the normal operation of the IANA Language Subtag Registry, they can be handled on ietf-languages@iana.org after the registry has been initialized using the contents of this document. The contents were checked against the data from the underlying standards and for internal consistency by multiple working group members using independent methods. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 19:03:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ww4-0002sR-H5; Wed, 17 Aug 2005 19:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ww1-0002sC-1y; Wed, 17 Aug 2005 19:03:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10192; Wed, 17 Aug 2005 19:02:43 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5XVN-0001ND-II; Wed, 17 Aug 2005 19:39:36 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 16:02:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5A37F.BCE6BF38" Date: Wed, 17 Aug 2005 16:02:27 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C81688F@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: Submission: draft-12 of draft-ietf-ltru-registry Thread-Index: AcWjf7Smq+Ey7Hc7RNmD2l6Huem6HA== From: "Addison Phillips" To: X-OriginalArrivalTime: 17 Aug 2005 23:02:28.0271 (UTC) FILETIME=[BD5733F0:01C5A37F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 868af33ea4044bf08ad1008f65bebaaf Cc: ltru@ietf.org Subject: [Ltru] Submission: draft-12 of draft-ietf-ltru-registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A37F.BCE6BF38 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGRyYWZ0LTEyIG9mIGRyYWZ0LWll dGYtbHRydS1yZWdpc3RyeS4gVGhpcyBkb2N1bWVudCBpcyBpbiB0ZXh0IGZvcm1hdCBnZW5lcmF0 ZWQgZnJvbSB4bWwycmZjIGFuZCBoYXMgYmVlbiB0aHJvdWdoIGlkbml0cy4NCg0KQmVzdCBSZWdh cmRzIChmb3IgdGhlIGVkaXRvcnMpLA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMN Ckdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVz dC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3Jv dXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6YXRp b24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg0K ------_=_NextPart_001_01C5A37F.BCE6BF38 Content-Type: text/plain; name="draft-ietf-ltru-registry-12.txt" Content-Description: draft-ietf-ltru-registry-12.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-12.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IEZlYnJ1YXJ5 IDE4LCAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBdWd1c3QgMTcsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTINCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBGZWJydWFyeSAxOCwgMjAwNi4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5 cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4NCg0KQWJzdHJhY3QNCg0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHN0cnVjdHVyZSwgY29udGVudCwgY29uc3RydWN0 aW9uLCBhbmQNCiAgIHNlbWFudGljcyBvZiBsYW5ndWFnZSB0YWdzIGZvciB1c2UgaW4gY2FzZXMg d2hlcmUgaXQgaXMgZGVzaXJhYmxlIHRvDQogICBpbmRpY2F0ZSB0aGUgbGFuZ3VhZ2UgdXNlZCBp biBhbiBpbmZvcm1hdGlvbiBvYmplY3QuICBJdCBhbHNvDQogICBkZXNjcmliZXMgaG93IHRvIHJl Z2lzdGVyIHZhbHVlcyBmb3IgdXNlIGluIGxhbmd1YWdlIHRhZ3MgYW5kIHRoZQ0KICAgY3JlYXRp b24gb2YgdXNlciBkZWZpbmVkIGV4dGVuc2lvbnMgZm9yIHByaXZhdGUgaW50ZXJjaGFuZ2UuDQoN Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAw NiAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQpUYWJsZSBv ZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIuICBUaGUgTGFuZ3VhZ2UgVGFnIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgICAyLjEg ICBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA0DQogICAgIDIuMiAgIExhbmd1YWdlIFN1YnRhZyBTb3VyY2VzIGFuZCBJbnRlcnByZXRh dGlvbiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgICAyLjIuMSAgIFByaW1hcnkgTGFuZ3VhZ2Ug U3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAgIDIuMi4yICAg RXh0ZW5kZWQgTGFuZ3VhZ2UgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEw DQogICAgICAgMi4yLjMgICBTY3JpcHQgU3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTANCiAgICAgICAyLjIuNCAgIFJlZ2lvbiBTdWJ0YWcgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICAgIDIuMi41ICAgVmFyaWFu dCBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICAg ICAgMi4yLjYgICBFeHRlbnNpb24gU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTQNCiAgICAgICAyLjIuNyAgIFByaXZhdGUgVXNlIFN1YnRhZ3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQ0KICAgICAgIDIuMi44ICAgUHJlLUV4aXN0aW5n IFJGQyAzMDY2IFJlZ2lzdHJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQogICAgICAgMi4y LjkgICBDbGFzc2VzIG9mIENvbmZvcm1hbmNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTYNCiAgIDMuICBSZWdpc3RyeSBGb3JtYXQgYW5kIE1haW50ZW5hbmNlICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICAzLjEgICBGb3JtYXQgb2YgdGhlIElBTkEgTGFu Z3VhZ2UgU3VidGFnIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIDE4DQogICAgIDMuMiAgIE1haW50 ZW5hbmNlIG9mIHRoZSBSZWdpc3RyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMN CiAgICAgMy4zICAgU3RhYmlsaXR5IG9mIElBTkEgUmVnaXN0cnkgRW50cmllcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyNA0KICAgICAzLjQgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlIGZvciBT dWJ0YWdzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4DQogICAgIDMuNSAgIFBvc3NpYmlsaXRp ZXMgZm9yIFJlZ2lzdHJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzENCiAgICAg My42ICAgRXh0ZW5zaW9ucyBhbmQgRXh0ZW5zaW9ucyBSZWdpc3RyeSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzMw0KICAgICAzLjcgICBJbml0aWFsaXphdGlvbiBvZiB0aGUgUmVnaXN0cmllcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM2DQogICA0LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNz aW5nIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcNCiAgICAgNC4xICAg Q2hvaWNlIG9mIExhbmd1YWdlIFRhZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzNw0KICAgICA0LjIgICBNZWFuaW5nIG9mIHRoZSBMYW5ndWFnZSBUYWcgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDM5DQogICAgIDQuMyAgIExlbmd0aCBDb25zaWRlcmF0aW9ucyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDANCiAgICAgICA0LjMuMSAgIFdv cmtpbmcgd2l0aCBMaW1pdGVkIEJ1ZmZlciBTaXplcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiA0MA0K ICAgICAgIDQuMy4yICAgVHJ1bmNhdGlvbiBvZiBMYW5ndWFnZSBUYWdzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDQyDQogICAgIDQuNCAgIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2Ug VGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDINCiAgICAgNC41ICAgQ29uc2lkZXJhdGlv bnMgZm9yIFByaXZhdGUgVXNlIFN1YnRhZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiA0NA0KICAgNS4g IElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDQ2DQogICAgIDUuMSAgIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDYNCiAgICAgNS4yICAgRXh0ZW5zaW9ucyBSZWdpc3Ry eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Nw0KICAgNi4gIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQ4DQogICA3LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDkNCiAgIDguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MA0KICAgOS4gIFJlZmVyZW5jZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUzDQog ICAgIDkuMSAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNTMNCiAgICAgOS4yICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NA0KICAgICAgIEF1dGhvcnMnIEFkZHJlc3Nl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1DQogICBBLiAg QWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNTYNCiAgIEIuICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBUYWdzIChJbmZvcm1hdGl2ZSkg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Nw0KICAgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBh bmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIDYwDQoNCg0KDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAg ICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KMS4gIEludHJvZHVjdGlv bg0KDQogICBIdW1hbiBiZWluZ3Mgb24gb3VyIHBsYW5ldCBoYXZlLCBwYXN0IGFuZCBwcmVzZW50 LCB1c2VkIGEgbnVtYmVyIG9mDQogICBsYW5ndWFnZXMuICBUaGVyZSBhcmUgbWFueSByZWFzb25z IHdoeSBvbmUgd291bGQgd2FudCB0byBpZGVudGlmeSB0aGUNCiAgIGxhbmd1YWdlIHVzZWQgd2hl biBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3JtYXRpb24uDQoNCiAgIFVzZXIncyBsYW5n dWFnZSBwcmVmZXJlbmNlcyBvZnRlbiBuZWVkIHRvIGJlIGlkZW50aWZpZWQgc28gdGhhdA0KICAg YXBwcm9wcmlhdGUgcHJvY2Vzc2luZyBjYW4gYmUgYXBwbGllZC4gIEZvciBleGFtcGxlLCB0aGUg dXNlcidzDQogICBsYW5ndWFnZSBwcmVmZXJlbmNlcyBpbiBhIFdlYiBicm93c2VyIGNhbiBiZSB1 c2VkIHRvIHNlbGVjdCBXZWIgcGFnZXMNCiAgIGFwcHJvcHJpYXRlbHkuICBMYW5ndWFnZSBwcmVm ZXJlbmNlcyBjYW4gYWxzbyBiZSB1c2VkIHRvIHNlbGVjdCBhbW9uZw0KICAgdG9vbHMgKHN1Y2gg YXMgZGljdGlvbmFyaWVzKSB0byBhc3Npc3QgaW4gdGhlIHByb2Nlc3Npbmcgb3INCiAgIHVuZGVy c3RhbmRpbmcgb2YgY29udGVudCBpbiBkaWZmZXJlbnQgbGFuZ3VhZ2VzLg0KDQogICBJbiBhZGRp dGlvbiwga25vd2xlZGdlIGFib3V0IHRoZSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHVzZWQgYnkgc29t ZQ0KICAgcGllY2Ugb2YgaW5mb3JtYXRpb24gY29udGVudCBtaWdodCBiZSB1c2VmdWwgb3IgZXZl biByZXF1aXJlZCBieSBzb21lDQogICB0eXBlcyBvZiBwcm9jZXNzaW5nOyBmb3IgZXhhbXBsZSBz cGVsbC1jaGVja2luZywgY29tcHV0ZXItc3ludGhlc2l6ZWQNCiAgIHNwZWVjaCwgQnJhaWxsZSB0 cmFuc2NyaXB0aW9uLCBvciBoaWdoLXF1YWxpdHkgcHJpbnQgcmVuZGVyaW5ncy4NCg0KICAgT25l IG1lYW5zIG9mIGluZGljYXRpbmcgdGhlIGxhbmd1YWdlIHVzZWQgaXMgYnkgbGFiZWxpbmcgdGhl DQogICBpbmZvcm1hdGlvbiBjb250ZW50IHdpdGggYW4gaWRlbnRpZmllciBvciAidGFnIi4gIFRo ZXNlIHRhZ3MgY2FuIGJlDQogICB1c2VkIHRvIHNwZWNpZnkgdXNlciBwcmVmZXJlbmNlcyB3aGVu IHNlbGVjdGluZyBpbmZvcm1hdGlvbiBjb250ZW50LA0KICAgb3IgZm9yIGxhYmVsaW5nIGFkZGl0 aW9uYWwgYXR0cmlidXRlcyBvZiBjb250ZW50IGFuZCBhc3NvY2lhdGVkDQogICByZXNvdXJjZXMu DQoNCiAgIFRhZ3MgY2FuIGFsc28gYmUgdXNlZCB0byBpbmRpY2F0ZSBhZGRpdGlvbmFsIGxhbmd1 YWdlIGF0dHJpYnV0ZXMgb2YNCiAgIGNvbnRlbnQuICBGb3IgZXhhbXBsZSwgaW5kaWNhdGluZyBz cGVjaWZpYyBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCiAgIGRpYWxlY3QsIHdyaXRpbmcgc3lzdGVt LCBvciBvcnRob2dyYXBoeSB1c2VkIGluIGEgZG9jdW1lbnQgb3INCiAgIHJlc291cmNlIG1heSBl bmFibGUgdGhlIHVzZXIgdG8gb2J0YWluIGluZm9ybWF0aW9uIGluIGEgZm9ybSB0aGF0DQogICB0 aGV5IGNhbiB1bmRlcnN0YW5kLCBvciBpbXBvcnRhbnQgaW4gcHJvY2Vzc2luZyBvciByZW5kZXJp bmcgdGhlDQogICBnaXZlbiBjb250ZW50IGludG8gYW4gYXBwcm9wcmlhdGUgZm9ybSBvciBzdHls ZS4NCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBwYXJ0aWN1bGFyIGlkZW50aWZpZXIg bWVjaGFuaXNtICh0aGUNCiAgIGxhbmd1YWdlIHRhZykgYW5kIGEgcmVnaXN0cmF0aW9uIGZ1bmN0 aW9uIGZvciB2YWx1ZXMgdG8gYmUgdXNlZCB0bw0KICAgZm9ybSB0YWdzLiAgSXQgYWxzbyBkZWZp bmVzIGEgbWVjaGFuaXNtIGZvciBwcml2YXRlIHVzZSB2YWx1ZXMgYW5kDQogICBmdXR1cmUgZXh0 ZW5zaW9uLg0KDQogICBUaGlzIGRvY3VtZW50IHJlcGxhY2VzIFtSRkMzMDY2XSwgd2hpY2ggcmVw bGFjZWQgW1JGQzE3NjZdLiAgRm9yIGENCiAgIGxpc3Qgb2YgY2hhbmdlcyBpbiB0aGlzIGRvY3Vt ZW50LCBzZWUgU2VjdGlvbiA4Lg0KDQogICBUaGUga2V5d29yZHMgIk1VU1QiLCAiTVVTVCBOT1Qi LCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxE IE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4N Cg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMTgsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoN Cg0KMi4gIFRoZSBMYW5ndWFnZSBUYWcNCg0KICAgTGFuZ3VhZ2UgdGFncyBhcmUgdXNlZCB0byBo ZWxwIGlkZW50aWZ5IGxhbmd1YWdlcywgd2hldGhlciBzcG9rZW4sDQogICB3cml0dGVuLCBzaWdu ZWQsIG9yIG90aGVyd2lzZSBzaWduYWxlZCwgZm9yIHRoZSBwdXJwb3NlIG9mDQogICBjb21tdW5p Y2F0aW9uLiAgVGhpcyBpbmNsdWRlcyBjb25zdHJ1Y3RlZCBhbmQgYXJ0aWZpY2lhbCBsYW5ndWFn ZXMsDQogICBidXQgZXhjbHVkZXMgbGFuZ3VhZ2VzIG5vdCBpbnRlbmRlZCBwcmltYXJpbHkgZm9y IGh1bWFuDQogICBjb21tdW5pY2F0aW9uLCBzdWNoIGFzIHByb2dyYW1taW5nIGxhbmd1YWdlcy4N Cg0KMi4xICBTeW50YXgNCg0KICAgVGhlIGxhbmd1YWdlIHRhZyBpcyBjb21wb3NlZCBvZiBvbmUg b3IgbW9yZSBwYXJ0cyBvciAic3VidGFncyIuICBFYWNoDQogICBzdWJ0YWcgY29uc2lzdHMgb2Yg YSBzZXF1ZW5jZSBvZiBhbHBoYS1udW1lcmljIGNoYXJhY3RlcnMuICBTdWJ0YWdzDQogICBhcmUg ZGlzdGluZ3Vpc2hlZCBhbmQgc2VwYXJhdGVkIGZyb20gb25lIGFub3RoZXIgYnkgYSBoeXBoZW4g KCItIiwNCiAgIEFCTkYgW1JGQzIyMzRiaXNdICV4MkQpLiAgQSBsYW5ndWFnZSB0YWcgY29uc2lz dHMgb2YgYSAicHJpbWFyeQ0KICAgbGFuZ3VhZ2UiIHN1YnRhZyBhbmQgYSAocG9zc2libHkgZW1w dHkpIHNlcmllcyBvZiBzdWJzZXF1ZW50IHN1YnRhZ3MsDQogICBlYWNoIG9mIHdoaWNoIHJlZmlu ZXMgb3IgbmFycm93cyB0aGUgcmFuZ2Ugb2YgbGFuZ3VhZ2UgaWRlbnRpZmllZCBieQ0KICAgdGhl IG92ZXJhbGwgdGFnLg0KDQogICBFYWNoIHR5cGUgb2Ygc3VidGFnIGlzIGRpc3Rpbmd1aXNoZWQg YnkgbGVuZ3RoLCBwb3NpdGlvbiBpbiB0aGUgdGFnLA0KICAgYW5kIGNvbnRlbnQ6IHN1YnRhZ3Mg Y2FuIGJlIHJlY29nbml6ZWQgc29sZWx5IGJ5IHRoZXNlIGZlYXR1cmVzLg0KICAgVGhpcyBtYWtl cyBpdCBwb3NzaWJsZSB0byBjb25zdHJ1Y3QgYSBwYXJzZXIgdGhhdCBjYW4gZXh0cmFjdCBhbmQN CiAgIGFzc2lnbiBzb21lIHNlbWFudGljIGluZm9ybWF0aW9uIHRvIHRoZSBzdWJ0YWdzLCBldmVu IGlmIHRoZSBzcGVjaWZpYw0KICAgc3VidGFnIHZhbHVlcyBhcmUgbm90IHJlY29nbml6ZWQuICBU aHVzIGEgcGFyc2VyIG5lZWQgbm90IGhhdmUgYW4gdXAtDQogICB0by1kYXRlIGNvcHkgKG9yIGFu eSBjb3B5IGF0IGFsbCkgb2YgdGhlIHN1YnRhZyByZWdpc3RyeSB0byBwZXJmb3JtDQogICBtb3N0 IHNlYXJjaGluZyBhbmQgbWF0Y2hpbmcgb3BlcmF0aW9ucy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBB dWd1c3QgMjAwNQ0KDQoNCiAgIFRoZSBzeW50YXggb2YgdGhlIGxhbmd1YWdlIHRhZyBpbiBBQk5G IFtSRkMyMjM0YmlzXSBpczoNCg0KICAgTGFuZ3VhZ2UtVGFnICA9IGxhbmd0YWcNCiAgICAgICAg ICAgICAgICAgLyBwcml2YXRldXNlICAgICAgICAgICAgIDsgcHJpdmF0ZSB1c2UgdGFnDQogICAg ICAgICAgICAgICAgIC8gZ3JhbmRmYXRoZXJlZCAgICAgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVn aXN0cmF0aW9ucw0KDQogICBsYW5ndGFnICAgICAgID0gKGxhbmd1YWdlDQogICAgICAgICAgICAg ICAgICAgIFsiLSIgc2NyaXB0XQ0KICAgICAgICAgICAgICAgICAgICBbIi0iIHJlZ2lvbl0NCiAg ICAgICAgICAgICAgICAgICAgKigiLSIgdmFyaWFudCkNCiAgICAgICAgICAgICAgICAgICAgKigi LSIgZXh0ZW5zaW9uKQ0KICAgICAgICAgICAgICAgICAgICBbIi0iIHByaXZhdGV1c2VdKQ0KDQog ICBsYW5ndWFnZSAgICAgID0gKDIqM0FMUEhBIFsgZXh0bGFuZyBdKSA7IHNob3J0ZXN0IElTTyA2 MzkgY29kZQ0KICAgICAgICAgICAgICAgICAvIDRBTFBIQSAgICAgICAgICAgICAgICAgOyByZXNl cnZlZCBmb3IgZnV0dXJlIHVzZQ0KICAgICAgICAgICAgICAgICAvIDUqOEFMUEhBICAgICAgICAg ICAgICAgOyByZWdpc3RlcmVkIGxhbmd1YWdlIHN1YnRhZw0KDQogICBleHRsYW5nICAgICAgID0g KjMoIi0iIDNBTFBIQSkgICAgICAgICA7IHJlc2VydmVkIGZvciBmdXR1cmUgdXNlDQoNCiAgIHNj cmlwdCAgICAgICAgPSA0QUxQSEEgICAgICAgICAgICAgICAgIDsgSVNPIDE1OTI0IGNvZGUNCg0K ICAgcmVnaW9uICAgICAgICA9IDJBTFBIQSAgICAgICAgICAgICAgICAgOyBJU08gMzE2NiBjb2Rl DQogICAgICAgICAgICAgICAgIC8gM0RJR0lUICAgICAgICAgICAgICAgICA7IFVOIE0uNDkgY29k ZQ0KDQogICB2YXJpYW50ICAgICAgID0gNSo4YWxwaGFudW0gICAgICAgICAgICA7IHJlZ2lzdGVy ZWQgdmFyaWFudHMNCiAgICAgICAgICAgICAgICAgLyAoRElHSVQgM2FscGhhbnVtKQ0KDQogICBl eHRlbnNpb24gICAgID0gc2luZ2xldG9uIDEqKCItIiAoMio4YWxwaGFudW0pKQ0KDQogICBzaW5n bGV0b24gICAgID0gJXg0MS01NyAvICV4NTktNUEgLyAleDYxLTc3IC8gJXg3OS03QSAvIERJR0lU DQogICAgICAgICAgICAgICAgIDsgImEiLSJ3IiAvICJ5Ii0ieiIgLyAiQSItIlciIC8gIlkiLSJa IiAvICIwIi0iOSINCiAgICAgICAgICAgICAgICAgOyBTaW5nbGUgbGV0dGVyczogeC9YIGlzIHJl c2VydmVkIGZvciBwcml2YXRlIHVzZQ0KDQogICBwcml2YXRldXNlICAgID0gKCJ4Ii8iWCIpIDEq KCItIiAoMSo4YWxwaGFudW0pKQ0KDQogICBncmFuZGZhdGhlcmVkID0gMSozQUxQSEEgMSoyKCIt IiAoMio4YWxwaGFudW0pKQ0KICAgICAgICAgICAgICAgICAgIDsgZ3JhbmRmYXRoZXJlZCByZWdp c3RyYXRpb24NCiAgICAgICAgICAgICAgICAgICA7IE5vdGU6IGkgaXMgdGhlIG9ubHkgc2luZ2xl dG9uDQogICAgICAgICAgICAgICAgICAgOyB0aGF0IHN0YXJ0cyBhIGdyYW5kZmF0aGVyZWQgdGFn DQoNCiAgIGFscGhhbnVtICAgICAgPSAoQUxQSEEgLyBESUdJVCkgICAgICAgOyBsZXR0ZXJzIGFu ZCBudW1iZXJzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBMYW5ndWFnZSBU YWcgQUJORg0KDQogICBOb3RlOiBUaGVyZSBpcyBhIHN1YnRsZXR5IGluIHRoZSBBQk5GIGZvciAn dmFyaWFudCc6IHZhcmlhbnRzDQogICBzdGFydGluZyB3aXRoIGEgZGlnaXQgTUFZIGJlIGZvdXIg Y2hhcmFjdGVycyBsb25nLCB3aGlsZSB0aG9zZQ0KICAgc3RhcnRpbmcgd2l0aCBhIGxldHRlciBN VVNUIGJlIGF0IGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICAgW1Bh Z2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIEFsbCBzdWJ0YWdzIGhhdmUgYSBtYXhp bXVtIGxlbmd0aCBvZiBlaWdodCBjaGFyYWN0ZXJzIGFuZCB3aGl0ZXNwYWNlDQogICBpcyBub3Qg cGVybWl0dGVkIGluIGEgbGFuZ3VhZ2UgdGFnLiAgRm9yIGV4YW1wbGVzIG9mIGxhbmd1YWdlIHRh Z3MsDQogICBzZWUgQXBwZW5kaXggQi4NCg0KICAgTm90ZSB0aGF0IGFsdGhvdWdoIFtSRkMyMjM0 YmlzXSByZWZlcnMgdG8gb2N0ZXRzLCB0aGUgbGFuZ3VhZ2UgdGFncw0KICAgZGVzY3JpYmVkIGlu IHRoaXMgZG9jdW1lbnQgYXJlIHNlcXVlbmNlcyBvZiBjaGFyYWN0ZXJzIGZyb20gdGhlIFVTLQ0K ICAgQVNDSUkgW0lTTzY0Nl0gcmVwZXJ0b2lyZS4gIExhbmd1YWdlIHRhZ3MgTUFZIGJlIHVzZWQg aW4gZG9jdW1lbnRzDQogICBhbmQgYXBwbGljYXRpb25zIHRoYXQgdXNlIG90aGVyIGVuY29kaW5n cywgc28gbG9uZyBhcyB0aGVzZSBlbmNvbXBhc3MNCiAgIHRoZSBVUy1BU0NJSSByZXBlcnRvaXJl LiAgQW4gZXhhbXBsZSBvZiB0aGlzIHdvdWxkIGJlIGFuIFhNTCBkb2N1bWVudA0KICAgdGhhdCB1 c2VzIHRoZSBVVEYtMTZMRSBbUkZDMjc4MV0gZW5jb2Rpbmcgb2YgW1VuaWNvZGVdLg0KDQogICBU aGUgdGFncyBhbmQgdGhlaXIgc3VidGFncywgaW5jbHVkaW5nIHByaXZhdGUgdXNlIGFuZCBleHRl bnNpb25zLCBhcmUNCiAgIHRvIGJlIHRyZWF0ZWQgYXMgY2FzZSBpbnNlbnNpdGl2ZTogdGhlcmUg ZXhpc3QgY29udmVudGlvbnMgZm9yIHRoZQ0KICAgY2FwaXRhbGl6YXRpb24gb2Ygc29tZSBvZiB0 aGUgc3VidGFncywgYnV0IHRoZXNlIE1VU1QgTk9UIGJlIHRha2VuIHRvDQogICBjYXJyeSBtZWFu aW5nLg0KDQogICBGb3IgZXhhbXBsZToNCg0KICAgbyAgW0lTTzYzOS0xXSByZWNvbW1lbmRzIHRo YXQgbGFuZ3VhZ2UgY29kZXMgYmUgd3JpdHRlbiBpbiBsb3dlciBjYXNlDQogICAgICAoJ21uJyBN b25nb2xpYW4pLg0KDQogICBvICBbSVNPMzE2Ni0xXSByZWNvbW1lbmRzIHRoYXQgY291bnRyeSBj b2RlcyBiZSBjYXBpdGFsaXplZCAoJ01OJw0KICAgICAgTW9uZ29saWEpLg0KDQogICBvICBbSVNP MTU5MjRdIHJlY29tbWVuZHMgdGhhdCBzY3JpcHQgY29kZXMgdXNlIGxvd2VyIGNhc2Ugd2l0aCB0 aGUNCiAgICAgIGluaXRpYWwgbGV0dGVyIGNhcGl0YWxpemVkICgnQ3lybCcgQ3lyaWxsaWMpLg0K DQogICBIb3dldmVyLCBpbiB0aGUgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIHRoZSB1 cHBlcmNhc2UgVVMtQVNDSUkNCiAgIGxldHRlcnMgaW4gdGhlIHJhbmdlICdBJyB0aHJvdWdoICda JyBhcmUgY29uc2lkZXJlZCBlcXVpdmFsZW50IGFuZA0KICAgbWFwcGVkIGRpcmVjdGx5IHRvIHRo ZWlyIFVTLUFTQ0lJIGxvd2VyY2FzZSBlcXVpdmFsZW50cyBpbiB0aGUgcmFuZ2UNCiAgICdhJyB0 aHJvdWdoICd6Jy4gIFRodXMgdGhlIHRhZyAibW4tQ3lybC1NTiIgaXMgbm90IGRpc3RpbmN0IGZy b20gIk1OLQ0KICAgY1lSTC1tbiIgb3IgIm1OLWNZckwtTW4iIChvciBhbnkgb3RoZXIgY29tYmlu YXRpb24pIGFuZCBlYWNoIG9mIHRoZXNlDQogICB2YXJpYXRpb25zIGNvbnZleXMgdGhlIHNhbWUg bWVhbmluZzogTW9uZ29saWFuIHdyaXR0ZW4gaW4gdGhlDQogICBDeXJpbGxpYyBzY3JpcHQgYXMg dXNlZCBpbiBNb25nb2xpYS4NCg0KMi4yICBMYW5ndWFnZSBTdWJ0YWcgU291cmNlcyBhbmQgSW50 ZXJwcmV0YXRpb24NCg0KICAgVGhlIG5hbWVzcGFjZSBvZiBsYW5ndWFnZSB0YWdzIGFuZCB0aGVp ciBzdWJ0YWdzIGlzIGFkbWluaXN0ZXJlZCBieQ0KICAgdGhlIEludGVybmV0IEFzc2lnbmVkIE51 bWJlcnMgQXV0aG9yaXR5IChJQU5BKSBbUkZDMjg2MF0gYWNjb3JkaW5nIHRvDQogICB0aGUgcnVs ZXMgaW4gU2VjdGlvbiA1IG9mIHRoaXMgZG9jdW1lbnQuICBUaGUgTGFuZ3VhZ2UgU3VidGFnDQog ICBSZWdpc3RyeSBtYWludGFpbmVkIGJ5IElBTkEgaXMgdGhlIHNvdXJjZSBmb3IgdmFsaWQgc3Vi dGFnczogb3RoZXINCiAgIHN0YW5kYXJkcyByZWZlcmVuY2VkIGluIHRoaXMgc2VjdGlvbiBwcm92 aWRlIHRoZSBzb3VyY2UgbWF0ZXJpYWwgZm9yDQogICB0aGF0IHJlZ2lzdHJ5Lg0KDQogICBUZXJt aW5vbG9neSBpbiB0aGlzIHNlY3Rpb246DQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIG8gIFRhZyBvciB0YWdzIHJlZmVycyB0byBhIGNvbXBs ZXRlIGxhbmd1YWdlIHRhZywgc3VjaCBhcw0KICAgICAgImZyLUxhdG4tQ0EiLiAgRXhhbXBsZXMg b2YgdGFncyBpbiB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbg0KICAgICAgZG91YmxlLXF1 b3RlcyAoImVuLVVTIikuDQoNCiAgIG8gIFN1YnRhZyByZWZlcnMgdG8gYSBzcGVjaWZpYyBzZWN0 aW9uIG9mIGEgdGFnLCBkZWxpbWl0ZWQgYnkgaHlwaGVuLA0KICAgICAgc3VjaCBhcyB0aGUgc3Vi dGFnICdMYXRuJyBpbiAiZnItTGF0bi1DQSIuICBFeGFtcGxlcyBvZiBzdWJ0YWdzIGluDQogICAg ICB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgnTGF0bicpLg0K DQogICBvICBDb2RlIG9yIGNvZGVzIHJlZmVycyB0byB2YWx1ZXMgZGVmaW5lZCBpbiBleHRlcm5h bCBzdGFuZGFyZHMgKGFuZA0KICAgICAgd2hpY2ggYXJlIHVzZWQgYXMgc3VidGFncyBpbiB0aGlz IGRvY3VtZW50KS4gIEZvciBleGFtcGxlLCAnTGF0bicNCiAgICAgIGlzIGFuIFtJU08xNTkyNF0g c2NyaXB0IGNvZGUgd2hpY2ggd2FzIHVzZWQgdG8gZGVmaW5lIHRoZSAnTGF0bicNCiAgICAgIHNj cmlwdCBzdWJ0YWcgZm9yIHVzZSBpbiBhIGxhbmd1YWdlIHRhZy4gIEV4YW1wbGVzIG9mIGNvZGVz IGluDQogICAgICB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgn ZW4nLCAnTGF0bicpLg0KDQogICBUaGUgZGVmaW5pdGlvbnMgaW4gdGhpcyBzZWN0aW9uIGFwcGx5 IHRvIHRoZSB2YXJpb3VzIHN1YnRhZ3Mgd2l0aGluDQogICB0aGUgbGFuZ3VhZ2UgdGFncyBkZWZp bmVkIGJ5IHRoaXMgZG9jdW1lbnQsIGV4Y2VwdGluZyB0aG9zZQ0KICAgImdyYW5kZmF0aGVyZWQi IHRhZ3MgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMi44Lg0KDQogICBMYW5ndWFnZSB0YWdzIGFyZSBk ZXNpZ25lZCBzbyB0aGF0IGVhY2ggc3VidGFnIHR5cGUgaGFzIHVuaXF1ZSBsZW5ndGgNCiAgIGFu ZCBjb250ZW50IHJlc3RyaWN0aW9ucy4gIFRoZXNlIG1ha2UgaWRlbnRpZmljYXRpb24gb2YgdGhl IHN1YnRhZydzDQogICB0eXBlIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBjb250ZW50IG9mIHRoZSBz dWJ0YWcgaXRzZWxmIGlzDQogICB1bnJlY29nbml6ZWQuICBUaGlzIGFsbG93cyB0YWdzIHRvIGJl IHBhcnNlZCBhbmQgcHJvY2Vzc2VkIHdpdGhvdXQNCiAgIHJlZmVyZW5jZSB0byB0aGUgbGF0ZXN0 IHZlcnNpb24gb2YgdGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzIG9yIHRoZQ0KICAgSUFOQSByZWdp c3RyeSBhbmQgbWFrZXMgdGhlIGFzc29jaWF0ZWQgZXhjZXB0aW9uIGhhbmRsaW5nIHdoZW4NCiAg IHBhcnNpbmcgdGFncyBzaW1wbGVyLg0KDQogICBTdWJ0YWdzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5 IHRoYXQgZG8gbm90IGNvbWUgZnJvbSBhbiB1bmRlcmx5aW5nDQogICBzdGFuZGFyZCBjYW4gb25s eSBhcHBlYXIgaW4gc3BlY2lmaWMgcG9zaXRpb25zIGluIGEgdGFnLg0KICAgU3BlY2lmaWNhbGx5 LCB0aGV5IGNhbiBvbmx5IG9jY3VyIGFzIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBvciBhcw0K ICAgdmFyaWFudCBzdWJ0YWdzLg0KDQogICBOb3RlIHRoYXQgc2VxdWVuY2VzIG9mIHByaXZhdGUg dXNlIGFuZCBleHRlbnNpb24gc3VidGFncyBNVVNUIG9jY3VyDQogICBhdCB0aGUgZW5kIG9mIHRo ZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFuZCBNVVNUIE5PVCBiZSBpbnRlcnNwZXJzZWQNCiAgIHdp dGggc3VidGFncyBkZWZpbmVkIGVsc2V3aGVyZSBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBTaW5n bGUgbGV0dGVyIGFuZCBkaWdpdCBzdWJ0YWdzIGFyZSByZXNlcnZlZCBmb3IgY3VycmVudCBvciBm dXR1cmUNCiAgIHVzZS4gIFRoZXNlIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBjdXJyZW50IHVzZXM6 DQoNCiAgIG8gIFRoZSBzaW5nbGUgbGV0dGVyIHN1YnRhZyAneCcgaXMgcmVzZXJ2ZWQgdG8gaW50 cm9kdWNlIGEgc2VxdWVuY2UNCiAgICAgIG9mIHByaXZhdGUgdXNlIHN1YnRhZ3MuICBUaGUgaW50 ZXJwcmV0YXRpb24gb2YgYW55IHByaXZhdGUgdXNlDQogICAgICBzdWJ0YWdzIGlzIGRlZmluZWQg c29sZWx5IGJ5IHByaXZhdGUgYWdyZWVtZW50IGFuZCBpcyBub3QgZGVmaW5lZA0KICAgICAgYnkg dGhlIHJ1bGVzIGluIHRoaXMgc2VjdGlvbiBvciBpbiBhbnkgc3RhbmRhcmQgb3IgcmVnaXN0cnkN CiAgICAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgbyAgQWxsIG90aGVyIHNpbmds ZSBsZXR0ZXIgc3VidGFncyBhcmUgcmVzZXJ2ZWQgdG8gaW50cm9kdWNlDQogICAgICBzdGFuZGFy ZGl6ZWQgZXh0ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZXMgYXMgZGVzY3JpYmVkIGluDQogICAgICBT ZWN0aW9uIDMuNi4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUN Cg0KDQogICBUaGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29tZSBncmFu ZGZhdGhlcmVkIHRhZ3MsIHN1Y2gNCiAgIGFzICJpLWVub2NoaWFuIiwgd2hlcmUgaXQgYWx3YXlz IGFwcGVhcnMgaW4gdGhlIGZpcnN0IHBvc2l0aW9uIGFuZA0KICAgY2Fubm90IGJlIGNvbmZ1c2Vk IHdpdGggYW4gZXh0ZW5zaW9uLg0KDQoyLjIuMSAgUHJpbWFyeSBMYW5ndWFnZSBTdWJ0YWcNCg0K ICAgVGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHRoZSBmaXJzdCBzdWJ0YWcgaW4gYSBs YW5ndWFnZSB0YWcNCiAgICh3aXRoIHRoZSBleGNlcHRpb24gb2YgcHJpdmF0ZSB1c2UgYW5kIGNl cnRhaW4gZ3JhbmRmYXRoZXJlZCB0YWdzKQ0KICAgYW5kIGNhbm5vdCBiZSBvbWl0dGVkLiAgVGhl IGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3VidGFn Og0KDQogICAxLiAgQWxsIHR3byBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3VidGFncyB3ZXJlIGRlZmlu ZWQgaW4gdGhlIElBTkENCiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1l bnRzIGZvdW5kIGluIHRoZSBzdGFuZGFyZCBJU08NCiAgICAgICA2MzkgUGFydCAxLCAiSVNPIDYz OS0xOjIwMDIsIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YNCiAgICAgICBuYW1lcyBv ZiBsYW5ndWFnZXMgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiIFtJU082MzktMV0sIG9yIHVzaW5n DQogICAgICAgYXNzaWdubWVudHMgc3Vic2VxdWVudGx5IG1hZGUgYnkgdGhlIElTTyA2MzkgUGFy dCAxIG1haW50ZW5hbmNlDQogICAgICAgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRp b24gYm9kaWVzLg0KDQogICAyLiAgQWxsIHRocmVlIGNoYXJhY3RlciBsYW5ndWFnZSBzdWJ0YWdz IHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0 aGUgYXNzaWdubWVudHMgZm91bmQgaW4gSVNPIDYzOSBQYXJ0IDIsDQogICAgICAgIklTTyA2Mzkt MjoxOTk4IC0gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZg0KICAgICAg IGxhbmd1YWdlcyAtLSBQYXJ0IDI6IEFscGhhLTMgY29kZSAtIGVkaXRpb24gMSIgW0lTTzYzOS0y XSwgb3INCiAgICAgICBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDYz OSBQYXJ0IDIgbWFpbnRlbmFuY2UNCiAgICAgICBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5kYXJk aXphdGlvbiBib2RpZXMuDQoNCiAgIDMuICBUaGUgc3VidGFncyBpbiB0aGUgcmFuZ2UgJ3FhYScg dGhyb3VnaCAncXR6JyBhcmUgcmVzZXJ2ZWQgZm9yDQogICAgICAgcHJpdmF0ZSB1c2UgaW4gbGFu Z3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MgY29ycmVzcG9uZCB0byBjb2Rlcw0KICAgICAgIHJl c2VydmVkIGJ5IElTTyA2MzktMiBmb3IgcHJpdmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUg dXNlZA0KICAgICAgIGZvciBub24tcmVnaXN0ZXJlZCBwcmltYXJ5LWxhbmd1YWdlIHN1YnRhZ3Mg KGluc3RlYWQgb2YgdXNpbmcNCiAgICAgICBwcml2YXRlIHVzZSBzdWJ0YWdzIGZvbGxvd2luZyAn eC0nKS4gIFBsZWFzZSByZWZlciB0byBTZWN0aW9uIDQuNQ0KICAgICAgIGZvciBtb3JlIGluZm9y bWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgIDQuICBBbGwgZm91ciBjaGFyYWN0 ZXIgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgcmVzZXJ2ZWQgZm9yIHBvc3NpYmxlDQogICAgICAgZnV0 dXJlIHN0YW5kYXJkaXphdGlvbi4NCg0KICAgNS4gIEFsbCBsYW5ndWFnZSBzdWJ0YWdzIG9mIDUg dG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IHdl cmUgZGVmaW5lZCB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGluIFNlY3Rpb24gMy40DQog ICAgICAgYW5kIE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFn LiAgQXQgdGhlIHRpbWUNCiAgICAgICB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCB0aGVyZSB3 ZXJlIG5vIGV4YW1wbGVzIG9mIHRoaXMga2luZCBvZg0KICAgICAgIHN1YnRhZyBhbmQgZnV0dXJl IHJlZ2lzdHJhdGlvbnMgb2YgdGhpcyB0eXBlIHdpbGwgYmUgZGlzY291cmFnZWQ6DQogICAgICAg cHJpbWFyeSBsYW5ndWFnZXMgYXJlIHN0cm9uZ2x5IFJFQ09NTUVOREVEIGZvciByZWdpc3RyYXRp b24gd2l0aA0KICAgICAgIElTTyA2MzkgYW5kIHByb3Bvc2FscyByZWplY3RlZCBieSBJU08gNjM5 L1JBIHdpbGwgYmUgY2xvc2VseQ0KICAgICAgIHNjcnV0aW5pemVkIGJlZm9yZSB0aGV5IGFyZSBy ZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KICAgNi4gIFRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRh ZyAneCcgYXMgdGhlIHByaW1hcnkgc3VidGFnIGluZGljYXRlcw0KICAgICAgIHRoYXQgdGhlIGxh bmd1YWdlIHRhZyBjb25zaXN0cyBzb2xlbHkgb2Ygc3VidGFncyB3aG9zZSBtZWFuaW5nIGlzDQog ICAgICAgZGVmaW5lZCBieSBwcml2YXRlIGFncmVlbWVudC4gIEZvciBleGFtcGxlLCBpbiB0aGUg dGFnICJ4LWZyLUNIIiwNCiAgICAgICB0aGUgc3VidGFncyAnZnInIGFuZCAnQ0gnIFNIT1VMRCBO T1QgYmUgdGFrZW4gdG8gcmVwcmVzZW50IHRoZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAgRnJlbmNoIGxhbmd1YWdlIG9yIHRoZSBjb3VudHJ5 IG9mIFN3aXR6ZXJsYW5kIChvciBhbnkgb3RoZXIgdmFsdWUNCiAgICAgICBpbiB0aGUgSUFOQSBy ZWdpc3RyeSkgdW5sZXNzIHRoZXJlIGlzIGEgcHJpdmF0ZSBhZ3JlZW1lbnQgaW4NCiAgICAgICBw bGFjZSB0byBkbyBzby4gIFNlZSBTZWN0aW9uIDQuNS4NCg0KICAgNy4gIFRoZSBzaW5nbGUgY2hh cmFjdGVyIHN1YnRhZyAnaScgaXMgdXNlZCBieSBzb21lIGdyYW5kZmF0aGVyZWQNCiAgICAgICB0 YWdzIChzZWUgU2VjdGlvbiAyLjIuOCkgc3VjaCBhcyAiaS1rbGluZ29uIiBhbmQgImktYm5uIi4g IChPdGhlcg0KICAgICAgIGdyYW5kZmF0aGVyZWQgdGFncyBoYXZlIGEgcHJpbWFyeSBsYW5ndWFn ZSBzdWJ0YWcgaW4gdGhlaXIgZmlyc3QNCiAgICAgICBwb3NpdGlvbikNCg0KICAgOC4gIE90aGVy IHZhbHVlcyBNVVNUIE5PVCBiZSBhc3NpZ25lZCB0byB0aGUgcHJpbWFyeSBzdWJ0YWcgZXhjZXB0 IGJ5DQogICAgICAgcmV2aXNpb24gb3IgdXBkYXRlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5v dGU6IEZvciBsYW5ndWFnZXMgdGhhdCBoYXZlIGJvdGggYW4gSVNPIDYzOS0xIHR3byBjaGFyYWN0 ZXIgY29kZQ0KICAgYW5kIGFuIElTTyA2MzktMiB0aHJlZSBjaGFyYWN0ZXIgY29kZSwgb25seSB0 aGUgSVNPIDYzOS0xIHR3bw0KICAgY2hhcmFjdGVyIGNvZGUgaXMgZGVmaW5lZCBpbiB0aGUgSUFO QSByZWdpc3RyeS4NCg0KICAgTm90ZTogRm9yIGxhbmd1YWdlcyB0aGF0IGhhdmUgbm8gSVNPIDYz OS0xIHR3byBjaGFyYWN0ZXIgY29kZSBhbmQgZm9yDQogICB3aGljaCB0aGUgSVNPIDYzOS0yL1Qg KFRlcm1pbm9sb2d5KSBjb2RlIGFuZCB0aGUgSVNPIDYzOS0yL0INCiAgIChCaWJsaW9ncmFwaGlj KSBjb2RlcyBkaWZmZXIsIG9ubHkgdGhlIFRlcm1pbm9sb2d5IGNvZGUgaXMgZGVmaW5lZCBpbg0K ICAgdGhlIElBTkEgcmVnaXN0cnkuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVh dGVkLCBhbGwNCiAgIGxhbmd1YWdlcyB0aGF0IGhhZCBib3RoIGtpbmRzIG9mIHRocmVlIGNoYXJh Y3RlciBjb2RlIHdlcmUgYWxzbw0KICAgYXNzaWduZWQgYSB0d28gY2hhcmFjdGVyIGNvZGU7IGl0 IGlzIG5vdCBleHBlY3RlZCB0aGF0IGZ1dHVyZQ0KICAgYXNzaWdubWVudHMgb2YgdGhpcyBuYXR1 cmUgd2lsbCBvY2N1ci4NCg0KICAgTm90ZTogVG8gYXZvaWQgcHJvYmxlbXMgd2l0aCB2ZXJzaW9u aW5nIGFuZCBzdWJ0YWcgY2hvaWNlIGFzDQogICBleHBlcmllbmNlZCBkdXJpbmcgdGhlIHRyYW5z aXRpb24gYmV0d2VlbiBSRkMgMTc2NiBhbmQgUkZDIDMwNjYsIGFzDQogICB3ZWxsIGFzIHRoZSBj YW5vbmljYWwgbmF0dXJlIG9mIHN1YnRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50LCB0aGUN CiAgIElTTyA2MzkgUmVnaXN0cmF0aW9uIEF1dGhvcml0eSBKb2ludCBBZHZpc29yeSBDb21taXR0 ZWUgKElTTyA2MzkvDQogICBSQS1KQUMpIGhhcyBpbmNsdWRlZCB0aGUgZm9sbG93aW5nIHN0YXRl bWVudCBpbiBbaXNvNjM5LnByaW5jaXBsZXNdOg0KDQogICAiQSBsYW5ndWFnZSBjb2RlIGFscmVh ZHkgaW4gSVNPIDYzOS0yIGF0IHRoZSBwb2ludCBvZiBmcmVlemluZyBJU08NCiAgIDYzOS0xIHNo YWxsIG5vdCBsYXRlciBiZSBhZGRlZCB0byBJU08gNjM5LTEuICBUaGlzIGlzIHRvIGVuc3VyZQ0K ICAgY29uc2lzdGVuY3kgaW4gdXNhZ2Ugb3ZlciB0aW1lLCBzaW5jZSB1c2VycyBhcmUgZGlyZWN0 ZWQgaW4gSW50ZXJuZXQNCiAgIGFwcGxpY2F0aW9ucyB0byBlbXBsb3kgdGhlIGFscGhhLTMgY29k ZSB3aGVuIGFuIGFscGhhLTIgY29kZSBmb3IgdGhhdA0KICAgbGFuZ3VhZ2UgaXMgbm90IGF2YWls YWJsZS4iDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIGluc3RhYmlsaXR5IGluIHRoZSBjYW5vbmlj YWwgZm9ybSBvZiB0YWdzLCBpZiBhIHR3bw0KICAgY2hhcmFjdGVyIGNvZGUgaXMgYWRkZWQgdG8g SVNPIDYzOS0xIGZvciBhIGxhbmd1YWdlIGZvciB3aGljaCBhIHRocmVlDQogICBjaGFyYWN0ZXIg Y29kZSB3YXMgYWxyZWFkeSBpbmNsdWRlZCBpbiBJU08gNjM5LTIsIHRoZSB0d28gY2hhcmFjdGVy DQogICBjb2RlIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQuICBTZWUgU2VjdGlvbiAzLjMuDQoNCiAg IEZvciBleGFtcGxlLCBpZiBzb21lIGNvbnRlbnQgd2VyZSB0YWdnZWQgd2l0aCAnaGF3JyAoSGF3 YWlpYW4pLCB3aGljaA0KICAgY3VycmVudGx5IGhhcyBubyB0d28gY2hhcmFjdGVyIGNvZGUsIHRo ZSB0YWcgd291bGQgbm90IGJlIGludmFsaWRhdGVkDQogICBpZiBJU08gNjM5LTEgd2VyZSB0byBh c3NpZ24gYSB0d28gY2hhcmFjdGVyIGNvZGUgdG8gdGhlIEhhd2FpaWFuDQogICBsYW5ndWFnZSBh dCBhIGxhdGVyIGRhdGUuDQoNCiAgIEZvciBleGFtcGxlLCBvbmUgb2YgdGhlIGdyYW5kZmF0aGVy ZWQgSUFOQSByZWdpc3RyYXRpb25zIGlzDQogICAiaS1lbm9jaGlhbiIuICBUaGUgc3VidGFnICdl bm9jaGlhbicgY291bGQgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQQ0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgIFtQ YWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICByZWdpc3RyeSBhcyBhIHByaW1hcnkg bGFuZ3VhZ2Ugc3VidGFnIChhc3N1bWluZyB0aGF0IElTTyA2MzkgZG9lcyBub3QNCiAgIHJlZ2lz dGVyIHRoaXMgbGFuZ3VhZ2UgZmlyc3QpLCBtYWtpbmcgdGFncyBzdWNoIGFzICJlbm9jaGlhbi1B USIgYW5kDQogICAiZW5vY2hpYW4tTGF0biIgdmFsaWQuDQoNCjIuMi4yICBFeHRlbmRlZCBMYW5n dWFnZSBTdWJ0YWdzDQoNCiAgIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIGV4dGVu ZGVkIGxhbmd1YWdlIHN1YnRhZ3M6DQoNCiAgIDEuICBUaHJlZSBsZXR0ZXIgc3VidGFncyBpbW1l ZGlhdGVseSBmb2xsb3dpbmcgdGhlIHByaW1hcnkgc3VidGFnIGFyZQ0KICAgICAgIHJlc2VydmVk IGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9uLCBhbnRpY2lwYXRpbmcgd29yayB0aGF0IGlzDQog ICAgICAgY3VycmVudGx5IHVuZGVyIHdheSBvbiBJU08gNjM5Lg0KDQogICAyLiAgRXh0ZW5kZWQg bGFuZ3VhZ2Ugc3VidGFncyBNVVNUIGZvbGxvdyB0aGUgcHJpbWFyeSBzdWJ0YWcgYW5kDQogICAg ICAgcHJlY2VkZSBhbnkgb3RoZXIgc3VidGFncy4NCg0KICAgMy4gIFRoZXJlIE1BWSBiZSB1cCB0 byB0aHJlZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzLg0KDQogICA0LiAgRXh0ZW5kZWQgbGFu Z3VhZ2Ugc3VidGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIG9yIHVzZWQgdG8gZm9ybQ0KICAg ICAgIGxhbmd1YWdlIHRhZ3MuICBUaGVpciBzeW50YXggaXMgZGVzY3JpYmVkIGhlcmUgc28gdGhh dA0KICAgICAgIGltcGxlbWVudGF0aW9ucyBjYW4gYmUgY29tcGF0aWJsZSB3aXRoIGFueSBmdXR1 cmUgcmV2aXNpb24gb2YNCiAgICAgICB0aGlzIGRvY3VtZW50IHdoaWNoIGRvZXMgcHJvdmlkZSBm b3IgdGhlaXIgcmVnaXN0cmF0aW9uLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcgcmVj b3Jkcywgb25jZSB0aGV5IGFwcGVhciBpbiB0aGUgcmVnaXN0cnksDQogICBNVVNUIGluY2x1ZGUg ZXhhY3RseSBvbmUgJ1ByZWZpeCcgZmllbGQgaW5kaWNhdGluZyBhbiBhcHByb3ByaWF0ZQ0KICAg bGFuZ3VhZ2Ugc3VidGFnIG9yIHNlcXVlbmNlIG9mIHN1YnRhZ3MgdGhhdCBNVVNUIGFsd2F5cyBh cHBlYXIgYXMgYQ0KICAgcHJlZml4IHRvIHRoZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcuDQoN CiAgIEV4YW1wbGU6IEluIGEgZnV0dXJlIHJldmlzaW9uIG9yIHVwZGF0ZSBvZiB0aGlzIGRvY3Vt ZW50LCB0aGUgdGFnDQogICAiemgtZ2FuIiAocmVnaXN0ZXJlZCB1bmRlciBSRkMgMzA2NikgbWln aHQgYmVjb21lIGEgdmFsaWQgbm9uLQ0KICAgZ3JhbmRmYXRoZXJlZCAodGhhdCBpcywgcmVkdW5k YW50KSB0YWcgaW4gd2hpY2ggdGhlIHN1YnRhZyAnZ2FuJw0KICAgbWlnaHQgcmVwcmVzZW50IHRo ZSBDaGluZXNlIGRpYWxlY3QgJ0dhbicuDQoNCjIuMi4zICBTY3JpcHQgU3VidGFnDQoNCiAgIFNj cmlwdCBzdWJ0YWdzIGFyZSB1c2VkIHRvIGluZGljYXRlIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBz eXN0ZW0NCiAgIHZhcmlhdGlvbnMgdGhhdCBkaXN0aW5ndWlzaCB0aGUgd3JpdHRlbiBmb3JtcyBv ZiBhIGxhbmd1YWdlIG9yIGl0cw0KICAgZGlhbGVjdHMuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFw cGx5IHRvIHRoZSBzY3JpcHQgc3VidGFnczoNCg0KICAgMS4gIEFsbCBmb3VyIGNoYXJhY3RlciBz dWJ0YWdzIHdlcmUgZGVmaW5lZCBhY2NvcmRpbmcgdG8NCiAgICAgICBbSVNPMTU5MjRdLS0iQ29k ZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgbmFtZXMgb2YNCiAgICAgICBzY3JpcHRz IjogYWxwaGEtNCBzY3JpcHQgY29kZXMsIG9yIHN1YnNlcXVlbnRseSBhc3NpZ25lZCBieSB0aGUN CiAgICAgICBJU08gMTU5MjQgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFy ZGl6YXRpb24gYm9kaWVzLA0KICAgICAgIGRlbm90aW5nIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBz eXN0ZW0gdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoDQogICAgICAgdGhpcyBsYW5ndWFnZS4NCg0K ICAgMi4gIFNjcmlwdCBzdWJ0YWdzIE1VU1QgaW1tZWRpYXRlbHkgZm9sbG93IHRoZSBwcmltYXJ5 IGxhbmd1YWdlDQogICAgICAgc3VidGFnIGFuZCBhbGwgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFn cyBhbmQgTVVTVCBvY2N1ciBiZWZvcmUNCiAgICAgICBhbnkgb3RoZXIgdHlwZSBvZiBzdWJ0YWcg ZGVzY3JpYmVkIGJlbG93Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIw MDUNCg0KDQogICAzLiAgVGhlIHNjcmlwdCBzdWJ0YWdzICdRYWFhJyB0aHJvdWdoICdRYWJ4JyBh cmUgcmVzZXJ2ZWQgZm9yIHByaXZhdGUNCiAgICAgICB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRo ZXNlIHN1YnRhZ3MgY29ycmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZA0KICAgICAgIGJ5IElTTyAx NTkyNCBmb3IgcHJpdmF0ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZCBmb3Igbm9uLQ0K ICAgICAgIHJlZ2lzdGVyZWQgc2NyaXB0IHZhbHVlcy4gIFBsZWFzZSByZWZlciB0byBTZWN0aW9u IDQuNSBmb3IgbW9yZQ0KICAgICAgIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3Mu DQoNCiAgIDQuICBTY3JpcHQgc3VidGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIHVzaW5nIHRo ZSBwcm9jZXNzIGluDQogICAgICAgU2VjdGlvbiAzLjQgb2YgdGhpcyBkb2N1bWVudC4gIFZhcmlh bnQgc3VidGFncyBNQVkgYmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdpc3RyYXRpb24gZm9y IHRoYXQgcHVycG9zZS4NCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgc2NyaXB0 IHN1YnRhZyBpbiBhIGxhbmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgc2NyaXB0IHN1YnRhZyBT SE9VTEQgYmUgb21pdHRlZCB3aGVuIGl0IGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcNCiAgICAgICB2 YWx1ZSB0byB0aGUgdGFnIG9yIHdoZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnJ3MgcmVj b3JkDQogICAgICAgaW5jbHVkZXMgYSBTdXBwcmVzcy1TY3JpcHQgZmllbGQgbGlzdGluZyB0aGUg YXBwbGljYWJsZSBzY3JpcHQNCiAgICAgICBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6ICJzci1MYXRu IiByZXByZXNlbnRzIFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0Lg0KDQoy LjIuNCAgUmVnaW9uIFN1YnRhZw0KDQogICBSZWdpb24gc3VidGFncyBhcmUgdXNlZCB0byBpbmRp Y2F0ZSBsaW5ndWlzdGljIHZhcmlhdGlvbnMgYXNzb2NpYXRlZA0KICAgd2l0aCBvciBhcHByb3By aWF0ZSB0byBhIHNwZWNpZmljIGNvdW50cnksIHRlcnJpdG9yeSwgb3IgcmVnaW9uLg0KICAgVHlw aWNhbGx5LCBhIHJlZ2lvbiBzdWJ0YWcgaXMgdXNlZCB0byBpbmRpY2F0ZSByZWdpb25hbCBkaWFs ZWN0cyBvcg0KICAgdXNhZ2UsIG9yIHJlZ2lvbi1zcGVjaWZpYyBzcGVsbGluZyBjb252ZW50aW9u cy4gIEEgcmVnaW9uIHN1YnRhZyBjYW4NCiAgIGFsc28gYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGF0 IGNvbnRlbnQgaXMgZXhwcmVzc2VkIGluIGEgd2F5IHRoYXQgaXMNCiAgIGFwcHJvcHJpYXRlIGZv ciB1c2UgdGhyb3VnaG91dCBhIHJlZ2lvbjsgZm9yIGluc3RhbmNlLCBTcGFuaXNoDQogICBjb250 ZW50IHRhaWxvcmVkIHRvIGJlIHVzZWZ1bCB0aHJvdWdob3V0IExhdGluIEFtZXJpY2EuDQoNCiAg IFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIHJlZ2lvbiBzdWJ0YWdzOg0KDQogICAx LiAgUmVnaW9uIHN1YnRhZ3MgTVVTVCBmb2xsb3cgYW55IGxhbmd1YWdlLCBleHRlbmRlZCBsYW5n dWFnZSwgb3INCiAgICAgICBzY3JpcHQgc3VidGFncyBhbmQgTVVTVCBwcmVjZWRlIGFsbCBvdGhl ciBzdWJ0YWdzLg0KDQogICAyLiAgQWxsIHR3byBjaGFyYWN0ZXIgc3VidGFncyBmb2xsb3dpbmcg dGhlIHByaW1hcnkgc3VidGFnIHdlcmUNCiAgICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lz dHJ5IGFjY29yZGluZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQNCiAgICAgICBpbiBbSVNPMzE2 Ni0xXSAoIkNvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YNCiAgICAgICBj b3VudHJpZXMgYW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAtLSBQYXJ0IDE6IENvdW50cnkgY29kZXMi KSB1c2luZw0KICAgICAgIHRoZSBsaXN0IG9mIGFscGhhLTIgY291bnRyeSBjb2Rlcywgb3IgdXNp bmcgYXNzaWdubWVudHMNCiAgICAgICBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDMxNjYg bWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZw0KICAgICAgIHN0YW5kYXJkaXphdGlvbiBi b2RpZXMuDQoNCiAgIDMuICBBbGwgdGhyZWUgY2hhcmFjdGVyIHN1YnRhZ3MgY29uc2lzdGluZyBv ZiBkaWdpdCAobnVtZXJpYykNCiAgICAgICBjaGFyYWN0ZXJzIGZvbGxvd2luZyB0aGUgcHJpbWFy eSBzdWJ0YWcgd2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgYWNjb3Jk aW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiBVTiBTdGFuZGFyZA0KICAgICAgIENvdW50 cnkgb3IgQXJlYSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgIFVzZSBbVU5fTS40OV0gb3INCiAgICAg ICBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgZ292ZXJuaW5nIHN0YW5kYXJk cyBib2R5Lg0KICAgICAgIE5vdGUgdGhhdCBub3QgYWxsIG9mIHRoZSBVTiBNLjQ5IGNvZGVzIGFy ZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkuICBUaGUgZm9sbG93aW5nIHJ1 bGVzIGRlZmluZSB3aGljaCBjb2RlcyBhcmUgZW50ZXJlZA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAgaW50byB0aGUgcmVnaXN0cnkgYXMgdmFs aWQgc3VidGFnczoNCg0KICAgICAgIEEuICBVTiBudW1lcmljIGNvZGVzIGFzc2lnbmVkIHRvICdt YWNyby1nZW9ncmFwaGljYWwNCiAgICAgICAgICAgKGNvbnRpbmVudGFsKScgb3Igc3ViLXJlZ2lv bnMgTVVTVCBiZSByZWdpc3RlcmVkIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeS4gIFRoZXNl IGNvZGVzIGFyZSBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbmVkDQogICAgICAgICAgIElT TyAzMTY2IGFscGhhLTIgY29kZSBhbmQgcmVwcmVzZW50IHN1cHJhLW5hdGlvbmFsIGFyZWFzLA0K ICAgICAgICAgICB1c3VhbGx5IGNvdmVyaW5nIG1vcmUgdGhhbiBvbmUgbmF0aW9uLCBzdGF0ZSwg cHJvdmluY2UsIG9yDQogICAgICAgICAgIHRlcnJpdG9yeS4NCg0KICAgICAgIEIuICBVTiBudW1l cmljIGNvZGVzIGZvciAnZWNvbm9taWMgZ3JvdXBpbmdzJyBvciAnb3RoZXINCiAgICAgICAgICAg Z3JvdXBpbmdzJyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFu ZA0KICAgICAgICAgICBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0K ICAgICAgIEMuICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMgd2l0aCBh bWJpZ3VvdXMgSVNPDQogICAgICAgICAgIDMxNjYgYWxwaGEtMiBjb2Rlcywgd2hlbiBlbnRlcmVk IGludG8gdGhlIHJlZ2lzdHJ5LCBNVVNUIGJlDQogICAgICAgICAgIGRlZmluZWQgYWNjb3JkaW5n IHRvIHRoZSBydWxlcyBpbiBTZWN0aW9uIDMuMyBhbmQgTVVTVCBiZQ0KICAgICAgICAgICB1c2Vk IHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB0aGF0IHJlcHJlc2VudCB0aGUgY291bnRyeSBvcg0KICAg ICAgICAgICByZWdpb24gZm9yIHdoaWNoIHRoZXkgYXJlIGRlZmluZWQuDQoNCiAgICAgICBELiAg VU4gbnVtZXJpYyBjb2RlcyBmb3IgY291bnRyaWVzIG9yIGFyZWFzIGZvciB3aGljaCB0aGVyZSBp cyBhbg0KICAgICAgICAgICBhc3NvY2lhdGVkIElTTyAzMTY2IGFscGhhLTIgY29kZSBpbiB0aGUg cmVnaXN0cnkgTVVTVCBOT1QgYmUNCiAgICAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3Ry eSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0byBmb3JtDQogICAgICAgICAgIGxhbmd1YWdlIHRhZ3Mu ICBOb3RlIHRoYXQgdGhlIElTTyAzMTY2LWJhc2VkIHN1YnRhZyBpbiB0aGUNCiAgICAgICAgICAg cmVnaXN0cnkgTVVTVCBhY3R1YWxseSBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIFVOIE0uNDkgY29k ZSBpbg0KICAgICAgICAgICBxdWVzdGlvbi4NCg0KICAgICAgIEUuICBVTiBudW1lcmljIGNvZGVz IGFuZCBJU08gMzE2NiBhbHBoYS0yIGNvZGVzIGZvciBjb3VudHJpZXMgb3INCiAgICAgICAgICAg YXJlYXMgbGlzdGVkIGFzIGVsaWdpYmxlIGZvciByZWdpc3RyYXRpb24gaW4gW2luaXRpYWwtDQog ICAgICAgICAgIHJlZ2lzdHJ5XSBidXQgbm90IHByZXNlbnRseSByZWdpc3RlcmVkIE1BWSBiZSBl bnRlcmVkIGludG8NCiAgICAgICAgICAgdGhlIElBTkEgcmVnaXN0cnkgdmlhIHRoZSBwcm9jZXNz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNC4NCiAgICAgICAgICAgT25jZSByZWdpc3RlcmVkLCB0 aGVzZSBjb2RlcyBNQVkgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlDQogICAgICAgICAgIHRhZ3Mu DQoNCiAgICAgICBGLiAgQWxsIG90aGVyIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmllcyBv ciBhcmVhcyB3aGljaCBkbw0KICAgICAgICAgICBub3QgaGF2ZSBhbiBhc3NvY2lhdGVkIElTTyAz MTY2IGFscGhhLTIgY29kZSBNVVNUIE5PVCBiZQ0KICAgICAgICAgICBlbnRlcmVkIGludG8gdGhl IHJlZ2lzdHJ5IGFuZCBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0NCiAgICAgICAgICAgbGFuZ3Vh Z2UgdGFncy4gIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZXNlIGNvZGVzLCBzZWUNCiAg ICAgICAgICAgU2VjdGlvbiAzLjMuDQoNCiAgIDQuICBOb3RlOiBUaGUgYWxwaGFudW1lcmljIGNv ZGVzIGluIEFwcGVuZGl4IFggb2YgdGhlIFVOIGRvY3VtZW50DQogICAgICAgTVVTVCBOT1QgYmUg ZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0bw0KICAgICAg IGZvcm0gbGFuZ3VhZ2UgdGFncy4gIChBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVh dGVkIHRoZXNlDQogICAgICAgdmFsdWVzIG1hdGNoIHRoZSBJU08gMzE2NiBhbHBoYS0yIGNvZGVz LikNCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUgcmVnaW9uIHN1YnRhZyBpbiBh IGxhbmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgcmVnaW9uIHN1YnRhZyBNQVkgYmUgb21pdHRl ZCwgYXMgd2hlbiBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQogICAgICAgdmFsdWUgdG8gdGhl IHRhZy4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAx OCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQog ICA2LiAgVGhlIHJlZ2lvbiBzdWJ0YWdzICdBQScsICdRTSctJ1FaJywgJ1hBJy0nWFonLCBhbmQg J1paJyBhcmUNCiAgICAgICByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1c2UgaW4gbGFuZ3VhZ2UgdGFn cy4gIFRoZXNlIHN1YnRhZ3MNCiAgICAgICBjb3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkIGJ5 IElTTyAzMTY2IGZvciBwcml2YXRlIHVzZS4gIFRoZXNlDQogICAgICAgY29kZXMgTUFZIGJlIHVz ZWQgZm9yIHByaXZhdGUgdXNlIHJlZ2lvbiBzdWJ0YWdzIChpbnN0ZWFkIG9mDQogICAgICAgdXNp bmcgYSBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2UpLiAgUGxlYXNlIHJlZmVyIHRvDQogICAg ICAgU2VjdGlvbiA0LjUgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gcHJpdmF0ZSB1c2Ugc3VidGFn cy4NCg0KICAgImRlLUNIIiByZXByZXNlbnRzIEdlcm1hbiAoJ2RlJykgYXMgdXNlZCBpbiBTd2l0 emVybGFuZCAoJ0NIJykuDQoNCiAgICJzci1MYXRuLUNTIiByZXByZXNlbnRzIFNlcmJpYW4gKCdz cicpIHdyaXR0ZW4gdXNpbmcgTGF0aW4gc2NyaXB0DQogICAoJ0xhdG4nKSBhcyB1c2VkIGluIFNl cmJpYSBhbmQgTW9udGVuZWdybyAoJ0NTJykuDQoNCiAgICJlcy00MTkiIHJlcHJlc2VudHMgU3Bh bmlzaCAoJ2VzJykgYXBwcm9wcmlhdGUgdG8gdGhlIFVOLWRlZmluZWQNCiAgIExhdGluIEFtZXJp Y2EgYW5kIENhcmliYmVhbiByZWdpb24gKCc0MTknKS4NCg0KMi4yLjUgIFZhcmlhbnQgU3VidGFn cw0KDQogICBWYXJpYW50IHN1YnRhZ3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgYWRkaXRpb25hbCwg d2VsbC1yZWNvZ25pemVkDQogICB2YXJpYXRpb25zIHRoYXQgZGVmaW5lIGEgbGFuZ3VhZ2Ugb3Ig aXRzIGRpYWxlY3RzIHdoaWNoIGFyZSBub3QNCiAgIGNvdmVyZWQgYnkgb3RoZXIgYXZhaWxhYmxl IHN1YnRhZ3MuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZQ0KICAgdmFyaWFudCBz dWJ0YWdzOg0KDQogICAxLiAgVmFyaWFudCBzdWJ0YWdzIGFyZSBub3QgYXNzb2NpYXRlZCB3aXRo IGFueSBleHRlcm5hbCBzdGFuZGFyZC4NCiAgICAgICBWYXJpYW50IHN1YnRhZ3MgYW5kIHRoZWly IG1lYW5pbmdzIGFyZSBkZWZpbmVkIGJ5IHRoZQ0KICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNz IGRlZmluZWQgaW4gU2VjdGlvbiAzLjQuDQoNCiAgIDIuICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBm b2xsb3cgYWxsIG9mIHRoZSBvdGhlciBkZWZpbmVkIHN1YnRhZ3MsIGJ1dA0KICAgICAgIHByZWNl ZGUgYW55IGV4dGVuc2lvbiBvciBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAz LiAgTW9yZSB0aGFuIG9uZSB2YXJpYW50IE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIGxhbmd1YWdl IHRhZy4NCg0KICAgNC4gIFZhcmlhbnQgc3VidGFncyBNVVNUIGJlIHJlZ2lzdGVyZWQgd2l0aCBJ QU5BIGFjY29yZGluZyB0byB0aGUNCiAgICAgICBydWxlcyBpbiBTZWN0aW9uIDMuNCBvZiB0aGlz IGRvY3VtZW50IGJlZm9yZSBiZWluZyB1c2VkIHRvIGZvcm0NCiAgICAgICBsYW5ndWFnZSB0YWdz LiAgSW4gb3JkZXIgdG8gZGlzdGluZ3Vpc2ggdmFyaWFudHMgZnJvbSBvdGhlciB0eXBlcw0KICAg ICAgIG9mIHN1YnRhZ3MsIHJlZ2lzdHJhdGlvbnMgTVVTVCBtZWV0IHRoZSBmb2xsb3dpbmcgbGVu Z3RoIGFuZA0KICAgICAgIGNvbnRlbnQgcmVzdHJpY3Rpb25zOg0KDQogICAgICAgMS4gIFZhcmlh bnQgc3VidGFncyB0aGF0IGJlZ2luIHdpdGggYSBsZXR0ZXIgKGEteiwgQS1aKSBNVVNUIGJlDQog ICAgICAgICAgIGF0IGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0KDQogICAgICAgMi4gIFZh cmlhbnQgc3VidGFncyB0aGF0IGJlZ2luIHdpdGggYSBkaWdpdCAoMC05KSBNVVNUIGJlIGF0DQog ICAgICAgICAgIGxlYXN0IGZvdXIgY2hhcmFjdGVycyBsb25nLg0KDQogICBWYXJpYW50IHN1YnRh ZyByZWNvcmRzIGluIHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkgTUFZIGluY2x1ZGUNCiAg IG9uZSBvciBtb3JlICdQcmVmaXgnIGZpZWxkcywgd2hpY2ggaW5kaWNhdGVzIHRoZSBsYW5ndWFn ZSB0YWcgb3IgdGFncw0KICAgdGhhdCB3b3VsZCBtYWtlIGEgc3VpdGFibGUgcHJlZml4ICh3aXRo IG90aGVyIHN1YnRhZ3MsIGFzDQogICBhcHByb3ByaWF0ZSkgaW4gZm9ybWluZyBhIGxhbmd1YWdl IHRhZyB3aXRoIHRoZSB2YXJpYW50LiAgRm9yDQogICBleGFtcGxlLCB0aGUgc3VidGFnICduZWRp cycgaGFzIGEgUHJlZml4IG9mICJzbCIsIG1ha2luZyBpdCBzdWl0YWJsZQ0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICB0byBmb3JtIGxhbmd1YWdlIHRh Z3Mgc3VjaCBhcyAic2wtbmVkaXMiIGFuZCAic2wtSVQtbmVkaXMiLCBidXQgbm90DQogICBzdWl0 YWJsZSBmb3IgdXNlIGluIGEgdGFnIHN1Y2ggYXMgInpoLW5lZGlzIiBvciAiaXQtSVQtbmVkaXMi Lg0KDQogICAic2wtbmVkaXMiIHJlcHJlc2VudHMgdGhlIE5hdGlzb25lIG9yIE5hZGl6YSBkaWFs ZWN0IG9mIFNsb3Zlbmlhbi4NCg0KICAgImRlLUNILTE5OTYiIHJlcHJlc2VudHMgR2VybWFuIGFz IHVzZWQgaW4gU3dpdHplcmxhbmQgYW5kIGFzIHdyaXR0ZW4NCiAgIHVzaW5nIHRoZSBzcGVsbGlu ZyByZWZvcm0gYmVnaW5uaW5nIGluIHRoZSB5ZWFyIDE5OTYgQy5FLg0KDQogICBNb3N0IHZhcmlh bnRzIHRoYXQgc2hhcmUgYSBwcmVmaXggYXJlIG11dHVhbGx5IGV4Y2x1c2l2ZS4gIEZvcg0KICAg ZXhhbXBsZSwgdGhlIEdlcm1hbiBvcnRob2dyYXBoaWMgdmFyaWF0aW9ucyAnMTk5NicgYW5kICcx OTAxJyBTSE9VTEQNCiAgIE5PVCBiZSB1c2VkIGluIHRoZSBzYW1lIHRhZywgYXMgdGhleSByZXBy ZXNlbnQgdGhlIGRhdGVzIG9mIGRpZmZlcmVudA0KICAgc3BlbGxpbmcgcmVmb3Jtcy4gIEEgdmFy aWFudCB0aGF0IGNhbiBtZWFuaW5nZnVsbHkgYmUgdXNlZCBpbg0KICAgY29tYmluYXRpb24gd2l0 aCBhbm90aGVyIHZhcmlhbnQgU0hPVUxEIGluY2x1ZGUgYSAnUHJlZml4JyBmaWVsZCBpbg0KICAg aXRzIHJlZ2lzdHJ5IHJlY29yZCB0aGF0IGxpc3RzIHRoYXQgb3RoZXIgdmFyaWFudC4gIEZvciBl eGFtcGxlLCBpZg0KICAgYW5vdGhlciBHZXJtYW4gdmFyaWFudCAnZXhhbXBsZScgd2VyZSBjcmVh dGVkIHRoYXQgbWFkZSBzZW5zZSB0byB1c2UNCiAgIHdpdGggJzE5OTYnLCB0aGVuICdleGFtcGxl JyBzaG91bGQgaW5jbHVkZSB0d28gUHJlZml4IGZpZWxkczogImRlIg0KICAgYW5kICJkZS0xOTk2 Ii4NCg0KMi4yLjYgIEV4dGVuc2lvbiBTdWJ0YWdzDQoNCiAgIEV4dGVuc2lvbnMgcHJvdmlkZSBh IG1lY2hhbmlzbSBmb3IgZXh0ZW5kaW5nIGxhbmd1YWdlIHRhZ3MgZm9yIHVzZSBpbg0KICAgdmFy aW91cyBhcHBsaWNhdGlvbnMuICBTZWU6IFNlY3Rpb24gMy42LiAgVGhlIGZvbGxvd2luZyBydWxl cyBhcHBseQ0KICAgdG8gZXh0ZW5zaW9uczoNCg0KICAgMS4gICBFeHRlbnNpb24gc3VidGFncyBh cmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0KICAgICAgICBpbiB0 aGlzIGRvY3VtZW50IGJ5IGEgc2luZ2xlIGNoYXJhY3RlciBzdWJ0YWcgKCJzaW5nbGV0b24iKS4N CiAgICAgICAgVGhlIHNpbmdsZXRvbiBNVVNUIGJlIG9uZSBhbGxvY2F0ZWQgdG8gYSByZWdpc3Ry YXRpb24gYXV0aG9yaXR5DQogICAgICAgIHZpYSB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDMuNiBhbmQgTVVTVCBOT1QgYmUgdGhlDQogICAgICAgIGxldHRlciAneCcsIHdoaWNo IGlzIHJlc2VydmVkIGZvciBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAyLiAg IE5vdGU6IFByaXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5jZXMgc3RhcnRpbmcgd2l0aCB0aGUgc2lu Z2xldG9uDQogICAgICAgIHN1YnRhZyAneCcgYXJlIGRlc2NyaWJlZCBiZWxvdy4NCg0KICAgMy4g ICBBbiBleHRlbnNpb24gTVVTVCBmb2xsb3cgYXQgbGVhc3QgYSBwcmltYXJ5IGxhbmd1YWdlIHN1 YnRhZy4NCiAgICAgICAgVGhhdCBpcywgYSBsYW5ndWFnZSB0YWcgY2Fubm90IGJlZ2luIHdpdGgg YW4gZXh0ZW5zaW9uLg0KICAgICAgICBFeHRlbnNpb25zIGV4dGVuZCBsYW5ndWFnZSB0YWdzLCB0 aGV5IGRvIG5vdCBvdmVycmlkZSBvciByZXBsYWNlDQogICAgICAgIHRoZW0uICBGb3IgZXhhbXBs ZSwgImEtdmFsdWUiIGlzIG5vdCBhIHdlbGwtZm9ybWVkIGxhbmd1YWdlIHRhZywNCiAgICAgICAg d2hpbGUgImRlLWEtdmFsdWUiIGlzLg0KDQogICA0LiAgIEVhY2ggc2luZ2xldG9uIHN1YnRhZyBN VVNUIGFwcGVhciBhdCBtb3N0IG9uZSB0aW1lIGluIGVhY2ggdGFnDQogICAgICAgIChvdGhlciB0 aGFuIGFzIGEgcHJpdmF0ZSB1c2Ugc3VidGFnKS4gIFRoYXQgaXMsIHNpbmdsZXRvbg0KICAgICAg ICBzdWJ0YWdzIE1VU1QgTk9UIGJlIHJlcGVhdGVkLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImVu LWEtYmJiLWEtDQogICAgICAgIGNjYyIgaXMgaW52YWxpZCBiZWNhdXNlIHRoZSBzdWJ0YWcgJ2En IGFwcGVhcnMgdHdpY2UuICBOb3RlIHRoYXQNCiAgICAgICAgdGhlIHRhZyAiZW4tYS1iYmIteC1h LWNjYyIgaXMgdmFsaWQgYmVjYXVzZSB0aGUgc2Vjb25kDQogICAgICAgIGFwcGVhcmFuY2Ugb2Yg dGhlIHNpbmdsZXRvbiAnYScgaXMgaW4gYSBwcml2YXRlIHVzZSBzZXF1ZW5jZS4NCg0KICAgNS4g ICBFeHRlbnNpb24gc3VidGFncyBNVVNUIG1lZXQgYWxsIG9mIHRoZSByZXF1aXJlbWVudHMgZm9y IHRoZQ0KICAgICAgICBjb250ZW50IGFuZCBmb3JtYXQgb2Ygc3VidGFncyBkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnQuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0K DQoNCiAgIDYuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IHdoYXRldmVyIHJlcXVpcmVt ZW50cyBhcmUgc2V0IGJ5IHRoZQ0KICAgICAgICBkb2N1bWVudCB0aGF0IGRlZmluZXMgdGhlaXIg c2luZ2xldG9uIHByZWZpeCBhbmQgd2hhdGV2ZXINCiAgICAgICAgcmVxdWlyZW1lbnRzIGFyZSBw cm92aWRlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5Lg0KDQogICA3LiAgIEVhY2ggZXh0 ZW5zaW9uIHN1YnRhZyBNVVNUIGJlIGZyb20gdHdvIHRvIGVpZ2h0IGNoYXJhY3RlcnMgbG9uZw0K ICAgICAgICBhbmQgY29uc2lzdCBzb2xlbHkgb2YgbGV0dGVycyBvciBkaWdpdHMsIHdpdGggZWFj aCBzdWJ0YWcNCiAgICAgICAgc2VwYXJhdGVkIGJ5IGEgc2luZ2xlICctJy4NCg0KICAgOC4gICBF YWNoIHNpbmdsZXRvbiBNVVNUIGJlIGZvbGxvd2VkIGJ5IGF0IGxlYXN0IG9uZSBleHRlbnNpb24N CiAgICAgICAgc3VidGFnLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgInRsaC1hLWItZm9vIiBpcyBp bnZhbGlkIGJlY2F1c2UNCiAgICAgICAgdGhlIGZpcnN0IHNpbmdsZXRvbiAnYScgaXMgZm9sbG93 ZWQgaW1tZWRpYXRlbHkgYnkgYW5vdGhlcg0KICAgICAgICBzaW5nbGV0b24gJ2InLg0KDQogICA5 LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1QgZm9sbG93IGFsbCBsYW5ndWFnZSwgZXh0ZW5kZWQg bGFuZ3VhZ2UsDQogICAgICAgIHNjcmlwdCwgcmVnaW9uIGFuZCB2YXJpYW50IHN1YnRhZ3MgaW4g YSB0YWcuDQoNCiAgIDEwLiAgQWxsIHN1YnRhZ3MgZm9sbG93aW5nIHRoZSBzaW5nbGV0b24gYW5k IGJlZm9yZSBhbm90aGVyIHNpbmdsZXRvbg0KICAgICAgICBhcmUgcGFydCBvZiB0aGUgZXh0ZW5z aW9uLiAgRXhhbXBsZTogSW4gdGhlIHRhZyAiZnItYS1MYXRuIiwgdGhlDQogICAgICAgIHN1YnRh ZyAnTGF0bicgZG9lcyBub3QgcmVwcmVzZW50IHRoZSBzY3JpcHQgc3VidGFnICdMYXRuJw0KICAg ICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4gIEl0cyBt ZWFuaW5nIGlzDQogICAgICAgIGRlZmluZWQgYnkgdGhlIGV4dGVuc2lvbiAnYScuDQoNCiAgIDEx LiAgSW4gdGhlIGV2ZW50IHRoYXQgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24gYXBwZWFycyBpbiBh IHNpbmdsZQ0KICAgICAgICB0YWcsIHRoZSB0YWcgU0hPVUxEIGJlIGNhbm9uaWNhbGl6ZWQgYXMg ZGVzY3JpYmVkIGluDQogICAgICAgIFNlY3Rpb24gNC40Lg0KDQogICBGb3IgZXhhbXBsZSwgaWYg dGhlIHByZWZpeCBzaW5nbGV0b24gJ3InIGFuZCB0aGUgc2hvd24gc3VidGFncyB3ZXJlDQogICBk ZWZpbmVkLCB0aGVuIHRoZSBmb2xsb3dpbmcgdGFnIHdvdWxkIGJlIGEgdmFsaWQgZXhhbXBsZTog ImVuLUxhdG4tDQogICBHQi1ib29udC1yLWV4dGVuZGVkLXNlcXVlbmNlLXgtcHJpdmF0ZSINCg0K Mi4yLjcgIFByaXZhdGUgVXNlIFN1YnRhZ3MNCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFncyBhcmUg dXNlZCB0byBpbmRpY2F0ZSBkaXN0aW5jdGlvbnMgaW4gbGFuZ3VhZ2UNCiAgIGltcG9ydGFudCBp biBhIGdpdmVuIGNvbnRleHQgYnkgcHJpdmF0ZSBhZ3JlZW1lbnQuICBUaGUgZm9sbG93aW5nDQog ICBydWxlcyBhcHBseSB0byBwcml2YXRlIHVzZSBzdWJ0YWdzOg0KDQogICAxLiAgUHJpdmF0ZSB1 c2Ugc3VidGFncyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0K ICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgdGhlIHJlc2VydmVkIHNpbmdsZS1jaGFyYWN0ZXIg c3VidGFnICd4Jy4NCg0KICAgMi4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgTVVTVCBjb25mb3JtIHRv IHRoZSBmb3JtYXQgYW5kIGNvbnRlbnQNCiAgICAgICBjb25zdHJhaW50cyBkZWZpbmVkIGluIHRo ZSBBQk5GIGZvciBhbGwgc3VidGFncy4NCg0KICAgMy4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgTVVT VCBmb2xsb3cgYWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwNCiAgICAgICBzY3JpcHQs IHJlZ2lvbiwgdmFyaWFudCwgYW5kIGV4dGVuc2lvbiBzdWJ0YWdzIGluIHRoZSB0YWcuDQogICAg ICAgQW5vdGhlciB3YXkgb2Ygc2F5aW5nIHRoaXMgaXMgdGhhdCBhbGwgc3VidGFncyBmb2xsb3dp bmcgdGhlDQogICAgICAgc2luZ2xldG9uICd4JyBNVVNUIGJlIGNvbnNpZGVyZWQgcHJpdmF0ZSB1 c2UuICBFeGFtcGxlOiBUaGUNCiAgICAgICBzdWJ0YWcgJ1VTJyBpbiB0aGUgdGFnICJlbi14LVVT IiBpcyBhIHByaXZhdGUgdXNlIHN1YnRhZy4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgQXVndXN0IDIwMDUNCg0KDQogICA0LiAgQSB0YWcgTUFZIGNvbnNpc3QgZW50aXJlbHkgb2Yg cHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0KICAgNS4gIE5vIHNvdXJjZSBpcyBkZWZpbmVkIGZvciBw cml2YXRlIHVzZSBzdWJ0YWdzLiAgVXNlIG9mIHByaXZhdGUgdXNlDQogICAgICAgc3VidGFncyBp cyBieSBwcml2YXRlIGFncmVlbWVudCBvbmx5Lg0KDQogICA2LiAgUHJpdmF0ZSB1c2Ugc3VidGFn cyBhcmUgTk9UIFJFQ09NTUVOREVEIHdoZXJlIGFsdGVybmF0aXZlcyBleGlzdA0KICAgICAgIG9y IGZvciBnZW5lcmFsIGludGVyY2hhbmdlLiAgU2VlIFNlY3Rpb24gNC41IGZvciBtb3JlIGluZm9y bWF0aW9uDQogICAgICAgb24gcHJpdmF0ZSB1c2Ugc3VidGFnIGNob2ljZS4NCg0KICAgRm9yIGV4 YW1wbGU6IFVzZXJzIHdobyB3aXNoZWQgdG8gdXRpbGl6ZSBjb2RlcyBmcm9tIHRoZSBFdGhub2xv Z3VlDQogICBwdWJsaWNhdGlvbiBvZiBTSUwgSW50ZXJuYXRpb25hbCBmb3IgbGFuZ3VhZ2UgaWRl bnRpZmljYXRpb24gbWlnaHQNCiAgIGFncmVlIHRvIGV4Y2hhbmdlIHRhZ3Mgc3VjaCBhcyAiYXot QXJhYi14LUFaRS1kZXJiZW5kIi4gIFRoaXMgZXhhbXBsZQ0KICAgY29udGFpbnMgdHdvIHByaXZh dGUgdXNlIHN1YnRhZ3MuICBUaGUgZmlyc3QgaXMgJ0FaRScgYW5kIHRoZSBzZWNvbmQNCiAgIGlz ICdkZXJiZW5kJy4NCg0KMi4yLjggIFByZS1FeGlzdGluZyBSRkMgMzA2NiBSZWdpc3RyYXRpb25z DQoNCiAgIEV4aXN0aW5nIElBTkEtcmVnaXN0ZXJlZCBsYW5ndWFnZSB0YWdzIGZyb20gUkZDIDE3 NjYgYW5kL29yIFJGQyAzMDY2DQogICBtYWludGFpbiB0aGVpciB2YWxpZGl0eS4gIFRoZXNlIHRh Z3Mgd2lsbCBiZSBtYWludGFpbmVkIGluIHRoZQ0KICAgcmVnaXN0cnkgaW4gcmVjb3JkcyBvZiBl aXRoZXIgdGhlICJncmFuZGZhdGhlcmVkIiBvciAicmVkdW5kYW50Ig0KICAgdHlwZS4gIEZvciBt b3JlIGluZm9ybWF0aW9uIHNlZSBTZWN0aW9uIDMuNy4NCg0KICAgSXQgaXMgaW1wb3J0YW50IHRv IG5vdGUgdGhhdCBhbGwgbGFuZ3VhZ2UgdGFncyBmb3JtZWQgdW5kZXIgdGhlDQogICBndWlkZWxp bmVzIGluIHRoaXMgZG9jdW1lbnQgd2VyZSBlaXRoZXIgbGVnYWwsIHdlbGwtZm9ybWVkIHRhZ3Mg b3INCiAgIGNvdWxkIGhhdmUgYmVlbiByZWdpc3RlcmVkIHVuZGVyIFJGQyAzMDY2Lg0KDQoyLjIu OSAgQ2xhc3NlcyBvZiBDb25mb3JtYW5jZQ0KDQogICBJbXBsZW1lbnRhdGlvbnMgc29tZXRpbWVz IG5lZWQgdG8gZGVzY3JpYmUgdGhlaXIgY2FwYWJpbGl0aWVzIHdpdGgNCiAgIHJlZ2FyZCB0byB0 aGUgcnVsZXMgYW5kIHByYWN0aWNlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZXJl DQogICBhcmUgdHdvIGNsYXNzZXMgb2YgY29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbnMgZGVzY3Jp YmVkIGJ5IHRoaXMNCiAgIGRvY3VtZW50OiAid2VsbC1mb3JtZWQiIHByb2Nlc3NvcnMgYW5kICJ2 YWxpZGF0aW5nIiBwcm9jZXNzb3JzLg0KICAgQ2xhaW1zIG9mIGNvbmZvcm1hbmNlIFNIT1VMRCBl eHBsaWNpdGx5IHJlZmVyZW5jZSBvbmUgb2YgdGhlc2UNCiAgIGRlZmluaXRpb25zLg0KDQogICBB biBpbXBsZW1lbnRhdGlvbiB0aGF0IGNsYWltcyB0byBjaGVjayBmb3Igd2VsbC1mb3JtZWQgbGFu Z3VhZ2UgdGFncw0KICAgTVVTVDoNCg0KICAgbyAgQ2hlY2sgdGhhdCB0aGUgdGFnIGFuZCBhbGwg b2YgaXRzIHN1YnRhZ3MsIGluY2x1ZGluZyBleHRlbnNpb24gYW5kDQogICAgICBwcml2YXRlIHVz ZSBzdWJ0YWdzLCBjb25mb3JtIHRvIHRoZSBBQk5GIG9yIHRoYXQgdGhlIHRhZyBpcyBvbiB0aGUN CiAgICAgIGxpc3Qgb2YgZ3JhbmRmYXRoZXJlZCB0YWdzLg0KDQogICBvICBDaGVjayB0aGF0IHNp bmdsZXRvbiBzdWJ0YWdzIHRoYXQgaWRlbnRpZnkgZXh0ZW5zaW9ucyBkbyBub3QNCiAgICAgIHJl cGVhdC4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJlbi1hLXh4LWIteXktYS16eiIgaXMgbm90IHdl bGwtDQogICAgICBmb3JtZWQuDQoNCiAgIFdlbGwtZm9ybWVkIHByb2Nlc3NvcnMgYXJlIHN0cm9u Z2x5IGVuY291cmFnZWQgdG8gaW1wbGVtZW50IHRoZQ0KICAgY2Fub25pY2FsaXphdGlvbiBydWxl cyBjb250YWluZWQgaW4gU2VjdGlvbiA0LjQuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICBBdWd1c3QgMjAwNQ0KDQoNCiAgIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgY2xhaW1zIHRvIGJl IHZhbGlkYXRpbmcgTVVTVDoNCg0KICAgbyAgQ2hlY2sgdGhhdCB0aGUgdGFnIGlzIHdlbGwtZm9y bWVkLg0KDQogICBvICBTcGVjaWZ5IHRoZSBwYXJ0aWN1bGFyIHJlZ2lzdHJ5IGRhdGUgZm9yIHdo aWNoIHRoZSBpbXBsZW1lbnRhdGlvbg0KICAgICAgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBzdWJ0 YWdzLg0KDQogICBvICBDaGVjayB0aGF0IGVpdGhlciB0aGUgdGFnIGlzIGEgZ3JhbmRmYXRoZXJl ZCB0YWcsIG9yIHRoYXQgYWxsDQogICAgICBsYW5ndWFnZSwgc2NyaXB0LCByZWdpb24sIGFuZCB2 YXJpYW50IHN1YnRhZ3MgY29uc2lzdCBvZiB2YWxpZA0KICAgICAgY29kZXMgZm9yIHVzZSBpbiBs YW5ndWFnZSB0YWdzIGFjY29yZGluZyB0byB0aGUgSUFOQSByZWdpc3RyeSBhcw0KICAgICAgb2Yg dGhlIHBhcnRpY3VsYXIgZGF0ZSBzcGVjaWZpZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uLg0KDQog ICBvICBTcGVjaWZ5IHdoaWNoLCBpZiBhbnksIGV4dGVuc2lvbiBSRkNzIGFzIGRlZmluZWQgaW4g U2VjdGlvbiAzLjYNCiAgICAgIGFyZSBzdXBwb3J0ZWQsIGluY2x1ZGluZyB2ZXJzaW9uLCByZXZp c2lvbiwgYW5kIGRhdGUuDQoNCiAgIG8gIEZvciBhbnkgc3VjaCBleHRlbnNpb25zIHN1cHBvcnRl ZCwgY2hlY2sgdGhhdCBhbGwgc3VidGFncyB1c2VkIGluDQogICAgICB0aGF0IGV4dGVuc2lvbiBh cmUgdmFsaWQuDQoNCiAgIG8gIEZvciB2YXJpYW50IGFuZCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0 YWdzLCBpZiB0aGUgcmVnaXN0cnkNCiAgICAgIGNvbnRhaW5zIG9uZSBvciBtb3JlICdQcmVmaXgn IGZpZWxkcyBmb3IgdGhhdCBzdWJ0YWcsIGNoZWNrIHRoYXQNCiAgICAgIHRoZSB0YWcgbWF0Y2hl cyBhdCBsZWFzdCBvbmUgcHJlZml4LiAgVGhlIHRhZyBtYXRjaGVzIGlmIGFsbCB0aGUNCiAgICAg IHN1YnRhZ3MgaW4gdGhlICdQcmVmaXgnIGFsc28gYXBwZWFyIGluIHRoZSB0YWcuICBGb3IgZXhh bXBsZSwgdGhlDQogICAgICBwcmVmaXggImVzLUNPIiBtYXRjaGVzIHRoZSB0YWcgImVzLUxhdG4t Q08teC1wcml2YXRlIiBiZWNhdXNlIGJvdGgNCiAgICAgIHRoZSAnZXMnIGxhbmd1YWdlIHN1YnRh ZyBhbmQgJ0NPJyByZWdpb24gc3VidGFnIGFwcGVhciBpbiB0aGUgdGFnLg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTdd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQozLiAgUmVnaXN0cnkgRm9ybWF0IGFuZCBNYWludGVu YW5jZQ0KDQogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lz dHJ5IGFuZCB0aGUgbWFpbnRlbmFuY2UNCiAgIGFuZCB1cGRhdGUgcHJvY2VkdXJlcyBhc3NvY2lh dGVkIHdpdGggaXQsIGFzIHdlbGwgYXMgYSByZWdpc3RyeSBmb3INCiAgIGV4dGVuc2lvbnMgdG8g bGFuZ3VhZ2UgdGFncyAoU2VjdGlvbiAzLjYpLg0KDQogICBUaGUgTGFuZ3VhZ2UgU3VidGFnIFJl Z2lzdHJ5IGNvbnRhaW5zIGEgY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGFsbCBvZg0KICAgdGhlIHN1 YnRhZ3MgdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoaXMgYWxsb3dzIGltcGxlbWVudGVycyBh DQogICBzdHJhaWdodGZvcndhcmQgYW5kIHJlbGlhYmxlIHdheSB0byB2YWxpZGF0ZSBsYW5ndWFn ZSB0YWdzLiAgVGhlDQogICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgd2lsbCBiZSBtYWludGFp bmVkIHNvIHRoYXQsIGV4Y2VwdCBmb3INCiAgIGV4dGVuc2lvbiBzdWJ0YWdzLCBpdCBpcyBwb3Nz aWJsZSB0byB2YWxpZGF0ZSBhbGwgb2YgdGhlIHN1YnRhZ3MgdGhhdA0KICAgYXBwZWFyIGluIGEg bGFuZ3VhZ2UgdGFnIHVuZGVyIHRoZSBwcm92aXNpb25zIG9mIHRoaXMgZG9jdW1lbnQgb3IgaXRz DQogICByZXZpc2lvbnMgb3Igc3VjY2Vzc29ycy4gIEluIGFkZGl0aW9uLCB0aGUgbWVhbmluZyBv ZiB0aGUgdmFyaW91cw0KICAgc3VidGFncyB3aWxsIGJlIHVuYW1iaWd1b3VzIGFuZCBzdGFibGUg b3ZlciB0aW1lLiAgKFRoZSBtZWFuaW5nIG9mDQogICBwcml2YXRlIHVzZSBzdWJ0YWdzLCBvZiBj b3Vyc2UsIGlzIG5vdCBkZWZpbmVkIGJ5IHRoZSBJQU5BIHJlZ2lzdHJ5LikNCg0KMy4xICBGb3Jt YXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5DQoNCiAgIFRoZSBJQU5BIExh bmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAoInRoZSByZWdpc3RyeSIpIGNvbnNpc3RzIG9mIGEgdGV4 dA0KICAgZmlsZSB0aGF0IGlzIG1hY2hpbmUgcmVhZGFibGUgaW4gdGhlIGZvcm1hdCBkZXNjcmli ZWQgaW4gdGhpcw0KICAgc2VjdGlvbiwgcGx1cyBjb3BpZXMgb2YgdGhlIHJlZ2lzdHJhdGlvbiBm b3JtcyBhcHByb3ZlZCBieSB0aGUNCiAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBpbiBhY2Nv cmRhbmNlIHdpdGggdGhlIHByb2Nlc3MgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDMuNC4gIFdp dGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUgcmVnaXN0cmF0aW9uIGZvcm1zIGZvcg0KICAgZ3JhbmRm YXRoZXJlZCBhbmQgcmVkdW5kYW50IHRhZ3MsIG5vIHJlZ2lzdHJhdGlvbiByZWNvcmRzIHdpbGwg YmUNCiAgIG1haW50YWluZWQgZm9yIHRoZSBpbml0aWFsIHNldCBvZiBzdWJ0YWdzLg0KDQogICBU aGUgcmVnaXN0cnkgaXMgaW4gYSBtb2RpZmllZCByZWNvcmQtamFyIGZvcm1hdCB0ZXh0IGZpbGUg W3JlY29yZC0NCiAgIGphcl0uICBMaW5lcyBhcmUgbGltaXRlZCB0byA3MiBjaGFyYWN0ZXJzLCBp bmNsdWRpbmcgYWxsIHdoaXRlc3BhY2UuDQoNCiAgIFJlY29yZHMgYXJlIHNlcGFyYXRlZCBieSBs aW5lcyBjb250YWluaW5nIG9ubHkgdGhlIHNlcXVlbmNlICIlJSINCiAgICgleDI1LjI1KS4NCg0K ICAgRWFjaCBmaWVsZCBjYW4gYmUgdmlld2VkIGFzIGEgc2luZ2xlLCBsb2dpY2FsIGxpbmUgb2Yg QVNDSUkNCiAgIGNoYXJhY3RlcnMsICBjb21wcmlzaW5nIGEgZmllbGQtbmFtZSBhbmQgYSBmaWVs ZC1ib2R5IHNlcGFyYXRlZCBieSBhDQogICBDT0xPTiBjaGFyYWN0ZXIgKCV4M0EpLiAgRm9yIGNv bnZlbmllbmNlLCB0aGUgZmllbGQtYm9keSBwb3J0aW9uIG9mDQogICB0aGlzIGNvbmNlcHR1YWwg ZW50aXR5IGNhbiBiZSBzcGxpdCBpbnRvIGEgbXVsdGlwbGUtbGluZQ0KICAgcmVwcmVzZW50YXRp b247IHRoaXMgaXMgY2FsbGVkICJmb2xkaW5nIi4gIFRoZSBmb3JtYXQgb2YgdGhlIHJlZ2lzdHJ5 DQogICBpcyBkZXNjcmliZWQgYnkgdGhlIGZvbGxvd2luZyBBQk5GIChwZXIgW1JGQzIyMzRiaXNd KToNCg0KICAgcmVnaXN0cnkgICA9IHJlY29yZCAqKCIlJSIgQ1JMRiByZWNvcmQpDQogICByZWNv cmQgICAgID0gMSooIGZpZWxkLW5hbWUgKlNQICI6IiAqU1AgZmllbGQtYm9keSBDUkxGICkNCiAg IGZpZWxkLW5hbWUgPSAoQUxQSEEgLyBESUdJVClbKihBTFBIQSAvIERJR0lUIC8gIi0iKSAoQUxQ SEEgLyBESUdJVCldDQogICBmaWVsZC1ib2R5ID0gKihBU0NDSEFSL0xXU1ApDQogICBBU0NDSEFS ICAgID0gJXgyMS0yNSAvICV4MjctN0UgLyBVTklDSEFSIDsgTm90ZTogQU1QRVJTQU5EIGlzICV4 MjYNCiAgIFVOSUNIQVIgICAgPSAiJiN4IiAyKjZIRVhESUcgIjsiDQoNCiAgIFRoZSBzZXF1ZW5j ZSAnLi4nICgleDJFLjJFKSBpbiBhIGZpZWxkLWJvZHkgZGVub3RlcyBhIHJhbmdlIG9mDQogICB2 YWx1ZXMuICBTdWNoIGEgcmFuZ2UgcmVwcmVzZW50cyBhbGwgc3VidGFncyBvZiB0aGUgc2FtZSBs ZW5ndGggdGhhdA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0K DQogICBhcmUgYWxwaGFiZXRpY2FsbHkgd2l0aGluIHRoYXQgcmFuZ2UsIGluY2x1ZGluZyB0aGUg dmFsdWVzIGV4cGxpY2l0bHkNCiAgIG1lbnRpb25lZC4gIEZvciBleGFtcGxlICdhLi5jJyBkZW5v dGVzIHRoZSB2YWx1ZXMgJ2EnLCAnYicsIGFuZCAnYycuDQoNCiAgIENoYXJhY3RlcnMgZnJvbSBv dXRzaWRlIHRoZSBVUy1BU0NJSVtJU082NDZdIHJlcGVydG9pcmUsIGFzIHdlbGwgYXMNCiAgIHRo ZSBBTVBFUlNBTkQgY2hhcmFjdGVyICgiJiIsICV4MjYpIHdoZW4gaXQgb2NjdXJzIGluIGEgZmll bGQtYm9keQ0KICAgYXJlIHJlcHJlc2VudGVkIGJ5IGEgIk51bWVyaWMgQ2hhcmFjdGVyIFJlZmVy ZW5jZSIgdXNpbmcgaGV4YWRlY2ltYWwNCiAgIG5vdGF0aW9uIGluIHRoZSBzdHlsZSB1c2VkIGJ5 IFtYTUwxMF0gKHNlZQ0KICAgPGh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy14bWwvI2R0LWNoYXJy ZWY+KS4gIFRoaXMgY29uc2lzdHMgb2YgdGhlDQogICBzZXF1ZW5jZSAiJiN4IiAoJXgyNi4yMy43 OCkgZm9sbG93ZWQgYnkgYSBoZXhhZGVjaW1hbCByZXByZXNlbnRhdGlvbg0KICAgb2YgdGhlIGNo YXJhY3RlcidzIGNvZGUgcG9pbnQgaW4gW0lTTzEwNjQ2XSBmb2xsb3dlZCBieSBhIGNsb3NpbmcN CiAgIHNlbWljb2xvbiAoJXgzQikuICBGb3IgZXhhbXBsZSwgdGhlIEVVUk8gU0lHTiwgVSsyMEFD LCB3b3VsZCBiZQ0KICAgcmVwcmVzZW50ZWQgYnkgdGhlIHNlcXVlbmNlICImI3gyMEFDOyIuICBO b3RlIHRoYXQgdGhlIGhleGFkZWNpbWFsDQogICBub3RhdGlvbiBNQVkgaGF2ZSBiZXR3ZWVuIHR3 byBhbmQgc2l4IGRpZ2l0cy4NCg0KICAgQWxsIGZpZWxkcyB3aG9zZSBmaWVsZC1ib2R5IGNvbnRh aW5zIGEgZGF0ZSB2YWx1ZSB1c2UgdGhlICJmdWxsLWRhdGUiDQogICBmb3JtYXQgc3BlY2lmaWVk IGluIFtSRkMzMzM5XS4gIEZvciBleGFtcGxlOiAiMjAwNC0wNi0yOCIgcmVwcmVzZW50cw0KICAg SnVuZSAyOCwgMjAwNCBpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLg0KDQogICBUaGUgZmlyc3Qg cmVjb3JkIGluIHRoZSBmaWxlIGNvbnRhaW5zIHRoZSBzaW5nbGUgZmllbGQgd2hvc2UgZmllbGQt DQogICBuYW1lIGlzICJGaWxlLURhdGUiLiAgVGhlIGZpZWxkLWJvZHkgb2YgdGhpcyByZWNvcmQg Y29udGFpbnMgdGhlIGxhc3QNCiAgIG1vZGlmaWNhdGlvbiBkYXRlIG9mIHRoaXMgY29weSBvZiB0 aGUgcmVnaXN0cnksIG1ha2luZyBpdCBwb3NzaWJsZSB0bw0KICAgY29tcGFyZSBkaWZmZXJlbnQg dmVyc2lvbnMgb2YgdGhlIHJlZ2lzdHJ5LiAgVGhlIHJlZ2lzdHJ5IG9uIHRoZSBJQU5BDQogICB3 ZWJzaXRlIGlzIHRoZSBtb3N0IGN1cnJlbnQuICBWZXJzaW9ucyB3aXRoIGFuIG9sZGVyIGRhdGUg dGhhbiB0aGF0DQogICBvbmUgYXJlIG5vdCB1cC10by1kYXRlLg0KDQogICBGaWxlLURhdGU6IDIw MDQtMDYtMjgNCiAgICUlDQoNCiAgIFN1YnNlcXVlbnQgcmVjb3JkcyByZXByZXNlbnQgc3VidGFn cyBpbiB0aGUgcmVnaXN0cnkuICBFYWNoIG9mIHRoZQ0KICAgZmllbGRzIGluIGVhY2ggcmVjb3Jk IE1VU1Qgb2NjdXIgbm8gbW9yZSB0aGFuIG9uY2UsIHVubGVzcyBvdGhlcndpc2UNCiAgIG5vdGVk IGJlbG93LiAgRWFjaCByZWNvcmQgTVVTVCBjb250YWluIHRoZSBmb2xsb3dpbmcgZmllbGRzOg0K DQogICBvICAnVHlwZScNCg0KICAgICAgKiAgVHlwZSdzIGZpZWxkLXZhbHVlIE1VU1QgY29uc2lz dCBvZiBvbmUgb2YgdGhlIGZvbGxvd2luZw0KICAgICAgICAgc3RyaW5nczogImxhbmd1YWdlIiwg ImV4dGxhbmciLCAic2NyaXB0IiwgInJlZ2lvbiIsICJ2YXJpYW50IiwNCiAgICAgICAgICJncmFu ZGZhdGhlcmVkIiwgYW5kICJyZWR1bmRhbnQiIGFuZCBkZW5vdGVzIHRoZSB0eXBlIG9mIHRhZyBv cg0KICAgICAgICAgc3VidGFnLg0KDQogICBvICBFaXRoZXIgJ1N1YnRhZycgb3IgJ1RhZycNCg0K ICAgICAgKiAgU3VidGFnJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgdGhlIHN1YnRhZyBiZWluZyBk ZWZpbmVkLiAgVGhpcw0KICAgICAgICAgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRz IG9mIHdob3NlICdUeXBlJyBoYXMgb25lIG9mDQogICAgICAgICB0aGVzZSB2YWx1ZXM6ICJsYW5n dWFnZSIsICJleHRsYW5nIiwgInNjcmlwdCIsICJyZWdpb24iLCBvcg0KICAgICAgICAgInZhcmlh bnQiLg0KDQogICAgICAqICBUYWcncyBmaWVsZC12YWx1ZSBjb250YWlucyBhIGNvbXBsZXRlIGxh bmd1YWdlIHRhZy4gIFRoaXMgZmllbGQNCiAgICAgICAgIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVj b3JkcyB3aG9zZSAnVHlwZScgaGFzIG9uZSBvZiB0aGVzZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTld DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAgICB2YWx1ZXM6ICJncmFuZGZhdGhlcmVk IiBvciAicmVkdW5kYW50Ii4NCg0KICAgbyAgRGVzY3JpcHRpb24NCg0KICAgICAgKiAgRGVzY3Jp cHRpb24ncyBmaWVsZC12YWx1ZSBjb250YWlucyBhIG5vbi1ub3JtYXRpdmUgZGVzY3JpcHRpb24N CiAgICAgICAgIG9mIHRoZSBzdWJ0YWcgb3IgdGFnLg0KDQogICBvICBBZGRlZA0KDQogICAgICAq ICBBZGRlZCdzIGZpZWxkLXZhbHVlIGNvbnRhaW5zIHRoZSBkYXRlIHRoZSByZWNvcmQgd2FzIGFk ZGVkIHRvDQogICAgICAgICB0aGUgcmVnaXN0cnkuDQoNCiAgIFRoZSAnU3VidGFnJyBvciAnVGFn JyBmaWVsZCBNVVNUIHVzZSBsb3dlcmNhc2UgbGV0dGVycyB0byBmb3JtIHRoZQ0KICAgc3VidGFn IG9yIHRhZywgd2l0aCB0d28gZXhjZXB0aW9ucy4gIFN1YnRhZ3Mgd2hvc2UgJ1R5cGUnIGZpZWxk IGlzDQogICAnc2NyaXB0JyAoaW4gb3RoZXIgd29yZHMsIHN1YnRhZ3MgZGVmaW5lZCBieSBJU08g MTU5MjQpIE1VU1QgdXNlDQogICB0aXRsZWNhc2UuICBTdWJ0YWdzIHdob3NlICdUeXBlJyBmaWVs ZCBpcyAncmVnaW9uJyAoaW4gb3RoZXIgd29yZHMsDQogICBzdWJ0YWdzIGRlZmluZWQgYnkgSVNP IDMxNjYpIE1VU1QgdXNlIHVwcGVyY2FzZS4gIFRoZXNlIGV4Y2VwdGlvbnMNCiAgIG1pcnJvciB0 aGUgdXNlIG9mIGNhc2UgaW4gdGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzLg0KDQogICBUaGUgZmll bGQgJ0Rlc2NyaXB0aW9uJyBNQVkgYXBwZWFyIG1vcmUgdGhhbiBvbmUgdGltZS4gIEF0IGxlYXN0 IG9uZQ0KICAgb2YgdGhlICAnRGVzY3JpcHRpb24nIGZpZWxkcyBNVVNUIGNvbnRhaW4gYSBkZXNj cmlwdGlvbiBvZiB0aGUgdGFnDQogICBiZWluZyByZWdpc3RlcmVkIHdyaXR0ZW4gb3IgdHJhbnNj cmliZWQgaW50byB0aGUgTGF0aW4gc2NyaXB0OyB0aGUNCiAgIHNhbWUgb3IgYWRkaXRpb25hbCBm aWVsZHMgTUFZIGFsc28gaW5jbHVkZSBhIGRlc2NyaXB0aW9uIGluIGEgbm9uLQ0KICAgTGF0aW4g c2NyaXB0LiAgVGhlICdEZXNjcmlwdGlvbicgZmllbGQgaXMgdXNlZCBmb3IgaWRlbnRpZmljYXRp b24NCiAgIHB1cnBvc2VzIGFuZCBTSE9VTEQgTk9UIGJlIHRha2VuIHRvIHJlcHJlc2VudCB0aGUg YWN0dWFsIG5hdGl2ZSBuYW1lDQogICBvZiB0aGUgbGFuZ3VhZ2Ugb3IgdmFyaWF0aW9uIG9yIHRv IGJlIGluIGFueSBwYXJ0aWN1bGFyIGxhbmd1YWdlLg0KICAgTW9zdCBkZXNjcmlwdGlvbnMgYXJl IHRha2VuIGRpcmVjdGx5IGZyb20gc291cmNlIHN0YW5kYXJkcyBzdWNoIGFzDQogICBJU08gNjM5 IG9yIElTTyAzMTY2Lg0KDQogICBOb3RlOiBEZXNjcmlwdGlvbnMgaW4gcmVnaXN0cnkgZW50cmll cyB0aGF0IGNvcnJlc3BvbmQgdG8gSVNPIDYzOSwNCiAgIElTTyAxNTkyNCwgIElTTyAzMTY2IG9y IFVOIE0uNDkgY29kZXMgYXJlIGludGVuZGVkIG9ubHkgdG8gaW5kaWNhdGUNCiAgIHRoZSBtZWFu aW5nIG9mIHRoYXQgaWRlbnRpZmllciBhcyBkZWZpbmVkIGluIHRoZSBzb3VyY2Ugc3RhbmRhcmQg YXQNCiAgIHRoZSB0aW1lIGl0IHdhcyBhZGRlZCB0byB0aGUgcmVnaXN0cnkuICBUaGUgZGVzY3Jp cHRpb24gZG9lcyBub3QNCiAgIHJlcGxhY2UgdGhlIGNvbnRlbnQgb2YgdGhlIHNvdXJjZSBzdGFu ZGFyZCBpdHNlbGYuICBUaGUgZGVzY3JpcHRpb25zDQogICBhcmUgbm90IGludGVuZGVkIHRvIGJl IHRoZSBFbmdsaXNoIGxvY2FsaXplZCBuYW1lcyBmb3IgdGhlIHN1YnRhZ3MuDQogICBMb2NhbGl6 YXRpb24gb3IgdHJhbnNsYXRpb24gb2YgbGFuZ3VhZ2UgdGFnIGFuZCBzdWJ0YWcgZGVzY3JpcHRp b25zDQogICBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgRWFjaCByZWNv cmQgTUFZIGFsc28gY29udGFpbiB0aGUgZm9sbG93aW5nIGZpZWxkczoNCg0KICAgbyAgUHJlZmVy cmVkLVZhbHVlDQoNCiAgICAgICogIEZvciBmaWVsZHMgb2YgdHlwZSAnbGFuZ3VhZ2UnLCAnZXh0 bGFuZycsICdzY3JpcHQnLCAncmVnaW9uJywNCiAgICAgICAgIGFuZCAndmFyaWFudCcsICdQcmVm ZXJyZWQtVmFsdWUnIGNvbnRhaW5zIGEgc3VidGFnIG9mIHRoZSBzYW1lDQogICAgICAgICAnVHlw ZScgd2hpY2ggaXMgcHJlZmVycmVkIGZvciBmb3JtaW5nIHRoZSBsYW5ndWFnZSB0YWcuDQoNCiAg ICAgICogIEZvciBmaWVsZHMgb2YgdHlwZSAnZ3JhbmRmYXRoZXJlZCcgYW5kICdyZWR1bmRhbnQn LCBhIGNhbm9uaWNhbA0KICAgICAgICAgbWFwcGluZyB0byBhIGNvbXBsZXRlIGxhbmd1YWdlIHRh Zy4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIw MDYgICAgICAgICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgbyAg RGVwcmVjYXRlZA0KDQogICAgICAqICBEZXByZWNhdGVkJ3MgZmllbGQtdmFsdWUgY29udGFpbnMg dGhlIGRhdGUgdGhlIHJlY29yZCB3YXMNCiAgICAgICAgIGRlcHJlY2F0ZWQuDQoNCiAgIG8gIFBy ZWZpeA0KDQogICAgICAqICBQcmVmaXgncyBmaWVsZC12YWx1ZSBjb250YWlucyBhIGxhbmd1YWdl IHRhZyB3aXRoIHdoaWNoIHRoaXMNCiAgICAgICAgIHN1YnRhZyBNQVkgYmUgdXNlZCB0byBmb3Jt IGEgbmV3IGxhbmd1YWdlIHRhZywgcGVyaGFwcyB3aXRoDQogICAgICAgICBvdGhlciBzdWJ0YWdz IGFzIHdlbGwuICBUaGlzIGZpZWxkIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3Jkcw0KICAgICAg ICAgd2hvc2UgJ1R5cGUnIGZpZWxkLXZhbHVlIGlzICd2YXJpYW50JyBvciAnZXh0bGFuZycuICBG b3INCiAgICAgICAgIGV4YW1wbGUsIHRoZSAnUHJlZml4JyBmb3IgdGhlIHZhcmlhbnQgJ25lZGlz JyBpcyAnc2wnLCBtZWFuaW5nDQogICAgICAgICB0aGF0IHRoZSB0YWdzICJzbC1uZWRpcyIgYW5k ICJzbC1JVC1uZWRpcyIgbWlnaHQgYmUgYXBwcm9wcmlhdGUNCiAgICAgICAgIHdoaWxlIHRoZSB0 YWcgImlzLW5lZGlzIiBpcyBub3QuDQoNCiAgIG8gIENvbW1lbnRzDQoNCiAgICAgICogIENvbW1l bnRzIGNvbnRhaW5zIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHN1YnRhZywgYXMN CiAgICAgICAgIGRlZW1lZCBhcHByb3ByaWF0ZSBmb3IgdW5kZXJzdGFuZGluZyB0aGUgcmVnaXN0 cnkgYW5kDQogICAgICAgICBpbXBsZW1lbnRpbmcgbGFuZ3VhZ2UgdGFncyB1c2luZyB0aGUgc3Vi dGFnIG9yIHRhZy4NCg0KICAgbyAgU3VwcHJlc3MtU2NyaXB0DQoNCiAgICAgICogIFN1cHByZXNz LVNjcmlwdCBjb250YWlucyBhIHNjcmlwdCBzdWJ0YWcgdGhhdCBTSE9VTEQgTk9UIGJlDQogICAg ICAgICB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB3aXRoIHRoZSBhc3NvY2lhdGVkIHByaW1h cnkgbGFuZ3VhZ2UNCiAgICAgICAgIHN1YnRhZy4gIFRoaXMgZmllbGQgTVVTVCBvbmx5IGFwcGVh ciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgICAgICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1 YWdlJy4gIFNlZSBTZWN0aW9uIDQuMS4NCg0KICAgVGhlIGZpZWxkICdEZXByZWNhdGVkJyBNQVkg YmUgYWRkZWQgdG8gYW55IHJlY29yZCB2aWEgdGhlIG1haW50ZW5hbmNlDQogICBwcm9jZXNzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuMiBvciB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzDQog ICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQuICBVc3VhbGx5IHRoZSBhZGRpdGlvbiBvZiBhICdE ZXByZWNhdGVkJw0KICAgZmllbGQgaXMgZHVlIHRvIHRoZSBhY3Rpb24gb2Ygb25lIG9mIHRoZSBz dGFuZGFyZHMgYm9kaWVzLCBzdWNoIGFzDQogICBJU08gMzE2Niwgd2l0aGRyYXdpbmcgYSBjb2Rl LiAgSW4gc29tZSBoaXN0b3JpY2FsIGNhc2VzIGl0IG1pZ2h0IG5vdA0KICAgaGF2ZSBiZWVuIHBv c3NpYmxlIHRvIHJlY29uc3RydWN0IHRoZSBvcmlnaW5hbCBkZXByZWNhdGlvbiBkYXRlLiAgRm9y DQogICB0aGVzZSBjYXNlcywgYW4gYXBwcm94aW1hdGUgZGF0ZSBhcHBlYXJzIGluIHRoZSByZWdp c3RyeS4gIEFsdGhvdWdoDQogICB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLCBzdWJ0YWdzIGFuZCB0 YWdzIHdpdGggYSAnRGVwcmVjYXRlZCcgZmllbGQNCiAgIGFyZSBkZXByZWNhdGVkIGFuZCB2YWxp ZGF0aW5nIHByb2Nlc3NvcnMgU0hPVUxEIE5PVCBnZW5lcmF0ZSB0aGVzZQ0KICAgc3VidGFncy4g IE5vdGUgdGhhdCBhIHJlY29yZCB0aGF0IGNvbnRhaW5zIGEgJ0RlcHJlY2F0ZWQnIGZpZWxkIGFu ZA0KICAgbm8gY29ycmVzcG9uZGluZyAnUHJlZmVycmVkLVZhbHVlJyBmaWVsZCBoYXMgbm8gcmVw bGFjZW1lbnQgbWFwcGluZy4NCg0KICAgVGhlIGZpZWxkICdQcmVmZXJyZWQtVmFsdWUnIGNvbnRh aW5zIGEgbWFwcGluZyBiZXR3ZWVuIHRoZSByZWNvcmQgaW4NCiAgIHdoaWNoIGl0IGFwcGVhcnMg YW5kIGEgdGFnIG9yIHN1YnRhZyB3aGljaCBTSE9VTEQgYmUgcHJlZmVycmVkIHdoZW4NCiAgIHNl bGVjdGVkIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSB2YWx1ZXMgZm9ybSB0aHJlZSBncm91cHM6DQoN CiAgICAgIElTTyA2MzkgbGFuZ3VhZ2UgY29kZXMgd2hpY2ggd2VyZSBsYXRlciB3aXRoZHJhd24g aW4gZmF2b3Igb2YNCiAgICAgIG90aGVyIGNvZGVzLiAgVGhlc2UgdmFsdWVzIGFyZSBtb3N0bHkg YSBoaXN0b3JpY2FsIGN1cmlvc2l0eS4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyMV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICBBdWd1c3QgMjAwNQ0KDQoNCiAgICAgIElTTyAzMTY2IHJlZ2lvbiBjb2RlcyB3aGljaCBoYXZl IGJlZW4gd2l0aGRyYXduIGluIGZhdm9yIG9mIGEgbmV3DQogICAgICBjb2RlLiAgVGhpcyBzb21l dGltZXMgaGFwcGVucyB3aGVuIGEgY291bnRyeSBjaGFuZ2VzIGl0cyBuYW1lIG9yDQogICAgICBh ZG1pbmlzdHJhdGlvbiBpbiBzdWNoIGEgd2F5IHRoYXQgd2FycmFudHMgYSBuZXcgcmVnaW9uIGNv ZGUuDQoNCiAgICAgIFRhZ3MgZ3JhbmRmYXRoZXJlZCBmcm9tIFJGQyAzMDY2LiAgSW4gbWFueSBj YXNlcyB0aGVzZSB0YWdzIGhhdmUNCiAgICAgIGJlY29tZSBvYnNvbGV0ZSBiZWNhdXNlIHRoZSB2 YWx1ZXMgdGhleSByZXByZXNlbnQgd2VyZSBsYXRlcg0KICAgICAgZW5jb2RlZCBieSBJU08gNjM5 Lg0KDQogICBSZWNvcmRzIHRoYXQgY29udGFpbiBhICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIE1V U1QgYWxzbyBoYXZlIGENCiAgICdEZXByZWNhdGVkJyBmaWVsZC4gIFRoaXMgZmllbGQgY29udGFp bnMgYSBkYXRlIG9mIGRlcHJlY2F0aW9uLiAgVGh1cw0KICAgYSBsYW5ndWFnZSB0YWcgcHJvY2Vz c29yIGNhbiB1c2UgdGhlIHJlZ2lzdHJ5IHRvIGNvbnN0cnVjdCB0aGUgdmFsaWQsDQogICBub24t ZGVwcmVjYXRlZCBzZXQgb2Ygc3VidGFncyBmb3IgYSBnaXZlbiBkYXRlLiAgSW4gYWRkaXRpb24s IGZvciBhbnkNCiAgIGdpdmVuIHRhZywgYSBwcm9jZXNzb3IgY2FuIGNvbnN0cnVjdCB0aGUgc2V0 IG9mIHZhbGlkIGxhbmd1YWdlIHRhZ3MNCiAgIHRoYXQgY29ycmVzcG9uZCB0byB0aGF0IHRhZyBm b3IgYWxsIGRhdGVzIHVwIHRvIHRoZSBkYXRlIG9mIHRoZQ0KICAgcmVnaXN0cnkuICBUaGUgYWJp bGl0eSB0byBkbyB0aGVzZSBtYXBwaW5ncyBNQVkgYmUgYmVuZWZpY2lhbCB0bw0KICAgYXBwbGlj YXRpb25zIHRoYXQgYXJlIG1hdGNoaW5nLCBzZWxlY3RpbmcsIGZvciBmaWx0ZXJpbmcgY29udGVu dA0KICAgYmFzZWQgb24gaXRzIGxhbmd1YWdlIHRhZ3MuDQoNCiAgIE5vdGUgdGhhdCAnUHJlZmVy cmVkLVZhbHVlJyBtYXBwaW5ncyBpbiByZWNvcmRzIG9mIHR5cGUgJ3JlZ2lvbicNCiAgIHNvbWV0 aW1lcyBkbyBub3QgcmVwcmVzZW50IGV4YWN0bHkgdGhlIHNhbWUgbWVhbmluZyBhcyB0aGUgb3Jp Z2luYWwNCiAgIHZhbHVlLiAgVGhlcmUgYXJlIG1hbnkgcmVhc29ucyBmb3IgYSBjb3VudHJ5IGNv ZGUgdG8gYmUgY2hhbmdlZCBhbmQNCiAgIHRoZSBlZmZlY3QgdGhpcyBoYXMgb24gdGhlIGZvcm1h dGlvbiBvZiBsYW5ndWFnZSB0YWdzIHdpbGwgZGVwZW5kIG9uDQogICB0aGUgbmF0dXJlIG9mIHRo ZSBjaGFuZ2UgaW4gcXVlc3Rpb24uDQoNCiAgIEluIHBhcnRpY3VsYXIsIHRoZSAnUHJlZmVycmVk LVZhbHVlJyBmaWVsZCBkb2VzIG5vdCBpbXBseSByZXRhZ2dpbmcNCiAgIGNvbnRlbnQgdGhhdCB1 c2VzIHRoZSBhZmZlY3RlZCBzdWJ0YWcuDQoNCiAgIFRoZSBmaWVsZCAnUHJlZmVycmVkLVZhbHVl JyBNVVNUIE5PVCBiZSBtb2RpZmllZCBvbmNlIGNyZWF0ZWQgaW4gdGhlDQogICByZWdpc3RyeS4g IFRoZSBmaWVsZCBNQVkgYmUgYWRkZWQgdG8gcmVjb3JkcyBvZiB0eXBlICJncmFuZGZhdGhlcmVk Ig0KICAgYW5kICJyZWdpb24iIGFjY29yZGluZyB0byB0aGUgcnVsZXMgaW4gU2VjdGlvbiAzLjIu ICBPdGhlcndpc2UgdGhlDQogICBmaWVsZCBNVVNUIE5PVCBiZSBhZGRlZCB0byBhbnkgcmVjb3Jk IGFscmVhZHkgaW4gdGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgJ1ByZWZlcnJlZC1WYWx1ZScgZmll bGQgaW4gcmVjb3JkcyBvZiB0eXBlICJncmFuZGZhdGhlcmVkIiBhbmQNCiAgICJyZWR1bmRhbnQi IGNvbnRhaW5zIHdob2xlIGxhbmd1YWdlIHRhZ3MgdGhhdCBhcmUgc3Ryb25nbHkNCiAgIFJFQ09N TUVOREVEIGZvciB1c2UgaW4gcGxhY2Ugb2YgdGhlIHJlY29yZCdzIHZhbHVlLiAgSW4gbWFueSBj YXNlcw0KICAgdGhlIG1hcHBpbmdzIHdlcmUgY3JlYXRlZCBieSBkZXByZWNhdGlvbiBvZiB0aGUg dGFncyBkdXJpbmcgdGhlDQogICBwZXJpb2QgYmVmb3JlIHRoaXMgZG9jdW1lbnQgd2FzIGFkb3B0 ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAibm8tDQogICBueW4iIHdhcyBkZXByZWNhdGVkIGlu IGZhdm9yIG9mIHRoZSBJU08gNjM5LTEgZGVmaW5lZCBsYW5ndWFnZSBjb2RlDQogICAnbm4nLg0K DQogICBSZWNvcmRzIG9mIHR5cGUgJ3ZhcmlhbnQnIE1BWSBoYXZlIG1vcmUgdGhhbiBvbmUgZmll bGQgb2YgdHlwZQ0KICAgJ1ByZWZpeCcuICBBZGRpdGlvbmFsIGZpZWxkcyBvZiB0aGlzIHR5cGUg TUFZIGJlIGFkZGVkIHRvIGEgJ3ZhcmlhbnQnDQogICByZWNvcmQgdmlhIHRoZSByZWdpc3RyYXRp b24gcHJvY2Vzcy4NCg0KICAgUmVjb3JkcyBvZiB0eXBlICdleHRsYW5nJyBNVVNUIGhhdmUgX2V4 YWN0bHlfIG9uZSAnUHJlZml4JyBmaWVsZC4NCg0KICAgVGhlIGZpZWxkLXZhbHVlIG9mIHRoZSAn UHJlZml4JyBmaWVsZCBjb25zaXN0cyBvZiBhIGxhbmd1YWdlIHRhZw0KICAgd2hvc2Ugc3VidGFn cyBhcmUgYXBwcm9wcmlhdGUgdG8gdXNlIHdpdGggdGhpcyBzdWJ0YWcuICBGb3IgZXhhbXBsZSwN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIwMDYg ICAgICAgICAgICAgIFtQYWdlIDIyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgdGhlIHZh cmlhbnQgc3VidGFnICcxOTk2JyBoYXMgYSBQcmVmaXggZmllbGQgb2YgImRlIi4gIFRoaXMgbWVh bnMNCiAgIHRoYXQgdGFncyBzdGFydGluZyB3aXRoIHRoZSBzZXF1ZW5jZSAiZGUtIiBhcmUgYXBw cm9wcmlhdGUgd2l0aCB0aGlzDQogICBzdWJ0YWcsIHNvICJkZS1MYXRnLTE5OTYiIGFuZCAiZGUt Q0gtMTk5NiIgYXJlIGJvdGggYWNjZXB0YWJsZSwgd2hpbGUNCiAgIHRoZSB0YWcgImZyLTE5OTYi IGlzIGFuIGluYXBwcm9wcmlhdGUgY2hvaWNlLg0KDQogICBUaGUgZmllbGQgb2YgdHlwZSAnUHJl Zml4JyBNVVNUIE5PVCBiZSByZW1vdmVkIGZyb20gYW55IHJlY29yZC4gIFRoZQ0KICAgZmllbGQt dmFsdWUgZm9yIHRoaXMgdHlwZSBvZiBmaWVsZCBNVVNUIE5PVCBiZSBtb2RpZmllZC4NCg0KICAg VGhlIGZpZWxkICdDb21tZW50cycgTUFZIGFwcGVhciBtb3JlIHRoYW4gb25jZSBwZXIgcmVjb3Jk LiAgVGhpcw0KICAgZmllbGQgTUFZIGJlIGluc2VydGVkIG9yIGNoYW5nZWQgdmlhIHRoZSByZWdp c3RyYXRpb24gcHJvY2VzcyBhbmQgbm8NCiAgIGd1YXJhbnRlZSBvZiBzdGFiaWxpdHkgaXMgcHJv dmlkZWQuICBUaGUgY29udGVudCBvZiB0aGlzIGZpZWxkIGlzIG5vdA0KICAgcmVzdHJpY3RlZCwg ZXhjZXB0IGJ5IHRoZSBuZWVkIHRvIHJlZ2lzdGVyIHRoZSBpbmZvcm1hdGlvbiwgdGhlDQogICBz dWl0YWJpbGl0eSBvZiB0aGUgcmVxdWVzdCwgYW5kIGJ5IHJlYXNvbmFibGUgcHJhY3RpY2FsIHNp emUNCiAgIGxpbWl0YXRpb25zLiAgTG9uZyB0ZXh0cyBhYm91dCBhIHBhcnRpY3VsYXIgc3VidGFn IGFyZSBmcm93bmVkIHVwb24uDQoNCiAgIFRoZSBmaWVsZCAnU3VwcHJlc3MtU2NyaXB0JyBNVVNU IG9ubHkgYXBwZWFyIGluIHJlY29yZHMgd2hvc2UgJ1R5cGUnDQogICBmaWVsZC12YWx1ZSBpcyAn bGFuZ3VhZ2UnLiAgVGhpcyBmaWVsZCBNVVNUIE5PVCBhcHBlYXIgbW9yZSB0aGFuIG9uZQ0KICAg dGltZSBpbiBhIHJlY29yZC4gIFRoaXMgZmllbGQgaW5kaWNhdGVzIGEgc2NyaXB0IHVzZWQgdG8g d3JpdGUgdGhlDQogICBvdmVyd2hlbG1pbmcgbWFqb3JpdHkgb2YgZG9jdW1lbnRzIGZvciB0aGUg Z2l2ZW4gbGFuZ3VhZ2UgYW5kIHdoaWNoDQogICB0aGVyZWZvcmUgYWRkcyBubyBkaXN0aW5ndWlz aGluZyBpbmZvcm1hdGlvbiB0byBhIGxhbmd1YWdlIHRhZy4gIEl0DQogICBoZWxwcyBlbnN1cmUg Z3JlYXRlciBjb21wYXRpYmlsaXR5IGJldHdlZW4gdGhlIGxhbmd1YWdlIHRhZ3MNCiAgIGdlbmVy YXRlZCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGluIHRoaXMgZG9jdW1lbnQgYW5kIGxhbmd1YWdl IHRhZ3MNCiAgIGFuZCB0YWcgcHJvY2Vzc29ycyBvciBjb25zdW1lcnMgYmFzZWQgb24gUkZDIDMw NjYuICBGb3IgZXhhbXBsZSwNCiAgIHZpcnR1YWxseSBhbGwgSWNlbGFuZGljIGRvY3VtZW50cyBh cmUgd3JpdHRlbiBpbiB0aGUgTGF0aW4gc2NyaXB0LA0KICAgbWFraW5nIHRoZSBzdWJ0YWcgJ0xh dG4nIHJlZHVuZGFudCBpbiB0aGUgdGFnICJpcy1MYXRuIi4NCg0KMy4yICBNYWludGVuYW5jZSBv ZiB0aGUgUmVnaXN0cnkNCg0KICAgTWFpbnRlbmFuY2Ugb2YgdGhlIHJlZ2lzdHJ5IHJlcXVpcmVz IHRoYXQgYXMgY29kZXMgYXJlIGFzc2lnbmVkIG9yDQogICB3aXRoZHJhd24gYnkgSVNPIDYzOSwg SVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0uNDksIHRoZSBMYW5ndWFnZQ0KICAgU3VidGFn IFJldmlld2VyIE1VU1QgZXZhbHVhdGUgZWFjaCBjaGFuZ2UsIGRldGVybWluZSB3aGV0aGVyIGl0 DQogICBjb25mbGljdHMgd2l0aCBleGlzdGluZyByZWdpc3RyeSBlbnRyaWVzLCBhbmQgc3VibWl0 IHRoZSBpbmZvcm1hdGlvbg0KICAgdG8gSUFOQSBmb3IgaW5jbHVzaW9uIGluIHRoZSByZWdpc3Ry eS4gIElmIGFuIGNoYW5nZSB0YWtlcyBwbGFjZSBhbmQNCiAgIHRoZSBMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXIgZG9lcyBub3QgZG8gdGhpcyBpbiBhIHRpbWVseSBtYW5uZXIsDQogICB0aGVuIGFu eSBpbnRlcmVzdGVkIHBhcnR5IE1BWSB1c2UgdGhlIHByb2NlZHVyZSBpbiBTZWN0aW9uIDMuNCB0 bw0KICAgcmVnaXN0ZXIgdGhlIGFwcHJvcHJpYXRlIHVwZGF0ZS4NCg0KICAgTm90ZTogVGhlIHJl ZHVuZGFudCBhbmQgZ3JhbmRmYXRoZXJlZCBlbnRyaWVzIHRvZ2V0aGVyIGFyZSB0aGUNCiAgIGNv bXBsZXRlIGxpc3Qgb2YgdGFncyByZWdpc3RlcmVkIHVuZGVyIFtSRkMzMDY2XS4gIFRoZSByZWR1 bmRhbnQgdGFncw0KICAgYXJlIHRob3NlIHRoYXQgY2FuIG5vdyBiZSBmb3JtZWQgdXNpbmcgdGhl IHN1YnRhZ3MgZGVmaW5lZCBpbiB0aGUNCiAgIHJlZ2lzdHJ5IHRvZ2V0aGVyIHdpdGggdGhlIHJ1 bGVzIG9mICBTZWN0aW9uIDIuMi4gIFRoZSBncmFuZGZhdGhlcmVkDQogICBlbnRyaWVzIGFyZSB0 aG9zZSB0aGF0IGNhbiBuZXZlciBiZSBsZWdhbCB1bmRlciB0aG9zZSBzYW1lDQogICBwcm92aXNp b25zLg0KDQogICBUaGUgc2V0IG9mIHJlZHVuZGFudCBhbmQgZ3JhbmRmYXRoZXJlZCB0YWdzIGlz IHBlcm1hbmVudCBhbmQgc3RhYmxlOg0KICAgbmV3IGVudHJpZXMgaW4gdGhpcyBzZWN0aW9uIE1V U1QgTk9UIGJlIGFkZGVkIGFuZCBleGlzdGluZyBlbnRyaWVzDQogICBNVVNUIE5PVCBiZSByZW1v dmVkLiAgUmVjb3JkcyBvZiB0eXBlICdncmFuZGZhdGhlcmVkJyBNQVkgaGF2ZSB0aGVpcg0KICAg dHlwZSBjb252ZXJ0ZWQgdG8gJ3JlZHVuZGFudCc6IHNlZSAgU2VjdGlvbiAzLjcgZm9yIG1vcmUg aW5mb3JtYXRpb24uDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0K DQoNCiAgIFJGQyAzMDY2IHRhZ3MgdGhhdCB3ZXJlIGRlcHJlY2F0ZWQgcHJpb3IgdG8gdGhlIGFk b3B0aW9uIG9mIHRoaXMNCiAgIGRvY3VtZW50IGFyZSBwYXJ0IG9mIHRoZSBsaXN0IG9mIGdyYW5k ZmF0aGVyZWQgdGFncyBhbmQgdGhlaXINCiAgIGNvbXBvbmVudCBzdWJ0YWdzIHdlcmUgbm90IGlu Y2x1ZGVkIGFzIHJlZ2lzdGVyZWQgdmFyaWFudHMgKGFsdGhvdWdoDQogICB0aGV5IHJlbWFpbiBl bGlnaWJsZSBmb3IgcmVnaXN0cmF0aW9uKS4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJhcnQtDQog ICBsb2piYW4iIHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBsYW5ndWFnZSBzdWJ0YWcg J2pibycuDQoNCiAgIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBlbnN1cmUgdGhh dCBuZXcgc3VidGFncyBtZWV0IHRoZQ0KICAgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gNC4xIG9y IHN1Ym1pdCBhbiBhcHByb3ByaWF0ZSBhbHRlcm5hdGUgc3VidGFnDQogICBhcyBkZXNjcmliZWQg aW4gdGhhdCBzZWN0aW9uLiAgV2hlbiBlaXRoZXIgYSBjaGFuZ2Ugb3IgYWRkaXRpb24gdG8NCiAg IHRoZSByZWdpc3RyeSBpcyBuZWVkZWQsIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVT VCBwcmVwYXJlIHRoZQ0KICAgY29tcGxldGUgcmVjb3JkLCBpbmNsdWRpbmcgYWxsIGZpZWxkcywg YW5kIGZvcndhcmQgaXQgdG8gSUFOQSBmb3INCiAgIGluc2VydGlvbiBpbnRvIHRoZSByZWdpc3Ry eS4NCg0KICAgSWYgcmVjb3JkIHJlcHJlc2VudHMgYSBuZXcgc3VidGFnIHRoYXQgZG9lcyBub3Qg Y3VycmVudGx5IGV4aXN0IGluDQogICB0aGUgcmVnaXN0cnksIHRoZW4gdGhlIG1lc3NhZ2UncyBz dWJqZWN0IGxpbmUgTVVTVCBpbmNsdWRlIHRoZSB3b3JkDQogICAiSU5TRVJUIi4gIElmIHRoZSBy ZWNvcmQgcmVwcmVzZW50cyBhIGNoYW5nZSB0byBhbiBleGlzdGluZyBzdWJ0YWcsDQogICB0aGVu IHRoZSBzdWJqZWN0IGxpbmUgb2YgdGhlIG1lc3NhZ2UgTVVTVCBpbmNsdWRlIHRoZSB3b3JkICJN T0RJRlkiLg0KICAgVGhlIG1lc3NhZ2UgTVVTVCBjb250YWluIGJvdGggdGhlIHJlY29yZCBmb3Ig dGhlIHN1YnRhZyBiZWluZw0KICAgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgYW5kIHRoZSBuZXcgRmls ZS1EYXRlIHJlY29yZC4gIEhlcmUgaXMgYW4NCiAgIGV4YW1wbGUgb2Ygd2hhdCB0aGUgYm9keSBv ZiB0aGUgbWVzc2FnZSBtaWdodCBjb250YWluOg0KDQogICBMQU5HVUFHRSBTVUJUQUcgTU9ESUZJ Q0FUSU9ODQogICBGaWxlLURhdGU6IDIwMDUtMDEtMDINCiAgICUlDQogICBUeXBlOiB2YXJpYW50 DQogICBTdWJ0YWc6IG5lZGlzDQogICBEZXNjcmlwdGlvbjogTmF0aXNvbmUgZGlhbGVjdA0KICAg RGVzY3JpcHRpb246IE5hZGl6YSBkaWFsZWN0DQogICBBZGRlZDogMjAwMy0xMC0wOQ0KICAgUHJl Zml4OiBzbA0KICAgQ29tbWVudHM6IFRoaXMgaXMgYSBjb21tZW50IHNob3duDQogICAgIGFzIGFu IGV4YW1wbGUuDQogICAlJQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1 cmUgNA0KDQogICBXaGVuZXZlciBhbiBlbnRyeSBpcyBjcmVhdGVkIG9yIG1vZGlmaWVkIGluIHRo ZSByZWdpc3RyeSwgdGhlICdGaWxlLQ0KICAgRGF0ZScgcmVjb3JkIGF0IHRoZSBzdGFydCBvZiB0 aGUgcmVnaXN0cnkgaXMgdXBkYXRlZCB0byByZWZsZWN0IHRoZQ0KICAgbW9zdCByZWNlbnQgbW9k aWZpY2F0aW9uIGRhdGUgaW4gdGhlIFtSRkMzMzM5XSAiZnVsbC1kYXRlIiBmb3JtYXQuDQoNCiAg IFZhbHVlcyBpbiB0aGUgJ1N1YnRhZycgZmllbGQgTVVTVCBiZSBsb3dlcmNhc2UgZXhjZXB0IGFz IHByb3ZpZGVkIGZvcg0KICAgaW4gU2VjdGlvbiAzLjEuDQoNCjMuMyAgU3RhYmlsaXR5IG9mIElB TkEgUmVnaXN0cnkgRW50cmllcw0KDQogICBUaGUgc3RhYmlsaXR5IG9mIGVudHJpZXMgYW5kIHRo ZWlyIG1lYW5pbmcgaW4gdGhlIHJlZ2lzdHJ5IGlzDQogICBjcml0aWNhbCB0byB0aGUgbG9uZyB0 ZXJtIHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLiAgVGhlIHJ1bGVzIGluDQogICB0aGlzIHNl Y3Rpb24gZ3VhcmFudGVlIHRoYXQgYSBzcGVjaWZpYyBsYW5ndWFnZSB0YWcncyBtZWFuaW5nIGlz DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2 ICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIHN0YWJs ZSBvdmVyIHRpbWUgYW5kIHdpbGwgbm90IGNoYW5nZS4NCg0KICAgVGhlc2UgcnVsZXMgc3BlY2lm aWNhbGx5IGRlYWwgd2l0aCBob3cgY2hhbmdlcyB0byBjb2RlcyAoaW5jbHVkaW5nDQogICB3aXRo ZHJhd2FsIGFuZCBkZXByZWNhdGlvbiBvZiBjb2RlcykgbWFpbnRhaW5lZCBieSBJU08gNjM5LCBJ U08NCiAgIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0uNDkgYXJlIHJlZmxlY3RlZCBpbiB0aGUg SUFOQSBMYW5ndWFnZQ0KICAgU3VidGFnIFJlZ2lzdHJ5LiAgQXNzaWdubWVudHMgdG8gdGhlIElB TkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5DQogICBNVVNUIGZvbGxvdyB0aGUgZm9sbG93aW5n IHN0YWJpbGl0eSBydWxlczoNCg0KICAgMS4gICBWYWx1ZXMgaW4gdGhlIGZpZWxkcyAnVHlwZScs ICdTdWJ0YWcnLCAnVGFnJywgJ0FkZGVkJywNCiAgICAgICAgJ0RlcHJlY2F0ZWQnIGFuZCAnUHJl ZmVycmVkLVZhbHVlJyBNVVNUIE5PVCBiZSBjaGFuZ2VkIGFuZCBhcmUNCiAgICAgICAgZ3VhcmFu dGVlZCB0byBiZSBzdGFibGUgb3ZlciB0aW1lLg0KDQogICAyLiAgIFZhbHVlcyBpbiB0aGUgJ0Rl c2NyaXB0aW9uJyBmaWVsZCBNVVNUIE5PVCBiZSBjaGFuZ2VkIGluIGEgd2F5DQogICAgICAgIHRo YXQgd291bGQgaW52YWxpZGF0ZSBwcmV2aW91c2x5LWV4aXN0aW5nIHRhZ3MuICBUaGV5IE1BWSBi ZQ0KICAgICAgICBicm9hZGVuZWQgc29tZXdoYXQgaW4gc2NvcGUsIGNoYW5nZWQgdG8gYWRkIGlu Zm9ybWF0aW9uLCBvcg0KICAgICAgICBhZGFwdGVkIHRvIHRoZSBtb3N0IGNvbW1vbiBtb2Rlcm4g dXNhZ2UuICBGb3IgZXhhbXBsZSwgY291bnRyaWVzDQogICAgICAgIG9jY2FzaW9uYWxseSBjaGFu Z2UgdGhlaXIgb2ZmaWNpYWwgbmFtZXM6IGFuIGhpc3RvcmljYWwgZXhhbXBsZQ0KICAgICAgICBv ZiB0aGlzIHdvdWxkIGJlICJVcHBlciBWb2x0YSIgY2hhbmdpbmcgdG8gIkJ1cmtpbmEgRmFzbyIu DQoNCiAgIDMuICAgVmFsdWVzIGluIHRoZSBmaWVsZCAnUHJlZml4JyBNQVkgYmUgYWRkZWQgdG8g cmVjb3JkcyBvZiB0eXBlDQogICAgICAgICd2YXJpYW50JyB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBw cm9jZXNzLg0KDQogICA0LiAgIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcgTUFZIGJlIG1v ZGlmaWVkLCBzbyBsb25nIGFzIHRoZQ0KICAgICAgICBtb2RpZmljYXRpb25zIGJyb2FkZW4gdGhl IHNldCBvZiBwcmVmaXhlcy4gIFRoYXQgaXMsIGEgcHJlZml4DQogICAgICAgIE1BWSBiZSByZXBs YWNlZCBieSBvbmUgb2YgaXRzIG93biBwcmVmaXhlcy4gIEZvciBleGFtcGxlLCB0aGUNCiAgICAg ICAgcHJlZml4ICJlbi1VUyIgY291bGQgYmUgcmVwbGFjZWQgYnkgImVuIiwgYnV0IG5vdCBieSB0 aGUNCiAgICAgICAgcHJlZml4ZXMgImVuLUxhdG4iLCAiZnIiLCBvciAiZW4tVVMtYm9vbnQiLiAg SWYgb25lIG9mIHRob3NlDQogICAgICAgIHByZWZpeGVzIHdlcmUgbmVlZGVkLCBhIG5ldyBQcmVm aXggU0hPVUxEIGJlIHJlZ2lzdGVyZWQuDQoNCiAgIDUuICAgVmFsdWVzIGluIHRoZSBmaWVsZCAn UHJlZml4JyBNVVNUIE5PVCBiZSByZW1vdmVkLg0KDQogICA2LiAgIFRoZSBmaWVsZCAnQ29tbWVu dHMnIE1BWSBiZSBhZGRlZCwgY2hhbmdlZCwgbW9kaWZpZWQsIG9yIHJlbW92ZWQNCiAgICAgICAg dmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBvciBhbnkgb2YgdGhlIHByb2Nlc3NlcyBvcg0K ICAgICAgICBjb25zaWRlcmF0aW9ucyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uLg0KDQogICA3 LiAgIFRoZSBmaWVsZCAnU3VwcHJlc3MtU2NyaXB0JyBNQVkgYmUgYWRkZWQgb3IgcmVtb3ZlZCB2 aWEgdGhlDQogICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLg0KDQogICA4LiAgIENvZGVzIGFz c2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgYW5kIElTTyAzMTY2IHRoYXQgZG8gbm90DQog ICAgICAgIGNvbmZsaWN0IHdpdGggZXhpc3Rpbmcgc3VidGFncyBvZiB0aGUgYXNzb2NpYXRlZCB0 eXBlIGFuZCB3aG9zZQ0KICAgICAgICBtZWFuaW5nIGlzIG5vdCB0aGUgc2FtZSBhcyBhbiBleGlz dGluZyBzdWJ0YWcgb2YgdGhlIHNhbWUgdHlwZQ0KICAgICAgICBhcmUgZW50ZXJlZCBpbnRvIHRo ZSBJQU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRzLg0KDQogICA5LiAgIENvZGVzIGFzc2lnbmVk IGJ5IElTTyA2MzksIElTTyAxNTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBhcmUNCiAgICAgICAgd2l0 aGRyYXduIGJ5IHRoZWlyIHJlc3BlY3RpdmUgbWFpbnRlbmFuY2Ugb3IgcmVnaXN0cmF0aW9uDQog ICAgICAgIGF1dGhvcml0eSByZW1haW4gdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIEEgJ0RlcHJl Y2F0ZWQnIGZpZWxkDQogICAgICAgIGNvbnRhaW5pbmcgdGhlIGRhdGUgb2Ygd2l0aGRyYXdhbCBp cyBhZGRlZCB0byB0aGUgcmVjb3JkLiAgSWYgYQ0KICAgICAgICBuZXcgcmVjb3JkIG9mIHRoZSBz YW1lIHR5cGUgaXMgYWRkZWQgdGhhdCByZXByZXNlbnRzIGENCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDI1 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgICByZXBsYWNlbWVudCB2YWx1ZSwgdGhl biBhICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIE1BWSBhbHNvIGJlDQogICAgICAgIGFkZGVkLiAg VGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIE1BWSBiZSB1c2VkIHRvIGFkZCBjb21tZW50cw0KICAg ICAgICBhYm91dCB0aGUgd2l0aGRyYXdhbCBvZiB0aGUgY29kZSBieSB0aGUgcmVzcGVjdGl2ZSBz dGFuZGFyZC4NCg0KICAgICAgICBFeGFtcGxlIFRoZSByZWdpb24gY29kZSAnVEwnIHdhcyBhc3Np Z25lZCB0byB0aGUgY291bnRyeSAnVGltb3ItDQogICAgICAgICAgIExlc3RlJywgcmVwbGFjaW5n IHRoZSBjb2RlICdUUCcgKHdoaWNoIHdhcyBhc3NpZ25lZCB0byAnRWFzdA0KICAgICAgICAgICBU aW1vcicgd2hlbiBpdCB3YXMgdW5kZXIgYWRtaW5pc3RyYXRpb24gYnkgUG9ydHVnYWwpLiAgVGhl DQogICAgICAgICAgIHN1YnRhZyAnVFAnIHJlbWFpbnMgdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncywg YnV0IGl0cyByZWNvcmQNCiAgICAgICAgICAgY29udGFpbnMgdGhlIGEgJ1ByZWZlcnJlZC1WYWx1 ZScgb2YgJ1RMJyBhbmQgaXRzIGZpZWxkDQogICAgICAgICAgICdEZXByZWNhdGVkJyBjb250YWlu cyB0aGUgZGF0ZSB0aGUgbmV3IGNvZGUgd2FzIGFzc2lnbmVkDQogICAgICAgICAgICgnMjAwNC0w Ny0wNicpLg0KDQogICAxMC4gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwg b3IgSVNPIDMxNjYgdGhhdCBjb25mbGljdA0KICAgICAgICB3aXRoIGV4aXN0aW5nIHN1YnRhZ3Mg b2YgdGhlIGFzc29jaWF0ZWQgdHlwZSwgaW5jbHVkaW5nIHN1YnRhZ3MNCiAgICAgICAgdGhhdCBh cmUgZGVwcmVjYXRlZCwgTVVTVCBOT1QgYmUgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeS4gIFRo ZQ0KICAgICAgICBmb2xsb3dpbmcgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBhcHBseSB0byBz dWJ0YWcgdmFsdWVzIHRoYXQNCiAgICAgICAgYXJlIHJlYXNzaWduZWQ6DQoNCiAgICAgICAgQS4g IEZvciBJU08gNjM5IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcg aXMNCiAgICAgICAgICAgIG5vdCByZXByZXNlbnRlZCBieSBhIHN1YnRhZyBpbiB0aGUgSUFOQSBy ZWdpc3RyeSwgdGhlDQogICAgICAgICAgICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsIGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuNCwgU0hBTEwNCiAgICAgICAgICAgIHByZXBhcmUgYSBwcm9w b3NhbCBmb3IgZW50ZXJpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgc29vbg0KICAgICAgICAg ICAgYXMgcHJhY3RpY2FsIGEgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcgYXMgYW4gYWx0ZXJu YXRlDQogICAgICAgICAgICB2YWx1ZSBmb3IgdGhlIG5ldyBjb2RlLiAgVGhlIGZvcm0gb2YgdGhl IHJlZ2lzdGVyZWQgbGFuZ3VhZ2UNCiAgICAgICAgICAgIHN1YnRhZyB3aWxsIGJlIGF0IHRoZSBk aXNjcmV0aW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcNCiAgICAgICAgICAgIFJldmlld2VyIGFu ZCBNVVNUIGNvbmZvcm0gdG8gb3RoZXIgcmVzdHJpY3Rpb25zIG9uIGxhbmd1YWdlDQogICAgICAg ICAgICBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgQi4gIEZvciBhbGwgc3Vi dGFncyB3aG9zZSBtZWFuaW5nIGlzIGRlcml2ZWQgZnJvbSBhbiBleHRlcm5hbA0KICAgICAgICAg ICAgc3RhbmRhcmQgKGkuZS4gIElTTyA2MzksIElTTyAxNTkyNCwgSVNPIDMxNjYsIG9yIFVOIE0u NDkpLA0KICAgICAgICAgICAgaWYgYSBuZXcgbWVhbmluZyBpcyBhc3NpZ25lZCB0byBhbiBleGlz dGluZyBjb2RlIGFuZCB0aGUgbmV3DQogICAgICAgICAgICBtZWFuaW5nIGJyb2FkZW5zIHRoZSBt ZWFuaW5nIG9mIHRoYXQgY29kZSwgdGhlbiB0aGUgbWVhbmluZw0KICAgICAgICAgICAgZm9yIHRo ZSBhc3NvY2lhdGVkIHN1YnRhZyBNQVkgYmUgY2hhbmdlZCB0byBtYXRjaC4gIFRoZQ0KICAgICAg ICAgICAgbWVhbmluZyBvZiBhIHN1YnRhZyBNVVNUIE5PVCBiZSBuYXJyb3dlZCwgaG93ZXZlciwg YXMgdGhpcw0KICAgICAgICAgICAgY2FuIHJlc3VsdCBpbiBhbiB1bmtub3duIHByb3BvcnRpb24g b2YgdGhlIGV4aXN0aW5nIHVzZXMgb2YNCiAgICAgICAgICAgIGEgc3VidGFnIGJlY29taW5nIGlu dmFsaWQuICBOb3RlOiBJU08gNjM5IE1BL1JBIGhhcyBhZG9wdGVkDQogICAgICAgICAgICBhIHNp bWlsYXIgc3RhYmlsaXR5IHBvbGljeS4NCg0KICAgICAgICBDLiAgRm9yIElTTyAxNTkyNCBjb2Rl cywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICAgICBu b3QgcmVwcmVzZW50ZWQgYnkgYSBzdWJ0YWcgaW4gdGhlIElBTkEgcmVnaXN0cnksIHRoZQ0KICAg ICAgICAgICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAzLjQsIFNIQUxMDQogICAgICAgICAgICBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yIGVudGVyaW5n IGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIHNvb24NCiAgICAgICAgICAgIGFzIHByYWN0aWNhbCBh IHJlZ2lzdGVyZWQgdmFyaWFudCBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRlDQogICAgICAgICAgICB2 YWx1ZSBmb3IgdGhlIG5ldyBjb2RlLiAgVGhlIGZvcm0gb2YgdGhlIHJlZ2lzdGVyZWQgdmFyaWFu dA0KICAgICAgICAgICAgc3VidGFnIHdpbGwgYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIExh bmd1YWdlIFN1YnRhZw0KICAgICAgICAgICAgUmV2aWV3ZXIgYW5kIE1VU1QgY29uZm9ybSB0byBv dGhlciByZXN0cmljdGlvbnMgb24gdmFyaWFudA0KICAgICAgICAgICAgc3VidGFncyBpbiB0aGlz IGRvY3VtZW50Lg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyNl0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0K DQoNCiAgICAgICAgRC4gIEZvciBJU08gMzE2NiBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVk IGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUg VU4gTS40OSBjb2RlIGFzIGFub3RoZXIgJ3JlZ2lvbicNCiAgICAgICAgICAgIHN1YnRhZywgdGhl biB0aGUgZXhpc3RpbmcgcmVnaW9uIHN1YnRhZyByZW1haW5zIGFzIHRoZQ0KICAgICAgICAgICAg cHJlZmVycmVkIHZhbHVlIGZvciB0aGF0IHJlZ2lvbiBhbmQgbm8gbmV3IGVudHJ5IGlzIGNyZWF0 ZWQuDQogICAgICAgICAgICBBIGNvbW1lbnQgTUFZIGJlIGFkZGVkIHRvIHRoZSBleGlzdGluZyBy ZWdpb24gc3VidGFnDQogICAgICAgICAgICBpbmRpY2F0aW5nIHRoZSByZWxhdGlvbnNoaXAgdG8g dGhlIG5ldyBJU08gMzE2NiBjb2RlLg0KDQogICAgICAgIEUuICBGb3IgSVNPIDMxNjYgY29kZXMs IGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgICAgYXNz b2NpYXRlZCB3aXRoIGEgVU4gTS40OSBjb2RlIHRoYXQgaXMgbm90IHJlcHJlc2VudGVkIGJ5IGFu DQogICAgICAgICAgICBleGlzdGluZyByZWdpb24gc3VidGFnLCB0aGVuIHRoZSBMYW5ndWFnZSBT dWJ0YWcgUmV2aWV3ZXIsDQogICAgICAgICAgICBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQs IFNIQUxMIHByZXBhcmUgYSBwcm9wb3NhbCBmb3INCiAgICAgICAgICAgIGVudGVyaW5nIHRoZSBh cHByb3ByaWF0ZSBVTiBNLjQ5IGNvdW50cnkgY29kZSBhcyBhbiBlbnRyeSBpbg0KICAgICAgICAg ICAgdGhlIElBTkEgcmVnaXN0cnkuDQoNCiAgICAgICAgRi4gIEZvciBJU08gMzE2NiBjb2Rlcywg aWYgdGhlcmUgaXMgbm8gYXNzb2NpYXRlZCBVTiBudW1lcmljDQogICAgICAgICAgICBjb2RlLCB0 aGVuIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgU0hBTEwgcGV0aXRpb24gdGhlDQogICAg ICAgICAgICBVTiB0byBjcmVhdGUgb25lLiAgSWYgdGhlcmUgaXMgbm8gcmVzcG9uc2UgZnJvbSB0 aGUgVU4NCiAgICAgICAgICAgIHdpdGhpbiBuaW5ldHkgZGF5cyBvZiB0aGUgcmVxdWVzdCBiZWlu ZyBzZW50LCB0aGUgTGFuZ3VhZ2UNCiAgICAgICAgICAgIFN1YnRhZyBSZXZpZXdlciBTSEFMTCBw cmVwYXJlIGEgcHJvcG9zYWwgZm9yIGVudGVyaW5nIGluIHRoZQ0KICAgICAgICAgICAgSUFOQSBy ZWdpc3RyeSBhcyBzb29uIGFzIHByYWN0aWNhbCBhIHJlZ2lzdGVyZWQgdmFyaWFudA0KICAgICAg ICAgICAgc3VidGFnIGFzIGFuIGFsdGVybmF0ZSB2YWx1ZSBmb3IgdGhlIG5ldyBjb2RlLiAgVGhl IGZvcm0gb2YNCiAgICAgICAgICAgIHRoZSByZWdpc3RlcmVkIHZhcmlhbnQgc3VidGFnIHdpbGwg YmUgYXQgdGhlIGRpc2NyZXRpb24gb2YNCiAgICAgICAgICAgIHRoZSBMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXIgYW5kIE1VU1QgY29uZm9ybSB0byBvdGhlcg0KICAgICAgICAgICAgcmVzdHJpY3Rp b25zIG9uIHZhcmlhbnQgc3VidGFncyBpbiB0aGlzIGRvY3VtZW50LiAgVGhpcw0KICAgICAgICAg ICAgc2l0dWF0aW9uIGlzIHZlcnkgdW5saWtlbHkgdG8gZXZlciBvY2N1ci4NCg0KICAgMTEuICBV TiBNLjQ5IGhhcyBjb2RlcyBmb3IgYm90aCBjb3VudHJpZXMgYW5kIGFyZWFzIChzdWNoIGFzICcy NzYnDQogICAgICAgIGZvciBHZXJtYW55KSBhbmQgZ2VvZ3JhcGhpY2FsIHJlZ2lvbnMgYW5kIHN1 Yi1yZWdpb25zIChzdWNoIGFzDQogICAgICAgICcxNTAnIGZvciBFdXJvcGUpLiAgVU4gTS40OSBj b3VudHJ5IG9yIGFyZWEgY29kZXMgZm9yIHdoaWNoDQogICAgICAgIHRoZXJlIGlzIG5vIGNvcnJl c3BvbmRpbmcgSVNPIDMxNjYgY29kZSBTSE9VTEQgTk9UIGJlDQogICAgICAgIHJlZ2lzdGVyZWQs IGV4Y2VwdCBhcyBhIHN1cnJvZ2F0ZSBmb3IgYW4gSVNPIDMxNjYgY29kZSB0aGF0IGlzDQogICAg ICAgIGJsb2NrZWQgZnJvbSByZWdpc3RyYXRpb24gYnkgYW4gZXhpc3Rpbmcgc3VidGFnLiAgSWYg c3VjaCBhIGNvZGUNCiAgICAgICAgYmVjb21lcyBuZWNlc3NhcnksIHRoZW4gdGhlIHJlZ2lzdHJh dGlvbiBhdXRob3JpdHkgZm9yIElTTyAzMTY2DQogICAgICAgIFNIT1VMRCBmaXJzdCBiZSBwZXRp dGlvbmVkIHRvIGFzc2lnbiBhIGNvZGUgdG8gdGhlIHJlZ2lvbi4gIElmDQogICAgICAgIHRoZSBw ZXRpdGlvbiBmb3IgYSBjb2RlIGFzc2lnbm1lbnQgYnkgSVNPIDMxNjYgaXMgcmVmdXNlZCBvciBu b3QNCiAgICAgICAgYWN0ZWQgb24gaW4gYSB0aW1lbHkgbWFubmVyLCB0aGUgcmVnaXN0cmF0aW9u IHByb2Nlc3MgZGVzY3JpYmVkDQogICAgICAgIGluIFNlY3Rpb24gMy40IE1BWSB0aGVuIGJlIHVz ZWQgdG8gcmVnaXN0ZXIgdGhlIGNvcnJlc3BvbmRpbmcgVU4NCiAgICAgICAgTS40OSBjb2RlLiAg QXQgdGhlIHRpbWUgdGhpcyBkb2N1bWVudCB3YXMgd3JpdHRlbiwgdGhlcmUgd2VyZQ0KICAgICAg ICBvbmx5IGZvdXIgc3VjaCBjb2RlczogODMwIChDaGFubmVsIElzbGFuZHMpLCA4MzEgKEd1ZXJu c2V5KSwgODMyDQogICAgICAgIChKZXJzZXkpLCBhbmQgODMzIChJc2xlIG9mIE1hbikuICBUaGlz IHdheSBVTiBNLjQ5IGNvZGVzIHJlbWFpbg0KICAgICAgICBhdmFpbGFibGUgYXMgdGhlIHZhbHVl IG9mIGxhc3QgcmVzb3J0IGluIGNhc2VzIHdoZXJlIElTTyAzMTY2DQogICAgICAgIHJlYXNzaWdu cyBhIGRlcHJlY2F0ZWQgdmFsdWUgaW4gdGhlIHJlZ2lzdHJ5Lg0KDQogICAxMi4gIFN0YWJpbGl0 eSBwcm92aXNpb25zIGFwcGx5IHRvIGdyYW5kZmF0aGVyZWQgdGFncyB3aXRoIHRoaXMNCiAgICAg ICAgZXhjZXB0aW9uOiBzaG91bGQgYWxsIG9mIHRoZSBzdWJ0YWdzIGluIGEgZ3JhbmRmYXRoZXJl ZCB0YWcNCiAgICAgICAgYmVjb21lIHZhbGlkIHN1YnRhZ3MgaW4gdGhlIElBTkEgcmVnaXN0cnks IHRoZW4gdGhlIGZpZWxkICdUeXBlJw0KICAgICAgICBpbiB0aGF0IHJlY29yZCBpcyBjaGFuZ2Vk IGZyb20gJ2dyYW5kZmF0aGVyZWQnIHRvICdyZWR1bmRhbnQnLg0KICAgICAgICBOb3RlIHRoYXQg dGhpcyB3aWxsIG5vdCBhZmZlY3QgbGFuZ3VhZ2UgdGFncyB0aGF0IG1hdGNoIHRoZQ0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAg ICAgICAgW1BhZ2UgMjddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICAgIGdyYW5kZmF0 aGVyZWQgdGFnLCBzaW5jZSB0aGVzZSB0YWdzIHdpbGwgbm93IG1hdGNoIHZhbGlkDQogICAgICAg IGdlbmVyYXRpdmUgc3VidGFnIHNlcXVlbmNlcy4gIEZvciBleGFtcGxlLCBpZiB0aGUgc3VidGFn ICdnYW4nDQogICAgICAgIGluIHRoZSBsYW5ndWFnZSB0YWcgInpoLWdhbiIgd2VyZSB0byBiZSBy ZWdpc3RlcmVkIGFzIGFuDQogICAgICAgIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZywgdGhlbiB0 aGUgZ3JhbmRmYXRoZXJlZCB0YWcgInpoLWdhbiINCiAgICAgICAgd291bGQgYmUgZGVwcmVjYXRl ZCAoYnV0IGV4aXN0aW5nIGNvbnRlbnQgb3IgaW1wbGVtZW50YXRpb25zDQogICAgICAgIHRoYXQg dXNlICJ6aC1nYW4iIHdvdWxkIHJlbWFpbiB2YWxpZCkuDQoNCg0KMy40ICBSZWdpc3RyYXRpb24g UHJvY2VkdXJlIGZvciBTdWJ0YWdzDQoNCiAgIFRoZSBwcm9jZWR1cmUgZ2l2ZW4gaGVyZSBNVVNU IGJlIHVzZWQgYnkgYW55b25lIHdobyB3YW50cyB0byB1c2UgYQ0KICAgc3VidGFnIG5vdCBjdXJy ZW50bHkgaW4gdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5Lg0KDQogICBPbmx5IHN1 YnRhZ3Mgb2YgdHlwZSAnbGFuZ3VhZ2UnIGFuZCAndmFyaWFudCcgd2lsbCBiZSBjb25zaWRlcmVk IGZvcg0KICAgaW5kZXBlbmRlbnQgcmVnaXN0cmF0aW9uIG9mIG5ldyBzdWJ0YWdzLiAgSGFuZGxp bmcgb2Ygc3VidGFncyBuZWVkZWQNCiAgIGZvciBzdGFiaWxpdHkgYW5kIHN1YnRhZ3MgbmVjZXNz YXJ5IHRvIGtlZXAgdGhlIHJlZ2lzdHJ5IHN5bmNocm9uaXplZA0KICAgd2l0aCBJU08gNjM5LCBJ U08gMTU5MjQsIElTTyAzMTY2LCBhbmQgVU4gTS40OSB3aXRoaW4gdGhlIGxpbWl0cw0KICAgZGVm aW5lZCBieSB0aGlzIGRvY3VtZW50IGFyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuICBTdGFi aWxpdHkNCiAgIHByb3Zpc2lvbnMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4NCg0KICAg VGhpcyBwcm9jZWR1cmUgTUFZIGFsc28gYmUgdXNlZCB0byByZWdpc3RlciBvciBhbHRlciB0aGUg aW5mb3JtYXRpb24NCiAgIGZvciB0aGUgIkRlc2NyaXB0aW9uIiwgIkNvbW1lbnRzIiwgIkRlcHJl Y2F0ZWQiLCBvciAiUHJlZml4IiBmaWVsZHMNCiAgIGluIGEgc3VidGFnJ3MgcmVjb3JkIGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4gIENoYW5nZXMgdG8gYWxsDQogICBvdGhlciBmaWVsZHMg aW4gdGhlIElBTkEgcmVnaXN0cnkgYXJlIE5PVCBwZXJtaXR0ZWQuDQoNCiAgIFJlZ2lzdGVyaW5n IGEgbmV3IHN1YnRhZyBvciByZXF1ZXN0aW5nIG1vZGlmaWNhdGlvbnMgdG8gYW4gZXhpc3RpbmcN CiAgIHRhZyBvciBzdWJ0YWcgc3RhcnRzIHdpdGggdGhlIHJlcXVlc3RlciBmaWxsaW5nIG91dCB0 aGUgcmVnaXN0cmF0aW9uDQogICBmb3JtIHJlcHJvZHVjZWQgYmVsb3cuICBOb3RlIHRoYXQgZWFj aCByZXNwb25zZSBpcyBub3QgbGltaXRlZCBpbg0KICAgc2l6ZSBzbyB0aGF0IHRoZSByZXF1ZXN0 IGNhbiBhZGVxdWF0ZWx5IGRlc2NyaWJlIHRoZSByZWdpc3RyYXRpb24uDQogICBUaGUgZmllbGRz IGluIHRoZSAiUmVjb3JkIFJlcXVlc3RlZCIgc2VjdGlvbiBTSE9VTEQgZm9sbG93IHRoZQ0KICAg cmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gMy4xLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgs IDIwMDYgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAg TEFOR1VBR0UgU1VCVEFHIFJFR0lTVFJBVElPTiBGT1JNDQogICAxLiBOYW1lIG9mIHJlcXVlc3Rl cjoNCiAgIDIuIEUtbWFpbCBhZGRyZXNzIG9mIHJlcXVlc3RlcjoNCiAgIDMuIFJlY29yZCBSZXF1 ZXN0ZWQ6DQoNCiAgICAgIFR5cGU6DQogICAgICBTdWJ0YWc6DQogICAgICBEZXNjcmlwdGlvbjoN CiAgICAgIFByZWZpeDoNCiAgICAgIFByZWZlcnJlZC1WYWx1ZToNCiAgICAgIERlcHJlY2F0ZWQ6 DQogICAgICBTdXBwcmVzcy1TY3JpcHQ6DQogICAgICBDb21tZW50czoNCg0KICAgNC4gSW50ZW5k ZWQgbWVhbmluZyBvZiB0aGUgc3VidGFnOg0KICAgNS4gUmVmZXJlbmNlIHRvIHB1Ymxpc2hlZCBk ZXNjcmlwdGlvbg0KICAgICAgb2YgdGhlIGxhbmd1YWdlIChib29rIG9yIGFydGljbGUpOg0KICAg Ni4gQW55IG90aGVyIHJlbGV2YW50IGluZm9ybWF0aW9uOg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBGaWd1cmUgNQ0KDQogICBUaGUgc3VidGFnIHJlZ2lzdHJhdGlvbiBmb3Jt IE1VU1QgYmUgc2VudCB0bw0KICAgPGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnPiBmb3IgYSB0d28g d2VlayByZXZpZXcgcGVyaW9kIGJlZm9yZSBpdCBjYW4NCiAgIGJlIHN1Ym1pdHRlZCB0byBJQU5B LiAgKFRoaXMgaXMgYW4gb3BlbiBsaXN0IGFuZCBjYW4gYmUgam9pbmVkIGJ5DQogICBzZW5kaW5n IGEgcmVxdWVzdCB0byA8aWV0Zi1sYW5ndWFnZXMtcmVxdWVzdEBpYW5hLm9yZz4uKQ0KDQogICBW YXJpYW50IGFuZCBleHRsYW5nIHN1YnRhZ3MgYXJlIGFsd2F5cyByZWdpc3RlcmVkIGZvciB1c2Ug d2l0aCBhDQogICBwYXJ0aWN1bGFyIHJhbmdlIG9mIGxhbmd1YWdlIHRhZ3MuICBGb3IgZXhhbXBs ZSwgdGhlIHN1YnRhZyAncm96YWonDQogICBpcyBpbnRlbmRlZCBmb3IgdXNlIHdpdGggbGFuZ3Vh Z2UgdGFncyB0aGF0IHN0YXJ0IHdpdGggdGhlIHByaW1hcnkNCiAgIGxhbmd1YWdlIHN1YnRhZyAi c2wiLCBzaW5jZSBSZXNpYW4gaXMgYSBkaWFsZWN0IG9mIFNsb3Zlbmlhbi4gIFRodXMNCiAgIHRo ZSBzdWJ0YWcgJ3JvemFqJyBjb3VsZCBiZSBpbmNsdWRlZCBpbiB0YWdzIHN1Y2ggYXMgInNsLUxh dG4tcm96YWoiDQogICBvciAic2wtSVQtcm96YWoiLiAgVGhpcyBpbmZvcm1hdGlvbiBpcyBzdG9y ZWQgaW4gdGhlICJQcmVmaXgiIGZpZWxkDQogICBpbiB0aGUgcmVnaXN0cnkuICBWYXJpYW50IHJl Z2lzdHJhdGlvbiByZXF1ZXN0cyBhcmUgUkVRVUlSRUQgdG8NCiAgIGluY2x1ZGUgYXQgbGVhc3Qg b25lICJQcmVmaXgiIGZpZWxkIGluIHRoZSByZWdpc3RyYXRpb24gZm9ybS4NCg0KICAgVGhlICdQ cmVmaXgnIGZpZWxkIGZvciBhIGdpdmVuIHJlZ2lzdGVyZWQgc3VidGFnIGV4aXN0cyBpbiB0aGUg SUFOQQ0KICAgcmVnaXN0cnkgYXMgYSBndWlkZSB0byB1c2FnZS4gIEFkZGl0aW9uYWwgcHJlZml4 ZXMgTUFZIGJlIGFkZGVkIGJ5DQogICBmaWxpbmcgYW4gYWRkaXRpb25hbCByZWdpc3RyYXRpb24g Zm9ybS4gIEluIHRoYXQgZm9ybSwgdGhlICJBbnkgb3RoZXINCiAgIHJlbGV2YW50IGluZm9ybWF0 aW9uOiIgZmllbGQgTVVTVCBpbmRpY2F0ZSB0aGF0IGl0IGlzIHRoZSBhZGRpdGlvbiBvZg0KICAg YSBwcmVmaXguDQoNCiAgIFJlcXVlc3RzIHRvIGFkZCBhIHByZWZpeCB0byBhIHZhcmlhbnQgc3Vi dGFnIHRoYXQgaW1wbHkgYSBkaWZmZXJlbnQNCiAgIHNlbWFudGljIG1lYW5pbmcgd2lsbCBwcm9i YWJseSBiZSByZWplY3RlZC4gIEZvciBleGFtcGxlLCBhIHJlcXVlc3QNCiAgIHRvIGFkZCB0aGUg cHJlZml4ICJkZSIgdG8gdGhlIHN1YnRhZyAnbmVkaXMnIHNvIHRoYXQgdGhlIHRhZyAiZGUtDQog ICBuZWRpcyIgcmVwcmVzZW50ZWQgc29tZSBHZXJtYW4gZGlhbGVjdCB3b3VsZCBiZSByZWplY3Rl ZC4gIFRoZQ0KICAgJ25lZGlzJyBzdWJ0YWcgcmVwcmVzZW50cyBhIHBhcnRpY3VsYXIgU2xvdmVu aWFuIGRpYWxlY3QgYW5kIHRoZQ0KICAgYWRkaXRpb25hbCByZWdpc3RyYXRpb24gd291bGQgY2hh bmdlIHRoZSBzZW1hbnRpYyBtZWFuaW5nIGFzc2lnbmVkIHRvDQogICB0aGUgc3VidGFnLiAgQSBz ZXBhcmF0ZSBzdWJ0YWcgU0hPVUxEIGJlIHByb3Bvc2VkIGluc3RlYWQuDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBb UGFnZSAyOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3Ry eSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIFRoZSAnRGVzY3JpcHRpb24nIGZp ZWxkIE1VU1QgY29udGFpbiBhIGRlc2NyaXB0aW9uIG9mIHRoZSB0YWcgYmVpbmcNCiAgIHJlZ2lz dGVyZWQgd3JpdHRlbiBvciB0cmFuc2NyaWJlZCBpbnRvIHRoZSBMYXRpbiBzY3JpcHQ7IGl0IE1B WSBhbHNvDQogICBpbmNsdWRlIGEgZGVzY3JpcHRpb24gaW4gYSBub24tTGF0aW4gc2NyaXB0LiAg Tm9uLUFTQ0lJIGNoYXJhY3RlcnMNCiAgIE1VU1QgYmUgZXNjYXBlZCB1c2luZyB0aGUgc3ludGF4 IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMS4gIFRoZQ0KICAgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBp cyB1c2VkIGZvciBpZGVudGlmaWNhdGlvbiBwdXJwb3NlcyBhbmQgZG9lc24ndA0KICAgbmVjZXNz YXJpbHkgcmVwcmVzZW50IHRoZSBhY3R1YWwgbmF0aXZlIG5hbWUgb2YgdGhlIGxhbmd1YWdlIG9y DQogICB2YXJpYXRpb24gb3IgdG8gYmUgaW4gYW55IHBhcnRpY3VsYXIgbGFuZ3VhZ2UuDQoNCiAg IFdoaWxlIHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGl0c2VsZiBpcyBub3QgZ3VhcmFudGVlZCB0 byBiZSBzdGFibGUNCiAgIGFuZCBlcnJhdGEgY29ycmVjdGlvbnMgTUFZIGJlIHVuZGVydGFrZW4g ZnJvbSB0aW1lIHRvIHRpbWUsIGF0dGVtcHRzDQogICB0byBwcm92aWRlIHRyYW5zbGF0aW9ucyBv ciB0cmFuc2NyaXB0aW9ucyBvZiBlbnRyaWVzIGluIHRoZSByZWdpc3RyeQ0KICAgaXRzZWxmIHdp bGwgcHJvYmFibHkgYmUgZnJvd25lZCB1cG9uIGJ5IHRoZSBjb21tdW5pdHkgb3IgcmVqZWN0ZWQN CiAgIG91dHJpZ2h0LCBhcyBjaGFuZ2VzIG9mIHRoaXMgbmF0dXJlIGhhdmUgYW4gaW1wYWN0IG9u IHRoZSBwcm92aXNpb25zDQogICBpbiBTZWN0aW9uIDMuMy4NCg0KICAgVGhlIExhbmd1YWdlIFN1 YnRhZyBSZXZpZXdlciBpcyByZXNwb25zaWJsZSBmb3IgcmVzcG9uZGluZyB0bw0KICAgcmVxdWVz dHMgZm9yIHRoZSByZWdpc3RyYXRpb24gb2Ygc3VidGFncyB0aHJvdWdoIHRoZSByZWdpc3RyYXRp b24NCiAgIHByb2Nlc3MgYW5kIGlzIGFwcG9pbnRlZCBieSB0aGUgSUVTRy4NCg0KICAgV2hlbiB0 aGUgdHdvIHdlZWsgcGVyaW9kIGhhcyBwYXNzZWQgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdl cg0KICAgZWl0aGVyIGZvcndhcmRzIHRoZSByZWNvcmQgdG8gYmUgaW5zZXJ0ZWQgb3IgbW9kaWZp ZWQgdG8NCiAgIGlhbmFAaWFuYS5vcmcgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmUgZGVzY3Jp YmVkIGluIFNlY3Rpb24gMy4yLCBvcg0KICAgcmVqZWN0cyB0aGUgcmVxdWVzdCBiZWNhdXNlIG9m IHNpZ25pZmljYW50IG9iamVjdGlvbnMgcmFpc2VkIG9uIHRoZQ0KICAgbGlzdCBvciBkdWUgdG8g cHJvYmxlbXMgd2l0aCBjb25zdHJhaW50cyBpbiB0aGlzIGRvY3VtZW50ICh3aGljaCBNVVNUDQog ICBiZSBleHBsaWNpdGx5IGNpdGVkKS4gIFRoZSByZXZpZXdlciBNQVkgYWxzbyBleHRlbmQgdGhl IHJldmlldyBwZXJpb2QNCiAgIGluIHR3byB3ZWVrIGluY3JlbWVudHMgdG8gcGVybWl0IGZ1cnRo ZXIgZGlzY3Vzc2lvbi4gIFRoZSByZXZpZXdlcg0KICAgTVVTVCBpbmRpY2F0ZSBvbiB0aGUgbGlz dCB3aGV0aGVyIHRoZSByZWdpc3RyYXRpb24gaGFzIGJlZW4gYWNjZXB0ZWQsDQogICByZWplY3Rl ZCwgb3IgZXh0ZW5kZWQgZm9sbG93aW5nIGVhY2ggdHdvIHdlZWsgcGVyaW9kLg0KDQogICBOb3Rl IHRoYXQgdGhlIHJldmlld2VyIE1BWSByYWlzZSBvYmplY3Rpb25zIG9uIHRoZSBsaXN0IGlmIGhl IG9yIHNoZQ0KICAgc28gZGVzaXJlcy4gIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB0aGUg b2JqZWN0aW9uIE1VU1QgYmUgbWFkZQ0KICAgcHVibGljbHkuDQoNCiAgIFRoZSBhcHBsaWNhbnQg aXMgZnJlZSB0byBtb2RpZnkgYSByZWplY3RlZCBhcHBsaWNhdGlvbiB3aXRoDQogICBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIGFuZCBzdWJtaXQgaXQgYWdhaW47IHRoaXMgcmVzdGFydHMgdGhlIHR3 bw0KICAgd2VlayBjb21tZW50IHBlcmlvZC4NCg0KICAgRGVjaXNpb25zIG1hZGUgYnkgdGhlIHJl dmlld2VyIE1BWSBiZSBhcHBlYWxlZCB0byB0aGUgSUVTRyBbUkZDMjAyOF0NCiAgIHVuZGVyIHRo ZSBzYW1lIHJ1bGVzIGFzIG90aGVyIElFVEYgZGVjaXNpb25zIFtSRkMyMDI2XS4NCg0KICAgQWxs IGFwcHJvdmVkIHJlZ2lzdHJhdGlvbiBmb3JtcyBhcmUgYXZhaWxhYmxlIG9ubGluZSBpbiB0aGUg ZGlyZWN0b3J5DQogICBodHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbCB1bmRlciAibGFu Z3VhZ2VzIi4NCg0KICAgVXBkYXRlcyBvciBjaGFuZ2VzIHRvIGV4aXN0aW5nIHJlY29yZHMgZm9s bG93IHRoZSBzYW1lIHByb2NlZHVyZSBhcw0KICAgbmV3IHJlZ2lzdHJhdGlvbnMuICBUaGUgTGFu Z3VhZ2UgU3VidGFnIFJldmlld2VyIGRlY2lkZXMgd2hldGhlcg0KICAgdGhlcmUgaXMgY29uc2Vu c3VzIHRvIHVwZGF0ZSB0aGUgcmVnaXN0cmF0aW9uIGZvbGxvd2luZyB0aGUgdHdvIHdlZWsNCiAg IHJldmlldyBwZXJpb2Q7IG5vcm1hbGx5IG9iamVjdGlvbnMgYnkgdGhlIG9yaWdpbmFsIHJlZ2lz dHJhbnQgd2lsbA0KICAgY2FycnkgZXh0cmEgd2VpZ2h0IGluIGZvcm1pbmcgc3VjaCBhIGNvbnNl bnN1cy4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgs IDIwMDYgICAgICAgICAgICAgIFtQYWdlIDMwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAg UmVnaXN0cmF0aW9ucyBhcmUgcGVybWFuZW50IGFuZCBzdGFibGUuICBPbmNlIHJlZ2lzdGVyZWQs IHN1YnRhZ3MNCiAgIHdpbGwgbm90IGJlIHJlbW92ZWQgZnJvbSB0aGUgcmVnaXN0cnkgYW5kIHdp bGwgcmVtYWluIGEgdmFsaWQgd2F5IGluDQogICB3aGljaCB0byBzcGVjaWZ5IGEgc3BlY2lmaWMg bGFuZ3VhZ2Ugb3IgdmFyaWFudC4NCg0KICAgTm90ZTogVGhlIHB1cnBvc2Ugb2YgdGhlICJEZXNj cmlwdGlvbiIgaW4gdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIGlzDQogICBpbnRlbmRlZCBhcyBhbiBh aWQgdG8gcGVvcGxlIHRyeWluZyB0byB2ZXJpZnkgd2hldGhlciBhIGxhbmd1YWdlIGlzDQogICBy ZWdpc3RlcmVkIG9yIHdoYXQgbGFuZ3VhZ2Ugb3IgbGFuZ3VhZ2UgdmFyaWF0aW9uIGEgcGFydGlj dWxhciBzdWJ0YWcNCiAgIHJlZmVycyB0by4gIEluIG1vc3QgY2FzZXMsIHJlZmVyZW5jZSB0byBh biBhdXRob3JpdGF0aXZlIGdyYW1tYXIgb3INCiAgIGRpY3Rpb25hcnkgb2YgdGhhdCBsYW5ndWFn ZSB3aWxsIGJlIHVzZWZ1bDsgaW4gY2FzZXMgd2hlcmUgbm8gc3VjaA0KICAgd29yayBleGlzdHMs IG90aGVyIHdlbGwga25vd24gd29ya3MgZGVzY3JpYmluZyB0aGF0IGxhbmd1YWdlIG9yIGluDQog ICB0aGF0IGxhbmd1YWdlIE1BWSBiZSBhcHByb3ByaWF0ZS4gIFRoZSBzdWJ0YWcgcmV2aWV3ZXIg ZGVjaWRlcyB3aGF0DQogICBjb25zdGl0dXRlcyAiZ29vZCBlbm91Z2giIHJlZmVyZW5jZSBtYXRl cmlhbC4gIFRoaXMgcmVxdWlyZW1lbnQgaXMNCiAgIG5vdCBpbnRlbmRlZCB0byBleGNsdWRlIHBh cnRpY3VsYXIgbGFuZ3VhZ2VzIG9yIGRpYWxlY3RzIGR1ZSB0byB0aGUNCiAgIHNpemUgb2YgdGhl IHNwZWFrZXIgcG9wdWxhdGlvbiBvciBsYWNrIG9mIGEgc3RhbmRhcmRpemVkIG9ydGhvZ3JhcGh5 Lg0KICAgTWlub3JpdHkgbGFuZ3VhZ2VzIHdpbGwgYmUgY29uc2lkZXJlZCBlcXVhbGx5IG9uIHRo ZWlyIG93biBtZXJpdHMuDQoNCjMuNSAgUG9zc2liaWxpdGllcyBmb3IgUmVnaXN0cmF0aW9uDQoN CiAgIFBvc3NpYmlsaXRpZXMgZm9yIHJlZ2lzdHJhdGlvbiBvZiBzdWJ0YWdzIG9yIGluZm9ybWF0 aW9uIGFib3V0DQogICBzdWJ0YWdzIGluY2x1ZGU6DQoNCiAgIG8gIFByaW1hcnkgbGFuZ3VhZ2Ug c3VidGFncyBmb3IgbGFuZ3VhZ2VzIG5vdCBsaXN0ZWQgaW4gSVNPIDYzOSB0aGF0DQogICAgICBh cmUgbm90IHZhcmlhbnRzIG9mIGFueSBsaXN0ZWQgb3IgcmVnaXN0ZXJlZCBsYW5ndWFnZSBNQVkg YmUNCiAgICAgIHJlZ2lzdGVyZWQuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVh dGVkIHRoZXJlIHdlcmUgbm8NCiAgICAgIGV4YW1wbGVzIG9mIHRoaXMgZm9ybSBvZiBzdWJ0YWcu ICBCZWZvcmUgYXR0ZW1wdGluZyB0byByZWdpc3RlciBhDQogICAgICBsYW5ndWFnZSBzdWJ0YWcs IHRoZXJlIE1VU1QgYmUgYW4gYXR0ZW1wdCB0byByZWdpc3RlciB0aGUgbGFuZ3VhZ2UNCiAgICAg IHdpdGggSVNPIDYzOS4gIFN1YnRhZ3MgTVVTVCBOT1QgYmUgcmVnaXN0ZXJlZCBmb3IgY29kZXMg dGhhdCBleGlzdA0KICAgICAgaW4gSVNPIDYzOS0xIG9yIElTTyA2MzktMiwgd2hpY2ggYXJlIHVu ZGVyIGNvbnNpZGVyYXRpb24gYnkgdGhlDQogICAgICBJU08gNjM5IG1haW50ZW5hbmNlIG9yIHJl Z2lzdHJhdGlvbiBhdXRob3JpdGllcywgb3Igd2hpY2ggaGF2ZQ0KICAgICAgbmV2ZXIgYmVlbiBh dHRlbXB0ZWQgZm9yIHJlZ2lzdHJhdGlvbiB3aXRoIHRob3NlIGF1dGhvcml0aWVzLiAgSWYNCiAg ICAgIElTTyA2MzkgaGFzIHByZXZpb3VzbHkgcmVqZWN0ZWQgYSBsYW5ndWFnZSBmb3IgcmVnaXN0 cmF0aW9uLCBpdCBpcw0KICAgICAgcmVhc29uYWJsZSB0byBhc3N1bWUgdGhhdCB0aGVyZSBtdXN0 IGJlIGFkZGl0aW9uYWwgdmVyeSBjb21wZWxsaW5nDQogICAgICBldmlkZW5jZSBvZiBuZWVkIGJl Zm9yZSBpdCB3aWxsIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkNCiAgICAgICh0 byB0aGUgZXh0ZW50IHRoYXQgaXQgaXMgdmVyeSB1bmxpa2VseSB0aGF0IGFueSBzdWJ0YWdzIHdp bGwgYmUNCiAgICAgIHJlZ2lzdGVyZWQgb2YgdGhpcyB0eXBlKS4NCg0KICAgbyAgRGlhbGVjdCBv ciBvdGhlciBkaXZpc2lvbnMgb3IgdmFyaWF0aW9ucyB3aXRoaW4gYSBsYW5ndWFnZSwgaXRzDQog ICAgICBvcnRob2dyYXBoeSwgd3JpdGluZyBzeXN0ZW0sIHJlZ2lvbmFsIG9yIGhpc3RvcmljYWwg dXNhZ2UsDQogICAgICB0cmFuc2xpdGVyYXRpb24gb3Igb3RoZXIgdHJhbnNmb3JtYXRpb24sIG9y IGRpc3Rpbmd1aXNoaW5nDQogICAgICB2YXJpYXRpb24gTUFZIGJlIHJlZ2lzdGVyZWQgYXMgdmFy aWFudCBzdWJ0YWdzLiAgQW4gZXhhbXBsZSBpcyB0aGUNCiAgICAgICdyb3phaicgc3VidGFnICh0 aGUgUmVzaWFuIGRpYWxlY3Qgb2YgU2xvdmVuaWFuKS4NCg0KICAgbyAgVGhlIGFkZGl0aW9uIG9y IG1haW50ZW5hbmNlIG9mIGZpZWxkcyAoZ2VuZXJhbGx5IG9mIGFuDQogICAgICBpbmZvcm1hdGlv bmFsIG5hdHVyZSkgaW4gVGFnIG9yIFN1YnRhZyByZWNvcmRzIGFzIGRlc2NyaWJlZCBpbg0KICAg ICAgU2VjdGlvbiAzLjEgYW5kIHN1YmplY3QgdG8gdGhlIHN0YWJpbGl0eSBwcm92aXNpb25zIGlu DQogICAgICBTZWN0aW9uIDMuMy4gIFRoaXMgaW5jbHVkZXMgZGVzY3JpcHRpb25zOyBjb21tZW50 czsgZGVwcmVjYXRpb24NCiAgICAgIGFuZCBwcmVmZXJyZWQgdmFsdWVzIGZvciBvYnNvbGV0ZSBv ciB3aXRoZHJhd24gY29kZXM7IG9yIHRoZQ0KICAgICAgYWRkaXRpb24gb2Ygc2NyaXB0IG9yIGV4 dGxhbmcgaW5mb3JtYXRpb24gdG8gcHJpbWFyeSBsYW5ndWFnZQ0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2Ug MzFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAgICBzdWJ0YWdzLg0KDQogICBvICBUaGUg YWRkaXRpb24gb2YgcmVjb3JkcyBhbmQgcmVsYXRlZCBmaWVsZCB2YWx1ZSBjaGFuZ2VzIG5lY2Vz c2FyeQ0KICAgICAgdG8gcmVmbGVjdCBhc3NpZ25tZW50cyBtYWRlIGJ5IElTTyA2MzksIElTTyAx NTkyNCwgSVNPIDMxNjYsIGFuZA0KICAgICAgVU4gIE0uNDkgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gMy4zLg0KDQogICBUaGlzIGRvY3VtZW50IGxlYXZlcyB0aGUgZGVjaXNpb24gb24gd2hhdCBz dWJ0YWdzIG9yIGNoYW5nZXMgdG8NCiAgIHN1YnRhZ3MgYXJlIGFwcHJvcHJpYXRlIChvciBub3Qp IHRvIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40 Lg0KDQogICBOb3RlOiBmb3VyIGNoYXJhY3RlciBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MgYXJl IHJlc2VydmVkIHRvIGFsbG93DQogICBmb3IgdGhlIHBvc3NpYmlsaXR5IG9mIGFscGhhNCBjb2Rl cyBpbiBzb21lIGZ1dHVyZSBhZGRpdGlvbiB0byB0aGUNCiAgIElTTyA2MzkgZmFtaWx5IG9mIHN0 YW5kYXJkcy4NCg0KICAgSVNPIDYzOSBkZWZpbmVzIGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBh ZGRpdGlvbnMgdG8gYW5kIGNoYW5nZXMgaW4NCiAgIHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBpbiBJ U08gNjM5LiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24g Q2VudHJlIGZvciBUZXJtaW5vbG9neSAoSW5mb3Rlcm0pDQogICBBaWNoaG9semdhc3NlIDYvMTIs IEFULTExMjANCiAgIFdpZW4sIEF1c3RyaWENCiAgIFBob25lOiArNDMgMSAyNiA3NSAzNSBFeHQu IDMxMiBGYXg6ICs0MyAxIDIxNiAzMiA3Mg0KDQogICBJU08gNjM5LTIgZGVmaW5lcyBhIG1haW50 ZW5hbmNlIGFnZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzDQogICBpbiB0aGUgbGlz dCBvZiBsYW5ndWFnZXMgaW4gSVNPIDYzOS0yLiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIExpYnJh cnkgb2YgQ29uZ3Jlc3MNCiAgIE5ldHdvcmsgRGV2ZWxvcG1lbnQgYW5kIE1BUkMgU3RhbmRhcmRz IE9mZmljZQ0KICAgV2FzaGluZ3RvbiwgRC5DLiAyMDU0MCBVU0ENCiAgIFBob25lOiArMSAyMDIg NzA3IDYyMzcgIEZheDogKzEgMjAyIDcwNyAwMTE1DQogICBVUkw6IGh0dHA6Ly93d3cubG9jLmdv di9zdGFuZGFyZHMvaXNvNjM5DQoNCiAgIFRoZSBtYWludGVuYW5jZSBhZ2VuY3kgZm9yIElTTyAz MTY2IChjb3VudHJ5IGNvZGVzKSBpczoNCg0KICAgSVNPIDMxNjYgTWFpbnRlbmFuY2UgQWdlbmN5 DQogICBjL28gSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbg0K ICAgQ2FzZSBwb3N0YWxlIDU2DQogICBDSC0xMjExIEdlbmV2YSAyMCBTd2l0emVybGFuZA0KICAg UGhvbmU6ICs0MSAyMiA3NDkgNzIgMzMgIEZheDogKzQxIDIyIDc0OSA3MyA0OQ0KICAgVVJMOiBo dHRwOi8vd3d3Lmlzby5vcmcvaXNvL2VuL3Byb2RzLXNlcnZpY2VzL2lzbzMxNjZtYS9pbmRleC5o dG1sDQoNCiAgIFRoZSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IGZvciBJU08gMTU5MjQgKHNjcmlw dCBjb2RlcykgaXM6DQoNCiAgIFVuaWNvZGUgQ29uc29ydGl1bSBCb3ggMzkxNDc2DQogICBNb3Vu dGFpbiBWaWV3LCBDQSA5NDAzOS0xNDc2LCBVU0ENCiAgIFVSTDogaHR0cDovL3d3dy51bmljb2Rl Lm9yZy9pc28xNTkyNA0KDQogICBUaGUgU3RhdGlzdGljcyBEaXZpc2lvbiBvZiB0aGUgVW5pdGVk IE5hdGlvbnMgU2VjcmV0YXJpYXQgbWFpbnRhaW5zDQogICB0aGUgU3RhbmRhcmQgQ291bnRyeSBv ciBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UgYW5kIGNhbiBiZQ0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgMzJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICByZWFjaGVkIGF0Og0KDQogICBT dGF0aXN0aWNhbCBTZXJ2aWNlcyBCcmFuY2gNCiAgIFN0YXRpc3RpY3MgRGl2aXNpb24NCiAgIFVu aXRlZCBOYXRpb25zLCBSb29tIERDMi0xNjIwDQogICBOZXcgWW9yaywgTlkgMTAwMTcsIFVTQQ0K DQogICBGYXg6ICsxLTIxMi05NjMtMDYyMw0KICAgRS1tYWlsOiBzdGF0aXN0aWNzQHVuLm9yZw0K ICAgVVJMOiBodHRwOi8vdW5zdGF0cy51bi5vcmcvdW5zZC9tZXRob2RzL200OS9tNDlhbHBoYS5o dG0NCg0KMy42ICBFeHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIFJlZ2lzdHJ5DQoNCiAgIEV4dGVu c2lvbiBzdWJ0YWdzIGFyZSB0aG9zZSBpbnRyb2R1Y2VkIGJ5IHNpbmdsZSBjaGFyYWN0ZXIgc3Vi dGFncw0KICAgKCJzaW5nbGV0b25zIikgb3RoZXIgdGhhbiAneCcuICBUaGV5IGFyZSByZXNlcnZl ZCBmb3IgdGhlIGdlbmVyYXRpb24NCiAgIG9mIGlkZW50aWZpZXJzIHdoaWNoIGNvbnRhaW4gYSBs YW5ndWFnZSBjb21wb25lbnQsIGFuZCBhcmUgY29tcGF0aWJsZQ0KICAgd2l0aCBhcHBsaWNhdGlv bnMgdGhhdCB1bmRlcnN0YW5kIGxhbmd1YWdlIHRhZ3MuDQoNCiAgIFRoZSBzdHJ1Y3R1cmUgYW5k IGZvcm0gb2YgZXh0ZW5zaW9ucyBhcmUgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IHNvDQogICB0 aGF0IGltcGxlbWVudGF0aW9ucyBjYW4gYmUgY3JlYXRlZCB0aGF0IGFyZSBmb3J3YXJkIGNvbXBh dGlibGUgd2l0aA0KICAgYXBwbGljYXRpb25zIHRoYXQgbWlnaHQgYmUgY3JlYXRlZCB1c2luZyBz aW5nbGV0b25zIGluIHRoZSBmdXR1cmUuDQogICBJbiBhZGRpdGlvbiwgZGVmaW5pbmcgYSBtZWNo YW5pc20gZm9yIG1haW50YWluaW5nIHNpbmdsZXRvbnMgd2lsbA0KICAgbGVuZCBzdGFiaWxpdHkg dG8gdGhpcyBkb2N1bWVudCBieSByZWR1Y2luZyB0aGUgbGlrZWx5IG5lZWQgZm9yDQogICBmdXR1 cmUgcmV2aXNpb25zIG9yIHVwZGF0ZXMuDQoNCiAgIFNpbmdsZSBjaGFyYWN0ZXIgc3VidGFncyBh cmUgYXNzaWduZWQgYnkgSUFOQSB1c2luZyB0aGUgIklFVEYNCiAgIENvbnNlbnN1cyIgcG9saWN5 IGRlZmluZWQgYnkgW1JGQzI0MzRdLiAgVGhpcyBwb2xpY3kgcmVxdWlyZXMgdGhlDQogICBkZXZl bG9wbWVudCBvZiBhbiBSRkMsIHdoaWNoIFNIQUxMIGRlZmluZSB0aGUgbmFtZSwgcHVycG9zZSwN CiAgIHByb2Nlc3NlcywgYW5kIHByb2NlZHVyZXMgZm9yIG1haW50YWluaW5nIHRoZSBzdWJ0YWdz LiAgVGhlDQogICBtYWludGFpbmluZyBvciByZWdpc3RlcmluZyBhdXRob3JpdHksIGluY2x1ZGlu ZyBuYW1lLCBjb250YWN0IGVtYWlsLA0KICAgZGlzY3Vzc2lvbiBsaXN0IGVtYWlsLCBhbmQgVVJM IGxvY2F0aW9uIG9mIHRoZSByZWdpc3RyeSBNVVNUIGJlDQogICBpbmRpY2F0ZWQgY2xlYXJseSBp biB0aGUgUkZDLiAgVGhlIFJGQyBNVVNUIHNwZWNpZnkgb3IgaW5jbHVkZSBlYWNoDQogICBvZiB0 aGUgZm9sbG93aW5nOg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIHJlZmVyZW5jZSB0 aGUgc3BlY2lmaWMgdmVyc2lvbiBvciByZXZpc2lvbg0KICAgICAgb2YgdGhpcyBkb2N1bWVudCB0 aGF0IGdvdmVybnMgaXRzIGNyZWF0aW9uIGFuZCBNVVNUIHJlZmVyZW5jZSB0aGlzDQogICAgICBz ZWN0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIGFuZCBh bGwgc3VidGFncyBkZWZpbmVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9uDQogICAgICBNVVNUIGZvbGxv dyB0aGUgQUJORiBhbmQgb3RoZXIgcnVsZXMgZm9yIHRoZSBmb3JtYXRpb24gb2YgdGFncyBhbmQN CiAgICAgIHN1YnRhZ3MgYXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgSW4gcGFydGljdWxh ciBpdCBNVVNUDQogICAgICBzcGVjaWZ5IHRoYXQgY2FzZSBpcyBub3Qgc2lnbmlmaWNhbnQgYW5k IHRoYXQgc3VidGFncyBNVVNUIE5PVA0KICAgICAgZXhjZWVkIGVpZ2h0IGNoYXJhY3RlcnMgaW4g bGVuZ3RoLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIHNwZWNpZnkgYSBjYW5vbmlj YWwgcmVwcmVzZW50YXRpb24uDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIG9mIHZhbGlkIHN1 YnRhZ3MgTVVTVCBiZSBhdmFpbGFibGUgb3ZlciB0aGUNCiAgICAgIEludGVybmV0IGFuZCBhdCBu byBjb3N0Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAx OCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMzNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQog ICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIGluIHRoZSBwdWJsaWMgZG9tYWluIG9yIGF2 YWlsYWJsZSB2aWEgYQ0KICAgICAgcm95YWx0eS1mcmVlIGxpY2Vuc2UgYWNjZXB0YWJsZSB0byB0 aGUgSUVURiBhbmQgc3BlY2lmaWVkIGluIHRoZQ0KICAgICAgUkZDLg0KDQogICBvICBUaGUgc3Bl Y2lmaWNhdGlvbiBNVVNUIGJlIHZlcnNpb25lZCBhbmQgZWFjaCB2ZXJzaW9uIG9mIHRoZQ0KICAg ICAgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIG51bWJlcmVkLCBkYXRlZCwgYW5kIHN0YWJsZS4NCg0K ICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBiZSBzdGFibGUuICBUaGF0IGlzLCBleHRlbnNp b24gc3VidGFncywNCiAgICAgIG9uY2UgZGVmaW5lZCBieSBhIHNwZWNpZmljYXRpb24sIE1VU1Qg Tk9UIGJlIHJldHJhY3RlZCBvciBjaGFuZ2UNCiAgICAgIGluIG1lYW5pbmcgaW4gYW55IHN1YnN0 YW50aWFsIHdheS4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBpbmNsdWRlIGluIGEg c2VwYXJhdGUgc2VjdGlvbiB0aGUNCiAgICAgIHJlZ2lzdHJhdGlvbiBmb3JtIHJlcHJvZHVjZWQg aW4gdGhpcyBzZWN0aW9uIChiZWxvdykgdG8gYmUgdXNlZCBpbg0KICAgICAgcmVnaXN0ZXJpbmcg dGhlIGV4dGVuc2lvbiB1cG9uIHB1YmxpY2F0aW9uIGFzIGFuIFJGQy4NCg0KICAgbyAgSUFOQSBN VVNUIGJlIGluZm9ybWVkIG9mIGNoYW5nZXMgdG8gdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gYW5k DQogICAgICBVUkwgZm9yIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQogICBJQU5BIHdpbGwgbWFpbnRh aW4gYSByZWdpc3RyeSBvZiBhbGxvY2F0ZWQgc2luZ2xlIGNoYXJhY3Rlcg0KICAgKHNpbmdsZXRv bikgc3VidGFncy4gIFRoaXMgcmVnaXN0cnkgTVVTVCB1c2UgdGhlIHJlY29yZC1qYXIgZm9ybWF0 DQogICBkZXNjcmliZWQgYnkgdGhlIEFCTkYgaW4gU2VjdGlvbiAzLjEuICBVcG9uIHB1YmxpY2F0 aW9uIG9mIGFuDQogICBleHRlbnNpb24gYXMgYW4gUkZDLCB0aGUgbWFpbnRhaW5pbmcgYXV0aG9y aXR5IGRlZmluZWQgaW4gdGhlIFJGQw0KICAgTVVTVCBmb3J3YXJkIHRoaXMgcmVnaXN0cmF0aW9u IGZvcm0gdG8gaWVzZ0BpZXRmLm9yZywgd2hvIE1VU1QNCiAgIGZvcndhcmQgdGhlIHJlcXVlc3Qg dG8gaWFuYUBpYW5hLm9yZy4gIFRoZSBtYWludGFpbmluZyBhdXRob3JpdHkgb2YNCiAgIHRoZSBl eHRlbnNpb24gTVVTVCBtYWludGFpbiB0aGUgYWNjdXJhY3kgb2YgdGhlIHJlY29yZCBieSBzZW5k aW5nIGFuDQogICB1cGRhdGVkIGZ1bGwgY29weSBvZiB0aGUgcmVjb3JkIHRvIGlhbmFAaWFuYS5v cmcgd2l0aCB0aGUgc3ViamVjdA0KICAgbGluZSAiTEFOR1VBR0UgVEFHIEVYVEVOU0lPTiBVUERB VEUiIHdoZW5ldmVyIGNvbnRlbnQgY2hhbmdlcy4gIE9ubHkNCiAgIHRoZSAnQ29tbWVudHMnLCAn Q29udGFjdF9FbWFpbCcsICdNYWlsaW5nX0xpc3QnLCBhbmQgJ1VSTCcgZmllbGRzIE1BWQ0KICAg YmUgbW9kaWZpZWQgaW4gdGhlc2UgdXBkYXRlcy4NCg0KICAgRmFpbHVyZSB0byBtYWludGFpbiB0 aGlzIHJlY29yZCwgdGhlIGNvcnJlc3BvbmRpbmcgcmVnaXN0cnksIG9yIG1lZXQNCiAgIG90aGVy IGNvbmRpdGlvbnMgaW1wb3NlZCBieSB0aGlzIHNlY3Rpb24gb2YgdGhpcyBkb2N1bWVudCBNQVkg YmUNCiAgIGFwcGVhbGVkIHRvIHRoZSBJRVNHIFtSRkMyMDI4XSB1bmRlciB0aGUgc2FtZSBydWxl cyBhcyBvdGhlciBJRVRGDQogICBkZWNpc2lvbnMgKHNlZSBbUkZDMjAyNl0pIGFuZCBNQVkgcmVz dWx0IGluIHRoZSBhdXRob3JpdHkgdG8gbWFpbnRhaW4NCiAgIHRoZSBleHRlbnNpb24gYmVpbmcg d2l0aGRyYXduIG9yIHJlYXNzaWduZWQgYnkgdGhlIElFU0cuDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgs IDIwMDYgICAgICAgICAgICAgIFtQYWdlIDM0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAg JSUNCiAgIElkZW50aWZpZXI6DQogICBEZXNjcmlwdGlvbjoNCiAgIENvbW1lbnRzOg0KICAgQWRk ZWQ6DQogICBSRkM6DQogICBBdXRob3JpdHk6DQogICBDb250YWN0X0VtYWlsOg0KICAgTWFpbGlu Z19MaXN0Og0KICAgVVJMOg0KICAgJSUNCg0KICAgIEZpZ3VyZSA2OiBGb3JtYXQgb2YgUmVjb3Jk cyBpbiB0aGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgUmVnaXN0cnkNCg0KICAgJ0lkZW50aWZp ZXInIGNvbnRhaW5zIHRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRhZyAoc2luZ2xldG9uKQ0KICAg YXNzaWduZWQgdG8gdGhlIGV4dGVuc2lvbi4gIFRoZSBJbnRlcm5ldC1EcmFmdCBzdWJtaXR0ZWQg dG8gZGVmaW5lDQogICB0aGUgZXh0ZW5zaW9uIFNIT1VMRCBzcGVjaWZ5IHdoaWNoIGxldHRlciBv ciBkaWdpdCB0byB1c2UsIGFsdGhvdWdoDQogICB0aGUgSUVTRyBNQVkgY2hhbmdlIHRoZSBhc3Np Z25tZW50IHdoZW4gYXBwcm92aW5nIHRoZSBSRkMuDQoNCiAgICdEZXNjcmlwdGlvbicgY29udGFp bnMgdGhlIG5hbWUgYW5kIGRlc2NyaXB0aW9uIG9mIHRoZSBleHRlbnNpb24uDQoNCiAgICdDb21t ZW50cycgaXMgYW4gT1BUSU9OQUwgZmllbGQgYW5kIE1BWSBjb250YWluIGEgYnJvYWRlciBkZXNj cmlwdGlvbg0KICAgb2YgdGhlIGV4dGVuc2lvbi4NCg0KICAgJ0FkZGVkJyBjb250YWlucyB0aGUg ZGF0ZSB0aGUgUkZDIHdhcyBwdWJsaXNoZWQgaW4gdGhlICJmdWxsLWRhdGUiDQogICBmb3JtYXQg c3BlY2lmaWVkIGluIFtSRkMzMzM5XS4gIEZvciBleGFtcGxlOiAyMDA0LTA2LTI4IHJlcHJlc2Vu dHMNCiAgIEp1bmUgMjgsIDIwMDQsIGluIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIuDQoNCiAgICdS RkMnIGNvbnRhaW5zIHRoZSBSRkMgbnVtYmVyIGFzc2lnbmVkIHRvIHRoZSBleHRlbnNpb24uDQoN CiAgICdBdXRob3JpdHknIGNvbnRhaW5zIHRoZSBuYW1lIG9mIHRoZSBtYWludGFpbmluZyBhdXRo b3JpdHkgZm9yIHRoZQ0KICAgZXh0ZW5zaW9uLg0KDQogICAnQ29udGFjdF9FbWFpbCcgY29udGFp bnMgdGhlIGVtYWlsIGFkZHJlc3MgdXNlZCB0byBjb250YWN0IHRoZQ0KICAgbWFpbnRhaW5pbmcg YXV0aG9yaXR5Lg0KDQogICAnTWFpbGluZ19MaXN0JyBjb250YWlucyB0aGUgVVJMIG9yIHN1YnNj cmlwdGlvbiBlbWFpbCBhZGRyZXNzIG9mIHRoZQ0KICAgbWFpbGluZyBsaXN0IHVzZWQgYnkgdGhl IG1haW50YWluaW5nIGF1dGhvcml0eS4NCg0KICAgJ1VSTCcgY29udGFpbnMgdGhlIFVSTCBvZiB0 aGUgcmVnaXN0cnkgZm9yIHRoaXMgZXh0ZW5zaW9uLg0KDQogICBUaGUgZGV0ZXJtaW5hdGlvbiBv ZiB3aGV0aGVyIGFuIEludGVybmV0LURyYWZ0IG1lZXRzIHRoZSBhYm92ZQ0KICAgY29uZGl0aW9u cyBhbmQgdGhlIGRlY2lzaW9uIHRvIGdyYW50IG9yIHdpdGhob2xkIHN1Y2ggYXV0aG9yaXR5IHJl c3RzDQogICBzb2xlbHkgd2l0aCB0aGUgSUVTRywgYW5kIGlzIHN1YmplY3QgdG8gdGhlIG5vcm1h bCByZXZpZXcgYW5kIGFwcGVhbHMNCiAgIHByb2Nlc3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBSRkMg cHJvY2Vzcy4NCg0KICAgRXh0ZW5zaW9uIGF1dGhvcnMgYXJlIHN0cm9uZ2x5IGNhdXRpb25lZCB0 aGF0IG1hbnkgKGluY2x1ZGluZyBtb3N0DQogICB3ZWxsLWZvcm1lZCkgcHJvY2Vzc29ycyB3aWxs IGJlIHVuYXdhcmUgb2YgYW55IHNwZWNpYWwgcmVsYXRpb25zaGlwcw0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgW1Bh Z2UgMzVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICBvciBtZWFuaW5nIGluaGVyZW50IGlu IHRoZSBvcmRlciBvZiBleHRlbnNpb24gc3VidGFncy4gIEV4dGVuc2lvbg0KICAgYXV0aG9ycyBT SE9VTEQgYXZvaWQgc3VidGFnIHJlbGF0aW9uc2hpcHMgb3IgY2Fub25pY2FsaXphdGlvbg0KICAg bWVjaGFuaXNtcyB0aGF0IGludGVyZmVyZSB3aXRoIG1hdGNoaW5nIG9yIHdpdGggbGVuZ3RoIHJl c3RyaWN0aW9ucw0KICAgdGhhdCBzb21ldGltZXMgZXhpc3QgaW4gY29tbW9uIHByb3RvY29scyB3 aGVyZSB0aGUgZXh0ZW5zaW9uIGlzIHVzZWQuDQogICBJbiBwYXJ0aWN1bGFyLCBhcHBsaWNhdGlv bnMgTUFZIHRydW5jYXRlIHRoZSBzdWJ0YWdzIGluIGRvaW5nDQogICBtYXRjaGluZyBvciBpbiBm aXR0aW5nIGludG8gbGltaXRlZCBsZW5ndGhzLCBzbyBpdCBpcyBSRUNPTU1FTkRFRA0KICAgdGhh dCB0aGUgbW9zdCBzaWduaWZpY2FudCBpbmZvcm1hdGlvbiBiZSBpbiB0aGUgbW9zdCBzaWduaWZp Y2FudA0KICAgKGxlZnQtbW9zdCkgc3VidGFncywgYW5kIHRoYXQgdGhlIHNwZWNpZmljYXRpb24g Z3JhY2VmdWxseSBoYW5kbGUNCiAgIHRydW5jYXRlZCBzdWJ0YWdzLg0KDQogICBXaGVuIGEgbGFu Z3VhZ2UgdGFnIGlzIHRvIGJlIHVzZWQgaW4gYSBzcGVjaWZpYywga25vd24sIHByb3RvY29sLCBp dA0KICAgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGF0IHRoZSBsYW5ndWFnZSB0YWcgbm90IGNvbnRh aW4gZXh0ZW5zaW9ucyBub3QNCiAgIHN1cHBvcnRlZCBieSB0aGF0IHByb3RvY29sLiAgSW4gYWRk aXRpb24sIG5vdGUgdGhhdCBzb21lIHByb3RvY29scw0KICAgTUFZIGltcG9zZSB1cHBlciBsaW1p dHMgb24gdGhlIGxlbmd0aCBvZiB0aGUgc3RyaW5ncyB1c2VkIHRvIHN0b3JlIG9yDQogICB0cmFu c3BvcnQgdGhlIGxhbmd1YWdlIHRhZy4NCg0KMy43ICBJbml0aWFsaXphdGlvbiBvZiB0aGUgUmVn aXN0cmllcw0KDQogICBVcG9uIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYW4gaW5pdGlhbCB2 ZXJzaW9uIG9mIHRoZSBMYW5ndWFnZQ0KICAgU3VidGFnIFJlZ2lzdHJ5IGNvbnRhaW5pbmcgdGhl IHZhcmlvdXMgc3VidGFncyBpbml0aWFsbHkgdmFsaWQgaW4gYQ0KICAgbGFuZ3VhZ2UgdGFnIGlz IG5lY2Vzc2FyeS4gIFRoaXMgY29sbGVjdGlvbiBvZiBzdWJ0YWdzLCBhbG9uZyB3aXRoIGENCiAg IGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9jZXNzIHVzZWQgdG8gY3JlYXRlIGl0LCBpcyBkZXNjcmli ZWQgYnkNCiAgIFtpbml0aWFsLXJlZ2lzdHJ5XS4NCg0KICAgUmVnaXN0cmF0aW9ucyB0aGF0IGFy ZSBpbiBwcm9jZXNzIHVuZGVyIHRoZSBydWxlcyBkZWZpbmVkIGluDQogICBbUkZDMzA2Nl0gd2hl biB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgTUFZIGJlIGNvbXBsZXRlZCB1bmRlciB0aGUNCiAg IGZvcm1lciBydWxlcywgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIGxhbmd1YWdlIHRhZyByZXZp ZXdlci4gIEFueQ0KICAgbmV3IHJlZ2lzdHJhdGlvbnMgc3VibWl0dGVkIGFmdGVyIHRoZSBhZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50IE1VU1QNCiAgIGJlIHJlamVjdGVkLg0KDQogICBBbiBpbml0 aWFsIHZlcnNpb24gb2YgdGhlIExhbmd1YWdlIEV4dGVuc2lvbiBSZWdpc3RyeSBkZXNjcmliZWQg aW4NCiAgIFNlY3Rpb24gMy42IGlzIGFsc28gbmVlZGVkLiAgVGhlIExhbmd1YWdlIEV4dGVuc2lv biBSZWdpc3RyeSBTSEFMTCBiZQ0KICAgaW5pdGlhbGl6ZWQgd2l0aCBhIHNpbmdsZSByZWNvcmQg Y29udGFpbmluZyBhIHNpbmdsZSBmaWVsZCBvZiB0eXBlDQogICAiRmlsZS1EYXRlIiBhcyBhIHBs YWNlaG9sZGVyIGZvciBmdXR1cmUgYXNzaWdubWVudHMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwg MjAwNiAgICAgICAgICAgICAgW1BhZ2UgMzZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQo0LiAg Rm9ybWF0aW9uIGFuZCBQcm9jZXNzaW5nIG9mIExhbmd1YWdlIFRhZ3MNCg0KICAgVGhpcyBzZWN0 aW9uIGFkZHJlc3NlcyBob3cgdG8gdXNlIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgcmVnaXN0cnkN CiAgIHdpdGggdGhlIHRhZyBzeW50YXggdG8gY2hvb3NlLCBmb3JtIGFuZCBwcm9jZXNzIGxhbmd1 YWdlIHRhZ3MuDQoNCjQuMSAgQ2hvaWNlIG9mIExhbmd1YWdlIFRhZw0KDQogICBPbmUgaXMgc29t ZXRpbWVzIGZhY2VkIHdpdGggdGhlIGNob2ljZSBiZXR3ZWVuIHNldmVyYWwgcG9zc2libGUgdGFn cw0KICAgZm9yIHRoZSBzYW1lIGJvZHkgb2YgdGV4dC4NCg0KICAgSW50ZXJvcGVyYWJpbGl0eSBp cyBiZXN0IHNlcnZlZCB3aGVuIGFsbCB1c2VycyB1c2UgdGhlIHNhbWUgbGFuZ3VhZ2UNCiAgIHRh ZyBpbiBvcmRlciB0byByZXByZXNlbnQgdGhlIHNhbWUgbGFuZ3VhZ2UuICBJZiBhbiBhcHBsaWNh dGlvbiBoYXMNCiAgIHJlcXVpcmVtZW50cyB0aGF0IG1ha2UgdGhlIHJ1bGVzIGhlcmUgaW5hcHBs aWNhYmxlLCB0aGVuIHRoYXQNCiAgIGFwcGxpY2F0aW9uIHJpc2tzIGRhbWFnaW5nIGludGVyb3Bl cmFiaWxpdHkuICBJdCBpcyBzdHJvbmdseQ0KICAgUkVDT01NRU5ERUQgdGhhdCB1c2VycyBub3Qg ZGVmaW5lIHRoZWlyIG93biBydWxlcyBmb3IgbGFuZ3VhZ2UgdGFnDQogICBjaG9pY2UuDQoNCiAg IFN1YnRhZ3MgU0hPVUxEIG9ubHkgYmUgdXNlZCB3aGVyZSB0aGV5IGFkZCB1c2VmdWwgZGlzdGlu Z3Vpc2hpbmcNCiAgIGluZm9ybWF0aW9uOyBleHRyYW5lb3VzIHN1YnRhZ3MgaW50ZXJmZXJlIHdp dGggdGhlIG1lYW5pbmcsDQogICB1bmRlcnN0YW5kaW5nLCBhbmQgcHJvY2Vzc2luZyBvZiBsYW5n dWFnZSB0YWdzLiAgSW4gcGFydGljdWxhciwgdXNlcnMNCiAgIGFuZCBpbXBsZW1lbnRhdGlvbnMg U0hPVUxEIGZvbGxvdyB0aGUgJ1ByZWZpeCcgYW5kICdTdXBwcmVzcy1TY3JpcHQnDQogICBmaWVs ZHMgaW4gdGhlIHJlZ2lzdHJ5IChkZWZpbmVkIGluIFNlY3Rpb24gMy4xKTogdGhlc2UgZmllbGRz IHByb3ZpZGUNCiAgIGd1aWRhbmNlIG9uIHdoZW4gc3BlY2lmaWMgYWRkaXRpb25hbCBzdWJ0YWdz IFNIT1VMRCAoYW5kIFNIT1VMRCBOT1QpDQogICBiZSB1c2VkIGluIGEgbGFuZ3VhZ2UgdGFnLg0K DQogICBPZiBwYXJ0aWN1bGFyIG5vdGUsIG1hbnkgYXBwbGljYXRpb25zIGNhbiBiZW5lZml0IGZy b20gdGhlIHVzZSBvZg0KICAgc2NyaXB0IHN1YnRhZ3MgaW4gbGFuZ3VhZ2UgdGFncywgYXMgbG9u ZyBhcyB0aGUgdXNlIGlzIGNvbnNpc3RlbnQgZm9yDQogICBhIGdpdmVuIGNvbnRleHQuICBTY3Jp cHQgc3VidGFncyB3ZXJlIG5vdCBmb3JtYWxseSBkZWZpbmVkIGluIFJGQw0KICAgMzA2NiBhbmQg dGhlaXIgdXNlIGNhbiBhZmZlY3QgbWF0Y2hpbmcgYW5kIHN1YnRhZyBpZGVudGlmaWNhdGlvbiBi eQ0KICAgaW1wbGVtZW50YXRpb25zIG9mIFJGQyAzMDY2LCBhcyB0aGVzZSBzdWJ0YWdzIGFwcGVh ciBiZXR3ZWVuIHRoZQ0KICAgcHJpbWFyeSBsYW5ndWFnZSBhbmQgcmVnaW9uIHN1YnRhZ3MuICBG b3IgZXhhbXBsZSwgaWYgYSB1c2VyIHJlcXVlc3RzDQogICBjb250ZW50IGluIGFuIGltcGxlbWVu dGF0aW9uIG9mIFNlY3Rpb24gMi41IG9mIFtSRkMzMDY2XSB1c2luZyB0aGUNCiAgIGxhbmd1YWdl IHJhbmdlICJlbi1VUyIsIGNvbnRlbnQgbGFiZWxlZCAiZW4tTGF0bi1VUyIgd2lsbCBub3QgbWF0 Y2gNCiAgIHRoZSByZXF1ZXN0LiAgVGhlcmVmb3JlIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHdo ZW4gc2NyaXB0IHN1YnRhZ3MNCiAgIHdpbGwgY3VzdG9tYXJpbHkgYmUgdXNlZCBhbmQgd2hlbiB0 aGV5IG91Z2h0IG5vdCBiZSB1c2VkLiAgSW4gdGhlDQogICByZWdpc3RyeSwgdGhlIFN1cHByZXNz LVNjcmlwdCBmaWVsZCBoZWxwcyBlbnN1cmUgZ3JlYXRlcg0KICAgY29tcGF0aWJpbGl0eSBiZXR3 ZWVuIHRoZSBsYW5ndWFnZSB0YWdzIGdlbmVyYXRlZCBhY2NvcmRpbmcgdG8gdGhlDQogICBydWxl cyBpbiB0aGlzIGRvY3VtZW50IGFuZCBsYW5ndWFnZSB0YWdzIGFuZCB0YWcgcHJvY2Vzc29ycyBv cg0KICAgY29uc3VtZXJzIGJhc2VkIG9uIFJGQyAzMDY2IGJ5IGRlZmluaW5nIHdoZW4gdXNlcnMg U0hPVUxEIE5PVCBpbmNsdWRlDQogICBhIHNjcmlwdCBzdWJ0YWcgd2l0aCBhIHBhcnRpY3VsYXIg cHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcuDQoNCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3Mg KHR5cGUgJ2V4dGxhbmcnIGluIHRoZSByZWdpc3RyeSwgc2VlDQogICBTZWN0aW9uIDMuMSkgYWxz byBhcHBlYXIgYmV0d2VlbiB0aGUgcHJpbWFyeSBsYW5ndWFnZSBhbmQgcmVnaW9uDQogICBzdWJ0 YWdzIGFuZCBhcmUgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSBzdGFuZGFyZGl6YXRpb24uICBBcHBsaWNh dGlvbnMNCiAgIG1pZ2h0IGJlbmVmaXQgZnJvbSB0aGVpciBqdWRpY2lvdXMgdXNlIGluIGZvcm1p bmcgbGFuZ3VhZ2UgdGFncyBpbg0KICAgdGhlIGZ1dHVyZS4gIFNpbWlsYXIgcmVjb21tZW5kYXRp b25zIGFyZSBleHBlY3RlZCB0byBhcHBseSB0byB0aGVpcg0KICAgdXNlIGFzIGFwcGx5IHRvIHNj cmlwdCBzdWJ0YWdzLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAzN10NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAw NQ0KDQoNCiAgIFN0YW5kYXJkcywgcHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlvbnMgdGhhdCByZWZl cmVuY2UgdGhpcyBkb2N1bWVudA0KICAgbm9ybWF0aXZlbHkgYnV0IGFwcGx5IGRpZmZlcmVudCBy dWxlcyB0byB0aGUgb25lcyBnaXZlbiBpbiB0aGlzDQogICBzZWN0aW9uIE1VU1Qgc3BlY2lmeSBo b3cgdGhlIHByb2NlZHVyZSB2YXJpZXMgZnJvbSB0aGUgb25lIGdpdmVuDQogICBoZXJlLg0KDQog ICBUaGUgY2hvaWNlIG9mIHN1YnRhZ3MgdXNlZCB0byBmb3JtIGEgbGFuZ3VhZ2UgdGFnIFNIT1VM RCBiZSBndWlkZWQgYnkNCiAgIHRoZSBmb2xsb3dpbmcgcnVsZXM6DQoNCiAgIDEuICBVc2UgYXMg cHJlY2lzZSBhIHRhZyBhcyBwb3NzaWJsZSwgYnV0IG5vIG1vcmUgc3BlY2lmaWMgdGhhbiBpcw0K ICAgICAgIGp1c3RpZmllZC4gIEF2b2lkIHVzaW5nIHN1YnRhZ3MgdGhhdCBhcmUgbm90IGltcG9y dGFudCBmb3INCiAgICAgICBkaXN0aW5ndWlzaGluZyBjb250ZW50IGluIGFuIGFwcGxpY2F0aW9u Lg0KDQogICAgICAgKiAgRm9yIGV4YW1wbGUsICdkZScgbWlnaHQgc3VmZmljZSBmb3IgdGFnZ2lu ZyBhbiBlbWFpbCB3cml0dGVuDQogICAgICAgICAgaW4gR2VybWFuLCB3aGlsZSAiZGUtQ0gtMTk5 NiIgaXMgcHJvYmFibHkgdW5uZWNlc3NhcmlseQ0KICAgICAgICAgIHByZWNpc2UgZm9yIHN1Y2gg YSB0YXNrLg0KDQogICAyLiAgVGhlIHNjcmlwdCBzdWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2VkIHRv IGZvcm0gbGFuZ3VhZ2UgdGFncyB1bmxlc3MNCiAgICAgICB0aGUgc2NyaXB0IGFkZHMgc29tZSBk aXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbiB0byB0aGUgdGFnLiAgVGhlDQogICAgICAgZmllbGQg J1N1cHByZXNzLVNjcmlwdCcgaW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2UgcmVjb3JkIGluIHRoZQ0K ICAgICAgIHJlZ2lzdHJ5IGluZGljYXRlcyB3aGljaCBzY3JpcHQgc3VidGFncyBkbyBub3QgYWRk IGRpc3Rpbmd1aXNoaW5nDQogICAgICAgaW5mb3JtYXRpb24gZm9yIG1vc3QgYXBwbGljYXRpb25z Lg0KDQogICAgICAgKiAgRm9yIGV4YW1wbGUsIHRoZSBzdWJ0YWcgJ0xhdG4nIHNob3VsZCBub3Qg YmUgdXNlZCB3aXRoIHRoZQ0KICAgICAgICAgIHByaW1hcnkgbGFuZ3VhZ2UgJ2VuJyBiZWNhdXNl IG5lYXJseSBhbGwgRW5nbGlzaCBkb2N1bWVudHMgYXJlDQogICAgICAgICAgd3JpdHRlbiBpbiB0 aGUgTGF0aW4gc2NyaXB0IGFuZCBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQogICAgICAgICAg aW5mb3JtYXRpb24uICBIb3dldmVyLCBpZiBhIGRvY3VtZW50IHdlcmUgd3JpdHRlbiBpbiBFbmds aXNoDQogICAgICAgICAgbWl4aW5nIExhdGluIHNjcmlwdCB3aXRoIGFub3RoZXIgc2NyaXB0IHN1 Y2ggYXMgQnJhaWxsZQ0KICAgICAgICAgICgnQnJhaScpLCB0aGVuIGl0IG1pZ2h0IGJlIGFwcHJv cHJpYXRlIHRvIGNob29zZSB0byBpbmRpY2F0ZQ0KICAgICAgICAgIGJvdGggc2NyaXB0cyB0byBh aWQgaW4gY29udGVudCBzZWxlY3Rpb24sIHN1Y2ggYXMgdGhlDQogICAgICAgICAgYXBwbGljYXRp b24gb2YgYSBzdHlsZSBzaGVldC4NCg0KICAgMy4gIElmIGEgdGFnIG9yIHN1YnRhZyBoYXMgYSAn UHJlZmVycmVkLVZhbHVlJyBmaWVsZCBpbiBpdHMgcmVnaXN0cnkNCiAgICAgICBlbnRyeSwgdGhl biB0aGUgdmFsdWUgb2YgdGhhdCBmaWVsZCBTSE9VTEQgYmUgdXNlZCB0byBmb3JtIHRoZQ0KICAg ICAgIGxhbmd1YWdlIHRhZyBpbiBwcmVmZXJlbmNlIHRvIHRoZSB0YWcgb3Igc3VidGFnIGluIHdo aWNoIHRoZQ0KICAgICAgIHByZWZlcnJlZCB2YWx1ZSBhcHBlYXJzLg0KDQogICAgICAgKiAgRm9y IGV4YW1wbGUsIHVzZSAnaGUnIGZvciBIZWJyZXcgaW4gcHJlZmVyZW5jZSB0byAnaXcnLg0KDQog ICA0LiAgVGhlICd1bmQnIChVbmRldGVybWluZWQpIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIFNI T1VMRCBOT1QgYmUNCiAgICAgICB1c2VkIHRvIGxhYmVsIGNvbnRlbnQsIGV2ZW4gaWYgdGhlIGxh bmd1YWdlIGlzIHVua25vd24uICBPbWl0dGluZw0KICAgICAgIHRoZSBsYW5ndWFnZSB0YWcgYWx0 b2dldGhlciBpcyBwcmVmZXJyZWQgdG8gdXNpbmcgYSB0YWcgd2l0aCBhDQogICAgICAgcHJpbWFy eSBsYW5ndWFnZSBzdWJ0YWcgb2YgJ3VuZCcuICBUaGUgJ3VuZCcgc3VidGFnIE1BWSBiZSB1c2Vm dWwNCiAgICAgICBmb3IgcHJvdG9jb2xzIHRoYXQgcmVxdWlyZSBhIGxhbmd1YWdlIHRhZyB0byBi ZSBwcm92aWRlZC4gIFRoZQ0KICAgICAgICd1bmQnIHN1YnRhZyBNQVkgYWxzbyBiZSB1c2VmdWwg d2hlbiBtYXRjaGluZyBsYW5ndWFnZSB0YWdzIGluDQogICAgICAgY2VydGFpbiBzaXR1YXRpb25z Lg0KDQogICA1LiAgVGhlICdtdWwnIChNdWx0aXBsZSkgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcg U0hPVUxEIE5PVCBiZSB1c2VkDQogICAgICAgd2hlbmV2ZXIgdGhlIHByb3RvY29sIGFsbG93cyB0 aGUgc2VwYXJhdGUgdGFncyBmb3IgbXVsdGlwbGUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDM4XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgIGxhbmd1YWdlcywgYXMgaXMgdGhlIGNhc2UgZm9y IHRoZSBDb250ZW50LUxhbmd1YWdlIGhlYWRlciBpbg0KICAgICAgIEhUVFAuICBUaGUgJ211bCcg c3VidGFnIGNvbnZleXMgbGl0dGxlIHVzZWZ1bCBpbmZvcm1hdGlvbjoNCiAgICAgICBjb250ZW50 IGluIG11bHRpcGxlIGxhbmd1YWdlcyBTSE9VTEQgaW5kaXZpZHVhbGx5IHRhZyB0aGUNCiAgICAg ICBsYW5ndWFnZXMgd2hlcmUgdGhleSBhcHBlYXIgb3Igb3RoZXJ3aXNlIGluZGljYXRlIHRoZSBh Y3R1YWwNCiAgICAgICBsYW5ndWFnZSBpbiBwcmVmZXJlbmNlIHRvIHRoZSAnbXVsJyBzdWJ0YWcu DQoNCiAgIDYuICBUaGUgc2FtZSB2YXJpYW50IHN1YnRhZyBTSE9VTEQgTk9UIGJlIHVzZWQgbW9y ZSB0aGFuIG9uY2Ugd2l0aGluDQogICAgICAgYSBsYW5ndWFnZSB0YWcuDQoNCiAgICAgICAqICBG b3IgZXhhbXBsZSwgZG8gbm90IHVzZSAiZGUtREUtMTkwMS0xOTAxIi4NCg0KICAgVG8gZW5zdXJl IGNvbnNpc3RlbnQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgdGhpcyBkb2N1bWVudCBjb250YWlu cw0KICAgc2V2ZXJhbCBwcm92aXNpb25zIHRvIGFjY291bnQgZm9yIHBvdGVudGlhbCBpbnN0YWJp bGl0eSBpbiB0aGUNCiAgIHN0YW5kYXJkcyB1c2VkIHRvIGRlZmluZSB0aGUgc3VidGFncyB0aGF0 IG1ha2UgdXAgbGFuZ3VhZ2UgdGFncy4NCiAgIFRoZXNlIHByb3Zpc2lvbnMgbWVhbiB0aGF0IG5v IGxhbmd1YWdlIHRhZyBjcmVhdGVkIHVuZGVyIHRoZSBydWxlcyBpbg0KICAgdGhpcyBkb2N1bWVu dCB3aWxsIGJlY29tZSBvYnNvbGV0ZS4NCg0KNC4yICBNZWFuaW5nIG9mIHRoZSBMYW5ndWFnZSBU YWcNCg0KICAgVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB0YWcgYW5kIHRoZSBpbmZvcm1h dGlvbiBpdCByZWxhdGVzIHRvIGlzDQogICBkZWZpbmVkIGJ5IHRoZSBjb250ZXh0IGluIHdoaWNo IHRoZSB0YWcgYXBwZWFycy4gIEFjY29yZGluZ2x5LCB0aGlzDQogICBzZWN0aW9uIGdpdmVzIG9u bHkgcG9zc2libGUgZXhhbXBsZXMgb2YgaXRzIHVzYWdlLg0KDQogICBvICBGb3IgYSBzaW5nbGUg aW5mb3JtYXRpb24gb2JqZWN0LCB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0YWdzDQogICAgICBt aWdodCBiZSBpbnRlcnByZXRlZCBhcyB0aGUgc2V0IG9mIGxhbmd1YWdlcyB0aGF0IGlzIG5lY2Vz c2FyeSBmb3INCiAgICAgIGEgY29tcGxldGUgY29tcHJlaGVuc2lvbiBvZiB0aGUgY29tcGxldGUg b2JqZWN0LiAgRXhhbXBsZTogUGxhaW4NCiAgICAgIHRleHQgZG9jdW1lbnRzLg0KDQogICBvICBG b3IgYW4gYWdncmVnYXRpb24gb2YgaW5mb3JtYXRpb24gb2JqZWN0cywgdGhlIGFzc29jaWF0ZWQg bGFuZ3VhZ2UNCiAgICAgIHRhZ3MgY291bGQgYmUgdGFrZW4gYXMgdGhlIHNldCBvZiBsYW5ndWFn ZXMgdXNlZCBpbnNpZGUgY29tcG9uZW50cw0KICAgICAgb2YgdGhhdCBhZ2dyZWdhdGlvbi4gIEV4 YW1wbGVzOiBEb2N1bWVudCBzdG9yZXMgYW5kIGxpYnJhcmllcy4NCg0KICAgbyAgRm9yIGluZm9y bWF0aW9uIG9iamVjdHMgd2hvc2UgcHVycG9zZSBpcyB0byBwcm92aWRlIGFsdGVybmF0aXZlcywN CiAgICAgIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MgY291bGQgYmUgcmVnYXJkZWQgYXMg YSBoaW50IHRoYXQgdGhlDQogICAgICBjb250ZW50IGlzIHByb3ZpZGVkIGluIHNldmVyYWwgbGFu Z3VhZ2VzLCBhbmQgdGhhdCBvbmUgaGFzIHRvDQogICAgICBpbnNwZWN0IGVhY2ggb2YgdGhlIGFs dGVybmF0aXZlcyBpbiBvcmRlciB0byBmaW5kIGl0cyBsYW5ndWFnZSBvcg0KICAgICAgbGFuZ3Vh Z2VzLiAgSW4gdGhpcyBjYXNlLCB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgdGFncyBtaWdodCBu b3QNCiAgICAgIG1lYW4gdGhhdCBvbmUgbmVlZHMgdG8gYmUgbXVsdGktbGluZ3VhbCB0byBnZXQg Y29tcGxldGUNCiAgICAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRvY3VtZW50LiAgRXhhbXBsZTog TUlNRSBtdWx0aXBhcnQvDQogICAgICBhbHRlcm5hdGl2ZS4NCg0KICAgbyAgSW4gbWFya3VwIGxh bmd1YWdlcywgc3VjaCBhcyBIVE1MIGFuZCBYTUwsIGxhbmd1YWdlIGluZm9ybWF0aW9uDQogICAg ICBjYW4gYmUgYWRkZWQgdG8gZWFjaCBwYXJ0IG9mIHRoZSBkb2N1bWVudCBpZGVudGlmaWVkIGJ5 IHRoZSBtYXJrdXANCiAgICAgIHN0cnVjdHVyZSAoaW5jbHVkaW5nIHRoZSB3aG9sZSBkb2N1bWVu dCBpdHNlbGYpLiAgRm9yIGV4YW1wbGUsIG9uZQ0KICAgICAgY291bGQgd3JpdGUgPHNwYW4gbGFu Zz0iZnIiPkMnZXN0IGxhIHZpZS48L3NwYW4+IGluc2lkZSBhDQogICAgICBOb3J3ZWdpYW4gZG9j dW1lbnQ7IHRoZSBOb3J3ZWdpYW4tc3BlYWtpbmcgdXNlciBjb3VsZCB0aGVuIGFjY2Vzcw0KICAg ICAgYSBGcmVuY2gtTm9yd2VnaWFuIGRpY3Rpb25hcnkgdG8gZmluZCBvdXQgd2hhdCB0aGUgbWFy a2VkIHNlY3Rpb24NCiAgICAgIG1lYW50LiAgSWYgdGhlIHVzZXIgd2VyZSBsaXN0ZW5pbmcgdG8g dGhhdCBkb2N1bWVudCB0aHJvdWdoIGENCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDM5XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1DQoNCg0KICAgICAgc3BlZWNoIHN5bnRoZXNpcyBpbnRlcmZhY2UsIHRoaXMgZm9y bWF0aW9uIGNvdWxkIGJlIHVzZWQgdG8gc2lnbmFsDQogICAgICB0aGUgc3ludGhlc2l6ZXIgdG8g YXBwcm9wcmlhdGVseSBhcHBseSBGcmVuY2ggdGV4dC10by1zcGVlY2gNCiAgICAgIHByb251bmNp YXRpb24gcnVsZXMgdG8gdGhhdCBzcGFuIG9mIHRleHQsIGluc3RlYWQgb2YgYXBwbHlpbmcgdGhl DQogICAgICBpbmFwcHJvcHJpYXRlIE5vcndlZ2lhbiBydWxlcy4NCg0KICAgTGFuZ3VhZ2UgdGFn cyBhcmUgcmVsYXRlZCB3aGVuIHRoZXkgY29udGFpbiBhIHNpbWlsYXIgc2VxdWVuY2Ugb2YNCiAg IHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwgaWYgYSBsYW5ndWFnZSB0YWcgQiBjb250YWlucyBsYW5n dWFnZSB0YWcgQSBhcw0KICAgYSBwcmVmaXgsIHRoZW4gQiBpcyB0eXBpY2FsbHkgIm5hcnJvd2Vy IiBvciAibW9yZSBzcGVjaWZpYyIgdGhhbiBBLg0KICAgVGh1cyAiemgtSGFudC1UVyIgaXMgbW9y ZSBzcGVjaWZpYyB0aGFuICJ6aC1IYW50Ii4NCg0KICAgVGhpcyByZWxhdGlvbnNoaXAgaXMgbm90 IGd1YXJhbnRlZWQgaW4gYWxsIGNhc2VzOiBzcGVjaWZpY2FsbHksDQogICBsYW5ndWFnZXMgdGhh dCBiZWdpbiB3aXRoIHRoZSBzYW1lIHNlcXVlbmNlIG9mIHN1YnRhZ3MgYXJlIE5PVA0KICAgZ3Vh cmFudGVlZCB0byBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUsIGFsdGhvdWdoIHRoZXkgbWlnaHQg YmUuICBGb3INCiAgIGV4YW1wbGUsIHRoZSB0YWcgImF6IiBzaGFyZXMgYSBwcmVmaXggd2l0aCBi b3RoICJhei1MYXRuIg0KICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4gdXNpbmcgdGhlIExhdGluIHNj cmlwdCkgYW5kICJhei1DeXJsIg0KICAgKEF6ZXJiYWlqYW5pIHdyaXR0ZW4gdXNpbmcgdGhlIEN5 cmlsbGljIHNjcmlwdCkuICBBIHBlcnNvbiBmbHVlbnQgaW4NCiAgIG9uZSBzY3JpcHQgbWlnaHQg bm90IGJlIGFibGUgdG8gcmVhZCB0aGUgb3RoZXIsIGV2ZW4gdGhvdWdoIHRoZSB0ZXh0DQogICBt aWdodCBiZSBpZGVudGljYWwuICBDb250ZW50IHRhZ2dlZCBhcyAiYXoiIG1vc3QgcHJvYmFibHkg aXMgd3JpdHRlbg0KICAgaW4ganVzdCBvbmUgc2NyaXB0IGFuZCB0aHVzIG1pZ2h0IG5vdCBiZSBp bnRlbGxpZ2libGUgdG8gYSByZWFkZXINCiAgIGZhbWlsaWFyIHdpdGggdGhlIG90aGVyIHNjcmlw dC4NCg0KNC4zICBMZW5ndGggQ29uc2lkZXJhdGlvbnMNCg0KICAgW1JGQzMwNjZdIGRpZCBub3Qg cHJvdmlkZSBhbiB1cHBlciBsaW1pdCBvbiB0aGUgc2l6ZSBvZiBsYW5ndWFnZQ0KICAgdGFncy4g IFdoaWxlIFJGQyAzMDY2IGRpZCBkZWZpbmUgdGhlIHNlbWFudGljcyBvZiBwYXJ0aWN1bGFyIHN1 YnRhZ3MNCiAgIGluIHN1Y2ggYSB3YXkgdGhhdCBtb3N0IGxhbmd1YWdlIHRhZ3MgY29uc2lzdGVk IG9mIGxhbmd1YWdlIGFuZA0KICAgcmVnaW9uIHN1YnRhZ3Mgd2l0aCBhIGNvbWJpbmVkIHRvdGFs IGxlbmd0aCBvZiB1cCB0byBzaXggY2hhcmFjdGVycywNCiAgIGxhcmdlciByZWdpc3RlcmVkIHRh Z3Mgd2VyZSBub3Qgb25seSBwb3NzaWJsZSBidXQgd2VyZSBhY3R1YWxseQ0KICAgcmVnaXN0ZXJl ZC4NCg0KICAgTmVpdGhlciB0aGUgbGFuZ3VhZ2UgdGFnIHN5bnRheCBub3Igb3RoZXIgcmVxdWly ZW1lbnRzIGluIHRoaXMNCiAgIGRvY3VtZW50IGltcG9zZSBhIGZpeGVkIHVwcGVyIGxpbWl0IG9u IHRoZSBudW1iZXIgb2Ygc3VidGFncyBpbiBhDQogICBsYW5ndWFnZSB0YWcgKGFuZCB0aHVzIGFu IHVwcGVyIGJvdW5kIG9uIHRoZSBzaXplIG9mIGEgdGFnKS4gIFRoZQ0KICAgbGFuZ3VhZ2UgdGFn IHN5bnRheCBzdWdnZXN0cyB0aGF0LCBkZXBlbmRpbmcgb24gdGhlIHNwZWNpZmljDQogICBsYW5n dWFnZSwgbW9yZSBzdWJ0YWdzIChhbmQgdGh1cyBhIGxvbmdlciB0YWcpIGFyZSBzb21ldGltZXMN CiAgIG5lY2Vzc2FyeSB0byBjb21wbGV0ZWx5IGlkZW50aWZ5IHRoZSBsYW5ndWFnZSBmb3IgY2Vy dGFpbg0KICAgYXBwbGljYXRpb25zOyB0aHVzIGl0IGlzIHBvc3NpYmxlIHRvIGVudmlzaW9uIGxv bmcgb3IgY29tcGxleCBzdWJ0YWcNCiAgIHNlcXVlbmNlcy4NCg0KNC4zLjEgIFdvcmtpbmcgd2l0 aCBMaW1pdGVkIEJ1ZmZlciBTaXplcw0KDQogICBTb21lIGFwcGxpY2F0aW9ucyBhbmQgcHJvdG9j b2xzIGFyZSBmb3JjZWQgdG8gYWxsb2NhdGUgZml4ZWQgYnVmZmVyDQogICBzaXplcyBvciBvdGhl cndpc2UgbGltaXQgdGhlIGxlbmd0aCBvZiBhIGxhbmd1YWdlIHRhZy4gIEEgY29uZm9ybWFudA0K ICAgaW1wbGVtZW50YXRpb24gb3Igc3BlY2lmaWNhdGlvbiBNQVkgcmVmdXNlIHRvIHN1cHBvcnQg dGhlIHN0b3JhZ2Ugb2YNCiAgIGxhbmd1YWdlIHRhZ3Mgd2hpY2ggZXhjZWVkIGEgc3BlY2lmaWVk IGxlbmd0aC4gIEFueSBzdWNoIGxpbWl0YXRpb24NCiAgIFNIT1VMRCBiZSBjbGVhcmx5IGRvY3Vt ZW50ZWQsIGFuZCBzdWNoIGRvY3VtZW50YXRpb24gU0hPVUxEIGluY2x1ZGUNCiAgIHdoYXQgaGFw cGVucyB0byBsb25nZXIgdGFncyAoZm9yIGV4YW1wbGUsIHdoZXRoZXIgYW4gZXJyb3IgdmFsdWUg aXMNCiAgIGdlbmVyYXRlZCBvciB0aGUgbGFuZ3VhZ2UgdGFnIGlzIHRydW5jYXRlZCkuICBBIHBy b3RvY29sIHRoYXQgYWxsb3dzDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVz IEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA0MF0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3Qg MjAwNQ0KDQoNCiAgIHRhZ3MgdG8gYmUgdHJ1bmNhdGVkIGF0IGFuIGFyYml0cmFyeSBsaW1pdCwg d2l0aG91dCBnaXZpbmcgYW55DQogICBpbmRpY2F0aW9uIG9mIHdoYXQgdGhhdCBsaW1pdCBpcywg aGFzIHRoZSBwb3RlbnRpYWwgZm9yIGNhdXNpbmcgaGFybQ0KICAgYnkgY2hhbmdpbmcgdGhlIG1l YW5pbmcgb2YgdGFncyBpbiBzdWJzdGFudGlhbCB3YXlzLg0KDQogICBJbiBwcmFjdGljZSwgbW9z dCBsYW5ndWFnZSB0YWdzIGRvIG5vdCByZXF1aXJlIG1vcmUgdGhhbiBhIGZldw0KICAgc3VidGFn cyBhbmQgd2lsbCBub3QgYXBwcm9hY2ggcmVhc29uYWJseSBzaXplZCBidWZmZXIgbGltaXRhdGlv bnM6DQogICBzZWUgU2VjdGlvbiA0LjEuDQoNCiAgIFNvbWUgc3BlY2lmaWNhdGlvbnMgb3IgcHJv dG9jb2xzIGhhdmUgbGltaXRzIG9uIHRhZyBsZW5ndGggYnV0IGRvIG5vdA0KICAgaGF2ZSBhIGZp eGVkIGxlbmd0aCBsaW1pdGF0aW9uLiAgRm9yIGV4YW1wbGUsIFtSRkMyMjMxXSAgaGFzIG5vDQog ICBleHBsaWNpdCBsZW5ndGggbGltaXRhdGlvbjogdGhlIGxlbmd0aCBhdmFpbGFibGUgZm9yIHRo ZSBsYW5ndWFnZSB0YWcNCiAgIGlzIGNvbnN0cmFpbmVkIGJ5IHRoZSBsZW5ndGggb2Ygb3RoZXIg aGVhZGVyIGNvbXBvbmVudHMgKHN1Y2ggYXMgdGhlDQogICBjaGFyc2V0J3MgbmFtZSkgY291cGxl ZCB3aXRoIHRoZSA3NiBjaGFyYWN0ZXIgbGltaXQgaW4gW1JGQzIwNDddLg0KICAgVGh1cyB0aGUg ImxpbWl0IiBtaWdodCBiZSA1MCBvciBtb3JlIGNoYXJhY3RlcnMsIGJ1dCBpdCBjb3VsZA0KICAg cG90ZW50aWFsbHkgYmUgcXVpdGUgc21hbGwuDQoNCiAgIFRoZSBjb25zaWRlcmF0aW9ucyBmb3Ig YXNzaWduaW5nIGEgYnVmZmVyIGxpbWl0IGFyZToNCg0KICAgICAgSW1wbGVtZW50YXRpb25zIFNI T1VMRCBOT1QgdHJ1bmNhdGUgbGFuZ3VhZ2UgdGFncyB1bmxlc3MgdGhlDQogICAgICBtZWFuaW5n IG9mIHRoZSB0YWcgaXMgcHVycG9zZWZ1bGx5IGJlaW5nIGNoYW5nZWQsIG9yIHVubGVzcyB0aGUN CiAgICAgIHRhZyBkb2VzIG5vdCBmaXQgaW50byBhIGxpbWl0ZWQgYnVmZmVyIHNpemUgc3BlY2lm aWVkIGJ5IGENCiAgICAgIHByb3RvY29sIGZvciBzdG9yYWdlIG9yIHRyYW5zbWlzc2lvbi4NCg0K ICAgICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCB3YXJuIHRoZSB1c2VyIHdoZW4gYSB0YWcgaXMg dHJ1bmNhdGVkIHNpbmNlDQogICAgICB0cnVuY2F0aW9uIGNoYW5nZXMgdGhlIHNlbWFudGljIG1l YW5pbmcgb2YgdGhlIHRhZy4NCg0KICAgICAgSW1wbGVtZW50YXRpb25zIG9mIHByb3RvY29scyBv ciBzcGVjaWZpY2F0aW9ucyB0aGF0IGFyZSBzcGFjZQ0KICAgICAgY29uc3RyYWluZWQgYnV0IGRv IG5vdCBoYXZlIGEgZml4ZWQgbGltaXQgU0hPVUxEIHVzZSB0aGUgbG9uZ2VzdA0KICAgICAgcG9z c2libGUgdGFnIGluIHByZWZlcmVuY2UgdG8gdHJ1bmNhdGlvbi4NCg0KICAgICAgUHJvdG9jb2xz IG9yIHNwZWNpZmljYXRpb25zIHRoYXQgc3BlY2lmeSBsaW1pdGVkIGJ1ZmZlciBzaXplcyBmb3IN CiAgICAgIGxhbmd1YWdlIHRhZ3MgTVVTVCBhbGxvdyBmb3IgbGFuZ3VhZ2UgdGFncyBvZiB1cCB0 byAzMyBjaGFyYWN0ZXJzLg0KDQogICAgICBQcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMgdGhh dCBzcGVjaWZ5IGxpbWl0ZWQgYnVmZmVyIHNpemVzIGZvcg0KICAgICAgbGFuZ3VhZ2UgdGFncyBT SE9VTEQgYWxsb3cgZm9yIGxhbmd1YWdlIHRhZ3Mgb2YgYXQgbGVhc3QgNDINCiAgICAgIGNoYXJh Y3RlcnMuDQoNCiAgIFRoZSBmb2xsb3dpbmcgaWxsdXN0cmF0aW9uIHNob3dzIGhvdyB0aGUgNDIt Y2hhcmFjdGVyIHJlY29tbWVuZGF0aW9uDQogICB3YXMgZGVyaXZlZC4gIFRoZSBjb21iaW5hdGlv biBvZiBsYW5ndWFnZSBhbmQgZXh0ZW5kZWQgbGFuZ3VhZ2UNCiAgIHN1YnRhZ3Mgd2FzIGNob3Nl biBmb3IgZnV0dXJlIGNvbXBhdGliaWxpdHkuICBBdCB1cCB0byAxNSBjaGFyYWN0ZXJzLA0KICAg dGhpcyBjb21iaW5hdGlvbiBpcyBsb25nZXIgdGhhbiB0aGUgbG9uZ2VzdCBwb3NzaWJsZSBwcmlt YXJ5IGxhbmd1YWdlDQogICBzdWJ0YWcgKDggY2hhcmFjdGVycyk6DQoNCg0KDQoNCg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAg ICAgICAgICBbUGFnZSA0MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIGxhbmd1YWdlICAg ICAgPSAgMyAoSVNPIDYzOS0yOyBJU08gNjM5LTEgcmVxdWlyZXMgMikNCiAgIGV4dGxhbmcxICAg ICAgPSAgNCAoZWFjaCBzdWJzZXF1ZW50IHN1YnRhZyBpbmNsdWRlcyAnLScpDQogICBleHRsYW5n MiAgICAgID0gIDQgKHVubGlrZWx5OiBuZWVkcyBwcmVmaXg9Imxhbmd1YWdlLWV4dGxhbmcxIikN CiAgIGV4dGxhbmczICAgICAgPSAgNCAoZXh0cmVtZWx5IHVubGlrZWx5KQ0KICAgc2NyaXB0ICAg ICAgICA9ICA1IChpZiBub3Qgc3VwcHJlc3NlZDogc2VlIFNlY3Rpb24gNC4xKQ0KICAgcmVnaW9u ICAgICAgICA9ICA0IChVTiBNLjQ5OyBJU08gMzE2NiByZXF1aXJlcyAzKQ0KICAgdmFyaWFudDEg ICAgICA9ICA5IChNVVNUIGhhdmUgbGFuZ3VhZ2UgYXMgYSBwcmVmaXgpDQogICB2YXJpYW50MiAg ICAgID0gIDkgKE1VU1QgaGF2ZSBsYW5ndWFnZS12YXJpYW50MSBhcyBhIHByZWZpeCkNCg0KICAg dG90YWwgICAgICAgICA9IDQyIGNoYXJhY3RlcnMNCg0KICAgICAgICAgICAgICBGaWd1cmUgNzog RGVyaXZhdGlvbiBvZiB0aGUgTGltaXQgb24gVGFnIExlbmd0aA0KDQoNCjQuMy4yICBUcnVuY2F0 aW9uIG9mIExhbmd1YWdlIFRhZ3MNCg0KICAgVHJ1bmNhdGlvbiBvZiBhIGxhbmd1YWdlIHRhZyBh bHRlcnMgdGhlIG1lYW5pbmcgb2YgdGhlIHRhZywgYW5kIHRodXMNCiAgIFNIT1VMRCBiZSBhdm9p ZGVkLiAgSG93ZXZlciwgdHJ1bmNhdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGlzIHNvbWV0aW1lcw0K ICAgbmVjZXNzYXJ5IGR1ZSB0byBsaW1pdGVkIGJ1ZmZlciBzaXplcy4gIFN1Y2ggdHJ1bmNhdGlv biBNVVNUIE5PVA0KICAgcGVybWl0IGEgc3VidGFnIHRvIGJlIGNob3BwZWQgb2ZmIGluIHRoZSBt aWRkbGUgb3IgdGhlIGZvcm1hdGlvbiBvZg0KICAgaW52YWxpZCB0YWdzIChmb3IgZXhhbXBsZSwg b25lIGVuZGluZyB3aXRoIHRoZSAiLSIgY2hhcmFjdGVyKS4NCg0KICAgVGhpcyBtZWFucyB0aGF0 IGFwcGxpY2F0aW9ucyBvciBwcm90b2NvbHMgd2hpY2ggdHJ1bmNhdGUgdGFncyBNVVNUIGRvDQog ICBzbyBieSBwcm9ncmVzc2l2ZWx5IHJlbW92aW5nIHN1YnRhZ3MgYWxvbmcgd2l0aCB0aGVpciBw cmVjZWRpbmcgIi0iDQogICBmcm9tIHRoZSByaWdodCBzaWRlIG9mIHRoZSBsYW5ndWFnZSB0YWcg dW50aWwgdGhlIHRhZyBpcyBzaG9ydCBlbm91Z2gNCiAgIGZvciB0aGUgZ2l2ZW4gYnVmZmVyLiAg SWYgdGhlIHJlc3VsdGluZyB0YWcgZW5kcyB3aXRoIGEgc2luZ2xlLQ0KICAgY2hhcmFjdGVyIHN1 YnRhZywgdGhhdCBzdWJ0YWcgYW5kIGl0cyBwcmVjZWRpbmcgIi0iIE1VU1QgYWxzbyBiZQ0KICAg cmVtb3ZlZC4gIEZvciBleGFtcGxlOg0KDQogICBUYWcgdG8gdHJ1bmNhdGU6IHpoLUhhbnQtQ04t dmFyaWFudDEtYS1leHRlbmQxLXgtd2FkZWdpbGUtcHJpdmF0ZTENCiAgIDEuIHpoLUxhdG4tQ04t dmFyaWFudDEtYS1leHRlbmQxLXgtd2FkZWdpbGUNCiAgIDIuIHpoLUxhdG4tQ04tdmFyaWFudDEt YS1leHRlbmQxDQogICAzLiB6aC1MYXRuLUNOLXZhcmlhbnQxDQogICA0LiB6aC1MYXRuLUNODQog ICA1LiB6aC1MYXRuDQogICA2LiB6aA0KDQogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA4OiBF eGFtcGxlIG9mIFRhZyBUcnVuY2F0aW9uDQoNCg0KNC40ICBDYW5vbmljYWxpemF0aW9uIG9mIExh bmd1YWdlIFRhZ3MNCg0KICAgU2luY2UgYSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHRhZyBpcyBzb21l dGltZXMgdXNlZCBieSBtYW55IHByb2Nlc3NlcywNCiAgIGxhbmd1YWdlIHRhZ3MgU0hPVUxEIGFs d2F5cyBiZSBjcmVhdGVkIG9yIGdlbmVyYXRlZCBpbiBhIGNhbm9uaWNhbA0KICAgZm9ybS4NCg0K ICAgQSBsYW5ndWFnZSB0YWcgaXMgaW4gY2Fub25pY2FsIGZvcm0gd2hlbjoNCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAg ICAgW1BhZ2UgNDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQogICAxLiAgVGhlIHRhZyBpcyB3 ZWxsLWZvcm1lZCBhY2NvcmRpbmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gMi4xIGFuZA0KICAgICAg IFNlY3Rpb24gMi4yLg0KDQogICAyLiAgU3VidGFncyBvZiB0eXBlICdSZWdpb24nIHRoYXQgaGF2 ZSBhIFByZWZlcnJlZC1WYWx1ZSBtYXBwaW5nIGluDQogICAgICAgdGhlIElBTkEgcmVnaXN0cnkg KHNlZSBTZWN0aW9uIDMuMSkgU0hPVUxEIGJlIHJlcGxhY2VkIHdpdGggdGhlaXINCiAgICAgICBt YXBwZWQgdmFsdWUuICBOb3RlOiBJbiByYXJlIGNhc2VzIHRoZSBtYXBwZWQgdmFsdWUgd2lsbCBh bHNvDQogICAgICAgaGF2ZSBhIFByZWZlcnJlZC1WYWx1ZS4NCg0KICAgMy4gIFJlZHVuZGFudCBv ciBncmFuZGZhdGhlcmVkIHRhZ3MgdGhhdCBoYXZlIGEgUHJlZmVycmVkLVZhbHVlDQogICAgICAg bWFwcGluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4xKSBNVVNUIGJlIHJl cGxhY2VkDQogICAgICAgd2l0aCB0aGVpciBtYXBwZWQgdmFsdWUuICBUaGVzZSBpdGVtcyBhcmUg ZWl0aGVyIGRlcHJlY2F0ZWQNCiAgICAgICBtYXBwaW5ncyBjcmVhdGVkIGJlZm9yZSB0aGUgYWRv cHRpb24gb2YgdGhpcyBkb2N1bWVudCAoc3VjaCBhcw0KICAgICAgIHRoZSBtYXBwaW5nIG9mICJu by1ueW4iIHRvICJubiIgb3IgImkta2xpbmdvbiIgdG8gInRsaCIpIG9yIGFyZQ0KICAgICAgIHRo ZSByZXN1bHQgb2YgbGF0ZXIgcmVnaXN0cmF0aW9ucyBvciBhZGRpdGlvbnMgdG8gdGhpcyBkb2N1 bWVudA0KICAgICAgIChmb3IgZXhhbXBsZSwgInpoLWd1b3l1IiBtaWdodCBiZSBtYXBwZWQgdG8g YSBsYW5ndWFnZS1leHRsYW5nDQogICAgICAgY29tYmluYXRpb24gc3VjaCBhcyAiemgtY21uIiBi eSBzb21lIGZ1dHVyZSB1cGRhdGUgb2YgdGhpcw0KICAgICAgIGRvY3VtZW50KS4NCg0KICAgNC4g IE90aGVyIHN1YnRhZ3MgdGhhdCBoYXZlIGEgUHJlZmVycmVkLVZhbHVlIG1hcHBpbmcgaW4gdGhl IElBTkENCiAgICAgICByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4xKSBNVVNUIGJlIHJlcGxhY2Vk IHdpdGggdGhlaXIgbWFwcGVkDQogICAgICAgdmFsdWUuICBUaGVzZSBpdGVtcyBjb25zaXN0IGVu dGlyZWx5IG9mIGNsZXJpY2FsIGNvcnJlY3Rpb25zIHRvDQogICAgICAgSVNPIDYzOS0xIGluIHdo aWNoIHRoZSBkZXByZWNhdGVkIHN1YnRhZ3MgaGF2ZSBiZWVuIG1haW50YWluZWQNCiAgICAgICBm b3IgY29tcGF0aWJpbGl0eSBwdXJwb3Nlcy4NCg0KICAgNS4gIElmIG1vcmUgdGhhbiBvbmUgZXh0 ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZSBleGlzdHMsIHRoZSBleHRlbnNpb24NCiAgICAgICBzZXF1 ZW5jZXMgYXJlIG9yZGVyZWQgaW50byBjYXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVyIGJ5DQog ICAgICAgc2luZ2xldG9uIHN1YnRhZy4NCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAi ZW4tQS1hYWEtQi1jY2MtYmJiLXgteHl6IiBpcyBpbiBjYW5vbmljYWwNCiAgIGZvcm0sIHdoaWxl ICJlbi1CLWNjYy1iYmItQS1hYWEtWC14eXoiIGlzIHdlbGwtZm9ybWVkIGJ1dCBub3QgaW4NCiAg IGNhbm9uaWNhbCBmb3JtLg0KDQogICBFeGFtcGxlOiBUaGUgbGFuZ3VhZ2UgdGFnICJlbi1CVSIg KEVuZ2xpc2ggYXMgdXNlZCBpbiBCdXJtYSkgaXMgbm90DQogICBjYW5vbmljYWwgYmVjYXVzZSB0 aGUgJ0JVJyBzdWJ0YWcgaGFzIGEgY2Fub25pY2FsIG1hcHBpbmcgdG8gJ01NJw0KICAgKE15YW5t YXIpLCBhbHRob3VnaCB0aGUgdGFnICJlbi1CVSIgbWFpbnRhaW5zIGl0cyB2YWxpZGl0eS4NCg0K ICAgQ2Fub25pY2FsaXphdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGRvZXMgbm90IGltcGx5IGFueXRo aW5nIGFib3V0IHRoZQ0KICAgdXNlIG9mIHVwcGVyIG9yIGxvd2VyY2FzZSBsZXR0ZXJzIHdoZW4g cHJvY2Vzc2luZyBvciBjb21wYXJpbmcNCiAgIHN1YnRhZ3MgKGFuZCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAyLjEpLiAgQWxsIGNvbXBhcmlzb25zIE1VU1QgYmUNCiAgIHBlcmZvcm1lZCBpbiBh IGNhc2UtaW5zZW5zaXRpdmUgbWFubmVyLg0KDQogICBXaGVuIHBlcmZvcm1pbmcgY2Fub25pY2Fs aXphdGlvbiBvZiBsYW5ndWFnZSB0YWdzLCBwcm9jZXNzb3JzIE1BWQ0KICAgcmVndWxhcml6ZSB0 aGUgY2FzZSBvZiB0aGUgc3VidGFncyAodGhhdCBpcywgdGhpcyBwcm9jZXNzIGlzDQogICBPUFRJ T05BTCksIGZvbGxvd2luZyB0aGUgY2FzZSB1c2VkIGluIHRoZSByZWdpc3RyeS4gIE5vdGUgdGhh dCB0aGlzDQogICBjb3JyZXNwb25kcyB0byB0aGUgZm9sbG93aW5nIGNhc2luZyBydWxlczogdXBw ZXJjYXNlIGFsbCBub24taW5pdGlhbA0KICAgdHdvLWxldHRlciBzdWJ0YWdzOyB0aXRsZWNhc2Ug YWxsIG5vbi1pbml0aWFsIGZvdXItbGV0dGVyIHN1YnRhZ3M7DQogICBsb3dlcmNhc2UgZXZlcnl0 aGluZyBlbHNlLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA0M10NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0K DQoNCiAgIE5vdGU6IENhc2UgZm9sZGluZyBvZiBBU0NJSSBsZXR0ZXJzIGluIGNlcnRhaW4gbG9j YWxlcywgdW5sZXNzDQogICBjYXJlZnVsbHkgaGFuZGxlZCwgc29tZXRpbWVzIHByb2R1Y2VzIG5v bi1BU0NJSSBjaGFyYWN0ZXIgdmFsdWVzLg0KICAgVGhlIFVuaWNvZGUgQ2hhcmFjdGVyIERhdGFi YXNlIGZpbGUgIlNwZWNpYWxDYXNpbmcudHh0IiBkZWZpbmVzIHRoZQ0KICAgc3BlY2lmaWMgY2Fz ZXMgdGhhdCBhcmUga25vd24gdG8gY2F1c2UgcHJvYmxlbXMgd2l0aCB0aGlzLiAgSW4NCiAgIHBh cnRpY3VsYXIsIHRoZSBsZXR0ZXIgJ2knIChVKzAwNjkpIGluIFR1cmtpc2ggYW5kIEF6ZXJiYWlq YW5pIGlzDQogICB1cHBlcmNhc2VkIHRvIFUrMDEzMCAoTEFUSU4gQ0FQSVRBTCBMRVRURVIgSSBX SVRIIERPVCBBQk9WRSkuDQogICBJbXBsZW1lbnRlcnMgU0hPVUxEIHNwZWNpZnkgYSBsb2NhbGUt bmV1dHJhbCBjYXNpbmcgb3BlcmF0aW9uIHRvDQogICBlbnN1cmUgdGhhdCBjYXNlIGZvbGRpbmcg b2Ygc3VidGFncyBkb2VzIG5vdCBwcm9kdWNlIHRoaXMgdmFsdWUsDQogICB3aGljaCBpcyBpbGxl Z2FsIGluIGxhbmd1YWdlIHRhZ3MuICBGb3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8NCiAgIHVw cGVyY2FzZSB0aGUgcmVnaW9uIHN1YnRhZyAnaW4nIHVzaW5nIFR1cmtpc2ggbG9jYWxlIHJ1bGVz LCB0aGUNCiAgIHNlcXVlbmNlIFUrMDEzMCBVKzAwNEUgd291bGQgcmVzdWx0IGluc3RlYWQgb2Yg dGhlIGV4cGVjdGVkICdJTicuDQoNCiAgIE5vdGU6IGlmIHRoZSBmaWVsZCAnRGVwcmVjYXRlZCcg YXBwZWFycyBpbiBhIHJlZ2lzdHJ5IHJlY29yZCB3aXRob3V0DQogICBhbiBhY2NvbXBhbnlpbmcg J1ByZWZlcnJlZC1WYWx1ZScgZmllbGQsIHRoZW4gdGhhdCB0YWcgb3Igc3VidGFnIGlzDQogICBk ZXByZWNhdGVkIHdpdGhvdXQgYSByZXBsYWNlbWVudC4gIFZhbGlkYXRpbmcgcHJvY2Vzc29ycyBT SE9VTEQgTk9UDQogICBnZW5lcmF0ZSB0YWdzIHRoYXQgaW5jbHVkZSB0aGVzZSB2YWx1ZXMsIGFs dGhvdWdoIHRoZSB2YWx1ZXMgYXJlDQogICBjYW5vbmljYWwgd2hlbiB0aGV5IGFwcGVhciBpbiBh IGxhbmd1YWdlIHRhZy4NCg0KICAgQW4gZXh0ZW5zaW9uIE1VU1QgZGVmaW5lIGFueSByZWxhdGlv bnNoaXBzIHRoYXQgZXhpc3QgYmV0d2VlbiB0aGUNCiAgIHZhcmlvdXMgc3VidGFncyBpbiB0aGUg ZXh0ZW5zaW9uIGFuZCB0aHVzIE1BWSBkZWZpbmUgYW4gYWx0ZXJuYXRlDQogICBjYW5vbmljYWxp emF0aW9uIHNjaGVtZSBmb3IgdGhlIGV4dGVuc2lvbidzIHN1YnRhZ3MuICBFeHRlbnNpb25zIE1B WQ0KICAgZGVmaW5lIGhvdyB0aGUgb3JkZXIgb2YgdGhlIGV4dGVuc2lvbidzIHN1YnRhZ3MgYXJl IGludGVycHJldGVkLiAgRm9yDQogICBleGFtcGxlLCBhbiBleHRlbnNpb24gY291bGQgZGVmaW5l IHRoYXQgaXRzIHN1YnRhZ3MgYXJlIGluIGNhbm9uaWNhbA0KICAgb3JkZXIgd2hlbiB0aGUgc3Vi dGFncyBhcmUgcGxhY2VkIGludG8gQVNDSUkgb3JkZXI6IHRoYXQgaXMsICJlbi1hLQ0KICAgYWFh LWJiYi1jY2MiIGluc3RlYWQgb2YgImVuLWEtY2NjLWJiYi1hYWEiLiAgQW5vdGhlciBleHRlbnNp b24gbWlnaHQNCiAgIGRlZmluZSB0aGF0IHRoZSBvcmRlciBvZiB0aGUgc3VidGFncyBpbmZsdWVu Y2VzIHRoZWlyIHNlbWFudGljDQogICBtZWFuaW5nIChzbyB0aGF0ICJlbi1iLWNjYy1iYmItYWFh IiBoYXMgYSBkaWZmZXJlbnQgdmFsdWUgZnJvbSAiZW4tYi0NCiAgIGFhYS1iYmItY2NjIikuICBI b3dldmVyLCBleHRlbnNpb24gc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGJlIGRlc2lnbmVkDQogICBz byB0aGF0IHRoZXkgYXJlIHRvbGVyYW50IG9mIHRoZSB0eXBpY2FsIHByb2Nlc3NlcyBkZXNjcmli ZWQgaW4NCiAgIFNlY3Rpb24gMy42Lg0KDQo0LjUgIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRl IFVzZSBTdWJ0YWdzDQoNCiAgIFByaXZhdGUgdXNlIHN1YnRhZ3MsIGxpa2UgYWxsIG90aGVyIHN1 YnRhZ3MsIE1VU1QgY29uZm9ybSB0byB0aGUNCiAgIGZvcm1hdCBhbmQgY29udGVudCBjb25zdHJh aW50cyBpbiB0aGUgQUJORi4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgaGF2ZQ0KICAgbm8gbWVhbmlu ZyBvdXRzaWRlIHRoZSBwcml2YXRlIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBwYXJ0aWVzIHRoYXQN CiAgIGludGVuZCB0byB1c2Ugb3IgZXhjaGFuZ2UgbGFuZ3VhZ2UgdGFncyB0aGF0IGVtcGxveSB0 aGVtLiAgVGhlIHNhbWUNCiAgIHN1YnRhZ3MgTUFZIGJlIHVzZWQgd2l0aCBhIGRpZmZlcmVudCBt ZWFuaW5nIHVuZGVyIGEgc2VwYXJhdGUgcHJpdmF0ZQ0KICAgYWdyZWVtZW50LiAgVGhleSBTSE9V TEQgTk9UIGJlIHVzZWQgd2hlcmUgYWx0ZXJuYXRpdmVzIGV4aXN0IGFuZA0KICAgU0hPVUxEIE5P VCBiZSB1c2VkIGluIGNvbnRlbnQgb3IgcHJvdG9jb2xzIGludGVuZGVkIGZvciBnZW5lcmFsIHVz ZS4NCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFncyBhcmUgc2ltcGx5IHVzZWxlc3MgZm9yIGluZm9y bWF0aW9uIGV4Y2hhbmdlDQogICB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50LiAgVGhlIHZhbHVl IGFuZCBzZW1hbnRpYyBtZWFuaW5nIG9mIHByaXZhdGUNCiAgIHVzZSB0YWdzIGFuZCBvZiB0aGUg c3VidGFncyB1c2VkIHdpdGhpbiBzdWNoIGEgbGFuZ3VhZ2UgdGFnIGFyZSBub3QNCiAgIGRlZmlu ZWQgYnkgdGhpcyBkb2N1bWVudC4NCg0KICAgU3VidGFncyBkZWZpbmVkIGluIHRoZSBJQU5BIHJl Z2lzdHJ5IGFzIGhhdmluZyBhIHNwZWNpZmljIHByaXZhdGUgdXNlDQogICBtZWFuaW5nIGNvbnZl eSBtb3JlIGluZm9ybWF0aW9uIHRoYXQgYSBwdXJlbHkgcHJpdmF0ZSB1c2UgdGFnDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAg ICAgICBbUGFnZSA0NF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIHByZWZpeGVkIGJ5IHRo ZSBzaW5nbGV0b24gc3VidGFnICd4Jy4gIEZvciBhcHBsaWNhdGlvbnMgdGhpcw0KICAgYWRkaXRp b25hbCBpbmZvcm1hdGlvbiBNQVkgYmUgdXNlZnVsLg0KDQogICBGb3IgZXhhbXBsZSwgdGhlIHJl Z2lvbiBzdWJ0YWdzICdBQScsICdaWicgYW5kIGluIHRoZSByYW5nZXMNCiAgICdRTSctJ1FaJyBh bmQgJ1hBJy0nWFonIChkZXJpdmVkIGZyb20gSVNPIDMxNjYgcHJpdmF0ZSB1c2UgY29kZXMpIE1B WQ0KICAgYmUgdXNlZCB0byBmb3JtIGEgbGFuZ3VhZ2UgdGFnLiAgQSB0YWcgc3VjaCBhcyAiemgt SGFucy1YUSIgY29udmV5cyBhDQogICBncmVhdCBkZWFsIG9mIHB1YmxpYywgaW50ZXJjaGFuZ2Vh YmxlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBsYW5ndWFnZQ0KICAgbWF0ZXJpYWwgKHRoYXQgaXQg aXMgQ2hpbmVzZSBpbiB0aGUgc2ltcGxpZmllZCBDaGluZXNlIHNjcmlwdCBhbmQgaXMNCiAgIHN1 aXRhYmxlIGZvciBzb21lIGdlb2dyYXBoaWMgcmVnaW9uICdYUScpLiAgV2hpbGUgdGhlIHByZWNp c2UNCiAgIGdlb2dyYXBoaWMgcmVnaW9uIGlzIG5vdCBrbm93biBvdXRzaWRlIG9mIHByaXZhdGUg YWdyZWVtZW50LCB0aGUgdGFnDQogICBjb252ZXlzIGZhciBtb3JlIGluZm9ybWF0aW9uIHRoYW4g YW4gb3BhcXVlIHRhZyBzdWNoIGFzICJ4LXNvbWVMYW5nIiwNCiAgIHdoaWNoIGNvbnRhaW5zIG5v IGluZm9ybWF0aW9uIGFib3V0IHRoZSBsYW5ndWFnZSBzdWJ0YWcgb3Igc2NyaXB0DQogICBzdWJ0 YWcgb3V0c2lkZSBvZiB0aGUgcHJpdmF0ZSBhZ3JlZW1lbnQuDQoNCiAgIEhvd2V2ZXIsIGluIHNv bWUgY2FzZXMgY29udGVudCB0YWdnZWQgd2l0aCBwcml2YXRlIHVzZSBzdWJ0YWdzIE1BWQ0KICAg aW50ZXJhY3Qgd2l0aCBvdGhlciBzeXN0ZW1zIGluIGEgZGlmZmVyZW50IGFuZCBwb3NzaWJseSB1 bnN1aXRhYmxlDQogICBtYW5uZXIgY29tcGFyZWQgdG8gdGFncyB0aGF0IHVzZSBvcGFxdWUsIHBy aXZhdGVseSBkZWZpbmVkIHN1YnRhZ3MsDQogICBzbyB0aGUgY2hvaWNlIG9mIHRoZSBiZXN0IGFw cHJvYWNoIHNvbWV0aW1lcyBkZXBlbmRzIG9uIHRoZQ0KICAgcGFydGljdWxhciBkb21haW4gaW4g cXVlc3Rpb24uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgNDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0K DQo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIHNlY3Rpb24gZGVhbHMgd2l0aCB0 aGUgcHJvY2Vzc2VzIGFuZCByZXF1aXJlbWVudHMgbmVjZXNzYXJ5IGZvcg0KICAgSUFOQSB0byB1 bmRlcnRha2UgdG8gbWFpbnRhaW4gdGhlIHN1YnRhZyBhbmQgZXh0ZW5zaW9uIHJlZ2lzdHJpZXMg YXMNCiAgIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCBhbmQgaW4gYWNjb3JkYW5jZSB3aXRoIHRo ZSByZXF1aXJlbWVudHMgb2YNCiAgIFtSRkMyNDM0XS4NCg0KICAgVGhlIGltcGFjdCBvbiB0aGUg SUFOQSBtYWludGFpbmVycyBvZiB0aGUgdHdvIHJlZ2lzdHJpZXMgZGVmaW5lZCBieQ0KICAgdGhp cyBkb2N1bWVudCB3aWxsIGJlIGEgc21hbGwgaW5jcmVhc2UgaW4gdGhlIGZyZXF1ZW5jeSBvZiBu ZXcNCiAgIGVudHJpZXMgb3IgdXBkYXRlcy4NCg0KNS4xICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0 cnkNCg0KICAgVXBvbiBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50LCB0aGUgcmVnaXN0cnkgd2ls bCBiZSBpbml0aWFsaXplZCBieSBhDQogICBjb21wYW5pb24gZG9jdW1lbnQ6IFtpbml0aWFsLXJl Z2lzdHJ5XS4gIFRoZSBjcml0ZXJpYSBhbmQgcHJvY2VzcyBmb3INCiAgIHNlbGVjdGluZyB0aGUg aW5pdGlhbCBzZXQgb2YgcmVjb3JkcyBpcyBkZXNjcmliZWQgaW4gdGhhdCBkb2N1bWVudC4NCiAg IFRoZSBpbml0aWFsIHNldCBvZiByZWNvcmRzIHJlcHJlc2VudHMgbm8gaW1wYWN0IG9uIElBTkEs IHNpbmNlIHRoZQ0KICAgd29yayB0byBjcmVhdGUgaXQgd2lsbCBiZSBwZXJmb3JtZWQgZXh0ZXJu YWxseS4NCg0KICAgVGhlIG5ldyByZWdpc3RyeSBNVVNUIGJlIGxpc3RlZCB1bmRlciAiTGFuZ3Vh Z2UgVGFncyIgYXQNCiAgIDxodHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbD4sIHJlcGxh Y2luZyB0aGUgZXhpc3RpbmcNCiAgIHJlZ2lzdHJhdGlvbnMgZGVmaW5lZCBieSBbUkZDMzA2Nl0u ICBUaGUgZXhpc3Rpbmcgc2V0IG9mIHJlZ2lzdHJhdGlvbg0KICAgZm9ybXMgYW5kIFJGQyAzMDY2 IHJlZ2lzdHJhdGlvbnMgTVVTVCBiZSByZWxhYmVsZWQgYXMgIkxhbmd1YWdlIFRhZ3MNCiAgIChP YnNvbGV0ZSkiIGFuZCBtYWludGFpbmVkIChidXQgbm90IGFkZGVkIHRvIG9yIG1vZGlmaWVkKS4N Cg0KICAgRnV0dXJlIHdvcmsgb24gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBTSEFMTCBi ZSBsaW1pdGVkIHRvDQogICBpbnNlcnRpbmcgb3IgcmVwbGFjaW5nIHdob2xlIHJlY29yZHMgcHJl Zm9ybWF0dGVkIGZvciBJQU5BIGJ5IHRoZQ0KICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMiBvZiB0aGlzDQogICBkb2N1bWVudC4gIFRoaXMgc2lt cGxpZmllcyBJQU5BJ3Mgd29yayBieSBsaW1pdGluZyBpdCB0byBwbGFjaW5nIHRoZQ0KICAgdGV4 dCBpbiB0aGUgYXBwcm9wcmlhdGUgbG9jYXRpb24gaW4gdGhlIHJlZ2lzdHJ5Lg0KDQogICBFYWNo IHJlY29yZCBNVVNUIGJlIHNlbnQgdG8gaWFuYUBpYW5hLm9yZyB3aXRoIGEgc3ViamVjdCBsaW5l DQogICBpbmRpY2F0aW5nIHdoZXRoZXIgdGhlIGVuY2xvc2VkIHJlY29yZCBpcyBhbiBpbnNlcnRp b24gb2YgYSBuZXcNCiAgIHJlY29yZCAoaW5kaWNhdGVkIGJ5IHRoZSB3b3JkICJJTlNFUlQiIGlu IHRoZSBzdWJqZWN0IGxpbmUpIG9yIGENCiAgIHJlcGxhY2VtZW50IG9mIGFuIGV4aXN0aW5nIHJl Y29yZCAoaW5kaWNhdGVkIGJ5IHRoZSB3b3JkICJNT0RJRlkiIGluDQogICB0aGUgc3ViamVjdCBs aW5lKS4gIFJlY29yZHMgTVVTVCBOT1QgYmUgZGVsZXRlZCBmcm9tIHRoZSByZWdpc3RyeS4NCiAg IElBTkEgTVVTVCBwbGFjZSBhbnkgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgcmVjb3JkcyBpbnRvIHRo ZSBhcHByb3ByaWF0ZQ0KICAgc2VjdGlvbiBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5 LCBncm91cGluZyB0aGUgcmVjb3JkcyBieQ0KICAgdGhlaXIgJ1R5cGUnIGZpZWxkLiAgSW5zZXJ0 ZWQgcmVjb3JkcyBNQVkgYmUgcGxhY2VkIGFueXdoZXJlIGluIHRoZQ0KICAgYXBwcm9wcmlhdGUg c2VjdGlvbjsgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIG9mIHRoZSBvcmRlciBvZiB0aGUNCiAgIHJl Y29yZHMgYmV5b25kIGdyb3VwaW5nIHRoZW0gdG9nZXRoZXIgYnkgJ1R5cGUnLiAgTW9kaWZpZWQg cmVjb3Jkcw0KICAgTVVTVCBvdmVyd3JpdGUgdGhlIHJlY29yZCB0aGV5IHJlcGxhY2UuDQoNCiAg IEluY2x1ZGVkIGluIGFueSByZXF1ZXN0IHRvIGluc2VydCBvciBtb2RpZnkgcmVjb3JkcyBNVVNU IGJlIGEgbmV3DQogICBGaWxlLURhdGUgcmVjb3JkLiAgVGhpcyByZWNvcmQgTVVTVCBiZSBwbGFj ZWQgZmlyc3QgaW4gdGhlIHJlZ2lzdHJ5Lg0KICAgSW4gdGhlIGV2ZW50IHRoYXQgdGhlIEZpbGUt RGF0ZSByZWNvcmQgcHJlc2VudCBpbiB0aGUgcmVnaXN0cnkgaGFzIGENCiAgIGxhdGVyIGRhdGUg dGhlbiB0aGUgcmVjb3JkIGJlaW5nIGluc2VydGVkIG9yIG1vZGlmaWVkLCB0aGUgZXhpc3RpbmcN CiAgIHJlY29yZCBNVVNUIGJlIHByZXNlcnZlZC4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDQ2XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA1DQoNCg0KNS4yICBFeHRlbnNpb25zIFJlZ2lzdHJ5DQoNCiAgIFRoZSBM YW5ndWFnZSBUYWcgRXh0ZW5zaW9ucyByZWdpc3RyeSB3aWxsIGFsc28gYmUgZ2VuZXJhdGVkIGFu ZCBzZW50DQogICB0byBJQU5BIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNi4gIFRoaXMgcmVn aXN0cnkgY2FuIGNvbnRhaW4gYXQNCiAgIG1vc3QgMzUgcmVjb3JkcyBhbmQgdGh1cyBjaGFuZ2Vz IHRvIHRoaXMgcmVnaXN0cnkgYXJlIGV4cGVjdGVkIHRvIGJlDQogICB2ZXJ5IGluZnJlcXVlbnQu DQoNCiAgIEZ1dHVyZSB3b3JrIGJ5IElBTkEgb24gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25z IFJlZ2lzdHJ5IGlzDQogICBsaW1pdGVkIHRvIHR3byBjYXNlcy4gIEZpcnN0LCB0aGUgSUVTRyBN QVkgcmVxdWVzdCB0aGF0IG5ldyByZWNvcmRzDQogICBiZSBpbnNlcnRlZCBpbnRvIHRoaXMgcmVn aXN0cnkgZnJvbSB0aW1lIHRvIHRpbWUuICBUaGVzZSByZXF1ZXN0cw0KICAgTVVTVCBpbmNsdWRl IHRoZSByZWNvcmQgdG8gaW5zZXJ0IGluIHRoZSBleGFjdCBmb3JtYXQgZGVzY3JpYmVkIGluDQog ICBTZWN0aW9uIDMuNi4gIEluIGFkZGl0aW9uLCB0aGVyZSBNQVkgYmUgb2NjYXNpb25hbCByZXF1 ZXN0cyBmcm9tIHRoZQ0KICAgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGZvciBhIHNwZWNpZmljIGV4 dGVuc2lvbiB0byB1cGRhdGUgdGhlIGNvbnRhY3QNCiAgIGluZm9ybWF0aW9uIG9yIFVSTHMgaW4g dGhlIHJlY29yZC4gIFRoZXNlIHJlcXVlc3RzIE1VU1QgaW5jbHVkZSB0aGUNCiAgIGNvbXBsZXRl LCB1cGRhdGVkIHJlY29yZC4gIElBTkEgaXMgbm90IHJlc3BvbnNpYmxlIGZvciB2YWxpZGF0aW5n IHRoZQ0KICAgaW5mb3JtYXRpb24gcHJvdmlkZWQsIG9ubHkgdGhhdCBpdCBpcyBwcm9wZXJseSBm b3JtYXR0ZWQuICBJdCBzaG91bGQNCiAgIHJlYXNvbmFibHkgYmUgc2VlbiB0byBjb21lIGZyb20g dGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBuYW1lZCBpbg0KICAgdGhlIHJlY29yZCBwcmVzZW50 IGluIHRoZSByZWdpc3RyeS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGly ZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDQ3XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3Vz dCAyMDA1DQoNCg0KNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIExhbmd1YWdlIHRh Z3MgdXNlZCBpbiBjb250ZW50IG5lZ290aWF0aW9uLCBsaWtlIGFueSBvdGhlciBpbmZvcm1hdGlv bg0KICAgZXhjaGFuZ2VkIG9uIHRoZSBJbnRlcm5ldCwgbWlnaHQgYmUgYSBzb3VyY2Ugb2YgY29u Y2VybiBiZWNhdXNlIHRoZXkNCiAgIG1pZ2h0IGJlIHVzZWQgdG8gaW5mZXIgdGhlIG5hdGlvbmFs aXR5IG9mIHRoZSBzZW5kZXIsIGFuZCB0aHVzDQogICBpZGVudGlmeSBwb3RlbnRpYWwgdGFyZ2V0 cyBmb3Igc3VydmVpbGxhbmNlLg0KDQogICBUaGlzIGlzIGEgc3BlY2lhbCBjYXNlIG9mIHRoZSBn ZW5lcmFsIHByb2JsZW0gdGhhdCBhbnl0aGluZyBzZW50IGlzDQogICB2aXNpYmxlIHRvIHRoZSBy ZWNlaXZpbmcgcGFydHkgYW5kIHBvc3NpYmx5IHRvIHRoaXJkIHBhcnRpZXMgYXMgd2VsbC4NCiAg IEl0IGlzIHVzZWZ1bCB0byBiZSBhd2FyZSB0aGF0IHN1Y2ggY29uY2VybnMgY2FuIGV4aXN0IGlu IHNvbWUgY2FzZXMuDQoNCiAgIFRoZSBldmFsdWF0aW9uIG9mIHRoZSBleGFjdCBtYWduaXR1ZGUg b2YgdGhlIHRocmVhdCwgYW5kIGFueSBwb3NzaWJsZQ0KICAgY291bnRlcm1lYXN1cmVzLCBpcyBs ZWZ0IHRvIGVhY2ggYXBwbGljYXRpb24gcHJvdG9jb2wgKHNlZSBCQ1AgNzINCiAgIFtSRkMzNTUy XSBmb3IgYmVzdCBjdXJyZW50IHByYWN0aWNlIGd1aWRhbmNlIG9uIHNlY3VyaXR5IHRocmVhdHMg YW5kDQogICBkZWZlbnNlcykuDQoNCiAgIFRoZSBsYW5ndWFnZSB0YWcgYXNzb2NpYXRlZCB3aXRo IGEgcGFydGljdWxhciBpbmZvcm1hdGlvbiBpdGVtIGlzIG9mDQogICBubyBjb25zZXF1ZW5jZSB3 aGF0c29ldmVyIGluIGRldGVybWluaW5nIHdoZXRoZXIgdGhhdCBjb250ZW50IG1pZ2h0DQogICBj b250YWluIHBvc3NpYmxlIGhvbW9ncmFwaHMuICBUaGUgZmFjdCB0aGF0IGEgdGV4dCBpcyB0YWdn ZWQgYXMgYmVpbmcNCiAgIGluIG9uZSBsYW5ndWFnZSBvciB1c2luZyBhIHBhcnRpY3VsYXIgc2Ny aXB0IHN1YnRhZyBwcm92aWRlcyBubw0KICAgYXNzdXJhbmNlIHdoYXRzb2V2ZXIgdGhhdCBpdCBk b2VzIG5vdCBjb250YWluIGNoYXJhY3RlcnMgZnJvbSBzY3JpcHRzDQogICBvdGhlciB0aGFuIHRo ZSBvbmUocykgYXNzb2NpYXRlZCB3aXRoIG9yIHNwZWNpZmllZCBieSB0aGF0IGxhbmd1YWdlDQog ICB0YWcuDQoNCiAgIFNpbmNlIHRoZXJlIGlzIG5vIGxpbWl0IHRvIHRoZSBudW1iZXIgb2YgdmFy aWFudCwgcHJpdmF0ZSB1c2UsIGFuZA0KICAgZXh0ZW5zaW9uIHN1YnRhZ3MsIGFuZCBjb25zZXF1 ZW50bHkgbm8gbGltaXQgb24gdGhlIHBvc3NpYmxlIGxlbmd0aA0KICAgb2YgYSB0YWcsIGltcGxl bWVudGF0aW9ucyBuZWVkIHRvIGd1YXJkIGFnYWluc3QgYnVmZmVyIG92ZXJmbG93DQogICBhdHRh Y2tzLiAgU2VlIFNlY3Rpb24gNC4zIGZvciBkZXRhaWxzIG9uIGxhbmd1YWdlIHRhZyB0cnVuY2F0 aW9uLA0KICAgd2hpY2ggY2FuIG9jY3VyIGFzIGEgY29uc2VxdWVuY2Ugb2YgZGVmZW5zZXMgYWdh aW5zdCBidWZmZXIgb3ZlcmZsb3cuDQoNCiAgIEFsdGhvdWdoIHRoZSBzcGVjaWZpY2F0aW9uIG9m IHZhbGlkIHN1YnRhZ3MgZm9yIGFuIGV4dGVuc2lvbiAoc2VlOg0KICAgU2VjdGlvbiAzLjYpIE1V U1QgYmUgYXZhaWxhYmxlIG92ZXIgdGhlIEludGVybmV0LCBpbXBsZW1lbnRhdGlvbnMNCiAgIFNI T1VMRCBOT1QgbWVjaGFuaWNhbGx5IGRlcGVuZCBvbiBpdCBiZWluZyBhbHdheXMgYWNjZXNzaWJs ZSwgdG8NCiAgIHByZXZlbnQgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrcy4NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA0OF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAw NQ0KDQoNCjcuICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBzeW50YXgg aW4gdGhpcyBkb2N1bWVudCByZXF1aXJlcyB0aGF0IGxhbmd1YWdlIHRhZ3MgdXNlIG9ubHkgdGhl DQogICBjaGFyYWN0ZXJzIEEtWiwgYS16LCAwLTksIGFuZCBIWVBIRU4tTUlOVVMsIHdoaWNoIGFy ZSBwcmVzZW50IGluIG1vc3QNCiAgIGNoYXJhY3RlciBzZXRzLCBzbyB0aGUgY29tcG9zaXRpb24g b2YgbGFuZ3VhZ2UgdGFncyBzaG91bGQgbm90IGhhdmUNCiAgIGFueSBjaGFyYWN0ZXIgc2V0IGlz c3Vlcy4NCg0KICAgUmVuZGVyaW5nIG9mIGNoYXJhY3RlcnMgYmFzZWQgb24gdGhlIGNvbnRlbnQg b2YgYSBsYW5ndWFnZSB0YWcgaXMgbm90DQogICBhZGRyZXNzZWQgaW4gdGhpcyBtZW1vLiAgSGlz dG9yaWNhbGx5LCBzb21lIGxhbmd1YWdlcyBoYXZlIHJlbGllZCBvbg0KICAgdGhlIHVzZSBvZiBz cGVjaWZpYyBjaGFyYWN0ZXIgc2V0cyBvciBvdGhlciBpbmZvcm1hdGlvbiBpbiBvcmRlciB0bw0K ICAgaW5mZXIgaG93IGEgc3BlY2lmaWMgY2hhcmFjdGVyIHNob3VsZCBiZSByZW5kZXJlZCAobm90 YWJseSB0aGlzDQogICBhcHBsaWVzIHRvIGxhbmd1YWdlIGFuZCBjdWx0dXJlIHNwZWNpZmljIHZh cmlhdGlvbnMgb2YgSGFuIGlkZW9ncmFwaHMNCiAgIGFzIHVzZWQgaW4gSmFwYW5lc2UsIENoaW5l c2UsIGFuZCBLb3JlYW4pLiAgV2hlbiBsYW5ndWFnZSB0YWdzIGFyZQ0KICAgYXBwbGllZCB0byBz cGFucyBvZiB0ZXh0LCByZW5kZXJpbmcgZW5naW5lcyBzb21ldGltZXMgdXNlIHRoYXQNCiAgIGlu Zm9ybWF0aW9uIGluIGRlY2lkaW5nIHdoaWNoIGZvbnQgdG8gdXNlIGluIHRoZSBhYnNlbmNlIG9m IG90aGVyDQogICBpbmZvcm1hdGlvbiwgcGFydGljdWxhcmx5IHdoZXJlIGxhbmd1YWdlcyB3aXRo IGRpc3RpbmN0IHdyaXRpbmcNCiAgIHRyYWRpdGlvbnMgdXNlIHRoZSBzYW1lIGNoYXJhY3RlcnMu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgs IDIwMDYgICAgICAgICAgICAgIFtQYWdlIDQ5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KOC4g IENoYW5nZXMgZnJvbSBSRkMgMzA2Ng0KDQogICBUaGUgbWFpbiBnb2FscyBmb3IgdGhpcyByZXZp c2lvbiBvZiBsYW5ndWFnZSB0YWdzIHdlcmUgdGhlIGZvbGxvd2luZzoNCg0KICAgKkNvbXBhdGli aWxpdHkuKiBBbGwgUkZDIDMwNjYgbGFuZ3VhZ2UgdGFncyAgKGluY2x1ZGluZyB0aG9zZSBpbiB0 aGUNCiAgIElBTkEgcmVnaXN0cnkpICByZW1haW4gdmFsaWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9u LiAgVGhlIGNoYW5nZXMgaW4NCiAgIHRoaXMgZG9jdW1lbnQgcmVwcmVzZW50IGFkZGl0aW9uYWwg Y29uc3RyYWludHMgb24gbGFuZ3VhZ2UgdGFncy4NCiAgIFRoYXQgaXMsIGluIG5vIGNhc2UgaXMg dGhlIHN5bnRheCBtb3JlIHBlcm1pc3NpdmUgYW5kIHByb2Nlc3NvcnMNCiAgIGJhc2VkIG9uIHRo ZSBBQk5GIGFuZCBvdGhlciBwcm92aXNpb25zIG9mIFJGQyAzMDY2IChzdWNoIGFzIHRob3NlDQog ICBkZXNjcmliZWQgaW4gW1hNTFNjaGVtYV0pIHdpbGwgYmUgYWJsZSB0byBwcm9jZXNzIHRoZSB0 YWdzIGRlc2NyaWJlZA0KICAgYnkgdGhpcyBkb2N1bWVudC4gIEluIGFkZGl0aW9uLCB0aGlzIGRv Y3VtZW50IGRlZmluZXMgbGFuZ3VhZ2UgdGFncw0KICAgaW4gc3VjaCBhcyB3YXkgYXMgdG8gZW5z dXJlIGZ1dHVyZSBjb21wYXRpYmlsaXR5Lg0KDQogICAqU3RhYmlsaXR5LiogQmVjYXVzZSBvZiBj aGFuZ2VzIGluIHRoZSBwYXN0IGluIHRoZSB1bmRlcmx5aW5nIElTTw0KICAgc3RhbmRhcmRzLCBh IHZhbGlkIFJGQyAzMDY2IGxhbmd1YWdlIHRhZyBjb3VsZCBiZWNvbWUgaW52YWxpZCBvciBoYXZl DQogICBpdHMgbWVhbmluZyBjaGFuZ2UuICBUaGlzIGhhcyB0aGUgcG90ZW50aWFsIG9mIGludmFs aWRhdGluZyBjb250ZW50DQogICB0aGF0IG1heSBoYXZlIGFuIGV4dGVuc2l2ZSBzaGVsZi1saWZl LiAgSW4gdGhpcyBzcGVjaWZpY2F0aW9uLCBvbmNlIGENCiAgIGxhbmd1YWdlIHRhZyBpcyB2YWxp ZCwgaXQgcmVtYWlucyB2YWxpZCBmb3JldmVyLg0KDQogICAqVmFsaWRpdHkuKiAgVGhlIHN0cnVj dHVyZSBvZiBsYW5ndWFnZSB0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudA0KICAgbWFrZXMg aXQgcG9zc2libGUgdG8gZGV0ZXJtaW5lIGlmIGEgcGFydGljdWxhciB0YWcgaXMgd2VsbC1mb3Jt ZWQNCiAgIHdpdGhvdXQgcmVnYXJkIGZvciB0aGUgYWN0dWFsIGNvbnRlbnQgb3IgIm1lYW5pbmci IG9mIHRoZSB0YWcgYXMgYQ0KICAgd2hvbGUuICBUaGlzIGlzIGltcG9ydGFudCBiZWNhdXNlIHRo ZSByZWdpc3RyeSBncm93cyBhbmQgdW5kZXJseWluZw0KICAgc3RhbmRhcmRzIGNoYW5nZSBvdmVy IHRpbWUuICBJbiBhZGRpdGlvbiwgaXQgbXVzdCBiZSBwb3NzaWJsZSB0bw0KICAgZGV0ZXJtaW5l IGlmIGEgdGFnIGlzIHZhbGlkIChvciBub3QpIGZvciBhIGdpdmVuIHBvaW50IGluIHRpbWUgaW4N CiAgIG9yZGVyIHRvIHByb3ZpZGUgcmVwcm9kdWNpYmxlLCB0ZXN0YWJsZSByZXN1bHRzLiAgVGhp cyBwcm9jZXNzIG11c3QNCiAgIG5vdCBiZSBlcnJvci1wcm9uZTsgb3RoZXJ3aXNlIGltcGxlbWVu dGF0aW9ucyBtaWdodCBnaXZlIGRpZmZlcmVudA0KICAgcmVzdWx0cy4gIEJ5IGhhdmluZyBhbiBh dXRob3JpdGF0aXZlIHJlZ2lzdHJ5IHdpdGggc3BlY2lmaWMNCiAgIHZlcnNpb25pbmcgaW5mb3Jt YXRpb24sIHRoZSB2YWxpZGl0eSBvZiBsYW5ndWFnZSB0YWdzIGF0IGFueSBwb2ludCBpbg0KICAg dGltZSBjYW4gYmUgcHJlY2lzZWx5IGRldGVybWluZWQgKGluc3RlYWQgb2YgaW50ZXJwb2xhdGlu ZyB2YWx1ZXMNCiAgIGZyb20gbWFueSBzZXBhcmF0ZSBzb3VyY2VzKS4NCg0KICAgKlV0aWxpdHku KiBJdCBpcyBzb21ldGltZXMgaW1wb3J0YW50IHRvIGJlIGFibGUgdG8gZGlmZmVyZW50aWF0ZQ0K ICAgYmV0d2VlbiB3cml0dGVuIGZvcm1zIG9mIGEgbGFuZ3VhZ2UgLS0gZm9yIG1hbnkgaW1wbGVt ZW50YXRpb25zIHRoaXMNCiAgIGlzIG1vcmUgaW1wb3J0YW50IHRoYW4gZGlzdGluZ3Vpc2hpbmcg YmV0d2VlbiB0aGUgc3Bva2VuIHZhcmlhbnRzIG9mDQogICBhIGxhbmd1YWdlLiAgTGFuZ3VhZ2Vz IGFyZSB3cml0dGVuIGluIGEgd2lkZSB2YXJpZXR5IG9mIGRpZmZlcmVudA0KICAgc2NyaXB0cywg c28gdGhpcyBkb2N1bWVudCBwcm92aWRlcyBmb3IgdGhlIGdlbmVyYXRpdmUgdXNlIG9mIElTTw0K ICAgMTU5MjQgc2NyaXB0IGNvZGVzLiAgTGlrZSB0aGUgZ2VuZXJhdGl2ZSB1c2Ugb2YgSVNPIGxh bmd1YWdlIGFuZA0KICAgY291bnRyeSBjb2RlcyBpbiBSRkMgMzA2NiwgdGhpcyBhbGxvd3MgY29t YmluYXRpb25zIHRvIGJlIHByb2R1Y2VkDQogICB3aXRob3V0IHJlc29ydGluZyB0byB0aGUgcmVn aXN0cmF0aW9uIHByb2Nlc3MuICBUaGUgYWRkaXRpb24gb2YgVU4NCiAgIE0uNDkgY29kZXMgcHJv dmlkZXMgZm9yIHRoZSBnZW5lcmF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgd2l0aCByZWdpb25hbA0K ICAgc2NvcGUsIHdoaWNoIGlzIGFsc28gcmVxdWlyZWQgYnkgc29tZSBhcHBsaWNhdGlvbnMuDQoN CiAgIFRoZSByZWNhc3Qgb2YgdGhlIHJlZ2lzdHJ5IGZyb20gY29udGFpbmluZyB3aG9sZSBsYW5n dWFnZSB0YWdzIHRvDQogICBzdWJ0YWdzIGlzIGEga2V5IHBhcnQgb2YgdGhpcy4gIEFuIGltcG9y dGFudCBmZWF0dXJlIG9mIFJGQyAzMDY2IHdhcw0KICAgdGhhdCBpdCBhbGxvd2VkIGdlbmVyYXRp dmUgdXNlIG9mIHN1YnRhZ3MuICBUaGlzIGFsbG93cyBwZW9wbGUgdG8NCiAgIG1lYW5pbmdmdWxs eSB1c2UgZ2VuZXJhdGVkIHRhZ3MsIHdpdGhvdXQgdGhlIGRlbGF5cyBpbiByZWdpc3RlcmluZw0K ICAgd2hvbGUgdGFncyBvciB0aGUgbmVlZCB0byByZWdpc3RlciBhbGwgb2YgdGhlIGNvbWJpbmF0 aW9ucyB0aGF0IG1pZ2h0DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA1MF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAw NQ0KDQoNCiAgIGJlIHVzZWZ1bC4NCg0KICAgVGhlIGNob2ljZSBvZiBwbGFjaW5nIHRoZSBleHRl bmRlZCBsYW5ndWFnZSBhbmQgc2NyaXB0IHN1YnRhZ3MNCiAgIGJldHdlZW4gdGhlIHByaW1hcnkg bGFuZ3VhZ2UgYW5kIHJlZ2lvbiBzdWJ0YWdzIHdhcyB3aWRlbHkgZGViYXRlZC4NCiAgIFRoaXMg ZGVzaWduIHdhcyBjaG9zZW4gYmVjYXVzZSB0aGUgcHJldmFsZW50IG1hdGNoaW5nIGFuZCBjb250 ZW50DQogICBuZWdvdGlhdGlvbiBzY2hlbWVzIHJlbHkgb24gdGhlIHN1YnRhZ3MgYmVpbmcgYXJy YW5nZWQgaW4gb3JkZXIgb2YNCiAgIGluY3JlYXNpbmcgc3BlY2lmaWNpdHkuICBUaGF0IGlzLCB0 aGUgc3VidGFncyB0aGF0IG1hcmsgYSBncmVhdGVyDQogICBiYXJyaWVyIHRvIG11dHVhbCBpbnRl bGxpZ2liaWxpdHkgYXBwZWFyIGxlZnQtbW9zdCBpbiBhIHRhZy4gIEZvcg0KICAgZXhhbXBsZSwg d2hlbiBzZWxlY3RpbmcgY29udGVudCB3cml0dGVuIGluIEF6ZXJiYWlqYW5pLCB0aGUgc2NyaXB0 DQogICAoQXJhYmljLCBDeXJpbGxpYywgb3IgTGF0aW4pIHJlcHJlc2VudHMgYSBncmVhdGVyIGJh cnJpZXIgdG8NCiAgIHVuZGVyc3RhbmRpbmcgdGhhbiBhbnkgcmVnaW9uYWwgdmFyaWF0aW9ucyAo dGhvc2UgYXNzb2NpYXRlZCB3aXRoDQogICBBemVyYmFpamFuIG9yIElyYW4sIGZvciBleGFtcGxl KS4gIEluZGl2aWR1YWxzIHdobyBwcmVmZXIgZG9jdW1lbnRzDQogICBpbiBhIHBhcnRpY3VsYXIg c2NyaXB0LCBidXQgY2FuIGRlYWwgd2l0aCB0aGUgbWlub3IgcmVnaW9uYWwNCiAgIGRpZmZlcmVu Y2VzLCBjYW4gdGhlcmVmb3JlIHNlbGVjdCBhcHByb3ByaWF0ZSBjb250ZW50LiAgQXBwbGljYXRp b25zDQogICB0aGF0IGRvIG5vdCBkZWFsIHdpdGggd3JpdHRlbiBjb250ZW50IHdpbGwgY29udGlu dWUgdG8gb21pdCB0aGVzZQ0KICAgc3VidGFncy4NCg0KICAgKkV4dGVuc2liaWxpdHkuKiBCZWNh dXNlIG9mIHRoZSB3aWRlc3ByZWFkIHVzZSBvZiBsYW5ndWFnZSB0YWdzLCBpdA0KICAgaXMgZGlz cnVwdGl2ZSB0byBoYXZlIHBlcmlvZGljIHJldmlzaW9ucyBvZiB0aGUgY29yZSBzcGVjaWZpY2F0 aW9uLA0KICAgZXZlbiBpbiB0aGUgZmFjZSBvZiBkZW1vbnN0cmF0ZWQgbmVlZC4gIFRoZSBleHRl bnNpb24gbWVjaGFuaXNtDQogICBwcm92aWRlcyBmb3IgYSB3YXkgZm9yIGluZGVwZW5kZW50IFJG Q3MgdG8gZGVmaW5lIGV4dGVuc2lvbnMgdG8NCiAgIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBleHRl bnNpb25zIGhhdmUgYSB2ZXJ5IGNvbnN0cmFpbmVkLCB3ZWxsLQ0KICAgZGVmaW5lZCBzdHJ1Y3R1 cmUgdGhhdCBwcmV2ZW50IGV4dGVuc2lvbnMgZnJvbSBpbnRlcmZlcmluZyB3aXRoDQogICBpbXBs ZW1lbnRhdGlvbnMgb2YgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuDQoN CiAgIFRoZSBkb2N1bWVudCBhbHNvIGFudGljaXBhdGVzIGZlYXR1cmVzIG9mIElTTyA2MzktMyB3 aXRoIHRoZSBhZGRpdGlvbg0KICAgb2YgdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MsIGFz IHdlbGwgYXMgdGhlIHBvc3NpYmlsaXR5IG9mIG90aGVyDQogICBJU08gNjM5IHBhcnRzIGJlY29t aW5nIHVzZWZ1bCBmb3IgdGhlIGZvcm1hdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGluDQogICB0aGUg ZnV0dXJlLg0KDQogICBUaGUgdXNlIGFuZCBkZWZpbml0aW9uIG9mIHByaXZhdGUgdXNlIHRhZ3Mg aGFzIGFsc28gYmVlbiBtb2RpZmllZCwgdG8NCiAgIGFsbG93IHBlb3BsZSB0byB1c2UgcHJpdmF0 ZSB1c2Ugc3VidGFncyB0byBleHRlbmQgb3IgbW9kaWZ5IGRlZmluZWQNCiAgIHRhZ3MgYW5kIHRv IG1vdmUgYXMgbXVjaCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSBvdXQgb2YgcHJpdmF0ZSB1c2UN CiAgIGFuZCBpbnRvIHRoZSByZWd1bGFyIHN0cnVjdHVyZS4NCg0KICAgVGhlIGdvYWwgZm9yIGVh Y2ggb2YgdGhlc2UgbW9kaWZpY2F0aW9ucyBpcyB0byByZWR1Y2Ugb3IgZWxpbWluYXRlDQogICB0 aGUgbmVlZCBmb3IgZnV0dXJlIHJldmlzaW9ucyBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBUaGUg c3BlY2lmaWMgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50IHRvIG1lZXQgdGhlc2UgZ29hbHMgYXJl Og0KDQogICBvICBEZWZpbmVzIHRoZSBBQk5GIGFuZCBydWxlcyBmb3Igc3VidGFncyBzbyB0aGF0 IHRoZSBjYXRlZ29yeSBvZiBhbGwNCiAgICAgIHN1YnRhZ3MgY2FuIGJlIGRldGVybWluZWQgd2l0 aG91dCByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5Lg0KDQogICBvICBBZGRzIHRoZSBjb25jZXB0 IG9mIHdlbGwtZm9ybWVkIHZzLiB2YWxpZGF0aW5nIHByb2Nlc3NvcnMsDQogICAgICBkZWZpbmlu ZyB0aGUgcnVsZXMgYnkgd2hpY2ggYW4gaW1wbGVtZW50YXRpb24gY2FuIGNsYWltIHRvIGJlIG9u ZQ0KICAgICAgb3IgdGhlIG90aGVyLg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDUxXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg IEF1Z3VzdCAyMDA1DQoNCg0KICAgbyAgUmVwbGFjZXMgdGhlIElBTkEgbGFuZ3VhZ2UgdGFnIHJl Z2lzdHJ5IHdpdGggYSBsYW5ndWFnZSBzdWJ0YWcNCiAgICAgIHJlZ2lzdHJ5IHRoYXQgcHJvdmlk ZXMgYSBjb21wbGV0ZSBsaXN0IG9mIHZhbGlkIHN1YnRhZ3MgaW4gdGhlDQogICAgICBJQU5BIHJl Z2lzdHJ5LiAgVGhpcyBhbGxvd3MgZm9yIHJvYnVzdCBpbXBsZW1lbnRhdGlvbiBhbmQgZWFzZSBv Zg0KICAgICAgbWFpbnRlbmFuY2UuICBUaGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5IGJlY29t ZXMgdGhlIGNhbm9uaWNhbA0KICAgICAgc291cmNlIGZvciBmb3JtaW5nIGxhbmd1YWdlIHRhZ3Mu DQoNCiAgIG8gIFByb3ZpZGVzIGEgcHJvY2VzcyB0aGF0IGd1YXJhbnRlZXMgc3RhYmlsaXR5IG9m IGxhbmd1YWdlIHRhZ3MsIGJ5DQogICAgICBoYW5kbGluZyByZXVzZSBvZiB2YWx1ZXMgYnkgSVNP IDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYgaW4NCiAgICAgIHRoZSBldmVudCB0aGF0IHRo ZXkgcmVnaXN0ZXIgYSBwcmV2aW91c2x5IHVzZWQgdmFsdWUgZm9yIGEgbmV3DQogICAgICBwdXJw b3NlLg0KDQogICBvICBBbGxvd3MgSVNPIDE1OTI0IHNjcmlwdCBjb2RlIHN1YnRhZ3MgYW5kIGFs bG93cyB0aGVtIHRvIGJlIHVzZWQNCiAgICAgIGdlbmVyYXRpdmVseS4gIERlZmluZXMgYSBtZXRo b2QgZm9yIGluZGljYXRpbmcgaW4gdGhlIHJlZ2lzdHJ5DQogICAgICB3aGVuIHNjcmlwdCBzdWJ0 YWdzIGFyZSBuZWNlc3NhcnkgZm9yIGEgZ2l2ZW4gbGFuZ3VhZ2UgdGFnLg0KDQogICBvICBBZGRz IHRoZSBjb25jZXB0IG9mIGEgdmFyaWFudCBzdWJ0YWcgYW5kIGFsbG93cyB2YXJpYW50cyB0byBi ZQ0KICAgICAgdXNlZCBnZW5lcmF0aXZlbHkuDQoNCiAgIG8gIEFkZHMgdGhlIGFiaWxpdHkgdG8g dXNlIGEgY2xhc3Mgb2YgVU4gTS40OSB0YWdzIGZvciBzdXByYS1uYXRpb25hbA0KICAgICAgcmVn aW9ucyBhbmQgdG8gcmVzb2x2ZSBjb25mbGljdHMgaW4gdGhlIGFzc2lnbm1lbnQgb2YgSVNPIDMx NjYNCiAgICAgIGNvZGVzLg0KDQogICBvICBEZWZpbmVzIHRoZSBwcml2YXRlIHVzZSB0YWdzIGlu IElTTyA2MzksIElTTyAxNTkyNCwgYW5kIElTTyAzMTY2DQogICAgICBhcyB0aGUgbWVjaGFuaXNt IGZvciBjcmVhdGluZyBwcml2YXRlIHVzZSBsYW5ndWFnZSwgc2NyaXB0LCBhbmQNCiAgICAgIHJl Z2lvbiBzdWJ0YWdzIHJlc3BlY3RpdmVseS4NCg0KICAgbyAgQWRkcyBhIHdlbGwtZGVmaW5lZCBl eHRlbnNpb24gbWVjaGFuaXNtLg0KDQogICBvICBEZWZpbmVzIGFuIGV4dGVuZGVkIGxhbmd1YWdl IHN1YnRhZywgcG9zc2libHkgZm9yIHVzZSB3aXRoIGNlcnRhaW4NCiAgICAgIGFudGljaXBhdGVk IGZlYXR1cmVzIG9mIElTTyA2MzktMy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIw MDYgICAgICAgICAgICAgIFtQYWdlIDUyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KOS4gIFJl ZmVyZW5jZXMNCg0KOS4xICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbSVNPMTA2NDZdDQog ICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRp b24sICJJU08vSUVDDQogICAgICAgICAgICAgIDEwNjQ2OjIwMDMuIEluZm9ybWF0aW9uIHRlY2hu b2xvZ3kgLS0gVW5pdmVyc2FsIE11bHRpcGxlLQ0KICAgICAgICAgICAgICBPY3RldCBDb2RlZCBD aGFyYWN0ZXIgU2V0IChVQ1MpIiwgMjAwMy4NCg0KICAgW0lTTzE1OTI0XQ0KICAgICAgICAgICAg ICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPDQog ICAgICAgICAgICAgIDE1OTI0OjIwMDQuIEluZm9ybWF0aW9uIGFuZCBkb2N1bWVudGF0aW9uIC0t IENvZGVzIGZvciB0aGUNCiAgICAgICAgICAgICAgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2Yg c2NyaXB0cyIsIEphbnVhcnkgMjAwNC4NCg0KICAgW0lTTzMxNjYtMV0NCiAgICAgICAgICAgICAg SW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyAzMTY2 LQ0KICAgICAgICAgICAgICAxOjE5OTcuIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2Yg bmFtZXMgb2YgY291bnRyaWVzDQogICAgICAgICAgICAgIGFuZCB0aGVpciBzdWJkaXZpc2lvbnMg LS0gUGFydCAxOiBDb3VudHJ5IGNvZGVzIiwgMTk5Ny4NCg0KICAgW0lTTzYzOS0xXQ0KICAgICAg ICAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAi SVNPIDYzOS0NCiAgICAgICAgICAgICAgMToyMDAyLiBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0 aW9uIG9mIG5hbWVzIG9mIGxhbmd1YWdlcw0KICAgICAgICAgICAgICAtLSBQYXJ0IDE6IEFscGhh LTIgY29kZSIsIDIwMDIuDQoNCiAgIFtJU082MzktMl0NCiAgICAgICAgICAgICAgSW50ZXJuYXRp b25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyA2MzktDQogICAgICAg ICAgICAgIDI6MTk5OC4gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBs YW5ndWFnZXMNCiAgICAgICAgICAgICAgLS0gUGFydCAyOiBBbHBoYS0zIGNvZGUsIGZpcnN0IGVk aXRpb24iLCAxOTk4Lg0KDQogICBbSVNPNjQ2XSAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9u IGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08vSUVDDQogICAgICAgICAgICAgIDY0NjoxOTkxLCBJ bmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0tIElTTyA3LWJpdCBjb2RlZA0KICAgICAgICAgICAgICBj aGFyYWN0ZXIgc2V0IGZvciBpbmZvcm1hdGlvbiBpbnRlcmNoYW5nZS4iLCAxOTkxLg0KDQogICBb UkZDMjAyNl0gIEJyYWRuZXIsIFMuLCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0t IFJldmlzaW9uDQogICAgICAgICAgICAgIDMiLCBCQ1AgOSwgUkZDIDIwMjYsIE9jdG9iZXIgMTk5 Ni4NCg0KICAgW1JGQzIwMjhdICBIb3ZleSwgUi4gYW5kIFMuIEJyYWRuZXIsICJUaGUgT3JnYW5p emF0aW9ucyBJbnZvbHZlZCBpbg0KICAgICAgICAgICAgICB0aGUgSUVURiBTdGFuZGFyZHMgUHJv Y2VzcyIsIEJDUCAxMSwgUkZDIDIwMjgsDQogICAgICAgICAgICAgIE9jdG9iZXIgMTk5Ni4NCg0K ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8g SW5kaWNhdGUNCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMg MjExOSwgTWFyY2ggMTk5Ny4NCg0KICAgW1JGQzIyMzRiaXNdDQogICAgICAgICAgICAgIENyb2Nr ZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3ludGF4DQogICAgICAg ICAgICAgIFNwZWNpZmljYXRpb25zOiBBQk5GIiwgZHJhZnQtY3JvY2tlci1hYm5mLXJmYzIyMzRi aXMtMDANCiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDA1Lg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA2ICAg ICAgICAgICAgICBbUGFnZSA1M10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCiAgIFtSRkMyNDM0 XSAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcg YW4NCiAgICAgICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBC Q1AgMjYsIFJGQyAyNDM0LA0KICAgICAgICAgICAgICBPY3RvYmVyIDE5OTguDQoNCiAgIFtSRkMy ODYwXSAgQ2FycGVudGVyLCBCLiwgQmFrZXIsIEYuLCBhbmQgTS4gUm9iZXJ0cywgIk1lbW9yYW5k dW0gb2YNCiAgICAgICAgICAgICAgVW5kZXJzdGFuZGluZyBDb25jZXJuaW5nIHRoZSBUZWNobmlj YWwgV29yayBvZiB0aGUNCiAgICAgICAgICAgICAgSW50ZXJuZXQgQXNzaWduZWQgTnVtYmVycyBB dXRob3JpdHkiLCBSRkMgMjg2MCwgSnVuZSAyMDAwLg0KDQogICBbUkZDMzMzOV0gIEtseW5lLCBH LiBhbmQgQy4gTmV3bWFuLCAiRGF0ZSBhbmQgVGltZSBvbiB0aGUgSW50ZXJuZXQ6DQogICAgICAg ICAgICAgIFRpbWVzdGFtcHMiLCBSRkMgMzMzOSwgSnVseSAyMDAyLg0KDQogICBbVU5fTS40OV0g IFN0YXRpc3RpY3MgRGl2aXNpb24sIFVuaXRlZCBOYXRpb25zLCAiU3RhbmRhcmQgQ291bnRyeSBv cg0KICAgICAgICAgICAgICBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UiLCBVTiBTdGFu ZGFyZCBDb3VudHJ5IG9yDQogICAgICAgICAgICAgIEFyZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2Fs IFVzZSwgUmV2aXNpb24gNCAoVW5pdGVkIE5hdGlvbnMNCiAgICAgICAgICAgICAgcHVibGljYXRp b24sIFNhbGVzIE5vLiA5OC5YVklJLjksIEp1bmUgMTk5OS4NCg0KOS4yICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzDQoNCiAgIFtSRkMxNzY2XSAgQWx2ZXN0cmFuZCwgSC4sICJUYWdzIGZvciB0aGUg SWRlbnRpZmljYXRpb24gb2YNCiAgICAgICAgICAgICAgTGFuZ3VhZ2VzIiwgUkZDIDE3NjYsIE1h cmNoIDE5OTUuDQoNCiAgIFtSRkMyMDQ3XSAgTW9vcmUsIEsuLCAiTUlNRSAoTXVsdGlwdXJwb3Nl IEludGVybmV0IE1haWwgRXh0ZW5zaW9ucykNCiAgICAgICAgICAgICAgUGFydCBUaHJlZTogTWVz c2FnZSBIZWFkZXIgRXh0ZW5zaW9ucyBmb3IgTm9uLUFTQ0lJIFRleHQiLA0KICAgICAgICAgICAg ICBSRkMgMjA0NywgTm92ZW1iZXIgMTk5Ni4NCg0KICAgW1JGQzIyMzFdICBGcmVlZCwgTi4gYW5k IEsuIE1vb3JlLCAiTUlNRSBQYXJhbWV0ZXIgVmFsdWUgYW5kIEVuY29kZWQNCiAgICAgICAgICAg ICAgV29yZCBFeHRlbnNpb25zOiBDaGFyYWN0ZXIgU2V0cywgTGFuZ3VhZ2VzLCBhbmQNCiAgICAg ICAgICAgICAgQ29udGludWF0aW9ucyIsIFJGQyAyMjMxLCBOb3ZlbWJlciAxOTk3Lg0KDQogICBb UkZDMjc4MV0gIEhvZmZtYW4sIFAuIGFuZCBGLiBZZXJnZWF1LCAiVVRGLTE2LCBhbiBlbmNvZGlu ZyBvZiBJU08NCiAgICAgICAgICAgICAgMTA2NDYiLCBSRkMgMjc4MSwgRmVicnVhcnkgMjAwMC4N Cg0KICAgW1JGQzMwNjZdICBBbHZlc3RyYW5kLCBILiwgIlRhZ3MgZm9yIHRoZSBJZGVudGlmaWNh dGlvbiBvZg0KICAgICAgICAgICAgICBMYW5ndWFnZXMiLCBCQ1AgNDcsIFJGQyAzMDY2LCBKYW51 YXJ5IDIwMDEuDQoNCiAgIFtSRkMzNTUyXSAgUmVzY29ybGEsIEUuIGFuZCBCLiBLb3J2ZXIsICJH dWlkZWxpbmVzIGZvciBXcml0aW5nIFJGQw0KICAgICAgICAgICAgICBUZXh0IG9uIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIiwgQkNQIDcyLCBSRkMgMzU1MiwNCiAgICAgICAgICAgICAgSnVseSAy MDAzLg0KDQogICBbVW5pY29kZV0gIFVuaWNvZGUgQ29uc29ydGl1bSwgIlRoZSBVbmljb2RlIENv bnNvcnRpdW0uIFRoZSBVbmljb2RlDQogICAgICAgICAgICAgIFN0YW5kYXJkLCBWZXJzaW9uIDQu MS4wLCBkZWZpbmVkIGJ5OiBUaGUgVW5pY29kZSBTdGFuZGFyZCwNCiAgICAgICAgICAgICAgVmVy c2lvbiA0LjAgKEJvc3RvbiwgTUEsIEFkZGlzb24tV2VzbGV5LCAyMDAzLiBJU0JOIDAtMzIxLQ0K ICAgICAgICAgICAgICAxODU3OC0xKSwgYXMgYW1lbmRlZCBieSBVbmljb2RlIDQuMC4xDQogICAg ICAgICAgICAgIChodHRwOi8vd3d3LnVuaWNvZGUub3JnL3ZlcnNpb25zL1VuaWNvZGU0LjAuMSkg YW5kIGJ5DQogICAgICAgICAgICAgIFVuaWNvZGUgNC4xLjANCiAgICAgICAgICAgICAgKGh0dHA6 Ly93d3cudW5pY29kZS5vcmcvdmVyc2lvbnMvVW5pY29kZTQuMS4wKS4iLA0KICAgICAgICAgICAg ICBNYXJjaCAyMDA1Lg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDE4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA1NF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAw NQ0KDQoNCiAgIFtYTUwxMF0gICAgQnJheSAoZXQgYWwpLCBULiwgIkV4dGVuc2libGUgTWFya3Vw IExhbmd1YWdlIChYTUwpIDEuMCIsDQogICAgICAgICAgICAgIDAyIDIwMDQuDQoNCiAgIFtYTUxT Y2hlbWFdDQogICAgICAgICAgICAgIEJpcm9uLCBQLiwgRWQuIGFuZCBBLiBNYWxob3RyYSwgRWQu LCAiWE1MIFNjaGVtYSBQYXJ0IDI6DQogICAgICAgICAgICAgIERhdGF0eXBlcyBTZWNvbmQgRWRp dGlvbiIsIDEwIDIwMDQsIDwNCiAgICAgICAgICAgICAgaHR0cDovL3d3dy53My5vcmcvVFIveG1s c2NoZW1hLTIvPi4NCg0KICAgW2luaXRpYWwtcmVnaXN0cnldDQogICAgICAgICAgICAgIEV3ZWxs LCBELiwgRWQuLCAiSW5pdGlhbCBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkiLA0KICAgICAgICAg ICAgICBKdW5lIDIwMDUsIDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAg ICAgICAgICAgICAgZHJhZnQtaWV0Zi1sdHJ1LWluaXRpYWwtcmVnaXN0cnktMDAudHh0Pi4NCg0K ICAgW2lzbzYzOS5wcmluY2lwbGVzXQ0KICAgICAgICAgICAgICBJU08gNjM5IEpvaW50IEFkdmlz b3J5IENvbW1pdHRlZSwgIklTTyA2MzkgSm9pbnQgQWR2aXNvcnkNCiAgICAgICAgICAgICAgQ29t bWl0dGVlOiAgV29ya2luZyBwcmluY2lwbGVzIGZvciBJU08gNjM5IG1haW50ZW5hbmNlIiwNCiAg ICAgICAgICAgICAgTWFyY2ggMjAwMCwNCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cubG9jLmdv di9zdGFuZGFyZHMvaXNvNjM5LTIvDQogICAgICAgICAgICAgIGlzbzYzOWphY19uM3IuaHRtbD4u DQoNCiAgIFtyZWNvcmQtamFyXQ0KICAgICAgICAgICAgICBSYXltb25kLCBFLiwgIlRoZSBBcnQg b2YgVW5peCBQcm9ncmFtbWluZyIsIDIwMDMuDQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAg IEFkZGlzb24gUGhpbGxpcHMgKGVkaXRvcikNCiAgIFF1ZXN0IFNvZnR3YXJlDQoNCiAgIEVtYWls OiBhZGRpc29uLnBoaWxsaXBzQHF1ZXN0LmNvbQ0KICAgVVJJOiAgIGh0dHA6Ly93d3cuaW50ZXIt bG9jYWxlLmNvbQ0KDQoNCiAgIE1hcmsgRGF2aXMgKGVkaXRvcikNCiAgIElCTQ0KDQogICBFbWFp bDogbWFyay5kYXZpc0B1cy5pYm0uY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAg ICAgW1BhZ2UgNTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUNCg0KDQpBcHBlbmRpeCBBLiAgQWNrbm93 bGVkZ2VtZW50cw0KDQogICBBbnkgbGlzdCBvZiBjb250cmlidXRvcnMgaXMgYm91bmQgdG8gYmUg aW5jb21wbGV0ZTsgcGxlYXNlIHJlZ2FyZCB0aGUNCiAgIGZvbGxvd2luZyBhcyBvbmx5IGEgc2Vs ZWN0aW9uIGZyb20gdGhlIGdyb3VwIG9mIHBlb3BsZSB3aG8gaGF2ZQ0KICAgY29udHJpYnV0ZWQg dG8gbWFrZSB0aGlzIGRvY3VtZW50IHdoYXQgaXQgaXMgdG9kYXkuDQoNCiAgIFRoZSBjb250cmli dXRvcnMgdG8gUkZDIDMwNjYgYW5kIFJGQyAxNzY2LCB0aGUgcHJlY3Vyc29ycyBvZiB0aGlzDQog ICBkb2N1bWVudCwgbWFkZSBlbm9ybW91cyBjb250cmlidXRpb25zIGRpcmVjdGx5IG9yIGluZGly ZWN0bHkgdG8gdGhpcw0KICAgZG9jdW1lbnQgYW5kIGFyZSBnZW5lcmFsbHkgcmVzcG9uc2libGUg Zm9yIHRoZSBzdWNjZXNzIG9mIGxhbmd1YWdlDQogICB0YWdzLg0KDQogICBUaGUgZm9sbG93aW5n IHBlb3BsZSAoaW4gYWxwaGFiZXRpY2FsIG9yZGVyKSBjb250cmlidXRlZCB0byB0aGlzDQogICBk b2N1bWVudCBvciB0byBSRkNzIDE3NjYgYW5kIDMwNjY6DQoNCiAgIEdsZW5uIEFkYW1zLCBIYXJh bGQgVHZlaXQgQWx2ZXN0cmFuZCwgVGltIEJlcm5lcnMtTGVlLCBNYXJjIEJsYW5jaGV0LA0KICAg TmF0aGFuaWVsIEJvcmVuc3RlaW4sIEthcmVuIEJyb29tZSwgRXJpYyBCcnVubmVyLCBTZWFuIE0u IEJ1cmtlLCBNLlQuDQogICBDYXJyYXNjbyBCZW5pdGV6LCBKZXJlbXkgQ2Fycm9sbCwgSm9obiBD bGV3cywgSmltIENvbmtsaW4sIFBldGVyDQogICBDb25zdGFibGUsIEpvaG4gQ293YW4sIE1hcmsg Q3Jpc3BpbiwgRGF2ZSBDcm9ja2VyLCBNYXJ0aW4gRHVlcnN0LA0KICAgRnJhbmsgRWxsZXJtYW4s IE1pY2hhZWwgRXZlcnNvbiwgRG91ZyBFd2VsbCwgTmVkIEZyZWVkLCBUaW0gR29vZHdpbiwNCiAg IERpcmstV2lsbGVtIHZhbiBHdWxpaywgTWFyaW9uIEd1bm4sIEpvZWwgSGFscHJlbiwgRWxsaW90 dGUgUnVzdHkNCiAgIEhhcm9sZCwgUGF1bCBIb2ZmbWFuLCBTY290dCBIb2xsZW5iZWNrLCBSaWNo YXJkIElzaGlkYSwgT2xsZQ0KICAgSmFybmVmb3JzLCBLZW50IEthcmxzc29uLCBKb2huIEtsZW5z aW4sIEVya2tpIEtvbGVobWFpbmVuLCBBbGFpbg0KICAgTGFCb250ZSwgRXJpYyBNYWRlciwgSXJh IE1jRG9uYWxkLCBLZWl0aCBNb29yZSwgQ2hyaXMgTmV3bWFuLA0KICAgTWFzYXRha2EgT2h0YSwg RHlsYW4gUGllcmNlLCBSYW5keSBQcmVzdWhuLCBHZW9yZ2UgUmhvdGVuLCBGZWxpeA0KICAgU2Fz YWtpLCBNYXJrdXMgU2NoZXJlciwgS2VsZCBKb3JuIFNpbW9uc2VuLCBUaGllcnJ5IFNvdXJiaWVy LCBPdHRvDQogICBTdG9seiwgVGV4IFRleGluLCBBbmRyZWEgVmluZSwgUmh5cyBXZWF0aGVybGV5 LCBNaXNoYSBXb2xmLCBGcmFuY29pcw0KICAgWWVyZ2VhdSBhbmQgbWFueSwgbWFueSBvdGhlcnMu DQoNCiAgIFZlcnkgc3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBIYXJhbGQgVHZlaXQgQWx2ZXN0 cmFuZCwgd2hvDQogICBvcmlnaW5hdGVkIFJGQ3MgMTc2NiBhbmQgMzA2NiwgYW5kIHdpdGhvdXQg d2hvbSB0aGlzIGRvY3VtZW50IHdvdWxkDQogICBub3QgaGF2ZSBiZWVuIHBvc3NpYmxlLiAgU3Bl Y2lhbCB0aGFua3MgbXVzdCBnbyB0byBNaWNoYWVsIEV2ZXJzb24sDQogICB3aG8gaGFzIHNlcnZl ZCBhcyBsYW5ndWFnZSB0YWcgcmV2aWV3ZXIgZm9yIGFsbW9zdCB0aGUgY29tcGxldGUNCiAgIHBl cmlvZCBzaW5jZSB0aGUgcHVibGljYXRpb24gb2YgUkZDIDE3NjYuICBTcGVjaWFsIHRoYW5rcyB0 byBEb3VnDQogICBFd2VsbCwgZm9yIGhpcyBwcm9kdWN0aW9uIG9mIHRoZSBmaXJzdCBjb21wbGV0 ZSBzdWJ0YWcgcmVnaXN0cnksIGFuZA0KICAgaGlzIHdvcmsgaW4gcHJvZHVjaW5nIGEgdGVzdCBw YXJzZXIgZm9yIHZlcmlmeWluZyBsYW5ndWFnZSB0YWdzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAy MDA2ICAgICAgICAgICAgICBbUGFnZSA1Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNQ0KDQoNCkFwcGVu ZGl4IEIuICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBUYWdzIChJbmZvcm1hdGl2ZSkNCg0KICAgU2lt cGxlIGxhbmd1YWdlIHN1YnRhZzoNCg0KICAgICAgZGUgKEdlcm1hbikNCg0KICAgICAgZnIgKEZy ZW5jaCkNCg0KICAgICAgamEgKEphcGFuZXNlKQ0KDQogICAgICBpLWVub2NoaWFuIChleGFtcGxl IG9mIGEgZ3JhbmRmYXRoZXJlZCB0YWcpDQoNCiAgIExhbmd1YWdlIHN1YnRhZyBwbHVzIFNjcmlw dCBzdWJ0YWc6DQoNCiAgICAgIHpoLUhhbnQgKENoaW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUgVHJh ZGl0aW9uYWwgQ2hpbmVzZSBzY3JpcHQpDQoNCiAgICAgIHpoLUhhbnMgKENoaW5lc2Ugd3JpdHRl biB1c2luZyB0aGUgU2ltcGxpZmllZCBDaGluZXNlIHNjcmlwdCkNCg0KICAgICAgc3ItQ3lybCAo U2VyYmlhbiB3cml0dGVuIHVzaW5nIHRoZSAgQ3lyaWxsaWMgc2NyaXB0KQ0KDQogICAgICBzci1M YXRuIChTZXJiaWFuIHdyaXR0ZW4gdXNpbmcgdGhlIExhdGluIHNjcmlwdCkNCg0KICAgTGFuZ3Vh Z2UtU2NyaXB0LVJlZ2lvbjoNCg0KICAgICAgemgtSGFucy1DTiAoQ2hpbmVzZSB3cml0dGVuIHVz aW5nIHRoZSBTaW1wbGlmaWVkIHNjcmlwdCBhcyB1c2VkIGluDQogICAgICBtYWlubGFuZCBDaGlu YSkNCg0KICAgICAgc3ItTGF0bi1DUyAoU2VyYmlhbiB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBz Y3JpcHQgYXMgdXNlZCBpbg0KICAgICAgU2VyYmlhIGFuZCBNb250ZW5lZ3JvKQ0KDQogICBMYW5n dWFnZS1WYXJpYW50Og0KDQogICAgICBzbC1yb3phaiAoUmVzaWFuIGRpYWxlY3Qgb2YgU2xvdmVu aWFuDQoNCiAgICAgIHNsLW5lZGlzIChOYWRpemEgZGlhbGVjdCBvZiBTbG92ZW5pYW4pDQoNCiAg IExhbmd1YWdlLVJlZ2lvbi1WYXJpYW50Og0KDQogICAgICBkZS1DSC0xOTAxIChHZXJtYW4gYXMg dXNlZCBpbiBTd2l0emVybGFuZCB1c2luZyB0aGUgMTkwMSB2YXJpYW50DQogICAgICBbb3J0aG9n cmFwaHldKQ0KDQogICAgICBzbC1JVC1uZWRpcyAoU2xvdmVuaWFuIGFzIHVzZWQgaW4gSXRhbHks IE5hZGl6YSBkaWFsZWN0KQ0KDQogICBMYW5ndWFnZS1TY3JpcHQtUmVnaW9uLVZhcmlhbnQ6DQoN Cg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgs IDIwMDYgICAgICAgICAgICAgIFtQYWdlIDU3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAg ICAgc2wtTGF0bi1JVC1uZWRpcyAoTmFkaXphIGRpYWxlY3Qgb2YgU2xvdmVuaWFuIHdyaXR0ZW4g dXNpbmcgdGhlDQogICAgICBMYXRpbiBzY3JpcHQgYXMgdXNlZCBpbiBJdGFseS4gIE5vdGUgdGhh dCB0aGlzIHRhZyBpcyBOT1QNCiAgICAgIFJFQ09NTUVOREVEIGJlY2F1c2Ugc3VidGFnICdzbCcg aGFzIGEgU3VwcHJlc3MtU2NyaXB0IHZhbHVlIG9mDQogICAgICAnTGF0bicpDQoNCiAgIExhbmd1 YWdlLVJlZ2lvbjoNCg0KICAgICAgZGUtREUgKEdlcm1hbiBmb3IgR2VybWFueSkNCg0KICAgICAg ZW4tVVMgKEVuZ2xpc2ggYXMgdXNlZCBpbiB0aGUgVW5pdGVkIFN0YXRlcykNCg0KICAgICAgZXMt NDE5IChTcGFuaXNoIGFwcHJvcHJpYXRlIGZvciB0aGUgTGF0aW4gQW1lcmljYSBhbmQgQ2FyaWJi ZWFuDQogICAgICByZWdpb24gdXNpbmcgdGhlIFVOIHJlZ2lvbiBjb2RlKQ0KDQogICBQcml2YXRl IHVzZSBzdWJ0YWdzOg0KDQogICAgICBkZS1DSC14LXBob25lYmsNCg0KICAgICAgYXotQXJhYi14 LUFaRS1kZXJiZW5kDQoNCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgKGV4YW1wbGVzIE9O TFk6IGV4dGVuZGVkIGxhbmd1YWdlcyBNVVNUIGJlDQogICBkZWZpbmVkIGJ5IHJldmlzaW9uIG9y IHVwZGF0ZSB0byB0aGlzIGRvY3VtZW50KToNCg0KICAgICAgemgtbWluDQoNCiAgICAgIHpoLW1p bi1uYW4tSGFudC1DTg0KDQogICBQcml2YXRlIHVzZSByZWdpc3RyeSB2YWx1ZXM6DQoNCiAgICAg IHgtd2hhdGV2ZXIgKHByaXZhdGUgdXNlIHVzaW5nIHRoZSBzaW5nbGV0b24gJ3gnKQ0KDQogICAg ICBxYWEtUWFhYS1RTS14LXNvdXRoZXJuIChhbGwgcHJpdmF0ZSB0YWdzKQ0KDQogICAgICBkZS1R YWFhIChHZXJtYW4sIHdpdGggYSBwcml2YXRlIHNjcmlwdCkNCg0KICAgICAgc3ItTGF0bi1RTSAo U2VyYmlhbiwgTGF0aW4tc2NyaXB0LCBwcml2YXRlIHJlZ2lvbikNCg0KICAgICAgc3ItUWFhYS1D UyAoU2VyYmlhbiwgcHJpdmF0ZSBzY3JpcHQsIGZvciBTZXJiaWEgYW5kIE1vbnRlbmVncm8pDQoN CiAgIFRhZ3MgdGhhdCB1c2UgZXh0ZW5zaW9ucyAoZXhhbXBsZXMgT05MWTogZXh0ZW5zaW9ucyBN VVNUIGJlIGRlZmluZWQNCiAgIGJ5IHJldmlzaW9uIG9yIHVwZGF0ZSB0byB0aGlzIGRvY3VtZW50 IG9yIGJ5IFJGQyk6DQoNCiAgICAgIGVuLVVTLXUtaXNsYW1DYWwNCg0KICAgICAgemgtQ04tYS1t eUV4dC14LXByaXZhdGUNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGly ZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDU4XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1Z3Vz dCAyMDA1DQoNCg0KICAgICAgZW4tYS1teUV4dC1iLWFub3RoZXINCg0KICAgU29tZSBJbnZhbGlk IFRhZ3M6DQoNCiAgICAgIGRlLTQxOS1ERSAodHdvIHJlZ2lvbiB0YWdzKQ0KDQogICAgICBhLURF ICh1c2Ugb2YgYSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRhZyBpbiBwcmltYXJ5IHBvc2l0aW9uOyBu b3RlDQogICAgICB0aGF0IHRoZXJlIGFyZSBhIGZldyBncmFuZGZhdGhlcmVkIHRhZ3MgdGhhdCBz dGFydCB3aXRoICJpLSIgdGhhdA0KICAgICAgYXJlIHZhbGlkKQ0KDQogICAgICBhci1hLWFhYS1i LWJiYi1hLWNjYyAodHdvIGV4dGVuc2lvbnMgd2l0aCBzYW1lIHNpbmdsZSBsZXR0ZXINCiAgICAg IHByZWZpeCkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMTgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDU5XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1DQoNCg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUg SUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9m IGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhh dCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBv ciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9y IHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1p Z2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0 IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBz dWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3Bl Y3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzgg YW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBv YnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAg c3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMN CiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJ UFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJ RVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlv biBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Ig b3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRo YXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFz ZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0 Zi5vcmcuDQoNCg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFu ZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAg ICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9T SEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJO RVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJ U0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJTkcg QlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJ TkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1Q TElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQ QVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmln aHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3Vi amVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWlu ZWQgaW4gQkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1 dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAg RnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVk IGJ5IHRoZQ0KICAgSW50ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgNjBdDQoM DQo= ------_=_NextPart_001_01C5A37F.BCE6BF38 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C5A37F.BCE6BF38-- From ltru-bounces@lists.ietf.org Wed Aug 17 19:37:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5XTR-0001xQ-IB; Wed, 17 Aug 2005 19:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5XTQ-0001xJ-6G for ltru@megatron.ietf.org; Wed, 17 Aug 2005 19:37:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12343 for ; Wed, 17 Aug 2005 19:37:28 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Y30-0002Sy-E2 for ltru@ietf.org; Wed, 17 Aug 2005 20:14:21 -0400 Received: from h-64-105-136-26.snvacaid.dynamic.covad.net ([64.105.136.26] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5XTD-0006uo-00 for ltru@ietf.org; Wed, 17 Aug 2005 19:37:19 -0400 Message-ID: <002001c5a384$cedb0d40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <005801c5a1cb$7e9eda60$7f1afea9@oemcomputer> Subject: Re: [Ltru] LTRU Milestones past due Date: Wed, 17 Aug 2005 16:38:44 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Randy Presuhn" > To: "LTRU Working Group" > Sent: Monday, August 15, 2005 11:59 AM > Subject: [Ltru] LTRU Milestones past due ... > Current: > May 05 Submit registry structure draft for IETF Last Call > Aug 05 Submit matching algorithms draft for IETF Last Call > > I propose that we ask our ADs to permit the following updates: > Aug 05 Submit registry structure draft for IETF Last Call > Oct 05 Submit matching algorithms draft for IETF Last Call ... Thanks to all who commented on proposed miestone updates. I'll send in the request. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 21:30:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ZEb-0008Qd-Aj; Wed, 17 Aug 2005 21:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ZEY-0008QW-Mt for ltru@megatron.ietf.org; Wed, 17 Aug 2005 21:30:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17971 for ; Wed, 17 Aug 2005 21:30:16 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5ZoD-0005fD-22 for ltru@ietf.org; Wed, 17 Aug 2005 22:07:09 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E5ZER-0005Kp-3B; Wed, 17 Aug 2005 18:30:11 -0700 Message-Id: <6.2.1.2.2.20050818021410.03153d70@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 18 Aug 2005 03:30:04 +0200 To: "Randy Presuhn" , Martin Duerst , "Scott Hollenbeck" From: r&d afrac Subject: Re: [Ltru] Re: appeal intent report to ADs In-Reply-To: <002101c5a368$fa2e6d00$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050817004910.031432e0@pop.online.fr> <037401c5a2bc$feae14e0$7f1afea9@oemcomputer> <6.2.1.2.2.20050817134148.031935b0@mail.afrac.org> <002101c5a368$fa2e6d00$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 22:18 17/08/2005, Randy Presuhn said: >Hi Jefsey - >Martin and I have decided that I'll be the shepherding AD for the two >registry-related documents, while Martin handles the parallel work on >completing the matching draft. I'll be sending in the publication requests >today. > >As the document's shepherd, I'm in no position to make "compromises". Dear Randy, Until this decision you had it. >My job is to ensure that the document makes it through the process. Your job is that the Internet standard process rules, the Charter and the users needs are respected. Now, it is to IESG, IAB and Users to decide. >If issues arise from the IESG or from the IETF last call, any changes >other than purely editorial ones will need to be approved by the working >group. (There's a reason for the "DISCUSS" nomenclature.) Certainly. >I respectfully decline your kind offer to help produce the summary of >potential appeals issues for the AD. Noted. jfc > From: "r&d afrac" > > To: "Randy Presuhn" ; > ; "Scott Hollenbeck" > > Cc: > > Sent: Wednesday, August 17, 2005 5:29 AM > > Subject: Re: [Ltru] Re: appeal intent report to ADs > > > > At 01:48 17/08/2005, Randy Presuhn wrote: > > >If you're planning to appeal an IESG decision, this WG isn't the > > >place to do it. Section 6.5.2 of RFC 2026 makes the IAB responsible > > >for handling such appeals. > > > > Dear Randy, > > I do not understand your answers since you quote the proper references. > > > > 1. RFC 2026 6.5 describes the appeal procedures. This mail is an attempt to > > help you start an effort towards a compromise you did not engage. > > > > >The report Martin and I are required to provide > > > > 2. The document you quote says that this report is by the Shepherding > > Chair. I will wait for his designation. > > > > >to our responsible AD > > >is in anticipation of likely appeals of working group decisions, per > > >section 6.5.1 of RFC 2026 and section 3.1 (1.f) of > > >http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shephe > rding-05.txt > > > > 3. This document says: "1.f) Has anyone threatened an appeal or otherwise > > indicated extreme discontent? If so, please summarise the areas of > > conflict in separate email to the Responsible Area Director." > > > > In the case you missed it, I fall in the category of this anyone. I suppose > > that an incorrect description of my positions will only delay the whole > > process and lower the WG credibility. This is why I proposed to help. I > > note that you refused that help. > > > > >I do suggest you take a look at section 5 of RFC 2026, as your > > >understanding of the significance of the "BCP" designation doesn't > > >appear to be supported by its definition there. > > > > A BCP can be: > > 1. good user service common guidelines for policies and operations > > different in scope and style from protocol standards. > > 2. a way for entities such as IAB/IESG to insert proposals into the > > consensus-building machinery of the IETF while gauging the community's view > > of that issue. > > 3. to document the operation of the IETF itself. For example, this > > document defines the IETF Standards Process and is published as a BCP. > > > > (1) seems unlikely since the Draft introduces standard track issues > > conflicting with open source/standard works and projects. > > (2) I thought it was a way for W3C and Unicode to introduce their > > proposals, but Addison Philip documented he did not represent the W3C (Mark > > Davis refused to comment and to inform the WG on the CLDR he directs and > > which is included in the Charter). > > (3) the title of the WG is "Language Tags Registry Update". The non-studied > > Charter says "It will describe the structure of the IANA registry and how > > the registered tags will relate to the generative mechanisms". > > > > I take that this intended BCP is to ascertain the control of this IANA > > registry to the benefit of the "ietf-languages@alvestrand.no" mailing list > > and through an excluding format, leading the users of other formats more > > appropriate to their needs to adopt non-IANA/IETF solutions, increasing the > > balkanisation of the Internet. > > > > I formally oppose this excluding proposition I consider as highly > > detrimental to the Internet. And will continue to engage every effort I can > > pursue to fight the internet balkanisation as a response to its partition > > necessity, all the more when I feel the motivation is not a common but a > > commercial interest for the very reasons documented by IAB in RFC 3869. > > > > jfc morfin > > > > > > From: "r&d afrac" > > > > To: "Randy Presuhn" > > > > Cc: "Scott Hollenbeck" ; > > > > Sent: Tuesday, August 16, 2005 4:11 PM > > > > Subject: appeal intent report to ADs > > > > > > > > Dear Randy, > > > > you have adopted a procedure which makes you (or Martin) to report > the ADs > > > > the documented motives of the appeals I announced, should the IETF Last > > > > Call lead to a positive IESG decision, regarding the Draft you made > > > > proposed by Addison Philips and Mark Davis. I am certainly ready to > help > > > > reviewing this report, so the AD get a complete and clear picture. > This may > > > > be an occasion for clarifications, and to agree on our disagreements. > > > > > > > > I think that this Draft would deeply harm the Internet should it > continue > > > > to claim being a BCP documenting an exclusive global Internet language > > > > tagging. But I also think that if this Draft brings a transitional > response > > > > to specific needs, it must go through as a standard track specific > document > > > > (having not studied the Charter in common, I trusted blindly Addison on > > > > this until he said he did not spoke on behalf the W3C: this is the > reason > > > > of my "if"). In such a case both the Internet standard process and the > > > > anti-open standard ABNF provisions parts should obviously be > removed as out > > > > of the new scope. > > > > > > > > jfc > > > > > > > > > > > > > > > > > > >_______________________________________________ > > >Ltru mailing list > > >Ltru@lists.ietf.org > > >https://www1.ietf.org/mailman/listinfo/ltru > > > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Aug 17 22:50:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5aUA-00070J-4c; Wed, 17 Aug 2005 22:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5aU6-0006zu-SK for ltru@megatron.ietf.org; Wed, 17 Aug 2005 22:50:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21158 for ; Wed, 17 Aug 2005 22:50:23 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E5aSq-0007Uk-P3 for ltru@lists.ietf.org; Thu, 18 Aug 2005 04:49:08 +0200 Received: from c-134-88-54.hh.dial.de.ignite.net ([62.134.88.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Aug 2005 04:49:08 +0200 Received: from nobody by c-134-88-54.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Aug 2005 04:49:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 18 Aug 2005 04:44:45 +0200 Organization: Lines: 28 Message-ID: <4303F61D.74A0@xyzzy.claranet.de> References: <003401c5a371$3f9e5460$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-54.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: I-D ACTION:draft-ietf-ltru-registry-11.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > Arrrrgh. Purely editorial, must be fixed before I can give > this to IESG. [...] > tmp/draft-ietf-ltru-registry-11.txt(987): Line has weird > spacing: '...al line of AS...' Trying to guess WT xml2rfc did I find this irony in the XML source: | [...] Lines are limited to 72 characters, including all | whitespace.Records are separated by lines containing | only the sequence "%%" (%x25.25). Each field can be | viewed as a single, logical line of | ASCII characters, comprising a field-name and a All in one line before the ASCII line, maybe xml2rfc "hates" long input lines. There's a new release 1.30 since yesterday. > tmp/draft-ietf-ltru-registry-11.txt(2921): Line contains > control character TAB in position 27. TAB copied from the source. Can't be a feature, therefore it's a bug. Sometimes I wonder how difficult it might be to roll my own XEDIT macros. If XML / WORD / NROFF can do it, then good old XEDIT (1981 ?) also can do. Never change your editor, bye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Aug 18 15:50:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qP2-0003l5-Iy; Thu, 18 Aug 2005 15:50:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qOr-0003hq-4f; Thu, 18 Aug 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27330; Thu, 18 Aug 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5qye-0003lw-Gs; Thu, 18 Aug 2005 16:27:05 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5qOn-00074x-J5; Thu, 18 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-12.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-registry-12.txt Pages : 60 Date : 2005-8-18 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-registry-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-registry-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-18123207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-18123207.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@lists.ietf.org Thu Aug 18 18:53:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tGI-0005ZO-7x; Thu, 18 Aug 2005 18:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tGG-0005Z6-9y for ltru@megatron.ietf.org; Thu, 18 Aug 2005 18:53:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09915 for ; Thu, 18 Aug 2005 18:53:21 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5tq6-0001Nr-8c for ltru@ietf.org; Thu, 18 Aug 2005 19:30:26 -0400 Received: from h-64-105-34-173.snvacaid.dynamic.covad.net ([64.105.34.173] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5tGF-0001Jz-00 for ltru@ietf.org; Thu, 18 Aug 2005 18:53:23 -0400 Message-ID: <004401c5a447$d9aaa640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 18 Aug 2005 15:53:57 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ltru] Updates to ltru WG charter milestone dates X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Just a quick note to let the WG know that the dates on our charter at http://www.ietf.org/html.charters/ltru-charter.html have been updated. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Aug 19 13:45:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ava-00078T-Nm; Fri, 19 Aug 2005 13:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ava-000785-Bb for ltru@megatron.ietf.org; Fri, 19 Aug 2005 13:45:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18927 for ; Fri, 19 Aug 2005 13:45:10 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6BVX-0000rz-0h for ltru@ietf.org; Fri, 19 Aug 2005 14:22:24 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 10:44:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Aug 2005 10:44:56 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C8B3A9E@irvmbxw01.quest.com> Thread-Topic: editor's copy of matching updated... Thread-Index: AcWk5a9d7BwYwT6rRe2Esfo4XyEi3w== From: "Addison Phillips" To: X-OriginalArrivalTime: 19 Aug 2005 17:44:56.0985 (UTC) FILETIME=[B6B72890:01C5A4E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] editor's copy of matching updated... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0976661459==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0976661459== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBzdGlsbCBuZWVkIHRvIGZpeCB1cCB0aGUgcmVmZXJlbmNlcyAodG8gbWF0Y2ggd2hhdCB3YXMg ZG9uZSBpbiB0aGUgb3RoZXIgZHJhZnRzKSwgZG8gaWRuaXRzLCBhbmQgcnVuIHRoZSBBQk5GIGNo ZWNrZXIsIGJ1dCBJJ3ZlIHBvc3RlZCBhIGNvcHkgb2YgZHJhZnQtMDQgb2YgbWF0Y2hpbmcgb24g aW50ZXItbG9jYWxlLiBPbmNlIEkndmUgZG9uZSB0aGUgaG91c2VrZWVwaW5nIEknbGwgc3VibWl0 IHRoZSB1cGRhdGUgYW5kIHByb2R1Y2UgYSBkaWZmLg0KDQpodHRwOi8vd3d3LmludGVyLWxvY2Fs ZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LW1hdGNoaW5nLTA0LnR4dA0KaHR0cDovL3d3dy5pbnRl ci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1tYXRjaGluZy0wNC5odG1sDQpodHRwOi8v d3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LW1hdGNoaW5nLTA0LnhtbA0K DQpOb3RhYmxlIGNoYW5nZXM6DQoNCi0gVXBkYXRlZCB0aGUgQUJORiBmb3IgZXh0ZW5kZWQgbGFu Z3VhZ2UgcmFuZ2VzIGFzIHBlciBLZW50J3MgbWVzc2FnZXMuIE5vdGUgdGhhdCBJIGFkZGVkIGV4 dGVuc2lvbnMgdG8gdGhlIEFCTkYgdGhpcyB0aW1lLg0KDQotIEFkZGVkIGEgbm90ZSB0byBleHBs aWNpdGx5IHN0YXRlIHRoYXQgbXVsdGlwbGUgc3RhcnMgY2FuIGNvbGxhcHNlIGluIFNlY3Rpb24g Mi4yLg0KDQotIE1pbm9yIHdvcmRzbWl0aGluZy4NCg0KLSBFeHBhbmRlZCBTZWN0aW9uIDIuMi4z IChTY29yZWQgTWF0Y2hpbmcpIHNpZ25pZmljYW50bHkuIEkgYWRkZWQgZXhhbXBsZXMgb2YgZGlm ZmVyZW50IHF1YWRydXBsZXMgYW5kIGNsZWFuZWQgdXAgdGhlIHRleHQuIEkgYWRkZWQgdGV4dHVh bCBydWxlcyBmb3IgaGFuZGxpbmcgZ3JhbmRmYXRoZXJlZCB0YWdzIGFuZCB0byBleGNsdWRlIGV4 dGVuc2lvbnMuDQoNCi0gVXBkYXRlZCB0aGUgcmVmZXJlbmNlcyB0byBkcmFmdC1yZWdpc3RyeSBh bmQgZHJhZnQtaW5pdGlhbC4NCg0KRm9yIHRoZSBlZGl0b3JzLA0KDQpBZGRpc29uDQoNCkFkZGlz b24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0K aHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBD b3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50 ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVy ZS4gDQoNCg0K --===============0976661459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0976661459==-- From ltru-bounces@lists.ietf.org Fri Aug 19 20:37:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6HMQ-0005FK-5n; Fri, 19 Aug 2005 20:37:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6HMO-0005Ak-AM for ltru@megatron.ietf.org; Fri, 19 Aug 2005 20:37:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14436 for ; Fri, 19 Aug 2005 20:37:18 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6HwR-0005Px-Ml for ltru@ietf.org; Fri, 19 Aug 2005 21:14:35 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E6HM4-0003iG-Jm for ltru@ietf.org; Fri, 19 Aug 2005 17:37:00 -0700 Message-Id: <6.2.3.4.2.20050820023107.04315da0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 20 Aug 2005 02:36:40 +0200 To: ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] editor's copy of matching updated... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Addison, I do not understand the meaning of the sentence in the introduction: " Given a set of language identifiers, such as those defined in [ID.ietf-ltru-registry], various mechanisms can be envisioned for performing language negotiation and tag matching.". Either a language tags uses subtags registered in the IANA registry (except "x-") and obey to the ABNF (and the "such" seems a contradiction) or I do not see how you can envision mechanisms on a language identification system you do not know? Or may be could you give an example of what could be another set of identifier which would not be defined in your Draft and could use the mecahisms you describe? I have other remarks, but your response to this one may obviously change them. jfc On 19:44 19/08/2005, Addison Phillips said: >Content-class: urn:content-classes:message >Content-Type: text/plain; > charset="UTF-8" > >I still need to fix up the references (to match what was done in the >other drafts), do idnits, and run the ABNF checker, but I've posted >a copy of draft-04 of matching on inter-locale. Once I've done the >housekeeping I'll submit the update and produce a diff. > >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.txt >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.html >http://www.inter-locale.com/ID/draft-ietf-ltru-matching-04.xml > >Notable changes: > >- Updated the ABNF for extended language ranges as per Kent's >messages. Note that I added extensions to the ABNF this time. > >- Added a note to explicitly state that multiple stars can collapse >in Section 2.2. > >- Minor wordsmithing. > >- Expanded Section 2.2.3 (Scored Matching) significantly. I added >examples of different quadruples and cleaned up the text. I added >textual rules for handling grandfathered tags and to exclude extensions. > >- Updated the references to draft-registry and draft-initial. > >For the editors, > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Chair, W3C Internationalization Core Working Group >http://www.w3.org/International > >Internationalization is not a feature. >It is an architecture. > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 22 04:18:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77VR-0008QX-N0; Mon, 22 Aug 2005 04:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77VO-0008QN-Ri for ltru@megatron.ietf.org; Mon, 22 Aug 2005 04:18:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00071 for ; Mon, 22 Aug 2005 04:18:03 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E785q-0008Rb-Gx for ltru@ietf.org; Mon, 22 Aug 2005 04:55:50 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j7M8HVd09747; Mon, 22 Aug 2005 17:17:31 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id ca9cf4ee_12e4_11da_9754_0030482532aa_23248; Mon, 22 Aug 2005 17:14:42 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO00337C; 22 Aug 05 17:18:23 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 22 Aug 05 17:17:54 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.66) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG003378; 22 Aug 05 17:17:47 +0900 Message-Id: <6.0.0.20.2.20050822155409.094c3430@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 22 Aug 2005 16:05:20 +0900 To: r&d afrac , ltru@ietf.org From: Martin Duerst In-Reply-To: <6.2.3.4.2.20050820023107.04315da0@mail.afrac.org> References: <6.2.3.4.2.20050820023107.04315da0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] matching for non-RFC3066bis langtags (was: editor's copy of matching updated...) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org [please use new subject for new issue, thanks!] At 09:36 05/08/20, r&d afrac wrote: >Dear Addison, >I do not understand the meaning of the sentence in the introduction: " Given a set of language identifiers, such as those defined in [ID.ietf-ltru-registry], various mechanisms can be envisioned for performing language negotiation and tag matching.". > >Either a language tags uses subtags registered in the IANA registry (except "x-") and obey to the ABNF (and the "such" seems a contradiction) or I do not see how you can envision mechanisms on a language identification system you do not know? I think there are some very general kinds of matching that can apply independent of the syntax. E.g. various completely different tagging syntaxes may allow matching of a list of languages (e.g. the list of languages somebody speaks or reads) against a particular language, or they may have one way or another to deal with subset relationships. Of course it may be possible to envision language tagging syntaxes where even these kinds of matching don't make sense. >Or may be could you give an example of what could be another set of identifier which would not be defined in your Draft and could use the mecahisms you describe? I think the above sentence does not say that the mechanisms described later in the document can be applied to arbitrary syntaxes. It's just a general statement in the introduction to motivate that there are more than one way of matching, as described later in the draft. A direct rewording that makes this clearer would be something like: "For any kind of language identifiers, including those defined by RFC3066bis, there is easily more than one of matching. Thus, this document defines a set of ways of matching for the language tags defined in RFC3066bis." However, I'm not sure it is necessary to start with that much generality, if the language tags of RFC2066bis need more than one way of matching, that's enough motivation. Regards, Martin. >I have other remarks, but your response to this one may obviously change them. >jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 22 06:16:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E79JI-0000z0-UC; Mon, 22 Aug 2005 06:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E79JF-0000xe-Hc for ltru@megatron.ietf.org; Mon, 22 Aug 2005 06:13:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04732 for ; Mon, 22 Aug 2005 06:13:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E79tn-0003II-Ca for ltru@ietf.org; Mon, 22 Aug 2005 06:51:27 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E79J8-0001n1-Em; Mon, 22 Aug 2005 03:13:34 -0700 Message-Id: <6.2.3.4.2.20050822113322.051ee100@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 22 Aug 2005 12:12:36 +0200 To: Martin Duerst , ltru@ietf.org From: r&d afrac In-Reply-To: <6.0.0.20.2.20050822155409.094c3430@itmail.it.aoyama.ac.jp> References: <6.2.3.4.2.20050820023107.04315da0@mail.afrac.org> <6.0.0.20.2.20050822155409.094c3430@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Subject: [Ltru] Re: matching for non-RFC3066bis langtags (was: editor's copy of matching updated...) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 09:05 22/08/2005, Martin Duerst wrote: >[please use new subject for new issue, thanks!] > >At 09:36 05/08/20, r&d afrac wrote: > >Dear Addison, > >I do not understand the meaning of the sentence in the > introduction: " Given a set of language identifiers, such as those > defined in [ID.ietf-ltru-registry], various mechanisms can be > envisioned for performing language negotiation and tag matching.". > > > >Either a language tags uses subtags registered in the IANA > registry (except "x-") and obey to the ABNF (and the "such" seems a > contradiction) or I do not see how you can envision mechanisms on a > language identification system you do not know? > >I think there are some very general kinds of matching that can apply >independent of the syntax. E.g. various completely different tagging >syntaxes may allow matching of a list of languages (e.g. the list of >languages somebody speaks or reads) against a particular language, >or they may have one way or another to deal with subset relationships. >Of course it may be possible to envision language tagging syntaxes where >even these kinds of matching don't make sense. Dear Martin, I am afraid there is a confusion here. What Addison talks about is of a set of "language identifiers" (I do not know what it is compared with language tags) "such as those defined in" his Draft. I understand that his Draft describes the structure, content, construction, and semantics of language tags" to be used on the Internet (BCP) when a language is to be indicated. This results in a strict ABNF and a registry of subtags. I do not know the extent of what you name "syntax" when referred to this? The only understanding I have is: a different syntax means a different ABNF. But I am confused because a different syntax does not affect the semantic, and a different syntax should not hamper the matching as you note it. The only reason why such a matching would not make senses would be when a different language tagging would support a different semantic. In saying that this is possible (I suppose in support of the Addison's text, therefore I suppose "practically, technically possible under the current Draft") I feel you say (and Addison says in using "such") what I say while supporting a document which (this is the way I understand it) forbids it. > >Or may be could you give an example of what could be another set > of identifier which would not be defined in your Draft and could > use the mecahisms you describe? > >I think the above sentence does not say that the mechanisms described >later in the document can be applied to arbitrary syntaxes. It's just >a general statement in the introduction to motivate that there are more >than one way of matching, as described later in the draft. I do not understand what you want to say here. A different syntax means a different ABNF. The "such" does not refer to mechanisms (there is no mechanism defined in the RFC 3066bis Draft), it refers to "language identifiers" what should mean ABNF plus registry. But it is true that there should be several mechanisms defined (or simply exemplified) as some could be very specialised. Just one to give a practical example: I am a news agency and I survey RSS feeds to build a calendar. I am interested in pages where the date is expressed in a way my program and I can read it, among a list of languages I have someone more or less understand. I will therefore filter langtags in reference to the locale information on date format. This is a typical OPES job. >A direct rewording that makes this clearer would be something like: > >"For any kind of language identifiers, including those defined by >RFC3066bis, there is easily more than one of matching. Thus, this >document defines a set of ways of matching for the language tags >defined in RFC3066bis." Full agreement. This clarifies the legitimacy of other types of language identifiers. ABNF + registry. >However, I'm not sure it is necessary to start with that much generality, >if the language tags of RFC3066bis need more than one way of matching, >that's enough motivation. IMO it really does because: - it clarifies a text which I find - and probably many will - find confuse. - I would then have no objection to the text. - the wording could be slightly extended to underline what you point out: this kind of matching may make sense in other language tagging systems which uses the same subtags. Regards. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 22 11:18:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E3m-0004D9-DH; Mon, 22 Aug 2005 11:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E3l-0004D3-0F for ltru@megatron.ietf.org; Mon, 22 Aug 2005 11:18:01 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22117 for ; Mon, 22 Aug 2005 11:17:58 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050822151728.CRSD29002.mta9.adelphia.net@DEWELL> for ; Mon, 22 Aug 2005 11:17:28 -0400 Message-ID: <001b01c5a72c$86545300$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 22 Aug 2005 08:16:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: matching for non-RFC3066bis langtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org If the matching schemes described in draft-matching were specifically designed for use with language tags as defined in draft-registry, then I think it would be appropriate to say so in the Introduction. It is often the case that a good engineering solution can be applied, in whole or part, to situations for which it was not specifically designed. I don't see any need to call special attention to this phenomenon in draft-matching. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 22 12:17:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ewf-0007El-ER; Mon, 22 Aug 2005 12:14:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ewd-0007Ds-Ff for ltru@megatron.ietf.org; Mon, 22 Aug 2005 12:14:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25139 for ; Mon, 22 Aug 2005 12:14:40 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7FXD-0005pn-4c for ltru@ietf.org; Mon, 22 Aug 2005 12:52:32 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 09:14:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: matching for non-RFC3066bis langtags Date: Mon, 22 Aug 2005 09:14:25 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C8B3EE1@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: matching for non-RFC3066bis langtags Thread-Index: AcWnLXLDyuwiWF+9Rd6TUMXGRnfLNQABgejg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 22 Aug 2005 16:14:26.0276 (UTC) FILETIME=[90FFFA40:01C5A734] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1356891336==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1356891336== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RldJVywgYSByZW1pbmRlcjogdGhlIG1hdGNoaW5nIGRyYWZ0IGhhc24ndCBoYWQgYSBsb3Qgb2Yg Y2xvc2Ugc2NydXRpbnkgdG8gaXRzIHNwZWNpZmljIGxhbmd1YWdlLiBJdCB3YXMgc3BsaXQgZnJv bSBkcmFmdC1yZWdpc3RyeSBiYWNrIGF0IHRoZSBzdGFydCBvZiB0aGUgd29ya2luZyBncm91cCdz IGFjdGl2aXR5LiBUaGUgdGhyZWUgY3VycmVudCBkcmFmdHMgaGF2ZSBtb3N0bHkgZm9jdXNlZCBv biBrZWVwaW5nIGl0IGluIHN5bmMgd2l0aCBkcmFmdC1yZWdpc3RyeS4gQXMgYSByZXN1bHQsIHRo ZSB0ZXh0IHN0aWxsIG5lZWRzIHNvbWUgZWRpdGluZyBvZiB0aGlzIG5hdHVyZS4NCg0KSSBtb2Rp ZmllZCB0aGUgaW50cm9kdWN0aW9uIGFuZCBiZWdhbiBzb21lIG90aGVyIG1pbm9yIGVkaXRpbmcg YmVmb3JlIHRoZSB3ZWVrZW5kLCBidXQgZGlkbid0IGhhdmUgYSBjaGFuY2UgdG8gcG9zdCB0aGUg cmVzdWx0cyB1bnRpbCBqdXN0IG5vdy4gSSBiZWxpZXZlIHRoZXNlIGNoYW5nZXMgYWRkcmVzcyBK RkMncyBjb21tZW50cyBhYm91dCB0aGUgaW50cm9kdWN0aW9uLg0KDQpUaGUgY29udGVudCBzZWN0 aW9uIHRoYXQgcmVjZWl2ZWQgdGhlIG1vc3QgYXR0ZW50aW9uIHdhcyB0aGUgb25lIG9uIHNjb3Jl ZCBtYXRjaGluZyAoMi4yLjMpLiBQcmV2aW91c2x5IHRoYXQgc2VjdGlvbiB3YXMgc3RyaXBwZWQg ZnJvbSBzb21lIGVtYWlscyBieSBKb2huIENvd2FuLiBJIGhhdmUgcmV3cml0dGVuIHRoaXMgc2Vj dGlvbiB1c2luZyB0aGUgc2FtZSBnZW5lcmFsIHRvbmUgYXMgdGhlIHJlc3Qgb2YgdGhlIGRvY3Vt ZW50LCBhZGRpbmcgYW4gZXhhbXBsZSBvZiBxdWFkcnVwbGVzLiBUaGVyZSBpcyBvbmUgYmFkIHdv cmQgY2hvaWNlIGluIHRoZSByZXN1bHQgY3VycmVudGx5IHBvc3RlZCAoIlNpbXBsZSBhcHBsaWNh dGlvbnMuLi4iIHNob3VsZCByZWFkICJTb21lIGFwcGxpY2F0aW9ucy4uLiIpDQoNCkJlc3QgUmVn YXJkcywNCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFy Y2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24g Q29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1 cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91 bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIERvdWcgRXdlbGwNCj4gU2VudDog MjAwNeW5tDjmnIgyMuaXpSA4OjE3DQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVj dDogW0x0cnVdIFJlOiBtYXRjaGluZyBmb3Igbm9uLVJGQzMwNjZiaXMgbGFuZ3RhZ3MNCj4gDQo+ IElmIHRoZSBtYXRjaGluZyBzY2hlbWVzIGRlc2NyaWJlZCBpbiBkcmFmdC1tYXRjaGluZyB3ZXJl IHNwZWNpZmljYWxseQ0KPiBkZXNpZ25lZCBmb3IgdXNlIHdpdGggbGFuZ3VhZ2UgdGFncyBhcyBk ZWZpbmVkIGluIGRyYWZ0LXJlZ2lzdHJ5LCB0aGVuIEkNCj4gdGhpbmsgaXQgd291bGQgYmUgYXBw cm9wcmlhdGUgdG8gc2F5IHNvIGluIHRoZSBJbnRyb2R1Y3Rpb24uDQo+IA0KPiBJdCBpcyBvZnRl biB0aGUgY2FzZSB0aGF0IGEgZ29vZCBlbmdpbmVlcmluZyBzb2x1dGlvbiBjYW4gYmUgYXBwbGll ZCwgaW4NCj4gd2hvbGUgb3IgcGFydCwgdG8gc2l0dWF0aW9ucyBmb3Igd2hpY2ggaXQgd2FzIG5v dCBzcGVjaWZpY2FsbHkgZGVzaWduZWQuDQo+IEkgZG9uJ3Qgc2VlIGFueSBuZWVkIHRvIGNhbGwg c3BlY2lhbCBhdHRlbnRpb24gdG8gdGhpcyBwaGVub21lbm9uIGluDQo+IGRyYWZ0LW1hdGNoaW5n Lg0KPiANCj4gLS0NCj4gRG91ZyBFd2VsbA0KPiBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gaHR0 cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlz dA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2x0cnUNCg0K --===============1356891336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1356891336==-- From ltru-bounces@lists.ietf.org Mon Aug 22 13:00:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Fec-000181-SU; Mon, 22 Aug 2005 13:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Fea-00017a-6z for ltru@megatron.ietf.org; Mon, 22 Aug 2005 13:00:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28195 for ; Mon, 22 Aug 2005 13:00:05 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7GFA-0007Q2-PQ for ltru@ietf.org; Mon, 22 Aug 2005 13:37:58 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E7FeS-0000uu-Qi; Mon, 22 Aug 2005 10:00:01 -0700 Message-Id: <6.2.3.4.2.20050822181456.04bfa480@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 22 Aug 2005 18:15:53 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: matching for non-RFC3066bis langtags In-Reply-To: <001b01c5a72c$86545300$030aa8c0@DEWELL> References: <001b01c5a72c$86545300$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 17:16 22/08/2005, Doug Ewell wrote: >If the matching schemes described in draft-matching were specifically >designed for use with language tags as defined in draft-registry, then I >think it would be appropriate to say so in the Introduction. The point is what is a language tag not defined in the RFC 3066 bis. A chance we could agree, I unfortunately do not beleive in. jfc >It is often the case that a good engineering solution can be applied, in >whole or part, to situations for which it was not specifically designed. >I don't see any need to call special attention to this phenomenon in >draft-matching. > >-- >Doug Ewell >Fullerton, California >http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Aug 22 13:24:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G2a-0005vY-ET; Mon, 22 Aug 2005 13:24:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G2Z-0005vI-Pl for ltru@megatron.ietf.org; Mon, 22 Aug 2005 13:24:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29563 for ; Mon, 22 Aug 2005 13:24:50 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Gd8-0008Et-Et for ltru@ietf.org; Mon, 22 Aug 2005 14:02:43 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 10:24:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: matching for non-RFC3066bis langtags Date: Mon, 22 Aug 2005 10:24:38 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C8B3F52@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: matching for non-RFC3066bis langtags Thread-Index: AcWnO2bb85fx7yzzSfKSlA713rleywAAjPLw From: "Addison Phillips" To: "r&d afrac" , "LTRU Working Group" X-OriginalArrivalTime: 22 Aug 2005 17:24:38.0973 (UTC) FILETIME=[5FF686D0:01C5A73E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Jefsey:=20 Do you have text to propose? Or is this just another example of your = wasting our time with vacuous rants? I believe the changes I have made in the draft should address your = original question: these matching schemes are for matching RFC 3066bis = language tags. If you have some other suggestion, you will need to = propose text or risk being ignored as irrelevant. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of r&d afrac > Sent: 2005?8?22? 9:16 > To: Doug Ewell; LTRU Working Group > Subject: Re: [Ltru] Re: matching for non-RFC3066bis langtags >=20 > At 17:16 22/08/2005, Doug Ewell wrote: > >If the matching schemes described in draft-matching were specifically > >designed for use with language tags as defined in draft-registry, = then I > >think it would be appropriate to say so in the Introduction. >=20 > The point is what is a language tag not defined in the RFC 3066 bis. > A chance we could agree, I unfortunately do not beleive in. > jfc >=20 >=20 >=20 > >It is often the case that a good engineering solution can be applied, = in > >whole or part, to situations for which it was not specifically = designed. > >I don't see any need to call special attention to this phenomenon in > >draft-matching. > > > >-- > >Doug Ewell > >Fullerton, California > >http://users.adelphia.net/~dewell/ > > > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 22 15:32:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7I29-00069A-2k; Mon, 22 Aug 2005 15:32:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7I28-000695-NC for ltru@megatron.ietf.org; Mon, 22 Aug 2005 15:32:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07811; Mon, 22 Aug 2005 15:32:34 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Ich-0003pF-Ow; Mon, 22 Aug 2005 16:10:27 -0400 Received: from h-64-105-136-138.snvacaid.dynamic.covad.net ([64.105.136.138] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E7I20-0001l2-00; Mon, 22 Aug 2005 15:32:29 -0400 Message-ID: <003c01c5a750$76021f40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Scott Hollenbeck" , "The IESG" Date: Mon, 22 Aug 2005 12:34:05 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: LTRU Working Group Subject: [Ltru] Publication request for as RFC (BCP) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - This questionnaire and write-up is being sent to the responsible Applications Area Director, Scott Hollenbeck, , and to iesg-secretary@ietf.org as a request for the publication of ltru working group document as an RFC, to obsolete RFC 3066 (BCP 47). The detailed response to question 1.f (on appeals) has been sent separately to the responsible AD. The shepherding co-chair for this document is Randy Presuhn, . 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? yes 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The document has received detailed review within the ltru WG. Reviews have been solicited outside the working group, but to date none have been received. Given the depth and breadth of expertise of the working group's members, we are not concerned about the adequacy of the review. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong (rough) consensus, with one outlier. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. Yes, details supplied separately. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Yes. 1.h) Is the document split into normative and informative references? Yes. Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? There is a reference to ABNF , which is currently in the RFC editor queue. There are no other normative references to internet-drafts. (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality 1.j) Please provide such a write-up. Recent examples can be found in the "protocol action" announcements for approved documents. Technical Summary This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. This document was produced as part of the effort to develop a successor to RFC 3066, and is the primary deliverable the working group was chartered to produce. Working Group Summary Use of the existing IANA Language Tag registry revealed several shortcomings, leading to the development of this document. In addressing the requirements of its charter, the working group found it necessary to significantly change the registry format. Since language tags are used in a large number of protocols and formats, the working group maintained compatibility with existing language tag syntax, though it did change the syntax of registry entries and updated the procedures for the maintenance of the registry. There was strong consensus on all of these. Two issues are noteworthy for the amount of debate needed before the working group was able to reach rough consensus on them. The first was the order of subtags, in particular of the script identifier. The second was the "Suppress-Script" registry field. These two are closely related, and the tradeoffs involved a desire to avoid re-tagging existing data and a need to keep the tag format syntactically compatible with existing software, versus a desire to provide a tag structure that was in some ways more consistent. The working group opted for compatibility and avoiding re-tagging. Protocol Quality This document received extensive review and discussion within the ltru working group. Since language tags are used in a large number of protocols and formats, the working group maintained compatibility with existing language tag syntax. At the time of this summary, likely additions to the registry had already been discussed, but the WG agreed that since such changes are part of the normal operation of the IANA Language Subtag Registry, they should be handled on the mailing list ietf-languages@iana.org after the registry has been initialized. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 22 21:19:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NRn-0003Pg-0g; Mon, 22 Aug 2005 21:19:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NRj-0003NA-8B for ltru@megatron.ietf.org; Mon, 22 Aug 2005 21:19:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08982 for ; Mon, 22 Aug 2005 21:19:21 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7NRi-0001WO-3M for ltru@ietf.org; Mon, 22 Aug 2005 21:19:24 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7N1JBIX003024 for ; Mon, 22 Aug 2005 21:19:11 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7N1JBPr284862 for ; Mon, 22 Aug 2005 21:19:11 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7N1JBSs009828 for ; Mon, 22 Aug 2005 21:19:11 -0400 Received: from [127.0.0.1] ([9.43.213.128]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7N1H9Ux004469; Mon, 22 Aug 2005 21:19:10 -0400 Message-ID: <430A7912.8060403@icu-project.org> Date: Mon, 22 Aug 2005 18:17:06 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: matching for non-RFC3066bis langtags References: <634978A7DF025A40BFEF33EB191E13BC0C8B3EE1@irvmbxw01.quest.com> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C8B3EE1@irvmbxw01.quest.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1078468242==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1078468242== Content-Type: multipart/alternative; boundary="------------070102030708060305090000" This is a multi-part message in MIME format. --------------070102030708060305090000 Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j7N1JBIX003024 Content-Transfer-Encoding: quoted-printable I think the scored matching would be better framed as a 'distance'=20 metric. Here is suggested replacement text: =3D=3D=3D=3D=3D In the "scored matching" scheme, the extended language range ... ... ... SHOULD probably allow users to choose the most appropriate selection=20 value. =3D> In the "distance metric" scheme, a numeric value representing a=20 'distance' between a language tags and a language range is computed. A=20 distance of zero means that they are identical, a small distance=20 indicates that they are very similar, and a large distance indicated=20 that they are very different. Given a distance, implementations can=20 allow users to select a threshold distance for a match to be successful=20 or a filter to be applied. The first step in the process is to normalize the extended language=20 range and the language tags by canonicalizing both, and mapping=20 grandfathered and obsolete tags into modern equivalents. If there is no=20 script, then the Suppress-Script value from the registry is added as the=20 script. The language range and the language tags are then transformed into=20 quadruples of elements of the form (language, script, country, variant).=20 Any extended languages are considered part of the language element and=20 any extension subtag sequences are considered part of the variant=20 element; an x private use subtag sequences is considered part of the=20 language element if it is initial and part of the variant element if=20 not. Missing components in the language range are set to "*"; thus a "*"=20 pattern becomes the quadruple ("*", "*", "*", "*"). Subtags 'und' and=20 'Zyyy' are converted to "*". Each language tag being matched or filtered is assigned a distance,=20 whereby small values indicate better matches and large values indicate=20 worse ones. The distance between the language tags is the sum of the=20 distances for each of the corresponding elements of the quadruple. If=20 the elements are identical or one is '*', then the distance between them=20 is zero. Otherwise, it is given by the following table: 128 language mismatch 32 script mismatch 4 region mismatch 1 variant mismatch(es) Examples of distances from en-US: fr: 132 en-GB: 4 en-Latn-US: 0 en-Kata: 36 Implementations may want to use more sophisticated weights that depend=20 on the values of the corresponding elements. For example, depending on=20 the domain, an implemenation might give a small distance to the=20 difference between 'no' and 'nb' or 'nn'; or between 'Kata' and 'Hira';=20 or between 'US' and 'UM'. Mark Addison Phillips wrote: >FWIW, a reminder: the matching draft hasn't had a lot of close scrutiny = to its specific language. It was split from draft-registry back at the st= art of the working group's activity. The three current drafts have mostly= focused on keeping it in sync with draft-registry. As a result, the text= still needs some editing of this nature. > >I modified the introduction and began some other minor editing before th= e weekend, but didn't have a chance to post the results until just now. I= believe these changes address JFC's comments about the introduction. > >The content section that received the most attention was the one on scor= ed matching (2.2.3). Previously that section was stripped from some email= s by John Cowan. I have rewritten this section using the same general ton= e as the rest of the document, adding an example of quadruples. There is = one bad word choice in the result currently posted ("Simple applications.= .." should read "Some applications...") > >Best Regards, > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture.=20 > > =20 > >>-----Original Message----- >>From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On >>Behalf Of Doug Ewell >>Sent: 2005=E5=B9=B48=E6=9C=8822=E6=97=A5 8:17 >>To: LTRU Working Group >>Subject: [Ltru] Re: matching for non-RFC3066bis langtags >> >>If the matching schemes described in draft-matching were specifically >>designed for use with language tags as defined in draft-registry, then = I >>think it would be appropriate to say so in the Introduction. >> >>It is often the case that a good engineering solution can be applied, i= n >>whole or part, to situations for which it was not specifically designed. >>I don't see any need to call special attention to this phenomenon in >>draft-matching. >> >>-- >>Doug Ewell >>Fullerton, California >>http://users.adelphia.net/~dewell/ >> >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> =20 >> > > =20 > >------------------------------------------------------------------------ > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > =20 > --------------070102030708060305090000 Content-Type: text/html; charset=UTF-8 X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j7N1JBIX003024 Content-Transfer-Encoding: quoted-printable I think the scored matching would be better framed as a 'distance' metric. Here is suggested replacement text:
=3D=3D=3D=3D=3D

In the "scored matching" scheme, the extended language range ...
...
... SHOULD probably allow users to choose the most appropriate selection value.

=3D>

In the "distance metric" scheme, a numeric value representing a 'distance' between a language tags and a language range is computed. A distance of zero means that they are identical, a small distance indicates that they are very similar, and a large distance indicated that they are very different. Given a distance, implementations can allow users to select a threshold distance for a match to be successful or a filter to be applied.

The first step in the process is to normalize the extended language range and the language tags by canonicalizing both, and mapping grandfathered and obsolete tags into modern equivalents. If there is no script, then the Suppress-Script value from the registry is added as the script.

The language range and the language tags are then transformed into quadruples of elements of the form (language, script, country, variant). Any extended languages are considered part of the language element and any extension subtag sequences are considered=C2=A0 part of t= he variant element; an x private use subtag sequences is considered part of the language element if it is initial and part of the variant element if not. Missing components in the language range are set to "*"; thus a "*" pattern becomes the quadruple ("*", "*", "*", "*"). Subtags 'und' and 'Zy= yy' are converted to "*".

Each language tag being matched or filtered is assigned a distance, whereby small values indicate better matches and large values indicate worse ones. The distance between the language tags is the sum of the distances for each of the corresponding elements of the quadruple. If the elements are identical or one is '*', then the distance between them is zero. Otherwise, it is given by the following table:

=C2=A0 128 =C2=A0=C2=A0 language mismatch
=C2=A0=C2=A0 32 =C2=A0=C2=A0 script mismatch
=C2=A0=C2=A0=C2=A0 4 =C2=A0=C2=A0 region mismatch
=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0 variant mismatch(es)

Examples of distances from en-US:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fr: 132
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 en-GB:=C2=A0=C2=A0 4
=C2=A0en-Latn-US:=C2=A0=C2=A0 0
=C2=A0=C2=A0=C2=A0 en-Kata:=C2=A0 36

Implementations may want to use more sophisticated weights that depend on the values of the corresponding elements. For example, depending on the domain, an implemenation might give a small distance to the difference between 'no' and 'nb' or 'nn'; or between 'Kata' and 'Hira'; or between 'US' and 'UM'.

Mark

Addison Phillips wrote: 
FWIW, a reminder: the matching draft hasn't had a lot of=
 close scrutiny to its specific language. It was split from draft-registr=
y back at the start of the working group's activity. The three current dr=
afts have mostly focused on keeping it in sync with draft-registry. As a =
result, the text still needs some editing of this nature.

I modified the introduction and began some other minor editing before the=
 weekend, but didn't have a chance to post the results until just now. I =
believe these changes address JFC's comments about the introduction.

The content section that received the most attention was the one on score=
d matching (2.2.3). Previously that section was stripped from some emails=
 by John Cowan. I have rewritten this section using the same general tone=
 as the rest of the document, adding an example of quadruples. There is o=
ne bad word choice in the result currently posted ("Simple applications..=
." should read "Some applications...")

Best Regards,

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture.=20

  
-----Original Message-----
From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces=
@lists.ietf.org] On
Behalf Of Doug Ewell
Sent: 2005=E5=B9=B48=E6=9C=8822=E6=97=A5 8:17
To: LTRU Working Group
Subject: [Ltru] Re: matching for non-RFC3066bis langtags

If the matching schemes described in draft-matching were specifically
designed for use with language tags as defined in draft-registry, then I
think it would be appropriate to say so in the Introduction.

It is often the case that a good engineering solution can be applied, in
whole or part, to situations for which it was not specifically designed.
I don't see any need to call special attention to this phenomenon in
draft-matching.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/



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

  

_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--------------070102030708060305090000-- --===============1078468242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1078468242==-- From ltru-bounces@ietf.org Mon Aug 22 22:03:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7O8h-0003Yp-5M; Mon, 22 Aug 2005 22:03:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7O8f-0003Yj-KF for ltru@megatron.ietf.org; Mon, 22 Aug 2005 22:03:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10672; Mon, 22 Aug 2005 22:03:43 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7O8e-0002eq-Qu; Mon, 22 Aug 2005 22:03:47 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E7O8T-0003Py-1D; Mon, 22 Aug 2005 19:03:33 -0700 Message-Id: <6.2.3.4.2.20050823020225.048c75e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 23 Aug 2005 03:45:14 +0200 To: "Randy Presuhn" , "Scott Hollenbeck" , "The IESG" From: r&d afrac Subject: Re: [Ltru] Publication request for as RFC (BCP) In-Reply-To: <003c01c5a750$76021f40$7f1afea9@oemcomputer> References: <003c01c5a750$76021f40$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The following few comments are in order: At 21:34 22/08/2005, Randy Presuhn wrote: >The document has received detailed review within the ltru WG. Reviews >have been solicited outside the working group, but to date none have >been received. Given the depth and breadth of expertise of the working >group's members, we are not concerned about the adequacy of the review. The documents does not even allude to languages as used in a specific networked context. This denotes that the small score of experts involved are no experts in that area. The planned participation statistics to the WG will document this. > 1.c) Do you have concerns that the document needs more review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? Languages as interintelligibility protocols are one layer above Internet interoperability protocols and support interculturation processes. This is a domain commanding the whole development of the digital ecosystem relational continuity and usage architectures. It is certainly of high complexity: it involves 20.000 listed languages (in ISO 639-6 project) and actually the different individual forms of speaking, reading and exchanging of 6.5 billions of persons. This may amount to thousands of billions of linguistic versions. Everyone can understand that the attempt to tag them through a reduction of the RFC 3066 flexibility is a challenging task calling for a pervasive acceptance, an IETF WG (or any WG) cannot deliver at this time, with the current status of R&D in the different concerned matters. >No. > > 1.d) Do you have any specific concerns/issues with this document that > you believe the ADs and/or IESG should be aware of? For > example, perhaps you are uncomfortable with certain parts of the > document, or have concerns whether there really is a need for > it. In any event, if your issues have been discussed in the WG > and the WG has indicated it that it still wishes to advance the > document, detail those concerns in the write-up. > >No. This WG-ltru obviously has not the technical expertise, the cultural consensus and the political support to decide of a IANA language identification system users should universally adhere to (BCP). It has however the technical expertise, the application need (to be confirmed) and the commercial support to document one of the ways some Internet users and software publishers could use. The personal user's risks represented by this langtag system calls for high civil society concerns, as it associates a language to a Government political line. This may put the IESG at the apex of a major political and human right diatribe, in particular at the WSIS: it may not be what the IESG wants. > 1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > >Strong (rough) consensus, with one outlier. This consensus is a silent consensus by exhaustion. The WGLC did not lead to significant expressed support even of the leading affinity group (20% of the Members). As the outlier I will add (as explained many times) this was a deliberate effort of mine to keep a working relation between the real world and the WG, while preventing the WG to be overthrown without real signification and a waste of time for all by an opposing group of scholars. I note that this WG on languages issues is overwhelmingly manned by people having the same linguistic vision (English mother-tongue) and that an attempt to participate from different vision was qualified of "troll" leading the concerned academic person to leave. > 1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email to the Responsible Area Director. > >Yes, details supplied separately. I wait for a courtesy copy of these details to make sure the IESG is correctly informed. I proposed the authors of the PROTO Draft to make this transparency the rule and not a courtesy. > Technical Summary > > This document describes the structure, content, construction, and > semantics of language tags for use in cases where it is desirable to > indicate the language used in an information object. It also > describes how to register values for use in language tags and the > creation of user defined extensions for private interchange. > > This document was produced as part of the effort to develop a > successor to RFC 3066, and is the primary deliverable the working > group was chartered to produce. This document pretends to be _the_ successor to RFC 3066. Should it not claim to replace BCP 47 and to support a future global language support framework for a Multilingual Internet as indicated here, permitting to immediately document and support other language tags formats adequate to the users needs, open source projects and current developments, there would be an unanimous acceptation of the document. What is objected is not the content, but the IANA exclusivity and status quo: the exclusion of competing solutions and innovation. >Working Group Summary > > Use of the existing IANA Language Tag registry revealed several > shortcomings, leading to the development of this document. > In addressing the requirements of its charter, the working group > found it necessary to significantly change the registry format. Not correct. The very basis of this WG is an undocumented "consensus" "obliging" to strictly respect the RFC 3066 ABNF up to - the absurd obligation to respect old blocking formats for new applications (which by nature never used them) - and the refusal of an escape sequence permitting to seamlessly introduce other formats and new developments. The Charter has never been discussed by the WG. > Since language tags are used in a large number of protocols and > formats, the working group maintained compatibility with existing > language tag syntax, though it did change the syntax of registry > entries and updated the procedures for the maintenance of the > registry. There was strong consensus on all of these. "maintaining compatibility" does not means here that the new format must support the old format.It means that the old format had to contain the new format. This "retro-compatibility"has been qualified of "reverse compatibility". > Two issues are noteworthy for the amount of debate needed > before the working group was able to reach rough consensus on > them. The first was the order of subtags, in particular of the script > identifier. The script identifier position does not result from a debate of the WG but from the continuation of the Addison/Davis Draft which was the only discussed matter, from the very fist day of the WG. The lack of debate lead in particular to disregard several important issues: - the lack of documentation of the oral modes. While langtags are supposed to be for every usage, voice, sign, etc.attributes are not documented. - the lack of documentation of the language identification main attributes such as the referent system (dictionary, publisher, etc.) and the context (style, relation, space of exchange, etc.) and the date of publication. Even without being a human relations specialist one can understand that what Words supports (dictionary, style, version) are elements important to the identification of a content vehicle. The Draft organises and protect a langtag scarcity. This has serious reasons, but these reasons should have been discussed, analysed and better addressed. It also represents important commercial and industrial interests. The same they should be discussed and an equal opportunity for all the concerned stakeholders protected. These points have never been investigated. > The second was the "Suppress-Script" registry field. This is another "script only" issue, underlining the WG-ltru did not considered multimodal aspects. > These two are closely related, and the tradeoffs involved a desire > to avoid re-tagging existing data and a need to keep the tag format > syntactically compatible with existing software, versus a desire > to provide a tag structure that was in some ways more consistent. > The working group opted for compatibility and avoiding re-tagging. This translates the desire to impose for ever a closely constrained exclusive format, the status quo of which will benefit to market dominants, excluding innovation, pretending that other projects re-tag into an inadequate approach. That attitude can only lead to competition (called by the author: "that the best win") between solutions instead of an inclusive support of the various user needs and existing/future systems. A competition, due to the care importance of the matter to users, can only lead to a "tag war", where the only losers will be the IETF, the IANA and the users. >Protocol Quality > > This document received extensive review and discussion within the > ltru working group. > > Since language tags are used in a large number of protocols and > formats, the working group maintained compatibility with existing > language tag syntax. Incorrect. The Charter quotes existing use in HTML, XML, CLDR. HTML has not been much discussed. XML has. CLDR has not been, nor even been documented (while it is a project conducted by one of the authors). Clarifications concerning the CLDR's IPR issues have been denied- while the concerns for Open Source are serious. Relations of the language tags with LDAP have been partly considered. DNS, OPES and programming languages were denied consideration. One or two other protocols have been alluded to. No systematic review of all the possibly affected protocols has been carried by the WG. > At the time of this summary, likely additions to the registry had > already been discussed, but the WG agreed that since such > changes are part of the normal operation of the IANA Language > Subtag Registry, they should be handled on the mailing list > ietf-languages@iana.org after the registry has been initialized. Incorrect. A Draft has been produced to build an initial registry one shot. The IESG should be aware that some entries may rise some political controversies. There is currently not such a list as "ietf-languages@iana.org". There is a alias of that name for the real list "ietf-languages@alvestrand.no". As a result it has not the international recognition it should, to warranty a transparent process. The organisation of this list creates problems not addressed by the Draft; they directly engage the responsibility of the IESG: - selection and renewal of its reviewer by the IESG - management of the list - its current manager uses its private nature to assimilate it to IETF mailing list, without providing appeal protection - technical expertise of the reviewer is only script oriented - there is no liaison with other SDOs possibly relying on langtag IANA registry entries. A major point of concern of this registry is its real use by users and therefore of its real operation cost and operational feasibility. This point has been discussed without offering a documented scenario. These are only quick comments on the current write-up. They represent only a small part of the planned comments for a Last Call and for possible IETF, IAB, IANA, etc. appeals. They would be immediately removed should the intent above of not replacing BCP 47, but to only be one of the contributions to a BCP 47 replacement was confirmed and the concerned sentence to be reworded accordingly. jfc morfin AFRAC,vp r&d _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 22 23:04:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7P5n-0000iW-By; Mon, 22 Aug 2005 23:04:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7P5m-0000hb-M3 for ltru@megatron.ietf.org; Mon, 22 Aug 2005 23:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25731 for ; Mon, 22 Aug 2005 23:04:46 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7P5k-0004ek-IM for ltru@ietf.org; Mon, 22 Aug 2005 23:04:51 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j7N34Xd24661; Tue, 23 Aug 2005 12:04:33 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 3d4506c4_1382_11da_8392_0030482532aa_5391; Tue, 23 Aug 2005 12:01:45 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0034FB; 23 Aug 05 12:05:27 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 23 Aug 05 12:05:16 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.66) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0034F8; 23 Aug 05 12:05:15 +0900 Message-Id: <6.0.0.20.2.20050823114424.08b99410@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 23 Aug 2005 11:45:36 +0900 To: Mark Davis , Addison Phillips From: Martin Duerst Subject: Distance Metric (was: Re: [Ltru] Re: matching for non-RFC3066bis langtags) In-Reply-To: <430A7912.8060403@icu-project.org> References: <634978A7DF025A40BFEF33EB191E13BC0C8B3EE1@irvmbxw01.quest.com> <430A7912.8060403@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Resent, with more appropriate Subject:. PLEASE everybody make sure you change the Subject: when changing the subject! Regards, Martin. At 10:17 05/08/23, Mark Davis wrote: >I think the scored matching would be better framed as a 'distance' metric. >Here is suggested replacement text: >===== > >In the "scored matching" scheme, the extended language range ... >... >... SHOULD probably allow users to choose the most appropriate selection value. > >=> > >In the "distance metric" scheme, a numeric value representing a >'distance' between a language tags and a language range is computed. A >distance of zero means that they are identical, a small distance indicates >that they are very similar, and a large distance indicated that they are >very different. Given a distance, implementations can allow users to >select a threshold distance for a match to be successful or a filter to be >applied. > >The first step in the process is to normalize the extended language range >and the language tags by canonicalizing both, and mapping grandfathered >and obsolete tags into modern equivalents. If there is no script, then the >Suppress-Script value from the registry is added as the script. > >The language range and the language tags are then transformed into >quadruples of elements of the form (language, script, country, variant). >Any extended languages are considered part of the language element and any >extension subtag sequences are considered$B%D(B part of the variant element; >an x private use subtag sequences is considered part of the language >element if it is initial and part of the variant element if not. Missing >components in the language range are set to "*"; thus a "*" pattern >becomes the quadruple ("*", "*", "*", "*"). Subtags 'und' and 'Zyyy' are >converted to "*". > >Each language tag being matched or filtered is assigned a distance, >whereby small values indicate better matches and large values indicate >worse ones. The distance between the language tags is the sum of the >distances for each of the corresponding elements of the quadruple. If the >elements are identical or one is '*', then the distance between them is >zero. Otherwise, it is given by the following table: > >$B%D(B 128 $B%D(B $B%D(B language mismatch >$B%D(B $B%D(B 32 $B%D(B $B%D(B script mismatch >$B%D(B $B%D(B $B%D(B 4 $B%D(B $B%D(B region mismatch >$B%D(B $B%D(B $B%D(B 1$B%D(B $B%D(B $B%D(B variant mismatch(es) > >Examples of distances from en-US: > >$B%D(B $B%D(B $B%D(B $B%D(B $B%D(B $B%D(B $B%D(B $B%D(B fr: 132 >$B%D(B $B%D(B $B%D(B $B%D(B $B%D(B en-GB:$B%D(B $B%D(B 4 >$B%D(B en-Latn-US:$B%D(B $B%D(B 0 >$B%D(B $B%D(B $B%D(B en-Kata:$B%D(B 36 > >Implementations may want to use more sophisticated weights that depend on >the values of the corresponding elements. For example, depending on the >domain, an implemenation might give a small distance to the difference >between 'no' and 'nb' or 'nn'; or between 'Kata' and 'Hira'; or between >'US' and 'UM'. > >Mark >Addison Phillips wrote: >> >>FWIW, a reminder: the matching draft hasn't had a lot of close scrutiny >>to its specific language. It was split from draft-registry back at the >>start of the working group's activity. The three current drafts have >>mostly focused on keeping it in sync with draft-registry. As a result, >>the text still needs some editing of this nature. >> >>I modified the introduction and began some other minor editing before >>the weekend, but didn't have a chance to post the results until just now. >>I believe these changes address JFC's comments about the introduction. >> >>The content section that received the most attention was the one on >>scored matching (2.2.3). Previously that section was stripped from some >>emails by John Cowan. I have rewritten this section using the same >>general tone as the rest of the document, adding an example of >>quadruples. There is one bad word choice in the result currently posted >>("Simple applications..." should read "Some applications...") >> >>Best Regards, >> >>Addison >> >>Addison P. Phillips >>Globalization Architect, Quest Software >>Chair, W3C Internationalization Core Working Group >> >>Internationalization is not a feature. >>It is an architecture. >> >> >>> >>>-----Original Message----- >>>From: ltru-bounces@lists.ietf.org >>>[mailto:ltru-bounces@lists.ietf.org] On >>>Behalf Of Doug Ewell >>>Sent: 2005$Bj;%((B8$Bk|/(B2$Bkw!&(B 8:17 >>>To: LTRU Working Group >>>Subject: [Ltru] Re: matching for non-RFC3066bis langtags >>> >>>If the matching schemes described in draft-matching were specifically >>>designed for use with language tags as defined in draft-registry, then I >>>think it would be appropriate to say so in the Introduction. >>> >>>It is often the case that a good engineering solution can be applied, in >>>whole or part, to situations for which it was not specifically designed. >>>I don't see any need to call special attention to this phenomenon in >>>draft-matching. >>> >>>-- >>>Doug Ewell >>>Fullerton, California >>>http://users.adelphia.net/~dewell/ >>> >>> >>> >>>_______________________________________________ >>>Ltru mailing list >>>Ltru@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/ltru >>> >> >> >> >> >> >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 23 12:23:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bYS-0002qj-WE; Tue, 23 Aug 2005 12:23:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bYS-0002qe-6c for ltru@megatron.ietf.org; Tue, 23 Aug 2005 12:23:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13199 for ; Tue, 23 Aug 2005 12:23:13 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bYa-0001Eo-Bu for ltru@ietf.org; Tue, 23 Aug 2005 12:23:25 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 23 Aug 2005 12:23:06 -0400 id 003644BC.430B4D6A.00007B57 From: "Scott Hollenbeck" To: ltru@ietf.org Date: Tue, 23 Aug 2005 12:23:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWn/u8pCWAvOJPTR8m5BCc1o0qk1A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Ltru] AD Evaluation Comments: draft-ietf-ltru-registry-12 and draft-ietf-ltru-initial-04 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Both documents are ready for IETF last call. I found only one small issue with draft-ietf-ltru-registry-12. It's common practice to note documents being obsoleted in the first page document header. It should be noted that RFC 3066 is being obsoleted. This can be done using xml2rfc as follows: Yes, I noticed the text in the introduction. Both are needed. This is not a significant issue. Add it to the queue for processing after the last call has been completed. I will ask to have the documents last-called as part of a joint announcement. They will then be evaluated by the IESG as part of the same ballot. -Scott- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 23 12:45:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7btx-0007xe-0o; Tue, 23 Aug 2005 12:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7btr-0007vy-KK; Tue, 23 Aug 2005 12:45:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14103; Tue, 23 Aug 2005 12:45:20 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bty-0001ro-5u; Tue, 23 Aug 2005 12:45:30 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E7bto-0003lh-0J; Tue, 23 Aug 2005 12:45:20 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 23 Aug 2005 12:45:20 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org Subject: [Ltru] Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The IESG has received a request from the Language Tag Registry Update WG to consider the following documents: - 'Initial Language Subtag Registry ' as an Informational RFC - 'Tags for Identifying Languages ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-09-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 23 13:24:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cVK-0000aX-RJ; Tue, 23 Aug 2005 13:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cVJ-0000aP-Jz for ltru@megatron.ietf.org; Tue, 23 Aug 2005 13:24:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16707 for ; Tue, 23 Aug 2005 13:23:58 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7cVM-0003Hq-5P for ltru@ietf.org; Tue, 23 Aug 2005 13:24:11 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 10:23:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] AD Evaluation Comments: draft-ietf-ltru-registry-12 anddraft-ietf-ltru-initial-04 Date: Tue, 23 Aug 2005 10:23:43 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C8B44F5@irvmbxw01.quest.com> Thread-Topic: [Ltru] AD Evaluation Comments: draft-ietf-ltru-registry-12 anddraft-ietf-ltru-initial-04 Thread-Index: AcWn/u8pCWAvOJPTR8m5BCc1o0qk1AACFrew From: "Addison Phillips" To: "Scott Hollenbeck" , X-OriginalArrivalTime: 23 Aug 2005 17:23:44.0146 (UTC) FILETIME=[69B25720:01C5A807] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Scott, I have added this item to my edit list and editor's copy. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Scott Hollenbeck > Sent: 2005?8?23? 9:23 > To: ltru@ietf.org > Subject: [Ltru] AD Evaluation Comments: draft-ietf-ltru-registry-12 > anddraft-ietf-ltru-initial-04 >=20 > Both documents are ready for IETF last call. I found only one small = issue > with draft-ietf-ltru-registry-12. >=20 > It's common practice to note documents being obsoleted in the first = page > document header. It should be noted that RFC 3066 is being obsoleted. > This > can be done using xml2rfc as follows: >=20 > docName=3D"draft-ietf-ltru-registry-12.txt"> >=20 > Yes, I noticed the text in the introduction. Both are needed. >=20 > This is not a significant issue. Add it to the queue for processing = after > the last call has been completed. >=20 > I will ask to have the documents last-called as part of a joint > announcement. They will then be evaluated by the IESG as part of the = same > ballot. >=20 > -Scott- >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 01:24:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nko-0001QN-60; Wed, 24 Aug 2005 01:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nkm-0001QD-KN for ltru@megatron.ietf.org; Wed, 24 Aug 2005 01:24:48 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01602 for ; Wed, 24 Aug 2005 01:24:47 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7njT-0004LH-7x for ltru@lists.ietf.org; Wed, 24 Aug 2005 07:23:27 +0200 Received: from c-180-160-105.hh.dial.de.ignite.net ([62.180.160.105]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Aug 2005 07:23:27 +0200 Received: from nobody by c-180-160-105.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Aug 2005 07:23:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 24 Aug 2005 07:22:25 +0200 Organization: Lines: 20 Message-ID: <430C0411.3823@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-105.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' to BCP) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The IESG wrote: > The IESG has received a request from the Language Tag > Registry Update WG to consider [...] > as a BCP JFTR, nothing new, I still prefer standards track: 3066bis could obsolete 3066 (BCP 47) also as PS. 3066ter oould integrate ISO 639-3 as DS (minor update) 3066tetra oould integrate ISO 639-6 as STD Okay, not a real protocol, all hate "three-step", the works. OTOH we already know that there will be at least a 3066ter, and I consider STD as "better" than BCP (maybe unjustified, but many BCPs are only IETF-internal meta / admin documents) Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 10:36:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wN8-0006SH-VO; Wed, 24 Aug 2005 10:36:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wN7-0006SC-7X for ltru@megatron.ietf.org; Wed, 24 Aug 2005 10:36:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24778 for ; Wed, 24 Aug 2005 10:36:55 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wNR-0002IS-50 for ltru@ietf.org; Wed, 24 Aug 2005 10:37:18 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5AAD5320096; Wed, 24 Aug 2005 16:36:38 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05495-01; Wed, 24 Aug 2005 16:36:32 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE879320095; Wed, 24 Aug 2005 16:36:30 +0200 (CEST) Date: Tue, 23 Aug 2005 23:25:34 -0700 From: Harald Tveit Alvestrand To: Frank Ellermann , ltru@ietf.org Subject: Re: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' to BCP) Message-ID: <65D2DF6E6CDF6D4FA2E40359@B50854F0A9192E8EC6CDA126> In-Reply-To: <430C0411.3823@xyzzy.claranet.de> References: <430C0411.3823@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.6 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On 24. august 2005 07:22 +0200 Frank Ellermann wrote: > JFTR, nothing new, I still prefer standards track: > > 3066bis could obsolete 3066 (BCP 47) also as PS. > 3066ter oould integrate ISO 639-3 as DS (minor update) > 3066tetra oould integrate ISO 639-6 as STD can't do that.... it's added functionality..... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 11:13:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wwr-0000Ot-Cb; Wed, 24 Aug 2005 11:13:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wwj-0000Ob-U3 for ltru@megatron.ietf.org; Wed, 24 Aug 2005 11:13:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27200 for ; Wed, 24 Aug 2005 11:13:43 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wx1-0003dG-Q6 for ltru@ietf.org; Wed, 24 Aug 2005 11:14:07 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j7OFDIVm007720; Wed, 24 Aug 2005 08:13:18 -0700 (PDT) Received: by admsrvnt022.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Aug 2005 08:15:19 -0700 Message-ID: From: "McDonald, Ira" To: "'Harald Tveit Alvestrand'" , Frank Ellermann , ltru@ietf.org Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' to BCP) Date: Wed, 24 Aug 2005 08:15:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Harald, Thanks for pointing out that one can't add functionality to an IETF 'standards track' document and simultaneously advance it on the 'standards track'. The new version MUST stay at the same level as the previous version. So all of those updates below in Frank's suggested list would have to be published as 'PS' (Proposed Std) and then later be advanced on the 'standards track'. Which is (possibly) the rationale for RFC3066bis staying 'BCP'. Implementors are warned in the IETF standards process that a 'PS' may well change significantly before advancing to 'DS'. Perceived instability in language tag specifications isn't going to help their adoption. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org]On Behalf Of > Harald Tveit Alvestrand > Sent: Wednesday, August 24, 2005 2:26 AM > To: Frank Ellermann; ltru@ietf.org > Subject: Re: [Ltru] STD (was: Last Call: 'Tags for Identifying > Languages' to BCP) > > > > > --On 24. august 2005 07:22 +0200 Frank Ellermann > > wrote: > > > JFTR, nothing new, I still prefer standards track: > > > > 3066bis could obsolete 3066 (BCP 47) also as PS. > > 3066ter oould integrate ISO 639-3 as DS (minor update) > > 3066tetra oould integrate ISO 639-6 as STD > > can't do that.... it's added functionality..... > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 11:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xDe-0000lC-JI; Wed, 24 Aug 2005 11:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xDc-0000l7-TP for ltru@megatron.ietf.org; Wed, 24 Aug 2005 11:31:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28732 for ; Wed, 24 Aug 2005 11:31:10 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xDx-0004Qd-BQ for ltru@ietf.org; Wed, 24 Aug 2005 11:31:34 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7OFV2A5006249 for ; Wed, 24 Aug 2005 11:31:02 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7OFV18a244460 for ; Wed, 24 Aug 2005 11:31:02 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7OFV1aR026768 for ; Wed, 24 Aug 2005 11:31:01 -0400 Received: from [127.0.0.1] (sig-9-48-121-238.mts.ibm.com [9.48.121.238]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7OFV049026405 for ; Wed, 24 Aug 2005 11:31:01 -0400 Message-ID: <430C92AE.9050705@icu-project.org> Date: Wed, 24 Aug 2005 08:30:54 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: LTRU Working Group References: <007001c59fc7$a7738040$7f1afea9@oemcomputer> In-Reply-To: <007001c59fc7$a7738040$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ltru] Minor regret X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I'll send this out just so it is on record. I am not proposing any change at this point in the game; just regretting slightly that we did not include the following text, to allow us some wriggle-room in the future. "All non-initial 4 character subtags that are not legal according to the above ABNF are reserved for possible future use as script or orthography subtags. Examples: Lat1, B123 All non-initial 2 and 3 character subtags that are not legal according to the above ABNF are reserved for possible future use as region subtags. Examples: C1, 12, C34, UZ5, 6AB" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 11:49:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xVH-0006pX-Pj; Wed, 24 Aug 2005 11:49:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xVG-0006pS-Qq for ltru@megatron.ietf.org; Wed, 24 Aug 2005 11:49:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29695 for ; Wed, 24 Aug 2005 11:49:24 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xVb-000533-78 for ltru@ietf.org; Wed, 24 Aug 2005 11:49:48 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 08:49:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' to BCP) Date: Wed, 24 Aug 2005 08:49:10 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C9A5546@irvmbxw01.quest.com> Thread-Topic: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' to BCP) Thread-Index: AcWovuSlBxl+lHmbReyHdm+vH9tlLAAAxOgg From: "Addison Phillips" To: "McDonald, Ira" , "Harald Tveit Alvestrand" , "Frank Ellermann" , X-OriginalArrivalTime: 24 Aug 2005 15:49:11.0307 (UTC) FILETIME=[5ED58DB0:01C5A8C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I don't necessarily agree that the changes in 3066ter, etc., would mark = a change in functionality. The changes would be to the rules affecting = registration of values in the registry. I believe that we have described = the operation of the tags themselves completely in 3066bis. ISO 639-6 codes are easily dealt with: there is a slot reserved for them = in the ABNF that implementers ignore at their peril and the only change = is the management of registrations. ISO 639-3 is slightly more complicated. Most values are simply added to = the existing language subtag collection (no change for = implementations!!!). The big change is that extlang subtags can be = registered. Rules for deciding what is an extlang and what is not may = need to be worked through (although I expect that ISO 639-3 itself will = provide the rationale there). But notice that Section 2.2.2 in = draft-registry already says *exactly* what form these subtags will take = and how to handle them! In other words, I don't see how small rules tweaks on what is allowed = into the registry (not the format of the registry or of subtags, please = note) would affect implementations. We could follow the Std track along = the lines of what Frank says, provided the scenario above is correct. Of course, I do not object to going down the BCP path either. It makes = no difference in practice. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > McDonald, Ira > Sent: 2005?8?24? 8:15 > To: 'Harald Tveit Alvestrand'; Frank Ellermann; ltru@ietf.org > Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying = Languages' > to BCP) >=20 > Hi Harald, >=20 > Thanks for pointing out that one can't add functionality to an > IETF 'standards track' document and simultaneously advance it on > the 'standards track'. The new version MUST stay at the same > level as the previous version. So all of those updates below > in Frank's suggested list would have to be published as 'PS' > (Proposed Std) and then later be advanced on the 'standards > track'. >=20 > Which is (possibly) the rationale for RFC3066bis staying 'BCP'. > Implementors are warned in the IETF standards process that a > 'PS' may well change significantly before advancing to 'DS'. > Perceived instability in language tag specifications isn't going > to help their adoption. >=20 > Cheers, > - Ira >=20 > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com >=20 > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org]On Behalf = Of > > Harald Tveit Alvestrand > > Sent: Wednesday, August 24, 2005 2:26 AM > > To: Frank Ellermann; ltru@ietf.org > > Subject: Re: [Ltru] STD (was: Last Call: 'Tags for Identifying > > Languages' to BCP) > > > > > > > > > > --On 24. august 2005 07:22 +0200 Frank Ellermann > > > > wrote: > > > > > JFTR, nothing new, I still prefer standards track: > > > > > > 3066bis could obsolete 3066 (BCP 47) also as PS. > > > 3066ter oould integrate ISO 639-3 as DS (minor update) > > > 3066tetra oould integrate ISO 639-6 as STD > > > > can't do that.... it's added functionality..... > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 12:00:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xgH-0001nE-5G; Wed, 24 Aug 2005 12:00:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xgG-0001n8-1F for ltru@megatron.ietf.org; Wed, 24 Aug 2005 12:00:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00365 for ; Wed, 24 Aug 2005 12:00:45 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xgY-0005PG-NM for ltru@ietf.org; Wed, 24 Aug 2005 12:01:10 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 09:00:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Minor regret Date: Wed, 24 Aug 2005 09:00:32 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C9A555C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Minor regret Thread-Index: AcWowOFJDXBJ0bEOT6W2DSZvaq4VyAAAsSlg From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 24 Aug 2005 16:00:32.0720 (UTC) FILETIME=[F4FCED00:01C5A8C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1564006997==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1564006997== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QWN0dWFsbHksIEkgZG9uJ3QgcmVncmV0IHRoaXMuDQoNClllcywgdGhlcmUgYXJlIGEgZmV3IHN1 YnRhZyBmb3JtcyB0aGF0IGNvdWxkIGJlIGV4cGxvaXRlZCBpbiB0aGUgZnV0dXJlLCBidXQgSSBo YXZlIHRvIGFkbWl0IHRoYXQ6DQoNCjEuIEFzIGFuIGltcGxlbWVudGVyIEkgZG9uJ3QgbGlrZSB0 aGUgaWRlYSBoYXZpbmcgdG8gYW5hbHl6ZSB0aGUgY29udGVudCBvZiBlYWNoIGNoYXJhY3RlciBp biBhIHN1YnRhZyBpbiBvcmRlciB0byByZWNvZ25pemUgdGhlIHN1YnRhZyB0eXBlLiBBbGwgc3Vi dGFncyBkaXN0aW5ndWlzaGVkIGJ5IGNvbnRlbnQgaW4gdGhlIGN1cnJlbnQgZ3JhbW1hciBhcmUg ZGlzdGluZ3Vpc2hlZCBvbiB0aGUgZmlyc3QgY2hhcmFjdGVyLiBUaGVyZSBhcmUgdHdvIHN1Y2gg Y2FzZXMgbm93Og0KDQotIDQgY2hhcmFjdGVyczogVmFyaWFudCAoaW5pdGlhbCBkaWdpdCkgdnMu IHNjcmlwdCAoaW5pdGlhbCBhbHBoYSkNCi0gMyBjaGFyYWN0ZXJzOiBleHRsYW5nIChpbml0aWFs IGFscGhhKSB2cy4gVU4gTS40OSBjb2RlIChpbml0aWFsIGRpZ2l0KQ0KDQoyLiBJIHRoaW5rIHRo ZSAiem9vIiBvZiBwb3RlbnRpYWwgc3VidGFncyBpcyBleG90aWMgZW5vdWdoLiBBbnkgYWRkaXRp b25hbCBzdWJ0YWcgdHlwZXMgd2lsbCBmYWxsIGludG8gdGhlIHJlYWxtIG9mIGV4dGVuc2lvbnMg KGFuZCBnb29kIHJpZGRhbmNlKS4gVGhlIHN1YnRhZyBzY2hlbWUgc2hvdWxkIGJlIGFzIHNpbXBs ZSBhcyBwb3NzaWJsZS4gVGhlIGV4aXN0aW5nIDMwNjZiaXMgZ3JhbW1hciBpcyBjb21wbGV4IGVu b3VnaCB0byBiZSBwb3dlcmZ1bCwgYnV0IHNpbXBsZSBlbm91Z2ggdGhhdCB1c2VycyBjYW4gZ3Jh c3AgaXQuIE1vcmUgc3VidGFnIHR5cGVzIHdpbGwgbWFrZSB0YWdzIG1vcmUgZGlmZmljdWx0IHRv IHdvcmsgd2l0aC4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6 YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBh IGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IE1hcmsgRGF2aXMNCj4gU2VudDogMjAwNeW5 tDjmnIgyNOaXpSA4OjMxDQo+IENjOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogW0x0 cnVdIE1pbm9yIHJlZ3JldA0KPiANCj4gSSdsbCBzZW5kIHRoaXMgb3V0IGp1c3Qgc28gaXQgaXMg b24gcmVjb3JkLiBJIGFtIG5vdCBwcm9wb3NpbmcgYW55DQo+IGNoYW5nZSBhdCB0aGlzIHBvaW50 IGluIHRoZSBnYW1lOyBqdXN0IHJlZ3JldHRpbmcgc2xpZ2h0bHkgdGhhdCB3ZSBkaWQNCj4gbm90 IGluY2x1ZGUgdGhlIGZvbGxvd2luZyB0ZXh0LCB0byBhbGxvdyB1cyBzb21lIHdyaWdnbGUtcm9v bSBpbiB0aGUNCj4gZnV0dXJlLg0KPiANCj4gIkFsbCBub24taW5pdGlhbCA0IGNoYXJhY3RlciBz dWJ0YWdzIHRoYXQgYXJlIG5vdCBsZWdhbCBhY2NvcmRpbmcgdG8gdGhlDQo+IGFib3ZlIEFCTkYg YXJlIHJlc2VydmVkIGZvciBwb3NzaWJsZSBmdXR1cmUgdXNlIGFzIHNjcmlwdCBvciBvcnRob2dy YXBoeQ0KPiBzdWJ0YWdzLiBFeGFtcGxlczogTGF0MSwgQjEyMw0KPiANCj4gQWxsIG5vbi1pbml0 aWFsIDIgYW5kIDMgY2hhcmFjdGVyIHN1YnRhZ3MgdGhhdCBhcmUgbm90IGxlZ2FsIGFjY29yZGlu Zw0KPiB0byB0aGUgYWJvdmUgQUJORiBhcmUgcmVzZXJ2ZWQgZm9yIHBvc3NpYmxlIGZ1dHVyZSB1 c2UgYXMgcmVnaW9uDQo+IHN1YnRhZ3MuIEV4YW1wbGVzOiBDMSwgMTIsIEMzNCwgVVo1LCA2QUIi DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============1564006997== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1564006997==-- From ltru-bounces@ietf.org Wed Aug 24 12:20:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xz0-0001EB-Ox; Wed, 24 Aug 2005 12:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xyx-0001Dv-Ue for ltru@megatron.ietf.org; Wed, 24 Aug 2005 12:20:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02012 for ; Wed, 24 Aug 2005 12:20:05 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xzH-0006Gl-PJ for ltru@ietf.org; Wed, 24 Aug 2005 12:20:30 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j7OGJh1e017952; Wed, 24 Aug 2005 12:19:43 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 24 Aug 2005 12:19:40 -0400 Date: Wed, 24 Aug 2005 12:19:40 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' to BCP) Message-ID: <20050824161940.GL24920@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C9A5546@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C9A5546@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > ISO 639-3 is slightly more complicated. Most values are simply > added to the existing language subtag collection (no change for > implementations!!!). The big change is that extlang subtags can be > registered. Rules for deciding what is an extlang and what is not may > need to be worked through (although I expect that ISO 639-3 itself > will provide the rationale there). Indeed. We'll probably want to issue another I-D to reload the registry with all the thousands of new values. Another reason for going dormant rather than shutting up shop when RFC 3066bis and friends are finished. > Of course, I do not object to going down the BCP path either. It makes > no difference in practice. Quite so. A process question: does a BCP go into effect when it is passed for publication as an RFC, or when it is actually published as an RFC, months or years later? -- Dream projects long deferred John Cowan usually bite the wax tadpole. http://www.ccil.org/~cowan --James Lileks http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 12:51:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yT1-0002JN-SX; Wed, 24 Aug 2005 12:51:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ySz-0002JC-LN for ltru@megatron.ietf.org; Wed, 24 Aug 2005 12:51:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04318 for ; Wed, 24 Aug 2005 12:51:07 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7yTL-0007Tr-N7 for ltru@ietf.org; Wed, 24 Aug 2005 12:51:32 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE0C7320091; Wed, 24 Aug 2005 18:50:54 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08150-08; Wed, 24 Aug 2005 18:50:51 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 53A9332008F; Wed, 24 Aug 2005 18:50:48 +0200 (CEST) Date: Wed, 24 Aug 2005 09:50:22 -0700 From: Harald Tveit Alvestrand To: "John.Cowan" , Addison Phillips Subject: Re: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' to BCP) Message-ID: <7942E2FF318E4D56A09EC8D4@B50854F0A9192E8EC6CDA126> In-Reply-To: <20050824161940.GL24920@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C9A5546@irvmbxw01.quest.com> <20050824161940.GL24920@NYCMJCOWA2> X-Mailer: Mulberry/4.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --On 24. august 2005 12:19 -0400 "John.Cowan" wrote: >> Of course, I do not object to going down the BCP path either. It makes >> no difference in practice. > > Quite so. > > A process question: does a BCP go into effect when it is passed for > publication as an RFC, or when it is actually published as an RFC, > months or years later? When it is passed (see tradition with BCP 101). Setting up the administrative details to actually act like the BCP says can take a little time, of course. Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 13:26:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z1f-0000CN-2g; Wed, 24 Aug 2005 13:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z1d-0000CF-RQ for ltru@megatron.ietf.org; Wed, 24 Aug 2005 13:26:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06718 for ; Wed, 24 Aug 2005 13:26:55 -0400 (EDT) Received: from tumbleweed1.tumbleweed.com ([216.148.213.196] helo=mailgate1.tumbleweed.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7z20-0000T3-3b for ltru@ietf.org; Wed, 24 Aug 2005 13:27:20 -0400 X-Mail-Filter: Tumbleweed MailGate 2.5.1-4097 Received: by mailgate1.tumbleweed.com (Tumbleweed MailGate, from userid 124) id 641BC33C018; Wed, 24 Aug 2005 10:16:37 -0700 (PDT) X-TMWD-Spam-Summary: SEV=1.1; DFV=A2005081707; IFV=2.0.4,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34333033393546382E303034433A534346454F31313438302D462D586C496B3278353041585648704F677067516E4E68773D3D; ENG=IBF; TS=20050817195702; CAT=NONE; CON=NONEX-MMS-Spam-Filter-ID: A2005081707 X-Filter-Reason: Magic; 119; 0ILDU32-28CA-00G; A5A9BA8BC300458C37D098FB43FA7363 X-Mail-Filter: Tumbleweed MailGate 2.5.1-4088 Received: from mgedge1.tumbleweed.com (mgedge1.tumbleweed.com [10.48.5.13]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mailgate1.tumbleweed.com (Tumbleweed MailGate) with ESMTP id 3B75733C004 for ; Wed, 17 Aug 2005 12:57:02 -0700 (PDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgedge1.tumbleweed.com (Tumbleweed MailGate Edge) with ESMTP id E409DF0003 for ; Wed, 17 Aug 2005 13:05:13 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvK-0007h3-FX; Wed, 17 Aug 2005 15:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvH-0007f5-6q; Wed, 17 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21150; Wed, 17 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5UUs-0001di-BQ; Wed, 17 Aug 2005 16:26:50 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5TvG-0001wF-2H; Wed, 17 Aug 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Aug 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-11.txt X-BeenThere: ltru@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-registry-11.txt Pages : 60 Date : 2005-8-17 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-registry-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-registry-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-17143958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-17143958.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Wed Aug 24 13:27:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z1m-0000D9-De; Wed, 24 Aug 2005 13:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z1j-0000Cy-S2 for ltru@megatron.ietf.org; Wed, 24 Aug 2005 13:27:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06729 for ; Wed, 24 Aug 2005 13:27:01 -0400 (EDT) Received: from tumbleweed1.tumbleweed.com ([216.148.213.196] helo=mailgate1.tumbleweed.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7z25-0000T9-0d for ltru@ietf.org; Wed, 24 Aug 2005 13:27:26 -0400 X-Mail-Filter: Tumbleweed MailGate 2.5.1-4097 Received: by mailgate1.tumbleweed.com (Tumbleweed MailGate, from userid 124) id 7773233C08A; Wed, 24 Aug 2005 10:16:36 -0700 (PDT) X-TMWD-Spam-Summary: SEV=1.1; DFV=A2005081707; IFV=2.0.4,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34333033393439422E303031453A534346454F31313438302D462D586C496B3278353041585648704F677067516E4E68773D3D; ENG=IBF; TS=20050817195029; CAT=NONE; CON=NONEX-MMS-Spam-Filter-ID: A2005081707 X-Filter-Reason: Magic; 112; 0ILDTS5-28CA-00R; 5623C16D002FD186A944BC1BD4F6FC0B X-Mail-Filter: Tumbleweed MailGate 2.5.1-4088 Received: from mgedge1.tumbleweed.com (mgedge1.tumbleweed.com [10.48.5.13]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mailgate1.tumbleweed.com (Tumbleweed MailGate) with ESMTP id 3290F33C004 for ; Wed, 17 Aug 2005 12:50:29 -0700 (PDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgedge1.tumbleweed.com (Tumbleweed MailGate Edge) with ESMTP id E978DF0002 for ; Wed, 17 Aug 2005 12:58:40 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvQ-0007nk-BP; Wed, 17 Aug 2005 15:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvH-0007gB-Nc; Wed, 17 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21149; Wed, 17 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5UUs-0001dX-7j; Wed, 17 Aug 2005 16:26:50 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5TvF-0001vm-Sr; Wed, 17 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-initial-04.txt X-BeenThere: ltru@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Initial Language Subtag Registry Author(s) : D. Ewell Filename : draft-ietf-ltru-initial-04.txt Pages : 118 Date : 2005-8-17 This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-initial-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-initial-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-17115325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-initial-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-initial-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-17115325.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Wed Aug 24 13:29:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z4W-0000nL-NJ; Wed, 24 Aug 2005 13:29:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z4U-0000n9-K8 for ltru@megatron.ietf.org; Wed, 24 Aug 2005 13:29:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06884 for ; Wed, 24 Aug 2005 13:29:51 -0400 (EDT) Received: from tumbleweed1.tumbleweed.com ([216.148.213.196] helo=mailgate1.tumbleweed.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7z4q-0000Zh-NM for ltru@ietf.org; Wed, 24 Aug 2005 13:30:17 -0400 X-Mail-Filter: Tumbleweed MailGate 2.5.1-4097 Received: by mailgate1.tumbleweed.com (Tumbleweed MailGate, from userid 124) id 18C9333C018; Wed, 24 Aug 2005 10:16:49 -0700 (PDT) X-TMWD-Spam-Summary: SEV=1.1; DFV=A2005081807; IFV=2.0.4,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34333034453645412E303033433A534346454F31313438302D462D586C496B3278353041585648704F677067516E4E68773D3D; ENG=IBF; TS=20050818195439; CAT=NONE; CON=NONEX-MMS-Spam-Filter-ID: A2005081807 X-Filter-Reason: Magic; 119; 0ILFON3-28CA-02H; 6F6DA5711B682C3FB009BE82EBC27994 X-Mail-Filter: Tumbleweed MailGate 2.5.1-4088 Received: from mgedge1.tumbleweed.com (mgedge1.tumbleweed.com [10.48.5.13]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mailgate1.tumbleweed.com (Tumbleweed MailGate) with ESMTP id E59A133C004 for ; Thu, 18 Aug 2005 12:54:38 -0700 (PDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgedge1.tumbleweed.com (Tumbleweed MailGate Edge) with ESMTP id 02ECAF0004 for ; Thu, 18 Aug 2005 13:02:55 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qP1-0003kN-5g; Thu, 18 Aug 2005 15:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qOr-0003hq-4f; Thu, 18 Aug 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27330; Thu, 18 Aug 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5qye-0003lw-Gs; Thu, 18 Aug 2005 16:27:05 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5qOn-00074x-J5; Thu, 18 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-12.txt X-BeenThere: ltru@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-registry-12.txt Pages : 60 Date : 2005-8-18 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-registry-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-registry-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-18123207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-18123207.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Wed Aug 24 13:42:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zGw-0005HL-BY; Wed, 24 Aug 2005 13:42:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zGu-0005HD-GH for ltru@megatron.ietf.org; Wed, 24 Aug 2005 13:42:44 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07484 for ; Wed, 24 Aug 2005 13:42:43 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7zF5-0002pl-9c for ltru@lists.ietf.org; Wed, 24 Aug 2005 19:40:51 +0200 Received: from c-180-160-132.hh.dial.de.ignite.net ([62.180.160.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Aug 2005 19:40:51 +0200 Received: from nobody by c-180-160-132.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Aug 2005 19:40:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 24 Aug 2005 19:37:52 +0200 Organization: Lines: 15 Message-ID: <430CB070.370C@xyzzy.claranet.de> References: <430C0411.3823@xyzzy.claranet.de> <65D2DF6E6CDF6D4FA2E40359@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-132.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: STD X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Harald Tveit Alvestrand wrote: > can't do that.... it's added functionality..... The extlang is already there, 3066ter will more or less allow a bulk update, because the tag review list + IANA won't like to handle 6000+ registrations "manually". The "functionality" won't change, some minor editorial changes mentioning 639-3. One of these IETF mysteries, but you got me to read 2026 6.2 twice. It's something on my side, I don't like the mixture of "real" documents like 3066bis and "meta" documents like 3934 in the same BCP series. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 14:06:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zda-0006Ql-MJ; Wed, 24 Aug 2005 14:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zdZ-0006Qd-69 for ltru@megatron.ietf.org; Wed, 24 Aug 2005 14:06:09 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09218 for ; Wed, 24 Aug 2005 14:06:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7zbe-00083u-6r for ltru@lists.ietf.org; Wed, 24 Aug 2005 20:04:10 +0200 Received: from c-180-160-132.hh.dial.de.ignite.net ([62.180.160.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Aug 2005 20:04:10 +0200 Received: from nobody by c-180-160-132.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Aug 2005 20:04:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 24 Aug 2005 20:00:51 +0200 Organization: Lines: 18 Message-ID: <430CB5D3.2A29@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C9A5546@irvmbxw01.quest.com> <20050824161940.GL24920@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-132.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] IANA effects (was: STD) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John.Cowan wrote: > A process question: does a BCP go into effect when it is > passed for publication as an RFC, or when it is actually > published as an RFC, months or years later? On average four months, not years. For an RfC the "effect" (as far as IANA is concerned) is apparently very fast, one experimental RfC approved less than two months ago with two IANA "effects" is ready for at least three weeks now, IIRC. In other words, IMHO we can post registration requests for missing Suppress-Scripts as soon as IANA is ready with the initial registry. Or in theory one minute after it was approved, but waiting until we're sure that IANA got the idea might be better. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 24 14:19:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zql-0001us-J4; Wed, 24 Aug 2005 14:19:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zqj-0001uk-Fz for ltru@megatron.ietf.org; Wed, 24 Aug 2005 14:19:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09744 for ; Wed, 24 Aug 2005 14:19:44 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zr4-0002IK-VR for ltru@ietf.org; Wed, 24 Aug 2005 14:20:08 -0400 Received: from h-64-105-136-41.snvacaid.dynamic.covad.net ([64.105.136.41] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E7zqb-0001tF-00 for ltru@ietf.org; Wed, 24 Aug 2005 14:19:37 -0400 Message-ID: <00c201c5a8d8$a1a87020$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C9A5546@irvmbxw01.quest.com><20050824161940.GL24920@NYCMJCOWA2> <430CB5D3.2A29@xyzzy.claranet.de> Subject: Re: [Ltru] IANA effects (was: STD) Date: Wed, 24 Aug 2005 11:20:24 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Wednesday, August 24, 2005 11:00 AM > Subject: [Ltru] IANA effects (was: STD) ... > On average four months, not years. For an RfC the "effect" > (as far as IANA is concerned) is apparently very fast, one > experimental RfC approved less than two months ago with two > IANA "effects" is ready for at least three weeks now, IIRC. ... Before a document is even approved for hand-off to the RFC editor, IANA will take a look at in in conjunction with the IESG review. In my experience, they go through the IANA considerations sections *very* carefully, and are not shy about asking questions or requesting clarification. Consequently, by the time the RFC appears, IANA has already known for some time what would need to be done to implement a registry, so it should not come as a surprise that they are able to activate them quickly. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 26 00:23:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8VkO-00053E-1I; Fri, 26 Aug 2005 00:23:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8VkM-00052g-7C for ltru@megatron.ietf.org; Fri, 26 Aug 2005 00:23:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12286; Fri, 26 Aug 2005 00:23:14 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Vkz-0006xJ-Ga; Fri, 26 Aug 2005 00:23:58 -0400 Received: from h-64-105-136-156.snvacaid.dynamic.covad.net ([64.105.136.156] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E8VkE-0002l4-00; Fri, 26 Aug 2005 00:23:10 -0400 Message-ID: <001901c5a9f6$1b83d240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Scott Hollenbeck" , Date: Thu, 25 Aug 2005 21:24:52 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: LTRU Working Group Subject: [Ltru] completion of ltru WG milestone X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - The ltru WG was completed the following milestone from its charter: Aug 05 Submit registry structure draft for IETF Last Call Please update the charter to mark this item "done". Randy Presuhn, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 26 00:34:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Vva-00015t-IA; Fri, 26 Aug 2005 00:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8VvZ-00015l-7v for ltru@megatron.ietf.org; Fri, 26 Aug 2005 00:34:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12624 for ; Fri, 26 Aug 2005 00:34:50 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8VwC-0007Dw-PX for ltru@ietf.org; Fri, 26 Aug 2005 00:35:34 -0400 Received: from h-64-105-136-156.snvacaid.dynamic.covad.net ([64.105.136.156] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E8VvW-0005MT-00 for ltru@ietf.org; Fri, 26 Aug 2005 00:34:50 -0400 Message-ID: <002d01c5a9f7$beb0c800$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C8B3EE1@irvmbxw01.quest.com><430A7912.8060403@icu-project.org> <6.0.0.20.2.20050823114424.08b99410@itmail.it.aoyama.ac.jp> Date: Thu, 25 Aug 2005 21:36:36 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ltru] Re: Distance Metric X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - ... At 10:17 05/08/23, Mark Davis wrote: >I think the scored matching would be better framed as a 'distance' metric. >Here is suggested replacement text: ... >Implementations may want to use more sophisticated weights that depend on editorial: you mean "Implementations MAY use more sophisticated..." right? >the values of the corresponding elements. For example, depending on the >domain, an implemenation might give a small distance to the difference might -> MAY? >between 'no' and 'nb' or 'nn'; or between 'Kata' and 'Hira'; or between >'US' and 'UM'. ... There are obviously lots of *possible* distance metrics for use in scored matching algorithms. However, as a technical contributor, I think it's helpful to keep in mind what our charter asks us to do: | The second document will describe matching algorithms for use with | language tags. Language tags are used in a broad variety of contexts | and it is not expected that any single matching algorithm will fit all | needs. Developing a small set of common matching algorithms does seem | likely to contribute to interoperability, however, as it seems likely | that using protocols could reference these well-known algorithms in | their specifications. I think the phrase "a small set of common matching algorithms" is important. Consequently, I think the discussion about what distance metrics *might* be used, while perhaps of academic interest, doesn't belong in this document unless we plan to use in one of the algorithms in our "small set" in order to foster interoperability. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 26 09:26:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8eEL-00076P-1m; Fri, 26 Aug 2005 09:26:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8eEK-00076B-1d for ltru@megatron.ietf.org; Fri, 26 Aug 2005 09:26:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19125 for ; Fri, 26 Aug 2005 09:26:46 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8eF2-0006RW-D9 for ltru@ietf.org; Fri, 26 Aug 2005 09:27:33 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 06:26:36 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 06:26:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 26 Aug 2005 06:26:45 -0700 Message-ID: Thread-Topic: update on ISO 639 Thread-Index: AcWqQc3Yg6S4OMG3TXiiTIDfzIEmUw== From: "Peter Constable" To: X-OriginalArrivalTime: 26 Aug 2005 13:26:36.0649 (UTC) FILETIME=[C8AFD590:01C5AA41] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Subject: [Ltru] update on ISO 639 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2047319124==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============2047319124== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AA41.C850718F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AA41.C850718F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm on my way home from the TC 37 meeting in Warsaw, and thought I'd give a quick update on projects in the ISO 639 series. =20 ISO 639-3 is being advanced to its last stage, FDIS. If things stay on schedule, the FDIS ballot will be over - and ISO 639-3 will be an ISO standard -- before the end of the year. =20 Work is progressing on ISO 639-4 and ISO 639-5. These are not expected to have much impact on RFC 3066 or its successors, though (unless we change our minds about wanting to use additional IDs for collections). =20 An updated working draft for ISO 639-6 was made available just before the meeting. The leads for that project have been working through the impact of adopting the ISO 11179 framework for that project. The working group gave them the go ahead to reference ISO 12620, which (roughly) is the TC 37 counterpart to ISO 11179. They may still need to reference directly to ISO 11179 for certain purposes. The team for that project will be preparing a new working draft this fall for review by the working group, with the aim of getting it reading for a CD ballot - so potentially a CD ballot will be distributed before the end of the year. =20 =20 =20 Peter Constable ------_=_NextPart_001_01C5AA41.C850718F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m on my way home from the TC 37 meeting in = Warsaw, and = thought I’d give a quick update on projects in the ISO 639 = series.

 

ISO 639-3 is being advanced to its last stage, FDIS. = If things stay on schedule, the FDIS ballot will be over – and ISO = 639-3 will be an ISO standard -- before the end of the = year.

 

Work is progressing on ISO 639-4 and ISO 639-5. These = are not expected to have much impact on RFC 3066 or its successors, though = (unless we change our minds about wanting to use additional IDs for = collections).

 

An updated working draft for ISO 639-6 was made = available just before the meeting. The leads for that project have been working = through the impact of adopting the ISO 11179 framework for that project. The = working group gave them the go ahead to reference ISO 12620, which (roughly) is = the TC 37 counterpart to ISO 11179. They may still need to reference directly = to ISO 11179 for certain purposes. The team for that project will be preparing = a new working draft this fall for review by the working group, with the aim of = getting it reading for a CD ballot – so potentially a CD ballot will be distributed before the end of the year.

 

 

 

Peter = Constable

------_=_NextPart_001_01C5AA41.C850718F-- --===============2047319124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2047319124==-- From ltru-bounces@ietf.org Fri Aug 26 11:37:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gGR-0001kr-F1; Fri, 26 Aug 2005 11:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gGP-0001kd-WE for ltru@megatron.ietf.org; Fri, 26 Aug 2005 11:37:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27431 for ; Fri, 26 Aug 2005 11:37:03 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gH9-0002Ra-Ds for ltru@ietf.org; Fri, 26 Aug 2005 11:37:52 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7QFannR735770 for ; Fri, 26 Aug 2005 11:36:49 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7QFZhTJ317576 for ; Fri, 26 Aug 2005 09:35:43 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7QFZWfx006636 for ; Fri, 26 Aug 2005 09:35:32 -0600 Received: from [127.0.0.1] (sig-9-48-110-69.mts.ibm.com [9.48.110.69]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7QFZRGT006462; Fri, 26 Aug 2005 09:35:28 -0600 Message-ID: <430F36BE.7060900@icu-project.org> Date: Fri, 26 Aug 2005 08:35:26 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: Distance Metric References: <634978A7DF025A40BFEF33EB191E13BC0C8B3EE1@irvmbxw01.quest.com><430A7912.8060403@icu-project.org> <6.0.0.20.2.20050823114424.08b99410@itmail.it.aoyama.ac.jp> <002d01c5a9f7$beb0c800$7f1afea9@oemcomputer> In-Reply-To: <002d01c5a9f7$beb0c800$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > Hi - > > ... > At 10:17 05/08/23, Mark Davis wrote: > >>I think the scored matching would be better framed as a 'distance' metric. > > >Here is suggested replacement text: > ... > >>Implementations may want to use more sophisticated weights that depend on > > > editorial: you mean "Implementations MAY use more sophisticated..." right? > > >>the values of the corresponding elements. For example, depending on the >>domain, an implemenation might give a small distance to the difference > > > might -> MAY? For both of these, I think the normal English meaning is being used. All implementations are free to match in different ways. What is being describe here is not a standardized option on the method being described, but rather pointing the user to an alternative matching that could be employed. (see below). > > >between 'no' and 'nb' or 'nn'; or between 'Kata' and 'Hira'; or between > >'US' and 'UM'. > ... > > There are obviously lots of *possible* distance metrics for use in scored > matching algorithms. However, as a technical contributor, I think it's > helpful to keep in mind what our charter asks us to do: > > | The second document will describe matching algorithms for use with > | language tags. Language tags are used in a broad variety of contexts > | and it is not expected that any single matching algorithm will fit all > | needs. Developing a small set of common matching algorithms does seem > | likely to contribute to interoperability, however, as it seems likely > | that using protocols could reference these well-known algorithms in > | their specifications. > > I think the phrase "a small set of common matching algorithms" is important. > Consequently, I think the discussion about what distance metrics *might* be > used, while perhaps of academic interest, doesn't belong in this document > unless we plan to use in one of the algorithms in our "small set" in order to > foster interoperability. I agree that the goal of the document is to present a small list of well-defined matching algorithms. However, I think it is also not outside the scope to at least point out ways in which implementations may choose to reasonably extend the methods that we define. And it is also useful during the development state, to get people thinking about various options. > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 26 11:44:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gNa-0003Eo-Do; Fri, 26 Aug 2005 11:44:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gNZ-0003Eh-3K for ltru@megatron.ietf.org; Fri, 26 Aug 2005 11:44:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27696 for ; Fri, 26 Aug 2005 11:44:23 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gOF-0002fC-4n for ltru@ietf.org; Fri, 26 Aug 2005 11:45:12 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 08:44:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: matching for non-RFC3066bis langtags Date: Fri, 26 Aug 2005 08:44:03 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C9A5EE8@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: matching for non-RFC3066bis langtags Thread-Index: AcWngKyZ6OpS9ofPTvKC8uGAaFEHYAAiHlUQ From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 26 Aug 2005 15:44:04.0094 (UTC) FILETIME=[FC8C11E0:01C5AA54] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1393397339==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1393397339== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Q29tbWVudHMgZm9sbG93Lg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFy Y2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24g Q29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1 cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9y Z10NCj4gU2VudDogMjAwNeW5tDjmnIgyMuaXpSAxODoxNw0KPiBUbzogQWRkaXNvbiBQaGlsbGlw cw0KPiBDYzogRG91ZyBFd2VsbDsgTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBb THRydV0gUmU6IG1hdGNoaW5nIGZvciBub24tUkZDMzA2NmJpcyBsYW5ndGFncw0KPiANCj4gSSB0 aGluayB0aGUgc2NvcmVkIG1hdGNoaW5nIHdvdWxkIGJlIGJldHRlciBmcmFtZWQgYXMgYSAnZGlz dGFuY2UnIG1ldHJpYy4NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KSSBsaWtlIGEgZGlzdGFuY2Ug bWV0cmljIGJldHRlci4NCg0KPiBIZXJlIGlzIHN1Z2dlc3RlZCByZXBsYWNlbWVudCB0ZXh0Og0K PiA9PT09PQ0KPiANCj4gDQo+IEluIHRoZSAic2NvcmVkIG1hdGNoaW5nIiBzY2hlbWUsIHRoZSBl eHRlbmRlZCBsYW5ndWFnZSByYW5nZSAuLi4NCj4gLi4uDQo+IC4uLiBTSE9VTEQgcHJvYmFibHkg YWxsb3cgdXNlcnMgdG8gY2hvb3NlIHRoZSBtb3N0IGFwcHJvcHJpYXRlIHNlbGVjdGlvbg0KPiB2 YWx1ZS4NCj4gDQo+IA0KPiA9Pg0KPiANCj4gDQo+IEluIHRoZSAiZGlzdGFuY2UgbWV0cmljIiBz Y2hlbWUsIGEgbnVtZXJpYyB2YWx1ZSByZXByZXNlbnRpbmcgYSAnZGlzdGFuY2UnDQo+IGJldHdl ZW4gYSBsYW5ndWFnZSB0YWdzIGFuZCBhIGxhbmd1YWdlIHJhbmdlIGlzIGNvbXB1dGVkLiBBIGRp c3RhbmNlIG9mDQo+IHplcm8gbWVhbnMgdGhhdCB0aGV5IGFyZSBpZGVudGljYWwsIGEgc21hbGwg ZGlzdGFuY2UgaW5kaWNhdGVzIHRoYXQgdGhleQ0KPiBhcmUgdmVyeSBzaW1pbGFyLCBhbmQgYSBs YXJnZSBkaXN0YW5jZSBpbmRpY2F0ZWQgdGhhdCB0aGV5IGFyZSB2ZXJ5DQo+IGRpZmZlcmVudC4g R2l2ZW4gYSBkaXN0YW5jZSwgaW1wbGVtZW50YXRpb25zIGNhbiBhbGxvdyB1c2VycyB0byBzZWxl Y3QgYQ0KPiB0aHJlc2hvbGQgZGlzdGFuY2UgZm9yIGEgbWF0Y2ggdG8gYmUgc3VjY2Vzc2Z1bCBv ciBhIGZpbHRlciB0byBiZSBhcHBsaWVkLg0KPiANCj4gVGhlIGZpcnN0IHN0ZXAgaW4gdGhlIHBy b2Nlc3MgaXMgdG8gbm9ybWFsaXplIHRoZSBleHRlbmRlZCBsYW5ndWFnZSByYW5nZQ0KPiBhbmQg dGhlIGxhbmd1YWdlIHRhZ3MgYnkgY2Fub25pY2FsaXppbmcgYm90aCwgYW5kIG1hcHBpbmcgZ3Jh bmRmYXRoZXJlZA0KPiBhbmQgb2Jzb2xldGUgdGFncyBpbnRvIG1vZGVybiBlcXVpdmFsZW50cy4g SWYgdGhlcmUgaXMgbm8gc2NyaXB0LCB0aGVuIHRoZQ0KPiBTdXBwcmVzcy1TY3JpcHQgdmFsdWUg ZnJvbSB0aGUgcmVnaXN0cnkgaXMgYWRkZWQgYXMgdGhlIHNjcmlwdC4NCltBZGRpc29uIFBoaWxs aXBzXSANCg0KVGhpcyBpcyB3cm9uZyBmb3IgdHdvIHJlYXNvbnMuIA0KDQpGaXJzdCwgc29tZSBs YW5ndWFnZXMgZG8gbm90IGhhdmUgU3VwcHJlc3MtU2NyaXB0cyBhbmQgdGhlc2UgbGFuZ3VhZ2Vz IHdvdWxkIGJlIGF0IGEgZGlzYWR2YW50YWdlIG9yIGRpZmZpY3VsdCB0byBpbXBsZW1lbnQgZm9y LiBObyBvdGhlciBtYXRjaGluZyBzY2hlbWUgcmVxdWlyZXMgYWNjZXNzIHRvIHRoZSByZWdpc3Ry eSB0byBkbyBpdHMgd29yay4gVGhpcyBvbmUgcmVxdWlyZXMgc29tZSAoZm9yIHRoZSBjYW5vbmlj YWxpemF0aW9uIGp1c3QgbWVudGlvbmVkKSwgYnV0IHRoaXMgc3RyaWtlcyBtZSBhcyBhIGxlYXAg b2YgY29tcGxleGl0eSB0aGF0IG1heSBub3QgYmUgbmVjZXNzYXJ5Lg0KDQpTZWNvbmQsIGEgbWlz c2luZyB2YWx1ZSBpbiBhIHF1YWRydXBsZSBtYXkgYmUgbWlzc2luZyBmb3IgYSByZWFzb24uIEkg dGhpbmsgb25seSB0d28gdmFsdWVzIG1pZ2h0IHBvdGVudGlhbGx5IGJlIGFkZGVkIGZvciBhIG1p c3NpbmcgdmFsdWU6IHRoZSBlbXB0eSB2YWx1ZSBvciAiKiIuIEkgaGF2ZSB0byBxdWVzdGlvbiB3 aHkgc2NyaXB0IHdvdWxkIGJlIGRpZmZlcmVudCB0aGFuIG90aGVyIHN1YnRhZ3MgaGVyZS4uLg0K PiANCj4gVGhlIGxhbmd1YWdlIHJhbmdlIGFuZCB0aGUgbGFuZ3VhZ2UgdGFncyBhcmUgdGhlbiB0 cmFuc2Zvcm1lZCBpbnRvDQo+IHF1YWRydXBsZXMgb2YgZWxlbWVudHMgb2YgdGhlIGZvcm0gKGxh bmd1YWdlLCBzY3JpcHQsIGNvdW50cnksIHZhcmlhbnQpLg0KPiBBbnkgZXh0ZW5kZWQgbGFuZ3Vh Z2VzIGFyZSBjb25zaWRlcmVkIHBhcnQgb2YgdGhlIGxhbmd1YWdlIGVsZW1lbnQgYW5kIGFueQ0K PiBleHRlbnNpb24gc3VidGFnIHNlcXVlbmNlcyBhcmUgY29uc2lkZXJlZCAgcGFydCBvZiB0aGUg dmFyaWFudCBlbGVtZW50OyBhbg0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpJbmNsdWRpbmcgZXh0 ZW5zaW9ucyBpbiB2YXJpYW50IHdpbGwgc2tldyB0aGUgc2NvcmVzIGluIGFuIGluYXBwcm9wcmlh dGUgbWFubmVyLCBhdCBsZWFzdCBwb3RlbnRpYWxseS4gUGVyaGFwcyBleHRlbnNpb25zIHNob3Vs ZCBiZSBzY29yZWQgc2VwYXJhdGVseSBhbmQgYXQgYSBsb3dlciB2YWx1ZToNCg0KUmFuZ2U9c2wt SVQtcm96YWotci1mb28NCg0KU2wtSVQ6IDENClNsLUlULXJvemFqOiAxIC8vIGhtLi4uDQpTbC1J VC1yLWZvbzogMQ0KU2wtcm96YWo6IDUgLy8gaG0uLi4NClNsLXJvemFqLXItZm9vOiA0DQoNCg0K PiB4IHByaXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5jZXMgaXMgY29uc2lkZXJlZCBwYXJ0IG9mIHRo ZSBsYW5ndWFnZSBlbGVtZW50DQo+IGlmIGl0IGlzIGluaXRpYWwgYW5kIHBhcnQgb2YgdGhlIHZh cmlhbnQgZWxlbWVudCBpZiBub3QuIE1pc3NpbmcNCj4gY29tcG9uZW50cyBpbiB0aGUgbGFuZ3Vh Z2UgcmFuZ2UgYXJlIHNldCB0byAiKiI7IHRodXMgYSAiKiIgcGF0dGVybg0KPiBiZWNvbWVzIHRo ZSBxdWFkcnVwbGUgKCIqIiwgIioiLCAiKiIsICIqIikuIFN1YnRhZ3MgJ3VuZCcgYW5kICdaeXl5 JyBhcmUNCj4gY29udmVydGVkIHRvICIqIi4NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KV2hlcmUg ZGlkICdaeXl5JyBjb21lIGZyb20/IA0KDQpBbHNvOiBXaGF0IGFib3V0ICdtdWwnPyBEb2VzIGl0 IG1hdGNoICIqIj8gT3IganVzdCAnbXVsJz8NCj4gDQo+IA0KPiBFYWNoIGxhbmd1YWdlIHRhZyBi ZWluZyBtYXRjaGVkIG9yIGZpbHRlcmVkIGlzIGFzc2lnbmVkIGEgZGlzdGFuY2UsDQo+IHdoZXJl Ynkgc21hbGwgdmFsdWVzIGluZGljYXRlIGJldHRlciBtYXRjaGVzIGFuZCBsYXJnZSB2YWx1ZXMg aW5kaWNhdGUNCj4gd29yc2Ugb25lcy4gVGhlIGRpc3RhbmNlIGJldHdlZW4gdGhlIGxhbmd1YWdl IHRhZ3MgaXMgdGhlIHN1bSBvZiB0aGUNCj4gZGlzdGFuY2VzIGZvciBlYWNoIG9mIHRoZSBjb3Jy ZXNwb25kaW5nIGVsZW1lbnRzIG9mIHRoZSBxdWFkcnVwbGUuIElmIHRoZQ0KPiBlbGVtZW50cyBh cmUgaWRlbnRpY2FsIG9yIG9uZSBpcyAnKicsIHRoZW4gdGhlIGRpc3RhbmNlIGJldHdlZW4gdGhl bSBpcw0KPiB6ZXJvLiBPdGhlcndpc2UsIGl0IGlzIGdpdmVuIGJ5IHRoZSBmb2xsb3dpbmcgdGFi bGU6DQo+IA0KPiAgIDEyOCAgICBsYW5ndWFnZSBtaXNtYXRjaA0KPiAgICAzMiAgICBzY3JpcHQg bWlzbWF0Y2gNCj4gICAgIDQgICAgcmVnaW9uIG1pc21hdGNoDQo+ICAgICAxICAgIHZhcmlhbnQg bWlzbWF0Y2goZXMpDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCklzIHRoaXMgbGFzdCBtZWFudCB0 byBpbmRpY2F0ZSB0aGF0IGEgc2NvcmUgb2YgIjIiIGlzIHBvc3NpYmxlIGZvciB0d28gdmFyaWFu dCBtaXNtYXRjaGVzPyBPciBqdXN0IHRoYXQgbXVsdGlwbGUgc3VidGFncyBhcmUgcG9zc2libGUg dGhlcmU/IEkgcmVhZCBpdCBhcyB0aGUgbGF0dGVyLg0KDQpBbHNvOiBub3RlIHRoYXQgc3VidGFn IG9yZGVyIGlzIHNpZ25pZmljYW50IGluIHZhcmlhbnQgbWF0Y2hpbmcgaWYgb25lIGFzc3VtZXMg c2ltcGxlIHN0cmluZyBtYXRjaGluZy4NCg0KSSdtIGN1cmlvdXMgd2h5IHRoZSB2YWx1ZXMgYXJl IGVhY2ggYW4gYWRkaXRpb25hbCBwb3dlciBvZiB0d28gYXBhcnQuIElmIG11bHRpcGxlIHNjb3Jp bmcgb24gYSBsZXZlbCBpc24ndCBwb3NzaWJsZSwgdGhlbiBhbGwgdGhpcyBkb2VzIGlzIG1hZ25p ZnkgdGhlIGFwcGFyZW50IGRpc3RhbmNlLiANCj4gDQo+IEV4YW1wbGVzIG9mIGRpc3RhbmNlcyBm cm9tIGVuLVVTOg0KPiANCj4gDQo+ICAgICAgICAgIGZyOiAxMzINCj4gICAgICAgZW4tR0I6ICAg NA0KPiAgZW4tTGF0bi1VUzogICAwDQo+ICAgICBlbi1LYXRhOiAgMzYNCj4gDQo+IA0KPiBJbXBs ZW1lbnRhdGlvbnMgbWF5IHdhbnQgdG8gdXNlIG1vcmUgc29waGlzdGljYXRlZCB3ZWlnaHRzIHRo YXQgZGVwZW5kIG9uDQo+IHRoZSB2YWx1ZXMgb2YgdGhlIGNvcnJlc3BvbmRpbmcgZWxlbWVudHMu IEZvciBleGFtcGxlLCBkZXBlbmRpbmcgb24gdGhlDQo+IGRvbWFpbiwgYW4gaW1wbGVtZW5hdGlv biBtaWdodCBnaXZlIGEgc21hbGwgZGlzdGFuY2UgdG8gdGhlIGRpZmZlcmVuY2UNCj4gYmV0d2Vl biAnbm8nIGFuZCAnbmInIG9yICdubic7IG9yIGJldHdlZW4gJ0thdGEnIGFuZCAnSGlyYSc7IG9y IGJldHdlZW4NCj4gJ1VTJyBhbmQgJ1VNJy4NCj4gDQpPciB3ZSBzaG91bGQganVzdCBzcGVjaWZ5 IHRoZSB3ZWlnaHRzIHRvIHVzZS4gSSBzZWUgc2NvcmVkIG1hdGNoaW5nIGJlaW5nIHVzZWQgbW9z dGx5IHRvIHByZXNlbnQgYSBsaXN0IG9mIHJlc3VsdHMgcmFua2VkIGJ5IHJlbGV2YW5jZSB0byB0 aGUgcmVxdWVzdC4gVGhlIG90aGVyIG1hdGNoaW5nIHNjaGVtZXMgcHJvZHVjZSBiaW5hcnkgbWF0 Y2hlcyBhbmQgYXJlIG1vcmUgc3VpdGVkIHRvIHJldHVybmluZyBhbiBpbmRpdmlkdWFsIGRvY3Vt ZW50IG9yIHBpZWNlIG9mIGNvbnRlbnQuDQoNCg== --===============1393397339== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1393397339==-- From ltru-bounces@ietf.org Fri Aug 26 12:55:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hUc-0000k9-Rk; Fri, 26 Aug 2005 12:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hUa-0000k4-Qg for ltru@megatron.ietf.org; Fri, 26 Aug 2005 12:55:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01583 for ; Fri, 26 Aug 2005 12:55:46 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8hVL-0005A7-Qn for ltru@ietf.org; Fri, 26 Aug 2005 12:56:36 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7QGtX4w633812 for ; Fri, 26 Aug 2005 12:55:33 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7QGthTJ144860 for ; Fri, 26 Aug 2005 10:55:43 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7QGtWA8026227 for ; Fri, 26 Aug 2005 10:55:32 -0600 Received: from [127.0.0.1] (sig-9-48-110-69.mts.ibm.com [9.48.110.69]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7QGtOfY025984; Fri, 26 Aug 2005 10:55:25 -0600 Message-ID: <430F497B.6020609@icu-project.org> Date: Fri, 26 Aug 2005 09:55:23 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: matching for non-RFC3066bis langtags References: <634978A7DF025A40BFEF33EB191E13BC0C9A5EE8@irvmbxw01.quest.com> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C9A5EE8@irvmbxw01.quest.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j7QGtX4w633812 X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Comments follow. >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture.=20 >=20 >=20 >>-----Original Message----- >>From: Mark Davis [mailto:mark.davis@icu-project.org] >>Sent: 2005=E5=B9=B48=E6=9C=8822=E6=97=A5 18:17 >>To: Addison Phillips >>Cc: Doug Ewell; LTRU Working Group >>Subject: Re: [Ltru] Re: matching for non-RFC3066bis langtags >> >>I think the scored matching would be better framed as a 'distance' metr= ic. good. >=20 > [Addison Phillips]=20 >=20 > I like a distance metric better. >=20 >=20 >>Here is suggested replacement text: >>=3D=3D=3D=3D=3D >> >> >>In the "scored matching" scheme, the extended language range ... >>... >>... SHOULD probably allow users to choose the most appropriate selectio= n >>value. >> >> >>=3D> >> >> >>In the "distance metric" scheme, a numeric value representing a 'distan= ce' >>between a language tags and a language range is computed. A distance of >>zero means that they are identical, a small distance indicates that the= y >>are very similar, and a large distance indicated that they are very >>different. Given a distance, implementations can allow users to select = a >>threshold distance for a match to be successful or a filter to be appli= ed. >> >>The first step in the process is to normalize the extended language ran= ge >>and the language tags by canonicalizing both, and mapping grandfathered >>and obsolete tags into modern equivalents. If there is no script, then = the >>Suppress-Script value from the registry is added as the script. >=20 > [Addison Phillips]=20 >=20 > This is wrong for two reasons.=20 >=20 > First, some languages do not have Suppress-Scripts and these languages = would be at a disadvantage or difficult to implement for. No other matchi= ng scheme requires access to the registry to do its work. This one requir= es some (for the canonicalization just mentioned), but this strikes me as= a leap of complexity that may not be necessary. >=20 > Second, a missing value in a quadruple may be missing for a reason. I t= hink only two values might potentially be added for a missing value: the = empty value or "*". I have to question why script would be different than= other subtags here... That's reasonable; if a script is missing it gets '*', so matching will=20 still work fine between en-Latn-US and en-US >=20 >>The language range and the language tags are then transformed into >>quadruples of elements of the form (language, script, country, variant). >>Any extended languages are considered part of the language element and = any >>extension subtag sequences are considered part of the variant element;= an >=20 > [Addison Phillips]=20 >=20 > Including extensions in variant will skew the scores in an inappropriat= e manner, at least potentially. Perhaps extensions should be scored separ= ately and at a lower value: >=20 > Range=3Dsl-IT-rozaj-r-foo >=20 > Sl-IT: 1 > Sl-IT-rozaj: 1 // hm... > Sl-IT-r-foo: 1 > Sl-rozaj: 5 // hm... > Sl-rozaj-r-foo: 4 I agree; let's make it a quintuple. >=20 >=20 >=20 >>x private use subtag sequences is considered part of the language eleme= nt >>if it is initial and part of the variant element if not. Missing >>components in the language range are set to "*"; thus a "*" pattern >>becomes the quadruple ("*", "*", "*", "*"). Subtags 'und' and 'Zyyy' ar= e >>converted to "*". >=20 > [Addison Phillips]=20 >=20 > Where did 'Zyyy' come from?=20 >=20 > Also: What about 'mul'? Does it match "*"? Or just 'mul'? Probably '*' is the best. Zyyy means undetermined script. We should also say 'Language subtags=20 'und' and 'mul', and the script subtag 'Zyyy' are converted to "*".'=20 since und could at some point be a region code. >=20 >> >>Each language tag being matched or filtered is assigned a distance, >>whereby small values indicate better matches and large values indicate >>worse ones. The distance between the language tags is the sum of the >>distances for each of the corresponding elements of the quadruple. If t= he >>elements are identical or one is '*', then the distance between them is >>zero. Otherwise, it is given by the following table: >> >> 128 language mismatch >> 32 script mismatch >> 4 region mismatch >> 1 variant mismatch(es) >=20 > [Addison Phillips]=20 >=20 > Is this last meant to indicate that a score of "2" is possible for two = variant mismatches? Or just that multiple subtags are possible there? I r= ead it as the latter. Yes, I meant the latter. >=20 > Also: note that subtag order is significant in variant matching if one = assumes simple string matching. Yes. >=20 > I'm curious why the values are each an additional power of two apart. I= f multiple scoring on a level isn't possible, then all this does is magni= fy the apparent distance.=20 Gaps were left just to allow for intermediate weights. For example, when=20 639-3 comes along, one might want to allow for weight differences=20 between dialects that are between 128 and 64. Logically, it would be cleaner to just have them be floating point=20 numbers, but I didn't want to run afoul of any integral purists ;-). >=20 >>Examples of distances from en-US: >> >> >> fr: 132 >> en-GB: 4 >> en-Latn-US: 0 >> en-Kata: 36 >> >> >>Implementations may want to use more sophisticated weights that depend = on >>the values of the corresponding elements. For example, depending on the >>domain, an implemenation might give a small distance to the difference >>between 'no' and 'nb' or 'nn'; or between 'Kata' and 'Hira'; or between >>'US' and 'UM'. >> >=20 > Or we should just specify the weights to use. I see scored matching bei= ng used mostly to present a list of results ranked by relevance to the re= quest. The other matching schemes produce binary matches and are more sui= ted to returning an individual document or piece of content. >=20 We could do that, and there are some obvious cases like the examples=20 given. As long as people didn't expect completeness, that would be ok.=20 But I'm sure that if we supply such weightings there will always be=20 people who argue that X language or region or script is being=20 disadvantaged by not being weighted specially, so that's why I didn't=20 want to go there at first. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 26 16:07:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kUY-0008JU-4A; Fri, 26 Aug 2005 16:07:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kUW-000863-VT for ltru@megatron.ietf.org; Fri, 26 Aug 2005 16:07:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16006 for ; Fri, 26 Aug 2005 16:07:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8kVH-0004HA-IP for ltru@ietf.org; Fri, 26 Aug 2005 16:08:44 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E8kUM-000852-3L; Fri, 26 Aug 2005 13:07:46 -0700 Message-Id: <6.2.3.4.2.20050826173709.04523830@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 26 Aug 2005 22:07:40 +0200 To: "Peter Constable" From: r&d afrac Subject: Re: [Ltru] update on ISO 639 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On 15:26 26/08/2005, Peter Constable said: >An updated working draft for ISO 639-6 was made available just >before the meeting. The leads for that project have been working >through the impact of adopting the ISO 11179 framework for that project. This WG's consensus is that ISO 11179 conflicts with RFC 3066 bis. What will you do now? Consider my proposition for joint serious work? As I noted the most difficult consensus is over the obvious. We can only thank and congratulate Debbie and Lee. As I explained it ISO is of interest to us only as a left-over of RFC 3066. ISO is "flat table" oriented. Our interest is in networking. ISO 11179 considers the right area of interest, has interesting approaches, but looks like an "OSI X.500" bird. You will note that ISO 11179 does not consider multilingualism and networking yet. The proper approach is networking, service architecture, multilingualism and then details like RFC 3066 bis. Details are important, but they are the final touch. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 26 18:52:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8n4E-00080s-3R; Fri, 26 Aug 2005 18:52:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8n4C-00080n-Px for ltru@megatron.ietf.org; Fri, 26 Aug 2005 18:52:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29411 for ; Fri, 26 Aug 2005 18:52:53 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8n50-0002cE-UR for ltru@ietf.org; Fri, 26 Aug 2005 18:53:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 15:52:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: matching for non-RFC3066bis langtags Date: Fri, 26 Aug 2005 15:52:36 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C9A617C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: matching for non-RFC3066bis langtags Thread-Index: AcWqXyerMxTRVLCmQ4yRxJAZGctmpgAMHuSw From: "Addison Phillips" To: "Mark Davis" X-OriginalArrivalTime: 26 Aug 2005 22:52:37.0766 (UTC) FILETIME=[DB170A60:01C5AA90] X-Spam-Score: 0.5 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0952740296==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0952740296== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 T2theSwgaW4gaW5jb3Jwb3JhdGluZyB0aGlzIHRleHQsIEkgZm91bmQgYSBzbWFsbCBwb3RlbnRp YWwgZ2xpdGNoIGluIE1hcmsncyBhbGdvcml0aG0uIENvbnNpZGVyIHRoZSByYW5nZSAiZW4tVVMi IHdpdGggdGhlIGZvbGxvd2luZyB0YWdzIGFuZCB0aGVpciBzY29yZXM6DQoNCiJmciIgICAgICAg ICAgICAgMjU2IChsYW5ndWFnZSBtaXNtYXRjaCwgcmVnaW9uIG1hdGNoKQ0KImVuLUdCIiAgICAg ICAgICAzODQgKGxhbmd1YWdlLCByZWdpb24gbWlzbWF0Y2gpDQoiZW4tTGF0bi1VUyIgICAgICAg MCAoYWxsIGZpZWxkcyBtYXRjaCkNCiJlbi1CcmFpIiAgICAgICAgIDMyIChyZWdpb24gbWlzbWF0 Y2gpDQoiZW4tVVMteC1mb28iICAgICAgMCAodmFyaWFudCBtaXNtYXRjaCkNCiJlbi1VUy1yLXdh ZGVnaWxlIiAwIChleHRlbnNpb24gbWlzbWF0Y2gpDQoNClRoZXNlIGxhc3QgdHdvIGFyZSBub3Qg bG9naWNhbCByZXN1bHRzOiB0aGVyZSBpcyAob3Igc2hvdWxkIGJlKSBhIGRpc3RhbmNlIGJldHdl ZW4gdGhlIGxhc3QgdHdvIHRhZ3MgYW5kIHRoZSByYW5nZSAiZW4tVVMiLCBpZiBvbmUgZm9sbG93 cyB0aGUgdGV4dCBhYm91dCBleHRlbmRlZCBsYW5ndWFnZSByYW5nZXMganVzdCBhYm92ZSBpdC4N Cg0KVGhlcmVmb3JlIEkgY2hhbmdlZCB0aGUgZXhwYW5zaW9uIG9mIHJhbmdlcyBhbmQgdGFncyB0 byBoYXZlIHNlcGFyYXRlIHJ1bGVzLiBUYWdzIGV4cGFuZCBtaXNzaW5nIGZpZWxkcyB0byAiKiIu IFJhbmdlcyBleHBhbmQgbWlzc2luZyBmaWVsZHMgdXAgdG8gdGhlIGxhc3QgY29uY3JldGUgZmll bGQgdG8gIioiIGFuZCB0byB0aGUgZW1wdHkgc3RyaW5nIGJleW9uZCB0aGF0LiBUaHVzIHJhbmdl ICJlbi1VUyIgaGFzIHRoZSBxdWludHVwbGU6DQoNCiJlbiIsIioiLCJVUyIsIiIsIiINCg0KTm93 IHRoZSBzY29yZXMgYXJlIGEgbW9yZSBsb2dpY2FsOg0KDQoiZnIiICAgICAgICAgICAgIDI1NiAo bGFuZ3VhZ2UgbWlzbWF0Y2gsIHJlZ2lvbiBtYXRjaCkNCiJlbi1HQiIgICAgICAgICAgMzg0IChs YW5ndWFnZSwgcmVnaW9uIG1pc21hdGNoKQ0KImVuLUxhdG4tVVMiICAgICAgIDAgKGFsbCBmaWVs ZHMgbWF0Y2gpDQoiZW4tQnJhaSIgICAgICAgICAzMiAocmVnaW9uIG1pc21hdGNoKQ0KImVuLVVT LXgtZm9vIiAgICAgIDQgKHZhcmlhbnQgbWlzbWF0Y2g6IHJhbmdlIGlzIHRoZSBlbXB0eSBzdHJp bmcpDQoiZW4tVVMtci13YWRlZ2lsZSIgMSAoZXh0ZW5zaW9uIG1pc21hdGNoOiByYW5nZSBpcyB0 aGUgZW1wdHkgc3RyaW5nKQ0KDQpNYXJrJ3MgdGV4dCB0aHVzIG1vZGlmaWVkIGlzIGluY29ycG9y YXRlZCBvbiBpbnRlci1sb2NhbGUuIFNlZToNCg0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29t L0lEL2RyYWZ0LWlldGYtbHRydS1tYXRjaGluZy0wNC50eHQNCmh0dHA6Ly93d3cuaW50ZXItbG9j YWxlLmNvbS9JRC9kcmFmdC1pZXRmLWx0cnUtbWF0Y2hpbmctMDQuaHRtbA0KDQpBZGRpc29uDQoN CkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0 d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXAN Cg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hp dGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBE YXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQ0KPiBTZW50OiAyMDA15bm0 OOaciDI25pelIDk6NTUNCj4gVG86IEFkZGlzb24gUGhpbGxpcHMNCj4gQ2M6IERvdWcgRXdlbGw7 IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBtYXRjaGluZyBm b3Igbm9uLVJGQzMwNjZiaXMgbGFuZ3RhZ3MNCj4gDQo+IA0KPiANCj4gQWRkaXNvbiBQaGlsbGlw cyB3cm90ZToNCj4gPiBDb21tZW50cyBmb2xsb3cuDQo+ID4NCj4gPiBBZGRpc29uIFAuIFBoaWxs aXBzDQo+ID4gR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQo+ID4gQ2hh aXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCj4gPg0KPiA+ IEludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQo+ID4gSXQgaXMgYW4gYXJj aGl0ZWN0dXJlLg0KPiA+DQo+ID4NCj4gPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ PkZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10NCj4g Pj5TZW50OiAyMDA15bm0OOaciDIy5pelIDE4OjE3DQo+ID4+VG86IEFkZGlzb24gUGhpbGxpcHMN Cj4gPj5DYzogRG91ZyBFd2VsbDsgTFRSVSBXb3JraW5nIEdyb3VwDQo+ID4+U3ViamVjdDogUmU6 IFtMdHJ1XSBSZTogbWF0Y2hpbmcgZm9yIG5vbi1SRkMzMDY2YmlzIGxhbmd0YWdzDQo+ID4+DQo+ ID4+SSB0aGluayB0aGUgc2NvcmVkIG1hdGNoaW5nIHdvdWxkIGJlIGJldHRlciBmcmFtZWQgYXMg YSAnZGlzdGFuY2UnDQo+IG1ldHJpYy4NCj4gDQo+IGdvb2QuDQo+IA0KPiA+DQo+ID4gW0FkZGlz b24gUGhpbGxpcHNdDQo+ID4NCj4gPiBJIGxpa2UgYSBkaXN0YW5jZSBtZXRyaWMgYmV0dGVyLg0K PiA+DQo+ID4NCj4gPj5IZXJlIGlzIHN1Z2dlc3RlZCByZXBsYWNlbWVudCB0ZXh0Og0KPiA+Pj09 PT09DQo+ID4+DQo+ID4+DQo+ID4+SW4gdGhlICJzY29yZWQgbWF0Y2hpbmciIHNjaGVtZSwgdGhl IGV4dGVuZGVkIGxhbmd1YWdlIHJhbmdlIC4uLg0KPiA+Pi4uLg0KPiA+Pi4uLiBTSE9VTEQgcHJv YmFibHkgYWxsb3cgdXNlcnMgdG8gY2hvb3NlIHRoZSBtb3N0IGFwcHJvcHJpYXRlIHNlbGVjdGlv bg0KPiA+PnZhbHVlLg0KPiA+Pg0KPiA+Pg0KPiA+Pj0+DQo+ID4+DQo+ID4+DQo+ID4+SW4gdGhl ICJkaXN0YW5jZSBtZXRyaWMiIHNjaGVtZSwgYSBudW1lcmljIHZhbHVlIHJlcHJlc2VudGluZyBh DQo+ICdkaXN0YW5jZScNCj4gPj5iZXR3ZWVuIGEgbGFuZ3VhZ2UgdGFncyBhbmQgYSBsYW5ndWFn ZSByYW5nZSBpcyBjb21wdXRlZC4gQSBkaXN0YW5jZSBvZg0KPiA+Pnplcm8gbWVhbnMgdGhhdCB0 aGV5IGFyZSBpZGVudGljYWwsIGEgc21hbGwgZGlzdGFuY2UgaW5kaWNhdGVzIHRoYXQgdGhleQ0K PiA+PmFyZSB2ZXJ5IHNpbWlsYXIsIGFuZCBhIGxhcmdlIGRpc3RhbmNlIGluZGljYXRlZCB0aGF0 IHRoZXkgYXJlIHZlcnkNCj4gPj5kaWZmZXJlbnQuIEdpdmVuIGEgZGlzdGFuY2UsIGltcGxlbWVu dGF0aW9ucyBjYW4gYWxsb3cgdXNlcnMgdG8gc2VsZWN0IGENCj4gPj50aHJlc2hvbGQgZGlzdGFu Y2UgZm9yIGEgbWF0Y2ggdG8gYmUgc3VjY2Vzc2Z1bCBvciBhIGZpbHRlciB0byBiZQ0KPiBhcHBs aWVkLg0KPiA+Pg0KPiA+PlRoZSBmaXJzdCBzdGVwIGluIHRoZSBwcm9jZXNzIGlzIHRvIG5vcm1h bGl6ZSB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2UNCj4gcmFuZ2UNCj4gPj5hbmQgdGhlIGxhbmd1YWdl IHRhZ3MgYnkgY2Fub25pY2FsaXppbmcgYm90aCwgYW5kIG1hcHBpbmcgZ3JhbmRmYXRoZXJlZA0K PiA+PmFuZCBvYnNvbGV0ZSB0YWdzIGludG8gbW9kZXJuIGVxdWl2YWxlbnRzLiBJZiB0aGVyZSBp cyBubyBzY3JpcHQsIHRoZW4NCj4gdGhlDQo+ID4+U3VwcHJlc3MtU2NyaXB0IHZhbHVlIGZyb20g dGhlIHJlZ2lzdHJ5IGlzIGFkZGVkIGFzIHRoZSBzY3JpcHQuDQo+ID4NCj4gPiBbQWRkaXNvbiBQ aGlsbGlwc10NCj4gPg0KPiA+IFRoaXMgaXMgd3JvbmcgZm9yIHR3byByZWFzb25zLg0KPiA+DQo+ ID4gRmlyc3QsIHNvbWUgbGFuZ3VhZ2VzIGRvIG5vdCBoYXZlIFN1cHByZXNzLVNjcmlwdHMgYW5k IHRoZXNlIGxhbmd1YWdlcw0KPiB3b3VsZCBiZSBhdCBhIGRpc2FkdmFudGFnZSBvciBkaWZmaWN1 bHQgdG8gaW1wbGVtZW50IGZvci4gTm8gb3RoZXINCj4gbWF0Y2hpbmcgc2NoZW1lIHJlcXVpcmVz IGFjY2VzcyB0byB0aGUgcmVnaXN0cnkgdG8gZG8gaXRzIHdvcmsuIFRoaXMgb25lDQo+IHJlcXVp cmVzIHNvbWUgKGZvciB0aGUgY2Fub25pY2FsaXphdGlvbiBqdXN0IG1lbnRpb25lZCksIGJ1dCB0 aGlzIHN0cmlrZXMNCj4gbWUgYXMgYSBsZWFwIG9mIGNvbXBsZXhpdHkgdGhhdCBtYXkgbm90IGJl IG5lY2Vzc2FyeS4NCj4gPg0KPiA+IFNlY29uZCwgYSBtaXNzaW5nIHZhbHVlIGluIGEgcXVhZHJ1 cGxlIG1heSBiZSBtaXNzaW5nIGZvciBhIHJlYXNvbi4gSQ0KPiB0aGluayBvbmx5IHR3byB2YWx1 ZXMgbWlnaHQgcG90ZW50aWFsbHkgYmUgYWRkZWQgZm9yIGEgbWlzc2luZyB2YWx1ZTogdGhlDQo+ IGVtcHR5IHZhbHVlIG9yICIqIi4gSSBoYXZlIHRvIHF1ZXN0aW9uIHdoeSBzY3JpcHQgd291bGQg YmUgZGlmZmVyZW50IHRoYW4NCj4gb3RoZXIgc3VidGFncyBoZXJlLi4uDQo+IA0KPiBUaGF0J3Mg cmVhc29uYWJsZTsgaWYgYSBzY3JpcHQgaXMgbWlzc2luZyBpdCBnZXRzICcqJywgc28gbWF0Y2hp bmcgd2lsbA0KPiBzdGlsbCB3b3JrIGZpbmUgYmV0d2VlbiBlbi1MYXRuLVVTIGFuZCBlbi1VUw0K PiANCj4gPg0KPiA+PlRoZSBsYW5ndWFnZSByYW5nZSBhbmQgdGhlIGxhbmd1YWdlIHRhZ3MgYXJl IHRoZW4gdHJhbnNmb3JtZWQgaW50bw0KPiA+PnF1YWRydXBsZXMgb2YgZWxlbWVudHMgb2YgdGhl IGZvcm0gKGxhbmd1YWdlLCBzY3JpcHQsIGNvdW50cnksIHZhcmlhbnQpLg0KPiA+PkFueSBleHRl bmRlZCBsYW5ndWFnZXMgYXJlIGNvbnNpZGVyZWQgcGFydCBvZiB0aGUgbGFuZ3VhZ2UgZWxlbWVu dCBhbmQNCj4gYW55DQo+ID4+ZXh0ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZXMgYXJlIGNvbnNpZGVy ZWQgIHBhcnQgb2YgdGhlIHZhcmlhbnQgZWxlbWVudDsNCj4gYW4NCj4gPg0KPiA+IFtBZGRpc29u IFBoaWxsaXBzXQ0KPiA+DQo+ID4gSW5jbHVkaW5nIGV4dGVuc2lvbnMgaW4gdmFyaWFudCB3aWxs IHNrZXcgdGhlIHNjb3JlcyBpbiBhbiBpbmFwcHJvcHJpYXRlDQo+IG1hbm5lciwgYXQgbGVhc3Qg cG90ZW50aWFsbHkuIFBlcmhhcHMgZXh0ZW5zaW9ucyBzaG91bGQgYmUgc2NvcmVkDQo+IHNlcGFy YXRlbHkgYW5kIGF0IGEgbG93ZXIgdmFsdWU6DQo+ID4NCj4gPiBSYW5nZT1zbC1JVC1yb3phai1y LWZvbw0KPiA+DQo+ID4gU2wtSVQ6IDENCj4gPiBTbC1JVC1yb3phajogMSAvLyBobS4uLg0KPiA+ IFNsLUlULXItZm9vOiAxDQo+ID4gU2wtcm96YWo6IDUgLy8gaG0uLi4NCj4gPiBTbC1yb3phai1y LWZvbzogNA0KPiANCj4gSSBhZ3JlZTsgbGV0J3MgbWFrZSBpdCBhIHF1aW50dXBsZS4NCj4gDQo+ ID4NCj4gPg0KPiA+DQo+ID4+eCBwcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzIGlzIGNvbnNp ZGVyZWQgcGFydCBvZiB0aGUgbGFuZ3VhZ2UNCj4gZWxlbWVudA0KPiA+PmlmIGl0IGlzIGluaXRp YWwgYW5kIHBhcnQgb2YgdGhlIHZhcmlhbnQgZWxlbWVudCBpZiBub3QuIE1pc3NpbmcNCj4gPj5j b21wb25lbnRzIGluIHRoZSBsYW5ndWFnZSByYW5nZSBhcmUgc2V0IHRvICIqIjsgdGh1cyBhICIq IiBwYXR0ZXJuDQo+ID4+YmVjb21lcyB0aGUgcXVhZHJ1cGxlICgiKiIsICIqIiwgIioiLCAiKiIp LiBTdWJ0YWdzICd1bmQnIGFuZCAnWnl5eScgYXJlDQo+ID4+Y29udmVydGVkIHRvICIqIi4NCj4g Pg0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4gV2hlcmUgZGlkICdaeXl5JyBjb21l IGZyb20/DQo+IA0KPiA+DQo+ID4gQWxzbzogV2hhdCBhYm91dCAnbXVsJz8gRG9lcyBpdCBtYXRj aCAiKiI/IE9yIGp1c3QgJ211bCc/DQo+IA0KPiBQcm9iYWJseSAnKicgaXMgdGhlIGJlc3QuDQo+ IA0KPiBaeXl5IG1lYW5zIHVuZGV0ZXJtaW5lZCBzY3JpcHQuIFdlIHNob3VsZCBhbHNvIHNheSAn TGFuZ3VhZ2Ugc3VidGFncw0KPiAndW5kJyBhbmQgJ211bCcsIGFuZCB0aGUgc2NyaXB0IHN1YnRh ZyAnWnl5eScgYXJlIGNvbnZlcnRlZCB0byAiKiIuJw0KPiBzaW5jZSB1bmQgY291bGQgYXQgc29t ZSBwb2ludCBiZSBhIHJlZ2lvbiBjb2RlLg0KPiANCj4gDQo+ID4NCj4gPj4NCj4gPj5FYWNoIGxh bmd1YWdlIHRhZyBiZWluZyBtYXRjaGVkIG9yIGZpbHRlcmVkIGlzIGFzc2lnbmVkIGEgZGlzdGFu Y2UsDQo+ID4+d2hlcmVieSBzbWFsbCB2YWx1ZXMgaW5kaWNhdGUgYmV0dGVyIG1hdGNoZXMgYW5k IGxhcmdlIHZhbHVlcyBpbmRpY2F0ZQ0KPiA+PndvcnNlIG9uZXMuIFRoZSBkaXN0YW5jZSBiZXR3 ZWVuIHRoZSBsYW5ndWFnZSB0YWdzIGlzIHRoZSBzdW0gb2YgdGhlDQo+ID4+ZGlzdGFuY2VzIGZv ciBlYWNoIG9mIHRoZSBjb3JyZXNwb25kaW5nIGVsZW1lbnRzIG9mIHRoZSBxdWFkcnVwbGUuIElm DQo+IHRoZQ0KPiA+PmVsZW1lbnRzIGFyZSBpZGVudGljYWwgb3Igb25lIGlzICcqJywgdGhlbiB0 aGUgZGlzdGFuY2UgYmV0d2VlbiB0aGVtIGlzDQo+ID4+emVyby4gT3RoZXJ3aXNlLCBpdCBpcyBn aXZlbiBieSB0aGUgZm9sbG93aW5nIHRhYmxlOg0KPiA+Pg0KPiA+PiAgMTI4ICAgIGxhbmd1YWdl IG1pc21hdGNoDQo+ID4+ICAgMzIgICAgc2NyaXB0IG1pc21hdGNoDQo+ID4+ICAgIDQgICAgcmVn aW9uIG1pc21hdGNoDQo+ID4+ICAgIDEgICAgdmFyaWFudCBtaXNtYXRjaChlcykNCj4gPg0KPiA+ IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4gSXMgdGhpcyBsYXN0IG1lYW50IHRvIGluZGlj YXRlIHRoYXQgYSBzY29yZSBvZiAiMiIgaXMgcG9zc2libGUgZm9yIHR3bw0KPiB2YXJpYW50IG1p c21hdGNoZXM/IE9yIGp1c3QgdGhhdCBtdWx0aXBsZSBzdWJ0YWdzIGFyZSBwb3NzaWJsZSB0aGVy ZT8gSQ0KPiByZWFkIGl0IGFzIHRoZSBsYXR0ZXIuDQo+IA0KPiBZZXMsIEkgbWVhbnQgdGhlIGxh dHRlci4NCj4gDQo+ID4NCj4gPiBBbHNvOiBub3RlIHRoYXQgc3VidGFnIG9yZGVyIGlzIHNpZ25p ZmljYW50IGluIHZhcmlhbnQgbWF0Y2hpbmcgaWYgb25lDQo+IGFzc3VtZXMgc2ltcGxlIHN0cmlu ZyBtYXRjaGluZy4NCj4gDQo+IFllcy4NCj4gDQo+ID4NCj4gPiBJJ20gY3VyaW91cyB3aHkgdGhl IHZhbHVlcyBhcmUgZWFjaCBhbiBhZGRpdGlvbmFsIHBvd2VyIG9mIHR3byBhcGFydC4gSWYNCj4g bXVsdGlwbGUgc2NvcmluZyBvbiBhIGxldmVsIGlzbid0IHBvc3NpYmxlLCB0aGVuIGFsbCB0aGlz IGRvZXMgaXMgbWFnbmlmeQ0KPiB0aGUgYXBwYXJlbnQgZGlzdGFuY2UuDQo+IA0KPiBHYXBzIHdl cmUgbGVmdCBqdXN0IHRvIGFsbG93IGZvciBpbnRlcm1lZGlhdGUgd2VpZ2h0cy4gRm9yIGV4YW1w bGUsIHdoZW4NCj4gNjM5LTMgY29tZXMgYWxvbmcsIG9uZSBtaWdodCB3YW50IHRvIGFsbG93IGZv ciB3ZWlnaHQgZGlmZmVyZW5jZXMNCj4gYmV0d2VlbiBkaWFsZWN0cyB0aGF0IGFyZSBiZXR3ZWVu IDEyOCBhbmQgNjQuDQo+IA0KPiANCj4gTG9naWNhbGx5LCBpdCB3b3VsZCBiZSBjbGVhbmVyIHRv IGp1c3QgaGF2ZSB0aGVtIGJlIGZsb2F0aW5nIHBvaW50DQo+IG51bWJlcnMsIGJ1dCBJIGRpZG4n dCB3YW50IHRvIHJ1biBhZm91bCBvZiBhbnkgaW50ZWdyYWwgcHVyaXN0cyA7LSkuDQo+IA0KPiA+ DQo+ID4+RXhhbXBsZXMgb2YgZGlzdGFuY2VzIGZyb20gZW4tVVM6DQo+ID4+DQo+ID4+DQo+ID4+ ICAgICAgICAgZnI6IDEzMg0KPiA+PiAgICAgIGVuLUdCOiAgIDQNCj4gPj4gZW4tTGF0bi1VUzog ICAwDQo+ID4+ICAgIGVuLUthdGE6ICAzNg0KPiA+Pg0KPiA+Pg0KPiA+PkltcGxlbWVudGF0aW9u cyBtYXkgd2FudCB0byB1c2UgbW9yZSBzb3BoaXN0aWNhdGVkIHdlaWdodHMgdGhhdCBkZXBlbmQN Cj4gb24NCj4gPj50aGUgdmFsdWVzIG9mIHRoZSBjb3JyZXNwb25kaW5nIGVsZW1lbnRzLiBGb3Ig ZXhhbXBsZSwgZGVwZW5kaW5nIG9uIHRoZQ0KPiA+PmRvbWFpbiwgYW4gaW1wbGVtZW5hdGlvbiBt aWdodCBnaXZlIGEgc21hbGwgZGlzdGFuY2UgdG8gdGhlIGRpZmZlcmVuY2UNCj4gPj5iZXR3ZWVu ICdubycgYW5kICduYicgb3IgJ25uJzsgb3IgYmV0d2VlbiAnS2F0YScgYW5kICdIaXJhJzsgb3Ig YmV0d2Vlbg0KPiA+PidVUycgYW5kICdVTScuDQo+ID4+DQo+ID4NCj4gPiBPciB3ZSBzaG91bGQg anVzdCBzcGVjaWZ5IHRoZSB3ZWlnaHRzIHRvIHVzZS4gSSBzZWUgc2NvcmVkIG1hdGNoaW5nDQo+ IGJlaW5nIHVzZWQgbW9zdGx5IHRvIHByZXNlbnQgYSBsaXN0IG9mIHJlc3VsdHMgcmFua2VkIGJ5 IHJlbGV2YW5jZSB0byB0aGUNCj4gcmVxdWVzdC4gVGhlIG90aGVyIG1hdGNoaW5nIHNjaGVtZXMg cHJvZHVjZSBiaW5hcnkgbWF0Y2hlcyBhbmQgYXJlIG1vcmUNCj4gc3VpdGVkIHRvIHJldHVybmlu ZyBhbiBpbmRpdmlkdWFsIGRvY3VtZW50IG9yIHBpZWNlIG9mIGNvbnRlbnQuDQo+ID4NCj4gV2Ug Y291bGQgZG8gdGhhdCwgYW5kIHRoZXJlIGFyZSBzb21lIG9idmlvdXMgY2FzZXMgbGlrZSB0aGUg ZXhhbXBsZXMNCj4gZ2l2ZW4uIEFzIGxvbmcgYXMgcGVvcGxlIGRpZG4ndCBleHBlY3QgY29tcGxl dGVuZXNzLCB0aGF0IHdvdWxkIGJlIG9rLg0KPiBCdXQgSSdtIHN1cmUgdGhhdCBpZiB3ZSBzdXBw bHkgc3VjaCB3ZWlnaHRpbmdzIHRoZXJlIHdpbGwgYWx3YXlzIGJlDQo+IHBlb3BsZSB3aG8gYXJn dWUgdGhhdCBYIGxhbmd1YWdlIG9yIHJlZ2lvbiBvciBzY3JpcHQgaXMgYmVpbmcNCj4gZGlzYWR2 YW50YWdlZCBieSBub3QgYmVpbmcgd2VpZ2h0ZWQgc3BlY2lhbGx5LCBzbyB0aGF0J3Mgd2h5IEkg ZGlkbid0DQo+IHdhbnQgdG8gZ28gdGhlcmUgYXQgZmlyc3QuDQoNCg0K --===============0952740296== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0952740296==-- From ltru-bounces@ietf.org Fri Aug 26 21:04:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8p7Q-0000BS-Tn; Fri, 26 Aug 2005 21:04:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8p7P-0000A5-6W for ltru@megatron.ietf.org; Fri, 26 Aug 2005 21:04:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04300 for ; Fri, 26 Aug 2005 21:04:20 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8p8D-0006Fe-9Q for ltru@ietf.org; Fri, 26 Aug 2005 21:05:14 -0400 Received: from h-68-166-38-45.snvacaid.dynamic.covad.net ([68.166.38.45] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E8p7B-0000XQ-00 for ltru@ietf.org; Fri, 26 Aug 2005 21:04:09 -0400 Message-ID: <009a01c5aaa3$79e57840$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C8B3EE1@irvmbxw01.quest.com><430A7912.8060403@icu-project.org> <6.0.0.20.2.20050823114424.08b99410@itmail.it.aoyama.ac.jp> <002d01c5a9f7$beb0c800$7f1afea9@oemcomputer> <430F36BE.7060900@icu-project.org> Subject: Re: [Ltru] Re: Distance Metric Date: Fri, 26 Aug 2005 18:05:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Mark Davis" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Friday, August 26, 2005 8:35 AM > Subject: Re: [Ltru] Re: Distance Metric ... > > I think the phrase "a small set of common matching algorithms" is important. > > Consequently, I think the discussion about what distance metrics *might* be > > used, while perhaps of academic interest, doesn't belong in this document > > unless we plan to use in one of the algorithms in our "small set" in order to > > foster interoperability. > > I agree that the goal of the document is to present a small list of > well-defined matching algorithms. However, I think it is also not > outside the scope to at least point out ways in which implementations > may choose to reasonably extend the methods that we define. That sort of stuff generally doesn't belong in a standards-track document. When it does, it's because there's a need to explain, for example, an extension mechanism. > And it is also useful during the development state, to get people > thinking about various options. ... I agree that it's useful to think about it, and discuss the possibilities on the mailing list if someone actually has requirements for them, but I really don't like seeing that kind of stuff in standards-track documents, since, at least in this form, it does nothing to help interoperability. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 26 22:35:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8qXo-0001JH-AQ; Fri, 26 Aug 2005 22:35:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8qXn-0001JC-4Z for ltru@megatron.ietf.org; Fri, 26 Aug 2005 22:35:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06824 for ; Fri, 26 Aug 2005 22:35:41 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8qYc-0008RD-FJ for ltru@ietf.org; Fri, 26 Aug 2005 22:36:35 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25175320089; Sat, 27 Aug 2005 04:35:17 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00462-09; Sat, 27 Aug 2005 04:35:13 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C928320084; Sat, 27 Aug 2005 04:35:03 +0200 (CEST) Date: Fri, 26 Aug 2005 17:39:17 -0700 From: Harald Tveit Alvestrand To: Mark Davis , Addison Phillips Subject: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) Message-ID: <9B72BC8C8F3E780710F80C39@B50854F0A9192E8EC6CDA126> In-Reply-To: <430F497B.6020609@icu-project.org> References: <634978A7DF025A40BFEF33EB191E13BC0C9A5EE8@irvmbxw01.quest.com> <430F497B.6020609@icu-project.org> X-Mailer: Mulberry/4.0.2 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1209543131==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1209543131== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========E742A69471BF549EA652==========" --==========E742A69471BF549EA652========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (Yes, I'm still around....) I like distance metrics..... since the subject has changed, I've changed=20 the subject.... >> Or we should just specify the weights to use. I see scored matching >> being used mostly to present a list of results ranked by relevance to >> the request. The other matching schemes produce binary matches and are >> more suited to returning an individual document or piece of content. >> > We could do that, and there are some obvious cases like the examples > given. As long as people didn't expect completeness, that would be ok. > But I'm sure that if we supply such weightings there will always be > people who argue that X language or region or script is being > disadvantaged by not being weighted specially, so that's why I didn't > want to go there at first. Stuff that people will want to tweak endlessly shouldn't be specified in a=20 standard, IMHO. And there's some interesting special cases; I thnk it was Mark who told me=20 about a case where the user wanted "xx-Aaaa" and "xx-Bbbb" to match with a=20 score of +INFINITY, so that when the user asked for "xx-Aaaa", "en" would=20 match better than "xx-Bbbb". (script names and language codes changed to protect the guilty..) But as a general rule, it may be a Good Idea to specify a sentence such as The standard's weights give a maximal metric of distance between two language tags. Local knowledge may assign a lower distance between specific pairs (such as between "nn" and "no"). Assigning such lower distances is outside of the scope of this standard. IE allow tweaking, but specify that normal tweaks bring things closer=20 together, it does not drive them further apart. (Historical parenthesis: the original HTTP "accept-language" specification=20 used floating point preference values between 0 and 1, so if specifiers=20 want floating point, they're following precedent....) Harald --==========E742A69471BF549EA652========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFDD7Y2OMj+2+WY0F4RAkODAKDcMpXcXnZXkcM56ORrXYQVr2U6OwCeLRAd Jd2VOlts4ObtsKSYnZ59hEI= =YC1r -----END PGP SIGNATURE----- --==========E742A69471BF549EA652==========-- --===============1209543131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1209543131==-- From ltru-bounces@ietf.org Sat Aug 27 00:31:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8sLt-0001rD-W3; Sat, 27 Aug 2005 00:31:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8sLr-0001p1-Ar for ltru@megatron.ietf.org; Sat, 27 Aug 2005 00:31:31 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11661 for ; Sat, 27 Aug 2005 00:31:27 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8sL9-0005ax-Kw for ltru@lists.ietf.org; Sat, 27 Aug 2005 06:30:47 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 06:30:47 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 06:30:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 27 Aug 2005 06:20:20 +0200 Organization: Lines: 12 Message-ID: <430FEA04.5DF@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: update on ISO 639 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > a quick update on projects in the ISO 639 series. Thanks for info. > ISO 639-3 will be an ISO standard -- before the end of the > year. Okay, then let's add 3066ter to the LTRU milestones, while we are all still hot about the 3066bis details... ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 27 07:30:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ytA-0004aH-DY; Sat, 27 Aug 2005 07:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8yt8-0004aC-Le for ltru@megatron.ietf.org; Sat, 27 Aug 2005 07:30:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08746 for ; Sat, 27 Aug 2005 07:30:17 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8yu2-0005cN-Tx for ltru@ietf.org; Sat, 27 Aug 2005 07:31:16 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E8yt1-0001IJ-V4; Sat, 27 Aug 2005 04:30:12 -0700 Message-Id: <6.2.3.4.2.20050827100259.042ca8b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 27 Aug 2005 11:21:49 +0200 To: Harald Tveit Alvestrand , Mark Davis , Addison Phillips From: r&d afrac Subject: Re: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) In-Reply-To: <9B72BC8C8F3E780710F80C39@B50854F0A9192E8EC6CDA126> References: <634978A7DF025A40BFEF33EB191E13BC0C9A5EE8@irvmbxw01.quest.com> <430F497B.6020609@icu-project.org> <9B72BC8C8F3E780710F80C39@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 02:39 27/08/2005, Harald Tveit Alvestrand wrote: >And there's some interesting special cases; I think it was Mark who >told me about a case where the user wanted "xx-Aaaa" and "xx-Bbbb" >to match with a score of +INFINITY, so that when the user asked for >"xx-Aaaa", "en" would match better than "xx-Bbbb". This has a known name: "shaping the world". It took time before someone eventually acknowledges it. Thank you. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 27 12:09:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E93F5-0006Uv-1F; Sat, 27 Aug 2005 12:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E93F2-0006TW-F7 for ltru@megatron.ietf.org; Sat, 27 Aug 2005 12:09:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19158 for ; Sat, 27 Aug 2005 12:09:06 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E93Fu-00045h-5H for ltru@ietf.org; Sat, 27 Aug 2005 12:10:09 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 Aug 2005 09:08:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) Date: Sat, 27 Aug 2005 09:08:49 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C9A61C3@irvmbxw01.quest.com> Thread-Topic: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) Thread-Index: AcWq+sCDnpPp6DM5ScCCA2zejeoG/wAH956Q From: "Addison Phillips" To: "r&d afrac" , "Harald Tveit Alvestrand" , "Mark Davis" X-OriginalArrivalTime: 27 Aug 2005 16:08:50.0874 (UTC) FILETIME=[9D2671A0:01C5AB21] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > This has a known name: "shaping the world". > It took time before someone eventually acknowledges it. No, this is called "language negotiation according to user preferences". = It is what the "q" weights in Accept-Language are for, for example. There are some different examples of how this could be useful. Case #1: Consider a user who speaks both Slovenian and Italian who = subscribes to an RSS news feed. RSS indicates the language of an article = using a language tag. If the user instructs her newsreader to filter the = articles in the news feed, she might use this Accept-Language setting: sl;q=3D1.0,it;q=3D0.8,sl-rozaj;q=3D0.0 The lowest distance metric value for each article (when comparing to = each range in succession) is the weight for the article as a whole. That = weight can be divided by the q weight associated with that range to = produce the "final score". When the articles are ordered by score, this = produces a list in which Slovenian articles always appear before Italian = articles on each "level" of matching, but in which articles in the = Resian dialect ("sl-rozaj") never appear (score is "infinity" = essentially, since divide by zero is an error) or at least appear at the = very end. Case #2: Consider a news feed from Japan. A friend tells me that an = interesting English language article appeared in this particular news = feed, but can't remember exactly when or what it was called. I can set = "ja;q=3D0.0" to filter out all the Japanese (presumably the majority of = the news feed), making the article easier to find. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 27 12:59:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E941q-0002g2-70; Sat, 27 Aug 2005 12:59:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E941o-0002fu-Nw for ltru@megatron.ietf.org; Sat, 27 Aug 2005 12:59:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20802 for ; Sat, 27 Aug 2005 12:59:33 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E942m-0005NQ-Pv for ltru@ietf.org; Sat, 27 Aug 2005 13:00:37 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7RGxJ1T495606 for ; Sat, 27 Aug 2005 12:59:19 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7RGxJRg039280 for ; Sat, 27 Aug 2005 10:59:19 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7RGxIfB016492 for ; Sat, 27 Aug 2005 10:59:18 -0600 Received: from [127.0.0.1] (sig-9-48-115-48.mts.ibm.com [9.48.115.48]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7RGxCWt016416; Sat, 27 Aug 2005 10:59:13 -0600 Message-ID: <43109BDE.1010502@icu-project.org> Date: Sat, 27 Aug 2005 09:59:10 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) References: <634978A7DF025A40BFEF33EB191E13BC0C9A5EE8@irvmbxw01.quest.com> <430F497B.6020609@icu-project.org> <9B72BC8C8F3E780710F80C39@B50854F0A9192E8EC6CDA126> In-Reply-To: <9B72BC8C8F3E780710F80C39@B50854F0A9192E8EC6CDA126> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org good points. Harald Tveit Alvestrand wrote: > (Yes, I'm still around....) > I like distance metrics..... since the subject has changed, I've changed > the subject.... > >>> Or we should just specify the weights to use. I see scored matching >>> being used mostly to present a list of results ranked by relevance to >>> the request. The other matching schemes produce binary matches and are >>> more suited to returning an individual document or piece of content. >>> >> We could do that, and there are some obvious cases like the examples >> given. As long as people didn't expect completeness, that would be ok. >> But I'm sure that if we supply such weightings there will always be >> people who argue that X language or region or script is being >> disadvantaged by not being weighted specially, so that's why I didn't >> want to go there at first. > > > Stuff that people will want to tweak endlessly shouldn't be specified in > a standard, IMHO. > And there's some interesting special cases; I thnk it was Mark who told > me about a case where the user wanted "xx-Aaaa" and "xx-Bbbb" to match > with a score of +INFINITY, so that when the user asked for "xx-Aaaa", > "en" would match better than "xx-Bbbb". > > (script names and language codes changed to protect the guilty..) > > But as a general rule, it may be a Good Idea to specify a sentence such as > > The standard's weights give a maximal metric of distance > between two language tags. Local knowledge may assign a lower > distance between specific pairs (such as between "nn" and "no"). > Assigning such lower distances is outside of the scope of > this standard. > > IE allow tweaking, but specify that normal tweaks bring things closer > together, it does not drive them further apart. > > (Historical parenthesis: the original HTTP "accept-language" > specification used floating point preference values between 0 and 1, so > if specifiers want floating point, they're following precedent....) > > Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 27 15:10:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E964E-00053e-OJ; Sat, 27 Aug 2005 15:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E964C-00053M-Vs for ltru@megatron.ietf.org; Sat, 27 Aug 2005 15:10:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25345 for ; Sat, 27 Aug 2005 15:10:10 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E965B-0008LF-AG for ltru@ietf.org; Sat, 27 Aug 2005 15:11:14 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9645-00018w-W2; Sat, 27 Aug 2005 12:10:06 -0700 Message-Id: <6.2.3.4.2.20050827195628.04e712d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 27 Aug 2005 20:11:17 +0200 To: "Addison Phillips" , "Harald Tveit Alvestrand" , "Mark Davis" From: r&d afrac Subject: RE: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C9A61C3@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C9A61C3@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Dear Addison, I was not refering to the mechanism which is really interesting, and I will review in detail when you have stabilised it. To see if one could establish local matrices, may be matching our investigated DNS matrices for emergency services for example (when you are traveling and get an accident or an hart failure, you want http://hart.sos to resolve at the nearest hospital [DNS root matrix], you also want to be able to talk with them). This is not that complex once there is the proper architecture. This is for the time being what I focus on. I was refering to the nice formulation about that "interesting special case" Mark told Harald "where the user wanted "xx-Aaaa" and "xx-Bbbb" to match with a score of +INFINITY, so that when the user asked for "xx-Aaaa", "en" would match better than "xx-Bbbb". Most Gov, Industry and Commerce people I discussed with around the world about your langtags tend to think that Harald's, Mark's, Peter's, Randy's and your's motivation is that "special" case. No idea why? But may be should you get familliar with that confusion? Cheers. jfc At 18:08 27/08/2005, Addison Phillips wrote: > > This has a known name: "shaping the world". > > It took time before someone eventually acknowledges it. > >No, this is called "language negotiation according to user >preferences". It is what the "q" weights in Accept-Language are for, >for example. > >There are some different examples of how this could be useful. > >Case #1: Consider a user who speaks both Slovenian and Italian who >subscribes to an RSS news feed. RSS indicates the language of an >article using a language tag. If the user instructs her newsreader >to filter the articles in the news feed, she might use this >Accept-Language setting: > >sl;q=1.0,it;q=0.8,sl-rozaj;q=0.0 > >The lowest distance metric value for each article (when comparing to >each range in succession) is the weight for the article as a whole. >That weight can be divided by the q weight associated with that >range to produce the "final score". When the articles are ordered by >score, this produces a list in which Slovenian articles always >appear before Italian articles on each "level" of matching, but in >which articles in the Resian dialect ("sl-rozaj") never appear >(score is "infinity" essentially, since divide by zero is an error) >or at least appear at the very end. > >Case #2: Consider a news feed from Japan. A friend tells me that an >interesting English language article appeared in this particular >news feed, but can't remember exactly when or what it was called. I >can set "ja;q=0.0" to filter out all the Japanese (presumably the >majority of the news feed), making the article easier to find. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 27 15:22:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E96G8-0007nc-5X; Sat, 27 Aug 2005 15:22:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E96G7-0007nX-1R for ltru@megatron.ietf.org; Sat, 27 Aug 2005 15:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26431 for ; Sat, 27 Aug 2005 15:22:28 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E96H6-0000Cq-EB for ltru@ietf.org; Sat, 27 Aug 2005 15:23:32 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 Aug 2005 12:22:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) Date: Sat, 27 Aug 2005 12:22:15 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C9A61C6@irvmbxw01.quest.com> Thread-Topic: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) Thread-Index: AcWrOvIbgWK6DyVzQv+mfhF5ThWkZQAAMckA From: "Addison Phillips" To: "r&d afrac" , "Harald Tveit Alvestrand" , "Mark Davis" X-OriginalArrivalTime: 27 Aug 2005 19:22:16.0291 (UTC) FILETIME=[A2848B30:01C5AB3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Case #1 in my email is an instance of Mark's "special case". The fact = that Harald used "en" instead of "it" or "sl" in his version is not = important. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: r&d afrac [mailto:rd@afrac.org] > Sent: 2005?8?27? 11:11 > To: Addison Phillips; Harald Tveit Alvestrand; Mark Davis > Cc: Doug Ewell; LTRU Working Group > Subject: RE: Nonstandard distance metrics (Re: [Ltru] Re: matching for > non-RFC3066bis langtags) >=20 > Dear Addison, > I was not refering to the mechanism which is really interesting, and > I will review in detail when you have stabilised it. To see if one > could establish local matrices, may be matching our investigated DNS > matrices for emergency services for example (when you are traveling > and get an accident or an hart failure, you want http://hart.sos to > resolve at the nearest hospital [DNS root matrix], you also want to > be able to talk with them). This is not that complex once there is > the proper architecture. This is for the time being what I focus on. >=20 > I was refering to the nice formulation about that "interesting > special case" Mark told Harald "where the user wanted "xx-Aaaa" and > "xx-Bbbb" to match with a score of +INFINITY, so that when the user > asked for "xx-Aaaa", "en" would match better than "xx-Bbbb". >=20 > Most Gov, Industry and Commerce people I discussed with around the > world about your langtags tend to think that Harald's, Mark's, > Peter's, Randy's and your's motivation is that "special" case. No idea = why? >=20 > But may be should you get familliar with that confusion? > Cheers. > jfc >=20 >=20 >=20 >=20 > At 18:08 27/08/2005, Addison Phillips wrote: > > > This has a known name: "shaping the world". > > > It took time before someone eventually acknowledges it. > > > >No, this is called "language negotiation according to user > >preferences". It is what the "q" weights in Accept-Language are for, > >for example. > > > >There are some different examples of how this could be useful. > > > >Case #1: Consider a user who speaks both Slovenian and Italian who > >subscribes to an RSS news feed. RSS indicates the language of an > >article using a language tag. If the user instructs her newsreader > >to filter the articles in the news feed, she might use this > >Accept-Language setting: > > > >sl;q=3D1.0,it;q=3D0.8,sl-rozaj;q=3D0.0 > > > >The lowest distance metric value for each article (when comparing to > >each range in succession) is the weight for the article as a whole. > >That weight can be divided by the q weight associated with that > >range to produce the "final score". When the articles are ordered by > >score, this produces a list in which Slovenian articles always > >appear before Italian articles on each "level" of matching, but in > >which articles in the Resian dialect ("sl-rozaj") never appear > >(score is "infinity" essentially, since divide by zero is an error) > >or at least appear at the very end. > > > >Case #2: Consider a news feed from Japan. A friend tells me that an > >interesting English language article appeared in this particular > >news feed, but can't remember exactly when or what it was called. I > >can set "ja;q=3D0.0" to filter out all the Japanese (presumably the > >majority of the news feed), making the article easier to find. > > > >Addison > > > >Addison P. Phillips > >Globalization Architect, Quest Software > >Chair, W3C Internationalization Core Working Group > > > >Internationalization is not a feature. > >It is an architecture. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 27 16:58:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E97lR-0001XS-0q; Sat, 27 Aug 2005 16:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E97lM-0001XN-KR for ltru@megatron.ietf.org; Sat, 27 Aug 2005 16:58:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29973 for ; Sat, 27 Aug 2005 16:58:49 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E97mL-0002bV-TA for ltru@ietf.org; Sat, 27 Aug 2005 16:59:55 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E97lG-0008CO-1x; Sat, 27 Aug 2005 13:58:46 -0700 Message-Id: <6.2.3.4.2.20050827214426.04e10a00@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 27 Aug 2005 22:58:34 +0200 To: "Addison Phillips" , "Harald Tveit Alvestrand" , "Mark Davis" From: r&d afrac Subject: RE: Nonstandard distance metrics (Re: [Ltru] Re: matching for non-RFC3066bis langtags) In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C9A61C6@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C9A61C6@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 21:22 27/08/2005, Addison Phillips wrote: >Case #1 in my email is an instance of Mark's "special case". The >fact that Harald used "en" instead of "it" or "sl" in his version is >not important. My remark is related to "en". The fun is that it is ... "not important" :-) Take care. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 27 21:11:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9BiH-00025O-HP; Sat, 27 Aug 2005 21:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9BiF-000253-SW for ltru@megatron.ietf.org; Sat, 27 Aug 2005 21:11:55 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09309 for ; Sat, 27 Aug 2005 21:11:53 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050828011124.CHCP19267.mta10.adelphia.net@DEWELL> for ; Sat, 27 Aug 2005 21:11:24 -0400 Message-ID: <00fa01c5ab6d$2e1a7d00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050824160648.XPAK1660.mta7.adelphia.net@megatron.ietf.org> Date: Sat, 27 Aug 2005 18:09:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > JFTR, nothing new, I still prefer standards track: > > 3066bis could obsolete 3066 (BCP 47) also as PS. > 3066ter oould integrate ISO 639-3 as DS (minor update) > 3066tetra oould integrate ISO 639-6 as STD I still have significant concerns about the assumption that ISO 639-6 will be, or should be, automatically integrated into a language tagging scheme. The Linguasphere database upon which 639-6 is based is still not freely available to the public for evaluation and examination, and seems unlikely ever to be, unlike the Ethnologue database upon which ISO 639-3 is based. Moreover, with ISO 639-3 already claiming to provide coverage for "all known human languages," numbering a bit over 7,600, and with Linguasphere listing "over 20,000 languages and constituent dialects," one is left to wonder just what the 13,400 new identifiers will contribute from the standpoint of identifying and requesting linguistic content. Will "en-US", "en-GB", "en-AU", and "en-IN" be given their own four-letter codes in ISO 639-6, and what will be the rules for correlating and equating these with the identifiers already in place? Meanwhile, the claim that there are "over 20,000 languages" to be tagged is being used as an argument against the current RFC 3066bis effort and the plan to support 7,600 languages in RFC 3066ter. I'm not saying anything against the Linguasphere effort per se, but with the limited knowledge available to me, I don't think its eventual role in language tagging should be considered a fait accompli. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 27 22:01:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9CTk-0003cQ-QI; Sat, 27 Aug 2005 22:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9CTk-0003cE-6v for ltru@megatron.ietf.org; Sat, 27 Aug 2005 22:01:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10715 for ; Sat, 27 Aug 2005 22:00:56 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9CUl-0000m0-1I for ltru@ietf.org; Sat, 27 Aug 2005 22:02:04 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j7S20Au24967; Sun, 28 Aug 2005 11:00:10 +0900 (JST) Received: from nodnsquery(133.2.210.1) by scmse2.scbb.aoyama.ac.jp via csmap id 195a7846_1767_11da_9dea_0030482532aa_25673; Sun, 28 Aug 2005 10:57:33 +0900 (JST) Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j7S241uh017285; Sun, 28 Aug 2005 11:04:47 +0900 Message-Id: <6.0.0.20.2.20050827142041.083322d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 27 Aug 2005 14:22:43 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: update on ISO 639 In-Reply-To: <430FEA04.5DF@xyzzy.claranet.de> References: <430FEA04.5DF@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hello Frank, Randy may know more details about this, but in general, an IETF WG first completes the existing milestones, and only then maybe applies for a charter extension with new work. Of course there sometimes are exceptions to this, but I think they are very rare. Also, our plan is to finish the matching draft by October, so let's try to concentrate on that one. Regards, Martin. At 13:20 05/08/27, Frank Ellermann wrote: >Peter Constable wrote: > >> a quick update on projects in the ISO 639 series. > >Thanks for info. > >> ISO 639-3 will be an ISO standard -- before the end of the >> year. > >Okay, then let's add 3066ter to the LTRU milestones, while we >are all still hot about the 3066bis details... ;-) Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 01:16:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9FWz-0007bX-13; Sun, 28 Aug 2005 01:16:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9FWw-0007bS-OF for ltru@megatron.ietf.org; Sun, 28 Aug 2005 01:16:30 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16049 for ; Sun, 28 Aug 2005 01:16:29 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050828051559.JEGV24042.mta11.adelphia.net@DEWELL> for ; Sun, 28 Aug 2005 01:15:59 -0400 Message-ID: <000a01c5ab8f$84001c80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050824173023.HJCD19156.edge4.adelphia.net@megatron.ietf.org> Date: Sat, 27 Aug 2005 22:15:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Minor regret X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > 1. As an implementer I don't like the idea having to analyze the > content of each character in a subtag in order to recognize the subtag > type. All subtags distinguished by content in the current grammar are > distinguished on the first character. There are two such cases now: > > - 4 characters: Variant (initial digit) vs. script (initial alpha) > - 3 characters: extlang (initial alpha) vs. UN M.49 code (initial > digit) You have to look at every character anyway if you are going to check for well-formedness. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 01:21:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Fbo-0000NB-W2; Sun, 28 Aug 2005 01:21:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Fbn-0000KG-7u for ltru@megatron.ietf.org; Sun, 28 Aug 2005 01:21:31 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16163 for ; Sun, 28 Aug 2005 01:21:29 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9Fad-0001qt-4G for ltru@lists.ietf.org; Sun, 28 Aug 2005 07:20:19 +0200 Received: from c-180-160-106.hh.dial.de.ignite.net ([62.180.160.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 07:20:19 +0200 Received: from nobody by c-180-160-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 07:20:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 28 Aug 2005 07:14:01 +0200 Organization: Lines: 22 Message-ID: <43114819.6EEE@xyzzy.claranet.de> References: <20050824160648.XPAK1660.mta7.adelphia.net@megatron.ietf.org> <00fa01c5ab6d$2e1a7d00$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: STD X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I still have significant concerns about the assumption that > ISO 639-6 will be, or should be, automatically integrated > into a language tagging scheme. Yes, it wasn't my intention to say something else, I used it only for my standards track example. More about "BCP" on the general list, a better solution could be a separate series for "non-technical" (admin / meta) documents. > the claim that there are "over 20,000 languages" to be tagged > is being used as an argument against the current RFC 3066bis > effort and the plan to support 7,600 languages in RFC 3066ter Jefsey mumbled something in this direction, but IMHO it was not convincing - we discussed potential size issues here. His real concern is "who controls IANA", that's interesting, but I'm not worried, and it's no reason to block 3066bis. BTW, I like number [7] in the rather long list. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 01:37:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Frc-0003bE-NG; Sun, 28 Aug 2005 01:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Fra-0003b9-7N for ltru@megatron.ietf.org; Sun, 28 Aug 2005 01:37:50 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16504 for ; Sun, 28 Aug 2005 01:37:46 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050828053703.PTXQ29002.mta9.adelphia.net@DEWELL> for ; Sun, 28 Aug 2005 01:37:03 -0400 Message-ID: <001301c5ab92$73f777e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050824173023.HJCD19156.edge4.adelphia.net@megatron.ietf.org> Date: Sat, 27 Aug 2005 22:36:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Reloading the registry (was: STD) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John.Cowan wrote: > Indeed. We'll probably want to issue another I-D to reload the > registry with all the thousands of new values. Another reason for > going dormant rather than shutting up shop when RFC 3066bis and > friends are finished. I've already built a hypothetical RFC 3066ter registry. The changes alone add up to 35,700 lines, or more than 740 pages in RFC format. It might reopen the question of whether an I-D is the best vehicle for delivering this amount of information to IANA. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 01:45:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9FzF-0005E0-1t; Sun, 28 Aug 2005 01:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9FzD-0005CD-4N for ltru@megatron.ietf.org; Sun, 28 Aug 2005 01:45:43 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16676 for ; Sun, 28 Aug 2005 01:45:42 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050828054507.JGME19267.mta10.adelphia.net@DEWELL> for ; Sun, 28 Aug 2005 01:45:07 -0400 Message-ID: <002701c5ab93$93709ba0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 27 Aug 2005 22:44:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I wrote: > Moreover, with ISO 639-3 already claiming to provide coverage for "all > known human languages," numbering a bit over 7,600, and with > Linguasphere listing "over 20,000 languages and constituent dialects," > one is left to wonder just what the 13,400 new identifiers will > contribute from the standpoint of identifying and requesting > linguistic content. Recte: 12,400 -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 07:23:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9LGW-000439-4I; Sun, 28 Aug 2005 07:23:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9LGT-00042z-9u for ltru@megatron.ietf.org; Sun, 28 Aug 2005 07:23:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11049 for ; Sun, 28 Aug 2005 07:23:52 -0400 (EDT) Received: from rly-ip08.mx.aol.com ([64.12.138.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9LHW-0000AB-3r for ltru@ietf.org; Sun, 28 Aug 2005 07:25:03 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip08.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7SBMqw2015940; Sun, 28 Aug 2005 07:22:52 -0400 Received: from DEBHOME (ACC91CB6.ipt.aol.com [172.201.28.182]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7SBMksg029043; Sun, 28 Aug 2005 07:22:46 -0400 Message-Id: <200508281122.j7SBMksg029043@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Sun, 28 Aug 2005 12:22:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <00fa01c5ab6d$2e1a7d00$030aa8c0@DEWELL> Thread-Index: AcWrbaze0m3RqlCgQay+z9+bPEGR1AASvw5A X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi See in line comments > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Doug Ewell > Sent: 28 August 2005 02:10 > To: LTRU Working Group > Subject: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' > toBCP) > > Frank Ellermann wrote: > > > JFTR, nothing new, I still prefer standards track: > > > > 3066bis could obsolete 3066 (BCP 47) also as PS. > > 3066ter oould integrate ISO 639-3 as DS (minor update) > > 3066tetra oould integrate ISO 639-6 as STD > > I still have significant concerns about the assumption that ISO 639-6 > will be, or should be, automatically integrated into a language tagging > scheme. The Linguasphere database upon which 639-6 is based is still > not freely available to the public for evaluation and examination, and > seems unlikely ever to be, unlike the Ethnologue database upon which ISO > 639-3 is based. I don't think anyone should make assumptions where technology is concerned! What I can say is that the database for the 639-6 standard will be made freely available online, in the same way as the Ethnologue, as soon as it is ready. However, this is a WIP and there really is no point putting up half information that has not yet been verified. I am currently putting together the verification methodology which will be implemented by various collaboration partners internationally. I cannot at this moment say when the database will be ready but rest assured you will be notified. > > Moreover, with ISO 639-3 already claiming to provide coverage for "all > known human languages," numbering a bit over 7,600, and with > Linguasphere listing "over 20,000 languages and constituent dialects," > one is left to wonder just what the 13,400 new identifiers will > contribute from the standpoint of identifying and requesting linguistic > content. Will "en-US", "en-GB", "en-AU", and "en-IN" be given their own > four-letter codes in ISO 639-6, and what will be the rules for > correlating and equating these with the identifiers already in place? As it stands at the moment, 639-6 will provide each linguistic entity with one language reference name. This reference name is intended for use as the unique data identifier (DI as per 11179). Unique Data Identifiers and alpha-4 Representations for each linguistic entity written, spoken and signed down to the level of dialect and component variety, where appropriate, will be provided. Because 639-6 is a hierarchical system (the parent alpha-4 representation is provided), it lends itself very well to the "mapping" of the other codes of the 639 family; something that should prove invaluable for backward compatibility. In other words, in the system as proposed, you could use either the alpha-4 representation or the unique DI to find the closest 639-1,-2,-3 or -5 tags should you so wish. > > Meanwhile, the claim that there are "over 20,000 languages" to be tagged > is being used as an argument against the current RFC 3066bis effort and > the plan to support 7,600 languages in RFC 3066ter. Hmmmm... at this point there could be very lengthy off topic discussions as to what is a language and I don't think that is a good idea. I would not say that there are 20,000 languages but rather nearer to 7,600 as stated in 639-3; just my humble opinion. JFTR, I support the inclusion of 639-3 in RFC3066ter. > > I'm not saying anything against the Linguasphere effort per se, but with > the limited knowledge available to me, I don't think its eventual role > in language tagging should be considered a fait accompli. That is your prerogative but IMHO very much a sensible approach (see first line comment). ISO 639-6 is being created as an International Standard. There is a long way to go (earliest completion 2007) until it reaches full IS and no doubt there will be twists and turns on the ISO journey :-) As previously mentioned by Peter, there will be a draft CD for comment available by the end of November. At that time I will happily make it available to this expert group for comment. Have a nice day! Debbie Garside > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 09:55:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Ndf-0006Rc-C4; Sun, 28 Aug 2005 09:55:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Ndd-0006RU-MW for ltru@megatron.ietf.org; Sun, 28 Aug 2005 09:55:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19285 for ; Sun, 28 Aug 2005 09:55:55 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Nem-0004Mp-S1 for ltru@ietf.org; Sun, 28 Aug 2005 09:57:09 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9NdX-0006VY-6o; Sun, 28 Aug 2005 06:55:51 -0700 Message-Id: <6.2.3.4.2.20050828154537.03a64d70@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 28 Aug 2005 15:54:14 +0200 To: "Debbie Garside" , "'Doug Ewell'" , "'LTRU Working Group'" From: r&d afrac Subject: RE: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) In-Reply-To: <200508281122.j7SBMksg029043@smtp-los01.proxy.aol.com> References: <00fa01c5ab6d$2e1a7d00$030aa8c0@DEWELL> <200508281122.j7SBMksg029043@smtp-los01.proxy.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Debbie, you will see my comments in the mail of comments/support to Doug Ewell. All this is good and clear. Except your timing. When do you think we can have a test sample, to be able to develop? I suppose IANA would be interested too. Ditto, Doug: could you release your complete test ISO-639-3 included base? jfc At 13:22 28/08/2005, Debbie Garside wrote: >See in line comments > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > > Doug Ewell > > Sent: 28 August 2005 02:10 > > To: LTRU Working Group > > Subject: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' > > toBCP) > > > > Frank Ellermann wrote: > > > > > JFTR, nothing new, I still prefer standards track: > > > > > > 3066bis could obsolete 3066 (BCP 47) also as PS. > > > 3066ter oould integrate ISO 639-3 as DS (minor update) > > > 3066tetra oould integrate ISO 639-6 as STD > > > > I still have significant concerns about the assumption that ISO 639-6 > > will be, or should be, automatically integrated into a language tagging > > scheme. The Linguasphere database upon which 639-6 is based is still > > not freely available to the public for evaluation and examination, and > > seems unlikely ever to be, unlike the Ethnologue database upon which ISO > > 639-3 is based. > >I don't think anyone should make assumptions where technology is concerned! >What I can say is that the database for the 639-6 standard will be made >freely available online, in the same way as the Ethnologue, as soon as it is >ready. However, this is a WIP and there really is no point putting up half >information that has not yet been verified. I am currently putting together >the verification methodology which will be implemented by various >collaboration partners internationally. I cannot at this moment say when >the database will be ready but rest assured you will be notified. > > > > > > Moreover, with ISO 639-3 already claiming to provide coverage for "all > > known human languages," numbering a bit over 7,600, and with > > Linguasphere listing "over 20,000 languages and constituent dialects," > > one is left to wonder just what the 13,400 new identifiers will > > contribute from the standpoint of identifying and requesting linguistic > > content. Will "en-US", "en-GB", "en-AU", and "en-IN" be given their own > > four-letter codes in ISO 639-6, and what will be the rules for > > correlating and equating these with the identifiers already in place? > >As it stands at the moment, 639-6 will provide each linguistic entity with >one language reference name. This reference name is intended for use as the >unique data identifier (DI as per 11179). Unique Data Identifiers and >alpha-4 Representations for each linguistic entity written, spoken and >signed down to the level of dialect and component variety, where >appropriate, will be provided. Because 639-6 is a hierarchical system (the >parent alpha-4 representation is provided), it lends itself very well to the >"mapping" of the other codes of the 639 family; something that should prove >invaluable for backward compatibility. In other words, in the system as >proposed, you could use either the alpha-4 representation or the unique DI >to find the closest 639-1,-2,-3 or -5 tags should you so wish. > > > > > Meanwhile, the claim that there are "over 20,000 languages" to be tagged > > is being used as an argument against the current RFC 3066bis effort and > > the plan to support 7,600 languages in RFC 3066ter. > >Hmmmm... at this point there could be very lengthy off topic discussions as >to what is a language and I don't think that is a good idea. I would not >say that there are 20,000 languages but rather nearer to 7,600 as stated in >639-3; just my humble opinion. JFTR, I support the inclusion of 639-3 in >RFC3066ter. > > > > > I'm not saying anything against the Linguasphere effort per se, but with > > the limited knowledge available to me, I don't think its eventual role > > in language tagging should be considered a fait accompli. > >That is your prerogative but IMHO very much a sensible approach (see first >line comment). > >ISO 639-6 is being created as an International Standard. There is a long >way to go (earliest completion 2007) until it reaches full IS and no doubt >there will be twists and turns on the ISO journey :-) > >As previously mentioned by Peter, there will be a draft CD for comment >available by the end of November. At that time I will happily make it >available to this expert group for comment. > >Have a nice day! > >Debbie Garside > > > > > -- > > Doug Ewell > > Fullerton, California > > http://users.adelphia.net/~dewell/ > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 10:55:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9OZH-0002Kx-0H; Sun, 28 Aug 2005 10:55:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9OZF-0002JT-Qz for ltru@megatron.ietf.org; Sun, 28 Aug 2005 10:55:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24379 for ; Sun, 28 Aug 2005 10:55:27 -0400 (EDT) Received: from rly-ip08.mx.aol.com ([64.12.138.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9OaK-00063y-Gi for ltru@ietf.org; Sun, 28 Aug 2005 10:56:41 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip08.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7SEsnjn012438; Sun, 28 Aug 2005 10:54:50 -0400 Received: from DEBHOME (ACC91CB6.ipt.aol.com [172.201.28.182]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7SEsc4m002580; Sun, 28 Aug 2005 10:54:39 -0400 Message-Id: <200508281454.j7SEsc4m002580@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'r&d afrac'" , "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Sun, 28 Aug 2005 15:54:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.3.4.2.20050828154537.03a64d70@mail.afrac.org> Thread-Index: AcWr2DMw9FePS5nnRcioyYMFEi7KuwACBXCQ X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi JFC I would not release any data until the November draft. Cheers Debbie > -----Original Message----- > From: r&d afrac [mailto:rd@afrac.org] > Sent: 28 August 2005 14:54 > To: Debbie Garside; 'Doug Ewell'; 'LTRU Working Group' > Subject: RE: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying > Languages' toBCP) > > Debbie, > you will see my comments in the mail of comments/support to Doug > Ewell. All this is good and clear. Except your timing. When do you > think we can have a test sample, to be able to develop? I suppose > IANA would be interested too. Ditto, Doug: could you release your > complete test ISO-639-3 included base? > jfc > > > At 13:22 28/08/2005, Debbie Garside wrote: > >See in line comments > > > -----Original Message----- > > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf > Of > > > Doug Ewell > > > Sent: 28 August 2005 02:10 > > > To: LTRU Working Group > > > Subject: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying > Languages' > > > toBCP) > > > > > > Frank Ellermann wrote: > > > > > > > JFTR, nothing new, I still prefer standards track: > > > > > > > > 3066bis could obsolete 3066 (BCP 47) also as PS. > > > > 3066ter oould integrate ISO 639-3 as DS (minor update) > > > > 3066tetra oould integrate ISO 639-6 as STD > > > > > > I still have significant concerns about the assumption that ISO 639-6 > > > will be, or should be, automatically integrated into a language > tagging > > > scheme. The Linguasphere database upon which 639-6 is based is still > > > not freely available to the public for evaluation and examination, and > > > seems unlikely ever to be, unlike the Ethnologue database upon which > ISO > > > 639-3 is based. > > > >I don't think anyone should make assumptions where technology is > concerned! > >What I can say is that the database for the 639-6 standard will be made > >freely available online, in the same way as the Ethnologue, as soon as it > is > >ready. However, this is a WIP and there really is no point putting up > half > >information that has not yet been verified. I am currently putting > together > >the verification methodology which will be implemented by various > >collaboration partners internationally. I cannot at this moment say when > >the database will be ready but rest assured you will be notified. > > > > > > > > > > Moreover, with ISO 639-3 already claiming to provide coverage for "all > > > known human languages," numbering a bit over 7,600, and with > > > Linguasphere listing "over 20,000 languages and constituent dialects," > > > one is left to wonder just what the 13,400 new identifiers will > > > contribute from the standpoint of identifying and requesting > linguistic > > > content. Will "en-US", "en-GB", "en-AU", and "en-IN" be given their > own > > > four-letter codes in ISO 639-6, and what will be the rules for > > > correlating and equating these with the identifiers already in place? > > > >As it stands at the moment, 639-6 will provide each linguistic entity > with > >one language reference name. This reference name is intended for use as > the > >unique data identifier (DI as per 11179). Unique Data Identifiers and > >alpha-4 Representations for each linguistic entity written, spoken and > >signed down to the level of dialect and component variety, where > >appropriate, will be provided. Because 639-6 is a hierarchical system > (the > >parent alpha-4 representation is provided), it lends itself very well to > the > >"mapping" of the other codes of the 639 family; something that should > prove > >invaluable for backward compatibility. In other words, in the system as > >proposed, you could use either the alpha-4 representation or the unique > DI > >to find the closest 639-1,-2,-3 or -5 tags should you so wish. > > > > > > > > Meanwhile, the claim that there are "over 20,000 languages" to be > tagged > > > is being used as an argument against the current RFC 3066bis effort > and > > > the plan to support 7,600 languages in RFC 3066ter. > > > >Hmmmm... at this point there could be very lengthy off topic discussions > as > >to what is a language and I don't think that is a good idea. I would not > >say that there are 20,000 languages but rather nearer to 7,600 as stated > in > >639-3; just my humble opinion. JFTR, I support the inclusion of 639-3 in > >RFC3066ter. > > > > > > > > I'm not saying anything against the Linguasphere effort per se, but > with > > > the limited knowledge available to me, I don't think its eventual role > > > in language tagging should be considered a fait accompli. > > > >That is your prerogative but IMHO very much a sensible approach (see > first > >line comment). > > > >ISO 639-6 is being created as an International Standard. There is a long > >way to go (earliest completion 2007) until it reaches full IS and no > doubt > >there will be twists and turns on the ISO journey :-) > > > >As previously mentioned by Peter, there will be a draft CD for comment > >available by the end of November. At that time I will happily make it > >available to this expert group for comment. > > > >Have a nice day! > > > >Debbie Garside > > > > > > > > -- > > > Doug Ewell > > > Fullerton, California > > > http://users.adelphia.net/~dewell/ > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 12:15:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Pjl-0000qu-UC; Sun, 28 Aug 2005 12:10:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Pjj-0000pw-OT for ltru@megatron.ietf.org; Sun, 28 Aug 2005 12:10:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27642 for ; Sun, 28 Aug 2005 12:10:21 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Pks-0007wg-U6 for ltru@ietf.org; Sun, 28 Aug 2005 12:11:36 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 09:10:09 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 09:10:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Sun, 28 Aug 2005 09:10:17 -0700 Message-ID: Thread-Topic: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Thread-Index: AcWovuSlBxl+lHmbReyHdm+vH9tlLAAAxOggAG30pfA= From: "Peter Constable" To: X-OriginalArrivalTime: 28 Aug 2005 16:10:09.0229 (UTC) FILETIME=[F64437D0:01C5ABEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Addison Phillips > ISO 639-6 codes are easily dealt with: there is a slot reserved for them > in the ABNF that implementers ignore at their peril and the only change is > the management of registrations. >=20 > ISO 639-3 is slightly more complicated. Actually, I think it could well be the other way around.=20 Yes, from a purely syntactic perspective 639-6 would be straightforward. But the same would be true for 639-3: any alpha-4 from 639-6 can go into the initial subtag position, and any alpha-3 from 639-3 can go into initial or extlang subtags. But 639-3 won't be quite that simple because we want to avoid certain things: - e.g. don't use 639-3 alpha-3 in initial subtag when there's an equivalent alpha-2 - there must be some constraint on the relationship between lang and extlang subtags to avoid uninterpretable anomalies like en-fre, or arb-ar (ar =3D generic Arabic, arb =3D specifically Standard Arabic) -- assuming the second subtag qualifies the first subtag - we want to avoid the wrong matching behaviour that would arise from tags like arb-ar > Rules for > deciding what is an extlang and what is not may need to be worked through > (although I expect that ISO 639-3 itself will provide the rationale there). We will likely be able to define constraints in terms of the macrolanguage mappings to be defined in 639-3. It's not obvious what we would do in 639-6, but it appears to me that there will be issues. For instance, consider a hypothetical alpha-4 abcd that means some dialect X of Tajik written in Latin script using some specific orthographic conventions defined in 2010 (say) by the government of Kazakhstan. So, what do we do about abcd-KZ abcd-TJ abcd-Latn abcd-Cyrl abcd-dialectx abcd-dialecty abcd-2010 abcd-1996 abcd-tgk abcd-eng etc. The issue is that he alpha-4 IDs can already be quite specific -- fully qualified -- and hence questions arise if they are combined with other qualifiers. Do we add permitted_subtags fields to some 25000 registry entries for these things? Note, though, that not all 639-6 IDs would be fully qualified. Thus, returning to the hypothetical example, there'd be a related alpha-4, call it abcc, that represented dialect X of Tajik in Latin script, but not the specific orthographic conventions. What do we do about the synonymity of abcd and abcc-2010? And, as I understand it, the idea for 639-6 would be that all levels of granularity would be coded, from the most specific to the most generic. This means that engl (say) -- the equivalent to en -- is available. Of course, using the shortest-first rule, en would take priority over engl. But the generality wouldn't stop at that level. There would be alpha-4 IDs for several more levels of generality all the way up to Indo-European. (For half the worlds languages, more or less, the top level would be a language phylum like I-E; for the other half, it would be a geographic grouping, such as Eurasian.) So, consider I-E with an alpha-4 ID (say) of ineu. So what of tags like ineu-DE ineu-Cyrl ineu-dialectx ineu-tgk These are all issues that can be resolved, though it's by no means obvious that they could be resolved easily -- not unless we do something like revising the syntax so that initial alpha-4 subtags cannot co-occur with any other subtags (except perhaps extensions), and even then we'd have the issue of synonymity between pairs like en / engl and tgk-Latn-KZ-dialectx-2010 / abcd. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 12:54:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9QQm-0001fm-I3; Sun, 28 Aug 2005 12:54:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9QQi-0001dy-Ar for ltru@megatron.ietf.org; Sun, 28 Aug 2005 12:54:50 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29427 for ; Sun, 28 Aug 2005 12:54:44 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9QPI-0002tO-Q6 for ltru@lists.ietf.org; Sun, 28 Aug 2005 18:53:20 +0200 Received: from c-134-89-8.hh.dial.de.ignite.net ([62.134.89.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 18:53:20 +0200 Received: from nobody by c-134-89-8.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 18:53:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 28 Aug 2005 18:51:16 +0200 Organization: Lines: 21 Message-ID: <4311EB84.253A@xyzzy.claranet.de> References: <20050824173023.HJCD19156.edge4.adelphia.net@megatron.ietf.org> <001301c5ab92$73f777e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-8.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Reloading the registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > It might reopen the question of whether an I-D is the best > vehicle for delivering this amount of information to IANA. An I-D is only the best vehicle for a proper "last call". Because the initial registry mixes various sources we want "last call" reviews to find potential remaining problems - something like 003 that escaped us. 639-3 will be a single source, except from filtering dupes and getting the extlang(s) right it will be simpler than the initial registry. It's possible to do it again as I-D (as an unscheduled test for xml2rfc maybe ;-) but not necessary. I'm pretty sure that IANA won't complain if it's submitted as a text/plain, u+A0 and above escaped. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 13:31:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9R0M-0000aG-Jc; Sun, 28 Aug 2005 13:31:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9R0L-0000a8-IW for ltru@megatron.ietf.org; Sun, 28 Aug 2005 13:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01007 for ; Sun, 28 Aug 2005 13:31:36 -0400 (EDT) Received: from rly-ip08.mx.aol.com ([64.12.138.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9R1R-0001RX-HW for ltru@ietf.org; Sun, 28 Aug 2005 13:32:51 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip08.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7SHVJgn030607; Sun, 28 Aug 2005 13:31:21 -0400 Received: from DEBHOME (ACC91CB6.ipt.aol.com [172.201.28.182]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7SHV9Pw008444; Sun, 28 Aug 2005 13:31:09 -0400 Message-Id: <200508281731.j7SHV9Pw008444@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages'toBCP) Date: Sun, 28 Aug 2005 18:31:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcWovuSlBxl+lHmbReyHdm+vH9tlLAAAxOggAG30pfAAXidJYA== X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi Peter Please correct me if I am wrong, but I thought the whole idea of the primary language sub tag is that you use the shortest available ISO 639 code. My perception of its possible use within this particular RFC is that if there is a requirement for a level of granularity lower than language use ISO 639-6; you can design the RFC to stop at any level within the hierarchy. However, that surely does not stop you from using any of the other qualifying tags in the ABNF e.g. ISO 3166 or 15924 if you need them. I would not envisage this RFC using an alpha-4 representation for Indo-European. However, I do foresee other applications for it and I see no point in creating half a hierarchical system when the whole is available. With regard to your examples, I can't really see a problem other than you would never get the following scenario as in your presentation: > abcd-2010 > abcd-1996 In your example abcd (1996) would be annotated and a new code abce (2010) created with the original staying in the registry as a historical language code so it would still be valid. Kind Regards Debbie > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Peter Constable > Sent: 28 August 2005 17:10 > To: ltru@ietf.org > Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying > Languages'toBCP) > > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf > Of > > Addison Phillips > > > ISO 639-6 codes are easily dealt with: there is a slot reserved for > them > > in the ABNF that implementers ignore at their peril and the only > change is > > the management of registrations. > > > > ISO 639-3 is slightly more complicated. > > Actually, I think it could well be the other way around. > > Yes, from a purely syntactic perspective 639-6 would be straightforward. > But the same would be true for 639-3: any alpha-4 from 639-6 can go into > the initial subtag position, and any alpha-3 from 639-3 can go into > initial or extlang subtags. But 639-3 won't be quite that simple because > we want to avoid certain things: > > - e.g. don't use 639-3 alpha-3 in initial subtag when there's an > equivalent alpha-2 > > - there must be some constraint on the relationship between lang and > extlang subtags to avoid uninterpretable anomalies like en-fre, or > arb-ar (ar = generic Arabic, arb = specifically Standard Arabic) -- > assuming the second subtag qualifies the first subtag > > - we want to avoid the wrong matching behaviour that would arise from > tags like arb-ar > > > > Rules for > > deciding what is an extlang and what is not may need to be worked > through > > (although I expect that ISO 639-3 itself will provide the rationale > there). > > We will likely be able to define constraints in terms of the > macrolanguage mappings to be defined in 639-3. > > It's not obvious what we would do in 639-6, but it appears to me that > there will be issues. For instance, consider a hypothetical alpha-4 abcd > that means some dialect X of Tajik written in Latin script using some > specific orthographic conventions defined in 2010 (say) by the > government of Kazakhstan. So, what do we do about > > abcd-KZ > abcd-TJ > abcd-Latn > abcd-Cyrl > abcd-dialectx > abcd-dialecty > abcd-2010 > abcd-1996 > abcd-tgk > abcd-eng > > etc. The issue is that he alpha-4 IDs can already be quite specific -- > fully qualified -- and hence questions arise if they are combined with > other qualifiers. Do we add permitted_subtags fields to some 25000 > registry entries for these things? > > Note, though, that not all 639-6 IDs would be fully qualified. Thus, > returning to the hypothetical example, there'd be a related alpha-4, > call it abcc, that represented dialect X of Tajik in Latin script, but > not the specific orthographic conventions. What do we do about the > synonymity of abcd and abcc-2010? > > And, as I understand it, the idea for 639-6 would be that all levels of > granularity would be coded, from the most specific to the most generic. > This means that engl (say) -- the equivalent to en -- is available. Of > course, using the shortest-first rule, en would take priority over engl. > But the generality wouldn't stop at that level. There would be alpha-4 > IDs for several more levels of generality all the way up to > Indo-European. (For half the worlds languages, more or less, the top > level would be a language phylum like I-E; for the other half, it would > be a geographic grouping, such as Eurasian.) So, consider I-E with an > alpha-4 ID (say) of ineu. So what of tags like > > ineu-DE > ineu-Cyrl > ineu-dialectx > ineu-tgk > > These are all issues that can be resolved, though it's by no means > obvious that they could be resolved easily -- not unless we do something > like revising the syntax so that initial alpha-4 subtags cannot co-occur > with any other subtags (except perhaps extensions), and even then we'd > have the issue of synonymity between pairs like en / engl and > tgk-Latn-KZ-dialectx-2010 / abcd. > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 14:37:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9S1e-0002IQ-Q1; Sun, 28 Aug 2005 14:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9S1d-0002IL-Qh for ltru@megatron.ietf.org; Sun, 28 Aug 2005 14:37:01 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03963 for ; Sun, 28 Aug 2005 14:37:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050828183630.YSBW24042.mta11.adelphia.net@DEWELL>; Sun, 28 Aug 2005 14:36:30 -0400 Message-ID: <003101c5abff$5cb05f80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <200508281122.j7SBMksg029043@smtp-los01.proxy.aol.com> Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Sun, 28 Aug 2005 11:36:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > I don't think anyone should make assumptions where technology is > concerned! What I can say is that the database for the 639-6 standard > will be made freely available online, in the same way as the > Ethnologue, as soon as it is ready. However, this is a WIP and there > really is no point putting up half information that has not yet been > verified. I am currently putting together the verification > methodology which will be implemented by various collaboration > partners internationally. I cannot at this moment say when the > database will be ready but rest assured you will be notified. I'm a bit surprised that a work characterized as a work-in-progress and not yet ready for public review is nevertheless deemed ready to be considered as a draft international standard. We're not talking about a completely new invention, but a method of classifying languages, which is a human endeavor dating back many centuries if not millenia. But I'm certainly glad that my assumption that the information might not be made freely available was incorrect. Clearly, there can't be anything proprietary or IP-restricted about the data available for language tags (but of course Linguasphere can always provide proprietary value-added data, such as the language hierarchy). > As it stands at the moment, 639-6 will provide each linguistic entity > with one language reference name. This reference name is intended for > use as the unique data identifier (DI as per 11179). Unique Data > Identifiers and alpha-4 Representations for each linguistic entity > written, spoken and signed down to the level of dialect and component > variety, where appropriate, will be provided. Because 639-6 is a > hierarchical system (the parent alpha-4 representation is provided), > it lends itself very well to the "mapping" of the other codes of the > 639 family; something that should prove invaluable for backward > compatibility. In other words, in the system as proposed, you could > use either the alpha-4 representation or the unique DI to find the > closest 639-1,-2,-3 or -5 tags should you so wish. But in language tags, either one value needs to be canonical -- sorry, "preferred" -- over the others, or else the duplicative values should be not be added at all. Otherwise there is a significant burden on those who would perform matching. I would suggest that for compatibility, subtags directly mappable to ISO 639-1/2/3 should not be added. This is similar to the situation with ISO 639-2 in RFC 3066, where values like "eng" were not made available for language tags because of the pre-existence of "en". Will Linguasphere provide the mapping between the new alpha-4 codes and ISO 639-1/2/3, or is that something a group like this would have to do? >> Meanwhile, the claim that there are "over 20,000 languages" to be >> tagged is being used as an argument against the current RFC 3066bis >> effort and the plan to support 7,600 languages in RFC 3066ter. > > Hmmmm... at this point there could be very lengthy off topic > discussions as to what is a language and I don't think that is a good > idea. I would not say that there are 20,000 languages but rather > nearer to 7,600 as stated in 639-3; just my humble opinion. JFTR, I > support the inclusion of 639-3 in RFC3066ter. I agree that the broad question of "what is a language" is out of our scope. The more specific question "what is a taggable language distinction" is perhaps more germane. I just think the two figures (7,600 and 20,000) could be seen as representing a fundamental disagreement. I'd like to cite a specfic example of a distinction that is made in 639-6 but not 639-3, but I can't because the data's not yet available. I did not mean to imply that it was you (or Lee) who opposed either the current draft or the proposed use of ISO 639-3 in future drafts. >> I'm not saying anything against the Linguasphere effort per se, but >> with the limited knowledge available to me, I don't think its >> eventual role in language tagging should be considered a fait >> accompli. > > That is your prerogative but IMHO very much a sensible approach (see > first line comment). > > ISO 639-6 is being created as an International Standard. There is a > long way to go (earliest completion 2007) until it reaches full IS and > no doubt there will be twists and turns on the ISO journey :-) > > As previously mentioned by Peter, there will be a draft CD for comment > available by the end of November. At that time I will happily make it > available to this expert group for comment. I will gladly wait until then before trying to make specific comments on 639-6. Until then, I stand by my prerogative (in the U.S. we might say that it's not a slam dunk). > Have a nice day! +1 -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 15:59:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9TJq-0007DW-Ke; Sun, 28 Aug 2005 15:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9TJp-0007DR-6j for ltru@megatron.ietf.org; Sun, 28 Aug 2005 15:59:53 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08539 for ; Sun, 28 Aug 2005 15:59:51 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050828195920.CUUA19267.mta10.adelphia.net@DEWELL>; Sun, 28 Aug 2005 15:59:20 -0400 Message-ID: <004601c5ac0a$da353e20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <200508281935.j7SJZksa001336@smtp-los02.proxy.aol.com> Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Sun, 28 Aug 2005 12:58:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > 639-6 will provide a complete hierarchical system. However, there > will also be mapping to all of the 639 standard family (639-1, -2B, > -2T, -3 and -5). It is this mapping that will facilitate the > exclusion of alpha-4 representations (for the purposes of RFC3066 > bis/ter) that already have tags in preceding parts. Thank you for clarifying that. If and when 639-6 is deemed appropriate for use in language tags, this step will make it much easier to integrate it. I do wish you had chosen a synonym for "exclusion," though, since that word has also been misappropriated to argue against this group's efforts. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 16:20:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Tdg-00021c-5Z; Sun, 28 Aug 2005 16:20:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Tde-00020Y-OR for ltru@megatron.ietf.org; Sun, 28 Aug 2005 16:20:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09772 for ; Sun, 28 Aug 2005 16:20:20 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Tep-00061g-22 for ltru@ietf.org; Sun, 28 Aug 2005 16:21:37 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 13:20:10 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 13:20:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages'toBCP) Date: Sun, 28 Aug 2005 13:20:18 -0700 Message-ID: Thread-Topic: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages'toBCP) Thread-Index: AcWr/4n3sU/S3JR1SRu6WSW8L9dYOQACnvpw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 28 Aug 2005 20:20:10.0778 (UTC) FILETIME=[E3E2EFA0:01C5AC0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org [I'll preface this reply by saying that we don't want to spend too much time discussing issues that are not of immediate concern while we've got the matching draft and IETF last call on the registry drafts to deal with. So, I won't pursue this thread much longer.] > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Doug Ewell > I'm a bit surprised that a work characterized as a work-in-progress and > not yet ready for public review is nevertheless deemed ready to be > considered as a draft international standard. Debbie at no point said that it was -- and it is not. It will be December at the earliest that it can be registered as a CD, and it must successfully complete a three-month ballot as CD before it can be registered as a Draft International Standard. So last spring of 2006 at the earliest. > > In other words, in the system as proposed, you could > > use either the alpha-4 representation or the unique DI to find the > > closest 639-1,-2,-3 or -5 tags should you so wish. >=20 > But in language tags, either one value needs to be canonical -- sorry, > "preferred" -- over the others, or else the duplicative values should be > not be added at all. Your statement doesn't contradict anything that Debbie has said, provided the context is ISO 639-6 alone. If we were to talk about incorporation of ISO 639-6 into a revision of RFC 3066, however, then duplication would become an issue for consideration. For clarification of Debbie's statement, in the model of ISO 11179, we have metadata elements that consist of a data element concept, such as 'English', and a representation for that, such as "en" or "eng" (these would be distinct representations belonging to different value domains). Within an metadata registry, a registry item corresponding to 'English' can have a Data Identifier (DI), which is a unique identifier *within the registry* for that administered item; in this example, that DI could be any number of strings, though "English" would be among the better choices. > Will Linguasphere provide the mapping between the new alpha-4 codes and > ISO 639-1/2/3, or is that something a group like this would have to do? They will be (and must) providing that. > I agree that the broad question of "what is a language" is out of our > scope. The more specific question "what is a taggable language > distinction" is perhaps more germane. Not an unreasonable suggestion. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 16:32:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9TpH-0003Ug-Pm; Sun, 28 Aug 2005 16:32:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9TpF-0003UC-EV for ltru@megatron.ietf.org; Sun, 28 Aug 2005 16:32:21 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10231 for ; Sun, 28 Aug 2005 16:32:18 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E9Tnd-0007E8-HN for ltru@lists.ietf.org; Sun, 28 Aug 2005 22:30:41 +0200 Received: from c-134-89-8.hh.dial.de.ignite.net ([62.134.89.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 22:30:41 +0200 Received: from nobody by c-134-89-8.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 22:30:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 28 Aug 2005 22:25:31 +0200 Organization: Lines: 64 Message-ID: <43121DBB.2423@xyzzy.claranet.de> References: <4amb37$ak3l4l@mx02.mrf.mail.rcn.net> <200508281015.01096@mail.blilly.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-8.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Bruce Lilly wrote: > While there is some mention of this issue in the document > under discussion, its treatment and resolving the underlying > issue in a manner that would minimize the problems are > lacking. That's a last call, if you have better ideas than those in the draft speak up. Your Content-Script idea is good, but won't help e.g. in encoded words (2047+2231). We definitely tried to minimize especially this problem. This is a ready-for-Bruce's-review draft as far as I can judge this, but for obvious reasons only you can really judge it. ;-) > Addressing the language range issue is not a WG work item > and, unfortunately, the algorithm issue is scheduled to be a > later work item than the registry issue. Only my personal view of course, but the matching draft offers a syntactical form for ranges, and the Suppress-Script in the registry provides for backwards compatibility where possible. > it is essential that such negotiation issues be considered > carefully before specifying the format of tags. > Unfortunately, that has not been done IBTD, we considered the script issues. Anything else is as good or bad as it is with 3066 - some minor problems fixed of course, if ISO 3166-1 pulls another CS 3066bis will handle it better than 3066 (no potential worldwide retagging confusion). > the WG product lacks the "particular care" expected of BCP > documents (RFC 2026). IBTD as far as scripts are concerned. > it appears that management of WG participant conduct has been > rather lax IBTD, the WG Chairs and the responsible AD did a very good job. > as it stands, the document cannot be evaluated for soundness > of the tag syntax design in the absence of a specification > that addresses negotiation issues (in a backwards-compatible > manner with the existing negotiation mechanisms (viz. MIME > Content- and Accept- fields and feature/filter negotiation). IBTD, see above. Your idea to split tag and registry syntax from all procedural aspects of tag registration is possible, but you get the same effect by "ignore the procedural stuff in chapter 3" (= about 14 of the 60 pages in the draft). > Revision to move the syntax specification to a separate > document, as mentioned above, would permit evaluation of the > registration procedures per se You can also read chapter 3 per se, the mentioned 14 pages plus 3.1 as introduction (5 pages, format of the registry). I'm not violently against splitting the document, but it's IMHO unnecessary. Bye, Frank (also posted on the LTRU list) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 16:33:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9TqS-0003cV-Kc; Sun, 28 Aug 2005 16:33:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9TqQ-0003bV-JH for ltru@megatron.ietf.org; Sun, 28 Aug 2005 16:33:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10337 for ; Sun, 28 Aug 2005 16:33:32 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Trd-0006LG-A5 for ltru@ietf.org; Sun, 28 Aug 2005 16:34:49 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 13:33:24 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 13:33:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages'toBCP) Date: Sun, 28 Aug 2005 13:33:22 -0700 Message-ID: Thread-Topic: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages'toBCP) Thread-Index: AcWovuSlBxl+lHmbReyHdm+vH9tlLAAAxOggAG30pfAAXidJYAAG7DFQ From: "Peter Constable" To: X-OriginalArrivalTime: 28 Aug 2005 20:33:24.0940 (UTC) FILETIME=[BD3E70C0:01C5AC0F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Please correct me if I am wrong, but I thought the whole idea of the > primary > language sub tag is that you use the shortest available ISO 639 code. Use the shortest equivalent, yes. > My > perception of its possible use within this particular RFC is that if there > is a requirement for a level of granularity lower than language use ISO > 639-6; you can design the RFC to stop at any level within the hierarchy. If I understand what you mean, that would amount to requiring that a lone alpha-4 be used in preference to a sequence like en-US or az-Cyrl or de-1996 etc. It would be possible to design the RFC this way, but it is far from clear that that is what we should do.=20 > However, that surely does not stop you from using any of the other > qualifying tags in the ABNF e.g. ISO 3166 or 15924 if you need them. But that raises questions like determining when they are needed, when they would be redundant, and whether there are implications of using them redundantly, or in a contradictory manner, as in my hypothetical examples abcd-KZ, abcd-TJ, etc. > I > would not envisage this RFC using an alpha-4 representation for > Indo-European. I'd be inclined to agree. But it raises the issue of needing to determine which of its 20K+ initial entries and which future additions should not be used by the RFC. > With regard to your examples, I can't really see a problem other than you > would never get the following scenario as in your presentation: >=20 > > abcd-2010 > > abcd-1996 But the syntax as it stands now would certainly allow it. Thus, the issue is raised whether we would need to revise the syntax to prohibit such combinations. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 17:58:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9VAE-00076a-7I; Sun, 28 Aug 2005 17:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9VAD-00076V-BN for ltru@megatron.ietf.org; Sun, 28 Aug 2005 17:58:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13325 for ; Sun, 28 Aug 2005 17:58:02 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9VBQ-0008L5-QN for ltru@ietf.org; Sun, 28 Aug 2005 17:59:21 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7SLvp4k026659 for ; Sun, 28 Aug 2005 17:57:51 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7SLvpwB278640 for ; Sun, 28 Aug 2005 17:57:51 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7SLvpGQ010104 for ; Sun, 28 Aug 2005 17:57:51 -0400 Received: from [127.0.0.1] (sig-9-48-122-110.mts.ibm.com [9.48.122.110]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7SLvgvf009961; Sun, 28 Aug 2005 17:57:45 -0400 Message-ID: <43123354.2040808@icu-project.org> Date: Sun, 28 Aug 2005 14:57:40 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Minor regret References: <634978A7DF025A40BFEF33EB191E13BC0C9A555C@irvmbxw01.quest.com> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C9A555C@irvmbxw01.quest.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id j7SLvp4k026659 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I don't want to rock the boat, so this is only an academic discussion. Region is not so interesting, but script/orthography would have been=20 interesting because of fallback; look at polytonic Greek, which we have=20 to use a private-use script code for in CLDR. If one really wanted to=20 key off of first letter, then it would work to reserve all 4-character=20 codes starting with a letter for future use. And as Doug said, you have to look at the contents anyway for=20 well-formedness. Mark Addison Phillips wrote: > Actually, I don't regret this. >=20 > Yes, there are a few subtag forms that could be exploited in the future= , but I have to admit that: >=20 > 1. As an implementer I don't like the idea having to analyze the conten= t of each character in a subtag in order to recognize the subtag type. Al= l subtags distinguished by content in the current grammar are distinguish= ed on the first character. There are two such cases now: >=20 > - 4 characters: Variant (initial digit) vs. script (initial alpha) > - 3 characters: extlang (initial alpha) vs. UN M.49 code (initial digit= ) >=20 > 2. I think the "zoo" of potential subtags is exotic enough. Any additio= nal subtag types will fall into the realm of extensions (and good riddanc= e). The subtag scheme should be as simple as possible. The existing 3066b= is grammar is complex enough to be powerful, but simple enough that users= can grasp it. More subtag types will make tags more difficult to work wi= th. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture.=20 >=20 >=20 >>-----Original Message----- >>From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >>Mark Davis >>Sent: 2005=E5=B9=B48=E6=9C=8824=E6=97=A5 8:31 >>Cc: LTRU Working Group >>Subject: [Ltru] Minor regret >> >>I'll send this out just so it is on record. I am not proposing any >>change at this point in the game; just regretting slightly that we did >>not include the following text, to allow us some wriggle-room in the >>future. >> >>"All non-initial 4 character subtags that are not legal according to th= e >>above ABNF are reserved for possible future use as script or orthograph= y >>subtags. Examples: Lat1, B123 >> >>All non-initial 2 and 3 character subtags that are not legal according >>to the above ABNF are reserved for possible future use as region >>subtags. Examples: C1, 12, C34, UZ5, 6AB" >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 18:55:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9W3L-0007LV-5r; Sun, 28 Aug 2005 18:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9W3K-0007L6-8T for ltru@megatron.ietf.org; Sun, 28 Aug 2005 18:55:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16670 for ; Sun, 28 Aug 2005 18:54:59 -0400 (EDT) Received: from rly-ip08.mx.aol.com ([64.12.138.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9W4N-0001CY-UA for ltru@ietf.org; Sun, 28 Aug 2005 18:56:18 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip08.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7SMsGlu026872 for ; Sun, 28 Aug 2005 18:54:16 -0400 Received: from DEBHOME (ACD6CA61.ipt.aol.com [172.214.202.97]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7SMsCZW005685 for ; Sun, 28 Aug 2005 18:54:12 -0400 Message-Id: <200508282254.j7SMsCZW005685@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'LTRU Working Group'" Subject: FW: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Sun, 28 Aug 2005 23:56:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWsCzTGT1Faf+GHR+eaUUKZ2Fg2xgAAX6dAAAVkTSA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org And another stray one :-) (As Peter quite rightly says, we should not pursue this topic at this time... better to wait until November) -----Original Message----- From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] Sent: 28 August 2005 23:32 To: 'Doug Ewell'; 'LTRU Working Group' Subject: RE: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Doug Ewell wrote: > Thank you for clarifying that. If and when 639-6 is deemed appropriate > for use in language tags, this step will make it much easier to > integrate it. This is one of the reasons why we are "mapping"! Just for you... I'll rephrase that last section: It is this mapping that will facilitate RFC 3066bis/ter in the use of alpha-4 representations for linguistic entities that are not already represented in preceding parts of 639. ;-) Hope that's ok! > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 28 August 2005 20:58 > To: LTRU Working Group > Cc: Debbie Garside > Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying > Languages' toBCP) > > Debbie Garside wrote: > > > 639-6 will provide a complete hierarchical system. However, there > > will also be mapping to all of the 639 standard family (639-1, -2B, > > -2T, -3 and -5). It is this mapping that will facilitate the > > exclusion of alpha-4 representations (for the purposes of RFC3066 > > bis/ter) that already have tags in preceding parts. > > Thank you for clarifying that. If and when 639-6 is deemed appropriate > for use in language tags, this step will make it much easier to > integrate it. > > I do wish you had chosen a synonym for "exclusion," though, since that > word has also been misappropriated to argue against this group's > efforts. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 18:57:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9W5y-0007na-A5; Sun, 28 Aug 2005 18:57:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9W5w-0007nV-UM for ltru@megatron.ietf.org; Sun, 28 Aug 2005 18:57:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16730 for ; Sun, 28 Aug 2005 18:57:42 -0400 (EDT) Received: from rly-ip07.mx.aol.com ([64.12.138.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9W7A-0001F9-Qq for ltru@ietf.org; Sun, 28 Aug 2005 18:59:01 -0400 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip07.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7SMvMdN010390 for ; Sun, 28 Aug 2005 18:57:22 -0400 Received: from DEBHOME (ACD6CA61.ipt.aol.com [172.214.202.97]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7SMvD5D012370 for ; Sun, 28 Aug 2005 18:57:17 -0400 Message-Id: <200508282257.j7SMvD5D012370@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'LTRU Working Group'" Subject: FW: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Sun, 28 Aug 2005 23:59:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWr/2gDOOZihBiiRten0AYccNPITQABuYmQAAbs5lA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org A number of emails seem to have gone astray (although Doug has received them they are not posted to the LTRU) so I am forwarding See below -----Original Message----- From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] Sent: 28 August 2005 20:36 To: 'Doug Ewell'; 'LTRU Working Group' Subject: RE: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Doug Ewell wrote: > I would suggest that for compatibility, subtags directly mappable to ISO > 639-1/2/3 should not be added. This is similar to the situation with > ISO 639-2 in RFC 3066, where values like "eng" were not made available > for language tags because of the pre-existence of "en". > > Will Linguasphere provide the mapping between the new alpha-4 codes and > ISO 639-1/2/3, or is that something a group like this would have to do? 639-6 will provide a complete hierarchical system. However, there will also be mapping to all of the 639 standard family (639-1, -2B, -2T, -3 and -5). It is this mapping that will facilitate the exclusion of alpha-4 representations (for the purposes of RFC3066 bis/ter) that already have tags in preceding parts. Kind regards Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 28 August 2005 19:36 > To: LTRU Working Group > Cc: Debbie Garside > Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying > Languages' toBCP) > > Debbie Garside wrote: > > > I don't think anyone should make assumptions where technology is > > concerned! What I can say is that the database for the 639-6 standard > > will be made freely available online, in the same way as the > > Ethnologue, as soon as it is ready. However, this is a WIP and there > > really is no point putting up half information that has not yet been > > verified. I am currently putting together the verification > > methodology which will be implemented by various collaboration > > partners internationally. I cannot at this moment say when the > > database will be ready but rest assured you will be notified. > > I'm a bit surprised that a work characterized as a work-in-progress and > not yet ready for public review is nevertheless deemed ready to be > considered as a draft international standard. We're not talking about a > completely new invention, but a method of classifying languages, which > is a human endeavor dating back many centuries if not millenia. > > But I'm certainly glad that my assumption that the information might not > be made freely available was incorrect. Clearly, there can't be > anything proprietary or IP-restricted about the data available for > language tags (but of course Linguasphere can always provide proprietary > value-added data, such as the language hierarchy). > > > As it stands at the moment, 639-6 will provide each linguistic entity > > with one language reference name. This reference name is intended for > > use as the unique data identifier (DI as per 11179). Unique Data > > Identifiers and alpha-4 Representations for each linguistic entity > > written, spoken and signed down to the level of dialect and component > > variety, where appropriate, will be provided. Because 639-6 is a > > hierarchical system (the parent alpha-4 representation is provided), > > it lends itself very well to the "mapping" of the other codes of the > > 639 family; something that should prove invaluable for backward > > compatibility. In other words, in the system as proposed, you could > > use either the alpha-4 representation or the unique DI to find the > > closest 639-1,-2,-3 or -5 tags should you so wish. > > But in language tags, either one value needs to be canonical -- sorry, > "preferred" -- over the others, or else the duplicative values should be > not be added at all. Otherwise there is a significant burden on those > who would perform matching. > > I would suggest that for compatibility, subtags directly mappable to ISO > 639-1/2/3 should not be added. This is similar to the situation with > ISO 639-2 in RFC 3066, where values like "eng" were not made available > for language tags because of the pre-existence of "en". > > Will Linguasphere provide the mapping between the new alpha-4 codes and > ISO 639-1/2/3, or is that something a group like this would have to do? > > >> Meanwhile, the claim that there are "over 20,000 languages" to be > >> tagged is being used as an argument against the current RFC 3066bis > >> effort and the plan to support 7,600 languages in RFC 3066ter. > > > > Hmmmm... at this point there could be very lengthy off topic > > discussions as to what is a language and I don't think that is a good > > idea. I would not say that there are 20,000 languages but rather > > nearer to 7,600 as stated in 639-3; just my humble opinion. JFTR, I > > support the inclusion of 639-3 in RFC3066ter. > > I agree that the broad question of "what is a language" is out of our > scope. The more specific question "what is a taggable language > distinction" is perhaps more germane. I just think the two figures > (7,600 and 20,000) could be seen as representing a fundamental > disagreement. I'd like to cite a specfic example of a distinction that > is made in 639-6 but not 639-3, but I can't because the data's not yet > available. > > I did not mean to imply that it was you (or Lee) who opposed either the > current draft or the proposed use of ISO 639-3 in future drafts. > > >> I'm not saying anything against the Linguasphere effort per se, but > >> with the limited knowledge available to me, I don't think its > >> eventual role in language tagging should be considered a fait > >> accompli. > > > > That is your prerogative but IMHO very much a sensible approach (see > > first line comment). > > > > ISO 639-6 is being created as an International Standard. There is a > > long way to go (earliest completion 2007) until it reaches full IS and > > no doubt there will be twists and turns on the ISO journey :-) > > > > As previously mentioned by Peter, there will be a draft CD for comment > > available by the end of November. At that time I will happily make it > > available to this expert group for comment. > > I will gladly wait until then before trying to make specific comments on > 639-6. Until then, I stand by my prerogative (in the U.S. we might say > that it's not a slam dunk). > > > Have a nice day! > > +1 > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 19:29:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Wau-0003sG-VZ; Sun, 28 Aug 2005 19:29:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Wau-0003sB-9u for ltru@megatron.ietf.org; Sun, 28 Aug 2005 19:29:44 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17709 for ; Sun, 28 Aug 2005 19:29:40 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050828232912.KZDM14360.mta13.adelphia.net@DEWELL> for ; Sun, 28 Aug 2005 19:29:12 -0400 Message-ID: <008a01c5ac28$462498c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050828203437.BKTC6870.mta1.adelphia.net@megatron.ietf.org> Date: Sun, 28 Aug 2005 16:29:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> it appears that management of WG participant conduct has been >> rather lax > > IBTD, the WG Chairs and the responsible AD did a very good job. I would be tempted to agree with Bruce on this, except that my lack of experience on other IETF Working Groups precludes a meaningful comparison. For all I know, the sheer volume of misquoting of group members, deliberate misrepresentation of members' clearly stated intentions, revisitation of closed action items, personal and professional attacks, disrespect for the chairs and AD, outright falsehoods, and other mayhem witnessed on this list is absolutely typical of other IETF Working Groups. Maybe RFCs 3683 and 3934 are meant for some higher level of disruption and "unprofessional commentary" -- say, direct physical threats -- or maybe they're not intended for serious application at all. Maybe this is just the way things are in the IETF. All I know is, none of the other six non-IETF mailing lists to which I subscribe would ever have stood for this, certainly not over a sustained period of eight months. This WG has been made to be a very unpleasant experience for me, and all I wanted to do was help put together a code list. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 20:06:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9XAh-0000KA-TZ; Sun, 28 Aug 2005 20:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9XAg-0000K1-7X for ltru@megatron.ietf.org; Sun, 28 Aug 2005 20:06:42 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18787 for ; Sun, 28 Aug 2005 20:06:40 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050829000610.JQZG24042.mta11.adelphia.net@DEWELL>; Sun, 28 Aug 2005 20:06:10 -0400 Message-ID: <009101c5ac2d$6ce6d4a0$030aa8c0@DEWELL> From: "Doug Ewell" To: , References: <6.2.3.4.2.20050827113513.04327160@pop.online.fr><431090C2.20804@blueyonder.co.uk><6.2.3.4.2.20050827201217.0598d250@mail.jefsey.com><4310E7E8.4070408@blueyonder.co.uk><6.2.3.4.2.20050828033256.03a3feb0@mail.jefsey.com> <6.2.3.4.2.20050828111916.03a41040@mail.jefsey.com> Date: Sun, 28 Aug 2005 17:05:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: [Ltru] Re: Last Call: language root file size X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org JFC (Jefsey) Morfin wrote: > I started documenting some of the problems resulting from the > expected size of the language tag registry and the capacity of the > langtag solution to fulfill the WG-ltru Charter. Here are two inputs > from the author of the Draft above on the WG-ltru list, Doug Ewell: > > - "I've already built a hypothetical RFC 3066ter registry. The > changes alone add up to 35,700 lines, or more than 740 pages in RFC > format. It might reopen the question of whether an I-D is the best > vehicle for delivering this amount of information to IANA." Some of you who have not had the joy of witnessing this sort of gross misrepresentation on LTRU over the past eight months might be a bit confused. At no time did I ever say, or imply, or MEAN, that the eventual size of the registry would be a problem in and of itself, nor that the solution developed by the LTRU WG would not fulfill the charter. What I said, as anyone can see from reading the quote above, is that a 740-page I-D might be unwieldy enough that the IETF might consider a different procedural mechanism for delivering the information to IANA. > - "I still have significant concerns about the assumption that ISO > 639-6 will be, or should be, automatically integrated into a language > tagging scheme. [snip] Meanwhile, the claim that there are "over > 20,000 languages" to be tagged is being used as an argument against > the current RFC 3066bis effort and the plan to support 7,600 languages > in RFC 3066ter." Since the charter neither refers nor alludes to ISO 639-6, there is no conflict with the charter if WG members disagree in regard to the *eventual* expansion of the scope of language tags to involve ISO 639-6. The argument against the RFC 3066bis effort on the basis of the asserted existence of "20,000 languages" is attributable to M. Morfin alone. He is not being truthful in saying that he does not oppose the draft; he has spent the entire lifetime of the LTRU WG, and before, shouting his opposition from the rooftops. > I fully share the concerns of Doug Ewell. M. Morfin does not share any concerns with me, except to the extent he can twist my words to mean something I do not intend. I hereby disassociate myself with any statements made by M. Morfin concerning the drafts produced by the LTRU WG. I hope that is clear enough for IETF members. > 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped) > to 650 K (100 K zipped). This information, updates and additions MUST > be available to each of the on-line application of the devices of > billions of users. The Draft does not explain how. The WG decided this was an IANA implementation issue, and out of scope. Clearly, if some consider it wrong to specify both a registry format and a registration procedure within the same draft, it would be that much worse to dictate to IANA how it should manage its resources. > 2. One of the author has _legitimate_ concerns about the capacity of > the proposition and the reasonability of the Charter expectation to > support the ISO 639-6 evolution of the underlying ISO standards. Any talk within the LTRU WG regarding ISO 639-6 is just that: talk. There is no charter requirement to support ISO 639-6. (There *is* a charter requirement to begin paving the way for support of ISO 639-3, and we have addressed that requirement within the limitation that ISO 639-3 is still not an approved standard.) > But he is wrong is in assuming that I use this as an argument against > the current RFC 3066bis effort. To the contrary, I use it for a an > argument to support the proposed Draft as default solution and > support extensions and practical information distribution through > other adapted solutions introduced by a singleton. I invite any interested IETF member to peruse the WG archives, and judge for himself whether M. Morfin supports the draft or not. Since there are no detectable RFC 3683 or 3934 constraints on M. Morfin's right to post anything he likes, I expect the usual scathing personal attack in response. (Don't bother sending it to me personally; I do have a Blocked Senders list.) -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 22:26:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ZLb-0004bX-QN; Sun, 28 Aug 2005 22:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ZLa-0004bF-Gz; Sun, 28 Aug 2005 22:26:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26080; Sun, 28 Aug 2005 22:26:04 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9ZMp-0006P7-V8; Sun, 28 Aug 2005 22:27:24 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 19:25:56 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 19:25:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 28 Aug 2005 19:26:05 -0700 Message-ID: Thread-Topic: STD (was: Last Call: 'Tags for Identifying Languages'toBCP) Thread-Index: AcWsMVnVpSX9hWW8Skm3a+zAqE/SMQAAx6FA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 29 Aug 2005 02:25:56.0055 (UTC) FILETIME=[FC4A7670:01C5AC40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: iesg@iesg.org, ietf@ietf.org Subject: [Ltru] RE: STD (was: Last Call: 'Tags for Identifying Languages'toBCP) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > An exchange on WG-ltru documents... In this post from Mr. Morfin, it is difficult (at least for me) to ascertain his point other than in relation to certain specifics: > The > proposed langtag is an arbitrary limited compound of three > information: language name, script and country. A language > identification MAY call for far more elements, and deliver much more > information. Mr. Morfin has often suggested to the LTRU WG that language tags should be able to provide greater information than is allowed by the draft. He has never provided any specific proposal except a request to permit certain private-use tags, which I will return to below. The consensus of the remainder of the LTRU WG is that the draft supports all relevant distinctions needed to describe the linguistic and written-form attributes of content as may be needed for all purposes, commercial and otherwise. > This means that: > - "fr-Latn-fr" is the default tag based upon ISO 639-1/2/3 > - "x-fran" is a private use tag based upon ISO 639-6 > - "0-jefsey.com:franver" is my vision of the French at the Palace of > Versailles. Documented by an ISO 11179 conformant system (see below) Two comments: First, Mr. Morfin suggested within the LTRU WG that the syntax for language tags should be loosened to permit additional characters, such as "." and ":". The remainder of the WG was in consensus that this was unacceptable due to backward incompatibility with processes designed to conform to RFC 3066. Secondly, Mr. Morfin has repeatedly made mention of ISO 11179, a series of ISO standards on metadata and metadata registries, indicating his view that language tags used on the Internet should be maintained in a registry conformant with ISO 11179, and therefore that the draft should make reference to those standards. He has also, on several occasions such as his comments above, cited ISO 11179 in relation to his views in a manner that appears to be intended to suggest that his views are superior to the draft because he has cited that series of standards while the draft does not. A reality check is in need here: - While Mr. Morfin cites ISO 11179, he has never made statements=20 that clearly indicate that he actually understands those=20 standards. - While Mr. Morfin refers to "an ISO 11179 conformant system",=20 none of the ISO 11179 series of standards contains any statement=20 of conformance requirements. Thus, no such notion of "ISO 11179=20 conformant" is defined anywhere. All that can be said is that a=20 system of metadata elements is maintained and administered using=20 a certain amount of the conceptual model, practice and=20 administrative infrastructure specified in the ISO 11179 standards.=20 The draft uses some measure of these, though it does not make=20 normative reference to ISO 11179. In terms of ISO 11179 notions, each entry in the proposed registry=20 includes the two essential components of a metadata element: a=20 representation, and a data element concept. Each item in the=20 registry indicates (i) the representation used in language tags,=20 (ii) a designator that indicates the value meaning and that can=20 also serve as the data identifier, (iii) the object class (its=20 "type"), (iv) the administrative status (limited to deprecated or=20 not deprecated), as well as other properties. Thus, while it cannot formally be said that the draft conforms to ISO 11179 (since no terms of conformance are defined), I think=20 it *can* reasonably be said that the draft creates a registry and system of metadata elements that is consistent with the model presented in ISO 11179. - The primary reason that the LTRU WG chose not to reference ISO 11179 in this draft had nothing to do with whether the WG=20 considered ISO 11179 appropriate or valuable in general. Rather, it was that it was not deemed that reference to ISO 11179 would add significant value in the context of an IETF language subtag registry. Taken together, the ISO 11179 standards are long and complex, and have not to our knowledge been referenced in any other IETF metadata registry -- and certainly not in relation to RFC 1766 or RFC 3066, which specifications accomplish their=20 purposes in spite of that absence of reference. Thus, when I see Mr. Morfin citing ISO 11179 in the course of arguing for some view that he holds, I consider that citation to have added nothing of significance in support of his view. > This means that this debate is only to lock a _final_ ABNF via an > accepted RFC and a loaded operationalIANA registry _before_ a simpler > solution [ISO 639-6] is available three months from now.... This statement makes several assumptions of uncertain validity, not the least of which is that use of alpha-4 symbols from ISO 639-6 for IETF language tags would constitute a simpler solution. Given the widespread existing use of RFC 3066 tags, use of ISO 639-6 would have to go alongside use of multi-part tags of the form permitted by RFC 3066, which is certainly not simpler than what is specified in the draft. > >Your statement doesn't contradict anything that Debbie has said, > >provided the context is ISO 639-6 alone. If we were to talk about > >incorporation of ISO 639-6 into a revision of RFC 3066, however, then > >duplication would become an issue for consideration. >=20 > This is the WG-ltru Charter that all the ISO codes be included. The charter makes reference to "the underlying ISO standards"; that is, to the ISO standards referenced in RFC 3066 or those cited in the charter to be incorporated into the update RFC. The charter does not cite ISO 639-6, let alone state that "all the ISO codes be included". > 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 of that standard assumes that metadata elements designate concepts within some conceptual system, and that the system of metadata elements includes a meta-model that reflects that conceptual system. This would have the effect of *constraining* the concepts represented to entities within that conceptual model. Those entities may be an infinite set, but the set of entities that can be represented by the tags defined by this draft would not increase in number if the draft were changed to reference ISO 11179. > But ISO 11179 totally open the concept... Clearly either Mr. Morfin does not understand ISO 11179 or, if he does, he has totally failed to express a statement consistent with that understanding. > I would then advise that the Draft is sent back to the WG-ltru, with > the suggestion that a lexicon is provided which would define what is > a "language", a "script", a "country", and the purpose (informative, > descriptive, normative?) of a langtag. This might be a big step ahead. Mr. Morfin submitted a request to the WG that these terms be defined. The consensus of everyone else in the WG was that this was not necessary since it would not significantly alter the ability of anyone to implement or use the specification. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 22:29:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ZOt-00053J-69; Sun, 28 Aug 2005 22:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ZOr-000536-0h for ltru@megatron.ietf.org; Sun, 28 Aug 2005 22:29:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26220 for ; Sun, 28 Aug 2005 22:29:25 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9ZNg-0001z8-7K for ltru@lists.ietf.org; Mon, 29 Aug 2005 04:28:16 +0200 Received: from c-180-160-2.hh.dial.de.ignite.net ([62.180.160.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 04:28:16 +0200 Received: from nobody by c-180-160-2.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 04:28:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 29 Aug 2005 04:21:26 +0200 Organization: Lines: 68 Message-ID: <43127126.46FD@xyzzy.claranet.de> References: <20050828203437.BKTC6870.mta1.adelphia.net@megatron.ietf.org> <008a01c5ac28$462498c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-2.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> the WG Chairs and the responsible AD did a very good job. > I would be tempted to agree with Bruce on this, except that > my lack of experience on other IETF Working Groups precludes > a meaningful comparison. My experience is limited to USEFOR and MARID. The latter must have been an all-time low in the history, "mismanagement" does not begin to describe the most blatant problems. So from that somewhat skewed POV maybe I should have said "good" instead of "very good". Otherwise my background is Fido- and Usenet, I'm not surprised when I need asbestos for a flamewar. And I'm ready to push back if somebody misrepresents what I said (as Jefesey tried it with you). And I'm ready to ignore off topic nonsense. While it can be necessary to use instruments like RfC 3934 this can backfire, if users cry "censorship" it could be worse than whatever the original cause was. Sure, when Jefsey harrassed John's employer it was "XAB" (= excessively annoying behaviour, the reason for an "excommunication" in Fidonet). Similar to RfC 3863, but RfC 3863 only addresses DOS-attacks, not "XAB". Fidonet rules would require a (serious) attempt of a peaceful settlement before a "formal policy complaint". And Randy did something in this direction. "Retro-moderation" (= moderation after an offensive article was posted) has its drawbacks, but IMHO it's far better than "moderation" (= censor all articles before they are posted). I wouldn't participate in moderated (= censored) groups, unless I trust the moderators absolutely. > other mayhem witnessed on this list is absolutely typical of > other IETF Working Groups. You started with a statement that you can't judge it, now you say it's absolutely typical (?) > Maybe RFCs 3683 and 3934 are meant for some higher level of > disruption and "unprofessional commentary" Above all they are new, RfC 3934 was published October 2004, most probably Jefsey, Randy, and Scott were the "beta-testers". For any unlucky RfC 3683 "tester", it requires IETF consensus, a "last call", it is on the same level as a proposed standard. BTW, it is also new (March 2004), and IIRC it was never tested. Let one of the ADs who helped to create this memo test it for the first time. > This WG has been made to be a very unpleasant experience for > me, and all I wanted to do was help put together a code list. Odd, after MARID and USEFOR I really liked LTRU, and of course all I wanted was to help you with the weird region codes. It was especially fun to work with Addison, as if we had precisely the same "vision", and the only problem was to get some details right for obscure formal rules, but no serious differences or ego-crap (some editors always insist on their own ideas). Okay, I didn't like Randy's "ticket flood". OTOH it was clear that he's forced to prepare for Jefsey's intended appeal. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 28 22:44:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Zd7-0007im-3D; Sun, 28 Aug 2005 22:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Zd5-0007ih-Mk for ltru@megatron.ietf.org; Sun, 28 Aug 2005 22:44:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26808 for ; Sun, 28 Aug 2005 22:44:09 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9ZeK-0006ri-Ox for ltru@ietf.org; Sun, 28 Aug 2005 22:45:30 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j7T2htYV010257; Sun, 28 Aug 2005 22:43:55 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 28 Aug 2005 22:43:50 -0400 Date: Sun, 28 Aug 2005 22:43:50 -0400 From: "John.Cowan" To: Frank Ellermann Subject: Re: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP Message-ID: <20050829024350.GA9592@NYCMJCOWA2> References: <20050828203437.BKTC6870.mta1.adelphia.net@megatron.ietf.org> <008a01c5ac28$462498c0$030aa8c0@DEWELL> <43127126.46FD@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43127126.46FD@xyzzy.claranet.de> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Sure, when Jefsey harrassed > John's employer it was "XAB" (= excessively annoying behaviour, > the reason for an "excommunication" in Fidonet). I would say XAB from a DAU. -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.reutershealth.com pleasures in life.... http://www.ccil.org/~cowan --Jeni Tennison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 00:16:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9b1U-00051M-AF; Mon, 29 Aug 2005 00:13:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9b1P-00050T-3r; Mon, 29 Aug 2005 00:13:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29945; Mon, 29 Aug 2005 00:13:20 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9b2f-0000fV-Ey; Mon, 29 Aug 2005 00:14:42 -0400 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050829041146.VVRY19267.mta10.adelphia.net@DEWELL>; Mon, 29 Aug 2005 00:11:46 -0400 Message-ID: <01b801c5ac4f$b79ada60$030aa8c0@DEWELL> From: "Doug Ewell" To: , References: <6.2.3.4.2.20050827113513.04327160@pop.online.fr><431090C2.20804@blueyonder.co.uk><6.2.3.4.2.20050827201217.0598d250@mail.jefsey.com><4310E7E8.4070408@blueyonder.co.uk><6.2.3.4.2.20050828033256.03a3feb0@mail.jefsey.com><6.2.3.4.2.20050828111916.03a41040@mail.jefsey.com><009101c5ac2d$6ce6d4a0$030aa8c0@DEWELL> <6.2.3.4.2.20050829022911.0595eeb0@mail.afrac.org> Subject: Re: [Ltru] Re: Last Call: language root file size (long) Date: Sun, 28 Aug 2005 21:11:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA29945 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org JFC (Jefsey) Morfin wrote: > I am sorry to impose that kind of response - and a large number of > mails. But this shows the problem to protect an open R&D capacity > against a chapel, which as some good points. And a non-profit R&D > against people sharing in a commercial competing consortium. Since most of M. Morfin's messages make at least passing mention of this supposed conflict between "open" and "commercial" interests -- the forces of good vs. the forces of evil, as it were -- I suppose some explanations about my own motives are in order. I do not have any commercial or financial stake in the success of the language-tag drafts. I am a software developer, working for a company that produces an internationalized software product, for (frankly) rather small values of "internationalized." Since we are working with the .NET platform, most of us have at least some familiarity with what the documentation calls "culture names," which are based on RFC 3066 but make use of some non-standard extensions. In addition to regular development, I am responsible for maintaining what we call "code lists," which are basically resource files shared between systems that otherwise know little about each other. I got involved in the language-tag project at its early stages, partly to avoid repeating some of the misconceptions I had had years earlier about RFC 3066. I had been keeping track of changes to ISO 639 and 3166 for many years anyway, so when the concept of a comprehensive language subtag registry came up, I mocked up my own "example" registry that matched the description in the draft. That "example" eventually became the proposed initial registry. I have developed, on my own time and with no company assistance, a small utility program that generates and validates language tags according to the current draft. It contains a database that is compiled programmatically from the text registry (into a DLL). It is flexible in the sense that the database can be updated independently from the main program. It understands the concept of extended-language subtags, although none are defined in the current draft. The IETF may wish to consider this "running code," or a "working implementation," for purposes of evaluating the drafts, and if IETF members are interested in examining it to help with serious evaluation of the drafts -- not just to find reasons to tear it down -- I can make it freely available. (I have not released it yet, of course, because the RFCs on which it is based are only I-Ds.) Very importantly, this program is **NOT** a commercial endeavor. It could conceivably be made into one, or it culd be offered as freeware or shareware (although I have no specific plans to do either), but it could just as easily be converted to an "open source" project of the type often mentioned by M. Morfin. The point is that there is NO dichotomy between "free" (or "open" or "non-profit") and "commercial" (or "corporate") when it comes to the current drafts. The draft contains NO restrictions against open-source or non-profit implementation (I would think they would be strongly encouraged). There is nothing in the ABNF that prevents open-source development based on the proposed BCP. There are no IP constraints on any of the technology used in its development. Any existing protocols that make use of language tags, and stand to benefit from the proposed update, will benefit equally regardless of whether they are commercial or not. M. Morfin has argued that there are prevalent "running code" implementations that use his expanded language-tag syntax, which is not compatible with the syntax in the present draft. However, to date I have not seen any pointers to such an implementation, nor any evidence of the "prevalence" of this alternative syntax. Obviously any developer can write code that *does not conform* to a given standard, or proposed standard, but that says nothing about the standard itself, or about whether the non-conformant code or the syntax it does follow is somehow better. The arguments that RFC 3066 is widely ignored are specious as well; there are numerous examples of protocols that adhere to the RFC 3066 model. The fact that non-conformant implementations (like the culture identifiers) exist is not a justification for throwing away the model. To cite an example from another thread, we acknowledge that some mail software implements "Reply-To" poorly, but that does not mean the whole notion of "Reply-To" should be thrown away as irrelevant, or "not supported by open R&D solutions." I apologize for the length of this particular point, but I feel it is important. Not everyone who supports the draft does so out of commercial greed, and even those who happen to work for Big Commercial Behemoths might have higher motives. Some people just like the feel of an "open software vs. closed software" struggle, =C3=A1 la Richard Stallm= an or Eric Raymond -- note M. Morfin's reference to a "chapel," evoking images of Raymond's "The Cathedral and the Bazaar" -- but the truth is that this image simply doesn't apply to the LTRU draft. >> What I said, as anyone can see from reading the quote above, is that >> a 740-page I-D might be unwieldy enough that the IETF might consider >> a different procedural mechanism for delivering the information to >> IANA. > > Correct. > I do not see the need of all the innuendo above to repeat what I > quoted. It was quoted as though it proved "some of the problems resulting from the expected size of the language tag registry and the capacity of the langtag solution to fulfill the WG-ltru Charter." It does nothing of the sort. Whether IETF or IANA wants to deal with a 740-page I-D is entirely up to them. >> Since the charter neither refers nor alludes to ISO 639-6, there is >> no conflict with the charter if WG members disagree in regard to the >> *eventual* expansion of the scope of language tags to involve ISO >> 639-6. > > This repeated allusion to the Charter neither refering nor alluding > to ISO 639-6 is to be compared with the text of the Charter > (http://ietf.org/html.charters/ltru-charter.html) which says "It is > also expected to provide mechanisms to support the evolution of the > underlying ISO standards, in particular ISO 639-3". Peter Constable has already addressed the meaning of "the underlying ISO standards." ISO 639-6 is not an underlying ISO standard for purposes of this draft. (It's not even a standard, in fact, not even a CD yet.) For that matter, ISO 6709 is also not an underlying ISO standard for purposes of this draft, so the draft does not permit tags of the form "fr+484816+0020708" either. > This kind of problem may be related to the refusal of the WG to start > from/analyse the Charter requirments? I understand the charter requirements just fine. Almost all of the WG does. > I do not know if I share concerns with Doug. I do share the concerns > of Doug. The concern quoted above was that a 740-page I-D might be unwieldy. I acknowledge that M. Morfin might share that concern. Happily, it is a concern for the next draft, not this one. >> I hereby disassociate myself with any statements made by M. Morfin >> concerning the drafts produced by the LTRU WG. I hope that is clear >> enough for IETF members. > > Since I said I supported his Draft .... "Disassociate" does not mean "disagree." It means I do not speak so as to bolster his point. >>> 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped) >>> to 650 K (100 K zipped). This information, updates and additions >>> MUST be available to each of the on-line application of the devices >>> of billions of users. The Draft does not explain how. >> >> The WG decided this was an IANA implementation issue, and out of >> scope. > > Correct. This is exactly what I say. I suppose if we want to pursue this issue of huge daily updates and bandwidth consumption, we should start by asking how many implementations currently perform daily updates on the existing IANA Language Tag Registry, a resource which (of course) is necessary to implement RFC 3066 fully. > Doug said in another mail "I just think the two figures (7,600 and > 20,000) could be seen as representing a fundamental disagreement." > This is a legitimate concern at a time a LC is to engage the whole > IETF in a direction where you think this is unclear. I would not > qualify that of ust "talk". This is something loyalty calls you to > say, even if it is to explain why there is no fundamental > disagreement. 1. The charter does not refer to ISO 639-6, which will eventually encode 20,000 "languages and dialects." 2. The charter does refer to ISO 639-3, which will encode 7,600 languages, but only for future planning, for "evolution." 3. The proposed initial registry contains subtags based only on the existing standards: ISO 639-1 and 639-2, ISO 3166-1, ISO 15924, and United Nations M.49, as well as "variant" and "grandfathered" subtags based on the RFC 3066 registry. 4. Normative references to a not-yet-completed standard are bad, for the same reason that normative references to an I-D are bad. > NB. As a user, the langtag solution does not provide as much > possibilities, simplicity, flexibility than solutions using ISO 639-6 > (with the possible use of ISO 639-1/2/3 when necessary. This is IETF > not ISO. THERE IS NO ISO 639-6. There will be, some day, but such a standard does NOT exist now. Good heavens, the data is not even publicly available yet! Of course the language tag solution is not going to be based on a vapor standard. > I have documented enough (too much :-)) during these last days that I > support (one can read my mails of end of December 2004) the Draft > with the provision it is not exclusive and serves the Internet > community rather than exclude its R&D and innovation capacity. The purpose of language tags is interoperability. This purpose is not served if every organization invents its own extensions. The sections of the draft that deal with private-use tags and subtags are heavily laden with caveats to explain this. > Happily I support my Unicode co-Member Doug's own Draft and I thanked > him for the work he consciensiously achieved over the months > maintaining the base he now proposes as a Draft! (even if I doubt a > 740 pages I-D can be of real use in the future). I acknowledge M. Morfin's support for draft-initial, and thank him for his restraint in this message. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 01:15:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9bzn-0005X5-PZ; Mon, 29 Aug 2005 01:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9bzk-0005WR-IL; Mon, 29 Aug 2005 01:15:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02265; Mon, 29 Aug 2005 01:15:44 -0400 (EDT) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9c10-0002F9-SG; Mon, 29 Aug 2005 01:17:04 -0400 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050829051528.XTTU19267.mta10.adelphia.net@DEWELL>; Mon, 29 Aug 2005 01:15:28 -0400 Message-ID: <01bd01c5ac58$a1a56dc0$030aa8c0@DEWELL> From: "Doug Ewell" To: , References: <6.2.3.4.2.20050827113513.04327160@pop.online.fr><431090C2.20804@blueyonder.co.uk><6.2.3.4.2.20050827201217.0598d250@mail.jefsey.com><4310E7E8.4070408@blueyonder.co.uk><6.2.3.4.2.20050828033256.03a3feb0@mail.jefsey.com><6.2.3.4.2.20050828111916.03a41040@mail.jefsey.com><009101c5ac2d$6ce6d4a0$030aa8c0@DEWELL><6.2.3.4.2.20050829022911.0595eeb0@mail.afrac.org> <01b801c5ac4f$b79ada60$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Last Call: language root file size (long) Date: Sun, 28 Aug 2005 22:15:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I wrote: > 3. The proposed initial registry contains subtags based only on the > existing standards: ISO 639-1 and 639-2, ISO 3166-1, ISO 15924, and > United Nations M.49, as well as "variant" and "grandfathered" subtags > based on the RFC 3066 registry. Should have been: "variant" subtags and "grandfathered" tags There is no such thing in the draft as a grandfathered subtag. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 01:21:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9c5d-0006Uq-Cw; Mon, 29 Aug 2005 01:21:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9c5W-0006Td-NQ; Mon, 29 Aug 2005 01:21:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02598; Mon, 29 Aug 2005 01:21:42 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9c6k-0002Qv-6z; Mon, 29 Aug 2005 01:23:02 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9c54-0005yE-2K; Sun, 28 Aug 2005 22:21:17 -0700 Message-Id: <6.2.3.4.2.20050829044546.05a00c30@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 07:21:06 +0200 To: "Peter Constable" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] RE: STD (was: Last Call: 'Tags for Identifying Languages'toBCP) In-Reply-To: References: Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 20c6ed26ee4f226a67d90641b17dfc32 Cc: iesg@iesg.org, ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0239373316==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0239373316== Content-Type: multipart/alternative; boundary="=====================_164349502==.ALT" --=====================_164349502==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I am sorry to impose again the community, what starts amounting to ad-hominems. Please, Brian advise if inadequate. At 04:26 29/08/2005, Peter Constable wrote: > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > The > > proposed langtag is an arbitrary limited compound of three > > information: language name, script and country. A language > > identification MAY call for far more elements, and deliver much more > > information. > >Mr. Morfin has often suggested to the LTRU WG that language tags should >be able to provide greater information than is allowed by the draft. He >has never provided any specific proposal except a request to permit >certain private-use tags, which I will return to below. Dear Peter, This kind of repetition now abuse no one. I bored everyone enough in explaining that two additional subtags were necessary IMHO: the referent and the context. There is also - a way or another the need of the date of the reference (this can be a date or included in a subtag). This is documented at length in a mail of mine today. I will not repeat it. I will only suggest you study Word. >The consensus of >the remainder of the LTRU WG is that the draft supports all relevant >distinctions needed to describe the linguistic and written-form >attributes of content as may be needed for all purposes, commercial and >otherwise. This is an historic statement I hope no one will forget. Every searcher and engineer knows the value of such final "all". 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. > > This means that: > > - "fr-Latn-fr" is the default tag based upon ISO 639-1/2/3 > > - "x-fran" is a private use tag based upon ISO 639-6 > > - "0-jefsey.com:franver" is my vision of the French at the Palace of > > Versailles. Documented by an ISO 11179 conformant system (see below) > >Two comments: First, Mr. Morfin suggested within the LTRU WG that the >syntax for language tags should be loosened to permit additional >characters, such as "." and ":". This is a false affirmation. I did two things: - benefiting from the marvelous capacity to direct the WG-ltru decisions in proposing the necessary opposite, I made sure the ABNF would be fool proof (this is not yet exactly the case as they did not always find the proper [cf. Peter] "constraints". - I supported the proposition of an African searcher (they treated of troll) to reconcile the desire of a strict ABNF expressed by the WG affinity group and the users, R&D and innovation (following ISO evolution) support to use the URI-tags RFC in proposing first to use the "private use" area. As indicated, a remark shown me it was a wrong choice, the private use area also addressing other needs. I then came to the conclusion that using the present Draft as a default non exclusive solution, and some reserved numeric "singleton" as the hooks for URI-tags was preserving the work made by the WG, while addressing the needs of the rest of the world, avoiding an unnecessary conflict. >The remainder of the WG was in >consensus that this was unacceptable due to backward incompatibility >with processes designed to conform to RFC 3066. > >Secondly, Mr. Morfin has repeatedly made mention of ISO 11179, a series >of ISO standards on metadata and metadata registries, indicating his >view that language tags used on the Internet should be maintained in a >registry conformant with ISO 11179, and therefore that the draft should >make reference to those standards. He has also, on several occasions >such as his comments above, cited ISO 11179 in relation to his views in >a manner that appears to be intended to suggest that his views are >superior to the draft because he has cited that series of standards >while the draft does not. The Draft addresses targets you defined a long ago. It was presented privately (twice) and is now presented as a WG document. The document having not changed, one can expect that it keeps the same targets. You consider it addresses them "all". There can therefore be no "superior" views. There are different targets. My target is protect the R&D, users, and Internet innovation. In a nutshell, I do _not_ believe that a draft crafted by a few individuals can supports all the relevant distinctions needed to describe the linguistic and written-form attributes of content as may be needed for all purposes, commercial and otherwise. And I want to protect other searchers and cultures' right to have their own solutions, _without_conflict_ and detriment to _your_solution_. The real solution is IRI-tags we will document as soon as the URI-tags RFC is published. But that will create a deployment conflict with your application, due to your sponsors. No one needs that. >A reality check is in need here: > >- While Mr. Morfin cites ISO 11179, he has never made statements > that clearly indicate that he actually understands those standards. I propose everyone having time to spend to read ISO 11179 and to judge. In a recent mail, Peter acknowledged the need to consider ISO 11179 and explained that ISO 12620 was its equivalent. May be the difference between an engineering and a literary approach ... One may note that I just proposed the IETF initiates a WG in the ISO 11179 area. The reason why is that ISO 11179 has not yet engaged the networking aspects. The work we carry on CRC (common reference centers) gives a vision of interest. I often compare ISO 11179 to X.500 and the work to be carried to LDAP. The importance to the internet architectural development should not be overlooked. I currently try to gather the necessary funding for a French AFNOR budget on the matter. >- While Mr. Morfin refers to "an ISO 11179 conformant system", > none of the ISO 11179 series of standards contains any statement > of conformance requirements. Thus, no such notion of "ISO 11179 > conformant" is defined anywhere. :-) :-) This is the second Historic statement! Too bad there is Google .... http://www.google.fr/url?sa=t&ct=res&cd=6&url=http%3A//www.epa.gov/sor/xml_tag_reg_gundry.pps&ei=Q38SQ-H7EpiERf-NydsK http://www.schemas-forum.org/registry/desire/activityreports.php3?field=filename&value=JTCI_SC32_D29D35(RDF).rtf "WG 2 intends to recommend using XML for accessing and interchanging information in 11179 conformant data registries. They expect that specific XML tags and data structure will be algorithmically derived form the normative UML data model specified in 11179 part 3. The Object Management Group (OMG) has already adopted a standard for XMI (XML Model Interchange), which they expect to recommend as one mechanism for such algorithmic derivation of XML representation from UML models. Work is also underway to foster interoperation between ISO/IEC 11179 metadata registries, XML registries, Universal Description Discovery and Integration (UDDI) registries, database catalogs, ontology registries and CASE tool repositories. The Sc 32 work is positioned to meet deeper semantic management aspects of data management and interchange. WG 2 has already initiated electronic Working group meetings to progress its program as quickly and efficiently as possible." http://www.jtc1sc34.org/repository/0346.htm WG 2 intends to recommend using XML for accessing and interchanging information in 11179 conformant data registries. http://www.google.fr/url?sa=t&ct=res&cd=24&url=http%3A//www.loria.fr/%7Elandragi/publis/catalog.ps&ei=xoESQ_rcDLWgRa30gNQK www.ncess.ac.uk/events/conference/programme/presentations/ncess2005_gillam.pdf etc. > All that can be said is that a > system of metadata elements is maintained and administered using > a certain amount of the conceptual model, practice and > administrative infrastructure specified in the ISO 11179 standards. > The draft uses some measure of these, though it does not make > normative reference to ISO 11179. This certainly explains the confusion with ISO 12620. > In terms of ISO 11179 notions, each entry in the proposed registry > includes the two essential components of a metadata element: a > representation, and a data element concept. Each item in the > registry indicates (i) the representation used in language tags, > (ii) a designator that indicates the value meaning and that can > also serve as the data identifier, (iii) the object class (its > "type"), (iv) the administrative status (limited to deprecated or > not deprecated), as well as other properties. A simplified vision, as noted in a previous mail, is C structures. Where a name can designate a value or another structure. What is interesting in a network context is that one can add a "scheme" to the structure as the URL/IP address of the registry (URI Tags). This means that two people can build the same registry description and links, and yet they are different registry systems. One simple application (but this is general) is to consider a language description registry root (lang root) using ISO 639-6. If instead of using entity names (for example "engl") I use the entity ID (for example an IPv6 interface ID) I can associate to the same base thousands of namelists, one for each language. At no cost. We can also keep the IPv6 ID grid and to port it under another IPv6 address for another language. And we can replicate the documentation of the language in various languages. Default to other languages when an information is missing is easy, since we play only on IPv6 addresses with the same Identifier ID. Flexibility is total and filtering/equivalence rules can be stored as one of the data file. The interest is that the same Item ID can be used as pointers in a local database [referents] (either loaded via a CD, or cached). We can build a local vision of a language and related information, according to personal rules. This means that we can have billions of ISO 11179 conformant descriptions based on ISO 639-6 names/IDs [context]. And to dynamically update them. The initial database interest is that on can allocate IDs to the subtags and to langtags. But this is not documented and the work is huge (ISO 639-6 is to provide them). Now, a langtag including the referent and the context will support interintelligibility between people the way want. Supported by an OPES people may even relate in "language" they do not know. But what is a language? > Thus, while it cannot formally be said that the draft conforms > to ISO 11179 (since no terms of conformance are defined), I think > it *can* reasonably be said that the draft creates a registry and > system of metadata elements that is consistent with the model > presented in ISO 11179. ISO 12620 understanding. Confusion resulting from the Varsaw meeting. ISO 639-6 can translate some minor (in term of importance) in terms from ISO 12620. That's all. >- The primary reason that the LTRU WG chose not to reference ISO > 11179 in this draft had nothing to do with whether the WG > considered ISO 11179 appropriate or valuable in general. Thank you for confirming that we are not interested in the same area. Then I can only say "keep clear". Play in your own field, we will help (I made sure you ABNF is quite proof). But leave others to address their own concerns. >Rather, > it was that it was not deemed that reference to ISO 11179 would > add significant value in the context of an IETF language subtag > registry. Taken together, the ISO 11179 standards are long and > complex, and have not to our knowledge been referenced in any > other IETF metadata registry This is why we have to create a WG on that area. But may be premature? > -- and certainly not in relation > to RFC 1766 or RFC 3066, which specifications accomplish their > purposes in spite of that absence of reference. > >Thus, when I see Mr. Morfin citing ISO 11179 in the course of arguing >for some view that he holds, I consider that citation to have added >nothing of significance in support of his view. see above. > > This means that this debate is only to lock a _final_ ABNF via an > > accepted RFC and a loaded operationalIANA registry _before_ a simpler > > solution [ISO 639-6] is available three months from now.... > >This statement makes several assumptions of uncertain validity, not the >least of which is that use of alpha-4 symbols from ISO 639-6 for IETF >language tags would constitute a simpler solution. You do not need to sell your solution. I explained again and again I support it. But do not say that it addresses my and other people's needs. It cannot be exclusive and exclude us all. >Given the widespread >existing use of RFC 3066 tags, use of ISO 639-6 would have to go >alongside use of multi-part tags of the form permitted by RFC 3066, >which is certainly not simpler than what is specified in the draft. Draft centric assumption. Peter, your Draft is not the center of the world. The user is. Simplicity is not according to your ABNF. Simplicity is according to the user with her needs. You think (and it may very well be) that your solution is simpler for you. I even accept that in some cases it may also be for me. But your solution does not scale. You have the same langtag capacity to document the English language of Pitcairn and of the USA. You miss half the existing scripts, do not cover founts and do not document anything of voice and signs. Your proposition is not able to be multilingual, You do not know what is a language in your context (and this is not easy) .... etc. etc. > > >Your statement doesn't contradict anything that Debbie has said, > > >provided the context is ISO 639-6 alone. If we were to talk about > > >incorporation of ISO 639-6 into a revision of RFC 3066, however, then > > >duplication would become an issue for consideration. > > > > This is the WG-ltru Charter that all the ISO codes be included. > >The charter makes reference to "the underlying ISO standards"; that is, >to the ISO standards referenced in RFC 3066 or those cited in the >charter to be incorporated into the update RFC. The charter does not >cite ISO 639-6, let alone state that "all the ISO codes be included". Having considered the old failed Draft instead of the Charter did not help .... http://ietf.org/html.charters/ltru-charter.html "It is also expected to provide mechanisms to support the evolution of the underlying ISO standards, in particular ISO 639-3". How do you read "evolution"? As far as I am concerned, we want to use, help, benefit from, etc. that evolution and do not want you to block us. "US" being all of us, and in particular my own team. > > 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 of that standard >assumes that metadata elements designate concepts within some conceptual >system, and that the system of metadata elements includes a meta-model >that reflects that conceptual system. This would have the effect of >*constraining* the concepts represented to entities within that >conceptual model. Those entities may be an infinite set, but the set of >entities that can be represented by the tags defined by this draft would >not increase in number if the draft were changed to reference ISO 11179. You seem now to want to tag your langtags with "ISO 11179" (soon we will learn they are "ISO 11179 inside"). Good! But this means you will have to _change_ your draft because the set of entities that can be represented by the tags defined by this draft will dramatically increase in number and in related information .... Once you have done it, we will probably say the same. > > But ISO 11179 totally open the concept... > >Clearly either Mr. Morfin does not understand ISO 11179 or, if he does, >he has totally failed to express a statement consistent with that >understanding. At this stage the reader has probably set-up his/her opinion. > > I would then advise that the Draft is sent back to the WG-ltru, with > > the suggestion that a lexicon is provided which would define what is > > a "language", a "script", a "country", and the purpose (informative, > > descriptive, normative?) of a langtag. This might be a big step ahead. > >Mr. Morfin submitted a request to the WG that these terms be defined. >The consensus of everyone else in the WG was that this was not necessary >since it would not significantly alter the ability of anyone to >implement or use the specification. May I just quote your response in another mail .... > > I agree that the broad question of "what is a language" is out of our > > scope. The more specific question "what is a taggable language > > distinction" is perhaps more germane. > >Not an unreasonable suggestion. Cheers.... jfc --=====================_164349502==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I am sorry to impose again the community, what starts amounting to ad-hominems.
Please, Brian advise if inadequate.

At 04:26 29/08/2005, Peter Constable wrote:
> From: JFC (Jefsey) Morfin [ mailto:jefsey@jefsey.com]
> The
> proposed langtag is an arbitrary limited compound of three
> information: language name, script and country. A language
> identification MAY call for far more elements, and deliver much more
> information.

Mr. Morfin has often suggested to the LTRU WG that language tags should
be able to provide greater information than is allowed by the draft. He
has never provided any specific proposal except a request to permit
certain private-use tags, which I will return to below.

Dear Peter,
This kind of repetition now abuse no one. I bored everyone enough in explaining that two additional subtags were necessary IMHO: the referent and the context. There is also - a way or another the need of the date of the reference (this can be a date or included in a subtag).

This is documented at length in a mail of mine today. I will not repeat it. I will only suggest you study Word.

The consensus of
the remainder of the LTRU WG is that the draft supports all relevant
distinctions needed to describe the linguistic and written-form
attributes of content as may be needed for all purposes, commercial and
otherwise.

This is an historic statement I hope no one will forget.
Every searcher and engineer knows the value of such final "all".

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.

> This means that:
> - "fr-Latn-fr" is the default tag based upon ISO 639-1/2/3
> - "x-fran" is a private use tag based upon ISO 639-6
> - "0-jefsey.com:franver" is my vision of the French at the Palace of
> Versailles. Documented by an ISO 11179 conformant system (see below)

Two comments: First, Mr. Morfin suggested within the LTRU WG that the
syntax for language tags should be loosened to permit additional
characters, such as "." and ":".

This is a false affirmation. I did two things:

- benefiting from the marvelous capacity to direct the WG-ltru decisions in proposing the necessary opposite, I made sure the ABNF would be fool proof (this is not yet exactly the case as they did not always find the proper [cf. Peter] "constraints".

- I supported the proposition of an African searcher (they treated of troll) to reconcile the desire of a strict ABNF expressed by the WG affinity group and the users, R&D and innovation (following ISO evolution) support to use the URI-tags RFC in proposing first to use the "private use" area. As indicated, a remark shown me it was a wrong choice, the private use area also addressing other needs.

I then came to the conclusion that using the present Draft as a default non exclusive solution, and some reserved numeric "singleton" as the hooks for URI-tags was preserving the work made by the WG, while addressing the needs of the rest of the world, avoiding an unnecessary conflict.

The remainder of the WG was in
consensus that this was unacceptable due to backward incompatibility
with processes designed to conform to RFC 3066.

Secondly, Mr. Morfin has repeatedly made mention of ISO 11179, a series
of ISO standards on metadata and metadata registries, indicating his
view that language tags used on the Internet should be maintained in a
registry conformant with ISO 11179, and therefore that the draft should
make reference to those standards. He has also, on several occasions
such as his comments above, cited ISO 11179 in relation to his views in
a manner that appears to be intended to suggest that his views are
superior to the draft because he has cited that series of standards
while the draft does not.

The Draft addresses targets you defined a long ago. It was presented privately (twice) and is now presented as a WG document.  The document having not changed, one can expect that it keeps the same targets. You consider it addresses them "all".

There can therefore be no "superior" views. There are different targets. My target is protect the R&D, users, and Internet innovation.

In a nutshell, I do _not_ believe that a draft crafted by a few individuals can supports all the relevant distinctions needed to describe the linguistic and written-form attributes of content as may be needed for all purposes, commercial and otherwise. And I want to protect other searchers and cultures' right to have their own solutions, _without_conflict_ and detriment to _your_solution_.

The real solution is IRI-tags we will document as soon as the URI-tags RFC is published. But that will create a deployment conflict with your application, due to your sponsors. No one needs that.

A reality check is in need here:

- While Mr. Morfin cites ISO 11179, he has never made statements
  that clearly indicate that he actually understands those standards.

I propose everyone having time to spend to read ISO 11179 and to judge.

In a recent mail, Peter acknowledged the need to consider ISO 11179 and explained that ISO 12620 was its equivalent. May be the difference between an engineering and a literary approach ...

One may note that I just proposed the IETF initiates a WG in the ISO 11179 area. The reason why is that ISO 11179 has not yet engaged the networking aspects. The work we carry on CRC (common reference centers) gives a vision of interest. I often compare ISO 11179 to X.500 and the work to be carried to LDAP. The importance to the internet architectural development should not be overlooked.

I currently try to gather the necessary funding for a French AFNOR budget on the matter.

- While Mr. Morfin refers to "an ISO 11179 conformant system",
  none of the ISO 11179 series of standards contains any statement
  of conformance requirements. Thus, no such notion of "ISO 11179
  conformant" is defined anywhere.

:-) :-)

This is the second Historic statement!
Too bad there is Google ....

http://www.google.fr/url?sa=t&ct=res&cd=6&url=http%3A//www.epa.gov/sor/xml_tag_reg_gundry.pps&ei=Q38SQ-H7EpiERf-NydsK
 http://www.schemas-forum.org/registry/desire/activityreports.php3?field=filename&value=JTCI_SC32_D29D35(RDF).rtf

"WG 2 intends to recommend using XML for accessing and interchanging information in 11179 conformant data registries. They expect that specific XML tags and data structure will be algorithmically derived form the normative UML data model specified in 11179 part 3. The Object Management Group (OMG) has already adopted a standard for XMI (XML Model Interchange), which they expect to recommend as one mechanism for such algorithmic derivation of XML representation from UML models. Work is also underway to foster interoperation between ISO/IEC 11179 metadata registries, XML registries, Universal Description Discovery and Integration (UDDI) registries, database catalogs, ontology registries and CASE tool repositories. The Sc 32 work is positioned to meet deeper semantic management aspects of data management and interchange. WG 2 has already initiated electronic Working group meetings to progress its program as quickly and efficiently as possible."

http://www.jtc1sc34.org/repository/0346.htm
WG 2 intends to recommend using XML for accessing and interchanging information in 11179 conformant data registries.

http://www.google.fr/url?sa=t&ct=res&cd=24&url=http%3A//www.loria.fr/%7Elandragi/publis/catalog.ps&ei=xoESQ_rcDLWgRa30gNQK
 www.ncess.ac.uk/events/conference/programme/presentations/ncess2005_gillam.pdf

etc.

  All that can be said is that a
  system of metadata elements is maintained and administered using
  a certain amount of the conceptual model, practice and
  administrative infrastructure specified in the ISO 11179 standards.
  The draft uses some measure of these, though it does not make
  normative reference to ISO 11179.

This certainly explains the confusion with ISO 12620.

  In terms of ISO 11179 notions, each entry in the proposed registry
  includes the two essential components of a metadata element: a
  representation, and a data element concept. Each item in the
  registry indicates (i) the representation used in language tags,
  (ii) a designator that indicates the value meaning and that can
  also serve as the data identifier, (iii) the object class (its
  "type"), (iv) the administrative status (limited to deprecated or
  not deprecated), as well as other properties.

A simplified vision, as noted in a previous mail, is C structures. Where a name can designate a value or another structure. What is interesting in a network context is that one can add a "scheme" to the structure as the URL/IP address of the registry (URI Tags). This means that two people can build the same registry description and links, and yet they are different registry systems.

One simple application (but this is general) is to consider a language description registry root (lang root) using ISO 639-6. If instead of using entity names (for example "engl") I use the entity ID (for example an IPv6 interface ID) I can associate to the same base thousands of namelists, one for each language. At no cost.

We can also keep the IPv6 ID grid and to port it under another IPv6 address for another language. And we can replicate the documentation of the language in various languages. Default to other languages when an information is missing is easy, since we play only on IPv6 addresses with the same Identifier ID. Flexibility is total and filtering/equivalence rules can be stored as one of the data file.

The interest is that the same Item ID can be used as pointers in a local database [referents] (either loaded via a CD, or cached). We can build a local vision of a language and related information, according to personal rules. This means that we can have billions of ISO 11179 conformant descriptions based on ISO 639-6 names/IDs [context]. And to dynamically update them.

The initial database interest is that on can allocate IDs to the subtags and to langtags. But this is not documented and the work is huge (ISO 639-6 is to provide them).

Now, a langtag including the referent and the context will support interintelligibility between people the way want. Supported by an OPES people may even relate in "language" they do not know. But what is a language?


  Thus, while it cannot formally be said that the draft conforms
  to ISO 11179 (since no terms of conformance are defined), I think
  it *can* reasonably be said that the draft creates a registry and
  system of metadata elements that is consistent with the model
  presented in ISO 11179.

ISO 12620 understanding. Confusion resulting from the Varsaw meeting. ISO 639-6 can translate some minor (in term of importance) in terms from ISO 12620. That's all.

- The primary reason that the LTRU WG chose not to reference ISO
  11179 in this draft had nothing to do with whether the WG
  considered ISO 11179 appropriate or valuable in general.

Thank you for confirming that we are not interested in the same area.
Then I can only say "keep clear". Play in your own field, we will help (I made sure you ABNF is quite proof). But leave others to address their own concerns.

Rather,
  it was that it was not deemed that reference to ISO 11179 would
  add significant value in the context of an IETF language subtag
  registry. Taken together, the ISO 11179 standards are long and
  complex, and have not to our knowledge been referenced in any
  other IETF metadata registry

This is why we have to create a WG on that area. But may be premature?

 -- and certainly not in relation
  to RFC 1766 or RFC 3066, which specifications accomplish their
  purposes in spite of that absence of reference.

Thus, when I see Mr. Morfin citing ISO 11179 in the course of arguing
for some view that he holds, I consider that citation to have added
nothing of significance in support of his view.

see above.

> This means that this debate is only to lock a _final_ ABNF via an
> accepted RFC and a loaded operationalIANA registry _before_ a simpler
> solution [ISO 639-6] is available three months from now....

This statement makes several assumptions of uncertain validity, not the
least of which is that use of alpha-4 symbols from ISO 639-6 for IETF
language tags would constitute a simpler solution.

You do not need to sell your solution. I explained again and again I support it.

But do not say that it addresses my and other people's needs. It cannot be exclusive and exclude us all.

Given the widespread
existing use of RFC 3066 tags, use of ISO 639-6 would have to go
alongside use of multi-part tags of the form permitted by RFC 3066,
which is certainly not simpler than what is specified in the draft.

Draft centric assumption. Peter, your Draft is not the center of the world. The user is. Simplicity is not according to your ABNF. Simplicity is according to the user with her needs. You think (and it may very well be) that your solution is simpler for you. I even accept that in some cases it may also be for me. But your solution does not scale.

You have the same langtag capacity to document the English language of Pitcairn and of the USA.
You miss half the existing scripts, do not cover founts and do not document anything of voice and signs.
Your proposition is not able to be multilingual,
You do not know what is a language in your context (and this is not easy) ....
etc. etc.

> >Your statement doesn't contradict anything that Debbie has said,
> >provided the context is ISO 639-6 alone. If we were to talk about
> >incorporation of ISO 639-6 into a revision of RFC 3066, however, then
> >duplication would become an issue for consideration.
>
> This is the WG-ltru Charter that all the ISO codes be included.

The charter makes reference to "the underlying ISO standards"; that is,
to the ISO standards referenced in RFC 3066 or those cited in the
charter to be incorporated into the update RFC. The charter does not
cite ISO 639-6, let alone state that "all the ISO codes be included".

Having considered the old failed Draft instead of the Charter did not help ....
http://ietf.org/html.charters/ltru-charter.html
"It is also expected to provide mechanisms to support the evolution
of the underlying ISO standards, in particular ISO 639-3".

How do you read "evolution"? As far as I am concerned, we want to use, help, benefit from, etc. that evolution and do not want you to block us. "US" being all of us, and in particular my own team.


> 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 of that standard
assumes that metadata elements designate concepts within some conceptual
system, and that the system of metadata elements includes a meta-model
that reflects that conceptual system. This would have the effect of
*constraining* the concepts represented to entities within that
conceptual model. Those entities may be an infinite set, but the set of
entities that can be represented by the tags defined by this draft would
not increase in number if the draft were changed to reference ISO 11179.

You seem now to want to tag your langtags with "ISO 11179" (soon we will learn they are "ISO 11179 inside"). Good!

But this means you will have to _change_ your draft because the set of entities that can be represented by the tags defined by this draft will  dramatically increase in number and in related information .... Once you have done it, we will probably say the same.

> But ISO 11179 totally open the concept...

Clearly either Mr. Morfin does not understand ISO 11179 or, if he does,
he has totally failed to express a statement consistent with that
understanding.

At this stage the reader has probably set-up his/her opinion.

> I would then advise that the Draft is sent back to the WG-ltru, with
> the suggestion that a lexicon is provided which would define what is
> a "language", a "script", a "country", and the purpose (informative,
> descriptive, normative?) of a langtag. This might be a big step ahead.

Mr. Morfin submitted a request to the WG that these terms be defined.
The consensus of everyone else in the WG was that this was not necessary
since it would not significantly alter the ability of anyone to
implement or use the specification.

May I just quote your response in another mail ....

<quote>

> I agree that the broad question of "what is a language" is out of our
> scope. The more specific question "what is a taggable language
> distinction" is perhaps more germane.

Not an unreasonable suggestion.

</quote>

Cheers....
jfc



--=====================_164349502==.ALT-- --===============0239373316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0239373316==-- From ltru-bounces@ietf.org Mon Aug 29 01:31:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9cEk-0000Ng-Mn; Mon, 29 Aug 2005 01:31:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9cEi-0000Nb-O8 for ltru@megatron.ietf.org; Mon, 29 Aug 2005 01:31:12 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03129 for ; Mon, 29 Aug 2005 01:31:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050829053041.WQGB14360.mta13.adelphia.net@DEWELL> for ; Mon, 29 Aug 2005 01:30:41 -0400 Message-ID: <01ca01c5ac5a$bfe335e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050829051715.OFHU9276.mta6.adelphia.net@megatron.ietf.org> Date: Sun, 28 Aug 2005 22:30:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> other mayhem witnessed on this list is absolutely typical of >> other IETF Working Groups. > > You started with a statement that you can't judge it, now you > say it's absolutely typical (?) I was afraid that big, long sentence might be misconstrued. What I wrote was: "For all I know, the sheer volume of... [blah blah blah] ... is absolutely typical of other IETF Working Groups." The operative phrase is "for all I know." I have only this one group to go by. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 01:44:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9cRf-00024s-Ti; Mon, 29 Aug 2005 01:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9cRe-00024Q-5W for ltru@megatron.ietf.org; Mon, 29 Aug 2005 01:44:34 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03517 for ; Mon, 29 Aug 2005 01:44:30 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050829054359.YHBO19267.mta10.adelphia.net@DEWELL>; Mon, 29 Aug 2005 01:43:59 -0400 Message-ID: <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> Date: Sun, 28 Aug 2005 22:43:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, iesg@iesg.org Subject: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org r&d afrac wrote: > - I supported the proposition of an African searcher (they treated of > troll) to reconcile the desire of a strict ABNF expressed by the WG > affinity group and the users, R&D and innovation (following ISO > evolution) support to use the URI-tags RFC in proposing first to use > the "private use" area. As indicated, a remark shown me it was a > wrong choice, the private use area also addressing other needs. Merriam-Webster OnLine defines "affinity group" as "a group of people having a common interest or goal or acting together for a specific purpose (as for a chartered tour)." Exercise for the reader: Explain why this is a bad thing for an IETF Working Group. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 03:14:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dqQ-0006Xz-SO; Mon, 29 Aug 2005 03:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dqP-0006Xe-8b; Mon, 29 Aug 2005 03:14:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20926; Mon, 29 Aug 2005 03:14:11 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9drg-0005Lm-2g; Mon, 29 Aug 2005 03:15:33 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9dqM-00023y-5z; Mon, 29 Aug 2005 00:14:10 -0700 Message-Id: <6.2.3.4.2.20050829090011.04dcc7f0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 09:07:45 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP) In-Reply-To: <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ietf@ietf.org, iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 07:43 29/08/2005, Doug Ewell wrote: >r&d afrac wrote: > > > - I supported the proposition of an African searcher (they treated of > > troll) to reconcile the desire of a strict ABNF expressed by the WG > > affinity group and the users, R&D and innovation (following ISO > > evolution) support to use the URI-tags RFC in proposing first to use > > the "private use" area. As indicated, a remark shown me it was a > > wrong choice, the private use area also addressing other needs. > >Merriam-Webster OnLine defines "affinity group" as "a group of people >having a common interest or goal or acting together for a specific >purpose (as for a chartered tour)." > >Exercise for the reader: Explain why this is a bad thing for an IETF >Working Group. Slowly, the good questions are asked. May be can I suggest to read: "RFC 3774 2.2.6: Members of this affinity group tend to talk more freely to each other and former members of the affinity group - this may be because the affinity group has also come to share a cultural outlook which matches the dominant cultural ethos of the IETF (North American, English speaking). Newcomers to the organization and others outside the affinity group are reluctant to challenge the apparent authority of the extended affinity group during debates and consequently influence remains concentrated in a relatively small group of people. This reluctance may also be exacerbated if participants come from a different cultural background than the dominant one." Obviously I am not much impressed by such "apparent authority" .... But the affinity group can use its number of to make believe and organise consensus by exhaustion: "RFC 3774 2.7: On the other hand, the decision making process must allow discussions to be re-opened if significant new information comes to light or additional experience is gained which appears to justify alternative conclusions for a closed issue. One cause that can lead to legitimate attempts to re-open an apparently closed issue is the occurrence of 'consensus by exhaustion'. " Take care. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 03:14:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dqW-0006ZE-OP; Mon, 29 Aug 2005 03:14:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dqP-0006Xd-84; Mon, 29 Aug 2005 03:14:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20928; Mon, 29 Aug 2005 03:14:11 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9dre-0005Lg-PR; Mon, 29 Aug 2005 03:15:33 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9dqG-00023y-RK; Mon, 29 Aug 2005 00:14:08 -0700 Message-Id: <6.2.3.4.2.20050829072137.03a47710@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 09:13:56 +0200 To: "Doug Ewell" , , From: r&d afrac Subject: Re: [Ltru] Re: Last Call: language root file size (long) In-Reply-To: <01b801c5ac4f$b79ada60$030aa8c0@DEWELL> References: <6.2.3.4.2.20050827113513.04327160@pop.online.fr> <431090C2.20804@blueyonder.co.uk> <6.2.3.4.2.20050827201217.0598d250@mail.jefsey.com> <4310E7E8.4070408@blueyonder.co.uk> <6.2.3.4.2.20050828033256.03a3feb0@mail.jefsey.com> <6.2.3.4.2.20050828111916.03a41040@mail.jefsey.com> <009101c5ac2d$6ce6d4a0$030aa8c0@DEWELL> <6.2.3.4.2.20050829022911.0595eeb0@mail.afrac.org> <01b801c5ac4f$b79ada60$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA20928 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 06:11 29/08/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > I am sorry to impose that kind of response - and a large number of > > mails. But this shows the problem to protect an open R&D capacity > > against a chapel, which as some good points. And a non-profit R&D > > against people sharing in a commercial competing consortium. > >Since most of M. Morfin's messages make at least passing mention of this >supposed conflict between "open" and "commercial" interests -- the >forces of good vs. the forces of evil, as it were -- I suppose some >explanations about my own motives are in order. Dear Doug, I read very carefully your mail. I apologise if you felt personally=20 concerned. None more than myself can understand that. You may realise=20 that I am even accused to have defended my own consulting practice=20 (you are an employee, I am an independent, sharing in non-profit I=20 often also subsidise) because I started losing clients because a=20 member used mails with his corporate name. My own involvement is in this area dates of 25 years and I accepted=20 much to defend the users needs. This lead to many experimentations.=20 The potential is huge for the users (to get back for everyone to what=20 I did in 1985 for countries). All this is directly endangered by the Draf= t. >Very importantly, this program is **NOT** a commercial endeavor. It >could conceivably be made into one, or it culd be offered as freeware or >shareware (although I have no specific plans to do either), but it could >just as easily be converted to an "open source" project of the type >often mentioned by M. Morfin. I refer to the piratical capacity to freely develop what they want.=20 Open to all, but also open to innovation. >The point is that there is NO dichotomy between "free" (or "open" or >"non-profit") and "commercial" (or "corporate") when it comes to the >current drafts. I do not speak of "free". I actually want to talk of "open standard"=20 but I am not sure there is a consensus on the meaning? I do not really consider commercial money, but commercial dominance.=20 Of Open Culture. This is in particular described in=20 http://nicso.org/equilang.tm equal lingual opportunity. >The draft contains NO restrictions against open-source >or non-profit implementation (I would think they would be strongly >encouraged). The problem is that the nature of the market makes that Draft=20 favorable to market dominant. And the threat on open source is=20 important. This is not the place to discuss this analysis. It was=20 made by Gov officials and international analysts I trust. >There is nothing in the ABNF that prevents open-source >development based on the proposed BCP. The problem is not the ABNF, it is the pretension to exclusive.=20 Because the ABNF does not address _all_ the situations. Status quo by nature favors commercial dominants. Status quo is=20 opposed to innovation. > There are no IP constraints on >any of the technology used in its development. Can you warranty that? Unfortunately the experience does not say that.... >Any existing protocols >that make use of language tags, and stand to benefit from the proposed >update, will benefit equally regardless of whether they are commercial >or not. > >M. Morfin has argued that there are prevalent "running code" >implementations that use his expanded language-tag syntax, which is not >compatible with the syntax in the present draft. However, to date I >have not seen any pointers to such an implementation, nor any evidence >of the "prevalence" of this alternative syntax. Obviously any developer >can write code that *does not conform* to a given standard, or proposed >standard, but that says nothing about the standard itself, or about >whether the non-conformant code or the syntax it does follow is somehow >better. I have documented enough the dot-root experiment which is at the=20 basis of our effort. The daily information we publish on the network.=20 We are currently blocked by the lack of data (we wait for stability=20 of ISO 639-3 and ISO 639-6 availability). The work engaged is of=20 magnitude and is based upon underlying effort. We have a plan and try=20 to stick to it at our expense. The cost the WG-ltru and the threat=20 it represents on us is significant (hence my delegation as an=20 interface). We try to be free to stay independent in advising Govs=20 and international entities. >The arguments that RFC 3066 is widely ignored Never said that !!! I say it is loosely enforced. And that the target=20 of the Draft is to use it much more. >are specious as well; >there are numerous examples of protocols that adhere to the RFC 3066 >model. The fact that non-conformant implementations (like the culture >identifiers) exist is not a justification for throwing away the model. ???? I am _defending_it_ if you really like it !!! I just want it=20 _not_to_want_to_be_exclusive_ and to warn people about its dangers. You are throwing away the model: in wanting to oppose others, you=20 will lead a generalised approach to develop which will also deprecate you= rs. >To cite an example from another thread, we acknowledge that some mail >software implements "Reply-To" poorly, but that does not mean the whole >notion of "Reply-To" should be thrown away as irrelevant, or "not >supported by open R&D solutions." > >I apologize for the length of this particular point, but I feel it is >important. Not everyone who supports the draft does so out of >commercial greed, and even those who happen to work for Big Commercial >Behemoths might have higher motives. Some people just like the feel of >an "open software vs. closed software" struggle, =C3=A1 la Richard Stall= man >or Eric Raymond -- note M. Morfin's reference to a "chapel," evoking >images of Raymond's "The Cathedral and the Bazaar" -- but the truth is >that this image simply doesn't apply to the LTRU draft. I am sure this is the way you see me. But read what I say, do not imagine= it! I documented enough that I defend industry non-dominants! I say that=20 I defend Govs and cultures! I am for _free_ commercial and trade=20 against a de facto monopoly. We do not want a _unique_ limited=20 langtag removing the capacity to refer non-dominant industries, and=20 imposing a vision foreign to people vernacular culture/way of life=20 (context). Because it does not sell. And does not permit open=20 source. Let take an example: TCP/IP is open to all. Can you give me=20 the source of a Windows socket? Do you know what is the turn-over of the printing industry? Imposing=20 a single langtag helps the market, technology unification. A few may=20 want to become book/press industries Majors. You will understand many=20 do not want. A chapel/church is usually (and this is the way it is often used in=20 here) as a religious way to support an idea received as a faith,=20 rather as the result of an experimentation or a serious analysis. A=20 serious analysis would have started with a clean sheet reading of the Cha= rter. You may recall that I started this WG in proposing to be a co-writer=20 of the Draft. The response was something like "no, they are Addison=20 and Mark. They will publish the WG Draft tomorrow" > >> What I said, as anyone can see from reading the quote above, is that > >> a 740-page I-D might be unwieldy enough that the IETF might consider > >> a different procedural mechanism for delivering the information to > >> IANA. > > > > Correct. > > I do not see the need of all the innuendo above to repeat what I > > quoted. > >It was quoted as though it proved "some of the problems resulting from >the expected size of the language tag registry and the capacity of the >langtag solution to fulfill the WG-ltru Charter." It does nothing of >the sort. Whether IETF or IANA wants to deal with a 740-page I-D is >entirely up to them. It was quoted period. So people may just decide that! > >> Since the charter neither refers nor alludes to ISO 639-6, there is > >> no conflict with the charter if WG members disagree in regard to the > >> *eventual* expansion of the scope of language tags to involve ISO > >> 639-6. > > > > This repeated allusion to the Charter neither refering nor alluding > > to ISO 639-6 is to be compared with the text of the Charter > > (http://ietf.org/html.charters/ltru-charter.html) which says "It is > > also expected to provide mechanisms to support the evolution of the > > underlying ISO standards, in particular ISO 639-3". > >Peter Constable has already addressed the meaning of "the underlying ISO >standards." I am not interested in "underlying" but in "evolution".... >ISO 639-6 is not an underlying ISO standard for purposes of >this draft. (It's not even a standard, in fact, not even a CD yet.) >For that matter, ISO 6709 is also not an underlying ISO standard for >purposes of this draft, so the draft does not permit tags of the form >"fr+484816+0020708" either. Do you really think this detail carry any weight when you consider=20 engaging the final lingual orientation of the Internet, hence of the worl= d? > > This kind of problem may be related to the refusal of the WG to start > > from/analyse the Charter requirments? > >I understand the charter requirements just fine. Almost all of the WG >does. How do you know? Randy documented 57 participants at some stage. May=20 be twenty participated. Really less than a dozen .... > > I do not know if I share concerns with Doug. I do share the concerns > > of Doug. > >The concern quoted above was that a 740-page I-D might be unwieldy. I >acknowledge that M. Morfin might share that concern. Happily, it is a >concern for the next draft, not this one. See above. Do you buy a car without considering the cost of=20 insurance; repairs, gas, etc. ? > >> I hereby disassociate myself with any statements made by M. Morfin > >> concerning the drafts produced by the LTRU WG. I hope that is clear > >> enough for IETF members. > > > > Since I said I supported his Draft .... > >"Disassociate" does not mean "disagree." It means I do not speak so as >to bolster his point. > > >>> 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped= ) > >>> to 650 K (100 K zipped). This information, updates and additions > >>> MUST be available to each of the on-line application of the devices > >>> of billions of users. The Draft does not explain how. > >> > >> The WG decided this was an IANA implementation issue, and out of > >> scope. > > > > Correct. This is exactly what I say. > >I suppose if we want to pursue this issue of huge daily updates and >bandwidth consumption, we should start by asking how many >implementations currently perform daily updates on the existing IANA >Language Tag Registry, a resource which (of course) is necessary to >implement RFC 3066 fully. Very good idea. Do you have figures? My experience of networks is different from yours. Let add experience=20 and experimentation. I have no predefined solution. But I have questions no one wants to addre= ss.... > > Doug said in another mail "I just think the two figures (7,600 and > > 20,000) could be seen as representing a fundamental disagreement." > > This is a legitimate concern at a time a LC is to engage the whole > > IETF in a direction where you think this is unclear. I would not > > qualify that of ust "talk". This is something loyalty calls you to > > say, even if it is to explain why there is no fundamental > > disagreement. > >1. The charter does not refer to ISO 639-6, which will eventually >encode 20,000 "languages and dialects." ISO 639-6 is an officially planned "evolution" of ISO standard (refer=20 to Charter). In any case we support Linguasphere. >2. The charter does refer to ISO 639-3, which will encode 7,600 >languages, but only for future planning, for "evolution." This is totally irrelevant remark: what does it change? We talk of=20 the Internet of the world. >3. The proposed initial registry contains subtags based only on the >existing standards: ISO 639-1 and 639-2, ISO 3166-1, ISO 15924, and >United Nations M.49, as well as "variant" and "grandfathered" subtags >based on the RFC 3066 registry. Yes. Then? >4. Normative references to a not-yet-completed standard are bad, for >the same reason that normative references to an I-D are bad. I am not interested in paper work, I am interested in stability,=20 security, surety, innovation capacity, multilingualism, multimode,=20 multitechnology etc. The common interest is that we can agree on=20 solutions. If we disagree (like SID and SPF) the user will decide,=20 not the vendor. This takes more time, delays everyone, cost to=20 everyone: so it is better than users and vendors agree. > > NB. As a user, the langtag solution does not provide as much > > possibilities, simplicity, flexibility than solutions using ISO 639-6 > > (with the possible use of ISO 639-1/2/3 when necessary. This is IETF > > not ISO. > >THERE IS NO ISO 639-6. There will be, some day, but such a standard >oes NOT exist now. Good heavens, the data is not even publicly >available yet! Of course the language tag solution is not going to be >based on a vapor standard. ..... in which world do you live? > > I have documented enough (too much :-)) during these last days that I > > support (one can read my mails of end of December 2004) the Draft > > with the provision it is not exclusive and serves the Internet > > community rather than exclude its R&D and innovation capacity. > >The purpose of language tags is interoperability. This is the problem: the need of the langtag is interintelligibility. >This purpose is not served if every organization invents its own extensi= ons. The purpose is served if every community can invent what it needs.=20 More complex for the vendor. Risk of local solutions being sold.... >The sections >of the draft that deal with private-use tags and subtags are heavily >laden with caveats to explain this. There is no private-use tags. > > Happily I support my Unicode co-Member Doug's own Draft and I thanked > > him for the work he consciensiously achieved over the months > > maintaining the base he now proposes as a Draft! (even if I doubt a > > 740 pages I-D can be of real use in the future). > >I acknowledge M. Morfin's support for draft-initial, and thank him for >his restraint in this message. I am afraid that I have been often hurt - for example on my Franglish=20 which is a very interesting demonstration of the difficulty of the=20 participants to deal with multilingualism :-) - despised, joked at,=20 etc. I do not think I ever retaliated. If I did I was wrong. I prefer=20 to explain. Even if it takes and not read. No one knows. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 10:36:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kkL-0006fW-Rx; Mon, 29 Aug 2005 10:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kkK-0006fO-L1 for ltru@megatron.ietf.org; Mon, 29 Aug 2005 10:36:24 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13772 for ; Mon, 29 Aug 2005 10:36:22 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050829143552.EUOM24716.mta9.adelphia.net@DEWELL>; Mon, 29 Aug 2005 10:35:52 -0400 Message-ID: <020d01c5aca6$deaf34a0$030aa8c0@DEWELL> From: "Doug Ewell" To: , References: <6.2.3.4.2.20050829091433.058e1850@mail.jefsey.com> Date: Mon, 29 Aug 2005 07:35:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org JFC (Jefsey) Morfin wrote: > From the input of Doug Ewell its _initial_ version withISO 639-6 will > include 40.000 lines. I never said that. I would not make any statement about ISO 639-6 when the data is not available. I said that the deltas for the initial version with ISO 639-*3* would add up to 35,700 lines -- and yes, that would put the grand total at over 40,000 lines. It's hard to follow this line of argument that a registry with 7,600 languages would be too large, and simultaneously that it should instead support 20,000 languages, unles the object is to do away with the registry altogether and have everyone invent new tags on the fly. What good would such nonce tags be? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 10:40:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kob-0007Wr-JS; Mon, 29 Aug 2005 10:40:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9koa-0007Wm-3W for ltru@megatron.ietf.org; Mon, 29 Aug 2005 10:40:48 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14052 for ; Mon, 29 Aug 2005 10:40:45 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050829144016.EHXN27017.mta11.adelphia.net@DEWELL>; Mon, 29 Aug 2005 10:40:16 -0400 Message-ID: <021201c5aca7$7b1ad880$030aa8c0@DEWELL> From: "Doug Ewell" To: , References: <6.2.3.4.2.20050829100328.05911b30@mail.jefsey.com> Date: Mon, 29 Aug 2005 07:39:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org JFC (Jefsey) Morfin wrote: > BTW is CLDR an IETF protocol? I tried to get the insurrence > that there would never be IPR attached to it. Never got it. I can't speak for anything having to do with ICU, but even if it were IPR-protected, that does not mean all of the protocols and standards it uses must themselves be IPR-protected. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 10:58:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9l5r-0003MP-Jx; Mon, 29 Aug 2005 10:58:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9l5p-0003M8-S4; Mon, 29 Aug 2005 10:58:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15115; Mon, 29 Aug 2005 10:58:35 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9l7C-0002Ty-5k; Mon, 29 Aug 2005 11:00:02 -0400 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050829145827.GKGQ24716.mta9.adelphia.net@DEWELL>; Mon, 29 Aug 2005 10:58:27 -0400 Message-ID: <024201c5aca9$fe47dc60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> <6.2.3.4.2.20050829090011.04dcc7f0@mail.afrac.org> Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP) Date: Mon, 29 Aug 2005 07:57:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org r&d afrac wrote: > "RFC 3774 2.2.6: Members of this affinity group tend to talk more > freely to each other and former members of the affinity group - this > may be because the affinity group has also come to share a cultural > outlook which matches the dominant cultural ethos of the IETF (North > American, English speaking). Newcomers to the organization and > others outside the affinity group are reluctant to challenge the > apparent authority of the extended affinity group during debates and > consequently influence remains concentrated in a relatively small > group of people. Quick show of hands: How many people think M. Morfin has been hampered by a reluctance to challenge the rest of the Working Group? > This reluctance may also be exacerbated if participants come from a > different cultural background than the dominant one." Which of your objections to the draft are based on your French-speaking, French-national cultural affiliation, such that they would not be adequately understood by North Americans or English speakers? Not everything is discrimination. Consider the possibility that the objections to your proposals have a technical basis, rather than being ad-hominem. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 12:45:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9mlH-0007EA-KK; Mon, 29 Aug 2005 12:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9mlD-0007Ck-JN for ltru@megatron.ietf.org; Mon, 29 Aug 2005 12:45:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20203 for ; Mon, 29 Aug 2005 12:45:24 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E9mgg-0001af-Oo for ltru@lists.ietf.org; Mon, 29 Aug 2005 18:40:46 +0200 Received: from c-180-160-216.hh.dial.de.ignite.net ([62.180.160.216]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 18:40:46 +0200 Received: from nobody by c-180-160-216.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 18:40:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Subject: Re: [Ltru] Date: Mon, 29 Aug 2005 18:27:11 +0200 Organization: Lines: 21 Message-ID: <4313375F.6C34@xyzzy.claranet.de> References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> <6.2.3.4.2.20050829090011.04dcc7f0@mail.afrac.org> <024201c5aca9$fe47dc60$030aa8c0@DEWELL> <20050829151605.GA24985@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-216.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > I can testify that Jefsey Morfin is exactly as verbose and > unparsable when he writes in French. His postings in my main > language are (like he does in english) very long and full of > pseudo-technical babbling. Thanks for info. The techno babble was very confusing, mixing the tag URI scheme with language tags (unrelated), throwing in IDNA (unrelated), comparing language tags with DNS (unrelated), spicing this with IAB / UN / ITU / W3C / ISO / ... (pick all) periodically, it was difficult to identify some real concerns in this mess. Where it was possible, e.g. registry size, the WG discussed it. Where this was impossible, e.g. assumptions that the registry is just another root zone or hosts.txt, or even something like AV signatures, the WG "skipped" it. The WG also refrained from contacting the UN general assembly and other stunts. BTW, please watch your Cc: in cases like this, somebody (guess) will always try to add iesg@iesg. Bye _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 12:58:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9myD-0000vo-TS; Mon, 29 Aug 2005 12:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9myA-0000vT-8z for ltru@megatron.ietf.org; Mon, 29 Aug 2005 12:58:52 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20873 for ; Mon, 29 Aug 2005 12:58:46 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9muU-0005Uo-Jy for ltru@lists.ietf.org; Mon, 29 Aug 2005 18:55:04 +0200 Received: from c-180-161-85.hh.dial.de.ignite.net ([62.180.161.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 18:55:02 +0200 Received: from nobody by c-180-161-85.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 18:55:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 29 Aug 2005 18:51:47 +0200 Organization: Lines: 16 Message-ID: <43133D23.6D3@xyzzy.claranet.de> References: <6.2.3.4.2.20050829100328.05911b30@mail.jefsey.com> <021201c5aca7$7b1ad880$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-85.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] ICU / CLDR (was: Last Call: 'Tags for Identifying Languages' to BCP) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I can't speak for anything having to do with ICU, but even > if it were IPR-protected, that does not mean all of the > protocols and standards it uses must themselves be > IPR-protected. http://www-306.ibm.com/software/globalization/icu/chartsdemostools.jsp I'd guess that it's in the same way "protected" like UniCode: You can't steal it, twist it, and claim that your version is the real thing. It's from IBM (= no MS "embrace and extend"). Bye, Frank (IANAL) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 13:28:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nQv-0006hV-QN; Mon, 29 Aug 2005 13:28:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nQu-0006hQ-OA for ltru@megatron.ietf.org; Mon, 29 Aug 2005 13:28:33 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22288 for ; Mon, 29 Aug 2005 13:28:29 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9nOo-0005mX-Rv for ltru@lists.ietf.org; Mon, 29 Aug 2005 19:26:22 +0200 Received: from c-180-161-85.hh.dial.de.ignite.net ([62.180.161.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 19:26:22 +0200 Received: from nobody by c-180-161-85.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 19:26:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 29 Aug 2005 19:23:25 +0200 Organization: Lines: 33 Message-ID: <4313448D.7B8F@xyzzy.claranet.de> References: <20050829051715.OFHU9276.mta6.adelphia.net@megatron.ietf.org> <01ca01c5ac5a$bfe335e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-85.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > "For all I know, the sheer volume of... [blah blah blah] ... > is absolutely typical of other IETF Working Groups." Oh, yes, that's possible. Apparently the LTRU list was more on the busy side, other lists like SASL or NETWRK are relatively quiet. But when I substract what I consider as "Jefsey tries to collect points for his appeal" (and Randy is forced to track this with the ticket system) it's not too bad from my POV. In another article: | It's hard to follow this line of argument that a registry | with 7,600 languages would be too large, and simultaneously | that it should instead support 20,000 languages, unles the | object is to do away with the registry altogether It's exactly the same line of arguments where he attacks the registry for its size, and simultaneously proposes to add descriptions in - hard to tell - "more" languages. Some supported the latter, and they were not worried about the size. A majority decided that French descriptions are not really better than English names, and that we're not creating a dictionary. Both are honest positions. But one participant wanted both, that was IMNSHO dishonest, and just another attempt to collect points for his appeal. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 13:35:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nXb-0008KI-Oh; Mon, 29 Aug 2005 13:35:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nXY-0008JY-DM; Mon, 29 Aug 2005 13:35:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22655; Mon, 29 Aug 2005 13:35:21 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9nYv-00072k-5g; Mon, 29 Aug 2005 13:36:50 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7THZ5ug025366; Mon, 29 Aug 2005 13:35:05 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7THZ48q024582; Mon, 29 Aug 2005 13:35:05 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7THZ4lD023886; Mon, 29 Aug 2005 13:35:04 -0400 Received: from [127.0.0.1] (sig-9-48-109-53.mts.ibm.com [9.48.109.53]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7THYvVX023311; Mon, 29 Aug 2005 13:34:58 -0400 Message-ID: <4313473E.2020406@icu-project.org> Date: Mon, 29 Aug 2005 10:34:54 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP References: <6.2.3.4.2.20050829100328.05911b30@mail.jefsey.com> <021201c5aca7$7b1ad880$030aa8c0@DEWELL> In-Reply-To: <021201c5aca7$7b1ad880$030aa8c0@DEWELL> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group , ietf@ietf.org, iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org One must not confuse ICU and CLDR: - CLDR is a project of the Unicode Consortium. - ICU is an open-source project, sponsored by IBM, that *uses* CLDR data. In both cases, however, data and code is freely available, with attribution. Mark (You know this, Doug, just pointing out for others.) Doug Ewell wrote: > JFC (Jefsey) Morfin wrote: > > >>BTW is CLDR an IETF protocol? I tried to get the insurrence >>that there would never be IPR attached to it. Never got it. > > > I can't speak for anything having to do with ICU, but even if it were > IPR-protected, that does not mean all of the protocols and standards it > uses must themselves be IPR-protected. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 13:49:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nkw-0002Ut-Rr; Mon, 29 Aug 2005 13:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nkv-0002Ug-Ad for ltru@megatron.ietf.org; Mon, 29 Aug 2005 13:49:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23381 for ; Mon, 29 Aug 2005 13:49:12 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9nmJ-0007Sp-A8 for ltru@ietf.org; Mon, 29 Aug 2005 13:50:39 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9nks-0000qZ-Cn; Mon, 29 Aug 2005 10:49:11 -0700 Message-Id: <6.2.3.4.2.20050829193905.04deabc0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 19:49:02 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP In-Reply-To: <4313448D.7B8F@xyzzy.claranet.de> References: <20050829051715.OFHU9276.mta6.adelphia.net@megatron.ietf.org> <01ca01c5ac5a$bfe335e0$030aa8c0@DEWELL> <4313448D.7B8F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 19:23 29/08/2005, Frank Ellermann wrote: >Doug Ewell wrote: > > "For all I know, the sheer volume of... [blah blah blah] ... > > is absolutely typical of other IETF Working Groups." > >Oh, yes, that's possible. Apparently the LTRU list was >more on the busy side, other lists like SASL or NETWRK are >relatively quiet. But when I substract what I consider as >"Jefsey tries to collect points for his appeal" (and Randy >is forced to track this with the ticket system) it's not >too bad from my POV. Dear Frank, you should add the private mails I received which amount in my dedicated mailbox to nearly 500 (but there are duplicates, side aspects, etc. in more and in less). Some are from Members of this WG. >In another article: > >| It's hard to follow this line of argument that a registry >| with 7,600 languages would be too large, and simultaneously >| that it should instead support 20,000 languages, unles the >| object is to do away with the registry altogether Your comment is very interesting as it implies positions I have not, and is insultring, on the ground of an obvious typo I appologized for. Some could say that you could be biased :-) "Be happy when you are gratuitly insulted, either you are stupid or right". take care. jfc >It's exactly the same line of arguments where he attacks the >registry for its size, and simultaneously proposes to add >descriptions in - hard to tell - "more" languages. > >Some supported the latter, and they were not worried about >the size. A majority decided that French descriptions are >not really better than English names, and that we're not >creating a dictionary. Both are honest positions. > >But one participant wanted both, that was IMNSHO dishonest, >and just another attempt to collect points for his appeal. > > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 14:07:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9o2q-0006DL-TY; Mon, 29 Aug 2005 14:07:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9lMs-0006Kz-Fp; Mon, 29 Aug 2005 11:16:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15890; Mon, 29 Aug 2005 11:16:12 -0400 (EDT) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9lOD-00030b-TT; Mon, 29 Aug 2005 11:17:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id ADFDC26C06D; Mon, 29 Aug 2005 17:16:06 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 9B80E26C00E; Mon, 29 Aug 2005 17:16:05 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j7TFG5Ya1016274; Mon, 29 Aug 2005 17:16:05 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 7C12616AB02; Mon, 29 Aug 2005 17:16:05 +0200 (CEST) Date: Mon, 29 Aug 2005 17:16:05 +0200 From: Stephane Bortzmeyer To: Doug Ewell Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP) Message-ID: <20050829151605.GA24985@nic.fr> References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> <6.2.3.4.2.20050829090011.04dcc7f0@mail.afrac.org> <024201c5aca9$fe47dc60$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024201c5aca9$fe47dc60$030aa8c0@DEWELL> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Mon, 29 Aug 2005 14:07:43 -0400 Cc: LTRU Working Group , ietf@ietf.org, iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org On Mon, Aug 29, 2005 at 07:57:35AM -0700, Doug Ewell wrote a message of 37 lines which said: > Quick show of hands: How many people think M. Morfin has been hampered > by a reluctance to challenge the rest of the Working Group? ... > Which of your objections to the draft are based on your French-speaking, > French-national cultural affiliation, I can testify that Jefsey Morfin is exactly as verbose and unparsable when he writes in French. His postings in my main language are (like he does in english) very long and full of pseudo-technical babbling. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 14:08:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9o3D-0006JH-2w; Mon, 29 Aug 2005 14:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nWa-00084I-2B for ltru@megatron.ietf.org; Mon, 29 Aug 2005 13:34:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22606 for ; Mon, 29 Aug 2005 13:34:21 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9nXw-00071b-TG for ltru@ietf.org; Mon, 29 Aug 2005 13:35:50 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9nWW-0003cC-AZ; Mon, 29 Aug 2005 10:34:21 -0700 Message-Id: <6.2.3.4.2.20050829181131.04e681c0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 19:20:54 +0200 To: "Doug Ewell" From: Délégué Général In-Reply-To: <020d01c5aca6$deaf34a0$030aa8c0@DEWELL> References: <6.2.3.4.2.20050829091433.058e1850@mail.jefsey.com> <020d01c5aca6$deaf34a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Mon, 29 Aug 2005 14:08:06 -0400 Cc: LTRU Working Group Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Sorry, typo of mine. I meant ISO 639-3. You are correct. At 16:35 29/08/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > > From the input of Doug Ewell its _initial_ version withISO 639-6 will > > include 40.000 lines. > >I never said that. I would not make any statement about ISO 639-6 when >the data is not available. > >I said that the deltas for the initial version with ISO 639-*3* would >add up to 35,700 lines -- and yes, that would put the grand total at >over 40,000 lines. > >It's hard to follow this line of argument that a registry with 7,600 >languages would be too large, and simultaneously that it should instead >support 20,000 languages, unles the object is to do away with the >registry altogether and have everyone invent new tags on the fly. What >good would such nonce tags be? I say that a large reistry implies problem which have not been addressed. I have other solutions based upon another architecture. I have none with yours. This is why I ask. Cheers. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 14:08:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9o3Q-0006LG-96; Mon, 29 Aug 2005 14:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Ndh-0006S3-TB; Sun, 28 Aug 2005 09:56:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19290; Sun, 28 Aug 2005 09:56:00 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Neq-0004Mo-SO; Sun, 28 Aug 2005 09:57:13 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9NdX-0006VZ-Br; Sun, 28 Aug 2005 06:55:51 -0700 Message-Id: <6.2.3.4.2.20050828111916.03a41040@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 28 Aug 2005 15:55:46 +0200 To: ietf@ietf.org, iesg@iesg.org From: "JFC (Jefsey) Morfin" In-Reply-To: <6.2.3.4.2.20050828033256.03a3feb0@mail.jefsey.com> References: <6.2.3.4.2.20050827113513.04327160@pop.online.fr> <431090C2.20804@blueyonder.co.uk> <6.2.3.4.2.20050827201217.0598d250@mail.jefsey.com> <4310E7E8.4070408@blueyonder.co.uk> <6.2.3.4.2.20050828033256.03a3feb0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 3.2 (+++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-Mailman-Approved-At: Mon, 29 Aug 2005 14:08:19 -0400 Cc: ltru@ietf.org Subject: [Ltru] Re: Last Call: language root file size X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Last Call: http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt I started documenting some of the problems resulting from the expected size of the language tag registry and the capacity of the langtag solution to fulfill the WG-ltru Charter. Here are two inputs from the author of the Draft above on the WG-ltru list, Doug Ewell: - "I've already built a hypothetical RFC 3066ter registry. The changes alone add up to 35,700 lines, or more than 740 pages in RFC format. It might reopen the question of whether an I-D is the best vehicle for delivering this amount of information to IANA." - "I still have significant concerns about the assumption that ISO 639-6 will be, or should be, automatically integrated into a language tagging scheme. [snip] Meanwhile, the claim that there are "over 20,000 languages" to be tagged is being used as an argument against the current RFC 3066bis effort and the plan to support 7,600 languages in RFC 3066ter." I fully share the concerns of Doug Ewell. There is only a difference of timing. I rose questions they took as oppositions and he now discovers as problems. Would the WG-ltru have first analysed its charter we would have identified them a long ago. I list some in annex. The Charter says: "The RFC 3066 standard for language tags has been widely adopted in various protocols and text formats, including HTML, XML, and CLDR, [... the first document] is also expected to provide mechanisms to support the evolution of the underlying ISO standards, in particular ISO 639-3, mechanisms to support variant registration and formal extensions, as well as allowing generative private use when necessary." 1. BTW the Charter speaks of "adopted _standard_" not of "generalised _practice_". 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped) to 650 K (100 K zipped). This information, updates and additions MUST be available to each of the on-line application of the devices of billions of users. The Draft does not explain how. 2. One of the author has _legitimate_ concerns about the capacity of the proposition and the reasonability of the Charter expectation to support the ISO 639-6 evolution of the underlying ISO standards. But he is wrong is in assuming that I use this as an argument against the current RFC 3066bis effort. To the contrary, I use it for a an argument to support the proposed Draft as default solution and support extensions and practical information distribution through other adapted solutions introduced by a singleton. The comment given by Debbie Garside, the author of ISO 639-6 shows there is no concern for our plans and developments using ISO 639-6 [except two months delay on our projected calendar], in line with ISO 11179 (what the WG-ltru and the author if ISO 639-3, Peter Constable, chose to disregard). No problem in specifying this extension capacity through a specialised Draft. If this Draft is a complement, not a competition. But I would prefer to work on a sample ISO 639-6 code and get inputs from the WGIG multilingual forum under discussion. The three approaches (not even alluded by the Charter) address three different layers: - practical, script oriented needs (ISO 639-1, 2, 3, ISO 15924) - comprehensive multimedia, multimodal, multitechnologies and extension to information systems (ISO 639-6) - lingual community networks (privateuse systems) Years of work ahead, I would prefer being made within the IETF rather than against it. jfc Annex: a quick list of questions that need to be addressed. - the nature and the size of the involved information - the size and the frequency of its additions which is not documented. However we know that the I-D bases are just the support for additions. - the availability of this information,addition and updates to the users - the redundancies of this information between three different visions of the language tagging supported by - ISO 639-3: a bare list of 7450 languages calling for variant information - ISO 639-6 : a list of 20.000 pre-formed language tag meant to deliver language information to ISO 11179 systems - the real user systems planned to be supported by the Draft "privateuse" solution. and their correlations (bridges, equivalence, conflict resolution, etc.) - the additional related information such as "locale" files (quoted in the Charter as CLDR, the Unicode project to publish all the locales of all the OS directed by one of the authors of the Draft). This related information is actually without limit as it may relates with every other information system (ISO 11179). However efforts like ISO 11179 have not yet addressed two major points: - networking what represents a huge area of research and applications (interoperation of an ISO complete system per... user avatar) - multilingualism, this means that everything supported in ASCII English must be able to be supported in every language - the change in nature of languages, texts, scripts by multilingual, multitechnology, multilateral computer supported relations - the multimodal (script, oral, sign, etc.) nature of the internet exchanges - the architectural evolution to support the "brain to brain" interintelligibility (languages) and the community interculturation (vernacularisation) layers. - the privacy violation and the intelligence leaks security issues this rises. - the purpose and architecture of the applications and services using language identifications - the relations to cultures and content, UNESCO, GAC - the identification, information and adhesion of lingual and culture experts and publics - the correlation with MPEG, MINC, ITU and other SDOs - the governance and the distribution of the language information system _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 14:08:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9o3Q-0006Le-E8; Mon, 29 Aug 2005 14:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Xb7-0003jp-3U; Sun, 28 Aug 2005 20:34:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19648; Sun, 28 Aug 2005 20:33:59 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9XcL-0003M6-QQ; Sun, 28 Aug 2005 20:35:18 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9Xao-0003G7-Ej; Sun, 28 Aug 2005 17:33:42 -0700 Message-Id: <6.2.3.4.2.20050828234319.0597ed50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 02:22:49 +0200 To: "Peter Constable" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-Mailman-Approved-At: Mon, 29 Aug 2005 14:08:19 -0400 Cc: iesg@iesg.org, ietf@ietf.org Subject: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages'toBCP) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org An exchange on WG-ltru documents (I do not say "support": the reader will judge) the positions I support. It involves: - Peter Constable: one of the initiator of the project and author of ISO 639-3 which lists 7500 languages and is used in building langtags - Doug Ewel: author of the Draft concerning the initial content of the registry - Debbie Garside: the author of ISO 639-6 At 22:20 28/08/2005, Peter Constable wrote: >[I'll preface this reply by saying that we don't want to spend too much >time discussing issues that are not of immediate concern while we've got >the matching draft and IETF last call on the registry drafts to deal >with. So, I won't pursue this thread much longer.] The proposed Draft is based upon ISO 639-1,2,3 lists of language names. ISO 639-6 is a list of language use names and IDs. The proposed langtag is an arbitrary limited compound of three information: language name, script and country. A language identification MAY call for far more elements, and deliver much more information. However these three basic elements are necessary to sell lingually related products (contract, ads, documentation, bills) and identify the current status of the art "locales" (CLDR project). The alternative seems to be: - GO for an e-commercial only multilingual internet, for ever. - NO we do not want the Multilingual Internet to be only commercial. The decision is NOW. And we understand Peter and the authors wants to win now, because they have real needs to address now. But I do not think there is a need for anyone to "win". There is a third response. - GO for an e-commercial multilingual internet support now, as default/immediate solution - YES to a generalised Multilingual Internet hooked to the RFC 3066 Draft how poor it is, using its reserved ABNF hooks. This means that: - "fr-Latn-fr" is the default tag based upon ISO 639-1/2/3 - "x-fran" is a private use tag based upon ISO 639-6 - "0-jefsey.com:franver" is my vision of the French at the Palace of Versailles. Documented by an ISO 11179 conformant system (see below) > > From:Doug Ewell > > I'm a bit surprised that a work characterized as a work-in-progress > > and not yet ready for public review is nevertheless deemed ready > > to be considered as a draft international standard. > >Debbie at no point said that it was -- and it is not. It will be >December at the earliest that it can be registered as a CD, and it must >successfully complete a three-month ballot as CD before it can be >registered as a Draft International Standard. So last spring of 2006 at >the earliest. This means that this debate is only to lock a _final_ ABNF via an accepted RFC and a loaded operationalIANA registry _before_ a simpler solution is available three months from now.... > > > In other words, in the system as proposed, you could > > > use either the alpha-4 representation or the unique DI to find the > > > closest 639-1,-2,-3 or -5 tags should you so wish. > > > > But in language tags, either one value needs to be canonical -- sorry, > > "preferred" -- over the others, or else the duplicative values should > > not be added at all. > >Your statement doesn't contradict anything that Debbie has said, >provided the context is ISO 639-6 alone. If we were to talk about >incorporation of ISO 639-6 into a revision of RFC 3066, however, then >duplication would become an issue for consideration. This is the WG-ltru Charter that all the ISO codes be included. As a user I am not much interested in mixing four formats only to please Peter Constable and/or Debbie Garside. All the more than the issue is the addition of the script information to document ... oral expression and they miss computer(ised?) languages (definition?) and all this is through computers. >For clarification of Debbie's statement, in the model of ISO 11179, we >have metadata elements that consist of a data element concept, such as >'English', and a representation for that, such as "en" or "eng" (these >would be distinct representations belonging to different value domains). >Within an metadata registry, a registry item corresponding to 'English' >can have a Data Identifier (DI), which is a unique identifier *within >the registry* for that administered item; in this example, that DI could >be any number of strings, though "English" would be among the better >choices. 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. Roughly it means that ISO 639-3 is a table of codes (names) related to non documented languages. While ISO 639-6 wants to be a root to a base of objects describing languages. The Draft proposes a very limited version of that base with three columns only. This is enough in many cases. But not in an increasing number of cases. Hence the possibility to use the Draft as a default. Since the three elements of the Draft's langtag are also in the language object base. CLDR (Unicode locale project) is a langtag related base. But ISO 11179 totally open the concept, like C structures: data they may indefinitely expand as metadata. Each data has the possibility to become a metadata describing a new dataset. For example "fr-latn-FR" can use the three codes as data. This is the case of the Draft. Or it can use the ISO 639-1 "fr" data, as the meta data describing all the French dialects and many new names to be listed (which are in ISO 639-6). "Latn" element of ISO 15924 for Latin script can become a meta data introducing French charset within a (to be defined) Latn concept, and also include elements such as founts, thickness, color, etc. etc. This is the approach I support: this is simple enough in extending the DI concept in a network, but this has be to discussed within ISO/TC 32 (or in a dedicated WG on reference centers?) > > Will Linguasphere provide the mapping between the new alpha-4 codes > > and ISO 639-1/2/3, or is that something a group like this would have to >do? >They will be (and must) providing that. This insures full compatibility between all the visions using ISO 639-X codes (documented by the ISO 639-4 guidelines under work). > > I agree that the broad question of "what is a language" is out of our > > scope. The more specific question "what is a taggable language > > distinction" is perhaps more germane. > >Not an unreasonable suggestion. This is a major step ahead for common understanding! My request, plea, begging, for a definition of what we intend to mean as a "language" in the Draft contest, might after all be listen to. I would then advise that the Draft is sent back to the WG-ltru, with the suggestion that a lexicon is provided which would define what is a "language", a "script", a "country", and the purpose (informative, descriptive, normative?) of a langtag. This might be a big step ahead. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 14:08:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9o3Q-0006M2-JC; Mon, 29 Aug 2005 14:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Ypu-0007cI-BG; Sun, 28 Aug 2005 21:53:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23207; Sun, 28 Aug 2005 21:53:20 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Yr9-0005Xv-Jh; Sun, 28 Aug 2005 21:54:40 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9Yps-0001LE-8v; Sun, 28 Aug 2005 18:53:20 -0700 Message-Id: <6.2.3.4.2.20050829022911.0595eeb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 03:53:12 +0200 To: , From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Last Call: language root file size In-Reply-To: <009101c5ac2d$6ce6d4a0$030aa8c0@DEWELL> References: <6.2.3.4.2.20050827113513.04327160@pop.online.fr> <431090C2.20804@blueyonder.co.uk> <6.2.3.4.2.20050827201217.0598d250@mail.jefsey.com> <4310E7E8.4070408@blueyonder.co.uk> <6.2.3.4.2.20050828033256.03a3feb0@mail.jefsey.com> <6.2.3.4.2.20050828111916.03a41040@mail.jefsey.com> <009101c5ac2d$6ce6d4a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 3.2 (+++) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-Mailman-Approved-At: Mon, 29 Aug 2005 14:08:19 -0400 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I am sorry to impose that kind of response - and a large number of mails. But this shows the problem to protect an open R&D capacity against a chapel, which as some good points. And a non-profit R&D against people sharing in a commercial competing consortium. At 02:05 29/08/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > I started documenting some of the problems resulting from the > > expected size of the language tag registry and the capacity of the > > langtag solution to fulfill the WG-ltru Charter. Here are two inputs > > from the author of the Draft above on the WG-ltru list, Doug Ewell: > > > > - "I've already built a hypothetical RFC 3066ter registry. The > > changes alone add up to 35,700 lines, or more than 740 pages in RFC > > format. It might reopen the question of whether an I-D is the best > > vehicle for delivering this amount of information to IANA." > >Some of you who have not had the joy of witnessing this sort of gross >misrepresentation on LTRU over the past eight months might be a bit >confused. > >At no time did I ever say, or imply, or MEAN, that the eventual size of >the registry would be a problem in and of itself, nor that the solution >developed by the LTRU WG would not fulfill the charter. > >What I said, as anyone can see from reading the quote above, is that a >740-page I-D might be unwieldy enough that the IETF might consider a >different procedural mechanism for delivering the information to IANA. Correct. I do not see the need of all the innuendo above to repeat what I quoted. > > - "I still have significant concerns about the assumption that ISO > > 639-6 will be, or should be, automatically integrated into a language > > tagging scheme. [snip] Meanwhile, the claim that there are "over > > 20,000 languages" to be tagged is being used as an argument against > > the current RFC 3066bis effort and the plan to support 7,600 languages > > in RFC 3066ter." > >Since the charter neither refers nor alludes to ISO 639-6, there is no >conflict with the charter if WG members disagree in regard to the >*eventual* expansion of the scope of language tags to involve ISO 639-6. This repeated allusion to the Charter neither refering nor alluding to ISO 639-6 is to be compared with the text of the Charter (http://ietf.org/html.charters/ltru-charter.html) which says "It is also expected to provide mechanisms to support the evolution of the underlying ISO standards, in particular ISO 639-3". This kind of problem may be related to the refusal of the WG to start from/analyse the Charter requirments? >The argument against the RFC 3066bis effort on the basis of the asserted >existence of "20,000 languages" is attributable to M. Morfin alone. He >is not being truthful in saying that he does not oppose the draft; he >has spent the entire lifetime of the LTRU WG, and before, shouting his >opposition from the rooftops. > > > I fully share the concerns of Doug Ewell. > >M. Morfin does not share any concerns with me, except to the extent he >can twist my words to mean something I do not intend. I do not know if I share concerns with Doug. I do share the concerns of Doug. >I hereby disassociate myself with any statements made by M. Morfin >concerning the drafts produced by the LTRU WG. I hope that is clear >enough for IETF members. Since I said I supported his Draft .... > > 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped) > > to 650 K (100 K zipped). This information, updates and additions MUST > > be available to each of the on-line application of the devices of > > billions of users. The Draft does not explain how. > >The WG decided this was an IANA implementation issue, and out of scope. Correct. This is exactly what I say. >Clearly, if some consider it wrong to specify both a registry format and >a registration procedure within the same draft, it would be that much >worse to dictate to IANA how it should manage its resources. This is an interesting idea: because I disagree that a general registration procedure is documented in the same document as a specific format (but I propose to address the point in considering it as the default format) ... I would support the idea to pass to others what one does not know to address. I note that this has been done with much success in the IDNA case. > > 2. One of the author has _legitimate_ concerns about the capacity of > > the proposition and the reasonability of the Charter expectation to > > support the ISO 639-6 evolution of the underlying ISO standards. > >Any talk within the LTRU WG regarding ISO 639-6 is just that: talk. Doug said in another mail "I just think the two figures (7,600 and 20,000) could be seen as representing a fundamental disagreement." This is a legitimate concern at a time a LC is to engage the whole IETF in a direction where you think this is unclear. I would not qualify that of ust "talk". This is something loyalty calls you to say, even if it is to explain why there is no fundamental disagreement. >There is no charter requirement to support ISO 639-6. (There *is* a >charter requirement to begin paving the way for support of ISO 639-3, >and we have addressed that requirement within the limitation that ISO >639-3 is still not an approved standard.) See remark above on the Charter. NB. As a user, the langtag solution does not provide as much possibilities, simplicity, flexibility than solutions using ISO 639-6 (with the possible use of ISO 639-1/2/3 when necessary. This is IETF not ISO. > > But he is wrong is in assuming that I use this as an argument against > > the current RFC 3066bis effort. To the contrary, I use it for a an > > argument to support the proposed Draft as default solution and > > support extensions and practical information distribution through > > other adapted solutions introduced by a singleton. > >I invite any interested IETF member to peruse the WG archives, and judge >for himself whether M. Morfin supports the draft or not. I have documented enough (too much :-)) during these last days that I support (one can read my mails of end of December 2004) the Draft with the provision it is not exclusive and serves the Internet community rather than exclude its R&D and innovation capacity. I make no mistery that I proposed or opposed some points, knowing that some persons, in particular the authors of the Drafts, would oppose them. This permitted to have a very clear/protected ABNF we can now use as a default, without risk of pollution from other specific sub-formats. >Since there are no detectable RFC 3683 or 3934 constraints on M. >Morfin's right to post anything he likes, I expect the usual scathing >personal attack in response. (Don't bother sending it to me personally; >I do have a Blocked Senders list.) Happily I support my Unicode co-Member Doug's own Draft and I thanked him for the work he consciensiously achieved over the months maintaining the base he now proposes as a Draft! (even if I doubt a 740 pages I-D can be of real use in the future). jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 14:08:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9o3Q-0006MQ-Nw; Mon, 29 Aug 2005 14:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nWZ-000844-OH for ltru@megatron.ietf.org; Mon, 29 Aug 2005 13:34:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22603 for ; Mon, 29 Aug 2005 13:34:20 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9nXv-00071W-Jw for ltru@ietf.org; Mon, 29 Aug 2005 13:35:49 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9nWW-0003cB-BT; Mon, 29 Aug 2005 10:34:20 -0700 Message-Id: <6.2.3.4.2.20050829181550.04da67a0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 18:19:39 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP) In-Reply-To: <024201c5aca9$fe47dc60$030aa8c0@DEWELL> References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> <6.2.3.4.2.20050829090011.04dcc7f0@mail.afrac.org> <024201c5aca9$fe47dc60$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Mon, 29 Aug 2005 14:08:19 -0400 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 16:57 29/08/2005, Doug Ewell wrote: >r&d afrac wrote: > > > "RFC 3774 2.2.6: Members of this affinity group tend to talk more > > freely to each other and former members of the affinity group - this > > may be because the affinity group has also come to share a cultural > > outlook which matches the dominant cultural ethos of the IETF (North > > American, English speaking). Newcomers to the organization and > > others outside the affinity group are reluctant to challenge the > > apparent authority of the extended affinity group during debates and > > consequently influence remains concentrated in a relatively small > > group of people. > >Quick show of hands: How many people think M. Morfin has been hampered >by a reluctance to challenge the rest of the Working Group? Read to line below in the mail. > > This reluctance may also be exacerbated if participants come from a > > different cultural background than the dominant one." > >Which of your objections to the draft are based on your French-speaking, >French-national cultural affiliation, such that they would not be >adequately understood by North Americans or English speakers? This is the other way around. The specifics of a koine (a lingua franca, common language) make it different from other languages. >Not everything is discrimination. Consider the possibility that the >objections to your proposals have a technical basis, rather than being >ad-hominem. The ad-hominems certainly have a technical basis. The problem is to resolve them technically. Not to keep it at ad-hominem level Cheers. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 14:08:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9o3Q-0006Mo-Ta; Mon, 29 Aug 2005 14:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nWd-000880-Hj for ltru@megatron.ietf.org; Mon, 29 Aug 2005 13:34:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22613 for ; Mon, 29 Aug 2005 13:34:24 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9nY0-00071j-Fo for ltru@ietf.org; Mon, 29 Aug 2005 13:35:53 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9nWX-0003cB-Ph; Mon, 29 Aug 2005 10:34:24 -0700 Message-Id: <6.2.3.4.2.20050829181947.04daa110@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 18:25:08 +0200 To: Stephane Bortzmeyer , Doug Ewell From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP) In-Reply-To: <20050829151605.GA24985@nic.fr> References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> <6.2.3.4.2.20050829090011.04dcc7f0@mail.afrac.org> <024201c5aca9$fe47dc60$030aa8c0@DEWELL> <20050829151605.GA24985@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Mon, 29 Aug 2005 14:08:19 -0400 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 17:16 29/08/2005, Stephane Bortzmeyer wrote: >On Mon, Aug 29, 2005 at 07:57:35AM -0700, > > Which of your objections to the draft are based on your French-speaking, > > French-national cultural affiliation, > >I can testify that Jefsey Morfin is exactly as verbose and unparsable >when he writes in French. His postings in my main language are (like >he does in english) very long and full of pseudo-technical babbling. Hi! Stephane, a long time I did not hear from you. I appreciate your French/english subtelty. This being said, is that not a perfect long on-going political ad-hominem :-) Your help is, as usual, welcome. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 15:51:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pfD-0006V9-QQ; Mon, 29 Aug 2005 15:51:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pfD-0006Un-57 for ltru@megatron.ietf.org; Mon, 29 Aug 2005 15:51:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03144 for ; Mon, 29 Aug 2005 15:51:25 -0400 (EDT) Received: from rly-ip08.mx.aol.com ([64.12.138.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9pgX-0003DR-2X for ltru@ietf.org; Mon, 29 Aug 2005 15:52:54 -0400 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip08.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7TJovv5013174; Mon, 29 Aug 2005 15:51:01 -0400 Received: from DEBHOME (ACD6CA61.ipt.aol.com [172.214.202.97]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7TJocel006641; Mon, 29 Aug 2005 15:50:38 -0400 Message-Id: <200508291950.j7TJocel006641@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'LTRU Working Group'" Subject: FW: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages'toBCP) Date: Mon, 29 Aug 2005 20:53:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWovuSlBxl+lHmbReyHdm+vH9tlLAAAxOggAG30pfAAXidJYAAG7DFQAAUktCAALBzxEA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Peter wrote: > I'd be inclined to agree. But it raises the issue of needing to > determine which of its 20K+ initial entries and which future additions > should not be used by the RFC. Once the course of action is determined by the LTRU (e.g. to accept everything under the level of language), it would be a simple task to extract the alpha-4s to be used (using the level code) > But the syntax as it stands now would certainly allow it. Thus, the > issue is raised whether we would need to revise the syntax to prohibit > such combinations. I don't think so... the correct alpha-4 representation would be abce. So long as users access the up to date data table they could only come up with abcd-1996 or abce-2010. Debbie > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Peter Constable > Sent: 28 August 2005 21:33 > To: ltru@ietf.org > Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying > Languages'toBCP) > > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > > > Please correct me if I am wrong, but I thought the whole idea of the > > primary > > language sub tag is that you use the shortest available ISO 639 code. > > Use the shortest equivalent, yes. > > > > My > > perception of its possible use within this particular RFC is that if > there > > is a requirement for a level of granularity lower than language use > ISO > > 639-6; you can design the RFC to stop at any level within the > hierarchy. > > If I understand what you mean, that would amount to requiring that a > lone alpha-4 be used in preference to a sequence like en-US or az-Cyrl > or de-1996 etc. It would be possible to design the RFC this way, but it > is far from clear that that is what we should do. > > > > However, that surely does not stop you from using any of the other > > qualifying tags in the ABNF e.g. ISO 3166 or 15924 if you need them. > > But that raises questions like determining when they are needed, when > they would be redundant, and whether there are implications of using > them redundantly, or in a contradictory manner, as in my hypothetical > examples abcd-KZ, abcd-TJ, etc. > > > > I > > would not envisage this RFC using an alpha-4 representation for > > Indo-European. > > I'd be inclined to agree. But it raises the issue of needing to > determine which of its 20K+ initial entries and which future additions > should not be used by the RFC. > > > > With regard to your examples, I can't really see a problem other than > you > > would never get the following scenario as in your presentation: > > > > > abcd-2010 > > > abcd-1996 > > But the syntax as it stands now would certainly allow it. Thus, the > issue is raised whether we would need to revise the syntax to prohibit > such combinations. > > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 15:51:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pfK-0006cy-FI; Mon, 29 Aug 2005 15:51:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pfI-0006Zz-8x for ltru@megatron.ietf.org; Mon, 29 Aug 2005 15:51:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03151 for ; Mon, 29 Aug 2005 15:51:30 -0400 (EDT) Received: from rly-ip08.mx.aol.com ([64.12.138.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9pgd-0003Dx-D6 for ltru@ietf.org; Mon, 29 Aug 2005 15:52:59 -0400 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip08.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7TJovux013174 for ; Mon, 29 Aug 2005 15:50:59 -0400 Received: from DEBHOME (ACD6CA61.ipt.aol.com [172.214.202.97]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7TJocem006641 for ; Mon, 29 Aug 2005 15:50:43 -0400 Message-Id: <200508291950.j7TJocem006641@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'LTRU Working Group'" Subject: FW: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Mon, 29 Aug 2005 20:53:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWr/2gDOOZihBiiRten0AYccNPITQACWb2QADKJS2A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I'm a bit surprised that a work characterized as a work-in-progress and > not yet ready for public review is nevertheless deemed ready to be > considered as a draft international standard. ISO 639-6 is based on the Linguasphere Register by Dr David Dalby published 1999/2000; it is currently being revised in conjunction with the standard. There are a number of copies still available if you would like to order one! ;-) > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 28 August 2005 19:36 > To: LTRU Working Group > Cc: Debbie Garside > Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying > Languages' toBCP) > > Debbie Garside wrote: > > > I don't think anyone should make assumptions where technology is > > concerned! What I can say is that the database for the 639-6 standard > > will be made freely available online, in the same way as the > > Ethnologue, as soon as it is ready. However, this is a WIP and there > > really is no point putting up half information that has not yet been > > verified. I am currently putting together the verification > > methodology which will be implemented by various collaboration > > partners internationally. I cannot at this moment say when the > > database will be ready but rest assured you will be notified. > We're not talking about a > completely new invention, but a method of classifying languages, which > is a human endeavor dating back many centuries if not millenia. > > But I'm certainly glad that my assumption that the information might not > be made freely available was incorrect. Clearly, there can't be > anything proprietary or IP-restricted about the data available for > language tags (but of course Linguasphere can always provide proprietary > value-added data, such as the language hierarchy). > > > As it stands at the moment, 639-6 will provide each linguistic entity > > with one language reference name. This reference name is intended for > > use as the unique data identifier (DI as per 11179). Unique Data > > Identifiers and alpha-4 Representations for each linguistic entity > > written, spoken and signed down to the level of dialect and component > > variety, where appropriate, will be provided. Because 639-6 is a > > hierarchical system (the parent alpha-4 representation is provided), > > it lends itself very well to the "mapping" of the other codes of the > > 639 family; something that should prove invaluable for backward > > compatibility. In other words, in the system as proposed, you could > > use either the alpha-4 representation or the unique DI to find the > > closest 639-1,-2,-3 or -5 tags should you so wish. > > But in language tags, either one value needs to be canonical -- sorry, > "preferred" -- over the others, or else the duplicative values should be > not be added at all. Otherwise there is a significant burden on those > who would perform matching. > > I would suggest that for compatibility, subtags directly mappable to ISO > 639-1/2/3 should not be added. This is similar to the situation with > ISO 639-2 in RFC 3066, where values like "eng" were not made available > for language tags because of the pre-existence of "en". > > Will Linguasphere provide the mapping between the new alpha-4 codes and > ISO 639-1/2/3, or is that something a group like this would have to do? > > >> Meanwhile, the claim that there are "over 20,000 languages" to be > >> tagged is being used as an argument against the current RFC 3066bis > >> effort and the plan to support 7,600 languages in RFC 3066ter. > > > > Hmmmm... at this point there could be very lengthy off topic > > discussions as to what is a language and I don't think that is a good > > idea. I would not say that there are 20,000 languages but rather > > nearer to 7,600 as stated in 639-3; just my humble opinion. JFTR, I > > support the inclusion of 639-3 in RFC3066ter. > > I agree that the broad question of "what is a language" is out of our > scope. The more specific question "what is a taggable language > distinction" is perhaps more germane. I just think the two figures > (7,600 and 20,000) could be seen as representing a fundamental > disagreement. I'd like to cite a specfic example of a distinction that > is made in 639-6 but not 639-3, but I can't because the data's not yet > available. > > I did not mean to imply that it was you (or Lee) who opposed either the > current draft or the proposed use of ISO 639-3 in future drafts. > > >> I'm not saying anything against the Linguasphere effort per se, but > >> with the limited knowledge available to me, I don't think its > >> eventual role in language tagging should be considered a fait > >> accompli. > > > > That is your prerogative but IMHO very much a sensible approach (see > > first line comment). > > > > ISO 639-6 is being created as an International Standard. There is a > > long way to go (earliest completion 2007) until it reaches full IS and > > no doubt there will be twists and turns on the ISO journey :-) > > > > As previously mentioned by Peter, there will be a draft CD for comment > > available by the end of November. At that time I will happily make it > > available to this expert group for comment. > > I will gladly wait until then before trying to make specific comments on > 639-6. Until then, I stand by my prerogative (in the U.S. we might say > that it's not a slam dunk). > > > Have a nice day! > > +1 > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 15:52:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pgN-0006p2-Kn; Mon, 29 Aug 2005 15:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pgM-0006ox-Nv for ltru@megatron.ietf.org; Mon, 29 Aug 2005 15:52:39 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03189 for ; Mon, 29 Aug 2005 15:52:36 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9peD-0007de-RC for ltru@lists.ietf.org; Mon, 29 Aug 2005 21:50:25 +0200 Received: from c-180-161-85.hh.dial.de.ignite.net ([62.180.161.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 21:50:25 +0200 Received: from nobody by c-180-161-85.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 21:50:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 29 Aug 2005 21:46:03 +0200 Organization: Lines: 32 Message-ID: <431365FB.1603@xyzzy.claranet.de> References: <20050829051715.OFHU9276.mta6.adelphia.net@megatron.ietf.org> <01ca01c5ac5a$bfe335e0$030aa8c0@DEWELL> <4313448D.7B8F@xyzzy.claranet.de> <6.2.3.4.2.20050829193905.04deabc0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-85.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org r&d afrac wrote: > you should add the private mails I received which amount in > my dedicated mailbox to nearly 500 Now I certainly have no idea what happens in your inbox. You sent some (about 6 ?) private mails to me, and I responded how often, twice ? Nothing special / unusual, I also had some off topic conversations with John, and Debbie (but that wasn't off topic and later also made it to the list). >> In another article: > >| It's hard to follow this line of argument [...] > Your comment is very interesting I quoted it because it is interesting, but actually it was Doug's comment (in a parallel article), and I marked it with a vertical bar (indicating quotes from sources outside of the actual thread, i.e. "> text" isn't the same as "| text") > Some could say that you could be biased :-) Yes, they're free to say what they like. OTOH I can prove that you attacked the draft from opposite directions, you were concerned about the registry size _and_ you wanted to make it even bigger by adding more descriptions. IIRC all others picked at most one of these positions. Bye _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 16:14:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pzr-0002T4-1C; Mon, 29 Aug 2005 16:12:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pzp-0002Sw-CK for ltru@megatron.ietf.org; Mon, 29 Aug 2005 16:12:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03887 for ; Mon, 29 Aug 2005 16:12:43 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-ash.bigfish.com ([206.16.192.253] helo=mail74-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9q1A-0003sT-Jm for ltru@ietf.org; Mon, 29 Aug 2005 16:14:12 -0400 Received: from mail74-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail74-ash-R.bigfish.com (Postfix) with ESMTP id 729B03E9E42; Mon, 29 Aug 2005 20:12:22 +0000 (UTC) X-BigFish: VP Received: by mail74-ash (MessageSwitch) id 1125346342395614_4725; Mon, 29 Aug 2005 20:12:22 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail74-ash.bigfish.com (Postfix) with ESMTP id 4E2C13DEB82; Mon, 29 Aug 2005 20:12:22 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005082913205200:30903 ; Mon, 29 Aug 2005 13:20:52 -0700 To: "JFC (Jefsey) Morfin" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Mon, 29 Aug 2005 13:09:15 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4FP1|June 19, 2005) at 08/29/2005 13:09:16, Serialize complete at 08/29/2005 13:09:16, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 08/29/2005 01:20:52 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 08/29/2005 01:20:52 PM, Serialize complete at 08/29/2005 01:20:52 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: LTRU Working Group Subject: [Ltru] Communication protocols X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1269736440==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1269736440== Content-Type: multipart/alternative; boundary="=_alternative 006EFE198825706C_=" This is a multipart message in MIME format. --=_alternative 006EFE198825706C_= Content-Type: text/plain; charset="us-ascii" Jefsey, As I am reading through my in-box on this subject, I see you have used no less than three different e-mail addresses and identities on the LTRU list today. It would be of great assistance to all if you could decide on a single personality to use to represent yourself within this group -- if that is an acceptable cultural imposition. Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 --=_alternative 006EFE198825706C_= Content-Type: text/html; charset="us-ascii"
Jefsey,

As I am reading through my in-box on this subject, I see you have used no less than three different e-mail addresses and identities on the LTRU list today. It would be of great assistance to all if you could decide on a single personality to use to represent yourself within this group -- if that is an acceptable cultural imposition.

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384

--=_alternative 006EFE198825706C_=-- --===============1269736440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1269736440==-- From ltru-bounces@ietf.org Mon Aug 29 17:54:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ra2-0006LW-CL; Mon, 29 Aug 2005 17:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9rZv-0006LK-S4 for ltru@megatron.ietf.org; Mon, 29 Aug 2005 17:54:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09239 for ; Mon, 29 Aug 2005 17:54:05 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9rbL-0006ss-TJ for ltru@ietf.org; Mon, 29 Aug 2005 17:55:36 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9rZq-0001TD-1e; Mon, 29 Aug 2005 14:54:02 -0700 Message-Id: <6.2.3.4.2.20050829232615.053d5eb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 29 Aug 2005 23:53:54 +0200 To: Karen_Broome@spe.sony.com From: r&d afrac In-Reply-To: References: Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: LTRU Working Group Subject: [Ltru] Re: Communication protocols X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0001833957==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0001833957== Content-Type: multipart/alternative; boundary="=====================_2624083==.ALT" --=====================_2624083==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 22:09 29/08/2005, Karen_Broome@spe.sony.com wrote: >Jefsey, >As I am reading through my in-box on this subject, I see you have >used no less than three different e-mail addresses and identities on >the LTRU list today. It would be of great assistance to all if you >could decide on a single personality to use to represent yourself >within this group -- if that is an acceptable cultural imposition. Dear Karen, I apologise for the inconvenience (I suppose you classify the incoming mails per authors?). The reason why of two is that my IETF mailname is jefsey@jefsey.com (my regular mail) and that when I was banned from this list this rose the interest of my working group, and my AFRAC name was used, this stayed - I am not the only one accessing the mails. During the last call period there are mails copied to ietf and to ltru and this creates a problem, probably obliging Randy to accept the two names (thank you for that). I was not aware I used a third one (as a consultant and a searcher I am involved in more than thirty activities and projects, with various assistant/teams calling for a dedicated password): this was a mistake. I will take advantage from your remark. It shows that common mail behaviour (I am using e-mail for management purposes for 28 years, so one grow accustomed to various habits ...) leads people to have various avatars, and that each of these avatars has a dedicated organisation and context. (as you noted I am not the only one). This is related to languages because each avatar has different relational parameters (for example signature: I suppose that you do not use your spe.sony.com for personal relations) and can also have various langtags. This certainly add to the complexity of tagging. This kind of errors, for the organisation of a mailing list, could be addressed through a dedicated OPES. Which also could address langtags related issues and services. And interfacte ISO 11179 compliant registries, etc. I will not continue :-) Take care jfc >Karen Broome >Metadata Systems Designer >Sony Pictures Entertainment >310.244.4384 --=====================_2624083==.ALT Content-Type: text/html; charset="us-ascii" At 22:09 29/08/2005, Karen_Broome@spe.sony.com wrote:
Jefsey,
As I am reading through my in-box on this subject, I see you have used no less than three different e-mail addresses and identities on the LTRU list today. It would be of great assistance to all if you could decide on a single personality to use to represent yourself within this group -- if that is an acceptable cultural imposition.

Dear Karen,
I apologise for the inconvenience (I suppose you classify the incoming mails per authors?). The reason why of two is that my IETF mailname is jefsey@jefsey.com (my regular mail) and that when I was banned from this list this rose the interest of my working group, and my AFRAC name was used, this stayed - I am not the only one accessing the mails. During the last call period there are mails copied to ietf and to ltru and this creates a problem, probably obliging Randy to accept the two names (thank you for that).

I was not aware I used a third one (as a consultant and a searcher I am involved in more than thirty activities and projects, with various assistant/teams calling for a dedicated password): this was a mistake.

I will take advantage from your remark. It shows that common mail behaviour (I am using e-mail for management purposes for 28 years, so one grow accustomed to various habits ...) leads people to have various avatars, and that each of these avatars has a dedicated organisation and context. (as you noted I am not the only one). This is related to languages because each avatar has different relational parameters (for example signature: I suppose that you do not use your spe.sony.com for personal relations) and can also have various langtags.  This certainly add to the complexity of tagging.

This kind of errors, for the organisation of a mailing list, could be addressed through a dedicated OPES. Which also could address langtags related issues and services. And interfacte ISO 11179 compliant registries, etc. I will not continue :-)

Take care
jfc








Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384
--=====================_2624083==.ALT-- --===============0001833957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0001833957==-- From ltru-bounces@ietf.org Mon Aug 29 19:34:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9t9D-00017v-VE; Mon, 29 Aug 2005 19:34:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9t9C-00015k-PS for ltru@megatron.ietf.org; Mon, 29 Aug 2005 19:34:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23685 for ; Mon, 29 Aug 2005 19:34:35 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9tAd-0004H1-CB for ltru@ietf.org; Mon, 29 Aug 2005 19:36:08 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7TNXinK032000 for ; Mon, 29 Aug 2005 19:33:51 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7TNXiLB320040 for ; Mon, 29 Aug 2005 17:33:44 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7TNXcB6021548 for ; Mon, 29 Aug 2005 17:33:38 -0600 Received: from [127.0.0.1] (mark-davis.sanjose.ibm.com [9.43.213.128]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7TNXcRZ021529; Mon, 29 Aug 2005 17:33:38 -0600 Message-ID: <43139B4F.1030102@icu-project.org> Date: Mon, 29 Aug 2005 16:33:35 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Debbie Garside Subject: Re: FW: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) References: <200508291950.j7TJocem006641@smtp-los04.proxy.aol.com> In-Reply-To: <200508291950.j7TJocem006641@smtp-los04.proxy.aol.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > ISO 639-6 is based on the Linguasphere Register by Dr David Dalby published > 1999/2000; it is currently being revised in conjunction with the standard. At the very least, you should not say "standard", but instead say "proposed standard". It is *not* an ISO standard, not even a CD. Mark Debbie Garside wrote: > > Doug Ewell wrote: > > >>I'm a bit surprised that a work characterized as a work-in-progress and >>not yet ready for public review is nevertheless deemed ready to be >>considered as a draft international standard. > > > ISO 639-6 is based on the Linguasphere Register by Dr David Dalby published > 1999/2000; it is currently being revised in conjunction with the standard. > There are a number of copies still available if you would like to order one! > ;-) > > >>-----Original Message----- >>From: Doug Ewell [mailto:dewell@adelphia.net] >>Sent: 28 August 2005 19:36 >>To: LTRU Working Group >>Cc: Debbie Garside >>Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying >>Languages' toBCP) >> >>Debbie Garside wrote: >> >> >>>I don't think anyone should make assumptions where technology is >>>concerned! What I can say is that the database for the 639-6 standard >>>will be made freely available online, in the same way as the >>>Ethnologue, as soon as it is ready. However, this is a WIP and there >>>really is no point putting up half information that has not yet been >>>verified. I am currently putting together the verification >>>methodology which will be implemented by various collaboration >>>partners internationally. I cannot at this moment say when the >>>database will be ready but rest assured you will be notified. >> > We're not talking about a > >>completely new invention, but a method of classifying languages, which >>is a human endeavor dating back many centuries if not millenia. >> >>But I'm certainly glad that my assumption that the information might not >>be made freely available was incorrect. Clearly, there can't be >>anything proprietary or IP-restricted about the data available for >>language tags (but of course Linguasphere can always provide proprietary >>value-added data, such as the language hierarchy). >> >> >>>As it stands at the moment, 639-6 will provide each linguistic entity >>>with one language reference name. This reference name is intended for >>>use as the unique data identifier (DI as per 11179). Unique Data >>>Identifiers and alpha-4 Representations for each linguistic entity >>>written, spoken and signed down to the level of dialect and component >>>variety, where appropriate, will be provided. Because 639-6 is a >>>hierarchical system (the parent alpha-4 representation is provided), >>>it lends itself very well to the "mapping" of the other codes of the >>>639 family; something that should prove invaluable for backward >>>compatibility. In other words, in the system as proposed, you could >>>use either the alpha-4 representation or the unique DI to find the >>>closest 639-1,-2,-3 or -5 tags should you so wish. >> >>But in language tags, either one value needs to be canonical -- sorry, >>"preferred" -- over the others, or else the duplicative values should be >>not be added at all. Otherwise there is a significant burden on those >>who would perform matching. >> >>I would suggest that for compatibility, subtags directly mappable to ISO >>639-1/2/3 should not be added. This is similar to the situation with >>ISO 639-2 in RFC 3066, where values like "eng" were not made available >>for language tags because of the pre-existence of "en". >> >>Will Linguasphere provide the mapping between the new alpha-4 codes and >>ISO 639-1/2/3, or is that something a group like this would have to do? >> >> >>>>Meanwhile, the claim that there are "over 20,000 languages" to be >>>>tagged is being used as an argument against the current RFC 3066bis >>>>effort and the plan to support 7,600 languages in RFC 3066ter. >>> >>>Hmmmm... at this point there could be very lengthy off topic >>>discussions as to what is a language and I don't think that is a good >>>idea. I would not say that there are 20,000 languages but rather >>>nearer to 7,600 as stated in 639-3; just my humble opinion. JFTR, I >>>support the inclusion of 639-3 in RFC3066ter. >> >>I agree that the broad question of "what is a language" is out of our >>scope. The more specific question "what is a taggable language >>distinction" is perhaps more germane. I just think the two figures >>(7,600 and 20,000) could be seen as representing a fundamental >>disagreement. I'd like to cite a specfic example of a distinction that >>is made in 639-6 but not 639-3, but I can't because the data's not yet >>available. >> >>I did not mean to imply that it was you (or Lee) who opposed either the >>current draft or the proposed use of ISO 639-3 in future drafts. >> >> >>>>I'm not saying anything against the Linguasphere effort per se, but >>>>with the limited knowledge available to me, I don't think its >>>>eventual role in language tagging should be considered a fait >>>>accompli. >>> >>>That is your prerogative but IMHO very much a sensible approach (see >>>first line comment). >>> >>>ISO 639-6 is being created as an International Standard. There is a >>>long way to go (earliest completion 2007) until it reaches full IS and >>>no doubt there will be twists and turns on the ISO journey :-) >>> >>>As previously mentioned by Peter, there will be a draft CD for comment >>>available by the end of November. At that time I will happily make it >>>available to this expert group for comment. >> >>I will gladly wait until then before trying to make specific comments on >>639-6. Until then, I stand by my prerogative (in the U.S. we might say >>that it's not a slam dunk). >> >> >>>Have a nice day! >> >>+1 >> >>-- >>Doug Ewell >>Fullerton, California >>http://users.adelphia.net/~dewell/ > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 22:52:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wEW-0003hm-Aj; Mon, 29 Aug 2005 22:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wET-0003hV-Fi for ltru@megatron.ietf.org; Mon, 29 Aug 2005 22:52:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02218 for ; Mon, 29 Aug 2005 22:52:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9wFt-00010z-TF for ltru@ietf.org; Mon, 29 Aug 2005 22:53:48 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9wEK-0004vb-Jw; Mon, 29 Aug 2005 19:52:08 -0700 Message-Id: <6.2.3.4.2.20050830043117.03a946e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 30 Aug 2005 04:42:57 +0200 To: Mark Davis , Debbie Garside From: r&d afrac Subject: Re: FW: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) In-Reply-To: <43139B4F.1030102@icu-project.org> References: <200508291950.j7TJocem006641@smtp-los04.proxy.aol.com> <43139B4F.1030102@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 01:33 30/08/2005, Mark Davis wrote: > > ISO 639-6 is based on the Linguasphere Register by Dr David Dalby published > > 1999/2000; it is currently being revised in conjunction with the standard. > >At the very least, you should not say "standard", but instead say >"proposed standard". It is *not* an ISO standard, not even a CD. Dear Mark, you call your Draft RFC 3066bis for so long, you could allow Debbie to enjoy calling her ISO 639-6 work a standard once. I may miss something, but you should be happy she supports and enhances your Draft with possibly missing names in ISO 639-3 to be? She even permitted Peter to document that (nobody known it!): in spite of having a WG consensus against the very idea, your Draft supported ISO 11179 (however no one but me ever talked of ISO 11179 conformant table). Now you are correct, it is not a CD but a very big book, very long to scann. Debbie could we at least have a file copy of the 1999/2000 version? It would save me days... Thank you. jfc >Mark > >Debbie Garside wrote: >>Doug Ewell wrote: >> >>>I'm a bit surprised that a work characterized as a work-in-progress and >>>not yet ready for public review is nevertheless deemed ready to be >>>considered as a draft international standard. >> >>ISO 639-6 is based on the Linguasphere Register by Dr David Dalby published >>1999/2000; it is currently being revised in conjunction with the standard. >>There are a number of copies still available if you would like to order one! >>;-) >> >>>-----Original Message----- >>>From: Doug Ewell [mailto:dewell@adelphia.net] >>>Sent: 28 August 2005 19:36 >>>To: LTRU Working Group >>>Cc: Debbie Garside >>>Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying >>>Languages' toBCP) >>> >>>Debbie Garside wrote: >>> >>> >>>>I don't think anyone should make assumptions where technology is >>>>concerned! What I can say is that the database for the 639-6 standard >>>>will be made freely available online, in the same way as the >>>>Ethnologue, as soon as it is ready. However, this is a WIP and there >>>>really is no point putting up half information that has not yet been >>>>verified. I am currently putting together the verification >>>>methodology which will be implemented by various collaboration >>>>partners internationally. I cannot at this moment say when the >>>>database will be ready but rest assured you will be notified. >>We're not talking about a >> >>>completely new invention, but a method of classifying languages, which >>>is a human endeavor dating back many centuries if not millenia. >>> >>>But I'm certainly glad that my assumption that the information might not >>>be made freely available was incorrect. Clearly, there can't be >>>anything proprietary or IP-restricted about the data available for >>>language tags (but of course Linguasphere can always provide proprietary >>>value-added data, such as the language hierarchy). >>> >>> >>>>As it stands at the moment, 639-6 will provide each linguistic entity >>>>with one language reference name. This reference name is intended for >>>>use as the unique data identifier (DI as per 11179). Unique Data >>>>Identifiers and alpha-4 Representations for each linguistic entity >>>>written, spoken and signed down to the level of dialect and component >>>>variety, where appropriate, will be provided. Because 639-6 is a >>>>hierarchical system (the parent alpha-4 representation is provided), >>>>it lends itself very well to the "mapping" of the other codes of the >>>>639 family; something that should prove invaluable for backward >>>>compatibility. In other words, in the system as proposed, you could >>>>use either the alpha-4 representation or the unique DI to find the >>>>closest 639-1,-2,-3 or -5 tags should you so wish. >>> >>>But in language tags, either one value needs to be canonical -- sorry, >>>"preferred" -- over the others, or else the duplicative values should be >>>not be added at all. Otherwise there is a significant burden on those >>>who would perform matching. >>> >>>I would suggest that for compatibility, subtags directly mappable to ISO >>>639-1/2/3 should not be added. This is similar to the situation with >>>ISO 639-2 in RFC 3066, where values like "eng" were not made available >>>for language tags because of the pre-existence of "en". >>> >>>Will Linguasphere provide the mapping between the new alpha-4 codes and >>>ISO 639-1/2/3, or is that something a group like this would have to do? >>> >>> >>>>>Meanwhile, the claim that there are "over 20,000 languages" to be >>>>>tagged is being used as an argument against the current RFC 3066bis >>>>>effort and the plan to support 7,600 languages in RFC 3066ter. >>>> >>>>Hmmmm... at this point there could be very lengthy off topic >>>>discussions as to what is a language and I don't think that is a good >>>>idea. I would not say that there are 20,000 languages but rather >>>>nearer to 7,600 as stated in 639-3; just my humble opinion. JFTR, I >>>>support the inclusion of 639-3 in RFC3066ter. >>> >>>I agree that the broad question of "what is a language" is out of our >>>scope. The more specific question "what is a taggable language >>>distinction" is perhaps more germane. I just think the two figures >>>(7,600 and 20,000) could be seen as representing a fundamental >>>disagreement. I'd like to cite a specfic example of a distinction that >>>is made in 639-6 but not 639-3, but I can't because the data's not yet >>>available. >>> >>>I did not mean to imply that it was you (or Lee) who opposed either the >>>current draft or the proposed use of ISO 639-3 in future drafts. >>> >>> >>>>>I'm not saying anything against the Linguasphere effort per se, but >>>>>with the limited knowledge available to me, I don't think its >>>>>eventual role in language tagging should be considered a fait >>>>>accompli. >>>> >>>>That is your prerogative but IMHO very much a sensible approach (see >>>>first line comment). >>>> >>>>ISO 639-6 is being created as an International Standard. There is a >>>>long way to go (earliest completion 2007) until it reaches full IS and >>>>no doubt there will be twists and turns on the ISO journey :-) >>>> >>>>As previously mentioned by Peter, there will be a draft CD for comment >>>>available by the end of November. At that time I will happily make it >>>>available to this expert group for comment. >>> >>>I will gladly wait until then before trying to make specific comments on >>>639-6. Until then, I stand by my prerogative (in the U.S. we might say >>>that it's not a slam dunk). >>> >>> >>>>Have a nice day! >>> >>>+1 >>> >>>-- >>>Doug Ewell >>>Fullerton, California >>>http://users.adelphia.net/~dewell/ >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 22:56:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wIM-0004F9-3U; Mon, 29 Aug 2005 22:56:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wIK-0004Eu-2Q for ltru@megatron.ietf.org; Mon, 29 Aug 2005 22:56:16 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02332 for ; Mon, 29 Aug 2005 22:56:13 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9wH6-0003DU-L8 for ltru@lists.ietf.org; Tue, 30 Aug 2005 04:55:00 +0200 Received: from c-180-161-85.hh.dial.de.ignite.net ([62.180.161.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Aug 2005 04:55:00 +0200 Received: from nobody by c-180-161-85.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Aug 2005 04:55:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 30 Aug 2005 04:52:27 +0200 Organization: Lines: 9 Message-ID: <4313C9EB.4F37@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-85.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] OT: record-jar X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi, I forgot who was interested to create an I-D for record-jar. Apparently a very similar effort: draft-kunze-anvl-02.txt http://www.ietf.org/internet-drafts/draft-kunze-anvl-02.txt Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 29 23:23:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wj9-0004Ai-Bv; Mon, 29 Aug 2005 23:23:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wj7-0004Aa-8m for ltru@megatron.ietf.org; Mon, 29 Aug 2005 23:23:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03397 for ; Mon, 29 Aug 2005 23:23:54 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9wkX-0001lq-SU for ltru@ietf.org; Mon, 29 Aug 2005 23:25:28 -0400 Received: from h-68-164-241-191.snvacaid.dynamic.covad.net ([68.164.241.191] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E9wiz-00077u-00 for ltru@ietf.org; Mon, 29 Aug 2005 23:23:49 -0400 Message-ID: <00ff01c5ad12$7fed4580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <4313C9EB.4F37@xyzzy.claranet.de> Subject: Re: [Ltru] OT: record-jar Date: Mon, 29 Aug 2005 20:25:40 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Monday, August 29, 2005 7:52 PM > Subject: [Ltru] OT: record-jar > > Hi, > > I forgot who was interested to create an I-D for record-jar. > Apparently a very similar effort: draft-kunze-anvl-02.txt > > http://www.ietf.org/internet-drafts/draft-kunze-anvl-02.txt > > Bye, Frank ... Thank you for the pointer. I suggest that those interested in further discussion contact the authors of that draft directly, since, as Frank notes, this is off-topic. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 00:36:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xrY-0002gA-Fl; Tue, 30 Aug 2005 00:36:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xrW-0002g5-Dl for ltru@megatron.ietf.org; Tue, 30 Aug 2005 00:36:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06117 for ; Tue, 30 Aug 2005 00:36:39 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9xsx-0003ba-MW for ltru@ietf.org; Tue, 30 Aug 2005 00:38:13 -0400 Received: from h-68-164-241-191.snvacaid.dynamic.covad.net ([68.164.241.191] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E9xrO-0006z6-00 for ltru@ietf.org; Tue, 30 Aug 2005 00:36:34 -0400 Message-ID: <014001c5ad1c$ac1d0640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <430FEA04.5DF@xyzzy.claranet.de> <6.0.0.20.2.20050827142041.083322d0@localhost> Subject: Re: [Ltru] Re: update on ISO 639 Date: Mon, 29 Aug 2005 21:38:29 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Martin Duerst" > To: "Frank Ellermann" ; > Sent: Friday, August 26, 2005 10:22 PM > Subject: Re: [Ltru] Re: update on ISO 639 ... > Randy may know more details about this, but in general, > an IETF WG first completes the existing milestones, and > only then maybe applies for a charter extension with new > work. Of course there sometimes are exceptions to this, > but I think they are very rare. Also, our plan is to > finish the matching draft by October, so let's try to > concentrate on that one. ... Martin is quite right. The relevant text is RFC 2418 section 5, where it says: Rechartering (other than revising milestones) a working group follows the same procedures that the initial chartering does (see section 2). The revised charter must be submitted to the IESG and IAB for approval. As with the initial chartering, the IESG may approve new charter as-is, it may request that changes be made in the new charter (including having the Working Group continue to use the old charter), or it may decline to approve the rechartered working group. In the latter case, the working group is disbanded. This sometimes happens when a group has not met its milestones; the current discussion in the isms working group is a good example of that kind of situation. As for our situation, as co-chair I wholeheartedly agree with Martin that we should complete our chartered work before asking for more work. As a technical contributor, I'd like to see the fate of other registry proposals not the responsibility of this working group, e.g., http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-03.txt and http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-registry-03.txt, before deciding whether to spend time on another effort like this one. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 03:51:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA0uV-0008It-Ah; Tue, 30 Aug 2005 03:51:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA0uT-0008Io-HO for ltru@megatron.ietf.org; Tue, 30 Aug 2005 03:51:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27329 for ; Tue, 30 Aug 2005 03:51:55 -0400 (EDT) Received: from rly-ip06.mx.aol.com ([64.12.138.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA0vo-00005q-9h for ltru@ietf.org; Tue, 30 Aug 2005 03:53:30 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip06.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7U7pEWj022684; Tue, 30 Aug 2005 03:51:15 -0400 Received: from DEBHOME (ACCBA57F.ipt.aol.com [172.203.165.127]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7U7p6U0015121; Tue, 30 Aug 2005 03:51:06 -0400 Message-Id: <200508300751.j7U7p6U0015121@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Mark Davis'" Subject: RE: FW: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' toBCP) Date: Tue, 30 Aug 2005 08:51:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWs8j+ohPLUM68fTr+2IBcmJYi5wwARJsBQ In-Reply-To: <43139B4F.1030102@icu-project.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I think it has been made perfectly clear where we are with it! > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 30 August 2005 00:34 > To: Debbie Garside > Cc: 'LTRU Working Group' > Subject: Re: FW: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying > Languages' toBCP) > > > ISO 639-6 is based on the Linguasphere Register by Dr David Dalby > published > > 1999/2000; it is currently being revised in conjunction with the > standard. > > At the very least, you should not say "standard", but instead say > "proposed standard". It is *not* an ISO standard, not even a CD. > > Mark > > Debbie Garside wrote: > > > > Doug Ewell wrote: > > > > > >>I'm a bit surprised that a work characterized as a work-in-progress and > >>not yet ready for public review is nevertheless deemed ready to be > >>considered as a draft international standard. > > > > > > ISO 639-6 is based on the Linguasphere Register by Dr David Dalby > published > > 1999/2000; it is currently being revised in conjunction with the > standard. > > There are a number of copies still available if you would like to order > one! > > ;-) > > > > > >>-----Original Message----- > >>From: Doug Ewell [mailto:dewell@adelphia.net] > >>Sent: 28 August 2005 19:36 > >>To: LTRU Working Group > >>Cc: Debbie Garside > >>Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying > >>Languages' toBCP) > >> > >>Debbie Garside wrote: > >> > >> > >>>I don't think anyone should make assumptions where technology is > >>>concerned! What I can say is that the database for the 639-6 standard > >>>will be made freely available online, in the same way as the > >>>Ethnologue, as soon as it is ready. However, this is a WIP and there > >>>really is no point putting up half information that has not yet been > >>>verified. I am currently putting together the verification > >>>methodology which will be implemented by various collaboration > >>>partners internationally. I cannot at this moment say when the > >>>database will be ready but rest assured you will be notified. > >> > > We're not talking about a > > > >>completely new invention, but a method of classifying languages, which > >>is a human endeavor dating back many centuries if not millenia. > >> > >>But I'm certainly glad that my assumption that the information might not > >>be made freely available was incorrect. Clearly, there can't be > >>anything proprietary or IP-restricted about the data available for > >>language tags (but of course Linguasphere can always provide proprietary > >>value-added data, such as the language hierarchy). > >> > >> > >>>As it stands at the moment, 639-6 will provide each linguistic entity > >>>with one language reference name. This reference name is intended for > >>>use as the unique data identifier (DI as per 11179). Unique Data > >>>Identifiers and alpha-4 Representations for each linguistic entity > >>>written, spoken and signed down to the level of dialect and component > >>>variety, where appropriate, will be provided. Because 639-6 is a > >>>hierarchical system (the parent alpha-4 representation is provided), > >>>it lends itself very well to the "mapping" of the other codes of the > >>>639 family; something that should prove invaluable for backward > >>>compatibility. In other words, in the system as proposed, you could > >>>use either the alpha-4 representation or the unique DI to find the > >>>closest 639-1,-2,-3 or -5 tags should you so wish. > >> > >>But in language tags, either one value needs to be canonical -- sorry, > >>"preferred" -- over the others, or else the duplicative values should be > >>not be added at all. Otherwise there is a significant burden on those > >>who would perform matching. > >> > >>I would suggest that for compatibility, subtags directly mappable to ISO > >>639-1/2/3 should not be added. This is similar to the situation with > >>ISO 639-2 in RFC 3066, where values like "eng" were not made available > >>for language tags because of the pre-existence of "en". > >> > >>Will Linguasphere provide the mapping between the new alpha-4 codes and > >>ISO 639-1/2/3, or is that something a group like this would have to do? > >> > >> > >>>>Meanwhile, the claim that there are "over 20,000 languages" to be > >>>>tagged is being used as an argument against the current RFC 3066bis > >>>>effort and the plan to support 7,600 languages in RFC 3066ter. > >>> > >>>Hmmmm... at this point there could be very lengthy off topic > >>>discussions as to what is a language and I don't think that is a good > >>>idea. I would not say that there are 20,000 languages but rather > >>>nearer to 7,600 as stated in 639-3; just my humble opinion. JFTR, I > >>>support the inclusion of 639-3 in RFC3066ter. > >> > >>I agree that the broad question of "what is a language" is out of our > >>scope. The more specific question "what is a taggable language > >>distinction" is perhaps more germane. I just think the two figures > >>(7,600 and 20,000) could be seen as representing a fundamental > >>disagreement. I'd like to cite a specfic example of a distinction that > >>is made in 639-6 but not 639-3, but I can't because the data's not yet > >>available. > >> > >>I did not mean to imply that it was you (or Lee) who opposed either the > >>current draft or the proposed use of ISO 639-3 in future drafts. > >> > >> > >>>>I'm not saying anything against the Linguasphere effort per se, but > >>>>with the limited knowledge available to me, I don't think its > >>>>eventual role in language tagging should be considered a fait > >>>>accompli. > >>> > >>>That is your prerogative but IMHO very much a sensible approach (see > >>>first line comment). > >>> > >>>ISO 639-6 is being created as an International Standard. There is a > >>>long way to go (earliest completion 2007) until it reaches full IS and > >>>no doubt there will be twists and turns on the ISO journey :-) > >>> > >>>As previously mentioned by Peter, there will be a draft CD for comment > >>>available by the end of November. At that time I will happily make it > >>>available to this expert group for comment. > >> > >>I will gladly wait until then before trying to make specific comments on > >>639-6. Until then, I stand by my prerogative (in the U.S. we might say > >>that it's not a slam dunk). > >> > >> > >>>Have a nice day! > >> > >>+1 > >> > >>-- > >>Doug Ewell > >>Fullerton, California > >>http://users.adelphia.net/~dewell/ > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 05:35:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA2WL-0006RW-EF; Tue, 30 Aug 2005 05:35:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA2WI-0006RI-QJ for ltru@megatron.ietf.org; Tue, 30 Aug 2005 05:35:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01633 for ; Tue, 30 Aug 2005 05:35:04 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA2Xm-0003DS-Vk for ltru@ietf.org; Tue, 30 Aug 2005 05:36:41 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 02:34:56 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 02:34:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Ltru] Re: STD (was: Last Call: 'Tags for IdentifyingLanguages' toBCP) Date: Tue, 30 Aug 2005 02:35:07 -0700 Message-ID: Thread-Topic: FW: [Ltru] Re: STD (was: Last Call: 'Tags for IdentifyingLanguages' toBCP) Thread-Index: AcWs8j+ohPLUM68fTr+2IBcmJYi5wwARJsBQAAK40zA= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 30 Aug 2005 09:34:56.0405 (UTC) FILETIME=[1525EC50:01C5AD46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Debbie Garside > > At the very least, you should not say "standard", but instead say > > "proposed standard". It is *not* an ISO standard, not even a CD. > I think it has been made perfectly clear where we are with it! Indeed. "Proposed standard" is not entirely incorrect to the extent that the intent (similar meaning to "proposal") is to create a standard. At the same time, it would also be fair to say it doesn't reflect the current status.=20 Technically, the ISO 639-6 project is beyond the proposal stage and can be considered an approved work item (AWI); the current stage is referred to as the preparatory stage, at which stage document are referred to as working drafts. It will remain such until it is registered with the ISO secretariat as a committee draft (CD) and distributed throughout SC2 for comments. So, one might refer to ISO AWI 639-6, or perhaps to ISO/WD 639-6. One should not refer to ISO 639-6 as a standard, though. Similarly, one should not yet refer to ISO 639-3 as a standard: it is a draft international standard (soon to be registered as final draft IS). Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 06:15:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA35J-0007Ku-Sj; Tue, 30 Aug 2005 06:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA2Ji-00039m-M9; Tue, 30 Aug 2005 05:22:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01028; Tue, 30 Aug 2005 05:22:04 -0400 (EDT) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA2LD-0002oZ-ES; Tue, 30 Aug 2005 05:23:41 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j7U9LuKT281522; Tue, 30 Aug 2005 09:21:56 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7U9LtJv204080; Tue, 30 Aug 2005 10:21:55 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j7U9Ltkx027467; Tue, 30 Aug 2005 10:21:55 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j7U9Lsq3027458; Tue, 30 Aug 2005 10:21:55 +0100 Received: from zurich.ibm.com (sig-9-146-223-240.de.ibm.com [9.146.223.240]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA57504; Tue, 30 Aug 2005 11:21:53 +0200 Message-ID: <4314252F.4040500@zurich.ibm.com> Date: Tue, 30 Aug 2005 11:21:51 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: STD References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL> <6.2.3.4.2.20050829090011.04dcc7f0@mail.afrac.org> <024201c5aca9$fe47dc60$030aa8c0@DEWELL> <20050829151605.GA24985@nic.fr> In-Reply-To: <20050829151605.GA24985@nic.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Aug 2005 06:11:16 -0400 Cc: Doug Ewell , LTRU Working Group , ietf@ietf.org, iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Gentlemen, Whatever one may or may not think of Jefsey's logic, please confine yourselves to discussing his logic and not the man himself. Thanks Brian Stephane Bortzmeyer wrote: > On Mon, Aug 29, 2005 at 07:57:35AM -0700, > Doug Ewell wrote > a message of 37 lines which said: > > >>Quick show of hands: How many people think M. Morfin has been hampered >>by a reluctance to challenge the rest of the Working Group? > > ... > >>Which of your objections to the draft are based on your French-speaking, >>French-national cultural affiliation, > > > I can testify that Jefsey Morfin is exactly as verbose and unparsable > when he writes in French. His postings in my main language are (like > he does in english) very long and full of pseudo-technical babbling. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 10:31:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA78u-0004vj-4u; Tue, 30 Aug 2005 10:31:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA78s-0004vM-Jt for ltru@megatron.ietf.org; Tue, 30 Aug 2005 10:31:14 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16256 for ; Tue, 30 Aug 2005 10:31:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050830143042.WRDR12299.mta13.adelphia.net@DEWELL> for ; Tue, 30 Aug 2005 10:30:42 -0400 Message-ID: <02b201c5ad6e$fba92020$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050830101246.DVZO9239.mta8.adelphia.net@megatron.ietf.org> Date: Tue, 30 Aug 2005 07:27:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Use of term "RFC 3066bis" (was: Re: STD) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org r&d afrac wrote: > you call your Draft RFC 3066bis for so long, you could allow Debbie > to enjoy calling her ISO 639-6 work a standard once. It has already been explained many, many times that the term "RFC 3066bis" is an abbreviation for "the intended successor to RFC 3066." It does not mean "we consider this draft to be an RFC already." Think of it as being grouped as follows: (RFC 3066) bis -not- RFC (3066 bis) If you visit the I-D Search page at http://www.rfc-editor.org/idsearch.html and enter "bis", you will find several other instances of drafts identified as RFC something-bis. This is an established shorthand usage, not something Mark or anyone else dreamed up to try to fool anyone into thinking it is already an RFC. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 15:21:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABg2-0005Bb-Ih; Tue, 30 Aug 2005 15:21:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABg0-0005AS-Kn for ltru@megatron.ietf.org; Tue, 30 Aug 2005 15:21:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02824 for ; Tue, 30 Aug 2005 15:21:42 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EABha-0002Vi-B5 for ltru@ietf.org; Tue, 30 Aug 2005 15:23:24 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC98A32009B; Tue, 30 Aug 2005 21:21:15 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18542-03; Tue, 30 Aug 2005 21:21:12 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE727320095; Tue, 30 Aug 2005 21:21:11 +0200 (CEST) Date: Tue, 30 Aug 2005 21:19:26 +0200 From: Harald Tveit Alvestrand To: Peter Constable , LTRU Working Group Subject: RE: FW: [Ltru] Re: STD (was: Last Call: 'Tags for IdentifyingLanguages' toBCP) Message-ID: <4FD6024E9A7C62F743B46939@B50854F0A9192E8EC6CDA126> In-Reply-To: References: X-Mailer: Mulberry/4.0.2 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563679880==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0563679880== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========DF481ACC22912A027F2A==========" --==========DF481ACC22912A027F2A========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 30. august 2005 02:35 -0700 Peter Constable =20 wrote: >> Debbie Garside > >> > At the very least, you should not say "standard", but instead say >> > "proposed standard". It is *not* an ISO standard, not even a CD. > >> I think it has been made perfectly clear where we are with it! > > Indeed. "Proposed standard" is not entirely incorrect to the extent that > the intent (similar meaning to "proposal") is to create a standard. Since "Proposed Standard" is a "reserved word" that means something=20 completley different in the IETF context, it seems better to use "ISO=20 Approved Work Item" when discussing 639-6 in an IETF context....... Harald --==========DF481ACC22912A027F2A========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFDFLE+OMj+2+WY0F4RAm9MAJ0U2xmno98ZmZJdemnbLCYo/x+kIQCgr0s4 JTgt8jv24uJINvdnNwpKAXE= =zsHY -----END PGP SIGNATURE----- --==========DF481ACC22912A027F2A==========-- --===============0563679880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0563679880==-- From ltru-bounces@ietf.org Tue Aug 30 15:44:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAC1w-0002An-Ta; Tue, 30 Aug 2005 15:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAC1v-0002Ag-Gp for ltru@megatron.ietf.org; Tue, 30 Aug 2005 15:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04156 for ; Tue, 30 Aug 2005 15:44:21 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAC3W-00038L-03 for ltru@ietf.org; Tue, 30 Aug 2005 15:46:03 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 12:44:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Ltru] Re:what to call 639-6 (was STD) Date: Tue, 30 Aug 2005 12:44:08 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA90CB6@irvmbxw01.quest.com> Thread-Topic: FW: [Ltru] Re:what to call 639-6 (was STD) Thread-Index: AcWtmEU/1yqvDWPdRP+fTadRL6Y5FwAABlGQ From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 30 Aug 2005 19:44:08.0490 (UTC) FILETIME=[2FE378A0:01C5AD9B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Since we don't reference it normatively anywhere, this strikes me as a = non-issue. Why don't we call it "ISO 639-6"? If anyone was unaware or = confused previously, they now know from this thread what its current = status is. It strikes me as counter productive to refer to it constantly = as "the ISO Approved Work Item ISO 639-6 which isn't a standard quite = yet". It was necessary to make the point that ISO 639-6 is not yet in a = finished state (in response to the assertion that draft-registry should = have a normative reference to it), and I am as concerned as others about = the logistics of integrating it to draft-registry in the future. I don't = think it adds anything to the debate to use a sort of tortured jargon in = order to refer to it in our conversations. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Harald Tveit Alvestrand > Sent: 2005?8?30? 12:19 > To: Peter Constable; LTRU Working Group > Subject: RE: FW: [Ltru] Re: STD (was: Last Call: 'Tags > forIdentifyingLanguages' toBCP) >=20 >=20 >=20 > --On 30. august 2005 02:35 -0700 Peter Constable = > wrote: >=20 > >> Debbie Garside > > > >> > At the very least, you should not say "standard", but instead say > >> > "proposed standard". It is *not* an ISO standard, not even a CD. > > > >> I think it has been made perfectly clear where we are with it! > > > > Indeed. "Proposed standard" is not entirely incorrect to the extent = that > > the intent (similar meaning to "proposal") is to create a standard. >=20 > Since "Proposed Standard" is a "reserved word" that means something > completley different in the IETF context, it seems better to use "ISO > Approved Work Item" when discussing 639-6 in an IETF context....... >=20 > Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 16:14:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACRt-0005SS-Mn; Tue, 30 Aug 2005 16:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACRt-0005Rw-3K for ltru@megatron.ietf.org; Tue, 30 Aug 2005 16:11:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07772 for ; Tue, 30 Aug 2005 16:11:10 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EACTT-0004oO-FI for ltru@ietf.org; Tue, 30 Aug 2005 16:12:52 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7UKB2FQ008643 for ; Tue, 30 Aug 2005 16:11:02 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7UKB2gX098180 for ; Tue, 30 Aug 2005 16:11:02 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7UKB24g009939 for ; Tue, 30 Aug 2005 16:11:02 -0400 Received: from [127.0.0.1] (sig-9-48-109-192.mts.ibm.com [9.48.109.192]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7UKAscZ009434; Tue, 30 Aug 2005 16:10:55 -0400 Message-ID: <4314BD4E.1060508@icu-project.org> Date: Tue, 30 Aug 2005 13:10:54 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: FW: [Ltru] Re:what to call 639-6 (was STD) References: <634978A7DF025A40BFEF33EB191E13BC0CA90CB6@irvmbxw01.quest.com> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CA90CB6@irvmbxw01.quest.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org The reason for consistently saying 'proposed' (lowercase) is that it helps to keep people from being mislead about the status. And I don't think we need to go much further than that. As you say, not only do we not have a normative reference, we don't even have an informative reference in either document. Nor should we; it is premature. The proposed ISO 639-6 may never become a standard; that has happened before. Or it could end up like ISO TR 14652, a Type 1 TR: "when the required support cannot be obtained for the publication of an International Standard, despite repeated effort", but it still gets published. Or even if published, this WG or its successor may decide that it is inappropriate for 3066ter or quart or whatever. But that is all for the future. Mark Addison Phillips wrote: > Since we don't reference it normatively anywhere, this strikes me as a non-issue. Why don't we call it "ISO 639-6"? If anyone was unaware or confused previously, they now know from this thread what its current status is. It strikes me as counter productive to refer to it constantly as "the ISO Approved Work Item ISO 639-6 which isn't a standard quite yet". > > It was necessary to make the point that ISO 639-6 is not yet in a finished state (in response to the assertion that draft-registry should have a normative reference to it), and I am as concerned as others about the logistics of integrating it to draft-registry in the future. I don't think it adds anything to the debate to use a sort of tortured jargon in order to refer to it in our conversations. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > >>-----Original Message----- >>From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >>Harald Tveit Alvestrand >>Sent: 2005?8?30? 12:19 >>To: Peter Constable; LTRU Working Group >>Subject: RE: FW: [Ltru] Re: STD (was: Last Call: 'Tags >>forIdentifyingLanguages' toBCP) >> >> >> >>--On 30. august 2005 02:35 -0700 Peter Constable >>wrote: >> >> >>>>Debbie Garside >>> >>>>>At the very least, you should not say "standard", but instead say >>>>>"proposed standard". It is *not* an ISO standard, not even a CD. >>> >>>>I think it has been made perfectly clear where we are with it! >>> >>>Indeed. "Proposed standard" is not entirely incorrect to the extent that >>>the intent (similar meaning to "proposal") is to create a standard. >> >>Since "Proposed Standard" is a "reserved word" that means something >>completley different in the IETF context, it seems better to use "ISO >>Approved Work Item" when discussing 639-6 in an IETF context....... >> >> Harald > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 16:15:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACVx-0006yZ-4Z; Tue, 30 Aug 2005 16:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACVw-0006yU-9A for ltru@megatron.ietf.org; Tue, 30 Aug 2005 16:15:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08031 for ; Tue, 30 Aug 2005 16:15:21 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EACXX-0004xx-4v for ltru@ietf.org; Tue, 30 Aug 2005 16:17:04 -0400 Received: from h-68-166-38-22.snvacaid.dynamic.covad.net ([68.166.38.22] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EACVr-0007Lw-00 for ltru@ietf.org; Tue, 30 Aug 2005 16:15:19 -0400 Message-ID: <002901c5ad9f$d00019c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0CA90CB6@irvmbxw01.quest.com> Subject: Re: [Ltru] what to call 639-6 Date: Tue, 30 Aug 2005 13:17:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "LTRU Working Group" > Sent: Tuesday, August 30, 2005 12:44 PM > Subject: RE: FW: [Ltru] Re:what to call 639-6 (was STD) > > Since we don't reference it normatively anywhere, > this strikes me as a non-issue. Why don't we call it "ISO 639-6"? > If anyone was unaware or confused previously, they now know > from this thread what its current status is. > It strikes me as counter productive to refer to it constantly as > "the ISO Approved Work Item ISO 639-6 which isn't a standard quite yet". ... Since this topic keeps recurring in various forms, as a WG co-chair (who happens to have spent some time in ISO-land) I *strongly* suggest that we use the nomenclature suggested by Peter Constable, modulo Harald Alvestrand's comments, as it would be more precise while not being onerous. Specifically, as that work progresses, we should refer to "ISO AWI 639-6", or, if there actually is a working draft, to "ISO/WD 639-6". As that work progresses, if we still need to talk about, for example, the work at the Draft International Standard stage, "ISO DIS 639-6" would do nicely. I'm sure we can trust WG participants who are currently active in ISO work to keep us appraised of the current status and the preferred ISO notation. Typing an extra three or four characters, if it will prevent recurrance of this thread, will be well worth the effort. The phrases "proposed standard" and "draft standard" (which are not proper ISO-ese anyway) should be avoided in this context, since, as Harald pointed out, they have a very specific IETF meaning from RFC 2026. Now, can we please move on to *substantive* discussion? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 16:43:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACxB-0006K7-2j; Tue, 30 Aug 2005 16:43:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACx9-0006Jc-V5 for ltru@megatron.ietf.org; Tue, 30 Aug 2005 16:43:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08881 for ; Tue, 30 Aug 2005 16:43:29 -0400 (EDT) Received: from rly-ip07.mx.aol.com ([64.12.138.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EACyg-0005Vh-SI for ltru@ietf.org; Tue, 30 Aug 2005 16:45:12 -0400 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip07.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7UKgnSY011660; Tue, 30 Aug 2005 16:43:00 -0400 Received: from DEBHOME (ACCBA57F.ipt.aol.com [172.203.165.127]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7UKgaIh027701; Tue, 30 Aug 2005 16:42:36 -0400 Message-Id: <200508302042.j7UKgaIh027701@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] what to call 639-6 Date: Tue, 30 Aug 2005 21:42:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWtn6bQYaYDbKfHRiaMuG8NhZMIowAA2z0g In-Reply-To: <002901c5ad9f$d00019c0$7f1afea9@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi As the editor of this document, I am happy to go with "ISO AWI 639-6" and will keep this WG informed of any change in status. Kind regards Debbie Garside > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Randy Presuhn > Sent: 30 August 2005 21:17 > To: LTRU Working Group > Subject: Re: [Ltru] what to call 639-6 > > Hi - > > > From: "Addison Phillips" > > To: "LTRU Working Group" > > Sent: Tuesday, August 30, 2005 12:44 PM > > Subject: RE: FW: [Ltru] Re:what to call 639-6 (was STD) > > > > > Since we don't reference it normatively anywhere, > > this strikes me as a non-issue. Why don't we call it "ISO 639-6"? > > If anyone was unaware or confused previously, they now know > > from this thread what its current status is. > > It strikes me as counter productive to refer to it constantly as > > "the ISO Approved Work Item ISO 639-6 which isn't a standard quite yet". > ... > > Since this topic keeps recurring in various forms, as a WG co-chair > (who happens to have spent some time in ISO-land) I *strongly* > suggest that we use the nomenclature suggested by Peter Constable, > modulo Harald Alvestrand's comments, as it would be more precise > while not being onerous. Specifically, as that work progresses, we should > refer to "ISO AWI 639-6", or, if there actually is a working draft, to > "ISO/WD 639-6". As that work progresses, if we still need to talk > about, for example, the work at the Draft International Standard > stage, "ISO DIS 639-6" would do nicely. I'm sure we can trust > WG participants who are currently active in ISO work to keep us > appraised of the current status and the preferred ISO notation. > > Typing an extra three or four characters, if it will prevent recurrance > of this thread, will be well worth the effort. > > The phrases "proposed standard" and "draft standard" (which are > not proper ISO-ese anyway) should be avoided in this context, > since, as Harald pointed out, they have a very specific IETF > meaning from RFC 2026. > > Now, can we please move on to *substantive* discussion? > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 16:54:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAD8F-0000NX-HU; Tue, 30 Aug 2005 16:54:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAD8D-0000NS-N5 for ltru@megatron.ietf.org; Tue, 30 Aug 2005 16:54:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09271 for ; Tue, 30 Aug 2005 16:54:55 -0400 (EDT) Received: from rly-ip08.mx.aol.com ([64.12.138.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAD9o-0005nY-Pz for ltru@ietf.org; Tue, 30 Aug 2005 16:56:38 -0400 Received: from smtp-los01.proxy.aol.com ([195.93.24.40]) by rly-ip08.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7UKsk2b015054; Tue, 30 Aug 2005 16:54:46 -0400 Received: from DEBHOME (ACCBA57F.ipt.aol.com [172.203.165.127]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7UKscFF014239; Tue, 30 Aug 2005 16:54:39 -0400 Message-Id: <200508302054.j7UKscFF014239@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] what to call 639-6 Date: Tue, 30 Aug 2005 21:54:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWtn6bQYaYDbKfHRiaMuG8NhZMIowABQjIA In-Reply-To: <002901c5ad9f$d00019c0$7f1afea9@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Or if you prefer "ISO/WD 639-6" either would be correct! > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Randy Presuhn > Sent: 30 August 2005 21:17 > To: LTRU Working Group > Subject: Re: [Ltru] what to call 639-6 > > Hi - > > > From: "Addison Phillips" > > To: "LTRU Working Group" > > Sent: Tuesday, August 30, 2005 12:44 PM > > Subject: RE: FW: [Ltru] Re:what to call 639-6 (was STD) > > > > > Since we don't reference it normatively anywhere, > > this strikes me as a non-issue. Why don't we call it "ISO 639-6"? > > If anyone was unaware or confused previously, they now know > > from this thread what its current status is. > > It strikes me as counter productive to refer to it constantly as > > "the ISO Approved Work Item ISO 639-6 which isn't a standard quite yet". > ... > > Since this topic keeps recurring in various forms, as a WG co-chair > (who happens to have spent some time in ISO-land) I *strongly* > suggest that we use the nomenclature suggested by Peter Constable, > modulo Harald Alvestrand's comments, as it would be more precise > while not being onerous. Specifically, as that work progresses, we should > refer to "ISO AWI 639-6", or, if there actually is a working draft, to > "ISO/WD 639-6". As that work progresses, if we still need to talk > about, for example, the work at the Draft International Standard > stage, "ISO DIS 639-6" would do nicely. I'm sure we can trust > WG participants who are currently active in ISO work to keep us > appraised of the current status and the preferred ISO notation. > > Typing an extra three or four characters, if it will prevent recurrance > of this thread, will be well worth the effort. > > The phrases "proposed standard" and "draft standard" (which are > not proper ISO-ese anyway) should be avoided in this context, > since, as Harald pointed out, they have a very specific IETF > meaning from RFC 2026. > > Now, can we please move on to *substantive* discussion? > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 16:57:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADAe-0000fg-4O; Tue, 30 Aug 2005 16:57:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADAd-0000eV-5Q for ltru@megatron.ietf.org; Tue, 30 Aug 2005 16:57:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09321 for ; Tue, 30 Aug 2005 16:57:24 -0400 (EDT) Received: from rly-ip07.mx.aol.com ([64.12.138.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EADCF-0005q4-B4 for ltru@ietf.org; Tue, 30 Aug 2005 16:59:07 -0400 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip07.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7UKvC4m001520; Tue, 30 Aug 2005 16:57:14 -0400 Received: from DEBHOME (ACCBA57F.ipt.aol.com [172.203.165.127]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7UKuNN6031907; Tue, 30 Aug 2005 16:56:24 -0400 Message-Id: <200508302056.j7UKuNN6031907@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Debbie Garside'" , "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] what to call 639-6 Date: Tue, 30 Aug 2005 21:56:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWtn6bQYaYDbKfHRiaMuG8NhZMIowAA2z0gAACD31A= In-Reply-To: <200508302042.j7UKgaIh027701@smtp-los03.proxy.aol.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.5 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org For some reason the word "pedantic" springs to mind! ;-) > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Debbie Garside > Sent: 30 August 2005 21:43 > To: 'Randy Presuhn'; 'LTRU Working Group' > Subject: RE: [Ltru] what to call 639-6 > > Hi > > As the editor of this document, I am happy to go with > "ISO AWI 639-6" and will keep this WG informed of any change in status. > > Kind regards > > > Debbie Garside > > > -----Original Message----- > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > > Randy Presuhn > > Sent: 30 August 2005 21:17 > > To: LTRU Working Group > > Subject: Re: [Ltru] what to call 639-6 > > > > Hi - > > > > > From: "Addison Phillips" > > > To: "LTRU Working Group" > > > Sent: Tuesday, August 30, 2005 12:44 PM > > > Subject: RE: FW: [Ltru] Re:what to call 639-6 (was STD) > > > > > > > > Since we don't reference it normatively anywhere, > > > this strikes me as a non-issue. Why don't we call it "ISO 639-6"? > > > If anyone was unaware or confused previously, they now know > > > from this thread what its current status is. > > > It strikes me as counter productive to refer to it constantly as > > > "the ISO Approved Work Item ISO 639-6 which isn't a standard quite > yet". > > ... > > > > Since this topic keeps recurring in various forms, as a WG co-chair > > (who happens to have spent some time in ISO-land) I *strongly* > > suggest that we use the nomenclature suggested by Peter Constable, > > modulo Harald Alvestrand's comments, as it would be more precise > > while not being onerous. Specifically, as that work progresses, we > should > > refer to "ISO AWI 639-6", or, if there actually is a working draft, to > > "ISO/WD 639-6". As that work progresses, if we still need to talk > > about, for example, the work at the Draft International Standard > > stage, "ISO DIS 639-6" would do nicely. I'm sure we can trust > > WG participants who are currently active in ISO work to keep us > > appraised of the current status and the preferred ISO notation. > > > > Typing an extra three or four characters, if it will prevent recurrance > > of this thread, will be well worth the effort. > > > > The phrases "proposed standard" and "draft standard" (which are > > not proper ISO-ese anyway) should be avoided in this context, > > since, as Harald pointed out, they have a very specific IETF > > meaning from RFC 2026. > > > > Now, can we please move on to *substantive* discussion? > > > > Randy, ltru co-chair > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 30 19:20:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAFOd-00020g-TC; Tue, 30 Aug 2005 19:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAFOc-00020D-Qp for ltru@megatron.ietf.org; Tue, 30 Aug 2005 19:20:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17073 for ; Tue, 30 Aug 2005 19:19:59 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAFQG-000143-0U for ltru@ietf.org; Tue, 30 Aug 2005 19:21:44 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7UNJiBN262730 for ; Tue, 30 Aug 2005 19:19:48 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7UNK0Wa386144 for ; Tue, 30 Aug 2005 17:20:00 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7UNJiQO031661 for ; Tue, 30 Aug 2005 17:19:44 -0600 Received: from [127.0.0.1] (sig-9-48-109-192.mts.ibm.com [9.48.109.192]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7UNJcgf031414; Tue, 30 Aug 2005 17:19:39 -0600 Message-ID: <4314E98A.9080404@icu-project.org> Date: Tue, 30 Aug 2005 16:19:38 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Debbie Garside Subject: Re: [Ltru] what to call 639-6 References: <200508302042.j7UKgaIh027701@smtp-los03.proxy.aol.com> In-Reply-To: <200508302042.j7UKgaIh027701@smtp-los03.proxy.aol.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Sounds good. Mark Debbie Garside wrote: > Hi > > As the editor of this document, I am happy to go with > "ISO AWI 639-6" and will keep this WG informed of any change in status. > > Kind regards > > > Debbie Garside > > >>-----Original Message----- >>From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >>Randy Presuhn >>Sent: 30 August 2005 21:17 >>To: LTRU Working Group >>Subject: Re: [Ltru] what to call 639-6 >> >>Hi - >> >> >>>From: "Addison Phillips" >>>To: "LTRU Working Group" >>>Sent: Tuesday, August 30, 2005 12:44 PM >>>Subject: RE: FW: [Ltru] Re:what to call 639-6 (was STD) >>> >> >>>Since we don't reference it normatively anywhere, >>>this strikes me as a non-issue. Why don't we call it "ISO 639-6"? >>>If anyone was unaware or confused previously, they now know >>>from this thread what its current status is. >>>It strikes me as counter productive to refer to it constantly as >>>"the ISO Approved Work Item ISO 639-6 which isn't a standard quite yet". >> >>... >> >>Since this topic keeps recurring in various forms, as a WG co-chair >>(who happens to have spent some time in ISO-land) I *strongly* >>suggest that we use the nomenclature suggested by Peter Constable, >>modulo Harald Alvestrand's comments, as it would be more precise >>while not being onerous. Specifically, as that work progresses, we should >>refer to "ISO AWI 639-6", or, if there actually is a working draft, to >>"ISO/WD 639-6". As that work progresses, if we still need to talk >>about, for example, the work at the Draft International Standard >>stage, "ISO DIS 639-6" would do nicely. I'm sure we can trust >>WG participants who are currently active in ISO work to keep us >>appraised of the current status and the preferred ISO notation. >> >>Typing an extra three or four characters, if it will prevent recurrance >>of this thread, will be well worth the effort. >> >>The phrases "proposed standard" and "draft standard" (which are >>not proper ISO-ese anyway) should be avoided in this context, >>since, as Harald pointed out, they have a very specific IETF >>meaning from RFC 2026. >> >>Now, can we please move on to *substantive* discussion? >> >>Randy, ltru co-chair >> >> >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 01:21:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAL2I-0002pv-DV; Wed, 31 Aug 2005 01:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAL2F-0002pm-LM for ltru@megatron.ietf.org; Wed, 31 Aug 2005 01:21:20 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02950 for ; Wed, 31 Aug 2005 01:21:18 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EAL1b-00078d-K0 for ltru@lists.ietf.org; Wed, 31 Aug 2005 07:20:39 +0200 Received: from c-180-160-4.hh.dial.de.ignite.net ([62.180.160.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Aug 2005 07:20:39 +0200 Received: from nobody by c-180-160-4.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Aug 2005 07:20:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 31 Aug 2005 07:17:01 +0200 Organization: Lines: 45 Message-ID: <43153D4D.4974@xyzzy.claranet.de> References: <4amb37$aq7och@mx02.mrf.mail.rcn.net> <200508302159.59785@mail.blilly.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-4.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: [Ltru] Re: Last Call: 'Tags for Identifying Languages' to BCP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Bruce Lilly wrote: > Encoded-words have several characteristics, one of which is > limited length (in octets). That has two implications w.r.t. > script: > 1. specifying script explicitly is unnecessary; it can be > determined from the charset (always specified in an > encoded-word) and the specific octets of the encoded text > (ISO-8859-1 is latin script, KOI8 is Cyrillic, etc.). It's not that easy for UTF-8. We need the ugly scripts after Unicode replaced the old charsets (the "implicit script" info of most legacy charsets). Where that's irrelevant you can of course use language tags without script, the draft encourages "taggers" that more is not always better, quite the contrary. > 2. an encoded-word has limited space available. [...snipped...] Yes, we calculated "the most perverse tag" in all dimensions especially for 2231, I knew that you would kill the draft otherwise... ;-) Compare figure 7 in chapter 4.3.1. > without a concrete specification for negotiation, it is not > possible to fully assess the proposed syntax changes. Maybe you can convince the PTB to delay the "last call" until the matching draft is ready, but I doubt it. And I disagree that it's impossible to judge the "data structure" (tags) now, the syntax is rather simple. For a general idea what the matching draft probably will be you could read draft-ietf-ltru-matching-03. >> the WG Chairs and the responsible AD did a very good job. > As an affected party, I disagree. Then let's agree to disagree and / or be more specific: 3934 is rather new, and it was used, all parts of it incl. appeal. IMNSHO it would be desastrous to abuse RfC 3934 as some kind of killfiling-by-rough-consensus. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 01:45:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EALPF-0000Z8-QQ; Wed, 31 Aug 2005 01:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EALPD-0000Yy-U3 for ltru@megatron.ietf.org; Wed, 31 Aug 2005 01:45:04 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03797 for ; Wed, 31 Aug 2005 01:45:02 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050831054422.PAGP12165.mta10.adelphia.net@DEWELL>; Wed, 31 Aug 2005 01:44:22 -0400 Message-ID: <007a01c5adef$047829a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" , References: <20050830101246.DVZO9239.mta8.adelphia.net@megatron.ietf.org> Date: Tue, 30 Aug 2005 22:44:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA03797 Cc: Brian E Carpenter Subject: [Ltru] Re: STD X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Brian E Carpenter wrote: > Whatever one may or may not think of Jefsey's logic, please > confine yourselves to discussing his logic and not the man > himself. I am perfectly willing to do this as long as the rules are enforced equally. Nobody is better, or more prolific, at inserting "Jefsey the man" into these discussions than Jefsey himself. In particular, in respect of Brian's request, I would hope to hear no more of the following self-referential topics: 1) "Franglish" or other reference to broken English -- as an excuse for misunderstanding others, or being misunderstood by others. That is not the problem at all. 2) "non-English mother-tongue speaker" -- as indication of a superior, more cosmopolitan, or more thoughtful world-view. Not all native English speakers are monolingual, and not all are culturally isolated as implied. 3) "27 years working with networks" -- as evidence of greater expertise than others with respect to the Internet and language tagging. Each of us has a r=C3=A9sum=C3=A9, but what we have to say *now* is the important= thing, not what we have done in the past. 4) "defending the needs of users" against, supposedly, the narrow interests of big business -- as justification for blocking an evolutionary change to existing language tagging practice. In addition, I would hope that a policy against ad-hominem arguments directed against others would apply as well. Discussions that call a person's motives into question on the basis of the company or organization for which he or she works should be restricted. Each individual's logic should be discussed and debated, not the man himself (or woman herself), and not the company he or she keeps. Participation in the IETF, as we have heard, is by individuals, not by representatives or delegates or spokesmen. Let's focus on the drafts, and have a productive discussion. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 01:54:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EALYX-0003Jk-Mt; Wed, 31 Aug 2005 01:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EALYV-0003JZ-Is for ltru@megatron.ietf.org; Wed, 31 Aug 2005 01:54:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04221 for ; Wed, 31 Aug 2005 01:54:37 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EALaB-0002Fr-6t for ltru@ietf.org; Wed, 31 Aug 2005 01:56:24 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 22:54:28 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 22:54:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] what to call 639-6 Date: Tue, 30 Aug 2005 22:54:27 -0700 Message-ID: Thread-Topic: [Ltru] what to call 639-6 Thread-Index: AcWtn6bQYaYDbKfHRiaMuG8NhZMIowAA2z0gAACD31AAEUKgkA== From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 05:54:27.0969 (UTC) FILETIME=[72CC8710:01C5ADF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Debbie Garside > For some reason the word "pedantic" springs to mind! ;-) Well, I suppose we could use "pendantic" as a code word for "ISO AWI 639-6" or "ISO/WD 639-6". But don't you think that's overly cryptic? Peter :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 03:15:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAMoo-0007Ce-Mp; Wed, 31 Aug 2005 03:15:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAMon-0007CW-GK for ltru@megatron.ietf.org; Wed, 31 Aug 2005 03:15:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05115 for ; Wed, 31 Aug 2005 03:15:31 -0400 (EDT) Received: from rly-ip08.mx.aol.com ([64.12.138.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAMqK-0004H1-Ub for ltru@ietf.org; Wed, 31 Aug 2005 03:17:19 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip08.mx.aol.com (8.12.11/8.12.11) with ESMTP id j7V7ESEj000311; Wed, 31 Aug 2005 03:14:31 -0400 Received: from DEBHOME (ACCBA57F.ipt.aol.com [172.203.165.127]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j7V7E8p5014804; Wed, 31 Aug 2005 03:14:08 -0400 Message-Id: <200508310714.j7V7E8p5014804@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , "'LTRU Working Group'" Subject: RE: [Ltru] what to call 639-6 Date: Wed, 31 Aug 2005 08:14:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWtn6bQYaYDbKfHRiaMuG8NhZMIowAA2z0gAACD31AAEUKgkAAELlyA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hmmm... yes... I think you could be right! > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Peter Constable > Sent: 31 August 2005 06:54 > To: LTRU Working Group > Subject: RE: [Ltru] what to call 639-6 > > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf > Of > > Debbie Garside > > > > For some reason the word "pedantic" springs to mind! ;-) > > Well, I suppose we could use "pendantic" as a code word for "ISO AWI > 639-6" or "ISO/WD 639-6". But don't you think that's overly cryptic? > > > > Peter :-) > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 03:27:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAN0Z-0002Fp-3A; Wed, 31 Aug 2005 03:27:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAN0X-0002Bo-4F for ltru@megatron.ietf.org; Wed, 31 Aug 2005 03:27:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05559 for ; Wed, 31 Aug 2005 03:27:38 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAN2C-0004ZJ-FP for ltru@ietf.org; Wed, 31 Aug 2005 03:29:26 -0400 Received: from h-68-166-38-22.snvacaid.dynamic.covad.net ([68.166.38.22] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EAN0T-0005rB-00 for ltru@ietf.org; Wed, 31 Aug 2005 03:27:37 -0400 Message-ID: <002101c5adfd$bb84c960$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 31 Aug 2005 00:29:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.4 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] decorum X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - I'm apalled by how low the signal-to-noise ratio has become on this mailing list. Before your next posting to the ltru WG mailing list, please take the time to read the four-page RFC 3184 ftp://ftp.rfc-editor.org/in-notes/rfc3184.txt In particular, I want no more statements of the form "Mommy, Beldar poked me". If someone is being a jerk, it will be obvious to the rest of us, and it does absolutely no good to return the favor. Indeed, retaliation makes it all the more difficult to discipline the original offender. STICK TO THE TECHNICAL SUBSTANCE OF THE DISCUSSION. IF THERE IS NO TECHNICAL SUBSTANCE, DON'T BOTHER RESPONDING. IF IT'S OFF-TOPIC, CONSIDER WHETHER YOUR RESPONSE WILL BRING US ANY CLOSER TO COMPLETING OUR WORK. Is this so difficult? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 14:26:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXHu-0000lO-8m; Wed, 31 Aug 2005 14:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXHt-0000lA-8t; Wed, 31 Aug 2005 14:26:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04650; Wed, 31 Aug 2005 14:26:15 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAXJd-0005af-Fm; Wed, 31 Aug 2005 14:28:09 -0400 Received: from h-68-166-189-43.snvacaid.dynamic.covad.net ([68.166.189.43] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EAXHg-0002nG-00; Wed, 31 Aug 2005 14:26:04 -0400 Message-ID: <007d01c5ae59$b9f6aa80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 31 Aug 2005 11:28:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: gen-art@ietf.org, Elwyn Davies , Mary Barnes Subject: [Ltru] Fw: Gen-art review: draft-ietf-ltru-registry-12.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - I'd like to thank the GenART reviewer for the thoughtful comments. I'm forwarding the comments to the ltru working group for discussion in conjunction with the other IETF last call comments that have been received. If any of the people on the Cc: list would like to listen in on the WG's discussion, I suggest subscribing to the ltru working group mailing list at https://www1.ietf.org/mailman/listinfo/ltru Since there are many issues raised in this review, I can't promise that a Cc: list would survive the many threads that will probably be spawned. The editors are hereby directed to correct the purely editorial typos in their working copies. In anticipation that this review might result in DISCUSS comments from the IESG, for the issues which involve the substance of the document, or result in signficant change (such as reorganization or rewriting whole paragraphs), I'd like to see working group discussion and agreement on (1) whether changes are needed, and (2) agreement on specific replacement text. Working group participants note well: it's OK to disagree with a review comment; in such case a result might be a purely editorial clarification of what was intended, rather than an actual subtantive change. For my own sanity, I'll be entering these (and other IETF last call issues) into the issue tracker at https://rt.psg.com/ (user and password "ietf"), In the meantime, in responding to the comments that are not purely editorial, PLEASE use an appropriate subject line (e.g. "subtag reviewer recall") and limit each of your postings to a single issue. Though this results in higher message volume, it makes the discussion *much* easier to follow. Randy, ltru co-chair ----- Original Message ----- From: "Elwyn Davies" To: Cc: "Randy Presuhn" ; "Mary Barnes" ; "Scott Hollenbeck" ; ; Sent: Wednesday, August 31, 2005 7:19 AM Subject: Gen-art review: draft-ietf-ltru-registry-12.txt Background for those on the CC list, who may be unaware of GenART: GenART is the Area Review Team for the General Area of the IETF. We advise the General Area Director (i.e. the IETF/IESG chair) by providing more in depth reviews than he could do himself of documents that come up for final decision in IESG telechat. I was selected as the GenART member to review this document. Below is my review, which was written specifically with an eye to the GenART process, but since I believe that it will be useful to have these comments more widely distributed, others outside the GenART group are being copied. Document: draft-ietf-ltru-registry-12.txt Intended Status: BCP Shepherding AD: Scott Hollenbeck PROTO Shepherd: Randy Presuhn Review Trigger: IETF Last Call, ends 6 September 2005 Summary: This document is generally in good shape and well written but is not yet ready for publication. It has in my view a couple of minor process issues that need to be sorted out, one issue which seems to be an unnecessary irritant, some minor restructuring to improve readability and some editorial nits. I would also suggest that areas which may be affected by the introduction of 'extended language subtags' are all revisited to ensure that they properly and clearly cover both the initial case (with no extlang subtags) and the future development including one or more extlang subtags. [My initial impression was that the new idea was not as well integrated as it might have been but on re-reading most of the 'issues' have become clear... hence the suggestion that some additional clarity might be gained by a few extra words in relevant areas.] Transition issue: I think the transition from RFC3066 to the subtag registry needs a little more attention. There are a few words in s3.7, but I think the process might need a little fleshing out. In particular suggestions about ensuring there is not an interregnum with no reviewer in place (they are appointed by different authorities) and giving notice of the changeover (e.g., a number of weeks after the publication of the RFC(s)). In principle the changeover should be seamless but it would probably be good to have the initial registry in place (i.e., translated from the initial state RFC) and reviewed before it becomes authoritative. Recall of Language Subtag Reviewer: Given recent IETF discussions, should the document set out ways for the community to request the unfrocking (recall) of the Language Subtag Reviewer in the event of non-performance or repeated inappropriate decisions? Also would it be appropriate to suggest that the IESG document the name of the reviewer on their web page and periodically reconfirm the appointment? I don't think a fixed term appointment would be desirable, and I agree this is not something for nomcom to be involved in. Irritant: Early in the document it is specifically set out that language tags are case insensitive and should be normally represented in lower case. However, because the corresponding ISO documents use title case for script codes and upper case for region codes, this representation has been used in the normative text (ss 2.2.3 and 2.2.4) and registrations of these codes MUST use this representation (s3.2). This struck me as unecessary bureaucracy for registrants. It would seem to me enough to RECOMMEND that the registry conform to the case patterns and otherwise allow users and registrants whatever case they choose. Restructuring: The Language Tag Reviewer of RFC3066 has metamorphosed into a Language Subtag Reviewer. The subtag reviewer is first mentioned in s3.1 in a rather sudden way. The role of the reviewer is scattered across several sub-sections of s3 and how the person is appointed is buried in depths of s3.4 (Registration Procedure for Subtags). I think it would be valuable to summarize the role of the Language Subtag Reviewer and set out how this person is appointed (and maybe also recalled) right at the start of s3. Update Load There has been considerable debate about the expected load of updating the registry especially over the next couple of years. It might be worth adding some notes about the expected load and emphasising that such changes will have minimal impact on applications due to the backwards compatibility rules. Review: ======= Substantive: ============ s2.2.2: This states that an extended language subtag '...MUST include exactly one prefix field....' . The implication of this seems to be that the same extended language subtag cannot be used for multiple primary languages. I think it would be worth spelling out the reasoning behind this as it might be seen as an undesirable restriction. A pointer to this discussion in the 'Prefix' discussion in s3.1 would then help. s2.2.3: item 3: Is it desirable to have normative text using other than lower case for tag identifiers? See also s3.2 comment below. s2.2.4: Item 6 and (maybe) examples: as per s2.2.3, Item 3. s2.2.4: Item 3A: [Out of interest...] Why not economic groupings? Their bureaucrats have languages all their own ;-) . s3.1: the 'Language Subtag Reviewer' makes a rather sudden entry here. 'Who is this person?' the naive reader may ask. It would be a good idea to add a sub-section before 3.1 introducing the Language Subtag Reviewer, summarizing the role and setting out how the person is appointed (and recalled) - move text from s3.4. Since the the Language Tag Reviewer (a wholly different person ;-) ) from RFC3066 is also mentioned, it is important that it is clear which one is referred to - the full title should be used throughout (e.g. several incomplete instances in s3.4) - a handy abbreviation (although LSR is already taken in MPLS land) might shorten the document a bit! s3.1: para 1, last sentence: Given that *all* the initial records are in the initial registry load RFC, maintaining registration forms for just the RFC3066 subset seems a little odd. Why not all or none, since presumably they can be created by an automated script? s3.1: para after ABNF: Numeric ranges? This section talks about alphabetic ranges such as c..k. Is this supposed to cover numeric ranges as well? s3.1: definition of 'Tag' field: Presumably the syntax of a tag of type 'grandfathered' is restricted to the 'grandfathered' format from s2.1? (Looking at the initial state it may well be) Given that grandfathered items are all in the initial registry load this is perhaps academic. s3.1: para after definition of 'Added': the 'MUST' requirement to follow the capitalization conventions of the underlying standards in the registry seems a little strange given earlier views on interpretation of case. s3.1: definition of 'Prefix': I think a more formal (ABNF) description of the possible values might help. Presumably an 'extlang' can have a primary language tag and up to 2 other extlangs and a 'variant' can have a complete language (including up to 3 extlangs)and possibly a script and/or a region. s3.1: discussion of 'Preferred-Value': '...SHOULD be preferred when selected language tags.' appears to be garbled... I am not sure exactly what is intended. s3.2: last para: the requirement to get the case pattern of a certain subset of tags right seems an unecessary hurdle - the registry can enforce this if it seems really desirable. s3.3: Item 12: Is there any chance that the meaning of the grandfathered tag and the (later) combination of valid subtags might be different? If so what should happen? The reviewer should take a view on this I think! Should there be some words on how to process such overlaps in the validating processor section? s3.4: para 2 and para next but one after Figure 5: At first sight these paras appear to conflict? the second one appears to indicate that type 'extlang' subtags can be registered but they are not mentioned in the first one. Presumably this is because extlang is currently reserved for future use, but it would be good to mention this in para 2. Text saying something like 'extlang records will also be able to be registered by this process when they are introduced'. s3.4: para next but one after Figure 5: I cannot find the requirement that Variant subtags have at least one Prefix field: extlang fields are explicitly specified to have exactly one but Variants appear to be allowed 0 or more. s4.1: Item 2: example: I am not clear how one would represent the combination of latin and braille since only one script subtag seems to be allowed. Maybe there is a special subtag for the combination? or is it intended that both complete tags are used? Editorial: ========== Global: Some pieces of ABNF are described as 'Figures' but others aren't, and not all figures have titles (e.g., Figure 4, and Figure 5). [Figure 2 and Figure 3 don't appear as such] s2.2.6: Item 2: 'below' should point to s2.2.7. s2.2.8: In reading the document for the first time, I found the use of 'redundant' as a type slightly confusing. It would help to clarify things if text was added (probably in this section) to the effect that subtags that don't come from RFC3066 but eventually become 'redundant' are NOT handled by the use of the 'redundant' type but by marking them as deprecated and (maybe) adding a Preferred-Value as described in s3.1. s3.1: Seems rather long... maybe could be broken up into subsections. s3.1: para next but one after definition of 'Added': s/registered written or transcribed/registered that has been written or transcribed into/ (repeated in s3.4 in para about 'description' field.) s3.1: discussion of Comment field: s/frowned on/strongly NOT RECOMMENDED/ s3.2: s/an change/a change/ s3.2: para before figure 4: is the intent of this that each email contains insertion or modification data for exactly one record? if so it should say this explicitly... at present it is sort of implied in that it appears to forbid mixing of INSERT and MODIFY but doesn't say just one record per email. s5.1 is slightly more precise - it says 'enclosed record' (singular). s3.5: last but one para: This paragraph talks about matching... there is a draft (draft-ietf-ltru-matching) specifically about this matter which does not appear to be referenced. Should this matter be discussed? s3.7: Presumably the language tag reviewer here the RFC3066 person rather than the language subtag reviewer defined in this draft? this should be made crystal clear! it might well be the same person but handover (or retitling) and authority are missing from this document! _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 15:36:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYNf-0002qU-KQ; Wed, 31 Aug 2005 15:36:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYNc-0002qI-Bi for ltru@megatron.ietf.org; Wed, 31 Aug 2005 15:36:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08842 for ; Wed, 31 Aug 2005 15:36:13 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAYPP-0007UB-GN for ltru@ietf.org; Wed, 31 Aug 2005 15:38:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 12:36:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2005 12:36:00 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA9121E@irvmbxw01.quest.com> Thread-Topic: Gen-art review: draft-ietf-ltru-registry-12.txt Thread-Index: AcWuXJ0BQ7Nn7+UrT7eVA/ngH6u2HQABi/Cw From: "Addison Phillips" To: "Randy Presuhn" , "Elwyn Davies" X-OriginalArrivalTime: 31 Aug 2005 19:36:01.0244 (UTC) FILETIME=[37E161C0:01C5AE63] X-Spam-Score: 0.0 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group , mark.davis@us.ibm.com Subject: [Ltru] RE: Gen-art review: draft-ietf-ltru-registry-12.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org I fully agree with the need to clarify as appropriate. I'm going to do the following: 1. Forward my responses to Elwyn to the LTRU list unexpurgated. 2. Break down the results into separate items (I need this for my = modification list too), with Elwyn's original issue, my response, and = the associated change(s) in the editor's copy that I propose to make. = Randy, if you can "rt" each one from that and we'll be in sync. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2005?8?31? 11:50 > To: Addison Phillips; Elwyn Davies > Cc: Martin Duerst; mark.davis@us.ibm.com; Scott Hollenbeck; gen- > art@ietf.org > Subject: Re: Gen-art review: draft-ietf-ltru-registry-12.txt >=20 > Hi - >=20 > I'd like to hold the rest of the follow-up discussion on the ltru WG > mailing list, > in order to ensure that there are no surprises and to keep a record = there. > Addison, could you include excerpts from your discussion with Elwyn in > your > postings to ltru? That way we should be able to quickly come to = consensus > on any changes or clarifications to the text. I imagine that gen- > art@ietf.org is > not terribly interested in our discussion, just the final results. >=20 > I view any case where we need to explain something to a reviewer as > a demonstration that the material in question is not sufficiently = clear, > so > I think that even in the cases where no change is technically needed, = we > should consider making the text even clearer or more explicit. >=20 > Randy, ltru co-chair > ----- Original Message ----- > From: "Elwyn Davies" > To: "Addison Phillips" > Cc: ; "Randy Presuhn" = ; > "Scott Hollenbeck" ; > > Sent: Wednesday, August 31, 2005 10:41 AM > Subject: Re: Gen-art review: draft-ietf-ltru-registry-12.txt >=20 >=20 > > Thanks for the swift responses - I am fine with most of your = responses > > and I hope they get into a revision. > > > > A couple of responses/clarifications below... > > > > Regards, > > Elwyn > > > > > > > > Addison Phillips wrote: > > > > >Thanks for this note. I'm not sure of what the procedural handling = of > these comments should be. Many of these comments would make > useful additions to the document. > > > > > >My main question (Randy) is: what is the process impact of > incorporating changes based on these comments? > > > > > >Response comments below are personal, of course. I expect I'll be > sending these to the list also after Randy forwards the > message. > > > > > >Addison > > > > > >Addison P. Phillips > > >Globalization Architect, Quest Software > > >Chair, W3C Internationalization Core Working Group > > > > > >Internationalization is not a feature. > > >It is an architecture. > > > > > > > > > > > >>-----Original Message----- > > >>From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > > >>Sent: 2005?8?31? 7:19 > > >>To: gen-art@ietf.org > > >>Cc: Randy Presuhn; Mary Barnes; Scott Hollenbeck; > mark.davis@us.ibm.com; > > >>Addison Phillips > > >>Subject: Gen-art review: draft-ietf-ltru-registry-12.txt > > >> > > >>Background for those on the CC list, who may be unaware of GenART: > > >>GenART is the Area Review Team for the General Area of the IETF. = We > > >>advise the General Area Director (i.e. the IETF/IESG chair) by > providing > > >>more in depth reviews than he could do himself of documents that = come > up > > >>for final decision in IESG telechat. I was selected as the GenART > > >>member to review this document. Below is my review, which was = written > > >>specifically with an eye to the GenART process, but since I = believe > that > > >>it will be useful to have these comments more widely distributed, > others > > >>outside the GenART group are being copied. > > >> > > >> > > >> > > <> > > > > >>Transition issue: > > >>I think the transition from RFC3066 to the subtag registry needs a > > >>little more attention. There are a few words in s3.7, but I think = the > > >>process might need a little fleshing out. In particular = suggestions > > >>about ensuring there is not an interregnum with no reviewer in = place > > >>(they are appointed by different authorities) and giving notice of = the > > >>changeover (e.g., a number of weeks after the publication of the > > >>RFC(s)). In principle the changeover should be seamless but it = would > > >>probably be good to have the initial registry in place (i.e., > translated > > >>from the initial state RFC) and reviewed before it becomes > authoritative. > > >> > > >> > > >[Addison Phillips] > > > > > >It may appear a bit vague. In practice, however, there has only = ever > been one Language (Sub)tag Reviewer, Michael Everson. The > change in appointing authorities was suggested by the IESG itself, so > there should be no interregnum. There are rules in place to > deal with any in-process registrations, which would mark the main = problem > source. > > > > > > > > Assuming Michael is willing to continue you shouldn't have any = problems > > with personnel, but it still might be worth asking your AD and IANA > > about phase-in process, and seeing if there is anything worth > documenting. > > > > <> > > > > >>Irritant: > > >>Early in the document it is specifically set out that language = tags > are > > >>case insensitive and should be normally represented in lower case. > > >> > > >> > > >[Addison Phillips] > > > > > >This is NOT correct. It actually says: > > > > > >-- > > ><> > > > > > You are of course right! This was mostly provoked by thinking how = messy > > these strings looked with the assortment of case. Your suggestion = later > > on covers most of the irritation. > > > > <> > > > > > <> > > > > > >>s2.2.2: This states that an extended language subtag '...MUST = include > > >>exactly one prefix field....' . The implication of this seems to = be > > >>that the same extended language subtag cannot be used for multiple > > >>primary languages. I think it would be worth spelling out the > reasoning > > >>behind this as it might be seen as an undesirable restriction. > > >> > > >> > > >[Addison Phillips] > > > > > >That's not just the implication, but entirely the idea. Extended > language subtags are meant to be closely associated with the > primary language subtag. Since they occur directly after the primary > language subtag, there are no intervening values or additional > variants that can creep into their prefix (requiring more than one = prefix). > In addition, extlangs are expected to be used with the > ISO 639-3 concept of "macro languages" (languages that contain other > languages). An example of this is the spoken variation Mandarin > Chinese. The tag for this would be zh-cmn and "cmn" would be an = extlang > with a prefix of "zh". It doesn't make sense to use "cmn" > with a different language prefix, such as "de" or "ja". > > > > > > > > > > > What I was perhaps not saying as well as I could was: does this > > therefore mean that you can't use the same extlang tag for different > > primary languages? the example you give could be a case in point - > > 'cmn' is a reasonable abbreviation for 'common' and the space is not > > that big - or are you allowed to register the same extlang with a > > different prefix in a separate record? I wasn't sure if this would = be > > allowed. > > > > <> > > > > >>pointer to this discussion in the 'Prefix' discussion in s3.1 = would > then > > >>help. > > >> > > >> > > >[Addison Phillips] > > > > > >Good idea. > > > > > > > > >>s3.1: para 1, last sentence: Given that *all* the initial records = are > > >>in the initial registry load RFC, maintaining registration forms = for > > >>just the RFC3066 subset seems a little odd. Why not all or none, > since > > >>presumably they can be created by an automated script? > > >> > > >> > > >[Addison Phillips] > > > > > >The RFC 3066 registry is maintained in perpetuity and its format is > different than that of the draft. That registry is maintained > as an obsolete reference (it just seemed prudent to do so). Generating > many registration forms for the initial set, however, doesn't > seem that useful. > > > > > > > > If the RFC3066 registry is being maintained then it seems like not > > generating any registration forms at all would be the right answer. > > > > <> > > > > >>s3.1: definition of 'Prefix': I think a more formal (ABNF) = description > > >>of the possible values might help. Presumably an 'extlang' can = have a > > >>primary language tag and up to 2 other extlangs and a 'variant' = can > have > > >>a complete language (including up to 3 extlangs)and possibly a = script > > >>and/or a region. > > >> > > >> > > >[Addison Phillips] > > > > > >Would that really add anything to the document? It would be easy to = do, > yes, but I'm not sure that it is unclear as written. > > > > > > > > I think the words are currently a little woolly and you are reliant = to > > an extent on the examples. If a formal definition is easy I would = add > it. > > > > >>s3.1: discussion of 'Preferred-Value': '...SHOULD be preferred = when > > >>selected language tags.' appears to be garbled... I am not sure > exactly > > >>what is intended. > > >> > > >> > > >[Addison Phillips] > > > > > >The value in the record that contains a 'Preferred-Value' field = should > be replaced with the value in the Preferred-Value. That > is, Preferred-Value is how a subtag is deprecated in favor of a = different > subtag. The cases where this applies are then enumerated. > Some textual tweaking to make this clearer is probably called for. > > > > > > > > I know what the overall intent is... I just cannot parse this = sentence > > at all! Something about generating or constructing language tags = was > > intended I suspect. > > > > >>s3.2: last para: the requirement to get the case pattern of a = certain > > >>subset of tags right seems an unecessary hurdle - the registry can > > >>enforce this if it seems really desirable. > > >> > > >> > > >[Addison Phillips] > > > > > >That requirement could be relaxed to SHOULD. > > > > > > > > I think that would relieve most of my irritation. > > > > < > > > > >>s3.4: para 2 and para next but one after Figure 5: At first sight > these > > >>paras appear to conflict? the second one appears to indicate that > type > > >>'extlang' subtags can be registered but they are not mentioned in = the > > >>first one. Presumably this is because extlang is currently = reserved > for > > >>future use, but it would be good to mention this in para 2. Text > saying > > >>something like 'extlang records will also be able to be registered = by > > >>this process when they are introduced'. > > >> > > >> > > >[Addison Phillips] > > > > > >The key word in para 2 is "independently". There are also = registrations > that can occur due to standards body activity (assignment > of a new ISO 3166 code, for example). > > > > > >Extlangs cannot currently be registered, as noted they are = reserved. > However, the rules for extlangs are spelled out so that > implementations can take them into account. Therefore it is important = to > point out that they must have a Prefix again here. The > conditional nature of their existence might be better mirrored by the > wording, though. > > > > > > > > When I first read through the document I was very confused by the = talk > > about what needed to be done with extlangs after Figure 5 but = nothing > > about them earlier. I think you probably need a few extra words to > > distinguish the two cases.. independently didn't trigger the right = chain > > of thought for me. > > > > >>s3.4: para next but one after Figure 5: I cannot find the = requirement > > >>that Variant subtags have at least one Prefix field: extlang = fields > are > > >>explicitly specified to have exactly one but Variants appear to be > > >>allowed 0 or more. > > >> > > >> > > >[Addison Phillips] > > > > > >You are looking at the requirement. Perhaps the matching = requirement in > Section 2.2.4 should be strengthened from MAY to MUST? > > > > > > > > [I think you mean s2.2.5]: To make it consistent, yes, the s2.2.5 > > statement should be "MUST include one or more 'Prefix' fields". > > > > <> > > > > >>s2.2.8: In reading the document for the first time, I found the = use of > > >>'redundant' as a type slightly confusing. It would help to = clarify > > >>things if text was added (probably in this section) to the effect = that > > >>subtags that don't come from RFC3066 but eventually become = 'redundant' > > >>are NOT handled by the use of the 'redundant' type but by marking = them > > >>as deprecated and (maybe) adding a Preferred-Value as described in > s3.1. > > >> > > >> > > >[Addison Phillips] > > > > > >That isn't correct. Redundant tags are values registered under RFC = 3066 > that are now defined by (separate) subtags in the > registry. For example, the tag "zh-Hant" is now defined by the subtags > 'zh' and 'Hant' and thus is redundant. It is NOT deprecated > and never may be deprecated by rule. This is in contrast to = grandfathered > values, which may sometimes become redundant (the only > time a zebra in this zoo may change its stripes) or may be deprecated, = but > which always maintain their validity. > > > > > >What's important to note is that redundant tags are valid. > > > > > > > > This is maybe a US/UK usage problem! I was reading 'redundant' in = the > > 'no longer wanted' sense rather than purely the 'alternative among = more > > or less equals'. A few words to make it clear what is going on = would > > help others to avoid the same trap. > > <> > > > > >>s3.1: para next but one after definition of 'Added': s/registered > > >>written or transcribed/registered that has been written or = transcribed > > >>into/ (repeated in s3.4 in para about 'description' field.) > > >> > > >> > > >[Addison Phillips] > > > > > >Yes. Actually a comma is missing there, but your version works too. > > > > > > > > I thought there was a comma missing initially but > > s/registered/registered,/ completely alters the sense. > > <> > > > > >>s3.5: last but one para: This paragraph talks about matching... = there > > >>is a draft (draft-ietf-ltru-matching) specifically about this = matter > > >>which does not appear to be referenced. Should this matter be > discussed? > > >> > > >> > > >[Addison Phillips] > > > > > >Do you mean Section 3.6? Matching is actually mentioned = sporadically > here and there in the document in a general manner. The > first occurrence is in S2.1, para2. Matching here can be assumed to = mean > RFC 3066-style prefix matching. The matching draft > enumerates other schemes too. > > > > > >Originally the matching draft was part of this document, please = note. > > > > > > > > [yes I meant s3.6]. I haven't read the matching draft in detail, = but I > > guess it would be useful to refer to it somewhere around s2.1. > > > > <> > > Regards, > > Elwyn >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 15:37:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYOk-0003SC-0i; Wed, 31 Aug 2005 15:37:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYOj-0003Q5-00 for ltru@megatron.ietf.org; Wed, 31 Aug 2005 15:37:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08911 for ; Wed, 31 Aug 2005 15:37:22 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAYQV-0007XA-WC for ltru@ietf.org; Wed, 31 Aug 2005 15:39:17 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 12:37:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2005 12:37:13 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91222@irvmbxw01.quest.com> Thread-Topic: Gen-art review: draft-ietf-ltru-registry-12.txt Thread-Index: AcWuNuK1nzfTAnp9RjWeeulr0CxpKgABAUeAAAoaJoA= From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 19:37:14.0009 (UTC) FILETIME=[63407090:01C5AE63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 Content-Transfer-Encoding: quoted-printable Subject: [Ltru] FW: Gen-art review: draft-ietf-ltru-registry-12.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Here was my original response to Elwyn for reference only. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Addison Phillips > Sent: 2005?8?31? 9:03 > To: 'Elwyn Davies'; gen-art@ietf.org > Cc: Randy Presuhn; Mary Barnes; Scott Hollenbeck; = mark.davis@us.ibm.com > Subject: RE: Gen-art review: draft-ietf-ltru-registry-12.txt >=20 > Thanks for this note. I'm not sure of what the procedural handling of > these comments should be. Many of these comments would make useful > additions to the document. >=20 > My main question (Randy) is: what is the process impact of = incorporating > changes based on these comments? >=20 > Response comments below are personal, of course. I expect I'll be = sending > these to the list also after Randy forwards the message. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > > Sent: 2005?8?31? 7:19 > > To: gen-art@ietf.org > > Cc: Randy Presuhn; Mary Barnes; Scott Hollenbeck; = mark.davis@us.ibm.com; > > Addison Phillips > > Subject: Gen-art review: draft-ietf-ltru-registry-12.txt > > > > Background for those on the CC list, who may be unaware of GenART: > > GenART is the Area Review Team for the General Area of the IETF. We > > advise the General Area Director (i.e. the IETF/IESG chair) by = providing > > more in depth reviews than he could do himself of documents that = come up > > for final decision in IESG telechat. I was selected as the GenART > > member to review this document. Below is my review, which was = written > > specifically with an eye to the GenART process, but since I believe = that > > it will be useful to have these comments more widely distributed, = others > > outside the GenART group are being copied. > > > > Document: draft-ietf-ltru-registry-12.txt > > Intended Status: BCP > > Shepherding AD: Scott Hollenbeck > > PROTO Shepherd: Randy Presuhn > > Review Trigger: IETF Last Call, ends 6 September 2005 > > > > Summary: > > This document is generally in good shape and well written but is not = yet > > ready for publication. It has in my view a couple of minor process > > issues that need to be sorted out, one issue which seems to be an > > unnecessary irritant, some minor restructuring to improve = readability > > and some editorial nits. I would also suggest that areas which may = be > > affected by the introduction of 'extended language subtags' are all > > revisited to ensure that they properly and clearly cover both the > > initial case (with no extlang subtags) and the future development > > including one or more extlang subtags. [My initial impression was = that > > the new idea was not as well integrated as it might have been but on > > re-reading most of the 'issues' have become clear... hence the > > suggestion that some additional clarity might be gained by a few = extra > > words in relevant areas.] > > > > Transition issue: > > I think the transition from RFC3066 to the subtag registry needs a > > little more attention. There are a few words in s3.7, but I think = the > > process might need a little fleshing out. In particular suggestions > > about ensuring there is not an interregnum with no reviewer in place > > (they are appointed by different authorities) and giving notice of = the > > changeover (e.g., a number of weeks after the publication of the > > RFC(s)). In principle the changeover should be seamless but it = would > > probably be good to have the initial registry in place (i.e., = translated > > from the initial state RFC) and reviewed before it becomes = authoritative. > [Addison Phillips] >=20 > It may appear a bit vague. In practice, however, there has only ever = been > one Language (Sub)tag Reviewer, Michael Everson. The change in = appointing > authorities was suggested by the IESG itself, so there should be no > interregnum. There are rules in place to deal with any in-process > registrations, which would mark the main problem source. > > > > Recall of Language Subtag Reviewer: > > Given recent IETF discussions, should the document set out ways for = the > > community to request the unfrocking (recall) of the Language Subtag > > Reviewer in the event of non-performance or repeated inappropriate > > decisions? Also would it be appropriate to suggest that the IESG > > document the name of the reviewer on their web page and periodically > > reconfirm the appointment? I don't think a fixed term appointment = would > > be desirable, and I agree this is not something for nomcom to be > > involved in. > [Addison Phillips] >=20 > Those are good questions. I'm not sure if there are any similar = practices > anywhere else in the IETF. Presumably the appointing authority is the > unappointing authority too and the body to whom to appeal? > > > > Irritant: > > Early in the document it is specifically set out that language tags = are > > case insensitive and should be normally represented in lower case. > [Addison Phillips] >=20 > This is NOT correct. It actually says: >=20 > -- > However, in the tags defined by this document, the uppercase US-ASCII > letters in the range 'A' through 'Z' are considered equivalent and = mapped > directly to their US-ASCII lowercase equivalents in the range 'a' = through > 'z'. Thus the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or = "mN- > cYrL-Mn" (or any other combination) and each of these variations = conveys > the same meaning: Mongolian written in the Cyrillic script as used in > Mongolia. > -- >=20 > The document goes to great lengths to say that case distinctions must = not > be considered when processing language tags. However, the canonical = form > follows the ISO standards: this practice has long standing in the > community at large and is enshrined in Section 4.4 ("Canonicalization = of > Language Tags") thusly: >=20 > -- > When performing canonicalization of language tags, processors MAY > regularize the case of the subtags (that is, this process is = OPTIONAL), > following the case used in the registry. Note that this corresponds to = the > following casing rules: uppercase all non-initial two-letter subtags; > titlecase all non-initial four-letter subtags; lowercase everything = else. > -- >=20 > > However, because the corresponding ISO documents use title case for > > script codes and upper case for region codes, this representation = has > > been used in the normative text (ss 2.2.3 and 2.2.4) and = registrations > > of these codes MUST use this representation (s3.2). This struck me = as > > unecessary bureaucracy for registrants. It would seem to me enough = to > > RECOMMEND that the registry conform to the case patterns and = otherwise > > allow users and registrants whatever case they choose. > [Addison Phillips] >=20 > This bureaucracy only applies to independently registered values > (variants), in practice, and isn't binding on those. The underlying = ISO > standards, when mirrored, won't be an issue, since their assignments = will > already come in the canonical format. > > > > Restructuring: > > The Language Tag Reviewer of RFC3066 has metamorphosed into a = Language > > Subtag Reviewer. The subtag reviewer is first mentioned in s3.1 in = a > > rather sudden way. The role of the reviewer is scattered across = several > > sub-sections of s3 and how the person is appointed is buried in = depths > > of s3.4 (Registration Procedure for Subtags). I think it would be > > valuable to summarize the role of the Language Subtag Reviewer and = set > > out how this person is appointed (and maybe also recalled) right at = the > > start of s3. > [Addison Phillips] >=20 > That seems like a sensible thing to do. > > > > Update Load > > There has been considerable debate about the expected load of = updating > > the registry especially over the next couple of years. It might be > > worth adding some notes about the expected load and emphasising that > > such changes will have minimal impact on applications due to the > > backwards compatibility rules. > [Addison Phillips] >=20 > Aside from revisions to document in question, the day-to-day activity = of > the ietf-languages list has been fairly steady over its lifetime. That > isn't expected to change. The number of ISO 639-1/-2 and ISO 3166 > registrations in a given year has tended to be small (on the order of = a > dozen relevant changes per year). The addition of ISO 639-3 or ISO = 639-6 > has been considered as a possibility, but that would be a special case = and > be coincident with a revision of the document. > > > > > > Review: > > =3D=3D=3D=3D=3D=3D=3D > > > > Substantive: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > s2.2.2: This states that an extended language subtag '...MUST = include > > exactly one prefix field....' . The implication of this seems to be > > that the same extended language subtag cannot be used for multiple > > primary languages. I think it would be worth spelling out the = reasoning > > behind this as it might be seen as an undesirable restriction. > [Addison Phillips] >=20 > That's not just the implication, but entirely the idea. Extended = language > subtags are meant to be closely associated with the primary language > subtag. Since they occur directly after the primary language subtag, = there > are no intervening values or additional variants that can creep into = their > prefix (requiring more than one prefix). In addition, extlangs are > expected to be used with the ISO 639-3 concept of "macro languages" > (languages that contain other languages). An example of this is the = spoken > variation Mandarin Chinese. The tag for this would be zh-cmn and "cmn" > would be an extlang with a prefix of "zh". It doesn't make sense to = use > "cmn" with a different language prefix, such as "de" or "ja". >=20 > A > > pointer to this discussion in the 'Prefix' discussion in s3.1 would = then > > help. > [Addison Phillips] >=20 > Good idea. > > > > s2.2.3: item 3: Is it desirable to have normative text using other = than > > lower case for tag identifiers? See also s3.2 comment below. > [Addison Phillips] >=20 > Yes. See above. >=20 > > s2.2.4: Item 6 and (maybe) examples: as per s2.2.3, Item 3. > [Addison Phillips] >=20 > Same. > > > > s2.2.4: Item 3A: [Out of interest...] Why not economic groupings? = Their > > bureaucrats have languages all their own ;-) . > [Addison Phillips] >=20 > The economic groupings are things like "10 poorest countries" and "10 > richest countries" and the like. The economic groupings don't describe > stable regional entities and might be controversial, especially in > language tags ("French as spoken in poor countries") >=20 > > > > s3.1: the 'Language Subtag Reviewer' makes a rather sudden entry = here. > > 'Who is this person?' the naive reader may ask. It would be a good = idea > > to add a sub-section before 3.1 introducing the Language Subtag > > Reviewer, summarizing the role and setting out how the person is > > appointed (and recalled) - move text from s3.4. Since the the = Language > > Tag Reviewer (a wholly different person ;-) ) from RFC3066 is also > > mentioned, it is important that it is clear which one is referred to = - > > the full title should be used throughout (e.g. several incomplete > > instances in s3.4) - a handy abbreviation (although LSR is already > > taken in MPLS land) might shorten the document a bit! > [Addison Phillips] >=20 > A very little bit :-). >=20 > A small subsection could be created to deal with this issue. > > > > s3.1: para 1, last sentence: Given that *all* the initial records = are > > in the initial registry load RFC, maintaining registration forms for > > just the RFC3066 subset seems a little odd. Why not all or none, = since > > presumably they can be created by an automated script? > [Addison Phillips] >=20 > The RFC 3066 registry is maintained in perpetuity and its format is > different than that of the draft. That registry is maintained as an > obsolete reference (it just seemed prudent to do so). Generating many > registration forms for the initial set, however, doesn't seem that = useful. > > > > s3.1: para after ABNF: Numeric ranges? This section talks about > > alphabetic ranges such as c..k. Is this supposed to cover numeric > > ranges as well? > [Addison Phillips] >=20 > Yes. It is an oversight (since there are no numeric ranges initially). > > > > s3.1: definition of 'Tag' field: Presumably the syntax of a tag of = type > > 'grandfathered' is restricted to the 'grandfathered' format from = s2.1? > > (Looking at the initial state it may well be) Given that = grandfathered > > items are all in the initial registry load this is perhaps academic. > [Addison Phillips] >=20 > Tag applies to both grandfathered and redundant types, although the = ANBF > for 'grandfathered' turns out to describe both accurately. > > > > s3.1: para after definition of 'Added': the 'MUST' requirement to = follow > > the capitalization conventions of the underlying standards in the > > registry seems a little strange given earlier views on = interpretation of > > case. > [Addison Phillips] >=20 > This has the effect of making the registry follow the optional > canonicalization rules quoted earlier and making the registry mirror = the > ISO standards more closely. The case in the registry has no impact on > interpretation of tags: these are defined to be case insensitive as = you > note, but the common practice has been to use the ISO case forms. > > > > s3.1: definition of 'Prefix': I think a more formal (ABNF) = description > > of the possible values might help. Presumably an 'extlang' can have = a > > primary language tag and up to 2 other extlangs and a 'variant' can = have > > a complete language (including up to 3 extlangs)and possibly a = script > > and/or a region. > [Addison Phillips] >=20 > Would that really add anything to the document? It would be easy to = do, > yes, but I'm not sure that it is unclear as written. > > > > s3.1: discussion of 'Preferred-Value': '...SHOULD be preferred when > > selected language tags.' appears to be garbled... I am not sure = exactly > > what is intended. > [Addison Phillips] >=20 > The value in the record that contains a 'Preferred-Value' field should = be > replaced with the value in the Preferred-Value. That is, = Preferred-Value > is how a subtag is deprecated in favor of a different subtag. The = cases > where this applies are then enumerated. Some textual tweaking to make = this > clearer is probably called for. > > > > s3.2: last para: the requirement to get the case pattern of a = certain > > subset of tags right seems an unecessary hurdle - the registry can > > enforce this if it seems really desirable. > [Addison Phillips] >=20 > That requirement could be relaxed to SHOULD. > > > > s3.3: Item 12: Is there any chance that the meaning of the = grandfathered > > tag and the (later) combination of valid subtags might be different? = If > > so what should happen? The reviewer should take a view on this I > > think! Should there be some words on how to process such overlaps = in > > the validating processor section? > [Addison Phillips] >=20 > There is a very small chance of this happening, so it should be dealt = with > as noted. > > > > s3.4: para 2 and para next but one after Figure 5: At first sight = these > > paras appear to conflict? the second one appears to indicate that = type > > 'extlang' subtags can be registered but they are not mentioned in = the > > first one. Presumably this is because extlang is currently reserved = for > > future use, but it would be good to mention this in para 2. Text = saying > > something like 'extlang records will also be able to be registered = by > > this process when they are introduced'. > [Addison Phillips] >=20 > The key word in para 2 is "independently". There are also = registrations > that can occur due to standards body activity (assignment of a new ISO > 3166 code, for example). >=20 > Extlangs cannot currently be registered, as noted they are reserved. > However, the rules for extlangs are spelled out so that = implementations > can take them into account. Therefore it is important to point out = that > they must have a Prefix again here. The conditional nature of their > existence might be better mirrored by the wording, though. > > > > s3.4: para next but one after Figure 5: I cannot find the = requirement > > that Variant subtags have at least one Prefix field: extlang fields = are > > explicitly specified to have exactly one but Variants appear to be > > allowed 0 or more. > [Addison Phillips] >=20 > You are looking at the requirement. Perhaps the matching requirement = in > Section 2.2.4 should be strengthened from MAY to MUST? > > > > s4.1: Item 2: example: I am not clear how one would represent the > > combination of latin and braille since only one script subtag seems = to > > be allowed. Maybe there is a special subtag for the combination? or = is > > it intended that both complete tags are used? > [Addison Phillips] >=20 > If runs of text may be marked up individually, then they should be. > Otherwise the language tag indicates the intended audience of the = content > (which will be one or the other). You could equally say the same of a > document that mixes English and French or en-US and en-GB. >=20 > Yes, multilingual documents (and not just multi-script documents) = exist > which do not have any particular primary language that is "above" the > others, but that is a limitation of the headers or other meta-data > structures that use language tags, not the tags themselves. Tags = identify > one language unambiguously, not multiple languages or language forms = mixed > together. The higher level protocol must deal with that. >=20 > See for example the section "Two types of language declaration" in: >=20 > http://www.w3.org/International/tutorials/language-decl/ >=20 > > > > Editorial: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Global: Some pieces of ABNF are described as 'Figures' but others > > aren't, and not all figures have titles (e.g., Figure 4, and Figure = 5). > > [Figure 2 and Figure 3 don't appear as such] > [Addison Phillips] >=20 > This is the result of xml2rfc. I'll check it. > > > > s2.2.6: Item 2: 'below' should point to s2.2.7. > [Addison Phillips] >=20 > Yes. > > > > s2.2.8: In reading the document for the first time, I found the use = of > > 'redundant' as a type slightly confusing. It would help to clarify > > things if text was added (probably in this section) to the effect = that > > subtags that don't come from RFC3066 but eventually become = 'redundant' > > are NOT handled by the use of the 'redundant' type but by marking = them > > as deprecated and (maybe) adding a Preferred-Value as described in = s3.1. > [Addison Phillips] >=20 > That isn't correct. Redundant tags are values registered under RFC = 3066 > that are now defined by (separate) subtags in the registry. For = example, > the tag "zh-Hant" is now defined by the subtags 'zh' and 'Hant' and = thus > is redundant. It is NOT deprecated and never may be deprecated by = rule. > This is in contrast to grandfathered values, which may sometimes = become > redundant (the only time a zebra in this zoo may change its stripes) = or > may be deprecated, but which always maintain their validity. >=20 > What's important to note is that redundant tags are valid. > > > > s3.1: Seems rather long... maybe could be broken up into = subsections. > [Addison Phillips] >=20 > That might be possible. > > > > s3.1: para next but one after definition of 'Added': s/registered > > written or transcribed/registered that has been written or = transcribed > > into/ (repeated in s3.4 in para about 'description' field.) > [Addison Phillips] >=20 > Yes. Actually a comma is missing there, but your version works too. > > > > s3.1: discussion of Comment field: s/frowned on/strongly NOT > RECOMMENDED/ > [Addison Phillips] >=20 > It's okay to make this normative, but the idea was to give a sense of = the > likely behavior of the community. It is possible that a long screed = might > be justified from time to time. > > > > s3.2: s/an change/a change/ > [Addison Phillips] >=20 > Yes. > > > > s3.2: para before figure 4: is the intent of this that each email > > contains insertion or modification data for exactly one record? if = so > > it should say this explicitly... at present it is sort of implied in > > that it appears to forbid mixing of INSERT and MODIFY but doesn't = say > > just one record per email. > [Addison Phillips] >=20 > It should say one per email. >=20 > > s5.1 is slightly more precise - it says 'enclosed record' = (singular). > [Addison Phillips] >=20 > Yep. > > > > s3.5: last but one para: This paragraph talks about matching... = there > > is a draft (draft-ietf-ltru-matching) specifically about this matter > > which does not appear to be referenced. Should this matter be = discussed? > [Addison Phillips] >=20 > Do you mean Section 3.6? Matching is actually mentioned sporadically = here > and there in the document in a general manner. The first occurrence is = in > S2.1, para2. Matching here can be assumed to mean RFC 3066-style = prefix > matching. The matching draft enumerates other schemes too. >=20 > Originally the matching draft was part of this document, please note. > > > > s3.7: Presumably the language tag reviewer here the RFC3066 person > > rather than the language subtag reviewer defined in this draft? = this > > should be made crystal clear! it might well be the same person but > > handover (or retitling) and authority are missing from this = document! > > > [Addison Phillips] Yes, I agree. Although I believe we expect it to be = the > same person at the moment. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 15:50:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYb6-0006yI-3r; Wed, 31 Aug 2005 15:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYaw-0006uB-M3 for ltru@megatron.ietf.org; Wed, 31 Aug 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09482 for ; Wed, 31 Aug 2005 15:50:00 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAYck-0007rD-EL for ltru@ietf.org; Wed, 31 Aug 2005 15:51:55 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 12:49:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2005 12:49:51 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91240@irvmbxw01.quest.com> Thread-Topic: Gen-art review: draft-ietf-ltru-registry-12.txt Thread-Index: AcWuUxHLEVknpW9xSe6JSWjpi3fQgAAArs8gAAPRnOA= From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 19:49:51.0798 (UTC) FILETIME=[26EDDD60:01C5AE65] X-Spam-Score: 0.0 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Content-Transfer-Encoding: quoted-printable Subject: [Ltru] FW: Gen-art review: draft-ietf-ltru-registry-12.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org And my follow up. Next comes the individual threads. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Addison Phillips > Sent: 2005?8?31? 12:49 > To: 'Elwyn Davies' > Cc: gen-art@ietf.org; Randy Presuhn; Scott Hollenbeck; > mark.davis@us.ibm.com > Subject: RE: Gen-art review: draft-ietf-ltru-registry-12.txt >=20 > Responses follow. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. > > > > Thanks for the swift responses - I am fine with most of your = responses > > and I hope they get into a revision. > > > > A couple of responses/clarifications below... > > > > Regards, > > Elwyn > > > > <> > > > > >>Transition issue: > > >>I think the transition from RFC3066 to the subtag registry needs a > > >>little more attention. There are a few words in s3.7, but I think = the > > >>process might need a little fleshing out. In particular = suggestions > > >>about ensuring there is not an interregnum with no reviewer in = place > > >>(they are appointed by different authorities) and giving notice of = the > > >>changeover (e.g., a number of weeks after the publication of the > > >>RFC(s)). In principle the changeover should be seamless but it = would > > >>probably be good to have the initial registry in place (i.e., > translated > > >>from the initial state RFC) and reviewed before it becomes > authoritative. > > >> > > >> > > >[Addison Phillips] > > > > > >It may appear a bit vague. In practice, however, there has only = ever > been > > one Language (Sub)tag Reviewer, Michael Everson. The change in > appointing > > authorities was suggested by the IESG itself, so there should be no > > interregnum. There are rules in place to deal with any in-process > > registrations, which would mark the main problem source. > > > > > > > > Assuming Michael is willing to continue you shouldn't have any = problems > > with personnel, but it still might be worth asking your AD and IANA > > about phase-in process, and seeing if there is anything worth > documenting. > [Addison Phillips] >=20 > I agree. > > > > <> > > > > > <> > > > > > >>s2.2.2: This states that an extended language subtag '...MUST = include > > >>exactly one prefix field....' . The implication of this seems to = be > > >>that the same extended language subtag cannot be used for multiple > > >>primary languages. I think it would be worth spelling out the > reasoning > > >>behind this as it might be seen as an undesirable restriction. > > >> > > >> > > >[Addison Phillips] > > > > > >That's not just the implication, but entirely the idea. Extended > language > > subtags are meant to be closely associated with the primary language > > subtag. Since they occur directly after the primary language subtag, > there > > are no intervening values or additional variants that can creep into > their > > prefix (requiring more than one prefix). In addition, extlangs are > > expected to be used with the ISO 639-3 concept of "macro languages" > > (languages that contain other languages). An example of this is the > spoken > > variation Mandarin Chinese. The tag for this would be zh-cmn and = "cmn" > > would be an extlang with a prefix of "zh". It doesn't make sense to = use > > "cmn" with a different language prefix, such as "de" or "ja". > > > > > > > > > > > What I was perhaps not saying as well as I could was: does this > > therefore mean that you can't use the same extlang tag for different > > primary languages? the example you give could be a case in point - > > 'cmn' is a reasonable abbreviation for 'common' and the space is not > > that big - or are you allowed to register the same extlang with a > > different prefix in a separate record? I wasn't sure if this would = be > > allowed. > [Addison Phillips] >=20 > Yes. The meaning of any subtag is defined and can't change in = different > contexts. That is, '1996' is subtag describing a particular = orthography of > German. It can't just be used as an arbitrary year number. The subtag > 'cmn' will mean "Mandarin Chinese" and won't have any meaning with a > different macro language. > > > > > > <> > > > > >>s3.1: definition of 'Prefix': I think a more formal (ABNF) = description > > >>of the possible values might help. Presumably an 'extlang' can = have a > > >>primary language tag and up to 2 other extlangs and a 'variant' = can > have > > >>a complete language (including up to 3 extlangs)and possibly a = script > > >>and/or a region. > > >> > > >> > > >[Addison Phillips] > > > > > >Would that really add anything to the document? It would be easy to = do, > > yes, but I'm not sure that it is unclear as written. > [Addison Phillips] >=20 > It's easy to do and therefore probably worthwhile. I'll work up a = version. > > > > >>s3.1: discussion of 'Preferred-Value': '...SHOULD be preferred = when > > >>selected language tags.' appears to be garbled... I am not sure > exactly > > >>what is intended. > > >> > > >> > > >[Addison Phillips] > > > > > >The value in the record that contains a 'Preferred-Value' field = should > be > > replaced with the value in the Preferred-Value. That is, = Preferred-Value > > is how a subtag is deprecated in favor of a different subtag. The = cases > > where this applies are then enumerated. Some textual tweaking to = make > this > > clearer is probably called for. > > > > > > > > I know what the overall intent is... I just cannot parse this = sentence > > at all! Something about generating or constructing language tags = was > > intended I suspect. > [Addison Phillips] >=20 > Yes. I'll propose suitable text modifications. > > > > >>s3.4: para 2 and para next but one after Figure 5: At first sight > these > > >>paras appear to conflict? the second one appears to indicate that > type > > >>'extlang' subtags can be registered but they are not mentioned in = the > > >>first one. Presumably this is because extlang is currently = reserved > for > > >>future use, but it would be good to mention this in para 2. Text > saying > > >>something like 'extlang records will also be able to be registered = by > > >>this process when they are introduced'. > > >> > > >> > > >[Addison Phillips] > > > > > >The key word in para 2 is "independently". There are also = registrations > > that can occur due to standards body activity (assignment of a new = ISO > > 3166 code, for example). > > > > > >Extlangs cannot currently be registered, as noted they are = reserved. > > However, the rules for extlangs are spelled out so that = implementations > > can take them into account. Therefore it is important to point out = that > > they must have a Prefix again here. The conditional nature of their > > existence might be better mirrored by the wording, though. > > > > > > > > When I first read through the document I was very confused by the = talk > > about what needed to be done with extlangs after Figure 5 but = nothing > > about them earlier. I think you probably need a few extra words to > > distinguish the two cases.. independently didn't trigger the right = chain > > of thought for me. > [Addison Phillips] >=20 > Actually, I think this point was raised before. I'll propose suitable = text > for the "independent" part and the extlang material. > > > > >>s3.4: para next but one after Figure 5: I cannot find the = requirement > > >>that Variant subtags have at least one Prefix field: extlang = fields > are > > >>explicitly specified to have exactly one but Variants appear to be > > >>allowed 0 or more. > > >> > > >> > > >[Addison Phillips] > > > > > >You are looking at the requirement. Perhaps the matching = requirement in > > Section 2.2.4 should be strengthened from MAY to MUST? > > > > > > > > [I think you mean s2.2.5]: To make it consistent, yes, the s2.2.5 > > statement should be "MUST include one or more 'Prefix' fields". > [Addison Phillips] >=20 > I do mean 2.2.5. > > > > <> > > > > >>s2.2.8: In reading the document for the first time, I found the = use of > > >>'redundant' as a type slightly confusing. It would help to = clarify > > >>things if text was added (probably in this section) to the effect = that > > >>subtags that don't come from RFC3066 but eventually become = 'redundant' > > >>are NOT handled by the use of the 'redundant' type but by marking = them > > >>as deprecated and (maybe) adding a Preferred-Value as described in > s3.1. > > >> > > >> > > >[Addison Phillips] > > > > > >That isn't correct. Redundant tags are values registered under RFC = 3066 > > that are now defined by (separate) subtags in the registry. For = example, > > the tag "zh-Hant" is now defined by the subtags 'zh' and 'Hant' and = thus > > is redundant. It is NOT deprecated and never may be deprecated by = rule. > > This is in contrast to grandfathered values, which may sometimes = become > > redundant (the only time a zebra in this zoo may change its stripes) = or > > may be deprecated, but which always maintain their validity. > > > > > >What's important to note is that redundant tags are valid. > > > > > > > > This is maybe a US/UK usage problem! I was reading 'redundant' in = the > > 'no longer wanted' sense rather than purely the 'alternative among = more > > or less equals'. A few words to make it clear what is going on = would > > help others to avoid the same trap. > > <> > [Addison Phillips] >=20 > No, the usage is meant to be similar. The redundant tags are "no = longer > wanted" in that all of their subtags are now separately defined. A > grandfathered tag must be handled in an implementation by an = exceptional > process--there is a list of grandfathered values used to validate = these > tags--while redundant tags are described entirely by various subtags = in > the registry and the registry entries can be entirely ignored by an > implementation. The entry merely exists so that people know where the = RFC > 3066 registered value went. > > > > >>s3.1: para next but one after definition of 'Added': s/registered > > >>written or transcribed/registered that has been written or = transcribed > > >>into/ (repeated in s3.4 in para about 'description' field.) > > >> > > >> > > >[Addison Phillips] > > > > > >Yes. Actually a comma is missing there, but your version works too. > > > > > > > > I thought there was a comma missing initially but > > s/registered/registered,/ completely alters the sense. > > <> > [Addison Phillips] >=20 > Yes, and appropriately too! >=20 > Here is the corrected sentence: > -- > At least one of the 'Description' fields MUST contain a description of = the > tag being registered, written or transcribed into the Latin script; > -- >=20 > The point is at least one description must be in the Latin script, not > that the tag must be in the Latin script (of course it is---> it is > required to be in our particular subset of ASCII). > > > > >>s3.5: last but one para: This paragraph talks about matching... = there > > >>is a draft (draft-ietf-ltru-matching) specifically about this = matter > > >>which does not appear to be referenced. Should this matter be > discussed? > > >> > > >> > > >[Addison Phillips] > > > > > >Do you mean Section 3.6? Matching is actually mentioned = sporadically > here > > and there in the document in a general manner. The first occurrence = is > in > > S2.1, para2. Matching here can be assumed to mean RFC 3066-style = prefix > > matching. The matching draft enumerates other schemes too. > > > > > >Originally the matching draft was part of this document, please = note. > > > > > > > > [yes I meant s3.6]. I haven't read the matching draft in detail, = but I > > guess it would be useful to refer to it somewhere around s2.1. > > > We could as easily (actually, since it's an RFC and draft-matching is = a > draft, more easily) refer to matching as described in RFC 3066, RFC = 3282 > and, of course, RFC 2616 Section 14.4. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 16:54:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZbB-0000sO-VJ; Wed, 31 Aug 2005 16:54:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZb7-0000ql-BG for ltru@megatron.ietf.org; Wed, 31 Aug 2005 16:54:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14412 for ; Wed, 31 Aug 2005 16:54:13 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAZcu-000220-8g for ltru@ietf.org; Wed, 31 Aug 2005 16:56:09 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 13:53:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 13:53:56 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA912BE@irvmbxw01.quest.com> Thread-Topic: Transition rules (gen-art #1) Thread-Index: AcWubhNrbsF3OpSXT/yboZN2qEF9mg== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 20:53:56.0657 (UTC) FILETIME=[1AA4CA10:01C5AE6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Elwyn Davies Subject: [Ltru] Transition rules (gen-art #1) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2096994258==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============2096994258== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IFRyYW5zaXRpb24gaXNzdWU6DQo+ID4gSSB0aGluayB0aGUgdHJhbnNpdGlvbiBmcm9tIFJG QzMwNjYgdG8gdGhlIHN1YnRhZyByZWdpc3RyeSBuZWVkcyBhIA0KPiA+IGxpdHRsZSBtb3JlIGF0 dGVudGlvbi4gIFRoZXJlIGFyZSBhIGZldyB3b3JkcyBpbiBzMy43LCBidXQgSSB0aGluayANCj4g PiB0aGUgcHJvY2VzcyBtaWdodCBuZWVkIGEgbGl0dGxlIGZsZXNoaW5nIG91dC4gIEluIHBhcnRp Y3VsYXIgDQo+ID4gc3VnZ2VzdGlvbnMgYWJvdXQgZW5zdXJpbmcgdGhlcmUgaXMgbm90IGFuIGlu dGVycmVnbnVtIHdpdGggbm8gDQo+ID4gcmV2aWV3ZXIgaW4gcGxhY2UgKHRoZXkgYXJlIGFwcG9p bnRlZCBieSBkaWZmZXJlbnQgYXV0aG9yaXRpZXMpIGFuZCANCj4gPiBnaXZpbmcgbm90aWNlIG9m IHRoZSBjaGFuZ2VvdmVyIChlLmcuLCBhIG51bWJlciBvZiB3ZWVrcyBhZnRlciB0aGUgDQo+ID4g cHVibGljYXRpb24gb2YgdGhlIFJGQyhzKSkuICBJbiBwcmluY2lwbGUgdGhlIGNoYW5nZW92ZXIg c2hvdWxkIGJlIA0KPiA+IHNlYW1sZXNzIGJ1dCBpdCB3b3VsZCBwcm9iYWJseSBiZSBnb29kIHRv IGhhdmUgdGhlIGluaXRpYWwgcmVnaXN0cnkgDQo+ID4gaW4gcGxhY2UgKGkuZS4sIHRyYW5zbGF0 ZWQgZnJvbSB0aGUgaW5pdGlhbCBzdGF0ZSBSRkMpIGFuZCByZXZpZXdlZCBiZWZvcmUgaXQgYmVj b21lcyBhdXRob3JpdGF0aXZlLg0KPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gDQo+IEl0IG1heSBh cHBlYXIgYSBiaXQgdmFndWUuIEluIHByYWN0aWNlLCBob3dldmVyLCB0aGVyZSBoYXMgb25seSBl dmVyIA0KPiBiZWVuIG9uZSBMYW5ndWFnZSAoU3ViKXRhZyBSZXZpZXdlciwgTWljaGFlbCBFdmVy c29uLiBUaGUgY2hhbmdlIGluIA0KPiBhcHBvaW50aW5nIGF1dGhvcml0aWVzIHdhcyBzdWdnZXN0 ZWQgYnkgdGhlIElFU0cgaXRzZWxmLCBzbyB0aGVyZSANCj4gc2hvdWxkIGJlIG5vIGludGVycmVn bnVtLiBUaGVyZSBhcmUgcnVsZXMgaW4gcGxhY2UgdG8gZGVhbCB3aXRoIGFueSANCj4gaW4tcHJv Y2VzcyByZWdpc3RyYXRpb25zLCB3aGljaCB3b3VsZCBtYXJrIHRoZSBtYWluIHByb2JsZW0gc291 cmNlLg0KDQpQcm9wb3NlZCByZXNvbHV0aW9uOg0KDQpUbyBjbGVhciB0aGUgaW50ZXJyZWdudW0g cHJvYmxlbSwgSSBwcm9wb3NlIGluc2VydGluZyB0aGUgZm9sbG93aW5nIHRleHQgaW4gU2VjdGlv biAzLjcgKGluc2VydGlvbiBtYXJrZWQgd2l0aCA+Pj4gYW5kIDw8PCk6DQoNCi0tDQpSZWdpc3Ry YXRpb25zIHRoYXQgYXJlIGluIHByb2Nlc3MgdW5kZXIgdGhlIHJ1bGVzIGRlZmluZWQgaW4gPHhy ZWYgdGFyZ2V0PSJSRkMzMDY2Ij48L3hyZWY+IHdoZW4gdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVk DQogIE1BWSBiZSBjb21wbGV0ZWQgdW5kZXIgdGhlIGZvcm1lciBydWxlcywgYXQgdGhlIGRpc2Ny ZXRpb24gb2YgdGhlIExhbmd1YWdlIFRhZyBSZXZpZXdlciA+Pj4gKGFzIGRlc2NyaWJlZCBpbiA8 eHJlZiB0YXJnZXQ9IlJGQzMwNjYiPjwveHJlZj4pLiBVbnRpbCB0aGUgSUVTRyBvZmZpY2lhbGx5 IGFwcG9pbnRzIGEgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLCB0aGUgZXhpc3RpbmcgTGFuZ3Vh Z2UgVGFnIFJldmlld2VyIHdpbGwgc2VydmUgYXMgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdl ci4gPDw8IA0KLS0NCg0KVG8gYWRkcmVzcyB0aGUgdGltaW5nIHByb2JsZW0gSSBwcm9wb3NlIGlu c2VydGluZyB0aGUgZm9sbG93aW5nIHRleHQgaW4gU2VjdGlvbiAzLjcgYXMgc2hvd246DQoNCi0t DQpVcG9uIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIHRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgY29udGFpbmluZyB0aGUgdmFyaW91cyBzdWJ0YWdz IGluaXRpYWxseSB2YWxpZCBpbiBhIGxhbmd1YWdlIHRhZyBpcyBuZWNlc3NhcnkuIFRoaXMgY29s bGVjdGlvbiBvZiBzdWJ0YWdzLCBhbG9uZyB3aXRoIGEgZGVzY3JpcHRpb24gb2YgdGhlIHByb2Nl c3MgdXNlZCB0byBjcmVhdGUgaXQsIGlzIGRlc2NyaWJlZCBieSA8eHJlZiB0YXJnZXQ9ImluaXRp YWwtcmVnaXN0cnkiPjwveHJlZj4uID4+PiBJQU5BIHdpbGwgcHVibGlzaCB0aGUgbmV3IHJlZ2lz dHJ5IGFzIGRlc2NyaWJlZCBpbiB0aGF0IGRvY3VtZW50LCBhdCB3aGljaCBwb2ludCB0aGUgbWFp bnRlbmFuY2UgcnVsZXMgYW5kIHJlZ2lzdHJhdGlvbiBwcm9jZXNzZXMgZGVzY3JpYmVkIGluIHRo aXMgZG9jdW1lbnQgd2lsbCBiZSBhdmFpbGFibGUgZm9yIG5ldyByZWdpc3RyYXRpb25zIG9yIHVw ZGF0ZXMuIDw8PA0KLS0NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNo aXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzND IEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5v cmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJl Lg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0K --===============2096994258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2096994258==-- From ltru-bounces@ietf.org Wed Aug 31 16:55:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZc0-000164-T3; Wed, 31 Aug 2005 16:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZbw-00014z-83 for ltru@megatron.ietf.org; Wed, 31 Aug 2005 16:55:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14452 for ; Wed, 31 Aug 2005 16:55:05 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAZdk-000256-Pq for ltru@ietf.org; Wed, 31 Aug 2005 16:57:01 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 13:54:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 13:54:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA912C3@irvmbxw01.quest.com> Thread-Topic: Recall of the LSR (gen-art #2) Thread-Index: AcWubjgmjTOZLzHxRo2EpTdBAGNOGQ== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 20:54:58.0235 (UTC) FILETIME=[3F58D8B0:01C5AE6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Elwyn Davies Subject: [Ltru] Recall of the LSR (gen-art #2) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1874355624==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1874355624== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IFJlY2FsbCBvZiBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXI6DQo+ID4gR2l2ZW4gcmVjZW50 IElFVEYgZGlzY3Vzc2lvbnMsIHNob3VsZCB0aGUgZG9jdW1lbnQgc2V0IG91dCB3YXlzIGZvciAN Cj4gPiB0aGUgY29tbXVuaXR5IHRvIHJlcXVlc3QgdGhlIHVuZnJvY2tpbmcgKHJlY2FsbCkgb2Yg dGhlIExhbmd1YWdlIA0KPiA+IFN1YnRhZyBSZXZpZXdlciBpbiB0aGUgZXZlbnQgb2Ygbm9uLXBl cmZvcm1hbmNlIG9yIHJlcGVhdGVkIGluYXBwcm9wcmlhdGUNCj4gPiBkZWNpc2lvbnM/ICAgQWxz byB3b3VsZCBpdCBiZSBhcHByb3ByaWF0ZSB0byBzdWdnZXN0IHRoYXQgdGhlIElFU0cNCj4gPiBk b2N1bWVudCB0aGUgbmFtZSBvZiB0aGUgcmV2aWV3ZXIgb24gdGhlaXIgd2ViIHBhZ2UgYW5kIHBl cmlvZGljYWxseSANCj4gPiByZWNvbmZpcm0gdGhlIGFwcG9pbnRtZW50PyAgSSBkb24ndCB0aGlu ayBhIGZpeGVkIHRlcm0gYXBwb2ludG1lbnQgDQo+ID4gd291bGQgYmUgZGVzaXJhYmxlLCBhbmQg SSBhZ3JlZSB0aGlzIGlzIG5vdCBzb21ldGhpbmcgZm9yIG5vbWNvbSB0byANCj4gPiBiZSBpbnZv bHZlZCBpbi4NCj4gW0FkZGlzb24gUGhpbGxpcHNdDQo+IA0KPiBUaG9zZSBhcmUgZ29vZCBxdWVz dGlvbnMuIEknbSBub3Qgc3VyZSBpZiB0aGVyZSBhcmUgYW55IHNpbWlsYXIgDQo+IHByYWN0aWNl cyBhbnl3aGVyZSBlbHNlIGluIHRoZSBJRVRGLiBQcmVzdW1hYmx5IHRoZSBhcHBvaW50aW5nIA0K PiBhdXRob3JpdHkgaXMgdGhlIHVuYXBwb2ludGluZyBhdXRob3JpdHkgdG9vIGFuZCB0aGUgYm9k eSB0byB3aG9tIHRvID5hcHBlYWw/DQoNClRob3NlIGFyZSBzdGlsbCBnb29kIHF1ZXN0aW9ucy4g Q29tbWVudHM/DQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlv biBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFp ciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3 dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBm ZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============1874355624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1874355624==-- From ltru-bounces@ietf.org Wed Aug 31 17:04:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZl1-0003Pm-CR; Wed, 31 Aug 2005 17:04:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZkw-0003Ow-8Y for ltru@megatron.ietf.org; Wed, 31 Aug 2005 17:04:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14824 for ; Wed, 31 Aug 2005 17:04:23 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAZmj-0002IC-V9 for ltru@ietf.org; Wed, 31 Aug 2005 17:06:19 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 14:04:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 14:04:14 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA912D6@irvmbxw01.quest.com> Thread-Topic: case canonicalization in registry (gen-art #3) Thread-Index: AcWub4OMtZV4xuKJRW+0J/2NEudOSA== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 21:04:14.0757 (UTC) FILETIME=[8B0F5D50:01C5AE6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Elwyn Davies Subject: [Ltru] case canonicalization in registry (gen-art #3) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1746428147==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1746428147== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IElycml0YW50Og0KPiA+IEVhcmx5IGluIHRoZSBkb2N1bWVudCBpdCBpcyBzcGVjaWZpY2Fs bHkgc2V0IG91dCB0aGF0IGxhbmd1YWdlIHRhZ3MgDQo+ID4gYXJlIGNhc2UgaW5zZW5zaXRpdmUg YW5kIHNob3VsZCBiZSBub3JtYWxseSByZXByZXNlbnRlZCBpbiBsb3dlciBjYXNlLg0KPiBbQWRk aXNvbiBQaGlsbGlwc10NCj4gDQo+IFRoaXMgaXMgTk9UIGNvcnJlY3QuIEl0IGFjdHVhbGx5IHNh eXM6DQo+IA0KPiAtLQ0KPiBIb3dldmVyLCBpbiB0aGUgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9j dW1lbnQsIHRoZSB1cHBlcmNhc2UgVVMtQVNDSUkgDQo+IGxldHRlcnMgaW4gdGhlIHJhbmdlICdB JyB0aHJvdWdoICdaJyBhcmUgY29uc2lkZXJlZCBlcXVpdmFsZW50IGFuZCANCj4gbWFwcGVkIGRp cmVjdGx5IHRvIHRoZWlyIFVTLUFTQ0lJIGxvd2VyY2FzZSBlcXVpdmFsZW50cyBpbiB0aGUgcmFu Z2UgDQo+ICdhJyB0aHJvdWdoICd6Jy4gVGh1cyB0aGUgdGFnICJtbi1DeXJsLU1OIiBpcyBub3Qg ZGlzdGluY3QgZnJvbSANCj4gIk1OLWNZUkwtbW4iIG9yICJtTi0gY1lyTC1NbiIgKG9yIGFueSBv dGhlciBjb21iaW5hdGlvbikgYW5kIGVhY2ggb2YgDQo+IHRoZXNlIHZhcmlhdGlvbnMgY29udmV5 cyB0aGUgc2FtZSBtZWFuaW5nOiBNb25nb2xpYW4gd3JpdHRlbiBpbiB0aGUgDQo+IEN5cmlsbGlj IHNjcmlwdCBhcyB1c2VkIGluIE1vbmdvbGlhLg0KPiAtLQ0KPiANCj4gVGhlIGRvY3VtZW50IGdv ZXMgdG8gZ3JlYXQgbGVuZ3RocyB0byBzYXkgdGhhdCBjYXNlIGRpc3RpbmN0aW9ucyBtdXN0IA0K PiBub3QgYmUgY29uc2lkZXJlZCB3aGVuIHByb2Nlc3NpbmcgbGFuZ3VhZ2UgdGFncy4gSG93ZXZl ciwgdGhlIA0KPiBjYW5vbmljYWwgZm9ybSBmb2xsb3dzIHRoZSBJU08gc3RhbmRhcmRzOiB0aGlz IHByYWN0aWNlIGhhcyBsb25nIA0KPiBzdGFuZGluZyBpbiB0aGUgY29tbXVuaXR5IGF0IGxhcmdl IGFuZCBpcyBlbnNocmluZWQgaW4gU2VjdGlvbiA0LjQgDQo+ICgiQ2Fub25pY2FsaXphdGlvbiBv ZiBMYW5ndWFnZSBUYWdzIikgdGh1c2x5Og0KPiANCj4gLS0NCj4gV2hlbiBwZXJmb3JtaW5nIGNh bm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncywgcHJvY2Vzc29ycyBNQVkgDQo+IHJlZ3Vs YXJpemUgdGhlIGNhc2Ugb2YgdGhlIHN1YnRhZ3MgKHRoYXQgaXMsIHRoaXMgcHJvY2VzcyBpcyAN Cj4gT1BUSU9OQUwpLCBmb2xsb3dpbmcgdGhlIGNhc2UgdXNlZCBpbiB0aGUgcmVnaXN0cnkuIE5v dGUgdGhhdCB0aGlzIA0KPiBjb3JyZXNwb25kcyB0byB0aGUgZm9sbG93aW5nIGNhc2luZyBydWxl czogdXBwZXJjYXNlIGFsbCBub24taW5pdGlhbCANCj4gdHdvLWxldHRlciBzdWJ0YWdzOyB0aXRs ZWNhc2UgYWxsIG5vbi1pbml0aWFsIGZvdXItbGV0dGVyIHN1YnRhZ3M7IGxvd2VyY2FzZSBldmVy eXRoaW5nIGVsc2UuDQo+IC0tDQo+IA0KPiA+IEhvd2V2ZXIsIGJlY2F1c2UgdGhlIGNvcnJlc3Bv bmRpbmcgSVNPIGRvY3VtZW50cyB1c2UgdGl0bGUgY2FzZSBmb3IgDQo+ID4gc2NyaXB0IGNvZGVz IGFuZCB1cHBlciBjYXNlIGZvciByZWdpb24gY29kZXMsIHRoaXMgcmVwcmVzZW50YXRpb24gDQo+ ID4gaGFzIGJlZW4gdXNlZCBpbiB0aGUgbm9ybWF0aXZlIHRleHQgKHNzIDIuMi4zIGFuZCAyLjIu NCkgYW5kIA0KPiA+IHJlZ2lzdHJhdGlvbnMgb2YgdGhlc2UgY29kZXMgTVVTVCB1c2UgdGhpcyBy ZXByZXNlbnRhdGlvbiAoczMuMikuICANCj4gPiBUaGlzIHN0cnVjayBtZSBhcyB1bmVjZXNzYXJ5 IGJ1cmVhdWNyYWN5IGZvciByZWdpc3RyYW50cy4gIEl0IHdvdWxkIA0KPiA+IHNlZW0gdG8gbWUg ZW5vdWdoIHRvIFJFQ09NTUVORCB0aGF0IHRoZSByZWdpc3RyeSBjb25mb3JtIHRvIHRoZSBjYXNl IA0KPiA+IHBhdHRlcm5zIGFuZCBvdGhlcndpc2UgYWxsb3cgdXNlcnMgYW5kIHJlZ2lzdHJhbnRz IHdoYXRldmVyIGNhc2UgdGhleSBjaG9vc2UuDQo+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiANCj4g VGhpcyBidXJlYXVjcmFjeSBvbmx5IGFwcGxpZXMgdG8gaW5kZXBlbmRlbnRseSByZWdpc3RlcmVk IHZhbHVlcyANCj4gKHZhcmlhbnRzKSwgaW4gcHJhY3RpY2UsIGFuZCBpc24ndCBiaW5kaW5nIG9u IHRob3NlLiBUaGUgdW5kZXJseWluZyANCj4gSVNPIHN0YW5kYXJkcywgd2hlbiBtaXJyb3JlZCwg d29uJ3QgYmUgYW4gaXNzdWUsIHNpbmNlIHRoZWlyIA0KPiBhc3NpZ25tZW50cyB3aWxsIGFscmVh ZHkgY29tZSBpbiB0aGUgY2Fub25pY2FsIGZvcm1hdC4NCg0KUHJvcG9zZWQgc29sdXRpb24gdG8g bGFjayBvZiBjbGFyaXR5IGFib3V0IGNhc2U6DQoNCkluc2VydCBpbnRvIFNlY3Rpb24gMi4xIHRo ZSBmb2xsb3dpbmcgYWRkaXRpb25hbCBwYXJhZ3JhcGggZm9sbG93aW5nIHRoZSBvbmUgYWJvdXQg Y2FzZToNCg0KLS0NCjx0PkFsdGhvdWdoIGNhc2UgZGlzdGluY3Rpb25zIGRvIG5vdCBjYXJyeSBt ZWFuaW5nIGluIGxhbmd1YWdlIHRhZ3MsIGNvbnNpc3RlbnQgZm9ybWF0dGluZyBhbmQgcHJlc2Vu dGF0aW9uIG9mIHRoZSB0YWdzIHdpbGwgYWlkIHVzZXJzLiBUaGUgZm9ybWF0IG9mIHRoZSB0YWdz IGFuZCBzdWJ0YWdzIGluIHRoZSByZWdpc3RyeSBTSE9VTEQgYmUgY29uc2lkZXJlZCB0aGUgcmVj b21tZW5kZWQgZm9ybWF0LiBUaGlzIGZvcm1hdCBjb3JyZXNwb25kcyB0byB1cHBlcmNhc2luZyBh bGwgbm9uLWluaXRpYWwgdHdvLWxldHRlciBzdWJ0YWdzIGFuZCB0aXRsZWNhc2luZyBhbGwgbm9u LWluaXRpYWwgZm91ci1sZXR0ZXIgc3VidGFncy48L3Q+DQotLQ0KDQpQcm9wb3NlZCBzb2x1dGlv biB0byB0aGUgYnVyZWF1Y3JhY3kgaXNzdWUgKGZvciByZWdpc3RyYW50cyk6DQoNCkNoYW5nZSB0 aGlzIHRleHQ6DQoNCi0tDQo8dD5WYWx1ZXMgaW4gdGhlICdTdWJ0YWcnIGZpZWxkIE1VU1QgYmUg bG93ZXJjYXNlIGV4Y2VwdCBhcyBwcm92aWRlZCBmb3IgaW4gPHhyZWYgdGFyZ2V0PSJpYW5hZm9y bWF0Ij48L3hyZWY+LjwvdD4NCi0tDQoNClRvIHJlYWQgdGh1c2x5Og0KDQotLQ0KPHQ+QmVmb3Jl IGZvcndhcmRpbmcgYSBuZXcgcmVnaXN0cmF0aW9uIHRvIElBTkEsIHRoZSBMYW5ndWFnZSBTdWJ0 YWcgUmV2aWV3IE1VU1QgZW5zdXJlIHRoYXQgdmFsdWVzIGluIHRoZSAnU3VidGFnJyBmaWVsZCBt YXRjaCBjYXNlIGFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRpb24gaW4gPHhyZWYgdGFyZ2V0PSJp YW5hZm9ybWF0Ij48L3hyZWY+LjwvdD4NCi0tDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGls bGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3 LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2lu ZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFs aXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============1746428147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1746428147==-- From ltru-bounces@ietf.org Wed Aug 31 17:14:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZuh-0005O8-B1; Wed, 31 Aug 2005 17:14:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZuf-0005Nz-AH for ltru@megatron.ietf.org; Wed, 31 Aug 2005 17:14:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15174 for ; Wed, 31 Aug 2005 17:14:26 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAZwS-0002ZA-MQ for ltru@ietf.org; Wed, 31 Aug 2005 17:16:22 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j7VLE2X3028858; Wed, 31 Aug 2005 17:14:03 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 31 Aug 2005 17:11:52 -0400 Date: Wed, 31 Aug 2005 17:11:51 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] Recall of the LSR (gen-art #2) Message-ID: <20050831211150.GN14448@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0CA912C3@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CA912C3@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Elwyn Davies , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > > Presumably the appointing > > authority is the unappointing authority too and the body to whom to >appeal? > > Those are still good questions. Comments? The above strategy seems right to me. The IESG giveth and the IESG taketh away, and the appeal is unto them. -- Babies are born as a result of the John Cowan mating between men and women, and most http://www.reutershealth.com men and women enjoy mating. http://www.ccil.org/~cowan --Isaac Asimov in Earth: Our Crowded Spaceship jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 17:36:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAaFb-0004WQ-Je; Wed, 31 Aug 2005 17:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAaFZ-0004WI-7B for ltru@megatron.ietf.org; Wed, 31 Aug 2005 17:36:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16965 for ; Wed, 31 Aug 2005 17:36:02 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAaHN-0003T9-54 for ltru@ietf.org; Wed, 31 Aug 2005 17:37:58 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 14:35:54 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 14:35:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Recall of the LSR (gen-art #2) Date: Wed, 31 Aug 2005 14:36:06 -0700 Message-ID: Thread-Topic: [Ltru] Recall of the LSR (gen-art #2) Thread-Index: AcWubjgmjTOZLzHxRo2EpTdBAGNOGQABKTWw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 21:35:54.0024 (UTC) FILETIME=[F71C8280:01C5AE73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: Elwyn Davies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Addison Phillips > > > Given recent IETF discussions, should the document set out ways for > > > the community to request the unfrocking (recall) of the Language > > > Subtag Reviewer in the event of non-performance or repeated > inappropriate > > > decisions? Also would it be appropriate to suggest that the IESG > > > document the name of the reviewer on their web page and periodically > > > reconfirm the appointment? I don't think a fixed term appointment > > > would be desirable, and I agree this is not something for nomcom to > > > be involved in. > > [Addison Phillips] > > > > Those are good questions. I'm not sure if there are any similar > > practices anywhere else in the IETF. Presumably the appointing > > authority is the unappointing authority too and the body to whom to > >appeal? >=20 > Those are still good questions. Comments? I'm not sure specifically what "recent IETF discussions" is referring to, so the following comments do not benefit from that.=20 I note that RFC 2978 doesn't have language addressing such issues (and, of course, neither did RFC 3066). I certainly don't think these are bad ideas, though I'm not sure that text needs to be added to this draft. If IESG wants to document the name of the reviewer on their web page, I don't think we need to add anything in the draft to make them do it. That's a purely IESG administrative activity. It would also seem to me to be more appropriate that a separate document define policies under which action against a reviewer of any IETF-sanctioned registry might be taken. For comparison, I'll mention that ISO standards such as ISO 639-x define a registration authority and their responsibilities without also specifying procedures for taking disciplinary action against an RA or re-confirming their appointment. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 17:38:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAaHh-0004jB-Dd; Wed, 31 Aug 2005 17:38:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAaHg-0004ie-Sg for ltru@megatron.ietf.org; Wed, 31 Aug 2005 17:38:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17021 for ; Wed, 31 Aug 2005 17:38:13 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAaJV-0003VO-20 for ltru@ietf.org; Wed, 31 Aug 2005 17:40:10 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 14:38:05 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Aug 2005 14:38:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] case canonicalization in registry (gen-art #3) Date: Wed, 31 Aug 2005 14:38:18 -0700 Message-ID: Thread-Topic: [Ltru] case canonicalization in registry (gen-art #3) Thread-Index: AcWub4OMtZV4xuKJRW+0J/2NEudOSAABKw2g From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 21:38:05.0852 (UTC) FILETIME=[45AFDDC0:01C5AE74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: Elwyn Davies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Addison Phillips > Proposed solution to the bureaucracy issue (for registrants): >=20 > Change this text: >=20 > -- > Values in the 'Subtag' field MUST be lowercase except as provided for > in . > -- >=20 > To read thusly: >=20 > -- > Before forwarding a new registration to IANA, the Language Subtag > Review MUST ensure that values in the 'Subtag' field match case according > to the description in . > -- Should "Review" be "Reviewer"? Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 18:52:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRO-0005xF-Py; Wed, 31 Aug 2005 18:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRN-0005x4-De for ltru@megatron.ietf.org; Wed, 31 Aug 2005 18:52:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23003 for ; Wed, 31 Aug 2005 18:52:16 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAbTA-0005SS-LK for ltru@ietf.org; Wed, 31 Aug 2005 18:54:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 15:51:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] case canonicalization in registry (gen-art #3) Date: Wed, 31 Aug 2005 15:51:56 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91342@irvmbxw01.quest.com> Thread-Topic: [Ltru] case canonicalization in registry (gen-art #3) Thread-Index: AcWub4OMtZV4xuKJRW+0J/2NEudOSAABKw2gAADr5tA= From: "Addison Phillips" To: "Peter Constable" , "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 22:51:57.0816 (UTC) FILETIME=[9757E780:01C5AE7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: Elwyn Davies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Yes. Good catch. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf = Of > Peter Constable > Sent: 2005?8?31? 14:38 > To: LTRU Working Group > Cc: Elwyn Davies > Subject: RE: [Ltru] case canonicalization in registry (gen-art #3) >=20 > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf > Of > > Addison Phillips >=20 >=20 > > Proposed solution to the bureaucracy issue (for registrants): > > > > Change this text: > > > > -- > > Values in the 'Subtag' field MUST be lowercase except as provided > for > > in . > > -- > > > > To read thusly: > > > > -- > > Before forwarding a new registration to IANA, the Language Subtag > > Review MUST ensure that values in the 'Subtag' field match case > according > > to the description in . > > -- >=20 > Should "Review" be "Reviewer"? >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 18:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRU-000666-7Q; Wed, 31 Aug 2005 18:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRO-0005xd-Uf for ltru@megatron.ietf.org; Wed, 31 Aug 2005 18:52:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23009 for ; Wed, 31 Aug 2005 18:52:19 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAbTE-0005SS-Dm for ltru@ietf.org; Wed, 31 Aug 2005 18:54:17 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 15:51:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 15:51:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91343@irvmbxw01.quest.com> Thread-Topic: define the LSR (gen-art #4) Thread-Index: AcWueJhPB74tF6j8SAOQHk/8Z7+9Yg== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 22:51:58.0144 (UTC) FILETIME=[9789F400:01C5AE7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Elwyn Davies Subject: [Ltru] define the LSR (gen-art #4) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1797398309==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1797398309== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IFJlc3RydWN0dXJpbmc6DQo+ID4gVGhlIExhbmd1YWdlIFRhZyBSZXZpZXdlciBvZiBSRkMz MDY2IGhhcyBtZXRhbW9ycGhvc2VkIGludG8gYSANCj4gPiBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3 ZXIuICBUaGUgc3VidGFnIHJldmlld2VyIGlzIGZpcnN0IG1lbnRpb25lZCBpbiANCj4gPiBzMy4x IGluIGEgcmF0aGVyIHN1ZGRlbiB3YXkuICBUaGUgcm9sZSBvZiB0aGUgcmV2aWV3ZXIgaXMgc2Nh dHRlcmVkIA0KPiA+IGFjcm9zcyBzZXZlcmFsIHN1Yi1zZWN0aW9ucyBvZiBzMyBhbmQgaG93IHRo ZSBwZXJzb24gaXMgYXBwb2ludGVkIGlzIA0KPiA+IGJ1cmllZCBpbiBkZXB0aHMgb2YgczMuNCAo UmVnaXN0cmF0aW9uIFByb2NlZHVyZSBmb3IgU3VidGFncykuICBJIA0KPiA+IHRoaW5rIGl0IHdv dWxkIGJlIHZhbHVhYmxlIHRvIHN1bW1hcml6ZSB0aGUgcm9sZSBvZiB0aGUgTGFuZ3VhZ2UgDQo+ ID4gU3VidGFnIFJldmlld2VyIGFuZCBzZXQgb3V0IGhvdyB0aGlzIHBlcnNvbiBpcyBhcHBvaW50 ZWQgKGFuZCBtYXliZSANCj4gPiBhbHNvIHJlY2FsbGVkKSByaWdodCBhdCB0aGUgc3RhcnQgb2Yg czMuDQo+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiANCj4gVGhhdCBzZWVtcyBsaWtlIGEgc2Vuc2li bGUgdGhpbmcgdG8gZG8uDQoNClByb3Bvc2VkIHNvbHV0aW9uOg0KDQpBZGQgYSBzZWN0aW9uIGZv bGxvd2luZyBzZWN0aW9uIDMuMSBjYWxsZWQgIlRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIi IGNvbnRhaW5pbmcgdGhlIHZhcmlvdXMgZGVmaW5pdGl2ZSBzdGF0ZW1lbnRzLiBUaGUgb25lIGZv cndhcmQgcmVmZXJlbmNlIGluIHNlY3Rpb24gMy4xOg0KDQotLQ0KVGhlIElBTkEgTGFuZ3VhZ2Ug U3VidGFnIFJlZ2lzdHJ5ICgidGhlIHJlZ2lzdHJ5IikgY29uc2lzdHMgb2YgYSB0ZXh0IGZpbGUg dGhhdCBpcyBtYWNoaW5lIHJlYWRhYmxlIGluIHRoZSBmb3JtYXQgZGVzY3JpYmVkIGluIHRoaXMg c2VjdGlvbiwgcGx1cyBjb3BpZXMgb2YgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtcyBhcHByb3ZlZCBi eSB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgcHJv Y2VzcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQgKFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUgZm9y IFN1YnRhZ3MpLg0KLS0NCg0KV291bGQgYmUgY2hhbmdlZCB0byByZWFkOg0KDQotLQ0KVGhlIElB TkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5ICgidGhlIHJlZ2lzdHJ5IikgY29uc2lzdHMgb2Yg YSB0ZXh0IGZpbGUgdGhhdCBpcyBtYWNoaW5lIHJlYWRhYmxlIGluIHRoZSBmb3JtYXQgZGVzY3Jp YmVkIGluIHRoaXMgc2VjdGlvbiwgcGx1cyBjb3BpZXMgb2YgdGhlIHJlZ2lzdHJhdGlvbiBmb3Jt cyBhcHByb3ZlZCBhY2NvcmRpbmcgdG8gdGhlIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24g My40IChSZWdpc3RyYXRpb24gUHJvY2VkdXJlIGZvciBTdWJ0YWdzKS4NCi0tDQoNCih0aGUgTFNS IHJlZmVyZW5jZSBhZGRzIG5vIHZhbHVlIGhlcmUpDQoNCkknbGwgcHJvZHVjZSBhIHZlcnNpb24g aW4gdGhlIGVkaXRvcidzIGNvcHkgZm9yIHJldmlldy4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAu IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6 Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBX b3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0 aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0K DQoNCg== --===============1797398309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1797398309==-- From ltru-bounces@ietf.org Wed Aug 31 18:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRU-00066Y-En; Wed, 31 Aug 2005 18:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRS-00065w-V6 for ltru@megatron.ietf.org; Wed, 31 Aug 2005 18:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23012 for ; Wed, 31 Aug 2005 18:52:22 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAbTH-0005SS-5V for ltru@ietf.org; Wed, 31 Aug 2005 18:54:19 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 15:51:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 15:51:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91344@irvmbxw01.quest.com> Thread-Topic: documenting the update load (gen-art #5) Thread-Index: AcWueMN4t1pB3yK4RciXz+FiMLbVFA== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 22:51:58.0472 (UTC) FILETIME=[97BC0080:01C5AE7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Elwyn Davies Subject: [Ltru] documenting the update load (gen-art #5) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0747161141==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0747161141== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IFVwZGF0ZSBMb2FkDQo+ID4gVGhlcmUgaGFzIGJlZW4gY29uc2lkZXJhYmxlIGRlYmF0ZSBh Ym91dCB0aGUgZXhwZWN0ZWQgbG9hZCBvZiANCj4gPiB1cGRhdGluZyB0aGUgcmVnaXN0cnkgZXNw ZWNpYWxseSBvdmVyIHRoZSBuZXh0IGNvdXBsZSBvZiB5ZWFycy4gIEl0IA0KPiA+IG1pZ2h0IGJl IHdvcnRoIGFkZGluZyBzb21lIG5vdGVzIGFib3V0IHRoZSBleHBlY3RlZCBsb2FkIGFuZCANCj4g PiBlbXBoYXNpc2luZyB0aGF0IHN1Y2ggY2hhbmdlcyB3aWxsIGhhdmUgbWluaW1hbCBpbXBhY3Qg b24gDQo+ID4gYXBwbGljYXRpb25zIGR1ZSB0byB0aGUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkg cnVsZXMuDQo+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiANCj4gQXNpZGUgZnJvbSByZXZpc2lvbnMg dG8gZG9jdW1lbnQgaW4gcXVlc3Rpb24sIHRoZSBkYXktdG8tZGF5IGFjdGl2aXR5IA0KPiBvZiB0 aGUgaWV0Zi1sYW5ndWFnZXMgbGlzdCBoYXMgYmVlbiBmYWlybHkgc3RlYWR5IG92ZXIgaXRzIGxp ZmV0aW1lLiANCj4gVGhhdCBpc24ndCBleHBlY3RlZCB0byBjaGFuZ2UuIFRoZSBudW1iZXIgb2Yg SVNPIDYzOS0xLy0yIGFuZCBJU08gMzE2NiANCj4gcmVnaXN0cmF0aW9ucyBpbiBhIGdpdmVuIHll YXIgaGFzIHRlbmRlZCB0byBiZSBzbWFsbCAob24gdGhlIG9yZGVyIG9mIA0KPiBhIGRvemVuIHJl bGV2YW50IGNoYW5nZXMgcGVyIHllYXIpLiBUaGUgYWRkaXRpb24gb2YgSVNPIDYzOS0zIG9yIElT TyANCj4gNjM5LTYgaGFzIGJlZW4gY29uc2lkZXJlZCBhcyBhIHBvc3NpYmlsaXR5LCBidXQgdGhh dCB3b3VsZCBiZSBhIA0KPiBzcGVjaWFsIGNhc2UgYW5kIGJlIGNvaW5jaWRlbnQgd2l0aCBhIHJl dmlzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KSSB3b3VsZCBzdWdnZXN0IHRoYXQgd2UgZG8gbm90 aGluZyBmb3IgdGhpcy4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxp emF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoN CkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRw Oi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5v dCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============0747161141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0747161141==-- From ltru-bounces@ietf.org Wed Aug 31 18:52:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRa-00067J-RZ; Wed, 31 Aug 2005 18:52:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRU-000665-3k for ltru@megatron.ietf.org; Wed, 31 Aug 2005 18:52:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23015 for ; Wed, 31 Aug 2005 18:52:24 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAbTI-0005SS-TQ for ltru@ietf.org; Wed, 31 Aug 2005 18:54:22 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 15:51:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 15:51:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91345@irvmbxw01.quest.com> Thread-Topic: various casing issues (gen-art #7) Thread-Index: AcWuefagDyBuFMkhS8mDK5P4hBKrig== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 22:51:59.0066 (UTC) FILETIME=[9816A3A0:01C5AE7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Elwyn Davies Subject: [Ltru] various casing issues (gen-art #7) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0263834549==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0263834549== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMyLjIuMzogaXRlbSAzOiBJcyBpdCBkZXNpcmFibGUgdG8gaGF2ZSBub3JtYXRpdmUgdGV4 dCB1c2luZyBvdGhlciANCj4gPiB0aGFuIGxvd2VyIGNhc2UgZm9yIHRhZyBpZGVudGlmaWVycz8g U2VlIGFsc28gczMuMiBjb21tZW50IGJlbG93Lg0KPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gDQo+ IFllcy4gU2VlIGFib3ZlLg0KPiANCj4gPiBzMi4yLjQ6IEl0ZW0gNiBhbmQgKG1heWJlKSBleGFt cGxlczogYXMgcGVyIHMyLjIuMywgSXRlbSAzLg0KPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gDQo+ IFNhbWUuDQoNCkkgd291bGQgc3VnZ2VzdCB0aGF0IHdlJ3ZlIGFscmVhZHkgZGVhbHQgd2l0aCB0 aGVzZS4NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1 ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIEludGVybmF0 aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcvSW50ZXJu YXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMg YW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============0263834549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0263834549==-- From ltru-bounces@ietf.org Wed Aug 31 18:52:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRb-00067k-2P; Wed, 31 Aug 2005 18:52:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRW-00066z-2p for ltru@megatron.ietf.org; Wed, 31 Aug 2005 18:52:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23018 for ; Wed, 31 Aug 2005 18:52:26 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAbTK-0005SS-Th for ltru@ietf.org; Wed, 31 Aug 2005 18:54:24 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 15:51:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 15:51:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91346@irvmbxw01.quest.com> Thread-Topic: UN economic groupings (gen-art #8) Thread-Index: AcWuegvBM3eBayAPSM6UmYI6cRrsrQ== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 22:51:59.0347 (UTC) FILETIME=[98418430:01C5AE7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Elwyn Davies Subject: [Ltru] UN economic groupings (gen-art #8) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1122170141==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1122170141== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMyLjIuNDogSXRlbSAzQTogW091dCBvZiBpbnRlcmVzdC4uLl0gV2h5IG5vdCBlY29ub21p YyBncm91cGluZ3M/ICANCj4gPiBUaGVpciBidXJlYXVjcmF0cyBoYXZlIGxhbmd1YWdlcyBhbGwg dGhlaXIgb3duIDstKSAuDQo+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiANCj4gVGhlIGVjb25vbWlj IGdyb3VwaW5ncyBhcmUgdGhpbmdzIGxpa2UgIjEwIHBvb3Jlc3QgY291bnRyaWVzIiBhbmQgIjEw IA0KPiByaWNoZXN0IGNvdW50cmllcyIgYW5kIHRoZSBsaWtlLiBUaGUgZWNvbm9taWMgZ3JvdXBp bmdzIGRvbid0IGRlc2NyaWJlIA0KPiBzdGFibGUgcmVnaW9uYWwgZW50aXRpZXMgYW5kIG1pZ2h0 IGJlIGNvbnRyb3ZlcnNpYWwsIGVzcGVjaWFsbHkgaW4gDQo+IGxhbmd1YWdlIHRhZ3MgKCJGcmVu Y2ggYXMgc3Bva2VuIGluIHBvb3IgY291bnRyaWVzIikNCg0KUHJvcG9zZWQgc29sdXRpb246DQoN CkRvIG5vdGhpbmcuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXph dGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpD aGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDov L3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3Qg YSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============1122170141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1122170141==-- From ltru-bounces@ietf.org Wed Aug 31 18:52:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRb-000688-9E; Wed, 31 Aug 2005 18:52:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbRW-000674-PU for ltru@megatron.ietf.org; Wed, 31 Aug 2005 18:52:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23021 for ; Wed, 31 Aug 2005 18:52:27 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAbTM-0005SS-Me for ltru@ietf.org; Wed, 31 Aug 2005 18:54:24 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 15:51:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 15:51:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91347@irvmbxw01.quest.com> Thread-Topic: define the LSR (gen-art #9) Thread-Index: AcWueinyO/cE6SCeR7WQBytsTHD9mQ== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 22:51:59.0675 (UTC) FILETIME=[987390B0:01C5AE7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Elwyn Davies Subject: [Ltru] define the LSR (gen-art #9) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0333279082==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============0333279082== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiA+IHMzLjE6IHRoZSAnTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyJyBtYWtlcyBhIHJhdGhlciBz dWRkZW4gZW50cnkgaGVyZS4NCj4gPiAnV2hvIGlzIHRoaXMgcGVyc29uPycgdGhlIG5haXZlIHJl YWRlciBtYXkgYXNrLiAgSXQgd291bGQgYmUgYSBnb29kIA0KPiA+IGlkZWEgdG8gYWRkIGEgc3Vi LXNlY3Rpb24gYmVmb3JlIDMuMSBpbnRyb2R1Y2luZyB0aGUgTGFuZ3VhZ2UgU3VidGFnIA0KPiA+ IFJldmlld2VyLCBzdW1tYXJpemluZyB0aGUgcm9sZSBhbmQgc2V0dGluZyBvdXQgaG93IHRoZSBw ZXJzb24gaXMgDQo+ID4gYXBwb2ludGVkIChhbmQgcmVjYWxsZWQpIC0gbW92ZSB0ZXh0IGZyb20g czMuNC4gIFNpbmNlIHRoZSB0aGUgDQo+ID4gTGFuZ3VhZ2UgVGFnIFJldmlld2VyIChhIHdob2xs eSBkaWZmZXJlbnQgcGVyc29uIDstKSApIGZyb20gUkZDMzA2NiANCj4gPiBpcyBhbHNvIG1lbnRp b25lZCwgaXQgaXMgaW1wb3J0YW50IHRoYXQgaXQgaXMgY2xlYXIgd2hpY2ggb25lIGlzIA0KPiA+ IHJlZmVycmVkIHRvIC0gdGhlIGZ1bGwgdGl0bGUgc2hvdWxkIGJlIHVzZWQgdGhyb3VnaG91dCAo ZS5nLiBzZXZlcmFsIA0KPiA+IGluY29tcGxldGUgaW5zdGFuY2VzIGluIHMzLjQpIC0gYSBoYW5k eSBhYmJyZXZpYXRpb24gKGFsdGhvdWdoIExTUiANCj4gPiBpcyBhbHJlYWR5IHRha2VuIGluIE1Q TFMgbGFuZCkgbWlnaHQgc2hvcnRlbiB0aGUgZG9jdW1lbnQgYSBiaXQhDQo+IFtBZGRpc29uIFBo aWxsaXBzXQ0KPiANCj4gQSB2ZXJ5IGxpdHRsZSBiaXQgOi0pLg0KPiANCj4gQSBzbWFsbCBzdWJz ZWN0aW9uIGNvdWxkIGJlIGNyZWF0ZWQgdG8gZGVhbCB3aXRoIHRoaXMgaXNzdWUuDQoNClJlcGVh dCBvZiBhbm90aGVyIGlzc3VlLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkds b2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5j b20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXAN Cmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg0K --===============0333279082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0333279082==-- From ltru-bounces@ietf.org Wed Aug 31 19:12:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbl8-0007H1-GM; Wed, 31 Aug 2005 19:12:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbl5-0007Ca-L2 for ltru@megatron.ietf.org; Wed, 31 Aug 2005 19:12:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26267 for ; Wed, 31 Aug 2005 19:12:40 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAbmt-0006sC-JO for ltru@ietf.org; Wed, 31 Aug 2005 19:14:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 16:12:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] define the LSR (gen-art #4) Date: Wed, 31 Aug 2005 16:12:23 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0CA91352@irvmbxw01.quest.com> Thread-Topic: [Ltru] define the LSR (gen-art #4) Thread-Index: AcWueJhPB74tF6j8SAOQHk/8Z7+9YgACJFCg From: "Addison Phillips" To: "Addison Phillips" , "LTRU Working Group" X-OriginalArrivalTime: 31 Aug 2005 23:12:24.0754 (UTC) FILETIME=[72A7C920:01C5AE81] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Elwyn Davies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1875129895==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org --===============1875129895== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGVyZSBpcyBhbiBpbml0aWFsIHByb3Bvc2VkIHRlc3QgZm9yIHRoaXMgc2VjdGlvbi4NCg0KLS0N CjxzZWN0aW9uIGFuY2hvcj0ic3VidGFncmV2aWV3ZXIiIHRpdGxlPSJMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXIiPg0KDQo8dD5UaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGlzIGFwcG9pbnRl ZCBieSB0aGUgSUVTRyB0byBtb2RlcmF0ZSB0aGUgaWV0Zi1sYW5ndWFnZXMgbWFpbGluZyBsaXN0 LCByZXNwb25kIHRvIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24sIGFuZCBwZXJmb3JtIHRoZSBv dGhlciByZWdpc3RyeSBtYWludGVuYW5jZSBkdXRpZXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdl dD0ibWFpbnRyZWciPjwveHJlZj4uIE9ubHkgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBp cyBwZXJtaXR0ZWQgdG8gcmVxdWVzdCBJQU5BIHRvIGNoYW5nZSwgdXBkYXRlIG9yIGFkZCByZWNv cmRzIHRvIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkuPC90Pg0KDQo8dD5UaGUgcGVyZm9y bWFuY2Ugb3IgZGVjaXNpb25zIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTUFZIGJl IGFwcGVhbGVkIHRvIHRoZSBJRVNHIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFzIG90aGVyIElFVEYg ZGVjaXNpb25zIChzZWUgPHhyZWYgdGFyZ2V0PSJSRkMyMDI2Ij48L3hyZWY+KS4gVGhlIElFU0cg Y2FuIHJldmVyc2Ugb3Igb3ZlcnR1cm4gdGhlIGRlY2lzaW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0 YWcgUmV2aWV3ZXIsIHByb3ZpZGUgZ3VpZGFuY2UsIG9yIHRha2Ugb3RoZXIgYXBwcm9wcmlhdGUg YWN0aW9ucy48L3Q+DQoNCjwvc2VjdGlvbj4NCi0tDQoNClRoZXJlIGFyZSBtYW55IHJlZmVyZW5j ZXMgdG8gdGhlIExTUiBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50LiBTaG91bGQgSSB0cnkgdG8g Y29sbGVjdCB0aGVzZSBpdGVtcyB1cD8gSXQgd291bGQgbWFyayBhIHN1YnN0YW50aWFsIGNoYW5n ZSBpbiB0aGUgdGV4dCwgc2luY2UgbWFueSBvZiB0aGVzZSBpdGVtcyBhcmUgcGFydCBvZiB0aGUg dGV4dHVhbCBmbG93LiBGb3Igbm93IEkgdGhpbmsgdGhpcyBpc24ndCBuZWNlc3Nhcnk7IHRoYXQg SSBvbmx5IG5lZWQgYWRkIHJlZmVyZW5jZXMgdG8gdGhlIG5ldyBTZWN0aW9uIDMuMiAoYWJvdmUp IGluIGVhY2ggcmVmZXJlbmNpbmcgc2VjdGlvbi4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBo aWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBX M0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9u YWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEFkZGlzb24g UGhpbGxpcHMNCj4gU2VudDogMjAwNeW5tDjmnIgzMeaXpSAxNTo1Mg0KPiBUbzogTFRSVSBXb3Jr aW5nIEdyb3VwDQo+IENjOiBFbHd5biBEYXZpZXMNCj4gU3ViamVjdDogW0x0cnVdIGRlZmluZSB0 aGUgTFNSIChnZW4tYXJ0ICM0KQ0KPiANCj4gPiA+IFJlc3RydWN0dXJpbmc6DQo+ID4gPiBUaGUg TGFuZ3VhZ2UgVGFnIFJldmlld2VyIG9mIFJGQzMwNjYgaGFzIG1ldGFtb3JwaG9zZWQgaW50byBh DQo+ID4gPiBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIuICBUaGUgc3VidGFnIHJldmlld2VyIGlz IGZpcnN0IG1lbnRpb25lZCBpbg0KPiA+ID4gczMuMSBpbiBhIHJhdGhlciBzdWRkZW4gd2F5LiAg VGhlIHJvbGUgb2YgdGhlIHJldmlld2VyIGlzIHNjYXR0ZXJlZA0KPiA+ID4gYWNyb3NzIHNldmVy YWwgc3ViLXNlY3Rpb25zIG9mIHMzIGFuZCBob3cgdGhlIHBlcnNvbiBpcyBhcHBvaW50ZWQgaXMN Cj4gPiA+IGJ1cmllZCBpbiBkZXB0aHMgb2YgczMuNCAoUmVnaXN0cmF0aW9uIFByb2NlZHVyZSBm b3IgU3VidGFncykuICBJDQo+ID4gPiB0aGluayBpdCB3b3VsZCBiZSB2YWx1YWJsZSB0byBzdW1t YXJpemUgdGhlIHJvbGUgb2YgdGhlIExhbmd1YWdlDQo+ID4gPiBTdWJ0YWcgUmV2aWV3ZXIgYW5k IHNldCBvdXQgaG93IHRoaXMgcGVyc29uIGlzIGFwcG9pbnRlZCAoYW5kIG1heWJlDQo+ID4gPiBh bHNvIHJlY2FsbGVkKSByaWdodCBhdCB0aGUgc3RhcnQgb2YgczMuDQo+ID4gW0FkZGlzb24gUGhp bGxpcHNdDQo+ID4NCj4gPiBUaGF0IHNlZW1zIGxpa2UgYSBzZW5zaWJsZSB0aGluZyB0byBkby4N Cj4gDQo+IFByb3Bvc2VkIHNvbHV0aW9uOg0KPiANCj4gQWRkIGEgc2VjdGlvbiBmb2xsb3dpbmcg c2VjdGlvbiAzLjEgY2FsbGVkICJUaGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIg0KPiBjb250 YWluaW5nIHRoZSB2YXJpb3VzIGRlZmluaXRpdmUgc3RhdGVtZW50cy4gVGhlIG9uZSBmb3J3YXJk IHJlZmVyZW5jZSBpbg0KPiBzZWN0aW9uIDMuMToNCj4gDQo+IC0tDQo+IFRoZSBJQU5BIExhbmd1 YWdlIFN1YnRhZyBSZWdpc3RyeSAoInRoZSByZWdpc3RyeSIpIGNvbnNpc3RzIG9mIGEgdGV4dCBm aWxlDQo+IHRoYXQgaXMgbWFjaGluZSByZWFkYWJsZSBpbiB0aGUgZm9ybWF0IGRlc2NyaWJlZCBp biB0aGlzIHNlY3Rpb24sIHBsdXMNCj4gY29waWVzIG9mIHRoZSByZWdpc3RyYXRpb24gZm9ybXMg YXBwcm92ZWQgYnkgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlcg0KPiBpbiBhY2NvcmRhbmNl IHdpdGggdGhlIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40IChSZWdpc3RyYXRpb24N Cj4gUHJvY2VkdXJlIGZvciBTdWJ0YWdzKS4NCj4gLS0NCj4gDQo+IFdvdWxkIGJlIGNoYW5nZWQg dG8gcmVhZDoNCj4gDQo+IC0tDQo+IFRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAo InRoZSByZWdpc3RyeSIpIGNvbnNpc3RzIG9mIGEgdGV4dCBmaWxlDQo+IHRoYXQgaXMgbWFjaGlu ZSByZWFkYWJsZSBpbiB0aGUgZm9ybWF0IGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24sIHBsdXMN Cj4gY29waWVzIG9mIHRoZSByZWdpc3RyYXRpb24gZm9ybXMgYXBwcm92ZWQgYWNjb3JkaW5nIHRv IHRoZSBwcm9jZXNzDQo+IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNCAoUmVnaXN0cmF0aW9uIFBy b2NlZHVyZSBmb3IgU3VidGFncykuDQo+IC0tDQo+IA0KPiAodGhlIExTUiByZWZlcmVuY2UgYWRk cyBubyB2YWx1ZSBoZXJlKQ0KPiANCj4gSSdsbCBwcm9kdWNlIGEgdmVyc2lvbiBpbiB0aGUgZWRp dG9yJ3MgY29weSBmb3IgcmV2aWV3Lg0KPiANCj4gQWRkaXNvbg0KPiANCj4gQWRkaXNvbiBQLiBQ aGlsbGlwcw0KPiBHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCj4gaHR0 cDovL3d3dy5xdWVzdC5jb20NCj4gDQo+IENoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24g Q29yZSBXb3JraW5nIEdyb3VwDQo+IGh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCj4g DQo+IEludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQo+IEl0IGlzIGFuIGFy Y2hpdGVjdHVyZS4NCj4gDQoNCg0K --===============1875129895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1875129895==-- From ltru-bounces@ietf.org Wed Aug 31 20:42:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAdA1-0004hK-OV; Wed, 31 Aug 2005 20:42:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAd9x-0004ex-QO for ltru@megatron.ietf.org; Wed, 31 Aug 2005 20:42:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29355 for ; Wed, 31 Aug 2005 20:42:27 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAdBm-0000dN-UB for ltru@ietf.org; Wed, 31 Aug 2005 20:44:24 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j810fsKq090376 for ; Wed, 31 Aug 2005 20:41:55 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j810ecMc538164 for ; Wed, 31 Aug 2005 18:40:38 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j810eWEG005270 for ; Wed, 31 Aug 2005 18:40:33 -0600 Received: from [127.0.0.1] (sig-9-48-115-248.mts.ibm.com [9.48.115.248]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j810eR7L005233; Wed, 31 Aug 2005 18:40:28 -0600 Message-ID: <43164DFA.60508@icu-project.org> Date: Wed, 31 Aug 2005 17:40:26 -0700 From: Mark Davis User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] (gen-art #1-5,7-9) References: <634978A7DF025A40BFEF33EB191E13BC0CA91352@irvmbxw01.quest.com> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CA91352@irvmbxw01.quest.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j810fsKq090376 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: Elwyn Davies , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Your suggestions all look good to me. Mark Addison Phillips wrote: > Here is an initial proposed test for this section. >=20 > -- >
>=20 > The Language Subtag Reviewer is appointed by the IESG to moderate th= e ietf-languages mailing list, respond to requests for registration, and = perform the other registry maintenance duties described in . Only the Language Subtag Reviewer is permitted to req= uest IANA to change, update or add records to the Language Subtag Registr= y. >=20 > The performance or decisions of the Language Subtag Reviewer MAY be = appealed to the IESG under the same rules as other IETF decisions (see ). The IESG can reverse or overturn the dec= ision of the Language Subtag Reviewer, provide guidance, or take other ap= propriate actions. >=20 >
> -- >=20 > There are many references to the LSR elsewhere in the document. Should = I try to collect these items up? It would mark a substantial change in th= e text, since many of these items are part of the textual flow. For now I= think this isn't necessary; that I only need add references to the new S= ection 3.2 (above) in each referencing section. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture.=20 >=20 >=20 >>-----Original Message----- >>From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of >>Addison Phillips >>Sent: 2005=E5=B9=B48=E6=9C=8831=E6=97=A5 15:52 >>To: LTRU Working Group >>Cc: Elwyn Davies >>Subject: [Ltru] define the LSR (gen-art #4) >> >> >>>>Restructuring: >>>>The Language Tag Reviewer of RFC3066 has metamorphosed into a >>>>Language Subtag Reviewer. The subtag reviewer is first mentioned in >>>>s3.1 in a rather sudden way. The role of the reviewer is scattered >>>>across several sub-sections of s3 and how the person is appointed is >>>>buried in depths of s3.4 (Registration Procedure for Subtags). I >>>>think it would be valuable to summarize the role of the Language >>>>Subtag Reviewer and set out how this person is appointed (and maybe >>>>also recalled) right at the start of s3. >>> >>>[Addison Phillips] >>> >>>That seems like a sensible thing to do. >> >>Proposed solution: >> >>Add a section following section 3.1 called "The Language Subtag Reviewe= r" >>containing the various definitive statements. The one forward reference= in >>section 3.1: >> >>-- >>The IANA Language Subtag Registry ("the registry") consists of a text f= ile >>that is machine readable in the format described in this section, plus >>copies of the registration forms approved by the Language Subtag Review= er >>in accordance with the process described in Section 3.4 (Registration >>Procedure for Subtags). >>-- >> >>Would be changed to read: >> >>-- >>The IANA Language Subtag Registry ("the registry") consists of a text f= ile >>that is machine readable in the format described in this section, plus >>copies of the registration forms approved according to the process >>described in Section 3.4 (Registration Procedure for Subtags). >>-- >> >>(the LSR reference adds no value here) >> >>I'll produce a version in the editor's copy for review. >> >>Addison >> >>Addison P. Phillips >>Globalization Architect, Quest Software >>http://www.quest.com >> >>Chair, W3C Internationalization Core Working Group >>http://www.w3.org/International >> >>Internationalization is not a feature. >>It is an architecture. >> >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 21:49:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAeDB-0003mt-Qr; Wed, 31 Aug 2005 21:49:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAeD9-0003ml-UI; Wed, 31 Aug 2005 21:49:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01664; Wed, 31 Aug 2005 21:49:49 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAeF1-0002Fw-Ah; Wed, 31 Aug 2005 21:51:47 -0400 Received: from h-68-166-189-43.snvacaid.dynamic.covad.net ([68.166.189.43] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EAeCy-0005Zz-00; Wed, 31 Aug 2005 21:49:41 -0400 Message-ID: <004701c5ae97$b0e01f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 31 Aug 2005 18:51:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: gen-art@ietf.org, Elwyn Davies , Mary Barnes Subject: [Ltru] Fw: Gen-art review: draft-ietf-ltru-initial-04.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Hi - I'd like to thank GenART reviewer Elwyn Davies for these comments. Any followup discussion should take place on the ltru working group mailing list. Randy, ltru co-chair ----- Original Message ----- > From: "Elwyn Davies" > To: > Cc: "Randy Presuhn" ; "Mary Barnes" ; "Scott Hollenbeck" ; ; ; > Sent: Wednesday, August 31, 2005 12:34 PM > Subject: Gen-art review: draft-ietf-ltru-initial-04.txt > > Background for those on the CC list, who may be unaware of GenART: > GenART is the Area Review Team for the General Area of the IETF. We > advise the General Area Director (i.e. the IETF/IESG chair) by providing > more in depth reviews than he could do himself of documents that come up > for final decision in IESG telechat. I was selected as the GenART > member to review this document. Below is my review, which was written > specifically with an eye to the GenART process, but since I believe that > it will be useful to have these comments more widely distributed, others > outside the GenART group are being copied. > > Document: draft-ietf-ltru-initial-04.txt > Intended Status: Informational > Shepherding AD: Scott Hollenbeck > PROTO Shepherd: Randy Presuhn > Review Trigger: IETF Last Call, ends 6 September 2005 > > Review: > The document is a companion to draft-ietf-ltru-registry-12.txt. This document is > generally in good shape and well written. It is essentially > ready for publication, subject to the caveat that I have not made any attempt to > verify the actual proposed record contents. > > One minor point that might be addressed if the draft is recycled for any other > reason is that several of the rules in Section 2 are actually copied from the > companion document. In other circumstances this might be undesirable (double > maintenance etc.) but given that this draft is essentially a 'one shot' it > doesn't much matter as long as they have beeen copied correctly - which appears > to be the case. If the document is recycled it might be worth cross-referencing > the original rules in ltru-registry. > Items 3,4,5 map to s2.2.4 of ltru-registry > Items 7-11 map to s3.2 and s3.3 (Item 12). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 22:22:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAeik-0002fr-4g; Wed, 31 Aug 2005 22:22:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAeig-0002eZ-9G for ltru@megatron.ietf.org; Wed, 31 Aug 2005 22:22:28 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03022 for ; Wed, 31 Aug 2005 22:22:22 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAehT-0004Y6-SQ for ltru@lists.ietf.org; Thu, 01 Sep 2005 04:21:11 +0200 Received: from c-134-88-106.hh.dial.de.ignite.net ([62.134.88.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 04:21:11 +0200 Received: from nobody by c-134-88-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 04:21:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 04:19:04 +0200 Organization: Lines: 52 Message-ID: <43166518.569F@xyzzy.claranet.de> References: <007d01c5ae59$b9f6aa80$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Case sensitive registration (GenArt) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > it's OK to disagree with a review comment Or to agree, if it's something we have missed above the editorial level. > From: "Elwyn Davies" [...] > Subject: Gen-art review: draft-ietf-ltru-registry-12.txt Thanks. > Irritant: > Early in the document it is specifically set out that > language tags are case insensitive and should be normally > represented in lower case. > However, because the corresponding ISO documents use title > case for script codes and upper case for region codes, this > representation has been used in the normative text (ss 2.2.3 > and 2.2.4) It's IMHO better readable this way. Otherwise "fr" vs. "FR" would result in "fr" vs. "fr" gibberish. That's nothing new in the draft, 3066 has the same non-issue. It's not a real issue, because the syntax guarantees that a primary tag "fr" or "fr-" can be always distinguished from a subtag "-fr". But from a purely editorial POV it's better readable to say "fr" vs. "FR" instead of "fr" vs. "-fr". > registrations of these codes MUST use this representation > (s3.2). This struck me as unecessary bureaucracy for > registrants. It would seem to me enough to RECOMMEND that > the registry conform to the case patterns and otherwise > allow users and registrants whatever case they choose. Yes, that makes sense, the language tag reviewer could "fix" it before it's forwarded to IANA. But it would be ugly if all lower case subtags make it to the registry proper, for the reasons outlined above (readability, minimize potential causes for confusion). So this unnecessary bureaucracy is not completely pointless and IMHO harmless. In practice the tag reviewer would just propose to fix an "erroneous" registration request (or do it silently), and so we get the _desired_ effect. Whether that should be a MUST or only RECOMMENDED is also a matter of taste, I'd like to change it as proposed. Bye _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 22:36:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAevu-0006XQ-23; Wed, 31 Aug 2005 22:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAevs-0006XI-Ix for ltru@megatron.ietf.org; Wed, 31 Aug 2005 22:36:04 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03538 for ; Wed, 31 Aug 2005 22:36:01 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAeuY-0006ms-TH for ltru@lists.ietf.org; Thu, 01 Sep 2005 04:34:42 +0200 Received: from c-134-88-106.hh.dial.de.ignite.net ([62.134.88.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 04:34:42 +0200 Received: from nobody by c-134-88-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 04:34:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 04:32:20 +0200 Organization: Lines: 17 Message-ID: <43166834.56D9@xyzzy.claranet.de> References: <007d01c5ae59$b9f6aa80$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Economic groupings (GenArt) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Elwyn Davies wrote: > [Out of interest...] Why not economic groupings? Their > bureaucrats have languages all their own ;-) Yes, nevertheless they are not really "regions". If you'd want something like en-legalese register it as a variant, don't try to approximate it by obscure "region" codes... ...so let's say that the region zoo is already bad, and you found a way to make it worse. The ISO 3166-1 Web page also has tons of obscure WIPO codes. This isn't about regional aspects of languages. Bye, Frank http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html?printable=true#AA _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 22:42:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAf2P-0008DN-VQ; Wed, 31 Aug 2005 22:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAf2P-0008CS-4b for ltru@megatron.ietf.org; Wed, 31 Aug 2005 22:42:49 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03750 for ; Wed, 31 Aug 2005 22:42:46 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAf18-0007rF-4w for ltru@lists.ietf.org; Thu, 01 Sep 2005 04:41:30 +0200 Received: from c-134-88-106.hh.dial.de.ignite.net ([62.134.88.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 04:41:30 +0200 Received: from nobody by c-134-88-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 04:41:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 04:39:54 +0200 Organization: Lines: 11 Message-ID: <431669FA.2E87@xyzzy.claranet.de> References: <007d01c5ae59$b9f6aa80$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Alphabetical ranges (GenArt) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Elwyn Davies wrote: > s3.1: para after ABNF: Numeric ranges? This section talks > about alphabetic ranges such as c..k. Is this supposed to > cover numeric ranges as well? Yes. What's the proper term, "alphanumerically" maybe, or "lexicographically" ? The latter cries for a reference. Thanks, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 22:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfAD-0001Qi-W2; Wed, 31 Aug 2005 22:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfAD-0001Qd-03 for ltru@megatron.ietf.org; Wed, 31 Aug 2005 22:50:53 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03970 for ; Wed, 31 Aug 2005 22:50:49 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAf8w-000130-Lr for ltru@lists.ietf.org; Thu, 01 Sep 2005 04:49:34 +0200 Received: from c-134-88-106.hh.dial.de.ignite.net ([62.134.88.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 04:49:34 +0200 Received: from nobody by c-134-88-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 04:49:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 04:48:39 +0200 Organization: Lines: 15 Message-ID: <43166C07.36D5@xyzzy.claranet.de> References: <007d01c5ae59$b9f6aa80$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] At least one prefix for variant (GenArt) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Elwyn Davies wrote: > s3.4: para next but one after Figure 5: I cannot find the > requirement that Variant subtags have at least one Prefix > field: extlang fields are explicitly specified to have > exactly one but Variants appear to be allowed 0 or more. As you say the difference is "exactly" vs. "at least" one. The last statement in this paragraph is: | Variant registration requests are REQUIRED to include at | least one "Prefix" field in the registration form. Is it that what you're looking for ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 23:05:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfOR-00050o-M7; Wed, 31 Aug 2005 23:05:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfOP-00050j-RK for ltru@megatron.ietf.org; Wed, 31 Aug 2005 23:05:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04521 for ; Wed, 31 Aug 2005 23:05:30 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAfQD-0004Mb-VG for ltru@ietf.org; Wed, 31 Aug 2005 23:07:29 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j8135FuW000313; Wed, 31 Aug 2005 23:05:16 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 31 Aug 2005 23:05:06 -0400 Date: Wed, 31 Aug 2005 23:05:06 -0400 From: "John.Cowan" To: Frank Ellermann Subject: Re: [Ltru] At least one prefix for variant (GenArt) Message-ID: <20050901030506.GE15784@NYCMJCOWA2> References: <007d01c5ae59$b9f6aa80$7f1afea9@oemcomputer> <43166C07.36D5@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43166C07.36D5@xyzzy.claranet.de> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > | Variant registration requests are REQUIRED to include at > | least one "Prefix" field in the registration form. > > Is it that what you're looking for ? Bye, Frank I forgot about this. Do we really want to forbid variants that apply to every language? "signed" would be a reasonable such candidate; it can be applied to any spoken language to specify the (exact) signed equivalent: thus en-signed would be a mapping from English to signs. This is not the same as sign languages proper. -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 23:07:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfQA-0005YL-FZ; Wed, 31 Aug 2005 23:07:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfQ8-0005YG-Av for ltru@megatron.ietf.org; Wed, 31 Aug 2005 23:07:20 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04569 for ; Wed, 31 Aug 2005 23:07:16 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAfOi-0004er-TK for ltru@lists.ietf.org; Thu, 01 Sep 2005 05:05:52 +0200 Received: from c-134-88-106.hh.dial.de.ignite.net ([62.134.88.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 05:05:52 +0200 Received: from nobody by c-134-88-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 05:05:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 05:02:04 +0200 Organization: Lines: 19 Message-ID: <43166F2C.16CD@xyzzy.claranet.de> References: <007d01c5ae59$b9f6aa80$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] More than one script in a tag (GenArt) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org Elwyn Davies wrote: > s4.1: Item 2: example: I am not clear how one would represent > the combination of latin and braille since only one script > subtag seems to be allowed. Maybe there is a special subtag > for the combination? or ist intended that both complete tags > are used? If it's Latin it's not Braille (and v.v.), same idea as Latin vs. Cyril etc. If you're talking about combined documents (e.g. a movie with captions) you could either tag the different parts / aspects separately, or just don't specify the script (or any similar subtag). There are also subtags like "mul", "und", "Zxxx", "Zyyy", "Zzzz", etc. for special purposes. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 23:17:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfZv-0007rN-6B; Wed, 31 Aug 2005 23:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfZt-0007r9-9D for ltru@megatron.ietf.org; Wed, 31 Aug 2005 23:17:25 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04898 for ; Wed, 31 Aug 2005 23:17:21 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAfYi-0006VS-Bo for ltru@lists.ietf.org; Thu, 01 Sep 2005 05:16:12 +0200 Received: from c-134-88-106.hh.dial.de.ignite.net ([62.134.88.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 05:16:12 +0200 Received: from nobody by c-134-88-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Sep 2005 05:16:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 01 Sep 2005 05:14:53 +0200 Organization: Lines: 15 Message-ID: <4316722D.350B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0CA912C3@irvmbxw01.quest.com> <20050831211150.GN14448@NYCMJCOWA2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Recall of the LSR (gen-art #2) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org John.Cowan wrote: >>> Presumably the appointing authority is the unappointing >>> authority too and the body to whom to appeal? >> Those are still good questions. Comments? > The above strategy seems right to me. The IESG giveth and > the IESG taketh away, and the appeal is unto them. +1 It would be a very bad idea if each IANA registry with expert review (charsets, URIs, langtags, etc.) invents its own funny "bureaucracy". Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 31 23:21:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfdS-0008QC-El; Wed, 31 Aug 2005 23:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfdR-0008PY-EB for ltru@megatron.ietf.org; Wed, 31 Aug 2005 23:21:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05097 for ; Wed, 31 Aug 2005 23:21:02 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAffI-0004nP-B8 for ltru@ietf.org; Wed, 31 Aug 2005 23:23:01 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EAfdK-0007ZP-DX; Wed, 31 Aug 2005 20:20:58 -0700 Message-Id: <6.2.3.4.2.20050901042404.048d5e50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 01 Sep 2005 05:20:45 +0200 To: "Randy Presuhn" From: r&d afrac Subject: scaling (was Re: [Ltru] decorum) In-Reply-To: <002101c5adfd$bb84c960$7f1afea9@oemcomputer> References: <002101c5adfd$bb84c960$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru , iesg@iesg.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org At 09:29 31/08/2005, Randy Presuhn wrote: >Before your next posting to the ltru WG mailing list, >please take the time to read the four-page RFC 3184 >ftp://ftp.rfc-editor.org/in-notes/rfc3184.txt thank you. 3. IETF participants think globally, devising solutions that meet the needs of diverse technical and operational environments. The goal of the IETF is to maintain and enhance a working, viable, scalable, global Internet, and the problems we encounter are genuinely very difficult. We understand that "scaling is the ultimate problem" and that many ideas quite workable in the small fail this crucial test. IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user. The Draft is probably the best solution for what the members of the leading affinity group want to address. However exclusives by nature do not scale - they are centralised network constructs. The "0-URI-tag" permits it to scale. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru