On Sun, 3 Nov 2002, The IESG wrote:
The IESG has received a request from the Prefix Taxonomy Ongoing
Measurement Inter Network Experiment Working Group to consider NOPEER
community for BGP route scope control
draft-ietf-ptomaine-nopeer-00.txt as a BCP.
The IESG plans to make a decision in
. If anyone who is going to Atlanta is interested in hearing
about what's happening in and around multi6, let me know.
Iljitsch van Beijnum
, and we
would be happy to provide an overview of what has been discussed on
multi6 (not just our own drafts/ideas) to anyone who's interested.
Contact me off-list for this.
Iljitsch van Beijnum
PS. Let me remind you in advance that this is NOT the forum to discuss
the feasability
On donderdag, jun 5, 2003, at 19:13 Europe/Amsterdam, Haren Visavadia
wrote:
Each CA has its own CPS. How do you the CA conduct its CPS accordingly?
Fortunately, as far as the spam issue is concerned, this question is
moot: unlike a breach of confidentiality, a breach of spamfreeness is
On dinsdag, mei 27, 2003, at 03:35 Europe/Amsterdam, Masataka Ohta
wrote:
I've looked over your draft quickly, however I don't see
what applicability statement is possible.
It is a reality check agaist people dreaming of magical
deployment of IPv6.
It can also be a proposal to shutdown
On maandag, mei 26, 2003, at 20:36 Europe/Amsterdam, Eric A. Hall wrote:
The issue of detecting abuse was the focus of the MIT anti-spam
conference. There are many paths presently being pursued: Blacklists,
header analysis, and various kinds of content analysis. I think the
general consensus
On woensdag, mei 28, 2003, at 02:36 Europe/Amsterdam, J. Noel Chiappa
wrote:
Anyway, this whole discussion is moot.
I couldn't agree more. The bottom line is that most people simply don't
want to receive spam, often to the degree that they are willing to pay
extra to get rid of it.
I'm sure
On woensdag, mei 28, 2003, at 19:56 Europe/Amsterdam, Christian Huitema
wrote:
It surprises me that so many people are so eager to declare defeat
before even trying the protocol route. (With current protocols defeat
is pretty much inevitable.)
There is an obvious issue with the protocol route:
On woensdag, mei 28, 2003, at 21:39 Europe/Amsterdam, Dean Anderson
wrote:
It surprises me that so many people are so eager to declare defeat
before even trying the protocol route.
We tried protocols 5 years ago. They haven't worked. I've explained
why
specifically, and why in theory they
On donderdag, mei 29, 2003, at 17:44 Europe/Amsterdam, Vernon Schryver
wrote:
I found the following to be an interesting read:
http://www.cdt.org/spam/
It shows that even five years ago or so most ligitimate businesses
advertising legitimate services through spam employed header forgery.
...
On donderdag, mei 29, 2003, at 21:34 Europe/Amsterdam, Tony Hain wrote:
The fundamental legal issue we need to deal with is the ability to
absolutely identify the originator of the mail. Is that precluded by
any
existing privacy laws? If not, identity would provide the means to
pursue financial
On donderdag, mei 29, 2003, at 23:06 Europe/Amsterdam, Dave Aronson
wrote:
[Having to do crypto for each outgoing spam]
Keep in
mind, they could always simply apply the usual Microsoft solution:
throw
more and faster hardware at it. Note also that a lot of spam is
already
sent to single
On vrijdag, mei 30, 2003, at 02:18 Europe/Amsterdam, Christian Huitema
wrote:
However, creating new publick/private key pairs is an incredibly
expensive operation,
Uh? Creating a Diffie-Hellman public/private key pair is actually
quite
simple. Even an RSA pair is not all that hard, considering
On vrijdag, mei 30, 2003, at 16:45 Europe/Amsterdam, Vernon Schryver
wrote:
spammer spams for an entire weekend until his account is yanked,
I've picked that fragment out of context only as an example of the
larger religion that holds most spam is forged as an article of
faith.
Most of it is.
On zaterdag, mei 31, 2003, at 17:32 Europe/Amsterdam, Paul Hoffman /
IMC wrote:
To bludgeon the point a bit:
- Big ISPs and other mail service providers know how much spam is
costing them.
Ah, but how much does spam earn them? I assume spammers pay for their
bandwidth. Then there are all the
On zondag, jun 1, 2003, at 23:48 Europe/Amsterdam, Vernon Schryver
wrote:
So I'll repeat myself: let's have an anti-spam BOF
Face to face talk is likely to be of even lower quality than this
thread.
But aren't you supposed to have a BOF first before you can have a wg?
BOFs are transient
(I really wanted to stop this thread with my previous message, but...)
On woensdag, jun 4, 2003, at 02:54 Europe/Amsterdam, Tony Hain wrote:
Just adding authentication only solves a very small part of the
problem: we can then accurately whitelist known senders.
Two points:
1) besides white
On maandag, jun 16, 2003, at 17:47 Europe/Amsterdam, Hallam-Baker,
Phillip wrote:
The think I find mindboggling about all this is that I have yet to see
a
concise explanation of how the great transition to IPv6 is going to be
managed and what the incentive for early adopters is going to be.
On woensdag, jun 18, 2003, at 04:33 Europe/Amsterdam, Hallam-Baker,
Phillip wrote:
I really wish that the IETF had designed a decent NAT box spec rather
than adopting the ostrich position.
http://www.ietf.org/html.charters/nat-charter.html
On woensdag, jun 18, 2003, at 21:17 Europe/Amsterdam, Bob Braden wrote:
Since 1980 we have believed that universal connectivity was one of the
great achievements of the Internet design. Today, one must
unfortunately question whether universal connectivity can be sustained
(or is even the right
On donderdag, jun 19, 2003, at 13:49 Europe/Amsterdam, J. Noel Chiappa
wrote:
Maybe NATs are, in fact, a result
of a very deep problem with our architecture.
My take is that NAT's respond to several flaws in the IPv4
architecture:
- 1) Not enough addresses - this being the one that brought
On donderdag, jun 19, 2003, at 23:42 Europe/Amsterdam, Eric Rescorla
wrote:
Realistically, there are three kinds of utility
effects of someone choosing to install a NAT:
(1) The effect on them personally.
(2) The effect on other people who might potentially correspond
with them (a rather
On woensdag, jul 2, 2003, at 23:43 Europe/Amsterdam, S Woodside wrote:
I think there's a problem with the name end-to-end. End is a word
with a lot of definitions: for example wordnet [1] lists 14 senses for
the noun end and 4 more for the verb. Indeed, we must walk down to the
5th definition
On zondag, jul 6, 2003, at 10:18 Europe/Amsterdam, Pedro Fortuny wrote:
Getting started with the IPv6 protocol (and new to this list :)
Any basic references (no need to be exhaustive at all) (I mean, six
or seven rfc's would be more than ok).
A good start would be:
Internet Protocol, Version 6
With regard to draft-baker-slem-architecture-01.txt and the surrounding
issues: is anything happening in this area in Vienna?
On woensdag, jul 16, 2003, at 21:59 Europe/Amsterdam, Keith Moore wrote:
I'm not sure what the problem is here:
- UDP checksums are optional
Not in IPv6. If this is the only thing we need at the transport layer
then we might want to change this back to the IPv4 behavior.
- IPv6 could define an
On donderdag, jul 17, 2003, at 14:24 Europe/Amsterdam, Keith Moore
wrote:
] I would have a hard time taking an IP header bit and making it the
Do
] not drop this packet in the presense of a bit error somewhere in the
] frame from layer 2 - layer 3. Don't think it is a good idea.
I don't know
On woensdag, aug 6, 2003, at 23:41 Europe/Amsterdam, Vernon Schryver
wrote:
xactly what in http://www.ieee802.org/16/docs/03/C80216-03_07.pdf
could possibly be a reasonable topic for the IETF to consider?
I look forward to seeing the IEEE reinvent the network layer and put it
_below_ the link
On donderdag, aug 7, 2003, at 00:40 Europe/Amsterdam, Vernon Schryver
wrote:
I look forward to seeing the IEEE reinvent the network layer and put
it
_below_ the link layer. This should be fun.
How is the IEEE reinventing the network layer this time? They really
have tried in some previous
On dinsdag, aug 19, 2003, at 09:14 Europe/Amsterdam, NM Research wrote:
Please qualify your false statement I would appreciate - what was
A-net all about.
The confusion that the ARPAnet supposedly had a military function stems
from the research done by Paul Baran at the RAND Corporation in the
On maandag, aug 25, 2003, at 10:15 Europe/Amsterdam, Randy Bush wrote:
unless there is a reason why that host should not be using v6
services, hmm?
because it works now?
But for some boxes only if I use NAT, and having to use NAT makes for a
liberal definition of works.
v6 has one salient
On dinsdag, aug 26, 2003, at 10:09 Europe/Amsterdam, NM Research wrote:
A scenario where all the ecommerce code and routing
code ( paid traffic ) would fail is if the Financial
Capital City of the World is Struck in a light nuke
attack. Are you, or is the code capable of handle
this ?
This is
On woensdag, aug 27, 2003, at 20:33 Europe/Amsterdam, Keith Moore wrote:
we need to move the FQDNs and especially IP addresses away from
identifying hosts, and introduce and explicit host or stack name
identifier.
mostly agree, except that I suspect it works better to put the new
layer
On vrijdag, aug 29, 2003, at 23:06 Europe/Amsterdam, Keith Moore wrote:
It's not uncommon to see a FQDN point to several IP addresses so that
the service identified by the FQDN can be provided either by
(a) multiple hosts, or
(b) a host with multiple addresses.
No. A client can't tell whether
On zaterdag, aug 30, 2003, at 21:28 Europe/Amsterdam, Christian Huitema
wrote:
Obviously, cutting of the A root would have some pretty drastic
consequences.
If that is the case then some people have been reading the relevant
RFCs with their eyes closed. The only consequence should some sporadic
On woensdag, aug 27, 2003, at 18:48 Europe/Amsterdam, Tony Hain wrote:
but if that only applied to apps using a new stabilization layer,
there wouldn't be as much complaint because those would see a clear
benefit.
So when will vendors recompile their apps for multihoming? Right after
they're
On woensdag, aug 27, 2003, at 18:52 Europe/Amsterdam, jfcm wrote:
Using a 1D numbering plan to support 5 (?) distinct dimensions (plan,
technology, network routing, global host addressing and interface
identification) looks like X121 or old telephony.
Which additionnal information do you need
On dinsdag, sep 2, 2003, at 20:22 Europe/Amsterdam, Scott Bradner wrote:
Perhaps, perhaps not. I live in Ontario Canada and in the recent
blackout, my phone kept working.
i.e., you did not have a ISDN or wireless phone
The telco can provide power over the ISDN line for a single device on
the
On woensdag, sep 3, 2003, at 17:33 Europe/Amsterdam, Dave Crocker wrote:
PN Well, I consider an *identifier* as something that is more or
PN less intrisically bound to an identity and a *name* as something
PN that merely indicates an entity,
I had not run into this distinction before. Now that
On woensdag, sep 3, 2003, at 23:34 Europe/Amsterdam, Vernon Schryver
wrote:
It is just plain ***WRONG!*** to even start to consider anything but
ASCII for the official documents. As hard as it is for the unscared
to believe, even XML will fade away completely and be replaced by
something else
IANAXE*, so I may be saying something stupid here, but...
Wouldn't it be possible to come up with a DTD that makes it possible to
tag all the different parts of a draft or an RFC to enable all the
automated processing we love so much, but in such a way that when all
the .* sequences are
On donderdag, aug 21, 2003, at 13:05 Europe/Amsterdam, JORDI PALET
MARTINEZ wrote:
Can the list be moved to a server that supports IPv6 transport? E.g.,
it looks like all the ops.ietf.org lists are delivered over IPv6 now.
I have received messages for the [EMAIL PROTECTED] list over IPv6
once
On vrijdag, sep 5, 2003, at 23:15 Europe/Amsterdam, Spencer Dawkins
wrote:
Dave's MAST proposal was announced at
http://www.ietf.org/mail-archive/ietf-announce/Current/msg25938.html.
It is not entirely clear where this draft should be discussed. I
bailed and sent my comments to Dave offlist,
On zondag, sep 7, 2003, at 21:45 Europe/Amsterdam, Dean Anderson wrote:
Information theory says that such things are impossible. One can not
construct a spam-free protocol because this is the same problem as
constructing a system free of covert channels, which information theory
says is
On maandag, sep 8, 2003, at 11:14 Europe/Amsterdam, Zefram wrote:
Vernon Schryver wrote:
I've been compiling a list in the style of Jeff Foxworthy.
You Might Be An Anti-Spam Kook If
Please publish this as an RFC. A collection of unworkable approaches
to the spam problem
On maandag, sep 8, 2003, at 17:30 Europe/Amsterdam, Dean Anderson wrote:
Nobody cares. Making a roof 100.00% impervious to water molecules
may be impossible, but that doesn't mean we have to resign to getting
wet every time it rains.
People care because when someone comes around saying you
On dinsdag, sep 9, 2003, at 19:41 Europe/Amsterdam, Dean Anderson wrote:
Let's first define our goal before declaring it impossible to reach.
Well, I think the goal has been stated: Create an abuse-free email
protocol. That goal is impossible. Thus, we have abusable protocols.
Ok, not going to
On maandag, sep 15, 2003, at 03:50 Europe/Amsterdam, Dean Anderson
wrote:
I think that content analysis holds much promise. Only a few years
ago, we
thought that speaker-independent voice recognition was science fiction.
And in the '60s we thought we'd all be going to work in a rocket by now.
On dinsdag, sep 16, 2003, at 12:25 Europe/Amsterdam, Karl Auerbach
wrote:
1. Via ICANN, instruct Verisign to remove the wildcard.
It isn't clear that this power is vested in ICANN. There is a
complicated
arrangement of Cooperative Agreements, MOUs, CRADAs, and Purchase
Orders
that exist
For those who aren't on the ICANN press list:
Marina del Rey, CA 30 September 2003 ICANN's Security and Stability
Advisory Committee (SECSAC) announced today that it will hold a special
meeting on 7 October 2003 to gather input regarding VeriSign's recent
change to the operation of the
-attachment
Huh?
Iljitsch van Beijnum
On zaterdag, okt 11, 2003, at 09:40 Europe/Amsterdam, Leif Johansson
wrote:
|Tell that to the root zone operators and brace for the reaction.
| Root zone operators, meaning like Verisign?
Yes. I recently sat in on a presentation from the operators of
I.root-servers.net. Currently 8-10% of
to become much more interesting.
I guess it all depends on how you look at it: either the glass is half
empty (still 1.5 billion addresses still free) or it's 97% full (31
bits down, one to go).
Iljitsch van Beijnum
On zondag, okt 12, 2003, at 03:23 Europe/Amsterdam, Scott Bradner wrote:
If you have $2500 to ante up for the allocation.
you might take a look at the RIR web pages - it does not cost
an ISP $2500 to get additional address space allocated - the
additional fee for additional space for large ISPs
On 15 okt 2003, at 19:45, Keith Moore wrote:
the marginal sin of
intercepting DNS queries for private addresses, to prevent the
sort of problems those queries cause, seems to me to be fairly
small.
I probably agree. But I guess my question is where does it end?
It ends when IPv4 ends. That is,
On 2 nov 2003, at 18:41, Eric Rescorla wrote:
Has anyone out there worked out how to get the IETF schedule
into your Palm in some fashion more convenient than just
typing it in?
I see lots of people use Macs, so an iCal shared calendar would be
useful too. I typed in around 30 of the nearly 110
On 9-nov-03, at 16:53, Randy Bush wrote:
Right now, I'm hearing (from where I'm sitting) eight different
802.11b
base stations on channel 6. Is this the intended configuration?
it is not an accident. it is not the production plan. but they
are not charging extra for it at the moment. :-)
So
On 10-nov-03, at 9:53, Joel Jaeggli wrote:
It would be nice for whoever lays on such provision for the IETF to
document their approach. I enquired about this on this list after
Vienna, but got no reply.This would be helpful for other people
organising events where a few hundred wireless
On 13-nov-03, at 16:44, Carsten Bormann wrote:
it turned out that when I replaced my Linksys 802.11b with
a brand new Motorola 802.11g the problem went away; there is a Radio
Shark on the third floor of City Center that sells them for $70.
Similarly, when I put a $70 Linksys WPC54G (directly
On 14-nov-03, at 23:08, Henk Uijterwaal (RIPE-NCC) wrote:
I strongly encourage people to consider bringing 802.11a cards to
future meetings! (Note: Of course, now that I've said that, the
future
hosts will decide against deploying it)
If we go for 802.11a, I sugggest that we ask a vendor (or
On 18-nov-03, at 15:56, Perry E.Metzger wrote:
The fact that 802.11 tries to be
reliable by doing its own retransmits results in massive congestive
collapse when a protocol like TCP is run over it.
Hardly. TCP plays nice and slows down when either the RTTs go up or
there is packet loss (which
On 18-nov-03, at 19:48, Keith Moore wrote:
I already indicated before: 100-150 Euros more is not a big issue.
I strongly and emphatically disagree, and I strongly object to
attempts to
use of increased meeting feeds to discourage some parties from
participating
at IETF. Basically this kind of
On 18-nov-03, at 23:44, Steven M. Bellovin wrote:
Maybe this would be a good time to explain what the IETF needs a 9.33
person secretariat for, and why the secretariat must be entirely
funded
by meeting fees.
The Secretariat handles I-D processing, meeting planning, IESG
telechats, software
On 19-nov-03, at 1:38, Eliot Lear wrote:
I think part of the blame should go to the access points that kept
disappearing. Someone told me this was because the AP transmitters
were set to just 1 mw. If this is true, it was obviously a very big
mistake.
Oh really?! Please explain why.
Ok,
On 19-nov-03, at 18:03, Dave Crocker wrote:
I think that enhanced character sets is a perfect topic for having the
IETF eat its own dogfood. Just dealing with the details of the name
tags might well prove instructive to us, nevermind the basic
politeness
it offers to attendees.
Easy to say
On 19-nov-03, at 17:45, Perry E.Metzger wrote:
However, RED like approach to attempt retries only a few times may be
a good strategy to improve latency.
A RED approach would be good,
15 authors of RFC 2309 can't be wrong. :-)
but in general there has to be a limit
on the queue. Your wireless
On 19-nov-03, at 23:16, Perry E.Metzger wrote:
I think there is some middle ground between 25000 and 10 ms.
10ms is the middle ground. That's enough for a bunch of retransmits on
modern hardware.
Retransmits on what type of hardware? At 1 Mbps transmitting a 1500
byte packet already takes 12
On 20-nov-03, at 4:05, James Seng wrote:
I think having the punycode form have no value on a name badge.
Punycode, as it is designed, is meant for machine-to-machine
communication.
So why don't we come up with a machine-to-human transliteration
mechanism? So if someone called (trouble with
On 19-nov-03, at 22:28, JORDI PALET MARTINEZ wrote:
It should be RFID, cheaper, and easier, not only for the blue sheets.
Wouldn't it be even cheaper if everyone who has a laptop with wireless
with them signs in on an electronic version of the blue sheets? This
just takes a few hours of
On 23-nov-03, at 12:47, James Seng wrote:
Yes, there is leakage in Punycode now and will be for a while. It is
not nice but I couldnt think of any encoding which wont leak. (UTF-8
will give you gibberish if client are not UTF-8 aware or with the
right fonts). Same arguments we have in IDN WG
On 27-nov-03, at 23:20, jfcm wrote:
Some others have technical implications. I would like to quote some
suggestions listed in the preparatory document, to get advices I
could quote at the meeting or in its report. Also to list the
alternative and additional suggestions some might do.
Ok, I'm
On 28-nov-03, at 14:47, Anthony G. Atkielski wrote:
I guess not because I have no idea what you're talking about.
There is a natural tendency to think that by dividing a 128-bit address
field into two 64-bit fields, the address space is cut in half (or
perhaps not diminished at all).
Ah, I see
On 30-nov-03, at 4:17, [EMAIL PROTECTED] wrote:
The at current burn rate assumption is far from safe though...
Oh? Have any better-than-handwaving reasons to suspect the current
allocation rate will change drastically?
I have a slightly better than handwaving indication that the current
On 2-dec-03, at 20:42, Schiro, Dan wrote:
Fortunately the mistake is easily rectified, so long
as software doesn't get into the habit of expecting the lower 64 bits
of an address to be a unique interface identifier.
This is a dangerous prospect. The company I work for makes a
networking
On 2-dec-03, at 21:04, Anthony G. Atkielski wrote:
Why dedicated /64 to anything? We are getting by just fine on /32 for
the whole world right now. Why is a sudden expansion of 2^32 required
RIGHT NOW?
Stateless autoconfiguration.
See, that's the classic mistake: Everyone wants to divide the
On 2-dec-03, at 20:03, Keith Moore wrote:
RFC 3513 mandates that all unicast IPv6 addresses except the ones
starting with the bits 000 must have a 64-bit interface identifier in
the lower 64 bits.
This was shortsighted, just like having the notion of class built
into
IPv4 addresses was
On 3-dec-03, at 21:21, Anthony G. Atkielski wrote:
It was well understood that it was important to keep most of the IPv6
address space open to allow for future use.
If it were well understood, nobody would have ever been foolish enough
to suggest blowing 2^125 addresses right up front. I've
On 5-dec-03, at 1:37, Franck Martin wrote:
Finally before a root-server is installed somewhere, someone will do
an assessment of the local conditions and taylor it adequately. I want
countries to request installation of root servers, and I know about 20
Pacific Islands countries that need
On 5-dec-03, at 17:16, Dean Anderson wrote:
Indeed, this is what they do when the agree to put the national root
nameservers in their own nameserver root configs. It is far easier to
have per-country stealth root slaves than it is to make every
nameserver
the stealth slave of every other domain
On 6-dec-03, at 23:04, Dean Anderson wrote:
I don't think this stealth business is a very good idea. If you want a
root servers somewhere, use anycast. That means importing BGP problems
into the DNS, which is iffy enough as it is.
That seems to argue against anycast...
If there were 65 actual
On 7-dec-03, at 2:26, Paul Vixie wrote:
... (Selecting the best path is pretty much an after thought in
BGP: the RFC doesn't even bother giving suggestions on how to do
this.)
congradulations, you're the millionth person to think that was an
oversight.
I don't think this is an oversight, I'm
On 7-dec-03, at 20:52, Paul Vixie wrote:
Just for fun, I cooked up a named.root file with only those IPv6
addresses
in it. This seems to confuse BIND such that its behavior becomes very
unpredictable.
hmmm. that configuration works fine for me here.
Ok... But does it also do anything useful?
On 8-dec-03, at 22:01, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything /35.
Generally ISP's should be filtering on allocation boundaries.
Thus if a certain prefix is allocated as a /32, they should not
be accepting anything smaller (/33, /34 etc)
So how are ISPs
[my apologies for burning so much bandwith]
On 8-dec-03, at 22:17, Zefram wrote:
Just wondering, as I have about IPv4 anycast allocations: why can't we
designate a block for microallocations, within which prefix length
filters
aren't applied? The number of routes in the DFZ is the same either
On 10-dec-03, at 10:28, leo vegoda wrote:
http://lacnic.net/en/chapter-4.html
http://ftp.apnic.net/apnic/docs/ipv6-address-policy
http://www.ripe.net/ripe/docs/ipv6-policies.html
http://www.arin.net/policy/ipv6_policy.html
http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02
In fact, we
On 12-dec-03, at 22:24, Theodore Ts'o wrote:
Does that mean that Path MTU was badly designed, because it failed to
take into account stupid firewalls?
Path MTU disovery was implemented very poorly because implementations
tend expect certain functionality in routers, and usually don't recover
On 15-dec-03, at 14:03, Spencer Dawkins wrote:
Your definition of broken is a little off. I would think the broken
implementation is the one that misunderstood the definition.
reserved as i have been enlightened privately has been clearly
defined at IETF as:
a) Must be set to zero on
On 16-dec-03, at 12:06, jfcm wrote:
I suggest ISO should define an international trans network numbering
scheme that could be adopted as the IPv6.010 numbering plan, the same
way as the ccTLD list is the ISO 3166 2 letters list, and IDNA uses
unicodes etc.
The ISO is already in charge of NSAP
On 17-dec-03, at 1:34, Sandy Wills wrote:
I would like to propose a solution to the looming religious war:
Some people are serious about wanting to see every message that
crosses the ietf domain, and will offer violence to anyone who wants
to keep their daily dose of spam away from them.
You could find more information about our project in
http://202.114.9.200/English/main.htm
Hm, it won't open for me.
I've looked over your other documents and it seems you mainly focus on
organization in general and organization by domain in particular. I
don't really have an opinion on whether
On 31-dec-03, at 17:47, Scott W Brim wrote:
I'd like to see more semantic
information in search engines. Eventually, this would allow queries
like which actors played in movies after books written by authors
born
in Chili in 1961?
Is SCORM useful to you? http://www.adlnet.org
As far as I can
On 12-jan-04, at 20:55, Gordon Cook wrote:
http://www.fourmilab.ch/documents/digital-imprimatur/ is the really
spooky essay. Excerpted in my December issue.
Read the Digital Imprimatur if you haven't already.
I find it a tad on the wordy side... (27731 words, to be precise, more
than an hour
On 12-jan-04, at 21:13, Paul Robinson wrote:
The modern Internet is run by marketing, not technical, requirements.
IPv6 will not take off any time soon because neither the end-user nor
the service provider sees the need. The moment AOL, Wanadoo, Tiscali,
World Online et al shout out we *need*
On 13-jan-04, at 10:36, Paul Robinson wrote:
Continuing work on IPv4 only creates the illusion that it is a viable
protocol for application developers to rely on for future income.
Are you suggesting then, that all RFCs based on IPv6 should be...
stopped?
I think that one should read IPv4...
On 14-jan-04, at 17:43, Fred Baker wrote:
It seems to me that there is a better approach to the above, at least
in the context of the above. If the tombstone is literally as
described, it would be far more space/search/etc efficient for us to
have the tombstone consist of an added text line in
On 15-jan-04, at 12:48, Yuri Ismailov (KI/EAB) wrote:
I share pretty much the views expressed on the page.
I don't share all of them (9 billion people in 2050, 3.7 billion usable
IPv4 addresses, show me some math that makes this work) but where on
this page is there a point being made? It seems
On 15-jan-04, at 18:12, Dean Anderson wrote:
But whether you internetwork with IPv6 and NAT, or just keep IPv4, NAT
will not go likely go away.
Directly internetworking IPv4 and IPv6 (where an IPv4-only host talks
to an IPv6-only host) is only possible for IPv6 hosts that use an
IPv4-compatible
On 18-jan-04, at 19:39, Bob Braden wrote:
So let's consciously endeavor to ensure that sigificant
non-standards documents -- responsible position papers, white papers,
new ideas, etc. -- become RFCs.
Sigh. Even more RFCs. Pretty soon we're going to need a 32-bit RFC
number space.
(Making
On 18-jan-04, at 23:17, grenville armitage wrote:
Actually it's pretty much the same topic, as there needs to be a way
to
preserve drafts that are important in some way or another.
If it is important, it'll progress the work of some group in the
IETF and be archived as an RFC.
Really. What's
On 25-jan-04, at 18:54, [EMAIL PROTECTED] wrote:
In this case I cannot map the IP address of the TCP session to one
specific
mobile subscriber - and the only way I can
identify the subscriber is by looking on the SMPP layer (above the
TCP)
and extract the subscriber mobile number.
It's
1 - 100 of 628 matches
Mail list logo
