RE: Certificate / CPS issues

[Dan Kohn]

Regarding a "passport" mechanism, have you taken a look at
www.habeas.com?  Specifically, they offer such a "this is not spam"
warrant mark, and the pricing for individuals is free.  The trick is
that they use copyright and trademark law as the enforcement mechanism. 

(NB: I helped start the company.)

      - dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com/>  

-Original Message-
From: Graham Klyne [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2003 03:50
To: Hallam-Baker, Phillip; '[EMAIL PROTECTED]'

At 12:12 05/06/03 -0700, Hallam-Baker, Phillip wrote:
>A spam sender could attempt to use disposable certificates in the same
way
>that IP addresses and dialup accounts are considered disposable. This
is
>unlikely to work for long, the spam sender can set up lots of shell
>companies at the same address but if the CA keeps authenticating to the
same
>address or phone number the pattern will soon become apparent.

Hmmm... is there an economic play here?


First, briefly, my view of the spam situation.  I don't think it's 
fundamentally an Internet protocol design issue (though some design
tweaks 
may help).  Essentially, I think people currently have the choice of
(1) putting filters in place and accept the loss of some non-spam mail,
or
(2) accepting a deluge of spam, and not lose any mail.  In practice, I 
think this option doesn't exist, because I find that (lacking spam
filters) 
I do lose a few pieces of non-spam mail because I don't recognize the 
sender or subject.  So I see a way forward to be a "passport" mechanism
to 
reliably bypass automated spam filters, a kind of whitelist++.


So back to my question: is there an economic play here?

(I was offered the opinion once that a big *disadvantage* of email
compared 
with fax for business transactions was that it has almost zero
incremental 
cost of use.)

I'm thinking of a cert issued for a small sum of money, without any 
authentication other than the purchaser promises something like "I
promise 
not to spam with this certificate".  At the earliest evidence of it
being 
used for spamming, it is revoked.  The price should be small enough to
be 
accessible to any reasonable person, but high enough that the bill for 
daily or hourly renewal would become significant.

Maybe crazy, just thinking aloud...

#g


---
Graham Klyne
<[EMAIL PROTECTED]>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E


___
This message was passed through [EMAIL PROTECTED],
which is a sublist of [EMAIL PROTECTED] Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

RE: Network Working Group

[Dan Kohn]

Fred Baker wrote:

>> Network Working Group
 
> The Network Working Group, as such, has not been functional for
> nearly 20 years.

> I personally would like to see us stop attributing documents to them.
> The world has long since moved on, and those who don't recognize it
> date themselves.

Fred, I'd respectfully like to disagree.  I believe the Network Working
Group tag represents the continuity in Internet engineering and
documentation that follows continuously from Steve Crocker's RFC 1
(written April 1969 in a dry bathtub, I believe, so as not to wake the
friends he was staying with) down to the latest RFCs and I-Ds.

I'm not sure that I'm a good enough engineer to have been involved with
the original Network Working Group, but I'm honored to participate in
the design tradition (especially the open publication of informational
and standards documents, rough consensus, working code, etc.) that that
label represents.

  - dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com/>  

RE: RFC authoring tools

[Dan Kohn]

Are you in luck.  Marshall Rose has provided us with a lovely little
tool called xml2rfc, which also supports output to HTML.

http://xml.resource.org/

  - dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com/>

  Randomly generated quote:
As the British Constitution is the most subtle organism which has
proceeded from the womb and long gestation of progressive history, so
the American Constitution is, so far as I can see, the most wonderful
work ever struck off at a given time by the brain and purpose of man.  -
W.E. Gladstone


-Original Message-
From: Florian Weimer [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, January 04, 2003 07:11
To: [EMAIL PROTECTED]
Subject: RFC authoring tools


Are there any tools which can produce documents in standard RFC format
from high-level markup?

These feature are required:

 - source format is human-readable ASCII (with embedded markup)
 - high-level, non-visual markup
 - libre conversion software to RFC format
 - automatic generation of cross references, bibliographical
   information, and table of contents

Wishlist items are:

 - conversion to nice-looking PDF 
 - conversion to HTML
 - conditional inclusion of pieces, depending on the output format
   (ASCII art for text version, bitmap for HTML etc.)

Whether the tool is based on SGML, XML, (La)TeX or *roff doesn't
really matter to me.

___
This message was passed through [EMAIL PROTECTED],
which is a sublist of [EMAIL PROTECTED] Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

Does anyone use message/external-body?

[Dan Kohn]

For the last several years, all I-Ds and RFCs publication announcements
have included message/external-body attachments to provide for automated
retrieval of the associated document.  This causes very little
distraction for those of us who prefer to use http or mailto URIs, while
providing useful functionality for those using the external-body MIME
type.

However, this raises a question: does *anyone* use external-body in
association with I-D announcements?  External-body was specified in RFC
1341 in 1992, 2.5 years before URIs were first specified in RFC 1738.  I
suspect that the use of external-body has been almost wholly, if not
completely, supplanted.  Of MUAs, I think that at least mh supports the
functionality, but is anyone using it?

And so I'd ask, should this

Content-Type: Message/External-body;
access-type="mail-server";
  server="[EMAIL PROTECTED]"

Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>

ENCODING mime
FILE /internet-drafts/draft-ietf-manet-lanmar-05.txt

Be replaced with:

<mailto:mailserv@;ietf.org&body=FILE%20/internet-drafts/draft-ietf-manet-
lanmar-05.txt>

(in addition to the http URI, which is what I believe we all use
anyway).  If there are actually people using the functionality (and who
wouldn't be just as happy with a mailto URI), than I would stick with
it, as it is a minimal distraction for the rest of us.  But if it's no
longer being used, I don't think the ietf-announce list needs to be the
only one using external-body, just because it was invented here.

  - dan
--
Dan Kohn <mailto:dan@;dankohn.com>
<http://www.dankohn.com/>

  Randomly generated quote:
Information is the currency of democracy.  - Thomas Jefferson

RE: Introducing the ID tracker

[Dan Kohn]

Until they add this functionality, you might try
<http://changedetection.com/detect.html>.  No, I'm not affiliated in any
way.

  - dan
--
Dan Kohn <mailto:dan@;dankohn.com>
<http://www.dankohn.com/>

  Randomly generated quote:
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!  - John
Perry Barlow


-Original Message-
From: Robert Elz [mailto:kre@;munnari.OZ.AU] 
Sent: Wednesday, November 06, 2002 02:38
To: Harald Tveit Alvestrand
Cc: [EMAIL PROTECTED]
Subject: Re: Introducing the ID tracker 


Date:Mon, 04 Nov 2002 16:44:11 -0500
From:Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Message-ID:  <[EMAIL PROTECTED]>

  | For the last year or so, the secretariat has been working on a tool
to help 
  | us keep track of what documents are on our plate, what state they
are in 
  | and who is responsible for them; we call it the "ID tracker".

  | The tool and its documentation is found at
  | 
  | https://datatracker.ietf.org/public/pidtracker.cgi

This looks fairly nice.   I'd like to see a bit more informative
information
in the "details" but this stuff is much better than existed before.

(Meaningless query: Is there a reason for https:// when nothing there
looks
to actually be secured?)

And a request - could the system be extended, sometime, so that it could
send e-mail to the working group, where there is one, or the (first)
author
in other cases, when a doc changes state?

That would avoid the need for continually polling the web page every day
to find out if anything has happened.

kre

-
This message was passed through [EMAIL PROTECTED],
which
is a sublist of [EMAIL PROTECTED] Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

RE: which standard?

[Dan Kohn]

More generally, see <http://www.normos.org/ietf/rfc/rfc2026.txt> to
understand the standards process.

  - dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com/>  

-Original Message-
From: Pawlukiewicz Jane [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, July 18, 2002 06:36
To: Dan Kohn
Cc: ietf
Subject: Re: which standard?


Hi Dan,

Thanks for clearing that up. I did see in RFC 2965 that it states it
obsoletes 2109, however I was confused as RFC 2965 is listed as a
_proposed_ standard.  

Thanks to you now I know RFC 2965 is currently in effect.

Thanks,

Jane

Dan Kohn wrote:
> 
> <http://www.normos.org/en/summaries/ietf/rfc/rfc2109.html> shows that
> RFC 2109 is obsoleted by RFC 2965.  RFC 2965 also mentions this in the
> third line of the document.
> 
> The canonical source of information on what obsoletes and is updated
by
> what is the RFC Editor's website:
> <http://www.rfc-editor.org/rfc-index2.html>
> 
>   - dan
> --
> Dan Kohn <mailto:[EMAIL PROTECTED]>
> <http://www.dankohn.com/>  
> Essays announced on <mailto:[EMAIL PROTECTED]>
> 
> 
> -Original Message-
> From: Pawlukiewicz Jane [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 17, 2002 12:44
> To: ietf
> Subject: which standard?
> 
> Hi,
> 
> I'm interested in reading up on cookies. Is RFC 2109 or RFC 2965
> currently in effect?
> 
> Thanks for any help,
> 
> Jane
> 
> -
> This message was passed through [EMAIL PROTECTED],
> which
> is a sublist of [EMAIL PROTECTED] Not all messages are passed.
> Decisions on what to pass are made solely by Raffaele D'Albenzio.

RE: which standard?

[Dan Kohn]

<http://www.normos.org/en/summaries/ietf/rfc/rfc2109.html> shows that
RFC 2109 is obsoleted by RFC 2965.  RFC 2965 also mentions this in the
third line of the document.

The canonical source of information on what obsoletes and is updated by
what is the RFC Editor's website:
<http://www.rfc-editor.org/rfc-index2.html>

      - dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com/>  
Essays announced on <mailto:[EMAIL PROTECTED]> 
 

-Original Message-
From: Pawlukiewicz Jane [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, July 17, 2002 12:44
To: ietf
Subject: which standard?


Hi,

I'm interested in reading up on cookies. Is RFC 2109 or RFC 2965
currently in effect?

Thanks for any help,

Jane

-
This message was passed through [EMAIL PROTECTED],
which
is a sublist of [EMAIL PROTECTED] Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

RE: [idn] Re: 7 bits forever!

[Dan Kohn]

I believe that Einar could be most easily satisfied with something along
the lines of a UTF8HEADERS ESMTP extension, which would specify both
that 8 bit character are permitted in the header and that those
characters MUST be interpreted as UTF-8.  It would be expected that this
extension would normally be used in conjunction with 8BITMIME [1] or
BINARYMIME [2].  The challenge is that any mail relay implementing this
extension MUST be able to downconvert headers to 7-bit RFC 2047 [3]
compliant encoded words if the next hop does not support UTF8HEADERS.

This would seem to be a middle ground between Dan's desire for
just-send-8 and other's demand that existing RFC 2821 [4] compliant
relays not be broken by adding support for UTF-8 headers.

This should be an easy RFC to write up.  If there is interest from
implementers, I would be happy to do so.  In any event, I would suggest
taking follow-up to ietf-smtp [5].

[1] http://www.ietf.org/rfc/rfc1652.txt
[2] http://www.ietf.org/rfc/rfc3030.txt
[3] http://www.ietf.org/rfc/rfc2047.txt
[4] http://www.ietf.org/rfc/rfc2821.txt
[5] http://www.imc.org/ietf-smtp/

  - dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com/>  
Essays announced on <mailto:[EMAIL PROTECTED]>


-Original Message-
From: Einar Stefferud [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 01, 2002 11:47
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [idn] Re: 7 bits forever!


Hi John -- My thesis is that the problem lies now in the SMTP
standards, where the current "Send 8-bits" problem has always
resided.  The MIME working group could not solve that problem, and so
did not, but it made mail work since its deployment, which was the
objective in the MIME WG.  inside the RFC822 Body there is only one
way to handle 8-bit data, and that is to tag it, and bag it.  Even if
you can transmit 8-bit data without encoding it in the body of an
SMTP message, it needs to be tagged and delimited in the body.

MIME Quoted-Printable was designed to be a work-around-damage
solution at the time, and was not design to remove the need for
handling 8-bit data in SMTP.

So, my only point is that it appears that some work needs to be done
in the SMTP standards, and beating up on the MIME WG does not compute
given this observation.

That is all...  Just trying to shift the focus of this thread to
where someone might think of a way to solve the current problem.

In the meantime, Thankfully, Mail still works, which was the MIME
objective for Quoted-Printable.

Cheers;-)\Stef


At 12:41 PM -0500 4/1/02, John C Klensin wrote:
>Stef,
>
>Either I misunderstand your message, or we have a bit of a
>disconnect.
>
>The SMTP extension "8BITMIME" was specified fairly early in the
>game.  My impression is that it is fairly widely deployed and
>used, possibly to the extent that most non-ASCII traffic is
>moving that way; someone on this list (or the SMTP extensions
>one) may have some numbers.  Where it is deployed, MIME is still
>required to label ("tag") the data -- one can still not tell one
>sort of 8bit character from another, and there is, I think,
>still much more traffic on the network in ISO 8859-N variants,
>or IS 2022-based systems, or local character sets than there is
>UTF-8 encoding of Unicode -- but quoted-printable (or base64)
>are not, unless the mail store or mail retrieval implementation
>cannot deal with 8bit materials.
>
>   john
>
>
>--On Monday, 01 April, 2002 08:59 -0800 Einar Stefferud
><[EMAIL PROTECTED]> wrote:
>
>  > Not to pick on Dan's particular message.
>  > It was just the last one to provide me with a handy response
>  > point.
>  >
>  > Looking back, the original 1990-1991 argument was between
>  > "Just send 8 bits" with no tagging of the content, vs "tagging
>  > and bagging" to deal with the fact that 8-bit at that time
>  > would break too many systems, and the problem of needing to
>  > tag the types of text characters that were contained in RFC822
>  > message bodies.
>  >
>  > But, as there were two problems to solve (8 bit SMTP ) and
>  > (tagging RFC822 content), the decision was made (after a very
>  > long and very heated argument) to split that problem according
>  > to the boundaries of SMTP and RFC822.
>  >
>  > In fact, the two problems were and still are totally distinct.
>  >
>  > The RFC822 solution group produced MIME with Quoted-Printable
>  > as its charter specified, to assure interworkability as soon
>  > as possible.
>  >
>  > The 8-bit folks did not do anything then or since to require
>  > 8-bit carriage.
>  >
>  > So, it is time for a working group to solve this problem.
>  >
>  > It is not going to

FW: I-D ACTION:draft-ietf-impp-datetime-01.txt

[Dan Kohn]

<http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-01.txt>
says that 

   The grammar element time-second may have the value "60" at the end of
   June (-06-30T23:59:60Z) or December (-12-31T23:59:60Z) if
   there is a leap second at that time (see Appendix D for a table of
   leap seconds).  At all other times the maximum value of time-second
   is "59".  

But, <http://tycho.usno.navy.mil/leapsec.html> states that:

The decision to introduce a leap second in UTC is the responsibility of
the International Earth Rotation Service (IERS). According to the CCIR
Recommendation, first preference is given to the opportunities at the
end of December and June, and second preference to those at the end of
March and September. 

Note that there has not yet been a March or September leap second, but
who knows what the future will bring?  Otherwise, the draft looks great.

    - dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com/>  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of [EMAIL PROTECTED]
Sent: Friday, 2001-05-11 04:13
To: IETF-Announce:; IETF-Announce:; @loki.ietf.org
Cc: [EMAIL PROTECTED]
Subject: I-D ACTION:draft-ietf-impp-datetime-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Instant Messaging and
Presence Protocol Working Group of the IETF.

Title   : Date and Time on the Internet: Timestamps
Author(s)   : G. Klyne, C. Newman
Filename: draft-ietf-impp-datetime-01.txt
Pages   : 16
Date: 10-May-01

This document defines a date and time format for use in Internet
protocols that is a profile of the ISO 8601 [ISO8601] standard for
representation of dates and times using the Gregorian calendar.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-impp-datetime-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-ietf-impp-datetime-01.txt".

NOTE:   The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail
readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

RE: spam

[Dan Kohn]

It troubles all of us a lot as well.

Typing spam into a search engine such as Google
<http://www.google.com/search?q=spam&num=30&sa=Google+Search> brings up
<http://www.spam.abuse.net/>, which is a good place to start your inquiry.

        - dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com>  

-Original Message-
From: 00 [mailto:[EMAIL PROTECTED]]
Sent: Monday, 2000-10-30 16:43
To: ietf
Subject: spam


I want to know something against spam ,it troubles me much.thanks!

RE: Last Call: Tags for the Identification of Languages to BCP

[Dan Kohn]

As you can see from Appendix B, all of the changes are backward compatible,
and so you would treat all references to RFC 1766 as referencing the new
specification instead.

This is the normal way standards progress through maturity, as otherwise
issuing any new RFC would require dozens or hundreds of other RFCs to be
simultaneously reissued.

- dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com>  

-Original Message-
From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED]]
Sent: Friday, 2000-10-20 08:46
To: [EMAIL PROTECTED]
Subject: Re: Last Call: Tags for the Identification of Languages to BCP


At 10:23 AM 10/20/00 -0400, The IESG wrote:
>The IESG has received a request to consider Tags for the Identification
>of Languages  as a BCP.  This has
>been reviewed in the IETF but is not the product of an IETF Working
>Group.
>
>This document will obsolete RFC1766, currently a Proposed Standard.

If RFC 1766 is obsoleted, wouldn't any Proposed Standard which has
a normative reference to RFC 1766 also be obsolete?

This would include RFC 2596 (Use of Language Codes in LDAP) and
likely others.  Has anyone a complete list of Standard Track RFC
which have normative references to 1766?   I believe that such
is needed to judge the impact of the proposal.

>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by November 20, 2000.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-alvestrand-lang-tag-v2-05.txt

RE: draft-kohn-assigned-numbers-00.txt

[Dan Kohn]

First, a disclaimer.  This I-D was just published to suggest one way to deal
with the assigned number series in the future.  The actual decision is the
province of IANA and the IESG.  I was informed by IANA that they are
currently revising RFC 1700, but I don't know what form they're planning to
use.

The specific inspiration for this draft was the following line from RFC
2929, which seems much better than referencing an assigned numbers RFC that
is nearly guaranteed to be out of date on publication: "IANA currently
maintains a web page of DNS parameters.  See
<http://www.iana.org/numbers.htm>."

As to your comment, filling in the references column on
<http://www.isi.edu/in-notes/iana/assignments/port-numbers> would be a
useful exercise that I expect IANA would be willing to accept help on, but
it does seem a lower priority than setting up new namespaces.

I don't think I understand why one would need a special search engine.  For
what it's worth, searching Google for IANA TCP brings up the port
assignments <http://www.google.com/search?q=iana+tcp>.

In any event, I believe a static RFC snapshot of assigned numbers such as
RFC 1700 has the same limitations as <http://www.iana.org/numbers.html>,
with the additional downside that it is nearly guaranteed to be out of date.

- dan
--
Dan Kohn <mailto:[EMAIL PROTECTED]>
<http://www.dankohn.com>  

-Original Message-
From: Mr. James W. Laferriere [mailto:[EMAIL PROTECTED]]
Sent: Monday, 2000-09-25 13:04
To: ietf maillist
Subject: Re: draft-kohn-assigned-numbers-00.txt



Hello All ,  Has everyone seen this & not wondered where the 
search engine is ?  I also see a lack of port# -> draft/rfc
capabilities .  I hope people other than myself find this
archive of limited use ?  Tia ,  JimL

On Mon, 25 Sep 2000 [EMAIL PROTECTED] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> 
> 
>   Title   : Assigned Numbers
>   Author(s)   : D. Kohn
>   Filename: draft-kohn-assigned-numbers-00.txt
>   Pages   : 6
>   Date: 22-Sep-00
>   
> This document replaces the static snapsnot of current assigned
> numbers used in previous documents with a link to
> <http://www.iana.org/numbers.html>.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kohn-assigned-numbers-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>   "get draft-kohn-assigned-numbers-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>   [EMAIL PROTECTED]
> In the body type:
>   "FILE /internet-drafts/draft-kohn-assigned-numbers-00.txt".
>   
> NOTE: The mail server at ietf.org can return the document in
>   MIME-encoded form by using the "mpack" utility.  To use this
>   feature, insert the command "ENCODING mime" before the "FILE"
>   command.  To decode the response(s), you will need "munpack" or
>   a MIME-compliant mail reader.  Different MIME-compliant mail readers
>   exhibit different behavior, especially when dealing with
>   "multipart" MIME messages (i.e. documents which have been split
>   up into multiple messages), so check your local documentation on
>   how to manipulate these messages.
>   
>   
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

RE: Bluetooth

[Dan Kohn]

I will bite regarding one issue near and dear to IETF hearts -- which is the
seeming need to buy yet another 802.11 card for each IETF meeting.  And yes,
I am actually suggesting an approach that would require one more purchase:

I was at Bluetooth Congress in Europe this month (which sounds better than
saying the Bluetooth Congress in Monte Carlo), and Bluetooth products are
definitely gathering momentum.  I expect the Ericsson wireless headset
shipping Q3 to be a killer product over the next 2 years, as people get
tired of dangling wires from headset cords and (for safety reasons) would
rather have a 1 milliwatt Bluetooth transceiver next to their head than a
300 milliwatt cellphone.

The remaining standards battle I see (now that HomeRF has been largely
killed off by Bluetooth FUD), is to settle once and for all that 802.11
should win as the wireless LAN technology of choice and that Bluetooth is
the only feasible wireless cable replacement technology that can actually
get into cellphones and other cheap digital devices.  Since the most
important attribute for 802.11 is bandwidth (its competition is 100BaseT),
while the most important attribute for Bluetooth is a $5 chip price, the
most likely outcome is for 802.11 to move up to the 5 GHz ISM band where it
can provide 54 Mbps (and up), significantly faster than the 11 Mbps
theoretically available today at 2.4 GHz, while offering the same ~$100
price point and propagation characteristics.

This would then leave the 2.4 GHz band for Bluetooth, and allow both
Bluetooth and 802.11 to be simultaneously active from the same laptop.  I
think most LANs will be wireless in a couple years simply for the
convenience of avoiding cabling (even for desktop computers), and that
people will want to sync up with their Palm Pilots and their cellphones
without having to disconnect from the network, which is the scenario today.
However, dual simultaneous use will work perfectly with Bluetooth at 2.4 GHz
and 802.11 at 5 GHz.

- dan
--
Daniel Kohn 
 Both US  and UK 
 numbers forward to the same automated operator to reach me.


-Original Message-
From: Parkinson, Jonathan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 2000-06-28 07:17
To: [EMAIL PROTECTED]
Subject: Bluetooth


Hi folks 
Anyone care to start a discussion about Bluetooth and how it
may/will impact the future of communications ? And the new generation of
Virus's that could come along with this technology.


Thanks
Jon


> Jonathan Parkinson
> EMEA Operations Management Center.
> Remote Server and Network Management Group.
> Unix Support .
> Compaq Computer Limited 
> 
> Tel: DTN 7830 1118
> Tel: External +44 (0)118 201118
> Fax: +44 (0)118 201175
> [EMAIL PROTECTED]
> 

RE: WAP and IP

[Dan Kohn]

As for cellular expertise, see
 and in particular
.

- dan
--
Daniel Kohn 
tel:+1-425-602-6222
http://www.dankohn.com

-Original Message-
From: Lloyd Wood [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 2000-06-27 04:05
To: Brijesh Kumar
Cc: 'Vernon Schryver'; [EMAIL PROTECTED]
Subject: RE: WAP and IP


On Mon, 26 Jun 2000, Brijesh Kumar wrote:

> Mohsen may be accused of any thing, but calling Mohsen whose aim is to
> create an open alternative to WAP is hilarious. And, Mohsen at least
> understands the issues involved in wireless cellular communication,
> something that can be said of many other TCP/IP for every thing
> advocates.

I don't think that paragraph says anything remotely near what you
wanted it to say.

You'd be more convincing if you said less.

L.

<[EMAIL PROTECTED]>PGP

RE: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)

[Dan Kohn]

I certainly hope you're joking.

If not, I can say definitively that this is certainly not Teledesic's view
of the world.  Teledesic (and it's sister network ICO) are being designed to
be great platforms for carrying IP.  (That means they will also be able to
do WAP, but that is hardly the focus.)

http://www.teledesic.com
http://www.ico.com

- dan
--
Daniel Kohn 
tel:+1-425-602-6222
http://www.dankohn.com

-Original Message-
From: Taylor, Johnny [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 2000-06-21 08:48
To: Donald E. Eastlake 3rd; [EMAIL PROTECTED]
Subject: RE: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)


All,

I have seen a lot of different people bash WAP over the past two days.
However, I
am a firm believer that WAP will become what IP is to us today. When you
relate the 
technologies of today and the future technologies from a Telecommunication
stand point.
Then you will find IP is on the rise today and various Platforms are
integrating or
converging IP to their core networks. But when you equate the moves that are
taking
place for future solutions to the commercial or residential market. such as
The Teledesic 
Model or AOL or Manasamen; then you began to get a glimpse 
of the future of WAP. Therefore I think it becomes quite important for this
group to 
keep WAP as one of the main protocols of discussion / solutions. That's my
take on WAP!

Coming from the Brain!

JT 


-Original Message-
From: Donald E. Eastlake 3rd [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 21, 2000 7:31 AM
To: [EMAIL PROTECTED]
Subject: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)


See .

Donald

From:  Magnus Danielson <[EMAIL PROTECTED]>
To:  [EMAIL PROTECTED]
Cc:  [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
In-Reply-To:  <[EMAIL PROTECTED]>
References:  <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-Id:  <[EMAIL PROTECTED]>
Date:  Wed, 21 Jun 2000 10:40:40 +0200

>From: Masataka Ohta <[EMAIL PROTECTED]>
>Subject: Re: WAP Is A Trap -- Reject WAP
>Date: Wed, 21 Jun 0 5:42:32 JST
>
>> Phil;
>> 
>> > >IP over NAT is, in no way, end-to-end.
>> > 
>> > >WAP and IP over NAT are equally bad.
>> > 
>> > I think you're overstating your case. Yes, IP over NAT is bad, but
>> > it's nowhere near as bad as WAP.
>> 
>> If you think so, don't say "end-to-end".
>> 
>> > If you want, it is still possible to "reconstruct" a true end-to-end
>> > IP service by tunneling it through a NAT with something vaguely
>> > resembling mobile IP.
>> 
>> You can have IP over HTTP, IP over XML or IP over WAP equally easily.
>
>With IP over MIME you could even establish an IP connection over a mail
>gateway, firewall bypassing... Hmm the same goes for http proxies.
>
>> The problem, however, is that the reconstruction point is an
>> intelligent gateway which violates the end to end principle.
>
>Havent we learned to love and hate these breaking of layering?
>
>You can put basically anything over anything else when it comes to just
moving
>bits around. While doing this we get the additional benefits of increased
>propagation delay, increased overhead, often complexer solutions and a new
>bag of problems in the interworking area. Lovely. We can feed a lot of
>research and engineer mouths this way.
>
>Now, while NAT and WAP both intend to solve some problems, they provide
ground
>for new problems which naturally require new solutions. We should really
ask
>weither some of these problems really should be solved within that scope or
>not. If IP over WAP is a bag of worms, maybe one should bypass WAP
alltogether.
>Where we know that neither ATM, IP or NAT solves all the problems neither
will
>WAP.
>
>It is not really what you could do as what you should do. Naturally there
is
>allways politically and technical preferences which prohibits some
solutions.
>
>Cheers,
>Magnus
>

RE: fyi.. House Committee Passes Bill Limiting Spam E-Mail

[Dan Kohn]

Furthermore, CAUCE, which is a widely respected anti-spam organization,
"vigorously supports" HR 3113 according to
.

Although I might prefer for spam to just be outlawed, I am certainly willing
to go to an FCC website to remove my email addresses, and I do not consider
the 30 day waiting period that onerous.

But why not make up your own mind.  The bill is at
.

- dan
--
Daniel Kohn 
tel:+1-425-602-6222
http://www.dankohn.com

-Original Message-
From: Doug Isenberg [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 2000-06-15 16:04
To: '[EMAIL PROTECTED]'
Subject: Re: fyi.. House Committee Passes Bill Limiting Spam E-Mail 


At 04:37 PM 6/15/00, Keith Moore wrote:
>yeah, the bill contains language like
>
>"Unsolicited commercial electronic mail can be an important mechanism
>through which businesses advertise and attract customers in the online
>environment."
>
>this bill isn't designed to limit spam; it's designed to make it legal.

 In the interest of providing both sides of the story, it should be 
noted that the bill also contains language like:

 "The receipt of unsolicited commercial electronic mail may result 
in costs to recipients who cannot refuse to accept such mail and who incur 
costs for the storage of such mail, or for the time spent accessing, 
reviewing, and discarding such mail, or for both."

and

 "Unsolicited commercial electronic mail may impose significant 
monetary costs on interactive computer services, businesses, and 
educational and nonprofit institutions that carry and receive such mail, as 
there is a finite volume of mail that such providers, businesses, and 
institutions can handle without further investment. The sending of such 
mail is increasingly and negatively affecting the quality of service 
provided to customers of interactive computer service, and shifting costs 
from the sender of the advertisement to the interactive computer service."

 I've yet to read the whole bill (H.R. 3113), but I suspect (or, at 
least, hope) that the politicians behind this legislation are intending to 
draft a federal law that, unlike at least two state attempts, will survive 
a constitutional challenge.

===
Douglas M. Isenberg
Attorney @ Law
Editor & Publisher, GigaLaw.com
===
GigaLaw.com: "Legal Information for
Internet and Technology Professionals"
http://www.GigaLaw.com
===

RE: How to unsubscribe from the IETF@ietf.org Mailing list.

[Dan Kohn]

Several months ago there was a request of Steve Coya on the list to
implement a simple filter in the IETF's majordomo implementation that
sidelines all messages that begin with "unsubscribe CRLF" (and preferably
"unsuscribe", etc.).  I understand this is very easy to do in majordomo and
that we have numerous majordomo experts on the list who would be happy to
help out.

I know that Steve is a busy man, but would it be possible to implement this
soon?

- dan
--
Daniel Kohn 
tel:+1-425-519-7968  fax:+1-425-602-6223
http://www.dankohn.com

RE: WAP

[Dan Kohn]

I believe the nearly identical paper is available at
.

And, a 35-page detailed version is available at
.

- dan
--
Daniel Kohn 
tel:+1-425-519-7968  fax:+1-425-602-6223
http://www.dankohn.com


-Original Message-
From: Henning Schulzrinne [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 1999-12-15 06:00
To: Jon Crowcroft
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: WAP




> and nearly as many clues as wires
> 

which
http://www.computer.org/internet/ic1999/w4089abs.htm
elaborates on.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

RE: To address or NAT to address?

[Dan Kohn]

>>It seems to me that we may be able to recapture some aspects of end-to-end
>>transparency at the application level if addressing issues are focused on
>>host FQDNs, rather than IP addresses.

>this works to some extent.  it specifically doesn't work for applications
>that need to rendezvous with specific processes on specific hosts
>(or which need to use specific interface addresses, say for performance
>reasons), since a single FQDN often corresponds to multiple hosts.
>(or, less frequently, to multiple addresses on a single host).

Specific processes can be and almost always are identified by a port number.
Just as TCP connections are identified as a 4-tuple of sender and receiver
IP address and port number, an application layer session would be identified
by a 4-tuple of sender and receiver FQDN and port.

Each interface has a different IP number, does it not?  So each can have
it's own FQDN if they need to be distinguished.  

>note also that DNS is often slow, and seems less reliable than IP.
>by increasing the reliance on DNS you increase the probability of failure. 

Yes, so DNS can occasionally fail.  But embedding addresses as a name in a
protocol is guaranteed to fail in increasingly common situations.

Finally, some have argued that DNS is less secure, but it seems that IP
numbers can be spoofed as easily as FQDNs, and an FQDN can always be
double-checked with a DNSSEC lookup if critical.

- dan

P.S.  And now I'll embarrass myself with a silly idea.  Could one create an
automatic tunneling mode to securely send encrypted IPsec streams through a
NAT by adding an IP option which also identifies the FQDN of the destination
host?  That is, the IP address would get the packet to the NAT, and the NAT
would use the embedded FQDN to forward the packet to the correct destination
host, using IP in IP encapsulation.  The destination host would need to have
knowledge of its external address, but the NAT would not need access to the
destination host's encryption keys and so security would not be compromised.

--
Daniel Kohn 
tel:+1-425-519-7968  fax:+1-425-602-6223
http://www.dankohn.com