Subject: [Ltru] draft-15 posted...

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 10 Jun 2008 12:51:21 -0700

For those who missed it, draft-15 was posted last night by IETF. The various copies are also posted on inter-locale. You can view the editor's copies here:

  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-15.txt
  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-15.html
  http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-15.xml

The diffs are:

  http://tinyurl.com/3whwwg (hwdiff)
  http://tinyurl.com/54zlqq (side-by-side)

The 'Scope' field is in (the text is, obviously, provisional).

Addison (for the Editors)

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Tue, 10 Jun 2008 17:21:54 -0400

Phillips, Addison scripsit:

> For those who missed it, draft-15 was posted last night by IETF. The
> various copies are also posted on inter-locale. You can view the
> editor's copies here:

Arrgh.  I was just about to post comments against -15 when you told us
you just posted -16.  I diffed it and merged the lists.

3.1.2: In "The values permitted in this field are 'individual',
'macrolanguage', 'collection', or 'special'.", s/or/and/.

3.1.10 under 'collection': s/enclosed languages/languages that belong
to it/; s/historical/historical, geographical/.

3.1.10: s/will have a Scope of 'macrolanguage'/& and vice versa/.

3.4, bullet points 12.1, 12.3.2 (twice), also 3.5:
s/enclosed/encompassed/.

3.4, bullet point 12.1: s/cannot be extended/cannot be given extended/.

3.4, bullet point 12.3.1: confusing, reword something like this:

	If a language has a macrolanguage mapping, and the macrolanguage
	has other encompassed languages with extended language subtags
	assigned, then the new language should have an 'extlang' record
	as well.  For example, any language with a macrolanguage of 'zh'
	or 'ar'.

4.1.1: freak "#&12288;" in plain text.

4.1.2: In "Malay ('ms') or Uzbek", s/or/and.

4.1.2 third bullet point:  s/langauge/language/.

4.1.2: s/spoken and the written/spoken, and the written/; s/is spoken
commonly/is commonly spoken/.

4.1.2 last graf: remove "Sign languages also provide this mechanism."
and the paragraph break before it, and add to the end:

	"sgn-US" used to mean American Sign Language specifically, without
	reference to the United States, is still valid but deprecated.

8: s/many more languages and dialects/many more language collections
and languages/.

-- 
Your worships will perhaps be thinking          John Cowan
that it is an easy thing to blow up a dog?      http://www.ccil.org/~cowan
[Or] to write a book?
    --Don Quixote, Introduction                 [email-masked]
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Tue, 10 Jun 2008 17:25:03 -0400

> 	reference to the United States, is still valid but deprecated.

Yeah, umm, let's make that s/"sgn-US" used/"sgn-US", when used/.

-- 
A rose by any other name                            John Cowan
may smell as sweet,                                 http://www.ccil.org/~cowan
but if you called it an onion                       [email-masked]
you'd get cooks very confused.          --RMS
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 10 Jun 2008 15:40:44 -0700

(editor hat ON)

> Arrgh.  I was just about to post comments against -15 when you told
> us you just posted -16.  I diffed it and merged the lists.

Draft-16 exists to receive edits :-).

> 'macrolanguage', 'collection', or 'special'.", s/or/and/.

DONE.

> to it/; s/historical/historical, geographical/.

DONE and DONE.

> 3.1.10: s/will have a Scope of 'macrolanguage'/& and vice versa/.

DONE.

> 3.4, bullet points 12.1, 12.3.2 (twice), also 3.5:

DONE.

> 3.4, bullet point 12.1: s/cannot be extended/cannot be given

DONE.

>         as well.  For example, any language with a macrolanguage of

DONE. Text reads:

<t>If a language has a macrolanguage mapping, and that macrolanguage has other encompassed languages that are assigned extended language subtags, then the new language SHOULD have an 'extlang' record assigned to it as well. For example, any language with a macrolanguage of 'zh' or 'ar'.</t>
> 4.1.1: freak "#&12288;" in plain text.

Fixed. My IME hates me.

> 4.1.2: In "Malay ('ms') or Uzbek", s/or/and.

DONE.
> 4.1.2 third bullet point:  s/langauge/language/.

Found and replaced two occurrences.
> commonly/is commonly spoken/.

DONE.

>         reference to the United States, is still valid but

Some of the other 'sgn' languages have this problem also. Text now reads (omitting first part of graf):

--
A number of sign languages also had grandfathered tags registered for them during the RFC 3066 era. For example, the grandfathered tag "sgn-US" used to mean 'American Sign Language' specifically, without reference to the United States. This is still valid, but deprecated: a document in American Sign Language can be labeled either "ase" or "sgn-ase" (the 'ase' subtag is for the language called 'American Sign Language').
--

> 8: s/many more languages and dialects/many more language

Good, although I reversed the pair to be "... many more languages and language collections." This puts the emphasis where it more properly belongs, I think.

Addison

---

From: Shawn Steele <[email-masked]>
Date: Tue, 10 Jun 2008 16:05:51 -0700

A item...

I'd like to see it a little stronger that the more specific Mandarin/Cantonese tag SHOULD be used although the less specific zh Chinese flag MAY be used if necessary.  -15 goes to great length to state that zh MAY be used, however I didn't see it clearly say that the more specific tag SHOULD be used if possible.

- Shawn

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 10 Jun 2008 16:12:17 -0700

Hi Shawn,

Please suggest specific text for a specific location or locations. This makes the editors' lives easier.

Addison

Addison Phillips

> -----Original Message-----
> From: Shawn Steele [mailto:[email-masked]]
> Sent: Tuesday, June 10, 2008 4:06 PM
> To: John Cowan; Phillips, Addison
> Cc: 'LTRU Working Group'
> Subject: RE: [Ltru] draft-15 posted...
>
> A item...
>
> I'd like to see it a little stronger that the more specific
> Mandarin/Cantonese tag SHOULD be used although the less specific zh
> Chinese flag MAY be used if necessary.  -15 goes to great length to
> state that zh MAY be used, however I didn't see it clearly say that
> the more specific tag SHOULD be used if possible.
>
> - Shawn

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Jun 2008 10:39:59 +0200

On Tue, Jun 10, 2008 at 04:05:51PM -0700,
 Shawn Steele <[email-masked]> wrote 
 a message of 9 lines which said:

> -15 goes to great length to state that zh MAY be used, however I
> didn't see it clearly say that the more specific tag SHOULD be used if
> possible.

That's not the way I read it.

>From -15 :

> This primary language subtag is RECOMMENDED for forming the language
> tag.

> while the primary language subtag ('gan', 'yue', 'cmn') is preferred
> to using the extended language form ("zh-gan", "zh-yue", "zh-cmn").

> The more specific encompassed language subtag SHOULD be used to form
> the language tag, although either the macrolanguage's primary
> language subtag or the encompassed language's subtag MAY be used.

What else do you want?

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 11 Jun 2008 10:53:06 +0200

Some ABNF-bashing:

The -14 draft had

   "no-bok" / "no-nyn"
 / "zh-cmn" / "zh-cmn-Hans" / "zh-cmn-Hant" / "zh-gan"     
 / "zh-min" / "zh-min-nan" / "zh-wuu" / "zh-yue"

as 'irregular', while for the new -15 draft these are all "regular",
i.e. covered by other (reinstated) parts of the grammar. In particular,
except for the script subtags:

     extlang       = "-" 3ALPHA             ; selected ISO 639 codes  
                     *2[ "-" 3ALPHA]        ; permanently reserved 

But 'bok' and 'nyn' aren't 639 codes (in particular not for nb/nn),
and while 'min' is in 639, it stands for a language unrelated to the
one intended by 'zh-min'. Further, in  zh-min-nan, the nan part goes
into the second extlang part which is said to be "permanently reserved".

While this might not affect registry entries, this grammar is confusing
and very far from my liking. Please keep these problem cases ("no-bok" /
"no-nyn" / "zh-min" / "zh-min-nan") as "irregular" even if they are also
(incorrectly) covered by other parts of the grammar, noting that the
"regular" part of the grammar MUST NOT be used for these problem cases.

Note that the 'irregular' tags don't allow for adding script code,
region code, variant codes, extension codes, or private use codes.

B.t.w. I'd like to see the non-extlang versions of the now introduced
extended double-coding to be the preferred coding. Indeed, I would
still prefer to go back to the -14 grammar, and no extlangs at all.

	/kent k

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Phillips, Addison
> Sent: Tuesday, June 10, 2008 9:51 PM
> To: 'LTRU Working Group'; 'LTRU Working Group'
> Subject: [Ltru] draft-15 posted...
> 
> For those who missed it, draft-15 was posted last night by 
> IETF. The various copies are also posted on inter-locale. You 
> can view the editor's copies here:
>

---

From: Martin Duerst <[email-masked]>
Date: Wed, 11 Jun 2008 17:58:17 +0900

>> language subtag or the encompassed language's subtag MAY be used.

Slightly unrelated, but I'd want some examples in the last paragraph.
Terms such as "macrolanguage's primary language subtag" are easiest
to understand for a large number of people simply by looking at examples.
Also, I'd note that the above text doesn't distinguish between using
"zh" and "zh-something", i.e. no preference is given.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Jun 2008 09:45:37 -0400

> into the second extlang part which is said to be "permanently reserved".

Nevertheless, we don't want an ambiguous grammar.  The grammar of RFC
4646 is ambiguous (it provides more than one way to parse "abc-def-ghi")
and excessive (it accepts things like "abcde-abcde-abcde"), and it has
in fact confused parser writers in the past.  By clearly distinguishing
between syntactically irregular and semantically grandfathered tags
(all irregular tags are grandfathered, but not all grandfathered tags
are irregular) we achieve a clean separation of syntax and semantics.
This is a Good Thing.

> "regular" part of the grammar MUST NOT be used for these problem cases.

That's what we did in RFC 4646, and it was *more* confusing.

> region code, variant codes, extension codes, or private use codes.

That is deliberate.  They are grandfathered, not productive, and at
the end of this process essentially all of them will be deprecated,
with productive replacements.  All this irregularity and grandfathering
is backward compatibility cruft, and we don't want to make more of it
than history requires us to.

-- 
Knowledge studies others / Wisdom is self-known;      John Cowan
Muscle masters brothers / Self-mastery is bone;       [email-masked]
Content need never borrow / Ambition wanders blind;   http://ccil.org/~cowan
Vitality cleaves to the marrow / Leaving death behind.    --Tao 33 (Bynner)
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 11 Jun 2008 16:45:33 +0200

> 4646 is ambiguous (it provides more than one way to parse "abc-def-ghi")

But not in draft -14 for 4646bis, which does not allow that in general,
but allows similar codes in exceptional cases (grandfathered and irregular).

> and excessive (it accepts things like "abcde-abcde-abcde"), and it has

4646bis still allows that; registered primary language 'abcde' (out of which
we so far have none registered) followed by two variants 'abcde'.

> between syntactically irregular and semantically grandfathered tags

The syntax in draft -14 for 4646bis did...

> That's what we did in RFC 4646, and it was *more* confusing.

I was referring to 4646bis draft -14, which I think got this right.
But now, for no good reason that I can see, we have reinstated extlang,
leading to these problems.

> than history requires us to.

I still contend that the grammar in -15 is misleading, in a "Bad Way".

I still suggest to restore the four problem tags as 'irregular', and for
the extlang I suggest to add a comment to the production like this:

     extlang       = "-" 3ALPHA             ; selected ISO 639 codes,
                                              '-bok', '-nyn', and '-min'
                                              are not allowed to match
                     *2[ "-" 3ALPHA]        ; permanently reserved

While that is informal, it can be formally excluded by accompaning
normative text (next paragraph in this email). It could be built into
the ABNF productions, but that would become very lengthy (and confusing).

| For the first extlang production, '-bok', '-nyn', and '-min'
| MUST NOT match.

Ok, that excludes 'bok', 'nyn', and 'min as *extlangs* not only for 'no'
but also for 'zh' and other extlang taking primary language codes. I don't
see that as a problem, since 'bok', 'nyn', and 'min' will be registered as
individual languages, not extlangs, via 4645bis. This solution also implies
excluding 'nan' as a second extlang item when parsing "zh-min-nan".

	/kent k

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Jun 2008 11:11:40 -0400

> but allows similar codes in exceptional cases (grandfathered and irregular).

There is no difference in principle between -14 and -15.  Each has a list
of irregular tags in the BNF for grandfathered tags that would otherwise
not be well-formed.  Each has many grandfathered tags that are well-formed
but would not be valid (e.g. "zh-hakka", which is a language, not a
language variant).  Expanding the BNF, as -15 does, necessarily shrinks
the list of irregular tags.  (It so happens that it shrinks the list of
grandfathered tags as well; e.g. "zh-yue" is no longer grandfathered.)

> 4646bis still allows that; registered primary language 'abcde' (out of
> which we so far have none registered) followed by two variants 'abcde'.

My bad: "abc-abcd-ab", then, which is accepted by the 4646 BNF as a
grandfathered tag, though there is no grandfathered tag of that form.

> > By clearly distinguishing

As does the syntax in -15.

> leading to these problems.

If you don't like extlangs, you don't.  But that's a separate issue
from the notion that the irregular list should contain all those
and only those tags that are grandfathered valid but not generated
by the BNF.

>      extlang       = "-" 3ALPHA             ; selected ISO 639 codes,

If you plant enough exclusions and inclusions in the BNF, you can probably
gerrymander the whole irregular list (and maybe the grandfathered list)
out of existence.  But then you've lost track of what the BNF is *about*.

The BNF allows you to determine which tags are well-formed, but the point
of being well-formed is that once you have excluded the fixed list of
grandfathered tags, you can dissect a tag into its subtags and understand
what each subtag is for (language, extlang, script, region, variant,
private-use or registered extension) *without* looking at the registry.
The more crap there is in the BNF, the harder that is to do.

-- 
Samuel Johnson on playing the violin:           John Cowan
"Difficult do you call it, Sir?                 [email-masked]
 I wish it were impossible."                    http://www.ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 11 Jun 2008 17:31:30 +0200

> As does the syntax in -15.

No, it does not. "Semantically irregular" tags are parsed as if they
are "syntactically regular". I find that to be a "Bad Thing".

> out of existence. 

I did not suggest that (though I'm not quite sure what you mean here).

>                 But then you've lost track of what the BNF is *about*.
>

My point is that one should be able to correctly parse the input WITHOUT
looking at the registry, not even need to look up grandfathered tags in
the registry (which of course still should be in the registry).

'bok', 'nyn', and 'min' aren't extlangs in any way, even though they
come after the primary language in *valid* tags, and they should not be
parsed as if they were extlangs. I would rather have an ambigous grammar,
than one that is outright wrong, falsely parsing those items as extlangs.

		/kent k

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 11 Jun 2008 08:37:15 -0700

I strongly agree with John.

Mark

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Jun 2008 12:54:52 -0400

> are "syntactically regular". I find that to be a "Bad Thing".

Both -14 and -15 did so: "art-lojban" is semantically irregular, but
both drafts parse it as syntactically regular.

> looking at the registry, not even need to look up grandfathered tags
> in the registry (which of course still should be in the registry).

You can do that by hard-coding the grandfathered tags, since the list
of them cannot grow.

You cannot do that with no knowledge of the grandfathered tags at all.

> come after the primary language in *valid* tags, and they should not
> be parsed as if they were extlangs.

By the same token, 'lojban', 'gaulish', 'guoyu', 'hakka', and 'xiang'
aren't variants in any way.  You are cherry-picking, objecting to
grandfathered but not irregular tags in the case you don't like and
saying nothing about the other cases.

(In fact, these eight are the *complete* list of semantic anomalies.
When 4646bis is in place, only "cel-gaulish" and "zh-min" will remain
undeprecated, primarily because they are languages collections or
macrolanguage without equivalent 639 code elements.)

> I would rather have an ambiguous grammar,

We may conclude that you are not a parser author.

> than one that is outright wrong, falsely parsing those items as

It is not "outright wrong", and its limitations are clearly stated.

-- 
Andrew Watt on Microsoft:                       John Cowan
Never in the field of human computing           [email-masked]
has so much been paid by so many                http://www.ccil.org/~cowan
to so few! (pace Winston Churchill)
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 11 Jun 2008 10:40:16 -0700

> macrolanguage without equivalent 639 code elements.)

Small nit: "zh-min" *will* be deprecated. The code for Min Nan is 'nan'. Also, at present, xx-yyy is deprecated in favor of yyy (I know you prefer the opposite).

> It is not "outright wrong", and its limitations are clearly stated.

It is wrong to interpret the semantic meaning of the grandfathered tags on the basis of the ABNF grammar, in fact, it is "outright wrong" to do so. In my case, my "well-formed" checker relies strictly on the regular expressions Mark and I derived from the ABNF, so it doesn't detect cases where the semantic meaning is "outright wrong". However, all of my other checking is based on checking a list of grandfathered first and then parsing. I should note that matching schemes don't care about the semantic meaning of subtags, grandfathered or otherwise. This mostly works because the ones that use "real" subtag prefixes are intended to work.

Addison

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 11 Jun 2008 19:55:39 +0200

John Cowan [mailto:[email-masked]] 
> saying nothing about the other cases.

Ok. Not to be cherry-picking, these should be called out in the grammar
as well, not to parse them as variants.

> macrolanguage without equivalent 639 code elements.)

draft-ietf-ltru-4645bis-05 lists zh-min as deprecated. While there is
discussion about zh-min and friends in the introduction, cel-gaulish
has no discussion...

> We may conclude that you are not a parser author.

Well, I am. But the tools I, and many others, use will resolve such
ambiguites in particular and well-known ways. Even without using tools,
it is not hard to get the correct (disambiguated in the intended way)
*parse* as long as the exceptions are called out explicitly. (And they
will be misparsed by many, not just by "me", if the exceptions are not
called out explicitly.) I don't really want to reparse the parsed tag
after having done the grammatical parse, and restructure the parse if
the reparse finds that the first parse was wrong. I don't think other
implementers want to do a reparse+restructure either, not even expect
to do that at all (nor the other way around, dealing with the grandfathered
tags first). If one really wants to do a semantic-less simple parse,
just using the production 'language-range = (1*8ALPHA *("-" 1*8alphanum))'
(not the '*' production) would be just fine, I guess.

	/kent k

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Jun 2008 15:13:40 -0400

Phillips, Addison scripsit:

> Small nit: "zh-min" *will* be deprecated. The code for Min Nan is
> 'nan'.

Min Nan is currently zh-min-nan, which will be deprecated in favor of
either nan or zh-nan.  Zh-min, on the other hand, is the collection
{'mnp', 'cdo', 'nan', 'czo'}, respectively the Min Bei 'northern',
Min Dong 'eastern', Min Nan 'southern', and Min Zhong 'central' Chinese
languages.  There is nothing to deprecate this to, because there is no
corresponding macrolanguage in -3 or collection in -5., so we are stuck
with it.  Roughly speaking, it is the collection of Sinitic languages
without /f/, which separated from the other Sinitic languages very early,
possibly before the Middle Chinese period that represents the underlying
unity of the rest.

> Also, at present, xx-yyy is deprecated in favor of yyy (I know
> you prefer the opposite).

True, but that doesn't affect any of the grandfathered languages.
Either zh-yue will become redundant, or it will become redundant and
deprecated, but in either case it will not be grandfathered any more.

-- 
Why are well-meaning Westerners so concerned that   John Cowan
the opening of a Colonel Sanders in Beijing means   [email-masked]
the end of Chinese culture? [...]  We have had      http://www.ccil.org/~cowan
Chinese restaurants in America for over a century,
and it hasn't made us Chinese.  On the contrary,
we obliged the Chinese to invent chop suey.            --Marshall Sahlins
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 11 Jun 2008 21:28:31 +0200

John Cowan wrote:

>                     Zh-min, on the other hand, is the collection

So then it should have a "Scope: collection" field as well, but that
would not be gotten from 639-5, obviously. Not sure why this collection
is deprecated, given that we don't deprecate all collection codes (as
well as macrolanguage codes...). Deprecating collection codes has been
suggested (long ago by several persons, me included), but does not
seem to have gotten enough support. I think there is a point in being
able to indicate partial knowledge, though.

	/kent k

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Jun 2008 15:41:33 -0400

Kent Karlsson scripsit:

> So then [zh-min] should have a "Scope: collection" field as well, but that

It isn't the collection that deserves to be deprecated, but the
grandfathered code element.  If -5 introduces a collection tag for
it, fine.

If everything that can be deprecated in RFC 4645bis is deprecated,
we will wind up with the following five undeprecated grandfathered
tags:  "zh-min", "en-GB-oed", "i-enochian", "i-mingo", and "i-default".
"zh-min" could be deprecated if 639-5 introduces a collection tag for it;
"en-GB-oed" and "i-mingo" if ietf-languages register variant subtags
for them, and "i-enochian" if ietf-languages registers a language subtag
for it.  That leaves only "i-default", which is very special and required
by RFC 2277.

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 11 Jun 2008 12:42:23 -0700

Argh.

I looked up 'min' in ISO 639-3, where it is a language code for the language Minangkabau, which is an Indonesian language unrelated to this discussion. There is no ISO 639-5 collection for this grouping, AFAICT.

The grandfathered tag "zh-min" is a tag for "Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese".

There is no *formal* collection specifically for these languages other than this tag. It is just a grandfathered bit of cruft. Which means that John's original statement about this tag is correct and my nit incorrect, provided one does not read the word "collection" to mean ISO 639-5 collection.

Addison Phillips

> Behalf Of Kent Karlsson
> Sent: Wednesday, June 11, 2008 12:29 PM
> To: 'LTRU Working Group'
> Subject: Re: [Ltru] draft-15 posted...
>
>
> John Cowan wrote:
>

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Jun 2008 15:52:50 -0400

Phillips, Addison scripsit:

> There is no *formal* collection specifically for these languages
> other than this tag. It is just a grandfathered bit of cruft. 

Specifically, Fuzhou is a variety of Min Dong, and the last three are
varieties of Min Nan.  Just to make things worse, it is not clear whether
Pu-Xian Chinese ('cpx') is or is not included.  Linguistically yes,
nomenclaturally no....

As you say, cruft.

-- 
John Cowan  [email-masked]  http://ccil.org/~cowan
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.
        --Gerald Holton
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru