Subject: Re: [Ltru] [psg.com #966] remove something from security considerations

From: "Doug Ewell" <[email-masked]>
Date: Sat, 28 May 2005 12:03:01 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

>>> Comment 38 in
>>> http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html
>>> reads:
>>> "38. 4. security considerations should not deal with users political
>>> security outside of their network usage. Otherwise tons of such
>>> considerations should be presented."
>>>
>>> followup in
>>> http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html
>>
>> (apologies for the vague subject line - if someone can give me
>> something more precise, I'll happily change it.)
> ...
>
> No one provided specific text, and there were no follow-ups in favor
> of this proposal, so I've marked it "rejected".

I'm happy to let the rejection stand, but in case it is challenged, I
can provide a follow-up against this proposal.

One, the wording in question deals with "language identifiers used in
content negotiation... that... may be used to infer the nationality of
the sender."  So, to the extent that the content being negotiated is
sent via the Internet, this wording does indeed deal with security
related to network usage.

Two, the wording was carried over from RFC 3066, as a response to the
passage in RFC 1766 that said "Security issues are not discussed in this
memo" (not "believed to be irrelevant," as quoted in RFC 3066).  The
intent at that time was apparently that the wording about content
negotiation and surveillance *was* considered appropriate for the RFC.
An attempt to overturn this decision would have to provide more detail
than a single line.  Alternatively, if there are "tons of such
considerations," then they would have to be spelled out instead of just
alluded to.

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

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 28 May 2005 12:13:36 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> I've created a ticket for this proposal: [psg.com #1011]

I agree that more Suppress-* categories should not be created.

Specifically, I agree with John Cowan that Suppress-Script was created
as a response to charges that RFC 3066bis tags would be incompatible
with RFC 3066 matching algorithms, not as a general guide to best
tagging practices.

Addison stated that extended-language subtags might also be candidates
for Suppression, because (like scripts) they are positioned between the
primary language and region subtags.  I worry about this because an
extended-language subtag would probably denote a genuinely different
language, and suppressing it would greatly change the meaning of the
tag.

---

From: John Cowan <[email-masked]>
Date: Sat, 28 May 2005 16:01:39 -0400

> language, and suppressing it would greatly change the meaning of the

It's a difficult question.  Probably most of the time when someone
uses "ar", they mean "ar-arb", standard Arabic.  But some of the time
they mean, or may mean, any Arabic whatsoever.  It's precisely
this dichotomy that led Peter Constable to introduce the notion of
macrolanguages.

If we used suppression in this case, we'd be saying that "ar" means
always and only Standard Arabic henceforward, possibly undermining
existing usage.  Better to leave "ar" as deliberately vague and allow
"ar-arb" for specificity.

What we *will* need when we come to put extlang entries into the registry
is a new header "Language-subtag" showing which (singular) language subtag
they can be used with; thus "arb" will point to "ar".

-- 
Work hard,                                      John Cowan
play hard,                                      [email-masked]
die young,                                      http://www.reutershealth.com
rot quickly.                                    http://www.ccil.org/~cowan

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 28 May 2005 13:32:00 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> Consequently, as a technical contributor, I think we should reject
this
> proposal, as supporting "_every_ Internet Standard Process needs, past
and
> future" would be like trying to boil the ocean, preventing us from
> completing our assigned task in a timely manner.

I agree.

Since this "universality" issue has been used to try to demonstrate that
the draft should not be considered for BCP status, I would also add that
RFC 2026 (BCP 9) makes no statement that a Best Current Practice must
support, or claim to support, every conceivable Internet Standard
Process need, let alone that it should try to predict future needs.

The RFC Index Search Engine
<http://www.rfc-editor.org/cgi-bin/rfcsearch.pl> did not indicate that
RFC 2026 has been obsoleted or superseded in any way related to this
issue, but if someone can point to a more recent document that touches
on it, please do so.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 29 May 2005 13:25:55 +0200

John Cowan wrote:
 
> What we *will* need when we come to put extlang entries into
> the registry is a new header "Language-subtag" showing which
> (singular) language subtag they can be used with; thus "arb"
> will point to "ar".

That's like Recommended-Prefix.

I'm still lost with multiple extlang-s in a tag, how many in
which order ?  Draft -03pre still says *( "-" extlang ).  The
maximum Recommended-Prefix allows 17 extlang-s.  

We are sure that this will never happen, and it wouldn't work
in encoded word (RfC 2047).  But the draft -03pre doesn't say
so, it also does not yet mention RfC 2047 together with 2231.

This one * before extlang in the ABNF will fascinate developers
in the "last call", it triggers nightmares of buffer overflows
and memory leaks.
                    Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 29 May 2005 13:40:46 +0200

Doug Ewell wrote:

> Alternatively, if there are "tons of such considerations,"
> then they would have to be spelled out instead of just
> alluded to.

It's not pure science fiction, I just checked that you don't
have a Suppress-Script for Tatar (tt) (= let's NOT add Cyrl),
and you reported a dispute about Latn for Moldavian (mo).

It's nothing we can do about in the Security Considerations
or elsewhere in the draft, but it's no nonsense.  Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 29 May 2005 11:10:33 -0400

> That's like Recommended-Prefix.

No, it's mandatory: you can only use 'arb' with 'ar', never with any other
language subtag.  But it could be called "Required-Prefix".

> maximum Recommended-Prefix allows 17 extlang-s.  

The only way multiple extlangs can arise is if language B, which is
encompassed by macrolanguage A, is itself reanalyzed as a macrolanguage
encompassing languages C, D, etc.  That would make A-B-C and A-B-D valid
(partial) language tags.

Order would be significant for matching purposes, but could be
reconstructed from the registry by following the Required-Prefix pointers.

-- 
John Cowan      [email-masked]        http://www.ccil.org/~cowan
        Is it not written, "That which is written, is written"?

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 29 May 2005 19:41:05 +0200

> No, it's mandatory: you can only use 'arb' with 'ar', never
> with any other language subtag.  But it could be called
> "Required-Prefix".

Maybe we should say "Prefix:", with REQUIRED for extlang, and
RECOMMENDED elsewhere.  These long field names are ugly, and
too may different field names are a zoo.

> That would make A-B-C and A-B-D valid (partial) language
> tags.  Order would be significant for matching purposes, but
> could be reconstructed from the registry by following the
> Required-Prefix pointers.

Pray that nobody wants E-C or E-D.  Okay, there can be more
than one Recommended-Prefix, it should still work.  Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 29 May 2005 14:12:58 -0400

> too may different field names are a zoo.

I think that would be easy to make a mistake about.

> Pray that nobody wants E-C or E-D.  

That wouldn't make any sense.  It may be a matter of context whether
Chadian Spoken Arabic ('shu') is a separate language or just part of the
Arabic macro-language; it's uncontroversial that it's Arabic and not
(say) Chinese, so "zh-shu" can be ruled out as invalid.

Similarly, the Auvergnat language is encompassed by the Occitan
macrolanguage, so in 3066ter-speak it would be designated "oc-auv".
Suppose that further research shows that the Haut-Auvergnat and
Bas-Auvergnat dialects are really more distinct than we now believe,
and they deserve separate ISO 3166 language codes, say 'avh' and 'avx'
respectively (insert "the good ones are all taken" lament here).

Then Auvergnat might become a macrolanguage within a macrolanguage,
and the two newly recognized languages would be coded "oc-auv-avh" and
"oc-auv-avx".  But it wouldn't ever make sense to refer to "en-avh"
(Haut-Auvergnat as encompassed by the individual language English) or
"sql-avx" (Bas-Auvergnat as encompassed by the macrolanguage Albanian).
The required prefix for 'avh' and 'avx' would be "oc-auv", just as the
required prefix for 'auv' is 'oc'.

(Seventeen levels of splitting is way more than enough under any conceivable
scenario, and I do think that word means what I think it means.)

-- 
Income tax, if I may be pardoned for saying so,         John Cowan
is a tax on income.  --Lord Macnaghten (1901)           [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 29 May 2005 21:36:31 +0200

John Cowan wrote:

 [Prefix for both RECOMMENDED and REQUIRED cases] 
> I think that would be easy to make a mistake about.

Required-Prefix
Macro-Language

We could just say what it means.  3066ter territory,
but Randy wanted us to prepare everything as far as
possible.

> It may be a matter of context whether Chadian Spoken Arabic
> ('shu') is a separate language or just part of the Arabic
> macro-language; it's uncontroversial that it's Arabic and
> not (say) Chinese, so "zh-shu" can be ruled out as invalid.

Okay, that's a detail not yet stated in the draft, I didn't
know that zh-shu for a hypothetical "southern Hu" isn't
allowed as soon as an ar-shu exists.  

If the "Macro-Language" is always unique and implicit, why
bother with it ?  Is it about a hypothetical shu vs. ar-shu ?

> (insert "the good ones are all taken" lament here)

"26**3 ought to be enough for everybody".  Hm, actually it's
not that much, minus 20*26 for qaa..qtz, plus 26**2 alpha-2,
17732 if I got this right.
                           Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 29 May 2005 16:40:54 -0400

> allowed as soon as an ar-shu exists.  

Correct: 'shu' always means Chadian Spoken Arabic in ISO 639-3.

> bother with it ?  Is it about a hypothetical shu vs. ar-shu ?

No.  It's yet another compromise with standard matching algorithms.
If a resource in Chadian Arabic were to be tagged simply "shu", a
client looking for Arabic of all sorts would have to have specialized
knowledge to recognize "shu" (and 29 other language subtags) as
equivalent.  By requiring "ar-shu" instead, we make it easy for
such a client, whereas a client wanting Standard Arabic specifically
can request "ar-arb" specifically.  Banning "shu" by itself eliminates
double coding for the same thing.

> 17732 if I got this right.

In fact every alpha-2 code has an alpha-3 equivalent (not used in 3066),
so you can't count those separately.  Still, 2,541,865,827,809 codes is quite
a lot of codes.  Only a few, however, can possibly have mnemonic value.

-- 
"Well, I'm back."  --Sam        John Cowan <[email-masked]>

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 29 May 2005 23:34:45 +0200

John Cowan wrote:

> yet another compromise with standard matching algorithms.

What kind of a compromise is this, replicate redundant info
in billions of tags instead of once in the registy ?  That
strikes me as abuse^Wodd, to put it politely.

Cc: Randy, that doesn't fly without a formal ticket number.

Not only is the *("-" extlang) a PITA, it's also _redundant_ ?

> If a resource in Chadian Arabic were to be tagged simply
> "shu", a client looking for Arabic of all sorts would have
> to have specialized knowledge to recognize "shu" (and 29
> other language subtags) as equivalent.  By requiring "ar-shu"
> instead, we make it easy for such a client

Okay, old clients might look for ar wanting also ar-TD or the
future ar-shu or ar-shu-TD.  New servers or new clients could
know that ar includes shu.

So that's about an old client with an old server and some new
shu content.  What a headache.  But in theory old clients could
say ar or shu or ... in an Accept-Language.

> whereas a client wanting Standard Arabic specifically can
> request "ar-arb" specifically.  Banning "shu" by itself
> eliminates double coding for the same thing.

I have to think about this for a while.  It was a big surprise,
thanks for info.  It's ODD.  Why no de-nds instead of nds, what
is the difference from ar-shu by definition ?  Where is this
definition, who decides about it, and do we trust them to get
it right ?

> In fact every alpha-2 code has an alpha-3 equivalent (not
> used in 3066), so you can't count those separately.

Okay, 26**3 - 20*26 = 17056.

> 2,541,865,827,809 codes is quite a lot of codes.

That's 3**26, not 26**3.  The CS disaster was no accident. ;-)

                          Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 29 May 2005 18:37:43 -0400

> Cc: Randy, that doesn't fly without a formal ticket number.

It's an RFC 3066ter feature, so we don't need to deal with it yet.

> Not only is the *("-" extlang) a PITA, it's also _redundant_ ?

Technically, yes.

> know that ar includes shu.

Currently you don't have to have access to the registry to do matching,
only to do validity checking.  I think that's as it should be.

> say ar or shu or ... in an Accept-Language.

Some clients.  Java resource matching doesn't work that way: the client
specifies one language-tag and gets the narrowest resource that matches.

> is the difference from ar-shu by definition ?

Basically because "German"/"Deutsch" normally means the standard language
including its regional varieties, but does not include the true Mundarten.
"Arabic" does include both the standard language and its colloquials.

> Where is this definition,

In ISO 639-3, or at present the draft thereof.

# In this example, it may appear that the single identifiers in ISO
# 639-1 and ISO 639-2 should be designated as collective language
# identifiers. That is not assumed here, however. In various parts of the
# world, there are clusters of closely-related language varieties that,
# based on the criteria discussed in 4.2.1, can be considered individual
# languages, yet in certain usage contexts a single language identity
# for all is needed. Typical situations in which this need can occur
# include the following:
#
# ⎯ There is one variety that is more developed and that tends to be
#   used for wider communication by speakers of various closely-related
#   languages; as a result, there is a perceived common linguistic identity
#   across these languages. For instance, there are several distinct spoken
#   Arabic languages, but Standard Arabic is generally used in business
#   and media across all of these communities, and is also an important
#   aspect of a shared ethno-religious unity. As a result, a perceived
#   common linguistic identity exists.
#
# ⎯ There is a common written form used for multiple closely-related
#   languages. For instance, multiple Chinese languages share a common
#   written form.
#
# ⎯ There is a transitional socio-linguistic situation in which
#   sub-communities of a single language communityare diverging, creating
#   a need for some purposes to recognise distinct languages while, for
#   other purposes, a single common identity is still valid. For instance,
#   in some business contexts it is necessary to make a distinction between
#   Bosnian, Croatian and Serbian languages, yet there are other contexts
#   in which these distinctions are not discernable in language resources
#   that are in use.
#
# Where such situations exist, an identifier for the single, common
# language identity is considered in this part of ISO 639 to be a
# macrolanguage identifier.

> who decides about it,

The ISO 639-3/RA, or at present Peter Constable, the editor of 639-3.

> and do we trust them to get it right ?

I do, anyhow.

> That's 3**26, not 26**3.  The CS disaster was no accident. ;-)

Oops.  17056 it is.  Still plenty if you don't care about mnemonicity.

-- 
John Cowan      http://www.ccil.org/~cowan      [email-masked]
Be yourself.  Especially do not feign a working knowledge of RDF where
no such knowledge exists.  Neither be cynical about RELAX NG; for in
the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass.  --DeXiderata, Sean McGrath