--On Wednesday, July 17, 2013 07:56 -0700 Bernard Aboba
bernard_ab...@hotmail.com wrote:
Sam said:
We don't get to place requirements on applications except to
say what they need to do to use EAP. The protocol
requirement for that is that applications using EAP need to
know what
Hi,
We don't get to place requirements on applications except to say what
they need to do to use EAP. The protocol requirement for that is that
applications using EAP need to know what character set they have so that
EAP can convert the identity to UTF-8 and so that EAP methods can do any
Hi,
After reading this document, I believe that this document omits
discussion of an important aspect, which is internationalization.
Since the contents of the EAP Identity and RADIUS User-Name attributes
are specified to be encoded in UTF-8, application protocols that utilize
encodings
Hi Bernard, Patrik,
Thanks for the comment. Checking that out now and will
get back.
Cheers,
S.
On 07/17/2013 05:29 AM, Patrik Fältström wrote:
On 16 jul 2013, at 21:42, Bernard Aboba bernard_ab...@hotmail.com wrote:
After reading this document, I believe that this document omits
Stephen == Stephen Farrell stephen.farr...@cs.tcd.ie writes:
Stephen Hi Bernard, Patrik,
Stephen Thanks for the comment. Checking that out now and will get
Stephen back.
Bernard, thanks for the comment. I expected to feel really frustrated
at how late the comment was sent but
Hi,
I think assuming that 4282bis has reached consensus on
internationalization is wildly wishful thinking at this stage. I
continue to be dubious that the right parties are involved in the
discussion and even if we have consensus in radext expect significant
discussion at ietf last call,
Hi,
Pushing the requirement down to the EAP method won't work IMHO.
Further to this: now that I have EAP-TTLS on screen, its words of wisdom
about EAP type selection show that it won't work quite clearly. And they
are valid beyond EAP-TTLS. Section 7.3 of RFC5281 states:
Note that at the time
Stefan == Stefan Winter stefan.win...@restena.lu writes:
However, I absolutely agree that if an application is going to
use EAP it needs to follow EAP's i18n conventions whatever those
may be. A rrequirement on anti-causal investigation for current
implementation efforts has
The question is: this document is about an applicability update, not a
change of the on-the-wire behaviour of EAP.
[BA] That's right -- which is why I see no need for the applicability update to
depend on RFC 4282bis. It just needs to discuss the applicability aspects.
If we were to try
Sam said:
My recommendation is that we point out the issue. And say that
strings used within a specific EAP method MUST follow the rules
for that method. If AAA is used, strings used within AAA MUST
follow the rules for the AAA protocol in use. We can add an
informative citation to
Hi,
Sam said:
Nah, you'd just be living in a different hell if you'd been explicit in
the EAP spec. I know: other parts of the IETF are in that hell. The
protocols are clear and everything is fine until you realize that the
backend authentication systems you're dealing with are using a
Hi,
[BA] We are just talking about core EAP and RADIUS RFCs here.
Internationalization of method-specific identities (and passwords) is
defined by the EAP method specifications, so the Identities UTF-8
everywhere is a much broader topic (and one which I'd argue is not
relevant to an ABFAB
[BA] Exactly. It's just an applicability statement, not a prescription
for world peace :)
Sure: we need more than an applicability statement update to achieve
peace in the EAP world. But if an applicability statement update is all
we can work with, we could try and do our best in that
Stefan == Stefan Winter stefan.win...@restena.lu writes:
Stefan In the other hell, it can be sure to receive UTF-8 in NFC,
Stefan and if that doesn't match what it needs, it can convert it.
Stefan In my naïve thinking, that second hell is a lot less hot
Stefan and much more
Sam said:
We don't get to place requirements on applications except to say what
they need to do to use EAP. The protocol requirement for that is that
applications using EAP need to know what character set they have so that
EAP can convert the identity to UTF-8 and so that EAP methods can do
Also, note that the important thing is not that applications use UTF-8
for usernames.
It's that they know what character set they are using and follow EAP's
(lack of) rules when using EAP.
In general, I would not expect an application to encode a username
that's also used in EAP authentication
After reading this document, I believe that this document omits discussion of
an important aspect, which is internationalization. Since the contents of the
EAP Identity and RADIUS User-Name attributes are specified to be encoded in
UTF-8, application protocols that utilize encodings other
On 16 jul 2013, at 21:42, Bernard Aboba bernard_ab...@hotmail.com wrote:
After reading this document, I believe that this document omits discussion of
an important aspect, which is internationalization. Since the contents of
the EAP Identity and RADIUS User-Name attributes are specified
A new Request for Comments is now available in online RFC libraries.
BCP 166
RFC 6365
Title: Terminology Used in Internationalization in
the IETF
Author: P. Hoffman, J. Klensin
Status: Best Current Practice
The IESG has approved the following document:
- 'Terminology Used in Internationalization in the IETF'
(draft-ietf-appsawg-rfc3536bis-06.txt) as a BCP
This document is the product of the Applications Area Working Group.
The IESG contact persons are Pete Resnick and Peter Saint-Andre.
A URL
At 06:04 16-06-2011, The IESG wrote:
The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Terminology Used in Internationalization in the IETF'
draft-ietf-appsawg-rfc3536bis-02.txt as a BCP
The IESG plans to make
25.06.2011 22:27, SM wrote:
At 06:04 16-06-2011, The IESG wrote:
The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Terminology Used in Internationalization in the IETF'
draft-ietf-appsawg-rfc3536bis-02.txt as a BCP
:2011 is published. The reference should be corrected.
Thanks,
Mykyta Yevstifeyev
16.06.2011 16:04, The IESG wrote:
The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Terminology Used in Internationalization in the IETF
On Thu, Jun 16, 2011 at 11:21 PM, Mykyta Yevstifeyev
evniki...@gmail.com wrote:
I have an only concern with regard to this document which I expressed
before, during WG discussions, and which I'd like to bring to IESG's
attention now.
For a number of times I proposed improving the control
The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Terminology Used in Internationalization in the IETF'
draft-ietf-appsawg-rfc3536bis-02.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
I suggest that the draft include a definition of the term writing
system. Peter Daniels' explanation of what a writing system is in
The World's Writing Systems is probably too detailed (not to mention
arcane); but given the importance of the term (which is used 7 times
in the draft), its
This draft makes three references to RFC 4646, Tags for Identifying
Languages, which was obsoleted in September 2009 by RFC 5646 (still BCP
47).
RFC 5646 introduced numerous changes, by far the most significant of
which was to add support for language subtags based on ISO 639-3. This
increased
On 3/8/11 8:09 AM, Doug Ewell wrote:
This draft makes three references to RFC 4646, Tags for Identifying
Languages, which was obsoleted in September 2009 by RFC 5646 (still BCP
47).
RFC 5646 introduced numerous changes, by far the most significant of
which was to add support for language
On 3/8/11 2:59 PM, Lyman Chapin wrote:
I suggest that the draft include a definition of the term writing
system. Peter Daniels' explanation of what a writing system is in
The World's Writing Systems is probably too detailed (not to mention
arcane); but given the importance of the term (which is
Here is my contribution to the requested definitions.
--
Directory service = a software system that responds to requests for information about
entities, e.g. people in an organization. It's a system for managing access to
computer resources, keeping track of the users of a network,... from a
; Randy Bush; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: Internationalization and the IETF
I hate to butt in here, I've been listening to these discussions for
some time. (I am incredibly impressed with how smart everyone in these
IETF groups is).
But, what about NMS directories that
Kyle;
There seems to be a debate to split "DNS" from "Directory" services,
whereas, in long term, it is inevitable that DNS will merge with
Directory services, even if current technology isn't that way.
Huh?
URLs are the result of such merge.
URLs have ASCII domain name part followed by a
On Mon, 11 Dec 2000 23:55:50 PST, "Durah, Kheder" said:
I see what you mean..it's not a perfect world and misuse of technology
standards always exist as long as human intelligence is involved. Do you
think going the other way and considering DNS as an directory service will
resolve this
Ph.D.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Monday, December 11, 2000 7:16 PM
To: Randy Bush
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: Internationalization and the IETF
As I recall,
%
% For the sake of a good discussion can we please have a
% definition of "directory service" and "address
% registry" to make sure we are all on the same page.
%
% I think we will find that defining these may be the
% issue, and this will clarify the discussion to
% something that we can get
At 05:40 AM 12/12/00 -0800, Gabriel Landowski wrote:
For the sake of a good discussion can we please have a
definition of "directory service" and "address
registry" to make sure we are all on the same page.
A Lookup, mapping, or address registry service takes a complete, precise
query
At/À 05:06 2000-12-12 -0800, Bill Manning you wrote/vous écriviez:
%
% For the sake of a good discussion can we please have a
% definition of "directory service" and "address
% registry" to make sure we are all on the same page.
%
% I think we will find that defining these may be the
% issue, and
On Mon, 11 Dec 2000 23:25:25 PST, "Durah, Kheder" said:
This is my first transmission to IETF, and would like to second the fact
that DNS is an address registry and not a directory service.
It's all fine and good to insist that sort of thing until you're blue in
the face, but the reality is
At 02:43 PM 12/7/00 +0100, Anthony Atkielski wrote:
Not a valid comparison. Do we have a worldwide, global phonebook that lists
every telephone number on the planet?
yes. we call it "411". If the operator doesn't have the information, s/he
redirects you to someone who does.
Do we have
% that's not obvious either. If I want to call you, I have to track down your
% phone number. I can't just call the operator and say "connect me to Anthony
% Atkielski". But I can find your email address pretty quickly with a web
% browser, and atkielski.com isn't too hard to come by.
Buzzt.
--- Dave Crocker [EMAIL PROTECTED] wrote:
If we did not already have very wide-scale use of
ascii, it might be worth
considering numerals as the common form. But that
wide-scale use is
everywhere.
Why not alias the ASCII to the numeral form?
Gabriel Landowski
Mindangle, USA
At 01:53 PM 12/8/00 -0800, Gabriel Landowski wrote:
Why not alias the ASCII to the numeral form?
What is the benefit of having the numeric form all, since we already have a
common form (ascii)?
d/
=-=-=-=-=
Dave Crocker [EMAIL PROTECTED]
Brandenburg Consulting www.brandenburg.com
Tel:
At 15:35 06/12/2000 -0700, Vernon Schryver wrote:
The same thinking that says that MIME Version headers make sense in
general IETF list mail also says that localized alphabets and glyphs must
be used in absolutely all contexts, including those that everyone must
use and so would expect to be
From: Harald Alvestrand [EMAIL PROTECTED]
The same thinking that says that MIME Version headers make sense in
general IETF list mail also says that localized alphabets and glyphs must
be used in absolutely all contexts, including those that everyone must
use and so would expect to be
Keith Moore [EMAIL PROTECTED] said:
The notion that use of languages other than English can or should be
'localized' strikes me as both shockingly arrogant and hopelessly naive.
It strikes me that the underlying assumption that people can't or won't
deal with numeric addresses may no longer
Keith Moore wrote:
Furthermore, a
great many people use multiple languages (not necessarily including
English) is, so that a given person, host, or subnetwork will often
need to exist in multiple (potentially competing) locales at once.
Sometimes even in the same sentence. My mother grew
Date: Thu, 07 Dec 2000 07:23:11 -0500
From: Dave Crocker [EMAIL PROTECTED]
At least the recipient has the unintelligible data well isolated and
labeled. MIME did its job.
Indeed. If I get a mail message which is in HTML only, 99.97% of the
time it's SPAM-mail. And I've lost
On Thu, 07 Dec 2000 09:06:41 CST, "Robert G. Ferrell" [EMAIL PROTECTED]
said:
bookmarks/hyperlinks or email address books, anyway. It might be a hassle in
the original contact to have to type in a sequence of numbers, but
after that it's back to point and click.
Until the destination
On Thu, 07 Dec 2000 17:09:16 +0100, Anthony Atkielski [EMAIL PROTECTED] said:
We've done without it thus far for telephone numbers, and that does not seem
to have hampered their use and availability.
Umm.. No. We haven't. You got a phone book in your office? Ever dialed
555-1212? ;)
--
[recipient list trimmed]
Look at other international communications systems, like TELEX and EDI
(Electronic Data Interchange). Why are they so "universal"?
they aren't. both are used by a limited number of people within a
limited set of business interests, as compared to the Internet.
I
On Thu, 7 Dec 2000, Anthony Atkielski wrote:
From: [EMAIL PROTECTED]
Umm.. No. We haven't. You got a phone book in your
office? Ever dialed 555-1212?
Not a valid comparison. Do we have a worldwide, global phonebook that lists
every telephone number on the planet? No. Do we have
From: Henk Langeveld [EMAIL PROTECTED]
You know, it isn't that long ago that I realised that for many Americans,
"International" is synonymous with "Non-American".
That is as true as the observation that many who learn English as a
second language think that "international" is synonymous
Vernon;
MIME character sets is an example of a battle fought and won.
When MIME is used to pass special forms among people whose common
understandings including more or other than ASCII, MIME is a battle
fought and won.
FYI, we, Japanese, have, long before MIME, been and still are
If the world had asked you or me to design an international
language, I think either of us would have done better.
Don't be too sure. Even today, there are no more speakers of
Esperanto than of Mayan.
Yes. 555-1212 (and it's regional equivalents).
No. That number only works in certain places, for certain numbers, not
everywhere for everything.
It's still name-to-address mapping.
But it is not universal and worldwide.
DNS may represent the same oversight that IP addressing schemes have
At 09:06 AM 12/7/00 -0600, Robert G. Ferrell wrote:
I would hazard a guess that the vast majority
of Internet message addressing is done automatically through the use of
bookmarks/hyperlinks or email address books, anyway.
This line of reasoning has shown up regularly for 20 years, or so. Yes,
At 15:09 07/12/2000 -0600, Matt Crawford wrote:
If the world had asked you or me to design an international
language, I think either of us would have done better.
Don't be too sure. Even today, there are no more speakers of
Esperanto than of Mayan.
Take care.
The SIL Ethnologue claims
57 matches
Mail list logo
