rnative.
If IETF makes it clear that AOL is not an ISP, it will commercially
motivate AOL to be an ISP.
Masataka Ohta
o be used on the Internet".
IETF is "Internet Engineering Task Force", not "IP Engineering
Task Force".
IETF can't say anything to braindead protocols of braindead providers
in their purely private IP network.
Masataka Ohta
AOL that I don't have to face it.
It is arrogance of you if you think you must help AOL users.
Just make the IETF definition of "ISP" clear and let ISP competitors
of AOL give reasons to say "AOL is not ISP".
Masataka Ohta
Brijesh;
> NAT is no less offender of the end
> to end design paradigm, than WAP and AOL.
Of course.
Who said otherwise?
Masataka Ohta
?
If you think domain names under TLDs scarese, you should better try
to charge annurally $15000 for domain names directly under TLDs and
for ones indirectly under ccTLDs $15.
Masataka Ohta
g to go to running IP in the handsets?
That's all.
I guess you don't understand the phrase "end-to-end", the essence of
the Internet.
Masataka Ohta
I or any other
protocol, because their backbone is a private network.
Masataka Ohta
you are hyped, your phone can not be free and can not compete
with telephone network), I just confirmed voice quality good enough
between Taiwan and Japan through USA.
Run this kind of protocol over Ricochet terminal and WAP and iMODE
will disapper.
Masataka Ohta
PS
You can purchase a prototype terminal adapter.
er characters slowly (some
quickly) for less important applications like phone calling or
web browsing.
Masataka Ohta
use intended users don't care and unintended users
use something else.
But it is an application specific issue to be discussed outside of
IETF (maybe in W3C).
Masataka Ohta
164.net into the equivalent of 192.36.143.3.
>
> That is, the phone number is merely an identity name, which is converted
> into a location name by a database lookup.
In that sense, DNS names are randomly (more aggressive than sequentially)
assigned addresses.
Masataka Ohta
ct together
> end sites, with v6 being used over that link layer.
That's like having Internet over telephone network and is no good.
> Mechanisms like
> FAITH and 6to4 allow us to move in that direction.
That's a waste of effort. Rely on NAT, there.
Masataka Ohta
l list is probably the wrong place for further extended
> discusssion
Maybe. But it means that entire IETF is the wrong place. Here is a
better place than IPNG WG committee list, where removal of features
can not be accepted.
Masataka Ohta
t but
necessary enhancement, of course.
Masataka Ohta
hyping now?
Masataka Ohta
ustified as a modest but necessary
> > > > enhancement to IPv4,
> > >
> > > I agree with this, and suspect that much of the core IPv6 community
> > > does as well.
> >
> > That's a silly statement.
>
> No it isn't.
For committee
onnectivity between the end systems.
Because end to end multihoming is performed in end systems, the
architecture needs no routing protocol changes. Instead, APIs and
applications must be modified to some extent.
for more details.
Masataka Ohta
on and renumbering.
Do you have any idea on how can it be avoided?
Masataka Ohta
ons about which links to use (given multiple
> choices). but most apps are not FT, and to those that aren't FT,
> address stability under changing network conditions is a boon.
Thus, most apps are taken care of by the transport layer.
READ THE DRAFT.
Masataka Ohta
ft.
READ THE DRAFT.
> Especially if you're also trying to support mobility.
No.
My draft says nothing about mobility, because it is no difficult.
Masataka Ohta
draft, so that we can check
> for ourselves if multihoming works or not...
Befor stating stupid things about my draft, READ THE DRAFT.
Two implementations are pointed to.
It's regrettable that you are using both of them.
Masataka Ohta
Marine;
> A request:
>
> Can y'all please either move the tone of this conversation back to a
> technical discussion
To do so, READ THE DRAFT, which has been the request.
Masataka Ohta
tion by
*INTELLIGENT* intermediate systems.
Users do not want to be annoyed by delay for the negotiation.
And, at the other side of the communication, users can't provide
so much variation of the content.
Masataka Ohta
PS
Of course, people
ke IANA
registration less important.
> As far as the domain of Internet services for mobile devices go, the
> key issue is "Efficiency".
No. It is wrong to assume that bandwidth for mobile devices is
limited forever.
Simplicity is the key issue.
Masataka Ohta
ed IDs are put under:
ftp:ftp.ietf.org/expired-internet-drafts/
or somewhere else.
Masataka Ohta
the end to end principle and does not scale.
Masataka Ohta
uch information, ask Docomo, not IETF.
Or, are you spamming IETF acting as a sales agent of Docomo?
Masataka Ohta
ver iMODE but not over WAP.
OK. OK.
You can discuss it in a specific WG (VPIM).
But you should not bother people in IETF mailing list by repeating
an obvious fact that both WAP and iMODE are dead-end technologies.
Masataka Ohta
But, it is your probelm and has nothing to do with IETF.
Masataka Ohta
eration mobile systems.
Masataka Ohta
asily avoidable delays in wireless
> internet services.
Why do you think "mobile" delays wireless Internet services?
IP mobility protocol is out there and AAA is a problem of
wireless, not mobile, Internet services.
Masataka Ohta
ich country?
Masataka Ohta
s are the only characters
internationally recognizable by so many people.
Masataka Ohta
so called zip code.
Postal address with various characters needs human intervention for
complex matching and is similar not to DNS but to search engines.
Masataka Ohta
or repeated silly conversation like above.
But it is not the place to discuss localized domain name, which
has nothing to do with internationalization.
Masataka Ohta
understand that the current ASCII DNS is already
fully internationalized.
Masataka Ohta
)
local that ccTLDs may or maynot be the local domains.
But, it can be said that gTLDs are not a proper place to put local
names.
Masataka Ohta
orld do people think they can justify or not justify actions
> based on whether something is an advantage/disadvantage in some
> "marketspace"?
They can justify them locally within local marketspaces, of course.
However, they can't justify to call them internationalization.
Masataka Ohta
the localization information to ISO 10646
as I demonstrated, as a silly joke, in RFC 1815.
Masataka Ohta
PS
Note that MIME charsets of "ISO-8859-*" also removes the essential
but optional feature of ISO 2022 to give localization i
able.
That's all and it's working.
Masataka Ohta
ears are wasted until IAB and IESG make the same
statement that assignments should be /48.
Masataka Ohta
ognizing one aspect of the
relationship that, even if multicast is free, customers do not bother
to use multicast if they pay flat rate to receive any amount of unicast
traffic
Those serving the customers simply increase the number of capacity
of servers, of course.
Masataka Ohta
h
multicast group consumes a precious resource of routing table
entry that multicast is a resource reserving communication.
Masataka Ohta
l. Some of them are available in Japanese only, I think.
> I didnt found it in the internet-drafts at the IETF !!!
I think it was not posted at all.
Masataka Ohta
arned to have more servers. See my column
article on the most recent IPSJ magazine for details.
That's all.
Masataka Ohta
he receivers. ;-)
Masataka Ohta
ink local multicast, which is unnecessary as,
following the CATENET model, internet should not include
large link layer, which ATM network dreamed to be.
Masataka Ohta
tually MSDP) core has nothing to do with
the Internet core routing system.
Masataka Ohta
on better.
Masataka Ohta
Keith;
> > I think you missed the important point. It's not the NAT vendors, it's
> > the ISPs.
>
> I'll grant that ISPs have something to do with it. But there is a
> shortage of IPv4 addresses, so it's not as if anybody can have as
> many as they want.
Wrong.
There actually is no shortage o
exist.
While some implementations work in some localized context, local
character set serves better for the context.
Masataka Ohta
s not widely used today, than existing
local character sets already used world wide.
Masataka Ohta
panese local unicode-based character set.
Unicode is not useful in international context.
Masataka Ohta
f current and past charset reviewers including you.
> Therefore, depending on "charset" to identify context is not only useless,
> but actively harmful.
Agreed. ISO 2022 escape sequence is the way to go.
> My opinion, which I stated in RFC 1766, and have found no reason to change.
It was already denied by real world examples.
Masataka Ohta
Erkki I. Kolehmainen;
> The use of local character sets (encoding) is doomed for particularly ww
> information interchange.
Interestingly enough, ww information interchange is working very
well with local character sets.
The reason is because only people sharing a language, a scripting
system a
i script:
IDN tte zenzen dame
follows, as you can easily guess, usual folding rules for Latin-based
scripts.
But, anyway, the discussion so far in IETF list is enough to deny IDN.
I'm happy to discontinue the thread, then.
Ma
, thanks to poor charset reviewing, essentaily is
yet another charset designaiton, is attached.
Masataka Ohta
TLDs.
>
> Very interesting. Could you share the theory, or privately if you prefer?
I will post it later if I have time.
Masataka Ohta
tml
Enjoy.
Masataka Ohta
--
Application Form for MIS/Miako Account
(mailto:[EMAIL PROTECTED])
Name:
Home (not IP but Postal) Address:
Country:
Email (optional):
Number of Accounts You can be Responsible for (default: 1):
Authorized Mail Address:
Name and page # of an
er, in the future, inexpensive base stations of WLAN are
essential to cover small holes of connectivity.
Masataka Ohta
relies
on rather static information stored on intermediate systems at the
time of signalling.
> A fragment (IPv4 fragment) may not be.
An IPv4 fragment, however, has full information on source and
destination hosts and is a datagram, though, it does not have full
information on source and destina
ngineering decision to allow optional circuit
switched service over a best-effort-capable network.
Masataka Ohta
ed anytime.
To say "flow" on packets not on flows is incorrect.
Masataka Ohta
However, you should also be aware that RSVP is virtually useless
without QoS routing.
Masataka Ohta
on.
New comers don't need two different models.
Masataka Ohta
eak.
You can't reserve 1Gbps on the best effort path with T1 circuit, even
if the T1 circuit is not broken.
Masataka Ohta
problem is that a protocol to tweak the control of an underlying
> > bandwidth allocation is pretty useless if there isn't enough bandwidth
> > to tweak.
>
> I'm aware of that.
Then, there is no reason to insist on detailed terminology of useles
protocols such as ATM and RSVP.
Masataka Ohta
ttp://www.lab1.kuis.kyoto-u.ac.jp/~arifumi/paper/saint2003html/
Masataka Ohta
ates. The same is even more true of the
> likes of Google, Cisco, Apple, IBM, Microsoft etc.
You miss the most important stakeholders, the end users aligning
to countries.
Masataka Ohta
PS
Of course, countries acting as representatives for telephon
t;.
ITU did it better for phone numbers.
Masataka Ohta
ssues.
Masataka Ohta
zed packets.
Masataka Ohta
kets from different countries at border towns.
> But the main long range 2G/3G signals are
> TDMA or CDMA in regulated bands.
Forget them.
Masataka Ohta
empt all the already assigned
bandwidth within their border.
Anyway, there can be no inter-border coordination by ITU-T
between fighting countries.
Masataka Ohta
l, TELNET).
The basic rule of the RFC is:
Although labels can contain any 8 bit values in octets that make up a
label
A label may include '.' character as is, as there is no escape
mechanism, though applications expecting host names may fail to
recognize it.
Masataka Ohta
]
and everything should be fine.
Masataka Ohta
years.
But, copyright of some movies expired at the end of 2003.
There were disputes in courts and the supreme court judged
that copyright of the movies expired.
Masataka Ohta
P
mostly unusable.
Masataka Ohta
gt; I'm pretty sure the saving on headers is more than made up for in
> FEC, delay, etc. Not the engineering tradeoff one might want.
It has nothing to do with congestion, not at all.
Masataka Ohta
t loss.
Masataka Ohta
properly supported. It is not very difficult to have done so.
Masataka Ohta
gt; IPv6 was no need for changes to TCP and consequent transparency
> to most applications. Ha!
There is no need for IPv6 specific changes.
Masataka Ohta
d manner involving all the nodes.
Masataka Ohta
a at that time.
Not at all.
It was merely that those who had little operational insight had
thought so.
Rest of the people developed DHCP and, now, you can see which is
better.
Masataka Ohta
as.
> With IPX, AT address assignment was automatic. No DHCP in those old
> times.
That something was automatic only to produce useless (to me) results
does not mean it was a good idea.
Masataka Ohta
#x27;t have to
waste time and packets to have DAD, with additional overehead
of IGMP, to confirm all the distributed nodes maintaining the
state of SLAAC consistently, that is, a new configured address
is unique.
Masataka Ohta
server is fine, it is not
a problem.
Masataka Ohta
>
nt 1).
Changing TCP is required not for address space extension but
for better handling of multiple addresses for better routing
table aggregation.
Masataka Ohta
Phillip Hallam-Baker wrote:
> Once you have established an SSH relationship
That's the (lack of) security of SSH by return routability. PERIOD.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.o
ing CA, is not
infallible, which is why PKI is insecure.
Is EV divine?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
PKI is a system of fraud.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
enerations. You may also use elliptic curve cryptography,
though I don't prefer it.
But, later, I noticed fundamental fraud in PKI, against which no
technical solution exists. Note that separation of ZSK and KSK
was an impossible attempt make inherently insecure PKI less
insecure.
not accountable at all.
That's all.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
please don't convert someone else's pure
ASCII message into something else.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
related topics.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
pable PDF.
Q.E.D.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
characters.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
nothing but ASCII
characters.
Note also that the wrong conversion is by Tim Bray who says:
> I will commit to offering some cycles to help with tools
> and specs, as appropriate.
How much reliability, do you think, the tools and specs will have?
d R in
metadata for pdf:Creator.
Thank you for a convincing demonstration to deny yourself.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
and there are lots of other bytes in
> this file with the high bit set, if we want to bring that up too.
As we are discussing about text format, let's ignore PDF. PERIOD.
Masataka Ohta
___
201 - 300 of 574 matches
Mail list logo
