Subject: Re: [Ltru] Re: WGLC security considerations

From: r&d afrac <[email-masked]>
Date: Wed, 17 Aug 2005 00:44:07 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Aug 2005 04:10:39 +0200

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

---

From: Martin Duerst <[email-masked]>
Date: Wed, 17 Aug 2005 11:49:35 +0900

[chair hat off, and mostly off topic]

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.

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?

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.

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.

---

From: r&d afrac <[email-masked]>
Date: Wed, 17 Aug 2005 13:24:36 +0200

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

---

From: r&d afrac <[email-masked]>
Date: Wed, 17 Aug 2005 14:50:35 +0200

>makes no sense for me.  Language tags and / or charsets are

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.

>There are uses, abuses, and errors.  Not very surprising, that

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.

>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.

>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.

>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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Aug 2005 16:28:41 +0200

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Aug 2005 13:00:06 -0700

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