Subject: [Ltru] Status of 4645bis and 4646bis

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Jun 2009 11:26:51 +0100

Hi,
A bit of good news: both documents were approved for publication by IESG 
yesterday. 4645bis doesn't require any changes and the announcement 
would be sent out around Monday-Tuesday next week. For 4646bis, there is 
one extra change (addition) that needs to be done to the document - some 
text about applicability statement, i.e. for which purposes the IANA 
registry can and can't be used, what it wasn't designed for. I am likely 
to suggest some text on this in a separate message.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Jun 2009 14:32:14 +0100

Alexey Melnikov wrote:

> Hi,
> A bit of good news: both documents were approved for publication by 
> IESG yesterday. 4645bis doesn't require any changes and the 
> announcement would be sent out around Monday-Tuesday next week. For 
> 4646bis, there is one extra change (addition) that needs to be done to 
> the document - some text about applicability statement, i.e. for which 
> purposes the IANA registry can and can't be used, what it wasn't 
> designed for. I am likely to suggest some text on this in a separate 
> message.

Ok, this is a stab at the text about applicability statement. I suspect 
this should be a new section:

The structure of the Language Tag registry is not designed for direct 
creation of user-interfacing or query processing code. For example, the 
registry does not contain the information necessary to produce, a 
properly localized pick-list or pull-down menu.

Some reasons for why creating a good end-user interface isn't possible are:
- The registry does not contain translations.
- It does not give additional information that would allow to group 
languages in a hierarchy for a hierarchical user interface (which might 
be necessary for a large number of languages).
- It does not give information about potential overlaps of language tags.
- It does not contain information about mutual intelligibility. As an 
example, it is impossible to derive from the registry what language 
pairs with common prefixes are mutually intelligible, because in the 
general case, this depends on a user's language knowledge.
- It does not contain information about "backup languages", because such 
languages may be linguistically unrelated and the fact that one language 
may be used as a backup language for another is a result of the 
political and cultural situation, and may not apply for all users. The 
typical example for a backup language is that people who use Breton (a 
Celtic language used in the North-West of France) may be served French 
if Breton isn't available.

=========
The target audience for this section are developers of user interfaces, 
language query processing engines, etc.
I am not expecting this new section to document all cases for which the 
Language Tag registry is considered to be appropriate or not appropriate.
But it should be a reasonable starting point and can be expanded in the 
future, if 4646bis is ever revised.

Please suggest improvements/modifications of this text before about noon 
(EST) on Thursday, June 25th.
I will be on holidays for a week after that, so if this text doesn't get 
in, then there would be at least 1 week extra delay with approval 
announcement for 4646bis.

Thanks,
Alexey

---

From: Marion Gunn <[email-masked]>
Date: Tue, 23 Jun 2009 15:27:08 +0100

Under pressure of work here, so only useful suggestion I can make on the 
hop is to put the mention of  the target audience first (positive) and 
relegate the mention of the unfriendly end-user interface (negative) to 
the end. Otherwise, a good stab at doing what is needed.

Rgds,
mg

Scríobh Alexey Melnikov:
>> 4646bis, there is one extra change (addition) that needs to be done 
>> to the document - some text about applicability statement, i.e. for 
>> which purposes the IANA registry can and can't be used, what it 
>> wasn't designed for. I am likely to suggest some text on this in a 
>> separate message.
>
> Ok, this is a stab at the text about applicability statement. I 
> suspect this should be a new section:
>
> creation of user-interfacing or query processing code. For example, 
> the registry does not contain the information necessary to produce, a 
> languages in a hierarchy for a hierarchical user interface (which 
> might be necessary for a large number of languages).
> - It does not contain information about "backup languages", because 
> such languages may be linguistically unrelated and the fact that one 
> language may be used as a backup language for another is a result of 
> the political and cultural situation, and may not apply for all users. 
> The typical example for a backup language is that people who use 
> Breton (a Celtic language used in the North-West of France) may be 
> served French if Breton isn't available.
>
> =========
> The target audience for this section are developers of user 
> interfaces, language query processing engines, etc.
> I am not expecting this new section to document all cases for which 
> the Language Tag registry is considered to be appropriate or not 
> appropriate.
> But it should be a reasonable starting point and can be expanded in 
> the future, if 4646bis is ever revised.
>
> Please suggest improvements/modifications of this text before about 
> noon (EST) on Thursday, June 25th.
> I will be on holidays for a week after that, so if this text doesn't 
> get in, then there would be at least 1 week extra delay with approval 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru
>

-- 

Marion Gunn * eGteo (Estab.1991)

27 Páirc an Fhéithlinn, Baile an

Bhóthair, An Charraig Dhubh,

Co. Átha Cliath, Éire/Ireland

* [email-masked] * [email-masked] *

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 23 Jun 2009 08:07:23 -0700

Hi Alexey,

I'm unclear on the purpose of the proposed text, in part because the focus is on why it is insufficient for producing a user interface. Quite to the contrary of what you suggest, having the registry has enabled me, at least, to produce user interfaces that allow users to choose their language preferences. It is true that the localized presentation is not inherent in registry. But then, localized presentation isn't inherent in very many data sources that I know of either. And there is a very handy source of localizations of this very material---it's the Common Locale Data Repository, hosted by the Unicode Consortium.

Much of this information is already inherent in the document---Section 4.1 was intended to help implementers as well as users of language tags--and some of this is really more appropriate (and appears in) the companion RFC 4647.

So I would suggest the following text instead:

--
Section x.x.x Applicability

The Language Subtag registry is not designed to be the sole data source in the creation of a user interface or query processing code. For example, the registry does not contain all of the information necessary to produce a properly localized pick-list or pull-down menu. 

The registry does not contain translations for subtags or for tags composed from the subtags. Sources for localized data based on the registry are generally available, notably [CLDR]. Nor does the registry indicate which subtag combinations are particularly useful or relevant.

Neither does the registry provide additional information that would allow one to group primary languages into some form of hierarchy or ontology based on the relationships between languages. The relationships between languages and their speaker populations are complex. Because there are many ways to organize languages and because these are somewhat arbitrary, dependent upon context, or mutually inconsistent, the registry does not attempt to provide additional ways to organize languages.

Language tags and their subtags can have overlapping meanings. The choice of language tag depends on the context in which it is used and the user's intentions. With over 7000 primary language subtags, applications might wish to limit the range of subtag variation to avoid confronting users with too many choices. It might be useful to establish a collection of commonly used tags for a given application or protocol. For more information, see [Section 4.1 Choice].

The registry does not contain information about mutual intelligibility. Although language tag matching schemes (see [RFC 4647]) depend on the use of language tag prefixes, two languages that share a given prefix might not be mutually intelligible. The registry also does not contain information about "backup languages", because such languages are often linguistically unrelated and the fact that one language could be used as a backup language for another is a result of the political, historical, cultural situation. It might not apply to all users. An example of a "backup language" is that people who use Breton (a Celtic language used in the Northwest of France) will probably prefer to be served French if Breton isn't available.
--

Sadly, I would like to add links to some of the W3C's materials here, but there is no single link today that describes a complete set of information. I hope, eventually, that the LTLI document will fulfill this role.

Best Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alexey Melnikov
> Sent: Tuesday, June 23, 2009 6:32 AM
> To: [email-masked]
> Subject: [Ltru] Applicability Statement for the IANA registry
> established by 4646
> 
> Alexey Melnikov wrote:
> 
> > Hi,
> the
> might
> such
> the

---

From: John Cowan <[email-masked]>
Date: Tue, 23 Jun 2009 11:34:05 -0400

> So I would suggest the following text instead:

+1

-- 
John Cowan   [email-masked]    http://ccil.org/~cowan
I come from under the hill, and under the hills and over the hills my paths
led. And through the air. I am he that walks unseen.  I am the clue-finder,
the web-cutter, the stinging fly. I was chosen for the lucky number.  --Bilbo

---

From: Mark Davis ⌛ <[email-masked]>
Date: Tue, 23 Jun 2009 09:04:15 -0700

+1

Mark

On Tue, Jun 23, 2009 at 08:34, John Cowan <[email-masked]> wrote:

> John Cowan   [email-masked]    http://ccil.org/~cowan<http://ccil.org/%7Ecowan>

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 23 Jun 2009 17:24:02 +0100

Addison wrote:

> Sadly, I would like to add links to some of the W3C's
> materials here, but there is no single link today that
> describes a complete set of information. I hope, eventually,
> that the LTLI document will fulfill this role.

Sadly, there would appear to be very little interest in ISO FDIS 639-6 which
will provide a hierarchical system for language encoding.  And this despite
the fact that many moons ago I, with my (mocked) crystal ball, predicted
that this would be necessary for any realistic use of the data within pick
lists.

But, hey, what would I know!

Debbie (Feeling irritated!)
Editor ISO FDIS 639-6

> Behalf Of Phillips, Addison
> Sent: 23 June 2009 16:07
> To: Alexey Melnikov; [email-masked]
> Subject: Re: [Ltru] Applicability Statement for the IANA
> registry established by 4646
>
> Hi Alexey,
>
> I'm unclear on the purpose of the proposed text, in part
> because the focus is on why it is insufficient for producing
> a user interface. Quite to the contrary of what you suggest,
> having the registry has enabled me, at least, to produce user
> interfaces that allow users to choose their language
> preferences. It is true that the localized presentation is
> not inherent in registry. But then, localized presentation
> isn't inherent in very many data sources that I know of
> either. And there is a very handy source of localizations of
> this very material---it's the Common Locale Data Repository,
> hosted by the Unicode Consortium.
>
> Much of this information is already inherent in the
> document---Section 4.1 was intended to help implementers as
> well as users of language tags--and some of this is really
> more appropriate (and appears in) the companion RFC 4647.
>
> The Language Subtag registry is not designed to be the sole
> data source in the creation of a user interface or query
> processing code. For example, the registry does not contain
> all of the information necessary to produce a properly
> localized pick-list or pull-down menu.
>
> The registry does not contain translations for subtags or for
> tags composed from the subtags. Sources for localized data
> based on the registry are generally available, notably
> [CLDR]. Nor does the registry indicate which subtag
> combinations are particularly useful or relevant.
>
> Neither does the registry provide additional information that
> would allow one to group primary languages into some form of
> hierarchy or ontology based on the relationships between
> languages. The relationships between languages and their
> speaker populations are complex. Because there are many ways
> to organize languages and because these are somewhat
> arbitrary, dependent upon context, or mutually inconsistent,
> the registry does not attempt to provide additional ways to
> organize languages.
>
> Language tags and their subtags can have overlapping
> meanings. The choice of language tag depends on the context
> in which it is used and the user's intentions. With over 7000
> primary language subtags, applications might wish to limit
> the range of subtag variation to avoid confronting users with
> too many choices. It might be useful to establish a
> collection of commonly used tags for a given application or
> protocol. For more information, see [Section 4.1 Choice].
>
> The registry does not contain information about mutual
> intelligibility. Although language tag matching schemes (see
> [RFC 4647]) depend on the use of language tag prefixes, two
> languages that share a given prefix might not be mutually
> intelligible. The registry also does not contain information
> about "backup languages", because such languages are often
> linguistically unrelated and the fact that one language could
> be used as a backup language for another is a result of the
> political, historical, cultural situation. It might not apply
> to all users. An example of a "backup language" is that
> people who use Breton (a Celtic language used in the
> Northwest of France) will probably prefer to be served French
> Sadly, I would like to add links to some of the W3C's
> materials here, but there is no single link today that
> describes a complete set of information. I hope, eventually,
> that the LTLI document will fulfill this role.
>
>
> Best Regards,
>
> Addison
>
>
> Addison Phillips
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf
> > Of Alexey Melnikov
> > Some reasons for why creating a good end-user interface
> isn't possible
> > are:
> > The

---

From: Kent Karlsson <[email-masked]>
Date: Tue, 23 Jun 2009 18:44:53 +0200

Sort of "+1", but the text is much more about "Some of the limitations of
applicability" rather than "Applicability". So if the text is to remain so
focussed on limitations, I'd suggest changing the section heading to
something similar to the string above.

    /kent k

Den 2009-06-23 17.07, skrev "Phillips, Addison" <[email-masked]>:

... 
> So I would suggest the following text instead:
...

---

From: Marion Gunn <[email-masked]>
Date: Tue, 23 Jun 2009 17:45:11 +0100

Scríobh Kent Karlsson:
> applicability" rather than "Applicability". 

My point exactly.
> So if the text is to remain so
I agree, except that 'Applicability' sounds better, as a title, were 
that not a mismatch to the actual text.
mg

--

---

From: John Cowan <[email-masked]>
Date: Tue, 23 Jun 2009 12:57:34 -0400

> that this would be necessary for any realistic use of the data within pick

It's a hierarchy, all right, but it's not clear that it's a *useful*
hierarchy for general use.  I find the Ethnologue hierarchy
search very useful, but most users confronted with a page like
http://www.ethnologue.com/family_index.asp and asked to find their
language wouldn't even know how to start.

Here's an idea I came up with some years ago:

At the top level, provide a choice between a set of widely used languages
(perhaps ISO 639/1 or even a subset of it) and a list of countries.  If
the user chooses a country, present a list of languages commonly spoken in
that country.  Scraping http://www.ethnologue.com/show_country.asp?name=XX
where XX is an ISO 3166/1 country code would provide a candidate list
of languages for that country.

-- 
Cash registers don't really add and subtract;           John Cowan
        they only grind their gears.                    [email-masked]
But then they don't really grind their gears, either;   
        they only obey the laws of physics.  --Unknown

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 23 Jun 2009 18:13:24 +0100

True! :-)

D

> From: John Cowan [mailto:[email-masked]]
> Sent: 23 June 2009 17:58
> To: Debbie Garside
> Cc: 'Phillips, Addison'; 'Alexey Melnikov'; [email-masked]
> > Sadly, there would appear to be very little interest in ISO
> FDIS 639-6
> > which will provide a hierarchical system for language
> encoding.  And
> > this despite the fact that many moons ago I, with my
> (mocked) crystal
> > ball, predicted that this would be necessary for any
> realistic use of
> > the data within pick lists.
>
> It's a hierarchy, all right, but it's not clear that it's a
> *useful* hierarchy for general use.  I find the Ethnologue
> hierarchy search very useful, but most users confronted with
> a page like http://www.ethnologue.com/family_index.asp and
> asked to find their language wouldn't even know how to start.
>
> At the top level, provide a choice between a set of widely
> used languages (perhaps ISO 639/1 or even a subset of it) and
> a list of countries.  If the user chooses a country, present
> a list of languages commonly spoken in that country.
> Scraping http://www.ethnologue.com/show_country.asp?name=XX
> where XX is an ISO 3166/1 country code would provide a
> candidate list of languages for that country.
>
> --

---

From: Peter Constable <[email-masked]>
Date: Tue, 23 Jun 2009 10:29:32 -0700

It seems to me that a _positive_ statement of Applicability would be something along the lines of the following: 

------------------------
The Language Subtag Registry is the sole source of data elements used in constructing language tags, following rules described in this document. The intended use of language tags is as metadata elements, for use on the Internet and in other application contexts, for declaring linguistic attributes of information objects, such as HTML content or application resource strings; or, for expressing linguistic attributes in application interfaces, such as interfaces requesting HTML content or application resource strings matching certain linguistic attributes.
------------------------

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Karlsson
Sent: Tuesday, June 23, 2009 9:45 AM
To: Phillips, Addison; Alexey Melnikov; [email-masked]
Subject: Re: [Ltru] Applicability Statement for the IANA registry established by 4646

    /kent k

... 
...

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 23 Jun 2009 12:48:04 -0700

Hi -

> From: "Phillips, Addison" <[email-masked]>
> To: "Alexey Melnikov" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, June 23, 2009 8:07 AM
...
> I'm unclear on the purpose of the proposed text, in part because the focus
> is on why it is insufficient for producing a user interface.

As co-chair:

Its purpose is to address IESG / reviewer concerns.  Consequently,
I believe we should not attempt to broaden it or address other issues.
Instead, we should focus on providing language that addresses the
concerns covered by Alexey's text, no more and no less.

> Quite to the contrary of what you suggest, having the registry has enabled me,
> at least, to produce user interfaces that allow users to choose their language
> preferences.

Please, let's not go there.  There can be no desirable outcome to pursuing
this argument.

> It is true that the localized presentation is not inherent in registry.
> But then, localized presentation isn't inherent in very many data
> sources that I know of either. 

That's the point.  It may be obvious to folks with even a little internationalization
background, but since it was not that obvious to the IESG/reviewer,
we need to address it.

> And there is a very handy source of localizations of this very material --- 
> it's the Common Locale Data Repository, hosted by the Unicode Consortium.

Fine, but we're not being asked to solve the "problem"; we're only being asked
to warn the naive.

> Much of this information is already inherent in the document --- Section 4.1
> was intended to help implementers as well as users of language tags -- and
> some of this is really more appropriate (and appears in) the companion RFC 4647.

As a technical contributor:

I'd agree, but there *will* be text here, so let's
just deal with it, rather than speculating about alternatives that just won't
be happening.

> The Language Subtag registry is not designed to be the sole data source in the
> creation of a user interface or query processing code. For example, the registry
> does not contain all of the information necessary to produce a properly localized
> pick-list or pull-down menu. 

I'd prefer something closer to Alexey's original:

The Language Subtag registry is not designed for direct creation of user-interface
query processing code. For example, the registry lacks information necessary to
produce a properly localized pick-list or pull-down menu.

> The registry does not contain translations for subtags or for tags composed
> from the subtags. Sources for localized data based on the registry are generally
> available, notably [CLDR]. Nor does the registry indicate which subtag

This issue was not raised, so I oppose adding this text.
 
> Neither does the registry provide additional information that would allow
> one to group primary languages into some form of hierarchy or ontology
> based on the relationships between languages. The relationships between
> languages and their speaker populations are complex. Because there are
> many ways to organize languages and because these are somewhat arbitrary,
> dependent upon context, or mutually inconsistent, the registry does not attempt
> to provide additional ways to organize languages.

Alexey's corresponding original text was much more concise.  I'd replace the above
with:

It does not give additional information that would support grouping
primary languages in a hierarchy for a hierarchical user interface.

> Language tags and their subtags can have overlapping meanings.
> The choice of language tag depends on the context in which it is used
> and the user's intentions. With over 7000 primary language subtags,
> applications might wish to limit the range of subtag variation to avoid
> confronting users with too many choices. It might be useful to establish
> a collection of commonly used tags for a given application or protocol.
> For more information, see [Section 4.1 Choice].

Way too much.  I'd prefer something closer to what Alexey proposed:

It does not give information about potential overlaps, which can occur, for
example, in the case of a dialect continuum.

> The registry does not contain information about mutual intelligibility.
> Although language tag matching schemes (see [RFC 4647]) depend
> on the use of language tag prefixes, two languages that share a given 
> prefix might not be mutually intelligible.

This is fine with me.

> The registry also does not
> contain information about "backup languages", because such
> languages are often linguistically unrelated and the fact that one
> language could be used as a backup language for another is a
> result of the political, historical, cultural situation. It might not apply to
> all users. An example of a "backup language" is that people who use
> Breton (a Celtic language used in the Northwest of France) will
> probably prefer to be served French if Breton isn't available.

I'd prefer slight wording tweaks:

It does not contain information about "backup languages." Ssuch 
languages may be linguistically unrelated and the fact that one language 
may be used as a backup language for another is a result of the 
political, historicalm and cultural situation, and can be user-specific.
For example, most people who use Breton (a Celtic language used
in the North-West of France) would probably prefer to be served
French (a Romance language) if Breton isn't available.

Randy

---

From: Mark Davis ⌛ <[email-masked]>
Date: Tue, 23 Jun 2009 13:45:21 -0700

Mark

> produce a properly localized pick-list or pull-down menu.

Addison's is better. Who knows what "direct creation" means?

> This issue was not raised, so I oppose adding this text.

The issue of the registry being insufficient for localization was raised, so
this text *is* relevant.

> primary languages in a hierarchy for a hierarchical user interface.

Addison's reasoning was clearly to provide some background for why we don't
include that kind of information. But I'm ok with the shorter version if
reworded somewhat, as the following.

It does not provide information indicating the relationship between
different languages, such as those used in a hierarchical user interface for
selecting language tags.

> example, in the case of a dialect continuum.

The problem with Alexey's version is that lots of people will have no idea
what it means: "dialect continuum"?? "overlaps"?? If we really want a
shorter version, it needs to be understandable. Maybe:

The notion of what constitutes a language is not precise: a given piece of
content may be reasonably tagged by different language tags. The registry
does not supply information about such potential overlaps.

> I'd prefer slight wording tweaks:

Ok with the following, with some small corrections.

> It does not contain information about "backup languages." Ssuch

Such

> languages may be linguistically unrelated and the fact that one language
unrelated. The

> political, historicalm and cultural situation, and can be user-specific.

historical,

---

From: Kent Karlsson <[email-masked]>
Date: Tue, 23 Jun 2009 23:31:33 +0200

Den 2009-06-23 21.48, skrev "Randy Presuhn" <[email-masked]>:

> query processing code.

What is "user-interface query processing code"? And what is "direct
creation" of it?

> It does not contain information about "backup languages." Ssuch

This introduces a new term, "backup languages". I'm not at all keen on
introducing a new term at this extreme late stage. And even if one were to
introduce a term for this, I would NOT choose "backup language". CLDR calls
this "fallback", MacOS has a language priority list, and that is also term
RFC 4647 uses.

    /kent k

---

From: Marion Gunn <[email-masked]>
Date: Wed, 24 Jun 2009 11:32:32 +0100

Definitely more positive, only perhaps something needing to be added 
after "sole", something in the way of "official" or "QQQ-approved", with 
QQQ slot to be filled in by title of issuing authority? Or if you do not 
want to do that, then "to be" inserted after "data elements".

Only suggesting such changes: I'm easy with things either way, only glad 
to put end to incredibly long debate. Would be interesting to see stats 
posted on this list re exact number of participants involved in this 
debate and from which countries, exactly, they come.
mg

--

---

From: Marion Gunn <[email-masked]>
Date: Wed, 24 Jun 2009 11:36:02 +0100

Stats set out as in usual lists of ISO participants, thus: USA (3), 
Finland (2), China (4), etc. Such stats could help increase 
participation next time around. There is something about seeing your 
country listed with either zero participation in brackets after its 
name, or a decent contingent.
mg

Scríobh Marion Gunn:
> after "sole", something in the way of "official" or "QQQ-approved", 
> with QQQ slot to be filled in by title of issuing authority? Or if you 
> do not want to do that, then "to be" inserted after "data elements".
>
> Only suggesting such changes: I'm easy with things either way, only 
> glad to put end to incredibly long debate. Would be interesting to see 
> stats posted on this list re exact number of participants involved in 
> this debate and from which countries, exactly, they come.
> mg
>
> Scríobh Peter Constable:

--

---

From: Peter Constable <[email-masked]>
Date: Wed, 24 Jun 2009 07:42:52 -0700

IETF doesn't work like ISO. Representation is not by country, but purely individually. (In some ways, I think IETF would be better if its processes were more like ISO's.)

Peter

From: Marion Gunn [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 3:36 AM
To: [email-masked]
Cc: Peter Constable; Kent Karlsson; Phillips, Addison; Alexey Melnikov
Subject: Re: [Ltru] Applicability Statement for the IANA registry established by 4646

Stats set out as in usual lists of ISO participants, thus: USA (3), Finland (2), China (4), etc. Such stats could help increase participation next time around. There is something about seeing your country listed with either zero participation in brackets after its name, or a decent contingent.
mg

Scríobh Marion Gunn:
Definitely more positive, only perhaps something needing to be added after "sole", something in the way of "official" or "QQQ-approved", with QQQ slot to be filled in by title of issuing authority? Or if you do not want to do that, then "to be" inserted after "data elements".

Only suggesting such changes: I'm easy with things either way, only glad to put end to incredibly long debate. Would be interesting to see stats posted on this list re exact number of participants involved in this debate and from which countries, exactly, they come.
mg

Scríobh Peter Constable:

------------------------

------------------------

Peter

--

* [email-masked]<mailto:[email-masked]> * [email-masked]<mailto:[email-masked]> *

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 24 Jun 2009 10:11:46 -0700

Hi -

As co-chair...

> From: "Marion Gunn" <[email-masked]>
> To: "Peter Constable" <[email-masked]>; <[email-masked]>
> Cc: "Alexey Melnikov" <[email-masked]>
> Sent: Wednesday, June 24, 2009 3:32 AM
...
> Would be interesting to see stats 
...

Interesting, perhaps, but as co-chair I think it would be both inappropriate
and probably more work than it would be worth.  This is not ISO or ITU, and
we work as individuals, not representatives of some national body.  I know
the national origins of three participants - others have not volunteered the
information and I'm not going to ask.

You *can* obtain statistics from IETF meeting attendance.  Those numbers
can be rather misleading, however, since in many cases the country where
someone works is not their country of citizenship, which in turn is not always
their country of birth,  nor is it necessarily their country of cultural affinity.
And if we go by employment, do we use their work location or the headquarters
of the firm?  Let's not go there.

Randy

---

From: "Broome, Karen" <[email-masked]>
Date: Wed, 24 Jun 2009 11:30:08 -0700

Randy,

I strongly agree that this is not appropriate. I work for a Japanese
company in America. My heritage is European. It would be difficult to
fit each participant into one neat bucket that would actually have some
useful meaning.

FYI: Sorry for the absence in my participation with some of the more
recent issues. I have made a transition from Sony Pictures to Sony
Electronics. I will still be based at Sony Pictures in Los Angeles, but
my e-mail address has changed to: [email-masked].

Best regards,

Karen Broome
Senior Staff, Technology Standards Office
Sony Electronics, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Randy Presuhn
Sent: Wednesday, June 24, 2009 1:12 PM
To: [email-masked]
Subject: [Ltru] National origins of participants

Hi -

As co-chair...

...
...

Interesting, perhaps, but as co-chair I think it would be both
inappropriate
and probably more work than it would be worth.  This is not ISO or ITU,
and
we work as individuals, not representatives of some national body.  I
know
the national origins of three participants - others have not volunteered
the
information and I'm not going to ask.

You *can* obtain statistics from IETF meeting attendance.  Those numbers
can be rather misleading, however, since in many cases the country where
someone works is not their country of citizenship, which in turn is not
always
their country of birth,  nor is it necessarily their country of cultural
affinity.
And if we go by employment, do we use their work location or the
headquarters
of the firm?  Let's not go there.

Randy