James;
> > As you could have seen, on IETF mailing list, Harald and I have, at
> > least, agreed that, if you use unicode based encoding, local context
> > (or locale) must be carried out of band
>
> Few will disagree (including me) that using Unicode to do localization is
> almost impossible wi
> > Few will disagree (including me) that using Unicode to do localization
is
> > almost impossible without locale context.
>
> Huh? No one said such a thing.
>
> What is agreed is that, to use unicode, it must be supplied out of
> band local context.
In that case, I disagree with "to use unicode
You want to be facing 8-bit bugs in 2002? I recommend reconsideration
of priorities.
--
James W. Meritt CISSP, CISA
Booz | Allen | Hamilton
phone: (410) 684-6566
Ah, but was there an implementable ANSWER? THAT is the question!
Dave Crocker wrote:
>
> At 09:52 PM 3/20/2002 -0500, Edmon Chung wrote:
> >An underlying question we must ask ourselves from all the discussions that
> >have sprung up every now and then is:
>
> and as luck would have it, the wor
Aaron Falk wrote:
> I think one can make the case that having border protection may
> prevent a DOS attack from consuming interior network resources and
> allowing interior hosts to communicate amongst themselves.
And if your interior network resources are less than 10x your external
resource, yo
> From: "Tony Hain" <[EMAIL PROTECTED]>
> it may be more convenient to have the border deal with DOS, but is it
> *required* as Noel asserted?
First, there's "good idea", "required", and "*required*". It's *required*
that your computer have a test-and-branch instruction to be a Turin
--On 20. mars 2002 07:48 +0100 Thor Harald Johansen <[EMAIL PROTECTED]>
wrote:
> Hi.
>
> One or two of the messages I've sent out haven't received a single reply
> (wich is strange, considering there's always some person who disagrees
> with you).
a number of reasons
- a lot of people ar
--On 21. mars 2002 16:47 +0859 Masataka Ohta
<[EMAIL PROTECTED]> wrote:
> However, as Harald and I agreed, such products need local
> context information OOB to work properly.
apologies for indicating too strong an agreement
we agree that for many functions that users would like software
HELP
Bert is MIA see bert.secret-wg.org.
He just started persuing his career as IT trend watcher. Help us find him back
--Bert's Secretary
An underlying question we must ask ourselves from all the discussions that
have sprung up every now and then is:
Do we wish to
1. eventually move the DNS towards UTF8/16 OR
2. do we want to stay with ASCII(ACE) for the rest of our lives?
If the answer is 1. then the IDN solution should take it i
> Unicode is not usable in international context.
...
It would not be worth replying to these threadworn and repeated
assertions by Mr. Ohta, except that some members of this list may not
be that familiar with Unicode. Clearly Unicode is being used
successfully in a huge variety of products in in
[Note: IDN WG list removed]
> As you could have seen, on IETF mailing list, Harald and I have, at
> least, agreed that, if you use unicode based encoding, local context
> (or locale) must be carried out of band
Few will disagree (including me) that using Unicode to do localization is
almost impos
>On Mar 19, "D. J. Bernstein" <[EMAIL PROTECTED]> wrote:
>
>> Go sell a Greek user an ``internationalized domain name'' with a delta,
>> Pete. Then tell him that most of his correspondents will see the delta
>> as incomprehensible gobbledygook rather than a delta. See what he says.
Okay, I'm n
From: "Meritt James" <[EMAIL PROTECTED]>
> Ah, but was there an implementable ANSWER? THAT is the question!
>
Here is a simple architecture/roadmap possibility:
1. IDNA user-end plugin
- this plugin does all the heavy lifting to encode and decode ACE and
display it properly for the user
Date:Thu, 21 Mar 2002 00:57:18 +0859 ()
From:Masataka Ohta <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Otha-san
| Anyway, with the fix, there is no reason to prefer Unicode-based
| local character sets, which is not widely used today, than existing
| lo
As a frequent visitor to Japan, I am planning to put together some kind of
"guide" and put it on a web page somewhere, more on that later.
Meanwhile, please mark your calendar for:
1. Akihabara (electronics town) Geek Tour, Sunday July 14. On Sundays, the
"Main Drag" aka Chuo Dori is closed to
Also as a frequent visitor, I'll post my favorite money and time saving
travel tip. Get a JR East rail pass *before* you travel to Japan. It's much
cheaper that way. Surf to http://www.jreast.co.jp/eastpass/index.htm to
find out details.
I would also plan ahead as much as possible as we will b
On Thu, 21 Mar 2002 16:27:23 +0859, Masataka Ohta said:
> Trying to reply your mail, my mailer says:
>
> [Charset Windows-1252 unsupported, skipping...]
>
> so, could you learn not to Microsoft centric and to use proper charset
> for the International discussion of IETF?
On Thu, 21 Mar 20
Hi Dave
You seem to be repeating my words in a slightly different "tone"
- Original Message -
From: "Dave Crocker" <[EMAIL PROTECTED]>
> the answer was that it is not happening now and we need to make a
> transition that is independent of converting to utf-8 native.
>
My answer
> >And a
Edmon Chung wrote:
>If we collectively decide that it is NEVER going to happen and we
>will stay with ACE FOREVER, then, we should stop here and live happily
ever
>after with ACE. But if the general direction or consensus is to move
>towards UTF8 eventually, then, we should start the work now.
>A plugin could be "non-nonsensibly" created to intercept
>all domain requests and responses and doing the encode and decode for ACE
>accordingly. This is all we need to make ACE work.
Provably false: well-coded applications know the limitations of domain
names, and do not even attempt to make
> Do we wish to
>
> 1. eventually move the DNS towards UTF8/16 OR
> 2. do we want to stay with ASCII(ACE) for the rest of our lives?
it's a false dichotomy.
first, there are probably some purposes for which identifiers
(including DNS names) should stay ASCII (and not even 10646
encoded as AS
>> Provably false: well-coded applications know the limitations of domain
>> names, and do not even attempt to make requests for non-ASCII names.
>
>First of all, I disagree with the "well-coded" part because I believe a
>well-coded application will do the dns request as is and allow the dns
>resp
John Stracke writes:
> For that matter, a well-designed application will not even make it
> possible to enter anything but ASCII in an input field (whatever) for a
> domain name.
That's incredibly bad design.
You're violating the basic principles of information hiding articulated
by Parnas in
Keith Moore writes:
> IDNA is designed to maximize the rate at which IDNs can be deployed.
I hereby declare that cs.utk.edu is an IDN. We will now spend twenty
years trying to convince all application programs to display it as the
international picture of an ostrich with his head in the sand.
Lo
Keith Moore wrote:
> it's a false dichotomy.
>
> first, there are probably some purposes for which identifiers
> (including DNS names) should stay ASCII (and not even 10646
> encoded as ASCII) for the forseeable purpose.
Agreed. Well-known data-types such as Message-ID are actually harmed if
th
The story just hit Slashdot -- Senators Hollings, Stevens, Inouye,
Breaux, Nelson, and Feinstein have introduced the so-called "Consumer
Broadband and Digital Television Act of 2002", formerly known to most
of us as the SSSCA. The text of Hollings' comments are available here:
http://www.politech
james woodyatt <[EMAIL PROTECTED]> wrote:
> That there is a profitable business to be made in selling NAT appliances
> to non-technical Internet users is *not* the root cause of the problem.
> It's a symptom, and I think the IETF would do very well to think long
> and hard about how to solve the
Keith Moore <[EMAIL PROTECTED]> wrote:
> notice I did say "in a just world". I don't pretend that this world
> is just. If you want to make money, you have to understand that the
> economic environment we live in favors those who do harm. You can
> choose whether or not to do harm (and to what
"J. Noel Chiappa" <[EMAIL PROTECTED]> wrote:
> I think you're seriously confused here. ISP's don't make a substantial share
> of their money selling addresses (and therefore desiring a scarce market in
> same), and I gather that for most of them, the costs of administering extra
> addresses is ju
On Thursday, March 21, 2002, at 06:15 PM, [EMAIL PROTECTED] wrote:
> Of course, there is the possibility that if they were totally honest,
> and marketed their devices as "Enabling appliances for selected Internet
> services" that they'd STILL make money (and then you'd have no one to
> blame).
P
31 matches
Mail list logo
