[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Received: from ietf.org by ietf.org id aa17199; 21 Apr 97 12:55 EDT
Received: from dell05.cnri.reston.va.us by ietf.org id aa17048;
21 Apr 97 12:52 EDT
Message-Id: <2.2.32.19970422164755.006e52d8 at ietf.org>
X-Sender: mbeaulie at ietf.org
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 22 Apr 1997 12:47:55 -0400
To: Steve Deering <deering at cisco.com>
Sender:ietf-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Subject: Hotel space in Munich - Update
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Just a quick update on the hotels for Munich.
I am working out details with other hotels in Munich to use as
overflows. As soon as we have signed agreements, I will send
out that information.
You may wish to check back with the Sheraton; historically our
room block gets full then the cancellation start coming in and
rooms become available again.
Marcia
IETF Meeting Coordinator
Received: from ietf.org by ietf.org id aa19107; 21 Apr 97 13:24 EDT
Received: from paris.ics.uci.edu by ietf.org id aa18990; 21 Apr 97 13:21 EDT
Received: from nma.com by paris.ics.uci.edu id aa16333; 21 Apr 97 10:08 PDT
Received: from paris.ics.uci.edu by norn.nma.com id aa09922; 21 Apr 97 9:57 PDT
To: ietf at ietf.org
Subject: Re: Hotel space in Munich
In-reply-to: Your message of "Mon, 21 Apr 1997 09:16:35 PDT."
<v03020902af8140e5a122 at [171.69.116.90]>
Reply-to: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Einar Stefferud <Stef at nma.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9918.861641851.1 at nma.com>
Date: Mon, 21 Apr 1997 09:57:32 -0700
Message-ID: <9920.861641852 at nma.com>
X-Orig-Sender: stef at nma.com
Source-Info: From (or Sender) name not authenticated.
}
}I wonder how long it will be before
}we read of a phone system meltdown triggered by an IETF At-A-Glance posting?
}
I hope that the IETF Secretariat will resume mailing those "IETF
MAILING" messages that they used to post on the IETF Announce List.
It is a real problem having to always go out on the net to get
information that can much more easily be received directly by EMail,
especially when one is never sure when new information is posted.
Best...\Stef
Received: from ietf.org by ietf.org id aa19836; 21 Apr 97 13:38 EDT
Received: from doggate.microsoft.com by ietf.org id aa19714; 21 Apr 97 13:35 EDT
Received: by DOGGATE with Internet Mail Service (5.0.1457.3)
id <292A1MWH>; Mon, 21 Apr 1997 10:31:56 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001048F63A9 at DINO>
Sender:ietf-request at ietf.org
From: Alec Dun <AlecDu at exchange.microsoft.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: Hotel space in Munich
Date: Mon, 21 Apr 1997 10:32:03 -0700
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1457.3)
Content-Type: text/plain;
charset="iso-8859-1"
Source-Info: From (or Sender) name not authenticated.
Stef, do you know where the "announce archives" are? I've been looking
for them, but can't find them.
Thanks,
Alec.
-----Original Message-----
From: Einar Stefferud [SMTP:Stef at nma.com]
Sent: Monday, April 21, 1997 9:58 AM
To: ietf at ietf.org
Subject: Re: Hotel space in Munich
}
}I wonder how long it will be before
}we read of a phone system meltdown triggered by an IETF
At-A-Glance posting?
}
I hope that the IETF Secretariat will resume mailing those "IETF
MAILING" messages that they used to post on the IETF Announce
List.
It is a real problem having to always go out on the net to get
information that can much more easily be received directly by
EMail,
especially when one is never sure when new information is
posted.
Best...\Stef
Received: from cnri by ietf.org id aa20841; 21 Apr 97 13:53 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11876;
21 Apr 97 13:53 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <QAA22503 at pad-thai.cam.ov.com>; Mon, 21 Apr 1997 16:18:28 GMT
Message-Id: <3.0.32.19970421092132.0096ad00 at pop-srvr.cybersafe.com>
X-Sender: matth at pop-srvr.cybersafe.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 21 Apr 1997 09:21:32 -0700
To: cat-ietf at mit.edu
From: Matt Hur <matt.hur at cybersafe.com>
Subject: Re: Recommended enhancement to PK-CROSS
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
If we agree that we wish to provide for specification of lifetime policy
then I have the following comments:
1) The PKCrossOutput sequence should specify the expiration time (not
lifetime) of encSharedKey (the RemoteReply would indicate duration, not
expiration). The expiration time could be included as part of the
encSharedKey (which would then have to become a separate sequence). It
would make sense to create a temporary key for encrypting this sequence.
There is also the issue of if we want to encrypt the desired lifetime in
the RemoteReply. This would be a problem, in that we had wished to NOT
perform any PK encryption in this message.
2) We should not specify an ACK from the remote KDC. We should not require
the KDC to maintain state for this.
3) There is an issue of how the lifetime of the shared secret is
negotiated. One option would be to allow the remote KDC to determine the
lifetime. I believe that this issue requires more discussion.
--Matt
At 02:12 PM 4/18/97 -0400, Tony Mione wrote:
>
> After some off-line discussions with Brian Tung, I have a
>recommendation for handling expiration of symmetric keys
>generated for cross-realm authentication. Please pardon any ASN.1 errors or
>hand-waving as I am partially ASN.1-challenged.
>
> Essentially, the differences simply involve sending a lifetime
>(in seconds) along with the random symmetric key. When cross-realm
>authentication is requested of the local kdc, it checks its out bound cache
>for a profile. If the profile is present for the remote realm, it checks
>the expiration time in the profile. If the key is expired, it follows the
>standard pk authentication as described in your document to acquire a new
>symmetric key. Otherwise, it uses the symmetric key from the existing
profile.
>
> The changes to the structures in the existing PK-CROSS document are
>as follows:
>
> 1) add a lifetime (in seconds) to the RemoteReply structure and
> the PKCrossOutput structure.
>
>
> PKCrossOutput ::= SEQUENCE {
> certificate [0] OCTET STRING OPTIONAL,
> -- public key certificate
> -- of local KDC
> encSharedKey [1] EncryptedData,
> -- of type EncryptionKey
> -- containing random symmetric key
> -- encrypted using public key
> -- of remote KDC
> sharedKeyLifetime [2] INTEGER,
> -- Local KDC's preferred
> -- lifetime of EncryptionKey
> -- in seconds
> sigSharedKey [3] Signature,
> -- of encSharedKey
> -- using signature key
> -- of local KDC
> pkEncData [4] EncryptedData,
> -- (normally) of type EncTktPart
> -- encrypted using encryption key
> -- found in encSharedKey
> }
>
> RemoteReply ::= [APPLICATION 42] SEQUENCE {
> trustedCertifiers [0] SEQUENCE OF PrincipalName,
> certificates[1] SEQUENCE OF Certificate,
> encTypeToUse [2] SEQUENCE OF INTEGER,
> -- encryption types usable
> -- for encrypting pkEncData
> sharedKeyLifetime [3] INTEGER
> -- Remote KDC's preferred key
> -- lifetime (in seconds)
> }
>
>
> Additionally, to be sure that the remote KDC has received the
>PKCrossOutput message (in case the local KDC desires a shorter expiration
>time than the remote KDC), have the remote KDC send a PKCrossOutputAck
>message containing the minimum of the two lifetimes.
>
> PKCrossOutputAck ::= SEQUENCE {
> agreedSharedKeyLifetime [0] INTEGER
> -- Minimum of the kdc
> -- shared key lifetimes
> }
>
> This makes the entire interchange look like the following:
>
> [local Client] [local KDC] [Remote KDC]
>
> AS_REQ [RRealm] ----->
> RemoteRequest --------->
> (nonce)
> <--------------- RemoteReply
> (certs,CAs,lifetime1)
> PkCrossOutput --------->
> (certs,key,lifetime2)
> <--------------- PkCrossOutputAck
> (min(lifetime1,lifetime2))
>
> That's about it. I am interested in hearing comments or feedback
>on this suggestion.
>
>--
>Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ -
908-445-0650
>mione at nbcs-ns.rutgers.edu W3:
http://www-ns.rutgers.edu/~mione/
>PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F
>Editorial Advisor for Digital Systems Report ***** Important: John 17:3
*****
>
>
----------------------------------------------------------------
Matt Hur CyberSafe
matt.hur at cybersafe.com 1605 NW Sammamish Road, Suite 310
(206) 391-6000 Issaquah, WA 98027-5378
http://www.cybersafe.com
Received: from ietf.org by ietf.org id aa21165; 21 Apr 97 14:01 EDT
Received: from ietf.ietf.org by ietf.org id aa20997; 21 Apr 97 13:58 EDT
To: ietf at ietf.org
Subject: Re: Munich on Sunday
Sender:ietf-request at ietf.org
From: Bill Wohler <wohler at newt.com>
Date: Mon, 21 Apr 1997 13:58:06 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704211358.aa20997 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
randy at psg.com (Randy Bush) writes:
>> who cares about the rest of Germany,
>Since you asked, I do. Probably a few others too.
Randy,
As I recall, Himmelfahrt (Assumption) was also a holiday in Heidelberg
(Baden Wurtemburg).
Except for bars and restaurants, Germany shuts down nights and
weekends, especially Sundays (don't know about museums though,
although tourist attractions remain open). If you need a midnight
snack, you'll have to find a 24-hour gas station (tankstelle) or
autobahn tankstelle or train station (bahnhof).
Regarding hotels: the adventurous, if unsuccessful at finding room in
Muenchen, can take a train to a bordering town and can probably find a
Rasthaus with some cheap, comfortable rooms.
Raise a liter or two (or three) for me at the biergartens. Schneider
Weisse, yum! If any San Franciscans can bring back some Jever Pils
(from the north), I'll reward you suitably.
For those who are driving (and are familiar with my signature),
remember that there isn't any passing on the right and you MUST move
to the right after passing. Keep your eyes much further forward and
backward than you're accustomed to because of the increased speeds
(but you won't have to look over your shoulder at the on-ramps for
cops).
Viel spass! Enjoy!
--
Bill Wohler <wohler at newt.com> ph: +1-415-854-1857 fax: +1-415-854-3195
Say it with MIME. Maintainer of comp.mail.mh and news.software.nn FAQs.
If you're passed on the right, you're in the wrong lane.
Received: from ietf.org by ietf.org id aa23174; 21 Apr 97 14:35 EDT
Received: from zephyr.isi.edu by ietf.org id aa22927; 21 Apr 97 14:30 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA14234>; Mon, 21 Apr 1997 11:26:46 -0700
Message-Id: <199704211826.AA14234 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2130 on Character Set Workshop Report
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 21 Apr 97 11:26:45 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2130:
Title: The Report of the IAB Character Set Workshop
held 29 February - 1 March, 1996
Author: C. Weider, C. Preston, K. Simonsen, H. Alvestrand,
R. Atkinson, M. Crispin, P. Svanberg
Date: April 1997
Mailbox: cweider at microsoft.com, cecilia at well.com,
Keld at dkuug.dk, Harald.T.Alvestrand at uninett.no,
rja at cisco.com, mrc at cac.washington.edu,
psv at nada.kth.se
Pages: 31
Characters: 63443
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2130.txt
This report details the conclusions of an IAB-sponsored invitational
workshop held 29 February - 1 March, 1996, to discuss the use of
character sets on the Internet. It motivates the need to have
character set handling in Internet protocols which transmit text,
provides a conceptual framework for specifying character sets,
recommends the use of MIME tagging for transmitted text, recommends a
default character set *without* stating that there is no need for
other character sets, and makes a series of recommendations to the
IAB, IANA, and the IESG for furthering the integration of the
character set framework into text transmission protocols. This
document is the product of the Internet Architecture Board (IAB).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970421111317.RFC at ISI.EDU>
SEND /rfc/rfc2130.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2130.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970421111317.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23594; 21 Apr 97 14:40 EDT
Received: from zephyr.isi.edu by ietf.org id aa23407; 21 Apr 97 14:38 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA14752>; Mon, 21 Apr 1997 11:35:26 -0700
Message-Id: <199704211835.AA14752 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2129 on FANP Specification
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 21 Apr 97 11:35:24 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2129:
Title: Toshiba's Flow Attribute Notification Protocol
(FANP) Specification
Author: K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi,
S. Matsuzawa, T. Jinmei, H. Esaki
Date: April 1997
Mailbox: nagami at isl.rdc.toshiba.co.jp,
katsube at isl.rdc.toshiba.co.jp,
masahata at csl.rdc.toshiba.co.jp,
mogi at isl.rdc.toshiba.co.jp,
shigeom at isl.rdc.toshiba.co.jp,
jinmei at isl.rdc.toshiba.co.jp,
hiroshi at isl.rdc.toshiba.co.jp
Pages: 19
Characters: 41137
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2129.txt
This memo discusses Flow Attribute Notification Protocol (FANP),
which is a protocol between neighbor nodes for the management of
cut-through packet forwarding functionalities.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970421112746.RFC at ISI.EDU>
SEND /rfc/rfc2129.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2129.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970421112746.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24716; 21 Apr 97 14:56 EDT
Received: from zephyr.isi.edu by ietf.org id aa24504; 21 Apr 97 14:53 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA15538>; Mon, 21 Apr 1997 11:50:21 -0700
Message-Id: <199704211850.AA15538 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2133 on IPv6 Socket Interface Extensions
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 21 Apr 97 11:50:21 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2133:
Title: Basic Socket Interface Extensions for IPv6
Author: R. Gilligan, S. Thomson, J. Bound, W. Stevens
Date: April 1997
Mailbox: gilligan at freegate.net, set at thumper.bellcore.com,
bound at zk3.dec.com, rstevens at kohala.com
Pages: 32
Characters: 69737
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2133.txt
The de facto standard application program interface (API) for TCP/IP
applications is the "sockets" interface. But changes are required to
the sockets API to support IPv6 and this memo describes these changes.
These include a new socket address structure to carry IPv6 addresses,
new address conversion functions, and some new socket options. This
document is the product of the IPNG Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970421113616.RFC at ISI.EDU>
SEND /rfc/rfc2133.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2133.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970421113616.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27377; 21 Apr 97 15:40 EDT
Received: from zephyr.isi.edu by ietf.org id aa26948; 21 Apr 97 15:32 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA17861>; Mon, 21 Apr 1997 12:29:02 -0700
Message-Id: <199704211929.AA17861 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2136 on DNS Update
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 21 Apr 97 12:29:02 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2136:
Title: Dynamic Updates in the Domain Name System
(DNS UPDATE)
Author: P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound
Date: April 1997
Mailbox: paul at vix.com, set at thumper.bellcore.com,
yakov at cisco.com, bound at zk3.dec.com,
Pages: 26
Characters: 56354
Updates/Obsoletes: 1035
URL: ftp://ds.internic.net/rfc/rfc2136.txt
The Domain Name System was originally designed to support queries of a
statically configured database. While the data was expected to
change, the frequency of those changes was expected to be fairly low,
and all updates were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add
or delete RRs or RRsets from a specified zone. Prerequisites are
specified separately from update operations, and can specify a
dependency upon either the previous existence or nonexistence of an
RRset, or the existence of a single RR. This document is a product of
the DNS IXFR, Notification, and Dynamic Update Working Group of the
IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970421115556.RFC at ISI.EDU>
SEND /rfc/rfc2136.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2136.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970421115556.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27548; 21 Apr 97 15:43 EDT
Received: from zephyr.isi.edu by ietf.org id aa27392; 21 Apr 97 15:40 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA18211>; Mon, 21 Apr 1997 12:37:00 -0700
Message-Id: <199704211937.AA18211 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2137 on Secure DNS Dynamic Update
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 21 Apr 97 12:36:59 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2137:
Title: Secure Domain Name System Dynamic Update
Author: D. Eastlake 3rd
Date: April 1997
Mailbox: dee at cybercash.com
Pages: 11
Characters: 24824
Updates/Obsoletes: 1035
URL: ftp://ds.internic.net/rfc/rfc2137.txt
This memo describes how to use DNSSEC digital signatures covering
requests and data to secure updates and restrict updates to those
authorized to perform them as indicated by the updater's possession of
cryptographic keys. This document is the product of the Domain Name
System Security Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970421123126.RFC at ISI.EDU>
SEND /rfc/rfc2137.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2137.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970421123126.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15755; 21 Apr 97 23:50 EDT
Received: from seeker.ar.com by ietf.org id aa15319; 21 Apr 97 23:37 EDT
Received: (from wessorh at localhost) by seeker.ar.com. (8.8.2/8.8.2) id UAA12152; Mon, 21 Apr 1997 20:33:26 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "Rick H. Wesson" <wessorh at ar.com>
Message-Id: <9704212033.ZM12150 at seeker.ar.com.>
Date: Mon, 21 Apr 1997 20:33:25 -0700
X-Mailer: Z-Mail (3.2.1 10oct95)
To: ietf at ietf.org
Subject: Shared gTLD Repository (coredb) WG
Cc: wessorh at ar.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
A Proto-WG has been formed to deal with defining a protocol, and
a requirements document for a Shared gTLD Repository. This Repository
is refered to in the IAHC's Final Draft Report on creating additional
Top Level Domains and Registrars to manage said namespace(tm).
A moderately active (~15 messages per day) list is discussing
requirements for this system. If you wish to participate in the
discussion (and hopefully the working group) subscribe by sending the word
'subscribe' (with out the quotes) to ietf-coredb-request at imc.org
A Web page with subscription info is at: http://www.imc.org/ietf-coredb/
The charter is atached.
-Rick
Council of Registrars Database (coredb)
------------------------------------------------------------------------
Draft Charter
Current status: proto-WG
Chair(s):
Rick Wesson <rick at ar.com>
Operational Requirements Area Director(s):
John Curran <jcuran at bbn.com>
Michael O'Dell <mo at uunet.uu.net>
Mailing lists:
General Discussion: ietf-coredb at imc.org
To Subscribe: ietf-coredb-request at imc.org
with 'subscribe' in the body of your message.
Archive: http://www.imc.org/ietf-coredb/mail-archive/
Description of Working Group:
Enchancements to the gTLD DNS space will entail sharing a registration data
base (repository) among mutually suspicious registrars. For this operation to
succeed, a reliable and efficient method must be defined for achieving that
sharing. This Working Group will specify the functional requirements and
specify or select the protocol to be used for such a service.
There are three main participatnts in a shared gTLD repository: Applicants
(users), Registrars, and the Repository. The Registrars take applications from
end-users and submit create, modify, and delete requests to the central
repository. This Working Group will define a protocol for the interaction of
the Registrars and the central repository i.e., a shared database. This group
will also define a set of templates that the registrars will accept and the
maping of those templates into request the Repository will process.
This working group will focus on transitioning from the system implemented by
CORE to a robust open standard. The group will look at scaleing and security
issues, define a transition plan, define protocols for interaction between
system components, and define database objects. The group will work twards a
system that scales to 100's of millions of objects while not excludeing
implementstions from the use of distributed databases.
Security concerns will include authenticated and private exchanges
between registrars and the repository, and to migration of applicants'
entries between registrars in a manner that satisfies CORE policies, for
example preventing "theft" of accounts.
The working group will coordinate it's effort where necessary with other
working groups (in particular RIDE) for data formats that are
already defined or use the guidelines put forward by said groups.
Goals and Milestones.
Jun 97 Draft of requirements for shared repository
Aug 97 Draft of object formats
Draft of application templates.
Sept 97 Draft (or selection) of exchange protocol
Dec 97 Revisions to requirements, object and protocol
specifications
Apr 97 Specifications submitted to standards track
--
Rick H. Wesson
Received: from ietf.org by ietf.org id aa22091; 22 Apr 97 5:20 EDT
Received: from bells.cs.ucl.ac.uk by ietf.org id aa21967; 22 Apr 97 5:15 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.03139-0 at bells.cs.ucl.ac.uk>; Tue, 22 Apr 1997 08:35:11 +0100
To: Steve Deering <deering at cisco.com>
cc: ietf at ietf.org
Subject: Re: Hotel space in Munich
In-reply-to: Your message of "Mon, 21 Apr 1997 09:16:35 PDT." <v03020902af8140e5a122 at [171.69.116.90]>
Date: Tue, 22 Apr 1997 08:35:09 +0100
Message-ID: <771.861694509 at cs.ucl.ac.uk>
Sender:ietf-request at ietf.org
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Source-Info: From (or Sender) name not authenticated.
>FYI, the IETF block of rooms at the Sheriton Munich is already exhausted for
>Aug 13 and 14 -- I got put on a waiting list for those two days. That'll
>teach me to wait a whole 5 days after the hotel announcement message to make
>my reservation. This has become like one of those radio call-in contests:
>"The first 300 lucky callers will win a reservation at the World Famous
>Sheraton Hotel in Magnificent Munich!!" I wonder how long it will be before
>we read of a phone system meltdown triggered by an IETF At-A-Glance posting?
Steve
clearly any IERTF sponsor should make sure ALL the hotels in the
region are on the mbone the day before announcing an IETF location,
and set up a "Global IETF hotel trading floor" mbone session
then we can do a free market experiment including futures and so
on....
only problem is that we'd have to use PGP for any emoney
transactions, and that means the french might be excluded.......
(along with other nice places with crazy security laws, e.g. england
soon...:-)
cheers
jon
Received: from ietf.org by ietf.org id aa27243; 22 Apr 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa26584; 22 Apr 97 9:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: applmib at emi-summit.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-applmib-sysapplmib-08.txt
Date: Tue, 22 Apr 1997 09:39:35 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704220939.aa26584 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Application MIB Working
Group of the IETF.
Title : Definitions of System-Level Managed Objects for
Applications
Author(s) : C. Krupczak, J. Saperia
Filename : draft-ietf-applmib-sysapplmib-08.txt
Pages : 48
Date : 04/21/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes a basic set of managed objects for fault,
configuration and performance management of applications from a systems
perspective. More specifically, the managed objects are restricted to
information that can be determined from the system itself and which does
not require special instrumentation within the applications to make the
information available.
This memo does not specify a standard for the Internet community.
Internet-Drafts are 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-applmib-sysapplmib-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-applmib-sysapplmib-08.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-applmib-sysapplmib-08.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970421143427.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-applmib-sysapplmib-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-applmib-sysapplmib-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970421143427.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27251; 22 Apr 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa26495; 22 Apr 97 9:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-filter-01.txt
Date: Tue, 22 Apr 1997 09:39:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704220939.aa26495 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : The String Representation of LDAP Search Filters
Author(s) : T. Howes
Filename : draft-ietf-asid-ldapv3-filter-01.txt
Pages : 6
Date : 04/21/1997
The Lightweight Directory Access Protocol (LDAP) [1] defines a network
representation of a search filter transmitted to an LDAP server. Some
applications may find it useful to have a common way of representing these
search filters in a human-readable form. This document defines a
human-readable string format for representing LDAP search filters.
This document replaces RFC 1960, extending the string LDAP filter
definition to include support for LDAP version 3 extended match filters,
and including support for representing the full range of possible LDAP
search filters.
Internet-Drafts are 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-asid-ldapv3-filter-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-filter-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-filter-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970421141636.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-filter-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-filter-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970421141636.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27250; 22 Apr 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa26539; 22 Apr 97 9:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-url-01.txt
Date: Tue, 22 Apr 1997 09:39:32 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704220939.aa26539 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : The LDAP URL Format
Author(s) : T. Howes, M. Smith
Filename : draft-ietf-asid-ldapv3-url-01.txt
Pages : 4
Date : 04/21/1997
LDAP is the Lightweight Directory Access Protocol, defined in [1], [2]
and [3]. This document describes a format for an LDAP Uniform Resource
Locator. The format describes an LDAP search operation to perform to
retrieve information from an LDAP directory. This document replaces RFC
1959. It updates the LDAP URL format for version 3 of LDAP. This document
also defines a second URL scheme prefix for LDAP running over the TLS
protocol defined in [6].
Internet-Drafts are 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-asid-ldapv3-url-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-url-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-url-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970421142403.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-url-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-url-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970421142403.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27248; 22 Apr 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa26736; 22 Apr 97 9:40 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-ipv6router-alert-01.txt
Date: Tue, 22 Apr 1997 09:40:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704220940.aa26736 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IPNG Working Group of the
IETF.
Title : IPv6 Router Alert Option
Author(s) : D. Katz, R. Atkinson
Filename : draft-ietf-ipngwg-ipv6router-alert-01.txt
Pages : 4
Date : 04/21/1997
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit
routers to more closely examine the contents of an IP packet. This is
useful for protocols addressed to a destination but also require special
processing in routers along the path.
Internet-Drafts are 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-ipngwg-ipv6router-alert-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6router-alert-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970421173511.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6router-alert-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970421173511.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27249; 22 Apr 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa26641; 22 Apr 97 9:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-clark-telnet-control-02.txt
Date: Tue, 22 Apr 1997 09:39:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704220939.aa26641 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Telnet Comport Control Option
Author(s) : G. Clark
Filename : draft-clark-telnet-control-02.txt
Pages : 10
Date : 04/21/1997
This memo proposes a protocol to allow greater use of modems attached to a
network. Increased needs for "off network" communications has increased the
need for modems. Increasing the functionality of Telnet increases the
functionality of network attached modems. For example, the ability to send
a FAX via a network attached modem. This memo addresses configuration of
the comport to which the modem is attached. It does not address the
internal configuration of the modem itself.
Internet-Drafts are 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-clark-telnet-control-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-clark-telnet-control-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-clark-telnet-control-02.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970421154714.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-clark-telnet-control-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-clark-telnet-control-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970421154714.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27245; 22 Apr 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa26685; 22 Apr 97 9:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-mcdonald-pf-key-v2-02.txt
Date: Tue, 22 Apr 1997 09:39:54 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704220939.aa26685 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : PF_KEY Key Management API, Version 2
Author(s) : D. McDonald, C. Metz, B Phan
Filename : draft-mcdonald-pf-key-v2-02.txt
Pages : 14
Date : 04/21/1997
A generic key management API that can be used not only for IP Security
[Atk95a] [Atk95b] [Atk95c] but also for other network security services
is presented in this document. Version 1 of this API was implemented
inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely
distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is
documented here for the benefit of thers who might also adopt and use the
API, thus providing increased portability of key management applications
(e.g. an ISAKMP daemon, a Photuris daemon or SKIP certificate discovery
protocol daemon).
Internet-Drafts are 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-mcdonald-pf-key-v2-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-mcdonald-pf-key-v2-02.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970421155501.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-mcdonald-pf-key-v2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-mcdonald-pf-key-v2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970421155501.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07830; 22 Apr 97 14:32 EDT
Received: from ietf.ietf.org by ietf.org id aa06494; 22 Apr 97 13:59 EDT
To: Alec Dun <AlecDu at exchange.microsoft.com>
cc: Cynthia Clark <cclark at ietf.org>, "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Re: Hotel space in Munich
In-reply-to: Your message of "Mon, 21 Apr 1997 10:32:03 PDT."
<2FBF98FC7852CF11912A000000000001048F63A9 at DINO>
Date: Tue, 22 Apr 1997 13:59:41 -0400
Sender:ietf-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9704221359.aa06494 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Alec,
> Stef, do you know where the "announce archives" are?
> I've been looking for them, but can't find them.
The IETF archive is.....
ftp ietf.org
cd ietf-mail-archive
cd ietf
get the file with the mail, the files are named yy-mm, like 97-04.
Kind Regards,
Cynthia
------------------------------------------------------
Cynthia Clark, IETF Internet-Drafts Administrator
E-mail Address: <cclark at ietf.org>
-------------------------------------------------------
------- Forwarded Message
Received: from ietf.org by ietf.org id aa19836; 21 Apr 97 13:38 EDT
Received: from doggate.microsoft.com by ietf.org id aa19714; 21 Apr 97 13:35 EDT
Received: by DOGGATE with Internet Mail Service (5.0.1457.3)
id <292A1MWH>; Mon, 21 Apr 1997 10:31:56 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001048F63A9 at DINO>
Sender:ietf-request at ietf.org
From: Alec Dun <AlecDu at exchange.microsoft.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: Hotel space in Munich
Date: Mon, 21 Apr 1997 10:32:03 -0700
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1457.3)
Content-Type: text/plain;
charset="iso-8859-1"
Source-Info: From (or Sender) name not authenticated.
Stef, do you know where the "announce archives" are? I've been looking
for them, but can't find them.
Thanks,
Alec.
-----Original Message-----
From: Einar Stefferud [SMTP:Stef at nma.com]
Sent: Monday, April 21, 1997 9:58 AM
To: ietf at ietf.org
Subject: Re: Hotel space in Munich
}
}I wonder how long it will be before
}we read of a phone system meltdown triggered by an IETF
At-A-Glance posting?
}
I hope that the IETF Secretariat will resume mailing those "IETF
MAILING" messages that they used to post on the IETF Announce
List.
It is a real problem having to always go out on the net to get
information that can much more easily be received directly by
EMail,
especially when one is never sure when new information is
posted.
Best...\Stef
------- End of Forwarded Message
Received: from cnri by ietf.org id aa08117; 22 Apr 97 14:41 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17406;
22 Apr 97 14:40 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA09580 at pad-thai.cam.ov.com>; Tue, 22 Apr 1997 15:04:33 GMT
Message-Id: <335D4FC4.7E8 at frcl.bull.fr>
Date: Tue, 22 Apr 1997 16:54:44 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: CAT-IETF WG <cat-ietf at mit.edu>
Subject: SP-NEGO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
CATfanciers,
I have prepared the document that is the successor of the
draft-ietf-cat-snego-03.txt.
It is NOT <draft-ietf-cat-snego-03.txt>
but <draft-ietf-cat-spnego-01.txt>
because the title is now :
The Simple and Protected GSS-API Negotiation Mechanism
When making the changes it appeared that we have in most cases a
protected negotiation and the new title seemed to me more appropriate.
I have made multiple changes from the text originally provided by Bill.
I will be away till next week, so you have plenty of time to review it
before sending comments.
Denis.
The document should be available soon on the server.
In the mean time here is (badly formatted) the document that was sent.
Internet-Draft Eric Baize, Denis Pinkas
IETF Common Authentication Technology WG Bull
<draft-ietf-cat-spnego-01.txt> 22 April 1997
The Simple and Protected GSS-API Negotiation Mechanism
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Comments on this document should be sent to "cat-ietf at mit.edu", the
IETF Common Authentication Technology WG discussion list. Distribution
of this document is unlimited.
2. ABSTRACT
This draft document specifies a Security Negotiation Mechanism for the
Generic Security Service Application Program Interface (GSS-API) which
is described in [1].
The GSS-API provides a generic interface which can be layered atop
different security mechanisms such that if communicating peers acquire
GSS-API credentials for the same security mechanism, then a security
context may be established between them (subject to policy). However,
GSS-API doesn't prescribe the method by which GSS-API peers can
establish whether they have a common security mechanism.
The Simple and Protected GSS-API Negotiation Mechanism defined here
is a pseudo-security mechanism, represented by the object identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
enables GSS-API peers to determine in-band whether their credentials
share common GSS-API security mechanism(s), and if so, to invoke
normal security context establishment for a selected common security
mechanism. This is most useful for applications that are based on
GSS-API implementations which support multiple security mechanisms.
Baize, Pinkas Document Expiration: 22 October 1997 [Page
1]
Internet-Draft April 22,
1997
As most existing GSS-API security mechanisms can support different
options (such as differing cryptographic algorithms due to policy or
legislative constraints), the Simple and Protected GSS-API Negotiation
Mechanism allows to negotiate security mechanisms including their
options (i.e. variants). Mechanism options can be considered as
providing a type of "quality of protection" for security contexts.
To facilitate mechanism negotiation, the OID which currently defines a
security mechanism is "extended" to be able to specify options within a
security mechanism rather than simply the basic mechanism. When the OID
specifies the mechanism only and no explicit option, then this means
that the default option is used. The default option and the specific
options for a given mechanism are as defined in the IETF GSS-API
specification(s) for the mechanism.
This allows to negotiate basic security mechanisms, different options
within a given security mechanism or different options from several
basic security mechanisms.
In addition, a given security mechanism may still negotiate mechanism-
specific options during the context establishment for that mechanism,
i.e. after the mechanism has been selected by the negotiation process.
The simple and protected GSS-API mechanism negotiation is based on the
following negotiation model : the initiator proposes one or several
security mechanisms, the target either accepts the proposed security
mechanism, or chooses one from an offered set, or rejects the proposed
value(s). The target informs the initiator of its choice and may also
return mechanism specific information related to the chosen mechanism.
In its basic form this protocol requires an extra-round trip. Network
connection setup is a critical performance characteristic of any
network infrastructure and extra round trips over WAN links, packet
radio networks, etc. really make a difference. In order to avoid such
an extra round trip the initial security token of the preferred
mechanism for the initiator may be embedded in the initial token.
If the target preferred mechanism matches the initiator's preferred
mechanism, no additional round trips are incurred by using the
negotiation protocol.
The simple and protected GSS-API mechanism negotiation provides a
technique to protect the negotiation that must be used when the
underlying mechanism selected by the target is capable of integrity
protection.
When all the mechanisms proposed by the initiator support integrity
protection or when the selected mechanism supports integrity
protection, then the negotiation mechanism becomes protected since
this guarantees that the appropriate mechanism supported by both
peers has been selected.
Baize, Pinkas Document Expiration: 22 October 1997 [Page 2]
Internet-Draft April 22, 1997
The Simple and Protected GSS-API Negotiation Mechanism uses the
concepts developed in GSS-API specification [1], and requires the use
of new GSS-API context-level tokens : negotiation tokens. Callers
of the GSS-API do not need to be aware of the existence of the
negotiation tokens but only of the new pseudo-security mechanism.
A failure in the negotiation phase causes a major status code to be
returned: GSS_S_BAD_MECH.
3. NEGOTIATION MODEL
3.1. Negotiation description
The model for security mechanism negotiation reuses a subset of the
concepts specified in [2].
Each security mechanism represents one basic security mechanism along
with one option for this security mechanism (when no option is present
the default option is assumed).
- When one security mechanism is proposed by the initiator, it
represents the only security mechanism option supported or
selected (when the additional APIs defined in the Annex A
are used) by the initiator.
- When several security mechanisms are proposed by the initiator,
they represent a set of security mechanisms supported or selected
(when the additional APIs defined in the Annex A are used) by the
initiator.
The first negotiation token sent by the initiator contains an ordered
list of mechanisms and optionally the initial security token for the
desired mechanism of the initiator (i.e. the first of the list).
The first negotiation token sent by the target contains the result of
the negotiation (accept or reject) and, in case of accept, the agreed
security mechanism along with optional mechanism specific information.
It may also include the response to the initial security token for the
desired mechanism of the initiator, when the first proposed mechanism
has been selected. Not all targets must be able to respond to the
initial security token for the desired mechanism when it is present.
The target can simply ignore it and complete the negotiation without
it. Implementations that can piggyback the initial token will be
rewarded by faster connection setup.
In case of a successful negotiation, the security mechanism represents
the value suitable for the target, and picked up from the list offered
by the initiator. The target selects the value according to a simple
selection criteria: it checks if the first entry from its own list is
present in the set offered by the initiator. If the entry is present,
then it is the agreed mechanism, if not then the second entry from its
own ordered list is checked and the process continues until all
entries have been checked. Thus, the target's mechanism preferences
have precedence when more than one common mechanism is available
between the target and initiator.
Baize, Pinkas Document Expiration: 22 October 1997 [Page
3]
Internet-Draft April 17, 1996
3.2. Negotiation procedure
The negotiation procedure is summarised as follows:
(a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
requests (either explicitly, with the negotiation mechanism, or
through accepting a default, when the default is the negotiation
mechanism) that the Simple and Protected GSS-API Negotiation Mechanism
be used;
b) the initiator GSS-API implementation emits a negotiation token
containing the set of supported security mechanism for the credentials
used for this context establishment, and optionally the initial
security token for the preferred mechanism, and indicates
GSS_CONTINUE_NEEDED status;
(c) The GSS-API initiator sends the token to the target application;
(d) The GSS-API target deposits the token through invoking
GSS_Accept_sec_context. The target GSS-API implementation emits a
negotiation token containing which if any of the proposed mechanisms
it supports (or has selected).
If the preferred mechanism selected by the target matches the preferred
mechanism identified by the initiator and the initiator provides a
preferredToken, the negotiation token response may contain also the
initial security token from that mechanism.
If the preferred mechanism is accepted, GSS_Accept_sec_context()
indicates GSS_COMPLETE when unilateral or mutual authentication has
been performed and involves a single token in either direction.
If the proposed mechanism(s) are accepted, or the preferred mechanism
is accepted but involves multiple exchanges (e.g. challenge-response
authentication), then GSS_Accept_sec_context()indicates
GSS_CONTINUE_NEEDED status.
If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
indicates GSS_S_BAD_MECH status. The security context initialisation
has failed.
(e) The GSS-API target returns the token to the initiator application;
(f) The GSS-API initiator deposits the token through invoking
GSS_Init_sec_context.
GSS_Init_sec_context() may then indicate GSS_CONTINUE_NEEDED,
GSS_COMPLETE or GSS_S_BAD_MECH status.
The GSS_S_BAD_MECH status is returned when the negotiation token
carries a reject result or when the negotiation token carries an
accept result and the mechanism selected by the target is not
included in the initial list sent by the initiator or the
Baize, Pinkas Document Expiration: 22 October 1997 [Page 4]
Internet-Draft April 22, 1997
selected mechanism supports a MIC token but the MIC computed over
the list of mechanisms sent by the initiator is missing or
incorrect. If the negotiation token carries a reject result, the
context establishment is impossible. For example, a rejection
will occur if the target doesn't support the initiator's proposed
mechanism type(s) and/or mechanism option(s). Upon failure of the
mechanism negotiation procedure, the mech_type output parameter
value is the negotiation mechanism type.
The GSS_CONTINUE_NEEDED status is returned when the negotiation
token carries an accept result. In that case
GSS_Init_sec_context() returns an initial context token as
output_token. The initiator then sends the output_token to the
target. The security context initialisation is then continued
according to the standard GSS-API conventions for the selected
mechanism, where the tokens of the selected mechanism are
encapsulated until the GSS_COMPLETE is returned for both the
initiator and the target. When GSS_CONTINUE_NEEDED is returned,
the mech_type output parameter is not yet valid.
When GSS_COMPLETE is returned, the mech_type output parameter
indicates the selected mechanism. When the final negotiation token
does not contain a MIC, the initiator GSS-API implementation must
check the returned/selected mechanism options with its originally
submitted list of mechanism options and also verify that the
selected mechanism is not able to support a MIC. When the final
negotiation token contains a MIC over the initial mechanisms list
sent by the initiator, the MIC must be verified.
Note that the *_req_flag input parameters for context establishment
are relative to the selected mechanism, as are the *_state output
parameters. i.e., these parameters are not applicable to the
negotiation process per se.
The initiator GSS-API calling application may know when the
negotiation exchanges were protected or not. For this, when
GSS_COMPLETE is returned, it can simply test the integ_avail flag.
When this flag is set it indicates that the negotiation was protected.
On receipt of a negotiation token on the target side, a GSS-API
implementation that does not support negotiation would indicate the
GSS_FAILURE status as if a particular basic security mechanism had
been requested but was not supported.
When GSS_Acquire_cred is invoked with the negotiation mechanism as
desired_mechs, an implementation-specific default credential is used to
carry on the negotiation. A set of mechanisms as specified locally by
the
system administrator is then available for negotiation. If there is a
desire for the caller to make its own choice, then an additional API has
to
be used (see Appendix A).
Baize, Pinkas Document Expiration: 22 October 1997 [Page 5]
Internet-Draft April 22, 1997
4. DATA ELEMENTS
4.1. Mechanism Type
MechType::= OBJECT IDENTIFIER
mechType
The concept of mechType is extended to specify a basic security
mechanism including its options. Each basic security mechanism
is as defined in [1], and must provide a single default option
which fully specifies the mechanism. The default option is
represented by the OID of the mechanism itself (i.e. without any
extension).
The options are specified by extending the OID. This
extension is defined in the same IETF GSS-API specification as
the security mechanism context token specification.
4.2. Negotiation Tokens
The syntax of the negotiation tokens follows the InitialContextToken
syntax defined in [1]. The security mechanism of the initial
negotiation token is identified by the Object Identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
4.2.1. Syntax
This section specifies the syntax of the corresponding
"innerContextToken" field for the first token and subsequent
negotiation tokens.
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenTarg [1] NegTokenTarg }
MechType ::= OBJECT IDENTIFIER
MechTypeList ::= SEQUENCE OF MechType
NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList OPTIONAL
preferredToken [1] OCTET STRING OPTIONAL
}
negTokenInit
Negotiation token sent by the initiator to the target, which
contains, for the first token sent, one or more security
mechanisms supported by the initiator. The preferredToken is an
optional field of the first token sent that all target
implementations would not have to support. However for those
targets that do support piggybacking the initial preferredToken,
an optimistic negotiation response is possible.
Baize, Pinkas Document Expiration: 22 October 1997 [Page 6]
Internet-Draft April 22, 1997
NegTokenTarg ::= SEQUENCE {
negResult [0] ENUMERATED { accept (0), reject (1) } OPTIONAL
supportedMech [1] MechType OPTIONAL
MechSpecInfo [2] OCTET STRING OPTIONAL
preferredToken [3] OCTET STRING OPTIONAL
mechListMIC [4] OCTET STRING OPTIONAL
}
negTokenTarg
Negotiation token returned by the target to the initiator which
contains, for the first token returned, a global negotiation
result, the security mechanism selected (if any) and optional
information specific to the security mechanism selected by the
target. For those targets that support piggybacking the initial
preferredToken, an optimistic negotiation response is possible
and includes in that case a preferredToken which may continue
the authentication exchange (e.g. when mutual authentication has
been requested or when unilateral authentication requires several
round trips). Otherwise the preferredToken is used to carry the
tokens specific to the mechanism selected. For the last token
returned by the target, the mechListMIC is a MIC computed over
the MechTypes using the selected mechanism.
negResult
Result of the negotiation exchange, specified by the target.
This can be either :
accept
The target accepts one of the proposed
security mechanisms, or,
reject
The target rejects all the proposed security
mechanisms.
supportedMech
This field has to be present when negResult is "accept".
It is a choice from the mechanisms offered by the initiator.
MechSpecInfo
This field may be used to transmit mechanism specific
information relative to the security mechanism selected
by the target.
preferredToken
This field may be used either to transmit the response to the
preferredToken when sent by the initiator and when the first
mechanism from the list has been selected by the target or
to carry the tokens specific to the selected security mechanism.
mechListMIC
If the selected mechanism is capable of integrity protection,
this field must be present in the last message of the negotiation,
(i.e., when the underlying mechanism returns a non-empty token
Baize, Pinkas Document Expiration: 22 October 1997 [Page 7]
Internet-Draft April 22, 1997
and a major status of GSS_COMPLETE); it contains the result of a
GetMIC of the MechTypes field in the initial NegTokenInit.
4.2.2. Processing of mechListMIC.
When the mechanism selected by the negotiation supports integrity
protection as a service, the mechListMIC must be used and validated.
In particular, the target that sends the last context establishment
token must also include the result of a gss_get_mic() of the
mechTypeList sent by the initiator in the first token; in addition,
the initiator that receives the last token must require that the
mechListMIC field be present and valid. In the absence of a valid
mechListMIC, the negotiation must fail as if the last context
establishment token was invalid.
5. EXAMPLES : SECURITY MECHANISM NEGOTIATION
Follow some examples of security mechanism options negotiation between
an initiator (I) and a target (T).
5.1. Initial steps
(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2),
and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2-
OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2.
(I) invokes GSS_Init_sec_context() with :
Input
mech_type = OID for negotiation mechanism or NULL, if the
negotiation mechanism is the default mechanism.
Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenInit
The negotiation token (negTokenInit) contains three security mechanisms
with :
mechType = GSS-MECH1 or
mechType = GSS-MECH2-OPTION1 or
mechType = GSS-MECH2-OPTION2
(I) sends to (T) the negotiation token.
5.2 Successful negotiation steps
(T) supports GSS-MECH2-OPTION1.
(T) receives the negotiation token (negTokenInit) from (I)
(T) invokes GSS_Accept_sec_context() with :
Baize, Pinkas Document Expiration: 22 October 1997 [Page 8]
Internet-Draft April 22, 1997
Input
input_token = negTokenInit
Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenTarg
The negotiation token (negTokenTarg) contains :
negResult = accept (the negotiation result)
supportedMech : mechType = GSS-MECH2-OPTION1
(T) returns the negotiation token (negTokenTarg) to (I)
(I) invokes GSS_Init_sec_context() with :
Input
input_token = negTokenTarg
Output
major_status = GSS_COMPLETE
output_token = initialContextToken (initial context token
for GSS-MECH2-OPTION1)
mech_type = GSS-MECH2-OPTION1
The subsequent steps are security mechanism specific, and work as
specified in [1]. The output tokens from the security mechanism are
encapsulated in a NegTokenTarg message (with the supportedMech and
MechSpecInfo fields omitted, and the mechListMIC included with the
last token).
5.3. Failed negotiation steps
(T) supports GSS-MECH3.
(T) receives the negotiation token (negTokenInit) from (I)
(T) invokes GSS_Accept_sec_context() with :
Input
input_token = negTokenInit
Output
major_status = GSS_S_BAD_MECH
output_token = negTokenTarg
The negotiation token (negTokenTarg) contains :
negResult = reject (the negotiation result)
(T) returns the negotiation token (negTokenTarg) to (I)
(I) invokes GSS_Init_sec_context() with :
Input
input_token = negTokenTarg
Baize, Pinkas Document Expiration: 22 October 1997 [Page 9]
Internet-Draft April 22, 1997
Output
major_status = GSS_S_BAD_MECH
The security context establishment has failed.
5.4 Successful Negotiation with preferred mechanism info
(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2),
and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2-
OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2.
(I) invokes GSS_Init_sec_context() with :
Input
mech_type = OID for negotiation mechanism or NULL, if the
negotiation mechanism is the default mechanism.
Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenInit
The negotiation token (negTokenInit) contains three security mechanisms
with :
mechType = GSS-MECH1 or
mechType = GSS-MECH2-OPTION1 or
mechType = GSS-MECH2-OPTION2
preferredToken = output_token from GSS_Init_sec_context
( first mechType) as described in [1]
(I) sends to (T) the negotiation token.
(T) supports GSS-MECH1.
(T) receives the negotiation token (negTokenInit) from (I)
(T) invokes GSS_Accept_sec_context() with :
Input
input_token = negTokenInit
Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenTarg
The negotiation token (negTokenTarg) contains :
negResult = accept (the negotiation result)
supportedMech : mechType = GSS-MECH1
MechSpecInfo = mechanism specific information for
the preferred mechanism
preferredToken = output_token from
GSS_Accept_sec_context(preferredToken )
Baize, Pinkas Document Expiration: 22 October 1997 [Page 10]
Internet-Draft April 22, 1997
(T) returns the negotiation token (negTokenTarg) to (I)
(I) invokes GSS_Init_sec_context() with :
Input
input_token = negTokenTarg
Output
major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed
output_token = ContextToken (initial or subsequent context token
for GSS-MECH1)
mech_type = GSS-MECH1
Specific implementations of the protocol can support the optimistic
negotiation by completing the security context establishment using the
agreed upon mechanism as described in [1]. As described above in
section 5.2, the output tokens from the security mechanism are
encapsulated in a NegTokenTarg message (with the negResult,
supportedMech and MechSpecInfo fields omitted, and the mechListMIC
included with the last token).
6. ACKNOWLEDGMENTS
Acknowledgments are due to Piers McMahon and Tom Parker of ICL,
Stephen Farrell of SSE, Doug Rosenthal of EINet and John Linn of
Openvision for reviewing earlier versions of this document and for
providing useful inputs. Acknowledgments are also due to Peter Brundrett
of Microsoft for his proposal for an optimistic negotiation, and for
Bill Sommerfeld of Hewlett-Packard for his proposal for protecting
the negotiation.
7. SECURITY CONSIDERATIONS
The purpose of the generic simple GSS-API mechanism negotiation
mechanism is to enable peers to agree on the value for a security
mechanism and security related options required for initialising
security services.
When the mechanism selected by the target from the list supplied by
the initiator supports integrity protection, then the negotiation is
protected.
When one of the mechanisms proposed by the initiator does not support
integrity protection, then the negotiation is exposed to all threats a
non
secured service is exposed. In particular, an active attacker can force
to
use a security mechanism which is not the common preferred one (when
multiple security mechanisms are shared between peers) but which is
acceptable anyway to the target.
In any case, the communicating peers may be exposed to the denial of
service threat.
Baize, Pinkas Document Expiration: 22 October 1997 [Page 11]
Internet-Draft April 22, 1997
APPENDIX A
GSS-API NEGOTIATION SUPPORT API
In order to provide to a GSS-API caller (either the initiator or the
target or both) the ability to choose among the set of supported
mechanisms a reduced set of mechanisms for negotiation, two
additional APIs are defined:
GSS_Get_neg_mechs() indicates the set of security mechanisms available
on the local system to the caller for negotiation.
GSS_Set_neg_mechs() specifies the set of security mechanisms to be
used on the local system by the caller for negotiation.
A.1. GSS_Get_neg_mechs call
Input:
cred_handle OCTET STRING - NULL specifies default credentials
Outputs:
major_status INTEGER,
minor_status INTEGER,
mech_option_set SET OF OBJECT IDENTIFIER
Return major_status codes :
GSS_COMPLETE indicates that the set of security mechanism
options available for negotiation has been returned in
mech_option_set.
GSS_FAILURE indicates that the requested operation could not
be performed for reasons unspecified at the GSS-API level.
Allows callers to determine the set of security mechanism options
available for negotiation. This call is intended for support of
specialised callers who need to reduce the set of negotiable security
mechanism options from the set of supported security mechanisms
available to the caller (based on available credentials).
Note: The GSS_Indicate_mechs() function indicates the full set of
mechanism
types available on the local system. Since this call does not use a
credential handle as an input parameter, the returned set is not
necessarily available for all credentials.
Baize, Pinkas Document Expiration: 22 October 1997 [Page 12]
Internet-Draft April 22, 1997
A.2. GSS_Set_neg_mechs call
Input:
cred_handle OCTET STRING - NULL specifies default credentials
mech_option_set SET OF OBJECT IDENTIFIER
Outputs:
major_status INTEGER,
minor_status INTEGER,
Return major_status codes :
GSS_COMPLETE indicates that the set of security mechanisms
available for negotiation has been set to mech_option_set.
GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
Allows callers to specify the set of security mechanism options that
may be negotiated with a particular credential: A NULL mech_option_set
specifies that only the default mech_type with the default option is
available for the GSS-API implementation. This call is intended for
support of specialised callers who need to restrict the set of
negotiable security mechanism options from the set of all security
mechanism options available to the caller (based on available
credentials). Note that if more than one mechanism is specified in
mech_option_set, the order in which those mechanisms are specified
implies a relative mechanism preference for the target.
REFERENCES
[1] Linn, J., "Generic Security Service Application Program
Interface", RFC 2078, OpenVision, January 1997. Available on
ftp://ds.internic.net/rfc/rfc2078.txt
[2] Standard ECMA-206, "Association Context Management including
Security Context Management", December 1993. Available on
http://www.ecma.ch
AUTHORS'S ADDRESSES
Eric Baize Internet email: E.Baize at ma02.bull.com
Bull HN - MA02/211S Phone: +1 508 294 61 37
Technology Park Fax: +1 508 294 61 09
Billerica, MA 01821 - USA
Denis Pinkas Internet email: D.Pinkas at frcl.bull.fr
Bull Phone: +33 1 30 80 34 87
Rue Jean-Jaures Fax: +33 1 30 80 33 21
BP 68
78340 Les Clayes-sous-Bois - FRANCE
Baize, Pinkas Document Expiration: 22 October 1997 [Page 13]
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa16289; 22 Apr 97 19:39 EDT
Received: from caladan.arrakis.es by ietf.org id aa16092; 22 Apr 97 19:29 EDT
Received: from pc-de-raides-j. (ih-69.arrakis.es [195.5.77.69]) by arrakis.es (8.7.5/8.7.3) with SMTP id BAA30788 for <ietf at ietf.org>; Wed, 23 Apr 1997 01:25:54 +0200 (MET DST)
Message-Id: <199704222325.BAA30788 at arrakis.es>
Comments: Authenticated sender is <raidesj at pop3.arrakis.es>
Sender:ietf-request at ietf.org
From: Dr-X <raidesj at arrakis.es>
Organization: Dr-X Enterprises, Ltd.
To: ietf at ietf.org
Date: Wed, 23 Apr 1997 00:27:28 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Subject: How can I do to make a Draft??
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.53/R1)
Source-Info: From (or Sender) name not authenticated.
Dear Sirs/Ladies:
After my initial complains because of the very much mail (still
coming) about the Munich Meeting, and having started to get and read
some Drafts on many different topics, I now want to know exactly how
to make a Draft? I mean:
- Which steps must I perform to propose a new (or modified) protocol
or application for Internet technology?
- How can I start a Working Group on it or at least have feedback
from related groups or individuals (I mean without flooding this
mail-list service) to share knowledge and even experiment on-line?
- How is it possible to join a Work-In-Progress Group and in which
ways can a free-lancer as I am help them to achieve their goals?
I have more questions in the pipeline, but I think I must have some
basic concepts clear first! I'm on my first days on the Net (I've
just started two months ago) and -as a very curious creature that I
am- I need to know as much as possible of this medium -the Net!
I will gracefully accept all the nettiquette rules needed to make
things go, but I won't accept a "sorry, you are not one of us so
don=B4t bother us any more!" kind of answer because I think it's not
very polite to say the least!
I really want to collaborate with my -maybe "wild"- ideas in the
building of the 21th Century Internet just for the pleasure of
saying: "Look, my children! I was there when all this started taking
shape!" (of course, if I can make money to finance my on-line
sessions it'll be welcome as well, but I can make it in other places)
;)
Hoping some willing soul to give me the orientation I need to be
productive .....
XXX XXX
DDDD RRRR XX XX
D D R R XX XX
D D R R XX XX
D D RRRR ----- XXXX ... ON THE EDGE OF TECHNOLOGY
D D R R XX XX
D D R R XX XX
DDDD R R XX XX
XXX XXX
Received: from ietf.org by ietf.org id aa17755; 22 Apr 97 20:21 EDT
Received: from nacho.cisco.com by ietf.org id aa17521; 22 Apr 97 20:18 EDT
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id RAA18226; Tue, 22 Apr 1997 17:14:42 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id RAA06694; Tue, 22 Apr 1997 17:14:40 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v03007811af82fffa16f6 at [171.69.128.118]>
In-Reply-To: <199704222325.BAA30788 at arrakis.es>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 22 Apr 1997 16:59:03 -0700
To: Dr-X <raidesj at arrakis.es>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Re: How can I do to make a Draft??
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>- Which steps must I perform to propose a new (or modified) protocol
>or application for Internet technology?
go to http://www.ietf.org and click on "internet draft instructions"
- How can I start a Working Group on it or at least have feedback
from related groups or individuals (I mean without flooding this
mail-list service) to share knowledge and even experiment on-line?
go to http://www.ietf.org and click on "IETF Working Groups"
- How is it possible to join a Work-In-Progress Group and in which
ways can a free-lancer as I am help them to achieve their goals?
go to http://www.ietf.org and click on "joining the IETF"
>Hoping some willing soul to give me the orientation I need to be
>productive ...
Got one of those, too. Go to http://www.ietf.org and click on "Overview of
the IETF".
And if you still have questions, drop me a note.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Fred Baker | While one person hesitates because
IETF Chair | he feels inferior, the other is
Senior Software Engineer | busy making mistakes and becoming
Cisco Systems | superior.
519 Lado Drive | -- Henry C. Link
Santa Barbara, California 93111 |
VOICE +1 408 526 4257 |
FAX +1 805 681-0115 |
PAGE: send max 100 character message to fbaker at airnote.com
Received: from ietf.org by ietf.org id aa05188; 23 Apr 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa03702; 23 Apr 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-oncrpc-remote-03.txt
Date: Wed, 23 Apr 1997 09:44:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704230944.aa03702 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the ONC Remote Procedure Call
Working Group of the IETF.
Title : RPC: Remote Procedure Call Protocol Specification
Version 2
Author(s) : S. Nahm
Filename : draft-ietf-oncrpc-remote-03.txt
Pages : 20
Date : 04/22/1997
This document describes the ONC Remote Procedure Call (ONC RPC Version 2)
protocol as it is currently deployed and accepted. "ONC" stands for
"Open Network Computing".
Internet-Drafts are 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-oncrpc-remote-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-oncrpc-remote-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-remote-03.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970422104608.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-oncrpc-remote-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-remote-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970422104608.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05204; 23 Apr 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa03903; 23 Apr 97 9:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-gahrns-imap-referrals-02.txt
Date: Wed, 23 Apr 1997 09:45:12 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704230945.aa03903 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Note: This revision reflects comments received during the last call period.
Title : IMAP4 Referrals
Author(s) : M. Gahrns
Filename : draft-gahrns-imap-referrals-02.txt
Pages : 9
Date : 04/22/1997
When dealing with large amounts of users, messages and geographically
dispersed IMAP4 [RFC-2060] servers, it is often desirable to distribute
messages amongst different servers within an organization. For example an
administrator may choose to store user's personal mailboxes on a local
IMAP4 server, while storing shared mailboxes remotely on another server.
This type of configuration is common when it is uneconomical to store all
data centrally due to limited bandwidth or disk resources. Additionally,
users may be frequently moved from one IMAP4 server to another because of
hardware failures or organizational changes.
Referrals allow clients to seamlessly access mailboxes that are distributed
across several IMAP4 servers or to transparently connect to an alternate
IMAP4 server.
A referral mechanism can provide efficiencies over the alternative
"proxy method", in which the local IMAP4 server contacts the remote
server on behalf of the client, and then transfers the data from the
remote server to itself, and then on to the client. The referral
mechanism's direct client connection to the remote server is often a
more efficient use of bandwidth, and does not require the local server
to impersonate the client when authenticating to the remote server.
Internet-Drafts are 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-gahrns-imap-referrals-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-referrals-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-gahrns-imap-referrals-02.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970423094051.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-referrals-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gahrns-imap-referrals-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970423094051.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05193; 23 Apr 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa03660; 23 Apr 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-vinod-icp-traffic-dist-00.txt
Date: Wed, 23 Apr 1997 09:44:26 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704230944.aa03660 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Hierarchical HTTP Routing Protocol
Author(s) : V. Valloppillil, J. Cohen
Filename : draft-vinod-icp-traffic-dist-00.txt
Pages : 6
Date : 04/22/1997
Recent interest in finding solutions for traffic problems stemming from
HTTP have centered around the use of cooperating proxy-caches.
We contend that by using a deterministic, hash-based approach for routing
URLs within an "array" of proxy servers, many of the benefits of
alternative cache cooperation protocols (such as ICP) may be realized.
As an example of such an implementation we propose the use of "Proxy Client
Configuration Files" between proxy servers in order to exchange routing
information. This implementation is motivated in part by the adoption of
this file by existing, popular web browsers to provide intelligent URL
request routing.
This draft discusses adopting this well-understood, widely implemented
browser protocol by web proxies in order to facilitate intelligent
routing of requests within a network of proxy servers.
Internet-Drafts are 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-vinod-icp-traffic-dist-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-vinod-icp-traffic-dist-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-vinod-icp-traffic-dist-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970422104307.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-vinod-icp-traffic-dist-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-vinod-icp-traffic-dist-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970422104307.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05195; 23 Apr 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa03745; 23 Apr 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-cat-snego-04.txt
Date: Wed, 23 Apr 1997 09:44:39 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704230944.aa03745 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Title : The Simple and Protected GSS-API Negotiation Mechanism
Author(s) : E. Baize, D. Pinkas
Filename : draft-ietf-cat-snego-04.txt
Pages : 13
Date : 04/22/1997
This draft document specifies a Security Negotiation Mechanism for the
Generic Security Service Application Program Interface (GSS-API) which is
described in [1].
The GSS-API provides a generic interface which can be layered atop
different security mechanisms such that if communicating peers
acquire GSS-API credentials for the same security mechanism,
then a security context may be established between them (subject
to policy). However, GSS-API doesn't prescribe the method by which GSS-API
peers can establish whether they have a common security mechanism.
The Simple and Protected GSS-API Negotiation Mechanism defined here is a
pseudo-security mechanism, represented by the object identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables
GSS-API peers to determine in-band whether their credentials share common
GSS-API security mechanism(s), and if so, to invoke normal security context
establishment for a selected common security mechanism. This is most useful
for applications that are based on GSS-API implementations which support
multiple security mechanisms.
Internet-Drafts are 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-cat-snego-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-snego-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-snego-04.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970422111531.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-snego-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-snego-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970422111531.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05181; 23 Apr 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa03787; 23 Apr 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-armitage-ion-venus-02.txt
Date: Wed, 23 Apr 1997 09:44:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704230944.aa03787 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : VENUS - Very Extensive Non-Unicast Service
Author(s) : G. Armitage
Filename : draft-armitage-ion-venus-02.txt
Pages : 12
Date : 04/22/1997
The MARS model (RFC2022) provides a solution to intra-LIS IP multicasting
over ATM, establishing and managing the use of ATM pt-mpt SVCs for IP
multicast packet forwarding. Inter-LIS multicast forwarding is achieved
using Mrouters, in a similar manner to which the `Classical IP over ATM'
model uses Routers to inter-connect LISes for unicast traffic. The
development of unicast IP shortcut mechanisms (e.g. NHRP) has led some
people to request the development of a Multicast equivalent. There are a
number of different approaches. This document focuses exclusively on the
problems associated with extending the MARS model to cover multiple
clusters or clusters spanning more than one subnet. It describes a
hypothetical solution, dubbed `Very Extensive NonUnicast Service' (VENUS),
and shows how complex such a service would be. It is also noted that VENUS
ultimately has the look and feel of a single, large cluster using a
distributed MARS. This document is being issued to help focus ION efforts
towards alternative solutions for establishing ATM level multicast
connections between LISes.
Internet-Drafts are 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-armitage-ion-venus-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-armitage-ion-venus-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-armitage-ion-venus-02.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970422112204.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-armitage-ion-venus-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-armitage-ion-venus-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970422112204.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05197; 23 Apr 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa03604; 23 Apr 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-classic2-02.txt
Date: Wed, 23 Apr 1997 09:44:17 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704230944.aa03604 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : Classical IP and ARP over ATM
Author(s) : M. Laubach, J. Halpern
Filename : draft-ietf-ion-classic2-02.txt
Pages : 27
Date : 04/22/1997
This memo defines an initial application of classical IP and ARP in an
Asynchronous Transfer Mode (ATM) network environment configured as a
Logical IP Subnetwork (LIS) as described in Section 5. This memo does not
preclude the subsequent development of ATM technology into areas other than
a LIS; specifically, as single ATM networks grow to replace many Ethernet
local LAN segments and as these networks become globally connected, the
application of IP and ARP will be treated differently. This memo considers
only the application of ATM as a direct replacement for the "wires" and
local LAN segments connecting IP end-stations ("members") and routers
operating in the "classical" LAN-based paradigm. Issues raised by MAC level
bridging and LAN emulation are beyond the scope of this paper.
This memo introduces general ATM technology and nomenclature. Readers are
encouraged to review the ATM Forum and ITU-TS (formerly CCITT) references
for more detailed information about ATM implementation agreements and
standards.
Internet-Drafts are 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-ion-classic2-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-classic2-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-classic2-02.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970422103737.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-classic2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-classic2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970422103737.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05196; 23 Apr 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa03875; 23 Apr 97 9:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-sasl at imc.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-auth-sasl-10.txt
Date: Wed, 23 Apr 1997 09:45:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704230945.aa03875 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Authentication and Security Layer (SASL)
Author(s) : J. Myers
Filename : draft-myers-auth-sasl-10.txt
Pages : 15
Date : 04/22/1997
This document describes a method for adding authentication support to
connection-based protocols. To use this specification, a protocol includes
a command for identifying and authenticating a user to a server and for
optionally negotiating protection of subsequent protocol interactions. If
its use is negotiated, a security layer is inserted between the protocol
and the connection. This document describes how a protocol specifies such
a command, defines several mechanisms for use by the command, and defines
the protocol used for carrying a negotiated security layer over the
connection.
Internet-Drafts are 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-myers-auth-sasl-10.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-10.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-auth-sasl-10.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970422164424.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970422164424.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05201; 23 Apr 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa03829; 23 Apr 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-lawrence-http-noclock-00.txt
Date: Wed, 23 Apr 1997 09:44:55 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704230944.aa03829 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : HTTP/1.1 Operation without a Clock
Author(s) : S. Lawrence, J. Mogul, R. Gray
Filename : draft-lawrence-http-noclock-00.txt
Pages : 4
Date : 04/22/1997
This memo describes a problem with the current Proposed Standard for
HTTP/1.1 found as a result of implementation experience. A web server may
be implemented in an embedded system as a network user interface. Often
the embedded system is one which has no other use for a real-time clock,
and/or the web interface is being added to an existing device which has no
clock. Without a clock, no accurate HTTP Date header can be generated.
This memo examines the implications of this situation for the operation of
HTTP/1.1 origin servers, proxies, and clients, and proposes changes to the
HTTP/1.1 specification to permit compliant operation in such systems.
Internet-Drafts are 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-lawrence-http-noclock-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-lawrence-http-noclock-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-lawrence-http-noclock-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970422152113.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-lawrence-http-noclock-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lawrence-http-noclock-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970422152113.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13427; 23 Apr 97 11:53 EDT
Received: from nacho.cisco.com by ietf.org id aa13310; 23 Apr 97 11:49 EDT
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id IAA12825; Wed, 23 Apr 1997 08:46:04 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id IAA06794; Wed, 23 Apr 1997 08:46:03 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v03007829af83dc55fe58 at [171.69.128.118]>
In-Reply-To: <9704238618.AA861805428 at ccmail.dowjones.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 23 Apr 1997 08:41:34 -0700
To: david jost <djost at ccmail.dowjones.com>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Re[2]: How can I do to make a Draft??
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 9:16 AM -0500 4/23/97, david jost wrote:
> I had the same question on draft format. To me it is not obvious from
> the web page where I would find the template for Internet Drafts.
There are a few templates in the internet drafts directory, if you want to
use one of them. Use is not required.
ftp://ds.internic.net/internet-drafts/2-latex.template
ftp://ds.internic.net/internet-drafts/2-nroff.template
ftp://ds.internic.net/internet-drafts/2-scribe.template
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
Calvin and Hobbes (Bill Watterson)
Received: from ietf.org by ietf.org id aa16567; 23 Apr 97 13:34 EDT
Received: from h20.n145.organic.com by ietf.org id aa16347; 23 Apr 97 13:26 EDT
Received: from veal.organic.com (veal.organic.com [204.152.145.20]) by veal.organic.com (8.8.3/8.6.12) with SMTP id KAA06220 for <ietf at ietf.org>; Wed, 23 Apr 1997 10:25:52 -0700 (PDT)
Date: Wed, 23 Apr 1997 10:25:50 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "Rick H. Wesson" <wessorh at organic.com>
To: ietf at ietf.org
Subject: Shared gTLD Repository (coredb) WG
Message-ID: <Pine.GSO.3.95.970423102231.3079E-100000 at veal.organic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
A Proto-WG has been formed to deal with defining a protocol, and a
requirements document for a Shared gTLD DNS Registration Repository. This
Repository is referred to in the IAHC's Final Report on creating
additional Top Level Domains and Registrars to manage said name-space(tm).
A moderately active (~15 messages per day) list is discussing requirements
for this system. If you wish to participate in the discussion (and
hopefully the working group) subscribe by sending the word 'subscribe'
(with out the quotes) to ietf-coredb-request at imc.org
A Web page with subscription info is at: http://www.imc.org/ietf-coredb/
The charter is attached.
-Rick
Council of Registrars Database (coredb)
------------------------------------------------------------------------
Draft Charter
Current status: proto-WG
Chair(s):
Rick Wesson <rick at ar.com>
Operational Requirements Area Director(s):
John Curran <jcuran at bbn.com>
Michael O'Dell <mo at uunet.uu.net>
Mailing lists:
General Discussion: ietf-coredb at imc.org
To Subscribe: ietf-coredb-request at imc.org
with 'subscribe' in the body of your message.
Archive: http://www.imc.org/ietf-coredb/mail-archive/
Description of Working Group:
Enchancements to the gTLD DNS space will entail sharing a registration
data base (repository) among mutually suspicious registrars. For this
operation to succeed, a reliable and efficient method must be defined for
achieving that sharing. This Working Group will specify the functional
requirements and specify or select the protocol to be used for such a
service.
There are three main participatnts in a shared gTLD repository:
Applicants (users), Registrars, and the Repository. The Registrars take
applications from end-users and submit create, modify, and delete requests
to the central repository. This Working Group will define a protocol for
the interaction of the Registrars and the central repository i.e., a
shared database. This group will also define a set of templates that the
registrars will accept and the maping of those templates into request the
Repository will process.
This working group will focus on transitioning from the system implemented
by CORE to a robust open standard. The group will look at scaleing and
security issues, define a transition plan, define protocols for
interaction between system components, and define database objects. The
group will work twards a system that scales to 100's of millions of
objects while not excludeing implementstions from the use of distributed
databases.
Security concerns will include authenticated and private exchanges
between registrars and the repository, and to migration of applicants'
entries between registrars in a manner that satisfies CORE policies, for
example preventing "theft" of accounts.
The working group will coordinate it's effort where necessary with other
working groups (in particular RIDE) for data formats that are
already defined or use the guidelines put forward by said groups.
Goals and Milestones.
Jun 97 Draft of requirements for shared repository
Aug 97 Draft of object formats
Draft of application templates.
Sep 97 Draft (or selection) of exchange protocol
Dec 97 Revisions to requirements, object and protocol
specifications
Apr 98 Specifications submitted to standards track
=============================================================
Rick H. Wesson Organic Online, Inc.
Geek rick at organic.com
Voice: 415.284.6888 http://www.organic.com
Received: from ietf.org by ietf.org id aa29017; 23 Apr 97 20:37 EDT
Received: from zephyr.isi.edu by ietf.org id aa28796; 23 Apr 97 20:29 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA01739>; Wed, 23 Apr 1997 17:26:39 -0700
Message-Id: <199704240026.AA01739 at zephyr.isi.edu>
To: IETF-Announce: ;
To: Internet-Monthly-Report-People: ;
Subject: Internet Monthly Report for March, 1997
Cc: imr-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 23 Apr 97 17:26:38 PDT
Sender:ietf-announce-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
--NextPart
The Internet Monthly Report for March, 1997 is now available
at the following location:
URL= ftp://ftp.isi.edu/in-notes/imr/imr9703.txt
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
Requests to be added or deleted from the IMR report list:
The Internet Monthly Report list is managed by MajorDomo atISI.EDU.
The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be added or deleted from the Internet Monthly report list
should be sent to majordomo at isi.edu with the message body either
subscribe imr or unsubscribe imr.
Requests to be added or deleted from the IETF list should be sent to
ietf-request at ietf.org.
Internet Monthly Report availability via WWW, FTP and EMAIL:
IMR Retrieval using WWW
-----------------------
The URL below may be used in web browsers to access the IMRs. You
will see a list of names in the form IMR9703.TXT. For example,
IMR9703.TXT is the report for March 1997.
URL: ftp://ftp.isi.edu/in-notes/imr
IMR Retrieval using EMAIL via the RFC-INFO Service
--------------------------------------------------
The EMail retrieval system RFC-Info will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to rfc-info at ISI.EDU with
the message body help: ways_to_get_imrs. For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from FTP.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of
the IMR.
For example IMR9703.TXT is the report for March 1997).
Login with FTP username anonymous and password ftp.
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the current IMR.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9703
--OtherAccess
Content-Type: Message/External-body;
name="imr9703.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29016; 23 Apr 97 20:37 EDT
Received: from zephyr.isi.edu by ietf.org id aa28835; 23 Apr 97 20:32 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA01841>; Wed, 23 Apr 1997 17:28:51 -0700
Message-Id: <199704240028.AA01841 at zephyr.isi.edu>
To: ietf at ietf.org, imr at isi.edu
Subject: Internet Monthly Report for March, 1997
Cc: imr-ed at isi.edu
Date: Wed, 23 Apr 97 17:28:51 PDT
Sender:ietf-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
Source-Info: From (or Sender) name not authenticated.
March 1997
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to "IMR-ED at ISI.EDU".
`````````````````````````````````````````````````````````````````````
The Internet Monthly Report mailing list is now managed by MajorDomo at
ISI.EDU. The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be ADDED or DELETED from the Internet Monthly report list
should be sent to "majordomo at isi.edu" with the message body either
"subscribe imr" or "unsubscribe imr".
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
or URL: http://www.isi.edu/in-notes/imr/
IMR Editor [Page 1]
Internet Monthly Report March 1997
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 21
Registration Services . . . . . . . . . . . . . . . . . page 21
Directory Services. . . . . . . . . . . . . . . . . . . page 21
US Domain Registry. . . . . . . . . . . . . . . . . . . page 22
MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 24
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 25
IANA REPORT . . . . . . . . . . . . . . . . . . . . . . . page 25
RFC-EDITOR REPORT . . . . . . . . . . . . . . . . . . . . page 26
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 27
TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 31
IMR Editor [Page 2]
Internet Monthly Report March 1997
INTERNET ARCHITECTURE BOARD
The minutes of the IAB back to 1990 are available for anonymous ftp
access on host ftp.isi.edu, directory /pub/IAB, or via the IAB
World-Wide Web page with URL http://www.iab.org/iab/.
Brian Carpenter IAB Chair
INTERNET ENGINEERING REPORTS
----------------------------
Internet Monthly Report for March
1. The first IETF meeting 1997 will be held in Memphis, Tennessee
from April 7-10, 1997. Our local host is Federal Express.
Following Memphis, the IETF returns to Europe for the summer
meeting in Munich, Germany from August 11-15, 1997. Our host for
this meeting will be Digi/ISOC.DE. The final meeting of the year
will be held in the D.C. area, hosted by Newbridge.
Once all arrangements have been made, notifications will be sent
to the IETF Announcement list. Remember that information on
future meetng sites can always be found in the file
0mtg-sites.txt, located on the IETF shadow directories. Of
course, this information is provided on the Web. The IETF's URL
is:
http://www.ietf.org/
2. The minutes of the IESG teleconferences be found on all the IETF
shadow directories in the iesg directory.
The following IESG minutes have been added:
February 20, 1997 (iesg.97-02-20)
March 6, 1997 (iesg.97-03-06)
3. The IESG approved or recommended the following two Protocol
Actions during the month of March:
o XDR: External Data Representation Standard for publication as a
Draft Standard.
o Basic Socket Interface Extensions for IPv6 for publication as
an Informational RFC.
IMR Editor [Page 3]
Internet Monthly Report March 1997
4. 19 Last Calls were issued by the IESG during the month of March:
o The Internet IP Security Domain of Interpretation for ISAKMP
<draft-ietf-ipsec-ipsec-doi-02> for consideration as a Proposed
Standard.
o A MIME body part for ODA <draft-ietf-mixer-oda-01> for
consideration as an Experimental Protocol.
o Internet Security Association and Key Management Protocol
(ISAKMP) <draft-ietf-ipsec-isakmp-07> for consideration as a
Proposed Standard.
o Best Current Practice for the Internet White Pages Service
<draft-ietf-ids-ds-bcp-02> for consideration as a Best Current
Practices RFC.
o The resolution of ISAKMP with Oakley
<draft-ietf-ipsec-isakmp-oakley-03> for consideration as a
Proposed Standard.
o URN Syntax <draft-ietf-urn-syntax-04> for consideration as a
Proposed Standard.
o A MIME body part for FAX <draft-ietf-mixer-fax-01> for
consideration as a Proposed Standard.
o The Interfaces Group MIB <draft-ietf-ifmib-mib-05> for
consideration as a Draft Standard.
o IMAP4 IDLE command <draft-leiba-imap-idle-01> for consideration
as a Proposed Standard.
o X.400 image body parts <draft-ietf-mixer-images-01> for
consideration as a Proposed Standard.
o Generic Packet Tunneling in IPv6 Specification
<draft-ietf-ipngwg-ipv6-tunnel-07> for consideration as a
Proposed Standard.
o Carrying PostScript in X.400 and MIME
<draft-ietf-mixer-postscript-01> for consideration as a
Proposed Standard.
o Generic Routing Encapsulation (GRE) <RFC1701> for consideration
as a Proposed Standard.
IMR Editor [Page 4]
Internet Monthly Report March 1997
o Generic Routing Encapsulation over IPv4 networks <RFC1702> for
consideration as a Proposed Standard.
o MIXER (Mime Internet X.400 Enhanced Relay): Mapping between
X.400 and RFC 822/MIME <draft-kille-mixer-rfc1327bis-05> for
consideration as a Proposed Standard.
o SMTP Service Extension for Command Pipelining
<draft-freed-smtp-pipeline-01> for consideration as a Draft
Standard.
o Mapping between X.400 and RFC-822/MIME Message Bodies
<draft-ietf-mixer-bodymap-06> for consideration as a Proposed
Standard.
o Definitions of Managed Objects for APPN
<draft-ietf-snanau-appnmib-04> for consideration as a Proposed
Standard.
o TCP and UDP over IPv6 Jumbograms <draft-borman-jumbograms-01>
for consideration as a Proposed Standard.
5. Five new working groups were created:
Telnet TN3270 Enhancements (tn3270e)
WWW Distributed Authoring and Versioning (webdav)
Internet Printing Protocol (ipp)
Multiprotocol Label Switching (mpls)
SNMP Version 3 (snmpv3)
6. There were 322 Internet-Draft Actions during the month of March:
(ion) o NBMA Next Hop Resolution Protocol (NHRP)
<draft-ietf-rolc-nhrp-11.txt>
(svrloc) o Service Location Protocol
<draft-ietf-svrloc-protocol-16.txt>
(idmr) o IP Multicast Routing MIB
<draft-ietf-idmr-multicast-routmib-05.txt>
(idmr) o Protocol Independent Multicast MIB
<draft-ietf-idmr-pim-mib-03.txt>
(idmr) o Core Based Trees (CBT) Multicast -- Protocol
Specification -- <draft-ietf-idmr-cbt-spec-07.txt>
(cat) o Independent Data Unit Protection Generic Security
Service Application Program Interface
(IDUP-GSS-API) <draft-ietf-cat-idup-gss-07.txt>
IMR Editor [Page 5]
Internet Monthly Report March 1997
(wts) o The Secure HyperText Transfer Protocol
<draft-ietf-wts-shttp-04.txt>
(dhc) o Dynamic Host Configuration Protocol for IPv6
(DHCPv6) <draft-ietf-dhc-dhcpv6-09.txt>
(pppext) o The PPP Internet Protocol Control Protocol (IPCP)
<draft-ietf-pppext-ipcp-network-01.txt>
(ion) o NHRP Protocol Applicability Statement
<draft-ietf-ion-nhrp-appl-01.txt>
(cat) o Public Key Cryptography for Initial Authentication
in Kerberos
<draft-ietf-cat-kerberos-pk-init-03.txt>
(cat) o Generic Security Service API Version 2 : C-bindings
<draft-ietf-cat-gssv2-cbind-04.txt>
(none) o OSPF with Digital Signatures
<draft-murphy-ospf-signature-03.txt>
(mmusic) o SDP: Session Description Protocol
<draft-ietf-mmusic-sdp-03.txt, .ps>
(none) o Tunneling SSL Through a WWW Proxy
<draft-luotonen-ssl-tunneling-03.txt>
(mixer) o MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME
<draft-kille-mixer-rfc1327bis-05.txt>
(none) o Common NNTP Extensions
<draft-barber-nntp-imp-06.txt>
(idmr) o Core Based Trees (CBT) Multicast Routing
Architecture <draft-ietf-idmr-cbt-arch-04.txt>
(cat) o Simple GSS-API Negotiation Mechanism
<draft-ietf-cat-snego-03.txt>
(atommib) o Definitions of Textual Conventions and
OBJECT-IDENTITIES for ATM Management
<draft-ietf-atommib-atm2TC-06.txt>
(ssh) o Site Security Handbook
<draft-ietf-ssh-handbook-04.txt>
(idmr) o Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification
<draft-ietf-idmr-pim-sm-spec-10.txt, .ps>
(grip) o Expectations for Security Incident Response
<draft-ietf-grip-framework-irt-04.txt>
(drums) o Simple Mail Transfer Protocol
<draft-ietf-drums-smtpupd-04.txt>
(none) o The META Tag of HTML
<draft-musella-html-metatag-03.txt>
(madman) o Mail Monitoring MIB
<draft-ietf-madman-mail-monitor-mib-03.txt>
(madman) o Network Services Monitoring MIB
<draft-ietf-madman-nsm-mib-04.txt>
(ids) o A Common Schema for the Internet White Pages
Service <draft-ietf-ids-iwps-schema-spec-04.txt>
IMR Editor [Page 6]
Internet Monthly Report March 1997
(cat) o Extended Generic Security Service APIs: XGSS-APIs
Access control and delegation extensions
<draft-ietf-cat-xgssapi-acc-cntrl-02.txt>
(ion) o Definitions of Managed Objects for Classical IP and
ARP Over ATM Using SMIv2
<draft-ietf-ion-mib-01.txt>
(http) o PEP: an Extension Mechanism for HTTP
<draft-ietf-http-pep-02.txt>
(madman) o LDAP/CLDAP/X.500 Directory Services Monitoring MIB
<draft-ietf-madman-dsa-mib-1-03.txt>
(ospf) o OSPF for IPv6 <draft-ietf-ospf-ospfv6-04.txt>
(hubmib) o Definitions of Managed Objects for IEEE 802.3
Medium Attachment Units (MAUs) using SMIv2
<draft-ietf-hubmib-mau-mib-04.txt>
(pktway) o Proposed Specification for the PacketWay Protocol
<draft-ietf-pktway-protocol-spec-03.txt>
(none) o RSVP Extensions for IPSEC Data Flows
<draft-berger-rsvp-ext-07.txt>
(atommib) o Definitions of Tests for ATM Management
<draft-ietf-atommib-test-02.txt>
(applmib) o Definitions of System-Level Managed Objects for
Applications <draft-ietf-applmib-sysapplmib-07.txt>
(dhc) o Interaction between DHCP and DNS
<draft-ietf-dhc-dhcp-dns-03.txt>
(none) o The "data" URL scheme
<draft-masinter-url-data-03.txt>
(dhc) o An option for FQDNs in DHCP options
<draft-ietf-dhc-fqdn-opt-02.txt>
(wts) o Security Extensions For HTML
<draft-ietf-wts-shtml-03.txt>
(dhc) o Extensions for DHCPv6
<draft-ietf-dhc-v6exts-05.txt>
(dnsind) o Clarifications to the DNS Specification
<draft-ietf-dnsind-clarify-07.txt>
(pkix) o Internet Public Key Infrastructure Part I: X.509
Certificate and CRL Profile
<draft-ietf-pkix-ipki-part1-04.txt>
(dnssec) o Detached Domain Name System Information
<draft-ietf-dnssec-ddi-02.txt>
(http) o Transparent Content Negotiation in HTTP
<draft-ietf-http-negotiation-01.txt>
(pppext) o PPP LCP Extensions
<draft-ietf-pppext-lcpext-ds-01.txt>
(ion) o ATM Signalling Support for IP over ATM - UNI 4.0
Update <draft-ietf-ion-sig-uni4.0-02.txt>
(asid) o Lightweight Directory Access Protocol (v3)
<draft-ietf-asid-ldapv3-protocol-04.txt>
IMR Editor [Page 7]
Internet Monthly Report March 1997
(asid) o Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions
<draft-ietf-asid-ldapv3-attributes-04.txt>
(drums) o Augmented BNF for Syntax Specifications: ABNF
<draft-ietf-drums-abnf-02.txt>
(snanau) o Definitions of Managed Objects for APPN
<draft-ietf-snanau-appnmib-04.txt>
(idmr) + Core Based Tree (CBT) Multicast Border Router
Specification for Connecting a CBT Stub Region to a
DVMRP Backbone <draft-ietf-idmr-cbt-dvmrp-00.txt>
(ion) + Transient Neighbors for IPv6 over ATM
<draft-ietf-ion-tn-00.txt>
(avt) o RTP Payload Format for H.263 Video Streams
<draft-ietf-avt-rtp-payload-03.txt>
(asid) o vCard MIME Directory Profile
<draft-ietf-asid-mime-vcard-02.txt>
(none) o Message Submission and Relay
<draft-gellens-submit-04.txt>
(acap) o ACAP -- Application Configuration Access Protocol
<draft-ietf-acap-spec-03.txt>
(rsvp) o RSVP Extensions for Policy Control
<draft-ietf-rsvp-policy-ext-02.txt, .ps>
(issll) o Providing integrated services over low-bitrate
links <draft-ietf-issll-isslow-01.txt>
(pppext) o PPP Vendor Extensions
<draft-ietf-pppext-vendor-01.txt>
(roamops) o Dialup Roaming Requirements
<draft-ietf-roamops-roamreq-03.txt>
(issll) o IP Integrated Services with RSVP over ATM
<draft-ietf-issll-atm-support-03.txt, .ps>
(urn) o Resolution of Uniform Resource Identifiers using
the Domain Name System
<draft-ietf-urn-naptr-04.txt>
(issll) o Interoperation of Controlled-Load and
Guaranteed-Service with ATM
<draft-ietf-issll-atm-mapping-02.txt>
(none) o RTP Payload for Redundant Audio Data
<draft-perkins-rtp-redundancy-03.txt>
(none) + A Common Internet File System (CIFS/1.0) Protocol
Preliminary Draft <draft-leach-cifs-v1-spec-00.txt>
(agentx) o Agent Extensibility (AgentX) Protocol Version 1
<draft-ietf-agentx-ext-pro-02.txt>
(asid) o Lightweight Directory Access Protocol: Extensions
for Dynamic Directory Services
<draft-ietf-asid-ldapv3ext-03.txt>
(none) o SMTP Service Extension for Command Pipelining
<draft-freed-smtp-pipeline-01.txt>
IMR Editor [Page 8]
Internet Monthly Report March 1997
(none) o SBM (Subnet Bandwidth Manager): A Proposal for
Admission Control over Ethernet
<draft-yavatkar-sbm-ethernet-03.txt>
(none) o Compression Payload for Use with IP Security
<draft-thayer-seccomp-01.txt>
(oncrpc) o RPCSEC_GSS Protocol Specification
<draft-ietf-oncrpc-rpcsec_gss-03.txt>
(none) o Dedicated Token Ring Interface MIB
<draft-warwick-tokenring-01.txt>
(ediint) o Requirements for Inter-operable Internet EDI
<draft-ietf-ediint-req-02.txt>
(asid) o Lightweight Directory Access Protocol (v3): UTF-8
String Representation of Distinguished Names
<draft-ietf-asid-ldapv3-dn-02.txt>
(none) o Dedicated Token Ring Concentrator MIB
<draft-warwick-tokenring-arch-01.txt>
(stdguide) o Guide for Internet Standards Writers
<draft-ietf-stdguide-ops-02.txt>
(bmwg) o Benchmarking Terminology for LAN Switching Devices
<draft-ietf-bmwg-lanswitch-04.txt>
(dhc) o DHCP Options for Service Location Protocol
<draft-ietf-dhc-slp-01.txt>
(none) o Ruby in the Hypertext Markup Language
<draft-duerst-ruby-01.txt>
(aft) + Challenge-Handshake Authentication Protocol for
SOCKS V5 <draft-ietf-aft-socks-chap-00.txt>
(ripv2) o RIP Version 2 Carrying Additional Information
<draft-ietf-ripv2-protocol-v2-02.txt>
(pppext) o Layer Two Tunneling Protocol "L2TP"
<draft-ietf-pppext-l2tp-03.txt>
(none) o ST2+ over ATM Protocol Specification - UNI 3.1
Version <draft-suzuki-st2-over-atm-01.txt>
(issll) o The Multi-Class Extension to Multi-Link PPP
<draft-ietf-issll-isslow-mcml-01.txt>
(issll) o A Framework for Providing Integrated Services Over
Shared and Switched LAN Technologies
<draft-ietf-issll-is802-framework-01.txt>
(none) o EARTH - EAsy IP multicast Routing THrough ATM
clouds <draft-smirnov-ion-earth-02.txt>
(none) o IMAP URL Scheme <draft-newman-url-imap-06.txt>
(none) o FTP Extensions for Variable Protocol Specification
<draft-allman-ftp-variable-04.txt>
(none) o MIME Parameter Value and Encoded Word Extensions:
Character Sets, Languages, and Continuations
<draft-freed-pvcsc-02.txt>
(none) o A Mail-Safe Transformation Format of Unicode
<draft-goldsmith-utf7-02.txt>
IMR Editor [Page 9]
Internet Monthly Report March 1997
(none) o Advanced Sockets API for IPv6
<draft-stevens-advanced-api-02.txt>
(ediint) o MIME-based Secure EDI
<draft-ietf-ediint-as1-03.txt>
(http) o Simple Hit-Metering and Usage-Limiting for HTTP
<draft-ietf-http-hit-metering-02.txt>
(frnetmib) o Management Information Base for Frame Relay Data
Compression <draft-ietf-frnetmib-dcp-01.txt>
(urn) o URN Syntax <draft-ietf-urn-syntax-04.txt>
(none) o Internet Cache Protocol (ICP), version 2
<draft-wessels-icp-v2-01.txt>
(roamops) o The Network Access Identifier
<draft-ietf-roamops-nai-02.txt>
(asid) o Use of Language Codes in LDAPv3
<draft-ietf-asid-ldapv3-lang-01.txt>
(none) o The Report of the IAB Character Set Workshop held
29 February - 1 March, 1996
<draft-weider-iab-char-wrkshop-01.txt>
(none) o Interoperability Rules for Multicast Routing
Protocols <draft-thaler-multicast-interop-01.txt>
(none) o Uniform Resource Locators (URL): Generic Syntax and
Semantics <draft-fielding-url-syntax-04.txt>
(dhc) o The User Class Option for DHCP
<draft-ietf-dhc-userclass-01.txt>
(bmwg) o Terminology for Cell/Call Benchmarking
<draft-ietf-bmwg-call-01.txt>
(ftpext) + MLST Command and Extensions to FTP
<draft-ietf-ftpext-mlst-00.txt>
(ipsec) o The Internet IP Security Domain of Interpretation
for ISAKMP <draft-ietf-ipsec-ipsec-doi-02.txt>
(none) o Transmission of IPv6 over IPv4 Domains without
Explicit Tunnels
<draft-carpenter-ipng-6over4-02.txt>
(none) o Label Switching: Label Stack Encodings
<draft-rosen-tag-stack-01.txt>
(none) o PF_KEY Key Management API, Version 2
<draft-mcdonald-pf-key-v2-01.txt>
(radius) o Implementation of Mandatory Tunneling via RADIUS
<draft-ietf-radius-tunnel-imp-01.txt>
(none) o The Kitchen Sink Resource Record
<draft-eastlake-kitchen-sink-01.txt>
(ftpext) o Internationalization of the File Transfer Protocol
<draft-ietf-ftpext-intl-ftp-01.txt>
(ipp) + Requirements for an Internet Printing Protocol
<draft-ietf-ipp-req-00.txt>
(dhc) o An Inter-server Protocol for DHCP
<draft-ietf-dhc-interserver-01.txt>
IMR Editor [Page 10]
Internet Monthly Report March 1997
(none) o A Simple IP Security API Extension to BSD Sockets
<draft-mcdonald-simple-ipsec-api-01.txt>
(frnetmib) o Definitions of Managed Objects for Frame Relay
Service <draft-ietf-frnetmib-frs-mib-01.txt>
(ids) o Naming Plan for an Internet Directory Service
<draft-ietf-ids-dirnaming-01.txt>
(disman) o Definitions of Managed Objects for the Delegation
of Management Scripts
<draft-ietf-disman-script-mib-01.txt>
(urn) o Requirements and a Framework for URN Resolution
Systems <draft-ietf-urn-req-frame-01.txt>
(rtfm) o Real Time Flow Measurement Working Group - New
Attributes for Traffic Flow Measurement
<draft-ietf-rtfm-new-traffic-flow-01.txt>
(svrloc) o An API for Service Location
<draft-ietf-svrloc-api-01.txt>
(ipsec) o Inline Keying within the ISAKMP Framework.
<draft-ietf-ipsec-inline-isakmp-01.txt>
(none) o Architecture of the Resource Reservation Service
for the Commercial Internet
<draft-suzuki-res-resv-svc-arch-01.txt>
(cat) o Public Key Cryptography for Cross-Realm
Authentication in Kerberos
<draft-ietf-cat-kerberos-pk-cross-01.txt>
(lsma) o Limitations of Internet Protocol Suite for
Distributed Simulation in the Large Multicast
Environment <draft-ietf-lsma-limitations-01.txt>
(none) + Virtual Router Redundancy Protocol
<draft-hinden-vrrp-00.txt>
(applmib) o Application Management MIB
<draft-ietf-applmib-mib-02.txt>
(rps) o Routing Policy Specification Language (RPSL)
<draft-ietf-rps-rpsl-01.txt>
(applmib) o Definitions of Managed Objects for WWW Servers
<draft-ietf-applmib-wwwmib-02.txt>
(radius) o RADIUS Attributes for Tunnel Protocol Support
<draft-ietf-radius-tunnel-auth-01.txt>
(none) o LZS Payload Compression Transform for ESP
<draft-sabin-lzs-payload-01.txt>
(none) o RMFP: A Reliable Multicast Framing Protocol
<draft-crowcroft-rmfp-01.txt>
(none) o Simple Unified Networking <draft-ohta-sun-01.txt>
(mmusic) o Real Time Streaming Protocol (RTSP)
<draft-ietf-mmusic-rtsp-02.txt, .ps>
(printmib) o Printer MIB <draft-ietf-printmib-mib-info-01.txt>
(none) o Securing FTP with TLS
<draft-murray-auth-ftp-ssl-01.txt>
IMR Editor [Page 11]
Internet Monthly Report March 1997
(asid) o Architecture of the WHOIS++ service
<draft-ietf-asid-whoispp-01.txt>
(find) o A Tagged Index Object for use in the Common
Indexing Protocol <draft-ietf-find-cip-ldap-01.txt>
(bmwg) o A One-way Delay Metric for IPPM
<draft-ietf-bmwg-ippm-delay-01.txt>
(none) o Key Derivation for Authentication, Integrity, and
Privacy <draft-horowitz-key-derivation-01.txt>
(avt) o Compressing IP/UDP/RTP Headers for Low-Speed Serial
Links <draft-ietf-avt-crtp-02.txt>
(tls) o The TLS Protocol Version 1.0
<draft-ietf-tls-protocol-02.txt>
(none) o Selectively Reliable Transport Protocol
<draft-laviano-srtp-01.txt>
(bmwg) o Terminology for IP Multicast Benchmarking
<draft-ietf-bmwg-mcast-01.txt>
(mmusic) o SIP: Session Initiation Protocol
<draft-ietf-mmusic-sip-02.txt, .ps>
(none) o Telnet Comport Control Option
<draft-clark-telnet-control-01.txt>
(harts) o Humanities and Arts: Sharing Center Stage on the
Internet <draft-ietf-harts-guide-01.txt>
(ipngwg) o IP Version 6 over PPP
<draft-ietf-ipngwg-ipv6-over-ppp-01.txt>
(none) o Multiprotocol Extensions for BGP-4
<draft-bates-bgp4-multiprotocol-01.txt>
(ipsec) + Implementation of Virtual Private Network (VPNs)
with IP Security <draft-ietf-ipsec-vpn-00.txt>
(mboned) o Introduction to IP Multicast Routing
<draft-ietf-mboned-intro-multicast-02.txt>
(none) o Guidelines and Process for new URL Schemes
<draft-masinter-url-process-01.txt>
(none) o The mailto URL scheme
<draft-hoffman-mailto-url-01.txt>
(dnsind) o Negative Caching of DNS Queries (DNS NCACHE)
<draft-ietf-dnsind-ncache-03.txt>
(radius) o Extensible Authentication Protocol Support in
RADIUS <draft-ietf-radius-eap-01.txt>
(http) o Use and interpretation of HTTP version numbers
<draft-ietf-http-versions-01.txt>
(otp) o A One-Time Password System <draft-ietf-otp-01.txt>
(mobileip) o Reverse Tunneling for Mobile IP
<draft-ietf-mobileip-tunnel-reverse-02.txt>
(calsch) o Internet Calendaring and Scheduling Core Object
Specification (iCalendar)
<draft-ietf-calsch-ical-01.txt>
IMR Editor [Page 12]
Internet Monthly Report March 1997
(ipngwg) o Management Information Base for IP Version 6:
Textual Conventions and General Group
<draft-ietf-ipngwg-ipv6-mib-01.txt>
(ipngwg) o Management Information Base for IP Version 6: UDP
and TCP Groups
<draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt>
(ipngwg) o Management Information Base for IP Version 6:
ICMPv6 Group
<draft-ietf-ipngwg-ipv6-icmp-mib-01.txt>
(none) o Extensions for Distributed Authoring and Versioning
on the World Wide Web -- WEBDAV
<draft-jensen-webdav-ext-01.txt>
(http) o HTTP Remote Variant Selection Algorithm -- RVSA/1.0
<draft-ietf-http-rvsa-v10-01.txt>
(mboned) o Some Issues for an Inter-domain Multicast Routing
Protocol
<draft-ietf-mboned-imrp-some-issues-01.txt>
(pppext) + Mobile IPv4 Configuration Option for PPP IPCP
<draft-ietf-pppext-ipcp-mip-00.txt>
(none) o Clearing the Traffic Jam at Internet Servers A
Network Layer View Of Network Traffic Consolidation
<draft-mansigian-ntc-intro-01.txt>
(mixer) o Use of an X.500/LDAP directory to support MIXER
address mapping <draft-ietf-mixer-directory-01.txt>
(asid) o LDAP Control Extension for Simple Paged Results
Manipulation
<draft-ietf-asid-ldapv3-simplepaged-01.txt>
(roamops) o The Roaming Relationship (REL) Resource Record in
the DNS <draft-ietf-roamops-dnsrr-03.txt>
(none) o Distributed Search Management Protocol
<draft-floyd-distributed-search-01.txt>
(none) o Zone KEY RRSet Signing Procedure
<draft-lewis-dnskey-handling-01.txt>
(roamops) o The Accounting Problem in Roaming
<draft-ietf-roamops-actng-02.txt>
(asid) + Lightweight Directory Access Protocol: Schema for
Storing RPC Entries in a Directory Service
<draft-ietf-asid-ldap-rpcschema-00.txt>
(none) + Extended Path MTU Discovery for IP version 6
<draft-sanghi-pmtudisc-ext-00.txt>
(none) + Usage of H.323 on the Internet
<draft-rfced-info-lantz-00.txt>
(none) + Practical Approach to Improving Scalability and
Interoperability of SNMP Applications
<draft-rfced-info-romanov-00.txt>
(none) + Definitions of Managed Objects for IEEE 802.1q
Virtual LAN Bridges
<draft-jeya-vlan-8021q-mib-00.txt>
IMR Editor [Page 13]
Internet Monthly Report March 1997
(none) o IMAP4 IDLE command <draft-leiba-imap-idle-01.txt>
(none) + Encapsulating IP with the Small Computer System
Interface <draft-rfced-exp-elliston-00.txt>
(none) + A Proposal for Internet and Public Switched
Telephone Networks (PSTN) Internetworking
<draft-faynberg-telephone-sw-net-00.txt>
(none) o Semantics of DNS NXT Resource Records
<draft-lewis-dnsnxt-semantics-01.txt>
(none) + VIPRE -- Virtual Internet Packet Relay An
Encapsulation Architecture for Unidirectional Links
<draft-stepanek-vipre-00.txt>
(ripv2) + RIP-II MD5 Authentication
<draft-ietf-ripv2-md5-auth-00.txt>
(cat) + Kerberos Change Password Protocol
<draft-ietf-cat-kerb-chg-password-00.txt>
(none) + APPN Implementer's Workshop Closed Pages Document
<draft-rfced-info-bryant-00.txt>
(rtfm) + Traffic Flow Measurement: Meter MIB
<draft-ietf-rtfm-meter-mib-00.txt>
(find) + CIP Index Object Format for SOIF Objects
<draft-ietf-find-cip-soif-00.txt>
(none) + Point-to-point Link Assembly for Simple Multiple
Access (PLASMA) <draft-fujikawa-plasma-00.txt>
(rsvp) + Designing Tunnels for Interoperability with RSVP
<draft-ietf-rsvp-tunnels-interop-00.txt>
(none) + Update of Korean Character Encoding for Internet
Messages <draft-rfced-info-kim-00.txt>
(pppext) + Semi Connected Mode for PPP links
<draft-ietf-pppext-scm-00.txt>
(none) + Scalable support for multi-homed multi-provider
connectivity <draft-bates-multihoming-00.txt>
(none) + Returning Values from Forms: multipart/form-data
<draft-masinter-form-data-00.txt>
(spki) o Simple Public Key Certificate
<draft-ietf-spki-cert-structure-01.txt>
(spki) + SPKI Requirements <draft-ietf-spki-cert-req-00.txt>
(run) + DON'T SPEW A Set of Guidelines for Mass Unsolicited
Mailings and Postings <draft-ietf-run-spew-00.txt>
(fax) + File Format for Internet Fax
<draft-ietf-fax-tiffplus-00.txt>
(http) + Problem with HTTP/1.1 Warning header, and proposed
fix <draft-ietf-http-warning-00.txt>
(http) + HTTP State Management Mechanism (Rev1)
<draft-ietf-http-state-man-mec-00.txt, .ps>
(none) + Reliable Multicast Transport Protocol
<draft-shiroshita-rmtp-spec-00.txt>
(http) + The User Agent Hint Response Header
<draft-ietf-http-uahint-00.txt>
IMR Editor [Page 14]
Internet Monthly Report March 1997
(pkix) + Internet Public Key Infrastructure Part 2:
Operational Protocols
<draft-ietf-pkix-ipki2opp-00.txt>
(rsvp) + Open Outsourcing Policy Service (OOPS) for RSVP
<draft-ietf-rsvp-policy-oops-00.txt, .ps>
(none) + Wildcards in the Accept-Charset Header
<draft-holtman-http-wildcards-00.txt>
(radius) o RADIUS Server MIB
<draft-ietf-radius-servmib-02.txt>
(aft) + Challenge-Response Authentication Method for SOCKS
V5 <draft-ietf-aft-socks-cram-00.txt>
(rip) + RIP Version 2 MIB Extension
<draft-ietf-rip-mib-00.txt>
(aft) + Secure Sockets Layer for SOCKS Version 5
<draft-ietf-aft-socks-ssl-00.txt>
(ipsec) + HMAC-SHA-1-96 IP Authentication with Replay
Prevention
<draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt>
(dhc) + Multicast address allocation extensions options
<draft-ietf-dhc-multopt-00.txt>
(dhc) + Multicast address allocation extensions to the
Dynamic Host Configuration Protocol
<draft-ietf-dhc-mdhcp-00.txt>
(asid) + LDAP Multi-master Replication Protocol
<draft-ietf-asid-ldap-mult-mast-rep-00.txt>
(none) + IMAP4 ID extension <draft-showalter-imap-id-00.txt>
(none) + QoS Path Management with RSVP
<draft-guerin-qospath-mgmt-rsvp-00.txt>
(ipsec) + HMAC-MD5-96 IP Authentication with Replay
Prevention <draft-ietf-ipsec-ah-hmac-md5-96-00.txt>
(ftpext) + REST Command and Extensions to FTP
<draft-ietf-ftpext-restart-00.txt>
(none) + DIAMETER Authentication Extensions
<draft-calhoun-diameter-authent-00.txt>
(none) + DIAMETER <draft-calhoun-diameter-00.txt>
(none) + DIAMETER Extensible Authentication Protocol Support
<draft-calhoun-diameter-eap-00.txt>
(ipngwg) + Transmission of IPv6 Packets over Ethernet Networks
<draft-ietf-ipngwg-trans-ethernet-00.txt>
(dhc) + DSCP: Dynamic Subnet Configuration Protocol
<draft-ietf-dhc-dyn-subnet-conf-00.txt>
(ipngwg) + Transmission of IPv6 Packets over FDDI Networks
<draft-ietf-ipngwg-trans-fddi-net-00.txt>
(radius) o RADIUS Client MIB
<draft-ietf-radius-clientmib-01.txt>
(poisson) + IETF Working Group Guidelines and Procedures
<draft-ietf-poisson-wg-guide-00.txt>
IMR Editor [Page 15]
Internet Monthly Report March 1997
(none) + Internet Public Key Infrastructure: Web-based
Certificate and CRL Repository
<draft-kikuchi-web-cert-repository-00.txt>
(none) + SMTP Service Extension for Secure SMTP over TLS
<draft-hoffman-smtp-ssl-00.txt>
(none) + Simple Integrated Media Access (SIMA)
<draft-kalevi-simple-media-access-00.txt, .ps>
(none) + Test Cases for HMAC-MD5 and HMAC-SHA-1
<draft-cheng-hmac-test-cases-00.txt>
(none) + ARTICLES OF INCORPORATION OF INTERNET SOCIETY
<draft-bradner-isoc-incorp-00.txt>
(bmwg) + A Packet Loss Metric for IPPM
<draft-ietf-bmwg-ippm-loss-00.txt>
(dhc) + The Server Selection Option for DHCP
<draft-ietf-dhc-sso-00.txt>
(dhc) + The Server Identification Option for DHCP
<draft-ietf-dhc-sio-00.txt>
(none) + The Use of URLs as Meta-Syntax for Core Mail List
Commands and their Transport through Message Header
Fields <draft-baer-listspec-00.txt>
(none) + IMAP4 Implementation Practice
<draft-gahrns-imap-practice-00.txt>
(ipngwg) + Synthesis of Routing Goop and AAAA Records in IPv6
<draft-ietf-ipngwg-dns-rr-rgadd-00.txt>
(none) + Realizing the Benefits of Virtual LANs by Using
IPv6 <draft-kurz-virtual-lans-benefits-00.txt>
(none) + Host Reachability Advertisement for IPv6
<draft-mccann-ipv6-hra-00.txt>
(none) + Internet Society By-Laws
<draft-bradner-isoc-by-laws-00.txt>
(none) + Header Compression for IPv6 over PPP
<draft-engan-ipv6-hc-00.txt>
(none) + Recommendations on Queue Management and Congestion
Avoidance in the Internet
<draft-irtf-e2e-queue-mgt-00.txt, .ps>
(pier) + IP Addresses in Applications
<draft-ietf-pier-applications-00.txt>
(none) + RSVP over ATM Implementation Guidelines
<draft-ietf-issll-atm-imp-guide-00.txt, .ps>
(ospf) + The OSPF NSSA Option
<draft-ietf-ospf-nssa-update-00.txt>
(none) + HTTP 1.1 as a Transport for the Internet Printing
Protocol <draft-turner-ipp-trans-develop-00.txt>
(qosr) + A Framework for QoS-based Routing in the Internet
<draft-ietf-qosr-framework-00.txt>
(none) + S/MIME Message Specification
<draft-dusse-smime-msg-00.txt>
IMR Editor [Page 16]
Internet Monthly Report March 1997
(none) + S/MIME Certificate Handling
<draft-dusse-smime-cert-00.txt>
(pppext) + Proposal for a PPP Network Layer Entity Selection
Protocol <draft-ietf-pppext-nles-00.txt>
(rps) + A strategy for the transition from RIPE-181 to RPSL
<draft-ietf-rps-transition-00.txt>
(none) + RIDE classes <draft-kessens-ride-classes-00.txt>
(ipngwg) + IP Version 6 Addressing Architecture
<draft-ietf-ipngwg-ipv6-arch-00.txt>
(none) o QoS Routing Mechanismsand OSPFExtensions
<draft-guerin-qos-routing-ospf-01.txt>
(pkix) + Internet Public Key Infrastructure Part IV:
Certificate Policy and Certification Practices
Framework <draft-ietf-pkix-ipki-part4-00.txt>
(cat) + Integrity Protection for the Kerberos Error Message
<draft-ietf-cat-kerberos-err-msg-00.txt>
(pppext) + PPP over AAL5 and FUNI
<draft-ietf-pppext-aal5-funi-00.txt>
(secsh) + SSH Transport Layer Protocol
<draft-ietf-secsh-transport-00.txt>
(secsh) + SSH Authentication Protocol
<draft-ietf-secsh-userauth-00.txt>
(secsh) + Connect <draft-ietf-secsh-connect-00.txt>
(http) + HTTP Connection Management
<draft-ietf-http-connection-00.txt>
(asid) + The LDAP URL Format
<draft-ietf-asid-ldapv3-url-00.txt>
(avt) + Real-Time Transport Protocol Management Information
Base <draft-ietf-avt-rtp-mib-00.txt>
(asid) + The String Representation of LDAP Search Filters
<draft-ietf-asid-ldapv3-filter-00.txt>
(none) + Internet Printing Protocol/1.0: Security
<draft-debry-ipp-sec-00.txt>
(mboned) + Multicast Debugging Handbook
<draft-ietf-mboned-mdh-00.txt>
(none) + Age Header Field in HTTP/1.1
<draft-fielding-http-age-00.txt>
(asid) + LDAP-based Routing of SMTP Messages: Approach Used
by Netscape
<draft-ietf-asid-email-routing-ns-00.txt>
(none) + Using TTLs with Administratively Scoped IP
Multicast Addresses
<draft-finlayson-ttl-admin-scope-00.txt>
(roamops) + The Authentication and Authorization Problem in
Roaming <draft-ietf-roamops-auth-00.txt>
(none) + Requirements for Unreliable Multicasting of Web
Resources <draft-aboba-unweb-00.txt>
IMR Editor [Page 17]
Internet Monthly Report March 1997
(none) + The Receiver-Initiated Shortcut Path Protocol
(RISP) <draft-ogawa-receiver-shortcut-path-00.txt>
(none) + A Stream Cipher Encryption Algorithm
<draft-thayer-cipher-00.txt>
(none) + Implications of the GSE Addressing Scheme to IPv6
Multicast <draft-dupont-ipv6-gse-multicast-00.txt>
(ngtrans) + A proposal for an IPv6 site database object
<draft-ietf-ngtrans-6bone-registry-00.txt>
(none) + Multicast Chat (MCC) Protocol
<draft-hay-mcc-00.txt>
(rps) + Application of Routing Policy Specification
Language (RPSL) on the Internet
<draft-ietf-rps-appl-rpsl-00.txt, .ps>
(tcpimp) + Known TCP Implementation Problems
<draft-ietf-tcpimp-prob-00.txt>
(none) + CIFS Logon and Pass Through Authentication
Preliminary Draft
<draft-leach-cifs-logon-spec-00.txt>
(none) + Physical Topology Terminology
<draft-malachi-topology-terms-00.txt>
(none) + Locating DS Entries by E-mail Address Preliminary
Draft <draft-leach-asid-ds-email-00.txt>
(none) + CIFS Printing Specification Preliminary Draft
<draft-leach-cifs-print-spec-00.txt>
(none) + CIFS Remote Administration Protocol Preliminary
Draft <draft-leach-cifs-rap-spec-00.txt>
(issll) + PPP in a real-time oriented HDLC-like framing
<draft-ietf-issll-isslow-rtf-00.txt>
(none) + ARIS: Aggregate Route-Based IP Switching
<draft-viswanathan-aris-overview-00.txt>
(none) + Physical Topology MIB and Discovery Protocol
Proposal <draft-bierman-ptopo-mib-proto-00.txt>
(none) + ARIS Specification <draft-feldman-aris-spec-00.txt>
(ipp) + Internet Printing Protocol/1.0: Model and Semantics
<draft-ietf-ipp-model-00.txt>
(aft) + SOCKS Protocol Version 5
<draft-ietf-aft-socks-pro-v5-00.txt>
(ipp) + Internet Printing Protocol/1.0: Directory Schema
<draft-ietf-ipp-dir-schema-00.txt>
(none) + Directory Entries From Email Address
<draft-greenblatt-defema-00.txt>
(dhc) + Security Architecture for DHCP
<draft-ietf-dhc-security-arch-00.txt>
(none) + Soft State Switching A Proposal to Extend RSVP for
Switching RSVP Flows
<draft-viswanathan-aris-rsvp-00.txt>
(none) + CIFS/E Browser Protocol Preliminary Draft
<draft-leach-cifs-browser-spec-00.txt>
IMR Editor [Page 18]
Internet Monthly Report March 1997
(asid) + X.500 Strong Authentication Mechanisms for LDAPv3
<draft-ietf-asid-ldapv3-strong-00.txt>
(asid) + LDAP-based Routing of SMTP Messages: Approach at
Stanford University
<draft-ietf-asid-email-routing-su-00.txt>
(mobileip) + Firewall Traversal for Mobile IP: Guidelines for
Firewalls and Mobile IP entities
<draft-ietf-mobileip-firewall-trav-00.txt>
(mmusic) + Specification of Security in SAP Using Public Key
Algorithms <draft-ietf-mmusic-sap-sec-00.txt>
(asid) + A Summary of the X.500(93) User Schema for use with
LDAPv3 <draft-ietf-asid-ldapv3schema-x500-00.txt>
(urn) o Namespace Identifier Requirements for URN Services
<draft-ietf-urn-nid-req-01.txt>
(rsvp) + Resource ReSerVation Protocol (RSVP) Version 1
Applicability Statement Some Guidelines on
Deployment <draft-ietf-rsvp-intsrv-analysis-00.txt>
(none) + Compression in IP Security
<draft-monsour-compr-ipsec-00.txt>
(avt) + RTP Profile for Audio and Video Conferences with
Minimal Control <draft-ietf-avt-profile-new-00.txt>
(ipngwg) + IPng Analysis of the GSE Proposal
<draft-ietf-ipngwg-esd-analysis-00.txt>
(none) + Simple Transaction Security (STS)
<draft-tung-transsec-sts-00.txt>
(pppext) + Layer Two Tunneling Protocol (L2TP) over AAL5 and
FUNI <draft-ietf-pppext-l2tp-aal5-funi-00.txt>
(pppext) + PPP CallBack <draft-ietf-pppext-callback-ds-00.txt>
(none) + ARIS Support for LAN Media Switching
<draft-blake-aris-lan-00.txt>
(asid) + A Summary of the Pilot X.500 Schema for use in
LDAPv3 <draft-ietf-asid-schema-pilot-00.txt>
(ipngwg) + Router Renumbering for IPv6
<draft-ietf-ipngwg-router-renum-00.txt>
(none) + Physical Topology Framework
<draft-kjones-ptopo-framework-00.txt>
(none) + The Use of End System Designators in IPv6
<draft-thomas-ipv6-esd-00.txt>
(dnssec) + The DNS Inverse Key Domain
<draft-ietf-dnssec-in-key-00.txt>
(none) + A ``Classy'' Approach to Aggregation for Integrated
Services <draft-berson-classy-approach-00.txt, .ps>
(none) + Locating Native Internet LDAP Servers Preliminary
Draft <draft-leach-asid-ldap-locating-00.txt>
(none) + Interdomain Multicast Routing Support for
Integrated Services Networks
<draft-zappala-multicast-routing-ar-00.txt, .ps>
IMR Editor [Page 19]
Internet Monthly Report March 1997
(none) + A Route Setup Mechanism For Multicast Routing
<draft-zappala-multicast-routing-me-00.txt, .ps>
(ipsec) + IP Encapsulating Security Payload (ESP)
<draft-ietf-ipsec-new-esp-00.txt>
(ipsec) + IP Authentication Header
<draft-ietf-ipsec-new-auth-00.txt>
(urn) + URN Resolution Services
<draft-ietf-urn-resolution-services-00.txt>
(calsch) + Real-time Protocol Requirements
<draft-ietf-calsch-rtreq-00.txt>
7. 17 RFCs were published during this period
RFC2099 I (none) Request for Comments Summary RFC Numbers
2000-2099
RFC2106 I (none) Data Link Switching Remote Access Protocol
RFC2110 PS (mhtml) MIME E-mail Encapsulation of Aggregate
Documents, such as HTML (MHTML)
RFC2111 PS (mhtml) Content-ID and Message-ID Uniform Resource
Locators
RFC2112 PS (mhtml) The MIME Multipart/Related Content-type
RFC2114 I (none) Data Link Switching Client Access Protocol
RFC2118 I (pppext) Microsoft Point-To-Point Compression (MPPC)
Protocol
RFC2119 B (none) Key words for use in RFCs to Indicate
Requirement Levels
RFC2120 E (ids) Managing the X.500 Root Naming Context
RFC2121 I (ion) Issues affecting MARS Cluster Size
RFC2122 PS (none) VEMMI URL Specification
RFC2123 I (rtfm) Traffic Flow Measurement: Experiences with
NeTraMet
RFC2124 I (none) Light-weight Flow Admission Protocol
Specification Version 1.0
RFC2125 PS (pppext) The PPP Bandwidth Allocation Protocol (BAP)
The PPP Bandwidth Allocation Control
Protocol (BACP)
RFC2126 PS (none) ISO Transport Service on top of TCP (ITO)
RFC2127 PS (isdnmib) ISDN Management Information Base
RFC2128 PS (isdnmib) Dial Control Management Information Base
using SMIv2
IMR Editor [Page 20]
Internet Monthly Report March 1997
INTERNET PROJECTS
-----------------
INTERNIC
--------
REGISTRATION SERVICES
Current Status
March:
Email:
Phone: 48651
Updates: 193080
Gopher connections: 18222 retrievals: 20580
WAIS connections: 36532 retrievals: 15926
FTP connections: 90868 retrievals: 178451
Telnet: 67372
Http: 12855124
Whois Queries: 17,102,743
Total Registrations: 98581
Rich Landers <richl at internic.net>
INTERNIC DIRECTORY AND DATABASE SERVICES
The Netfind Seed Database which is used by both Netfind and
WebFinder is up to 1.2 million entries in March. The database
contains information that relates companies with the domain names
they have registered. The information is gathered from various
registration databases around the world. The April seed database
is currently under construction and should have about 1.3 million
entries. The number of entries will fluctuate from time to time
since we periodically check the validity of old entries and delete
those that are no longer good.
In late April we expect our primary server (ds0.internic.net) to
move to a new physical location. The server will be out of
service for a few days during the move, but our other two
production servers (ds1.internic.net and ds2.internic.net) will
be available. Up-to-date information on the planned availability
of the server can be found in the greeting message when you
telnet to the machine.
IMR Editor [Page 21]
Internet Monthly Report March 1997
As has been mentioned in the past, the best way to access our
servers is via the generic name ds.internic.net. This way you
avoid attempting to access a machine that is down.
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories. If you prefer, you can enter
information about your resource in our WWW suggestion form. The
form can be reached through our Directory of Directories Web page
at:
http://ds.internic.net:80/ds/dsdirofdirs.html
by Rick Huber <rvh at ds.internic.net>
THE US DOMAIN REGISTRY
The US Domain has an online registration form available at
http://www.isi.edu/us-domain.
The US Domain administrator no longer makes direct registrations of
hosts, and only makes delegations of third or fourth level domain
names (such as localities).
Some of the processing of the requests to the third level domain
name is now automated. In particular, most requests to register
names in localities already delegated are automatically forwarded
to the administrator of that locality.
A new policy has been added regarding the charges for the domain
name passed on during delegation. The administrator of the
locality has to notify one year in advance before charging for
those domains.
US DOMAIN ADMINISTRATIVE INFORMATION
====================================
EMAIL/FAX 3282
PHONE 400
----------------------------
Total Contacts 3682
IMR Editor [Page 22]
Internet Monthly Report March 1997
DELEGATIONS 148
FORWARDED REQUESTS: 1326
OTHER US DOMAIN MSGS:2208
---------------------------
Total 3682
OTHER US DOMAIN MESSAGES include referrals to other subdomains or
to/from the InterNic, phone calls, modifications, application
requests, discussion and clarification of the requests, questions
about names, resolving technical problems with zone files and name
servers, and whois listings.
MAJOR SUBDOMAINS DELEGATED
K12 CC TEC STATE LIB MUS GEN DST COG
===================================================================
52 38 34 47 39 26 26 10 6
===================================================================
THIRD LEVEL DELEGATIONS
========================
K12.OK.US. K12 Schools, Oklahoma.
DST.MI.US. Districts, Michigan.
GEN.MI.US. General Independent Entities, Michigan.
MUS.MI.US. Museums, Michigan.
COG.MD.US. Councils of Government, Maryland.
LOCALITIES
==========
We delegated 148 localities in Arizona, Alabama, Arkansas,
California, Illinois, Pennsylvania, Florida, Georgia, Hawii, Idaho,
Iowa, Indiana, Kansas, Massachusetts, Maryland, Missouri, Montana,
Michigan, Maine, Nebraska, New Hampshire, North Carolina, North
Dakota, New Jersey, New York, Ohio, Virginia, Vermont, Texas,
Tennessee, Washington and Wyoming this month.
We delegated 1 Native Soverign Nations - SUQUAMISH.NSN.US.
OTHER US DOMAIN DELEGATIONS THIS MONTH
======================================
CI.BELLFLOWER.CA.US. SACPUBLIC.LIB.CA.US.
MANCHESTER.LIB.NH.US. DEVIANT.SAINT-LOUIS.MO.US.
SPY.WASHINGTON.DC.US. CI.GILLETT.WI.US.
MERRIMACK.LIB.NH.US. SALEM.LIB.NH.US.
BEDFORD.LIB.NH.US. DERRY.LIB.NH.US.
IMR Editor [Page 23]
Internet Monthly Report March 1997
MG.GEN.AK.US. CI.ADDISON.TX.US.
STPATRICKS.WASHINGTON.DC.US. TWP.WASHINGTON.NJ.US.
CI.ALCOA.TN.US. FOGGY-BOTTOM.WASHINGTON.DC.US.
CAPITOL-HILL.WASHINGTON.DC.US. PENNSYLVANIA-AVE.WASHINGTON.DC.US.
TOWN.BLOCK-ISLAND.RI.US. CI.VALDESE.NC.US.
MIDDLESEX.CC.MA.US. CONEJO.TEC.CA.US.
EVMWD.DST.CA.US. CI.SANDSTONE.MN.US.
WWW.PLANNING.COG.ID.US. CCCSWA.DST.CA.US.
CI.BEAVERTON.OR.US. TIMBO-LONG-LAKE.MN.US.
-----------------------------------------------------------
URL: http://www.isi.edu/us-domain/
Shanthi Ranganathan (US-Domain at ISI.EDU)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MERIT INTERNET ENGINEERING
--------------------------
This report summarizes March 1997 activities of Merit's Internet
Engineering group on behalf of the Routing Arbiter (RA) service and
other projects.
A reminder for Routing Arbiter Database users: you will get the
fastest turnaround for your database updates by sending them to
auto-dbm at ra.net, which is machine-processed. Only new Maintainer
objects--as well as consulting questions--should go to db-
admin at ra.net, which is read by the RADB support staff.
Route Server Next Generation (RSng) operations are now up and
running at the AADS NAP in Chicago. One Sun Ultra running Solaris
and one DEC Alpha running Digital Unix are in production at the
site. RSng services went into production at the MAE-East
interconnection point in January, and at the Digital Internet
Exchange in February. The Route Servers were developed under the
NSF-supported Routing Arbiter project, a partnership between Merit
and the USC Information Sciences Institute. RSng, a commercial
follow-on activity, makes it possible for exchange point operators
to purchase Route Server services from Merit. For more
information, see:
http://www.rsng.net
IMR Editor [Page 24]
Internet Monthly Report March 1997
The National Science Foundation has awarded Merit and the
University of Michigan a three-year follow-on grant for continued
development of the Multi-Threaded Routing Toolkit. Professor
Farnam Jahanian of the U-M Electrical Engineering and Computer
Science department is now a Co-PI on the project, along with Craig
Labovitz of Merit. MRT, an extensible platform for developing and
debugging routing protocols and routing code, now provides IPv6
support for two additional platforms:
- WIDE IPv6 (hydrangea 970225, BSD/OS 2.1)
- NRL IPv6 (Sep96, NetBSD 1.2)
For more information about MRT, see:
http://www.merit.edu/~mrt/
Susan R. Harris (srh at merit.edu)
UCL
----
Main news is that we have released a new version of the Robust
Audio Tool, and that we are close to completign our translatlantic
link to the CAIRN.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
IANA REPORT
-----------
Here is the IANA March report:
Address Resolution Protocol Parameters 2
Cable Address Blocks 5
Character Sets 1
Country Codes 5
Media Types 6
Port Assignments 33
Protocol Assignments 1
SMI Numbers 1
Josh Elliott (iana at isi.edu)
IMR Editor [Page 25]
Internet Monthly Report March 1997
RFC-EDITOR REPORT
-----------------
This is a summary of Request for Comments Editor activity for the
month of March, 1997:
TIME IN QUEUE
DOCUMENTS New* 30 days 60 days 90 days TOTAL
------------------------------------------------------------------
|
Beginning of |
month 0 9 12 8 | 29
|
New 6 0 0 0 | 6
Processed 2 7 10 0 | 19
------------------------------------------------------------------
End of month 4 2 2 8 | 16
* New RFCs added to queue throughout the month
The Requests for Comments (RFCs) are a series of notes, started in
1969, about the Internet (originally the ARPANET). The notes
discuss many aspects of computing and computer communication
focusing in networking protocols, procedures, programs, and
concepts, but also including meeting notes, opinion, and sometimes
humor. The specification documents of the Internet protocol suite,
as defined by the Internet Engineering Task Force (IETF) and its
steering group (the IESG), are published as RFCs.
RFCs-to-be are edited by the RFC Editor. RFCs enter the RFC
Editor's work queue either by an action of the IESG or by
independent submission. Most independent submissions are referred
to the IESG to check for overlap with IETF work. The IESG might
put a hold on a document to gather more input from its members.
The wait for an RFC to be published varies as there can be
unforeseen complications (typically editorial matters that need
clarification from the author). Documents can be removed from the
publication queue if they are found to be insufficient or incorrect
or if the IESG asks the author to join work already in progress in
the IETF.
Mary Kennedy <rfc-ed at isi.edu>
IMR Editor [Page 26]
Internet Monthly Report March 1997
CALENDAR
--------
Last update 04/01/97
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at ietf.org>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
A copy of this calendar is available as follows:
VIA FTP
-------
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
Africa Address: ftp.is.co.za (196.4.160.12)
cd ietf
ls *0mtg*
WWW
-------
<http://www.ietf.org/home.html> Click on the link for "meetings" and
you should find an entry "listing of other Internet related events".
************************************************************************
1997
-----------
Apr. 2-3 Europia '97 Edinburgh, Scotland
Apr. 7-10 EMA'97 Philadelphia, PA
Apr. 7-11 38th IETF (host by Fed. Exp) Memphis, TN
Apr. 7-11 ANSI X3T11 (Brocade) Palm Springs, CA
Apr. 7-11 IEEE INFOCOM '97 Kobe, Japan
Apr. 7-12 W3C "Accessibility" 6th Int'l Santa Clara, CA
IMR Editor [Page 27]
Internet Monthly Report March 1997
Apr. 9-11 ISADS 97 - 3rd Intl Symposium on
Autonmous Decentralized Sys. Berlin, Germany
Apr. 21-22 1st European Conf on Internet
Voting and Rating Vienna, Austria
Apr. 22-24 DCI's Internet Expo Chicago, IL
Apr. 27-May 2 ATM Forum Chicago, IL
Apr. 28-May 2 HPN'97 (High Performance Net) White Plains, NY
May 5-9 ANSI X3T10 '97
May 5-9 NATO Workshop Edinburgh, Scotland
May 12-15 8th JENC8 Edinburgh, Scotland
May 12-16 IFIP/IEEE San Diego, CA
May 15-16 TERENA General Assembly Edinburgh, Scotland
May 19-21 7th Int'l Workshop on Ntwk & Oper
for Digital Audio & Video St. Louis, MO
May 21-23 RIPE 27 Dublin
May 27-29 IS&N '97 4th Int'l Conf. on
Intelligence in Services & Networks Como, Italy
May 28-30 ETW'97 IEEE Europen Test Wrkshop Cagliari,Italy
May 28-30 Web Developer '97 Chicago, IL
Jun. 2-6 IEEE Multimedia Systems '97 Ottawa, CANADA
Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico
Jun. 8-12 ICC '97 (joint with ENM) Montreal, CANADA
Jun. 9-13 OIW (Firm)
Jun. 9-13 ANSI X3T11 (host by Boeing) Seattle, WA
Jun. 16-18 EEMA'97 Netherlands
Jun. 23-25 4th IEEE Wrkshp on the Architecture and
Implementation of High Performance
Communication Systems (HPCS'97) Sani Beach, Greece
Jun. 24-27 INET '97 Kuala Lumpur, Malaysia
Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI
Jul. 14-18 ANSI X3T10 '97
Jul. 14-17 APPN Implementers Workshop San Jose, CA
Jul. 17-19 VTIC-97 San Jose CA
Jul. 20-25 ATM Forum Montreal, CANADA
Jul. 24-25 DMS '97 Vancouver, CANADA
Aug. 4-8 ANSI X3T11 (host by Hitachi) Honolulu, HI
Aug. 11-15 39th IETF (host by German ISOC) Munich, Germany
Aug. 12-14 DCI's Internet Expo Boston, MA
Aug. 13-15 IEEE 25th Annual Int'l Computer Software and
Application Conference Washington, DC
Sep 2-5 1997 Int'l Conference
Intelligent Networks and
Intelligence in Networks Paris, France
Sep. 8-12 ANSI X3T10 '97
Sep. 8-12 OIW (Firm)
Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland
Sep. 10-12 IDMS '97 w/ ACM SIGMM, GMD, IEEE
Darmstadt, Germany
IMR Editor [Page 28]
Internet Monthly Report March 1997
Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France
Sep. 21-26 ATM Forum Paris, France
Sep. 26-30 3rd ACM/IEEE on Mobile Computing
& Networking 1997 (MobiCom'97) Budapest, Hungary
Oct. 6-10 ANSI X3T11 (host by FSI) Tucson, AZ
Oct. 7-10 COMDEX Internet '97 and Object World '97
Internet Forum Europe (IFE) & Object
World Frankfurt (OWF) Frankfurt, Germany
Oct. 23-25 ETSI Nice, France
Nov. 3-5 Int'l Test Conference 1997
Sheraton Washington Hotel Washington, DC
Nov. 3-7 ANSI X3T10 '97
Nov. 3-7 SPIE Int'l Symposium
Voice, Video & Data Communications
Conf. on Performance & Control of
Network System - Special Session on
Switching & Traffic Mgmt in
High Speed Networks Dallas, TX
Nov. 3-7 2nd French/Brazilian Symposium
on Distributed System Architectures:
Telecommunication Multimedia Architectures
Ceara, Brazil
Nov. 8-14 ACM MULTIMEDIA '97 Seattle, WA
Nov. 10-14 IEEE 802 Plenary Queen Elizabeth, Montreal
Nov. 19-21 ICCC'97 Cannes, France
Nov. 24-26 PROMSMmNet '97
Multimedia Networking Santiago, Chile
Nov. 30-Dec 5 ATM Forum Singapore
Dec. 1-3 30th IEEE/ACM Int'l Symposium
on Microarchitecture RTC, NC
Dec. 1-5 ANSI X3T11 (host by DPT) Orlando, FL
Dec. 8-12 40th IETF (tentative) Washington, DC
Host by NewBridge
Dec. 8-12 OIW (Firm)
TELECOM '97 Asia (Venue and Dates to be Determined)
1998
-----------
Jan 6-8 W3C Interest Group Mtg TBA
Feb. 8-13 ATM Forum TBA
Feb 7-9 DCI'S Internet Expo San Jose, CA
Mar. 9-13 IEEE 802 Plenary Irvine, CA
Mar. 29-Apr 2 IEEE INFOCOM '98 - Hotel Nikko San Francisco, CA
Apr. 3-4 IEEE "OPENARCH '98" San Francisco, CA
Apr. 19-24 ATM Forum TBA
Apr 20-22 W3C Interest Group Mtg TBA
SPRING 1998 TELECOM '97 Africa Midrand, South Africa
Jun 16-18 DCI's Internet Expo Chicago, IL
IMR Editor [Page 29]
Internet Monthly Report March 1997
Jul. 6-10 IEEE 802 Plenary San Diego, CA
Jul. 26-31 ATM Forum TBA
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
Sep 1-3 DCI's Internet Expo Boston, MA
Oct. 4-9 ATM Forum TBA
Oct 20-22 W3C Interest Group Mtg TBA
Nov. 9-13 IEEE 802 Plenary Albuquerque, NM
Nov. 30-Dec 4 ATM Forum TBA
Dec. 6-11 43rd IETF Adelaide, Australia
Host: Univ. of Adelaide
1999
-----
Feb 23-25 W3C Interest Group Mtg TBA
Jun 4-6 W3C Interest Group Mtg TBA
Sep 21-23 W3C Interest Group Mtg TBA
Oct. 8-14 TELECOM '99 Geneva, Switzerland
IMR Editor [Page 30]
Internet Monthly Report March 1997
TERENA CALENDAR
---------------
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact the
chair of the meeting or the TERENA Secretariat. If you have
additions/corrections/comments, please mail <secretariat at terena.nl>.
**********************************************************************
NAME / DATE LOCATION
TERENA General Assembly
GA7
15-16 May Edinburgh
TERENA Technical Committee
22 January Amsterdam
EWOS
----
EWOS Assembly 2, 25-26 February Brussels
EWOS Assembly 3, 13-14 May "
EWOS Assembly 4, 16-17 September "
EWOS Assembly 5, 2-3 December "
Workshops
36: 20-24 January Brussels
37: 7-11 April "
38: 16-20 June "
39: 27-31 October "
IETF
----
38, 7-11 April Memphis, Tenn.
39, 11-15 August Munich, Germany
ISOC
----
Symposium
10-11 February San Diego, CA
IMR Editor [Page 31]
Internet Monthly Report March 1997
NATO
----
Workshop
5-9 May Edinburgh
RIPE
----
RIPE 26
20-22 January Amsterdam
RIPE27
21-23 May Dublin
IMR Editor [Page 32]
Internet Monthly Report March 1997
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TERENA CONFERENCES
JENC8 - 8th Joint European Networking Conference
"Diversity and Integration: The New European Networking Landscape"
12-15 May
Edinburgh, Scotland
This conference will be the European Forum to get up-to-date
information, to debate and assess the new deregulated
tele-communication environment in Europe, new leading-edge
applications, and the network/internetwork support infrastructure
which is currently being developed
Subject Areas:
* Emerging Network Technologies and Network Engineering
* User Support, Training and Education
* Security and Management Issues
* Information Systems and Distributed Applications
* Economic and Political Issues
For information please contact the JENC8 Secretariat at:
TERENA Secretariat
Singel 466-468
1017 AW Amsterdam, The Netherlands
tel: +31 20 6391131 fax: +31 20 6393289
email: <jenc8-sec at terena.nl>
http://www.terena.nl/jenc8
or
JENC8 Local Organization
c/o Concorde Services Ltd
Unit 5, SECC
Glasgow, G3 8YW, Scotland
email: <jenc8 at ed.ac.uk>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
IMR Editor [Page 33]
Internet Monthly Report March 1997
OTHER CONFERENCES
The Arab World and the Information Society - Regional Symposium
---------------------------------------------------------------
5-9 May
Tunis, Tunisia
Organized by ITU and UNESCO, in cooperation with the government of
Tunisia and in the framework of RAITNET (Regional Arab Information
Technology Network)
For information see www site: http://www.irsit.rnrt.tn/symposium
and/or email <symposium at irsit.rnrt.tn
IS&N '97
4th International Conference on Intelligence in Services & Networks
-------------------------------------------------------------------
27-29 May
Como, Italy
Title: "Technology for Co-operative Competition". The conference will
provide a forum for the discussion of issues and the exchange of
outstanding technical results related to the engineering of advanced
communication services and experiments on their use.
Sponsored by the European Commission and Italtel, and supported by
ACTS projects in IS&N domain.
Further information is available on WWW:
http://www.uni-stuttgart.de/SONAH/Acts/domain5
ECOOP'97
11th European Conference on Object-Oriented Programming
-------------------------------------------------------
9-13 June
University of Jyv=E4skyl=E4, Jyv=E4skyl=E4, Finland
or information see www page:
http://www.trese.cs.utwente.nl/ecoop97 or
http://www.ecoop97.jyu.fi
EEMA'97 - Annual Conference and Exhibition
Electronic Commerce and Messaging in Europe,
"The Premier European Forum for Advanced Business"
-------------------------------------------------
16-18 June
Maastricht Exhibition and Congress Centre, Maastricht, Netherlands
Issues of the conference will be:
Global Security; Corporate Directories; Messaging Products & Services;
Electronic Commerce; Global Messaging Enterprise; European
Initiatives; Mobile Messaging Technology; Messaging Technology &
Management Strategy; Intranet; World Wide Web & Infobots.
For information contact WWW: http://www.eema.org/
IMR Editor [Page 34]
Internet Monthly Report March 1997
International Distributed Conference on Network Interoperability
----------------------------------------------------------------
16-18 June
Madeira
Organized by ACTS project GINA and sponsored by the European
commission, this conference is open for all involved in networking
solutions for information society.
Paper submission by 28 February
Contact for information and submissions email <rao at telscom.ch
Local organizer email <rp at cet.pt
INET'97 - Workshop
------------------
15-21 June
Kuala Lumpur, Malaysia
Focus of the workshop will be upon assisting countries that are either
not yet connected to the Internet or are in the process of developing
and enhancing an initial national Internet.
For copy of announcement e-mail <workshop-apply at isoc.org>
Apply for admission by 7 February 1997 to e-mail
<workshop-application at isoc.org>
INET'97
7th Annual Internet Society Conference
---------------------------------------
24-27 June
Kuala Lumpur, Malaysia
The conference will address the traditional and evolving frontiers of
the Internet as well as its significant impact on education, commerce
and societies throughout the world.
-information on INET97, the K-12 workshop, the Tutorials, and the
associated Developing Countries Workshop, along with an abstract
submission form, can be found on the ISOC web page:
http://isoc.org/inet
or, for information via e-mail:
- for details of submission procedure email
<inet-program-interest at isoc.org>
- for other information email <inet97 at isoc.org>
IMR Editor [Page 35]
Internet Monthly Report March 1997
FIRST - Forum of Incident Response and Security Teams
9th Annual Computer Security Incident Handling Workshop
-------------------------------------------------------
23-27 June
Marriott Hotel, Bristol, England
This annual workshop is part of FIRST's ongoing program of education
and raising awareness for its members and others.
Paper submission deadline 15 January
For information see: http://www.first.org/
FMOODS'97 - Second IFIP Interrnational Workshop on
Formal Methods for Open-based Distributed Systems
----------------------------------------------------
21-23 July
Canterbury, United Kingdom
Objective is to provide an integrated forum for the presentation of
research in several related fields.
Paper submission deadline 14 January 1997
For all information: e-mail <fmoods97-request at uck.ac.uk> or
web page: http://alethea.u,c.ac.uk/Dept/Computing/Research/NDS/FMOODS/
IDMS'97
European Workshop on Interactive Distributed Multimedia Systems
and Telecommunication Services
---------------------------------------------------------------
10-12 September
Darmstadt, Germany
In cooperation with ACM SIGM, Gesellschaft fuer Informatik, GMD, IEEE
Computer Society and VDE ITG.
The purpose of this 4th workshop is to provide a forum for the
presentation, exploration and discussion of technologies and their
advancements in the broad field of interactive distributed multimedia
systems.
Paper submission due 1 March 1997
For additional information se www: http://www.th-darmstadt.de/idms97
IMR Editor [Page 36]
Received: from ietf.org by ietf.org id aa14829; 24 Apr 97 5:21 EDT
Received: from mars.dsv.su.se by ietf.org id aa14633; 24 Apr 97 5:13 EDT
Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138])
by mars.dsv.su.se (8.7.1/8.7.1) with ESMTP
id LAA18951 for <ietf at ietf.org>;
Thu, 24 Apr 1997 11:10:02 +0200
Message-Id: <v0300780aaf84df3dcf03 at [130.237.150.138]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Apr 1997 11:03:05 +0100
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Jacob Palme <jpalme at dsv.su.se>
Subject: e-mail and p-mail
Source-Info: From (or Sender) name not authenticated.
The word "mail" is becoming more and more ambiguous, since it can
be used to refer to both postal mail and e-mail. The most commonly
used word for postal mail in order to differentiate from e-mail
is "snail-mail" but this is not really a good term, derogatory
comments should not be part of the name of an important public
service.
I have seen "p-mail", which seems an excellent term. Can we
agree to use "p-mail" as an abbreviation for postal mail?
------------------------------------------------------------------------
Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Received: from ietf.org by ietf.org id aa16228; 24 Apr 97 6:13 EDT
Received: from survis.surfnet.nl by ietf.org id aa16130; 24 Apr 97 6:09 EDT
Received: from surah.surfnet.nl by survis.surfnet.nl with SMTP (PP) with ESMTP;
Thu, 24 Apr 1997 12:05:32 +0200
Received: from surfnet.nl (actually host surah.surfnet.nl)
by surah.surfnet.nl with SMTP (PP) with ESMTP;
Thu, 24 Apr 1997 12:05:29 +0200
X-Mailer: exmh version 2.0gamma 1/27/96
To: Jacob Palme <jpalme at dsv.su.se>
cc: ietf at ietf.org
Subject: Re: e-mail and p-mail
In-reply-to: Your message of "Thu, 24 Apr 1997 11:03:05 BST." <v0300780aaf84df3dcf03 at [130.237.150.138]>
Organisation: SURFnet ExpertiseCentrum bv
Address: Radboudburcht, P.O. Box 19115, 3501 DC Utrecht, NL
Phone: +31 302 305 305
Telefax: +31 302 305 329
X-url: http://www.sec.nl/persons/wierenga
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 Apr 1997 12:05:27 +0200
Sender:ietf-request at ietf.org
From: Klaas Wierenga <Klaas.Wierenga at sec.nl>
Message-ID: <9704240609.aa16130 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
==> From: Jacob Palme
> The word "mail" is becoming more and more ambiguous, since it can
> be used to refer to both postal mail and e-mail. The most commonly
> used word for postal mail in order to differentiate from e-mail
> is "snail-mail" but this is not really a good term, derogatory
> comments should not be part of the name of an important public
> service.
>
> I have seen "p-mail", which seems an excellent term. Can we
> agree to use "p-mail" as an abbreviation for postal mail?
Jacob,
This may be a bit confusing for all those people using Pegasus Mail, mostly
called PMail for short.
Klaas Wierenga
SURFnet ExpertiseCentrum bv
Received: from ietf.org by ietf.org id aa20211; 24 Apr 97 9:45 EDT
Received: from egate2.citicorp.com by ietf.org id aa19827; 24 Apr 97 9:34 EDT
Received: by egate2.citicorp.com id AA20624
(InterLock SMTP Gateway 3.0 for ietf at ietf.org);
Thu, 24 Apr 1997 09:31:33 -0400
Message-Id: <199704241331.AA20624 at egate2.citicorp.com>
Received: by egate2.citicorp.com (Protected-side Proxy Mail Agent-1);
Thu, 24 Apr 1997 09:31:33 -0400
Date: Thu, 24 Apr 1997 09:31:00 -0400
Sender:ietf-request at ietf.org
From: Lee Piazza <lee.piazza at citicorp.com>
Reply-To: lee.piazza at citicorp.com
Organization: Citicorp
X-Mailer: Mozilla 3.01 (WinNT; I)
Mime-Version: 1.0
To: ietf at ietf.org
Cc: jpalme at dsv.su.se, Klaas.Wierenga at sec.nl
Subject: Re: e-mail and p-mail
References: <9704240609.aa16130 at ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I agree with Klaas' comments. Using the derogatory term "snail-mail" is
a snobby, elitist way of refering to the world's postal system. However,
since we refer to voice mail by its full name, and even use "snail-mail"
- not s-mail - would it be so difficult to refer to postal mail as
"postal mail"?
I know, I know, I'm speaking to the ultimate acronym-loving audience
here.....how about just "M"? ;-)
Lee Piazza (LP)
Citicorp Global Technology Infrastucture Global Distributed Computing
(CGTI-GDC)
Klaas Wierenga wrote:
>
> ==> From: Jacob Palme
>
> > The word "mail" is becoming more and more ambiguous, since it can
> > be used to refer to both postal mail and e-mail. The most commonly
> > used word for postal mail in order to differentiate from e-mail
> > is "snail-mail" but this is not really a good term, derogatory
> > comments should not be part of the name of an important public
> > service.
> >
> > I have seen "p-mail", which seems an excellent term. Can we
> > agree to use "p-mail" as an abbreviation for postal mail?
>
> Jacob,
>
> This may be a bit confusing for all those people using Pegasus Mail, mostly
> called PMail for short.
>
> Klaas Wierenga
> SURFnet ExpertiseCentrum bv
Received: from ietf.org by ietf.org id aa20212; 24 Apr 97 9:45 EDT
Received: from ns1.BayNetworks.COM by ietf.org id aa19694; 24 Apr 97 9:28 EDT
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost2.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP
id GAA16077
Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199])
by ns1.BayNetworks.COM (8.8.5/BNET-97/03/12-I) with ESMTP
id GAA15491
Posted-Date: Thu, 24 Apr 1997 06:25:07 -0700 (PDT)
Received: from rvator.engeast (rvator [192.32.242.168])
by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP
id JAA29755; Thu, 24 Apr 1997 09:25:09 -0400
for
Received: by rvator.engeast (4.1/SMI-4.1)
id AA09236; Thu, 24 Apr 97 09:24:05 EDT
Date: Thu, 24 Apr 1997 09:24:05 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Nirlay Kundu <nkundu at baynetworks.com>
To: Jacob Palme <jpalme at dsv.su.se>
Cc: ietf at ietf.org
Subject: Re: e-mail and p-mail
In-Reply-To: <v0300780aaf84df3dcf03 at [130.237.150.138]>
Message-Id: <Pine.SUN.3.91.970424092103.9232A-100000 at rvator>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> The word "mail" is becoming more and more ambiguous, since it can
> be used to refer to both postal mail and e-mail. The most commonly
> used word for postal mail in order to differentiate from e-mail
> is "snail-mail" but this is not really a good term, derogatory
> comments should not be part of the name of an important public
> service.
On the other hand, I thought snail mail(taken in the light sense) was
humorous rather than derogatory. But, I understand some people may take
it seriously.
Nirlay
Received: from ietf.org by ietf.org id aa21162; 24 Apr 97 10:01 EDT
Received: from dip.eecs.umich.edu by ietf.org id aa20949; 24 Apr 97 9:56 EDT
Received: from localhost (rhall at localhost) by dip.eecs.umich.edu (8.8.5/8.8.0) with SMTP id JAA02143; Thu, 24 Apr 1997 09:53:32 -0400 (EDT)
Date: Thu, 24 Apr 1997 09:53:31 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Robert W. Hall" <rhall at eecs.umich.edu>
To: "Robert W. Hall" <rhall at dip.eecs.umich.edu>
cc: ietf at ietf.org
Subject: Re: e-mail and p-mail
In-Reply-To: <Pine.SUN.3.91.970424092103.9232A-100000 at rvator>
Message-ID: <Pine.SUN.3.96.970424095148.1691B-100000 at dip.eecs.umich.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Perhaps as suggested 'postal mail' or something like 'physical mail' that
connotes the fact that postal mail is non-electronic and has physical
form.
Robert W. Hall,
Software Systems Research Laboratory
Department of Computer Science and Engineering
The University of Michigan
On Thu, 24 Apr 1997, Nirlay Kundu wrote:
> > The word "mail" is becoming more and more ambiguous, since it can
> > be used to refer to both postal mail and e-mail. The most commonly
> > used word for postal mail in order to differentiate from e-mail
> > is "snail-mail" but this is not really a good term, derogatory
> > comments should not be part of the name of an important public
> > service.
>
> On the other hand, I thought snail mail(taken in the light sense) was
> humorous rather than derogatory. But, I understand some people may take
> it seriously.
>
> Nirlay
>
Received: from ietf.org by ietf.org id aa22163; 24 Apr 97 10:10 EDT
Received: from hq.idt.net by ietf.org id aa22067; 24 Apr 97 10:07 EDT
Received: from localhost (mpark at localhost) by hq.idt.net (8.8.5/NETSYS-LEN) with SMTP id KAA02695; Thu, 24 Apr 1997 10:04:22 -0400 (EDT)
Date: Thu, 24 Apr 1997 10:04:22 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Michael Park <mpark at corp.idt.net>
X-Sender: mpark at hq.idt.net
To: Jacob Palme <jpalme at dsv.su.se>
cc: ietf at ietf.org
Subject: Re: e-mail and p-mail
In-Reply-To: <v0300780aaf84df3dcf03 at [130.237.150.138]>
Message-ID: <Pine.GSO.3.95.970424100404.18957F-100000 at hq.idt.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
hehe..cute.
i agree!
M.
On Thu, 24 Apr 1997, Jacob Palme wrote:
> The word "mail" is becoming more and more ambiguous, since it can
> be used to refer to both postal mail and e-mail. The most commonly
> used word for postal mail in order to differentiate from e-mail
> is "snail-mail" but this is not really a good term, derogatory
> comments should not be part of the name of an important public
> service.
>
> I have seen "p-mail", which seems an excellent term. Can we
> agree to use "p-mail" as an abbreviation for postal mail?
>
> ------------------------------------------------------------------------
> Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
> for more info see URL: http://www.dsv.su.se/~jpalme
>
>
>
Received: from ietf.org by ietf.org id aa22944; 24 Apr 97 10:19 EDT
Received: from atl_xch_srvr1.hayes.com by ietf.org id aa22657;
24 Apr 97 10:16 EDT
Received: by atl_xch_srvr1.hayes.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <01BC5098.15C4C780 at atl_xch_srvr1.hayes.com>; Thu, 24 Apr 1997 10:12:59 -0400
Message-ID: <c=US%a=_%p=Hayes_Microcompu%l=ATL_XCH_SRVR1-970424141257Z-2054 at atl_xch_srvr1.hayes.com>
Sender:ietf-request at ietf.org
From: "Dunlap, Randy" <rdunlap at hayes.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: e-mail and p-mail
Date: Thu, 24 Apr 1997 10:12:57 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I also agree that snail-mail is not a highly desirable name for
postal mail. However, p-mail did confuse me with Pegasus mail
(as someone else pointed out).
There are lots of other possibilities, although it may be too late
to agree on any one of them.
ne-mail:
"not e-mail" (of course, NE to some people means ANY)
hard-mail, h-mail, hc-mail:
hard-copy mail (printed matter as opposed to soft or
electronic matter)
s-mail:
surface mail (but postal mail could also be air mail)
g-mail or gov-mail:
postal mail is usually a government-sanctioned mail
service
i-mail:
institutional mail
This is my list without brainstorming. We could come up with
hundreds of suggestions.
____________________________________________________________
Randy Dunlap, Software Engineer 770/840-9200 x-2442
rdunlap at hayes.com fax: 770/447-0178
Network Systems
US Mail: P.O. Box 105203, Atlanta, GA 30348-5203
street: 5923 Peachtree Industrial Blvd., Norcross, GA 30092-3405
>Klaas Wierenga wrote:
>>
>> ==> From: Jacob Palme
>>
>> > The word "mail" is becoming more and more ambiguous, since it can
>> > be used to refer to both postal mail and e-mail. The most commonly
>> > used word for postal mail in order to differentiate from e-mail
>> > is "snail-mail" but this is not really a good term, derogatory
>> > comments should not be part of the name of an important public
>> > service.
>> >
>> > I have seen "p-mail", which seems an excellent term. Can we
>> > agree to use "p-mail" as an abbreviation for postal mail?
>>
>> Jacob,
>>
>> This may be a bit confusing for all those people using Pegasus Mail, mostly
>> called PMail for short.
>>
>> Klaas Wierenga
>> SURFnet ExpertiseCentrum bv
>
Received: from ietf.org by ietf.org id aa24639; 24 Apr 97 10:44 EDT
Received: from Hypatia.Stanford.EDU by ietf.org id aa24347; 24 Apr 97 10:40 EDT
Received: from Turing.Stanford.EDU (Turing.Stanford.EDU [36.9.0.14]) by Hypatia.Stanford.EDU (8.8.5/8.8.3) with ESMTP id HAA11100; Thu, 24 Apr 1997 07:35:26 -0700 (PDT)
Received: from localhost (ole at localhost)
by Turing.Stanford.EDU (8.8.5/8.8.5) with SMTP id HAA14855;
Thu, 24 Apr 1997 07:36:08 -0700 (PDT)
X-Authentication-Warning: Turing.Stanford.EDU: ole owned process doing -bs
Date: Thu, 24 Apr 1997 07:36:08 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
X-Sender: ole at Turing.Stanford.EDU
To: Jacob Palme <jpalme at dsv.su.se>
cc: ietf at ietf.org
Subject: Re: e-mail and p-mail
In-Reply-To: <v0300780aaf84df3dcf03 at [130.237.150.138]>
Message-ID: <Pine.GSO.3.95.970424073249.14607B-100000 at Turing.Stanford.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I would prefer to stick to e-mail as distinguishing it from other forms
of mail since "postal" doesn't really capture all the physcial
alternatives such as FedEx, UPS, DHL, Airborne and others.
"Mail" has a well-established meaning in the real world: the cheque
is in the mail. We don't need a new word for that, just a better
excuse :-)
Ole
-----------------------------------------------------------------
Ole J. Jacobsen, Senior Technical Advisor, Interop Company,
A division of SOFTBANK Forums, 303 Vintage Park Drive,
Foster City, California 94404-1138, USA.
Phone: +1 415-578-6988
Fax: Please don't, use e-mail instead.
E-mail: ole at csli.stanford.edu, ole at world.std.com, ole at interop.com
-----------------------------------------------------------------
On Thu, 24 Apr 1997, Jacob Palme wrote:
> The word "mail" is becoming more and more ambiguous, since it can
> be used to refer to both postal mail and e-mail. The most commonly
> used word for postal mail in order to differentiate from e-mail
> is "snail-mail" but this is not really a good term, derogatory
> comments should not be part of the name of an important public
> service.
>
> I have seen "p-mail", which seems an excellent term. Can we
> agree to use "p-mail" as an abbreviation for postal mail?
>
> ------------------------------------------------------------------------
> Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
> for more info see URL: http://www.dsv.su.se/~jpalme
>
>
>
Received: from ietf.org by ietf.org id aa24864; 24 Apr 97 10:48 EDT
Received: from puli.cisco.com by ietf.org id aa24779; 24 Apr 97 10:47 EDT
Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id HAA03512 for <ietf at ietf.org>; Thu, 24 Apr 1997 07:44:00 -0700
X-Sender: bstewart at puli.cisco.com
Message-Id: <v0310250aaf85217d8cf1 at [171.69.128.42]>
In-Reply-To:
<c=US%a=_%p=Hayes_Microcompu%l=ATL_XCH_SRVR1-970424141257Z-2054 at atl_xch_sr
vr1.hayes.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Apr 1997 10:43:53 -0400
To: "'ietf at ietf.org'" <ietf at ietf.org>
Sender:ietf-request at ietf.org
From: Bob Stewart <bstewart at cisco.com>
Subject: RE: e-mail and p-mail
Source-Info: From (or Sender) name not authenticated.
Circa 10:12 AM -0400 4/24/97, Dunlap, Randy bitwhacked:
>hard-mail, h-mail, hc-mail:
> hard-copy mail (printed matter as opposed to soft or
> electronic matter)
Of the ideas so far I rather like hard mail, h-mail.
Although I can't claim to have noticed it first, think typical American
euphemisms and say p-mail several times...
But I suppose that might have been intentional. :-)}
Bob
Received: from ietf.org by ietf.org id aa25093; 24 Apr 97 10:50 EDT
Received: from hiway1.exit109.com by ietf.org id aa25007; 24 Apr 97 10:49 EDT
Received: from ppp6-rb.exit109.com (ppp6-rb.exit109.com [205.164.176.133]) by hiway1.exit109.com (8.8.5/8.7.3) with SMTP id KAA05195; Thu, 24 Apr 1997 10:45:39 -0400 (EDT)
Received: by ppp6-rb.exit109.com with Microsoft Mail
id <01BC509C.9DBC12C0 at ppp6-rb.exit109.com>; Thu, 24 Apr 1997 10:45:25 -0400
Message-ID: <01BC509C.9DBC12C0 at ppp6-rb.exit109.com>
Sender:ietf-request at ietf.org
From: "Herman R. Silbiger" <hsilbiger at exit109.com>
To: Jacob Palme <jpalme at dsv.su.se>, 'Klaas Wierenga' <Klaas.Wierenga at sec.nl>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: e-mail and p-mail
Date: Thu, 24 Apr 1997 09:25:28 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
How about using UPU-mail, where UPU stands for Universal Postal Union, the world administrative body for postal services.
Herman Silbiger
----------
From: Klaas Wierenga[SMTP:Klaas.Wierenga at sec.nl]
Sent: Thursday, April 24, 1997 6:05 AM
To: Jacob Palme
Cc: ietf at ietf.org
Subject: Re: e-mail and p-mail
==> From: Jacob Palme
> The word "mail" is becoming more and more ambiguous, since it can
> be used to refer to both postal mail and e-mail. The most commonly
> used word for postal mail in order to differentiate from e-mail
> is "snail-mail" but this is not really a good term, derogatory
> comments should not be part of the name of an important public
> service.
>
> I have seen "p-mail", which seems an excellent term. Can we
> agree to use "p-mail" as an abbreviation for postal mail?
Jacob,
This may be a bit confusing for all those people using Pegasus Mail, mostly
called PMail for short.
Klaas Wierenga
SURFnet ExpertiseCentrum bv
Received: from ietf.org by ietf.org id aa25562; 24 Apr 97 10:58 EDT
Received: from kcgw2.att.com by ietf.org id aa25475; 24 Apr 97 10:56 EDT
Received: from lynxhub.ho.att.com by kcig2.att.att.com (SMI-8.6/EMS-1.2 sol2)
id JAA07448; Thu, 24 Apr 1997 09:46:08 -0500
Received: from CARPENTER.cis.att.com ([135.46.61.210]) by lynxhub.ho.att.com (5.x/EMS-1.2 sol2)
id AA07449; Thu, 24 Apr 1997 10:51:15 -0400
Date: Thu, 24 Apr 1997 10:50:54 -0400
Message-Id: <3081-Thu24Apr1997105235-0400-bill at att.com>
X-Mailer: emacs 19.34.1 (via feedmail 7-beta-8 Q) WJC
Sender:ietf-request at ietf.org
From: WJCarpenter <bill at att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: ietf at ietf.org
Subject: RE: e-mail and p-mail
In-Reply-To: Dunlap, Randy's note of 24 Apr 1997 10:12:57 -0400
References: <c=US%a=_%p=Hayes_Microcompu%l=ATL_XCH_SRVR1-970424141257Z-2054 at atl_xch_srvr1.hayes.com>
Source-Info: From (or Sender) name not authenticated.
For quite a while I have called it "physical mail". It is not
inconceivable to me that some postal authority could eventually gain
credibility in the email arena. "Physical mail" says what it is
without getting into the confusing tangent of who's doing it.
--
bill at att.com (WJCarpenter) +1.908.576.2932
bill at attmail.com LZ 1C-320
AT&T Labs / AT&T WorldNet Service
Received: from ietf.org by ietf.org id aa26066; 24 Apr 97 11:08 EDT
Received: from piraya.electrum.kth.se by ietf.org id aa25848;
24 Apr 97 11:05 EDT
Received: from drum.it.kth.se (drum.it.kth.se [130.237.213.23])
by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP
id RAA02169;
Thu, 24 Apr 1997 17:02:05 +0200 (MET DST)
Message-Id: <199704241502.RAA02169 at piraya.electrum.kth.se>
To: rdunlap at hayes.com
Cc: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Magnus Danielson <magda at it.kth.se>
Subject: RE: e-mail and p-mail
In-Reply-To: Your message of "Thu, 24 Apr 1997 10:12:57 -0400"
References: <c=US%a=_%p=Hayes_Microcompu%l=ATL_XCH_SRVR1-970424141257Z-2054 at atl_xch_srvr1.hayes.com>
X-Mailer: Mew version 1.06 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Thu, 24 Apr 1997 17:01:45 +0200
X-Orig-Sender: e93_mda at drum.it.kth.se
Source-Info: From (or Sender) name not authenticated.
>>>>> "DR" == Dunlap, Randy <rdunlap at hayes.com> writes:
DR> I also agree that snail-mail is not a highly desirable name for
DR> postal mail. However, p-mail did confuse me with Pegasus mail
DR> (as someone else pointed out).
If we where to use statistical methods on for instance user base on
Pegasus Mail versus Postal Mail I think Postal Mail will win with a
big margin, don't you think so?
DR> There are lots of other possibilities, although it may be too late
DR> to agree on any one of them.
DR> ne-mail:
DR> "not e-mail" (of course, NE to some people means ANY)
DR> hard-mail, h-mail, hc-mail:
DR> hard-copy mail (printed matter as opposed to soft or
DR> electronic matter)
DR> s-mail:
DR> surface mail (but postal mail could also be air mail)
DR> g-mail or gov-mail:
DR> postal mail is usually a government-sanctioned mail
DR> service
DR> i-mail:
DR> institutional mail
Althougth good tries I still beleive that "p-mail" is a better one,
however just to confuse you all I can give you a reason why NOT to use
it (for both Pegasus Mail and Postal Mail):
p-mail could possibly be connected with Porno-Mail in some people sick
minds (I wonder what it sais about my mind... houps!).
There is numerous collisions allready, but the context separate most
of them. I beleive that the context of the Pegasus instance of Pmail
is distinct from the Postal instance of p-mail. Also, in writing you
really make a diffrence as I just did, the confusion comes when you
speak.
Let's also recall that here we do not set an new protocol standard but
rather an human language preference, and as such we may need to make
diffrent prioritations than otherwise.
I still think Jacob's proposal is the best so far.
Respectfully,
Magnus
Received: from ietf.org by ietf.org id aa26865; 24 Apr 97 11:23 EDT
Received: from yakko.chicks.net by ietf.org id aa26762; 24 Apr 97 11:21 EDT
Received: from localhost (chicks at localhost) by yakko.chicks.net (8.7.4/8.7.3) with SMTP id LAA08818; Thu, 24 Apr 1997 11:17:32 -0400
X-Authentication-Warning: yakko.chicks.net: chicks owned process doing -bs
Date: Thu, 24 Apr 1997 11:17:30 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Christopher Hicks <chicks at chicks.net>
To: "Ole J. Jacobsen" <ole at csli.stanford.edu>
cc: Jacob Palme <jpalme at dsv.su.se>, ietf at ietf.org
Subject: Re: e-mail and p-mail
In-Reply-To: <Pine.GSO.3.95.970424073249.14607B-100000 at Turing.Stanford.EDU>
Message-ID: <Pine.LNX.3.94.970424111454.8789C-100000 at yakko.chicks.net>
Organization: Flamingo Internet Navigators
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 24 Apr 1997, Ole J. Jacobsen wrote:
> I would prefer to stick to e-mail as distinguishing it from other forms
> of mail since "postal" doesn't really capture all the physcial
> alternatives such as FedEx, UPS, DHL, Airborne and others.
>
> "Mail" has a well-established meaning in the real world: the cheque
> is in the mail. We don't need a new word for that, just a better
> excuse :-)
Maybe saying "postal" wouldn't be good. But why not just call it "post".
It avoids using the ambiguous "mail" and its short.
</chris>
Any chance of those paper cups and string being upgraded to tin cans
and wire? Or as a coworker has said . . . I've seen better throughput
from a pair of gorillas and flash cards. -Jon Lewis <jlewis at fdt.net>
Received: from ietf.org by ietf.org id aa27576; 24 Apr 97 11:34 EDT
Received: from caladan.arrakis.es by ietf.org id aa27354; 24 Apr 97 11:31 EDT
Received: from pc-de-raides-j. (if-133.arrakis.es [195.5.75.133]) by arrakis.es (8.7.5/8.7.3) with SMTP id QAA21942; Thu, 24 Apr 1997 16:46:28 +0200 (MET DST)
Message-Id: <199704241446.QAA21942 at arrakis.es>
Comments: Authenticated sender is <raidesj at pop3.arrakis.es>
Sender:ietf-request at ietf.org
From: Dr-X <raidesj at arrakis.es>
Organization: Dr-X Enterprises, Ltd.
To: Jacob Palme <jpalme at dsv.su.se>
Date: Thu, 24 Apr 1997 15:48:00 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: e-mail and p-mail
CC: ietf at ietf.org
Priority: normal
In-reply-to: <v0300780aaf84df3dcf03 at [130.237.150.138]>
X-mailer: Pegasus Mail for Win32 (v2.53/R1)
Source-Info: From (or Sender) name not authenticated.
> The word "mail" is becoming more and more ambiguous, since it can
> be used to refer to both postal mail and e-mail. The most commonly
> used word for postal mail in order to differentiate from e-mail
> is "snail-mail" but this is not really a good term, derogatory
> comments should not be part of the name of an important public
> service.
>
> I have seen "p-mail", which seems an excellent term. Can we
> agree to use "p-mail" as an abbreviation for postal mail?
>
> ------------------------------------------------------------------------
> Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
> for more info see URL: http://www.dsv.su.se/~jpalme
>
Why not? ... It seems a really simple and good idea ... enough
simple to "catch" the people. Now it's time to submit it to every
magazine around the world and post it on popular newsgroups -ie. sex
ones- to spread it around! ;)
However I agree a bit with Lee Piazza's answer in that using the
full qualified name of "postal mail" won't be such a bad idea at all
(good the "M" joke, Lee! ;) )
XXX XXX
DDDD RRRR XX XX
D D R R XX XX
D D R R XX XX
D D RRRR ----- XXXX ... ON THE EDGE OF TECHNOLOGY
D D R R XX XX
D D R R XX XX
DDDD R R XX XX
XXX XXX
(Yeah! It's technology what makes it possible, but ... what's technology without
the people behind it? ... )
Received: from ietf.org by ietf.org id aa27823; 24 Apr 97 11:37 EDT
Received: from proxy1.ba.best.com by ietf.org id aa27691; 24 Apr 97 11:36 EDT
Received: from [205.149.180.135] (boo.vip.best.com [205.149.180.135]) by proxy1.ba.best.com (8.8.5/8.8.3) with ESMTP id IAA14657 for <ietf at ietf.org>; Thu, 24 Apr 1997 08:30:14 -0700 (PDT)
X-Sender: boo at shell5.ba.best.com
Message-Id: <v03007817af852c286e29 at [205.149.180.135]>
In-Reply-To: <v0310250aaf85217d8cf1 at [171.69.128.42]>
References:
<c=US%a=_%p=Hayes_Microcompu%l=ATL_XCH_SRVR1-970424141257Z-2054 at atl_xch_s
r vr1.hayes.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Web-Site: http://www.natural-innovations.com/
X-Quote: I wasn't innocent till I got older. --WIK
Date: Thu, 24 Apr 1997 08:29:57 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Walter Ian Kaye <walter at natural-innovations.com>
Subject: RE: e-mail and p-mail
Source-Info: From (or Sender) name not authenticated.
At 10:43a -0400 04/24/97, Bob Stewart wrote:
> Circa 10:12 AM -0400 4/24/97, Dunlap, Randy bitwhacked:
> >hard-mail, h-mail, hc-mail:
> > hard-copy mail (printed matter as opposed to soft or
> > electronic matter)
>
> Of the ideas so far I rather like hard mail, h-mail.
>
> Although I can't claim to have noticed it first, think typical American
> euphemisms and say p-mail several times...
>
> But I suppose that might have been intentional. :-)}
Hehehe... I was going to suggest "paper mail" until I sounded that out, too!
Made me think of gigolos. <G>
-Walter ::wondering what this has to do with internet engineering::
__________________________________________________________________________
Walter Ian Kaye <boo_at_best*com> Programmer - Excel, AppleScript,
Mountain View, CA ProTERM, FoxPro, HTML
http://www.natural-innovations.com/ Musician - Guitarist, Songwriter
Received: from ietf.org by ietf.org id aa28537; 24 Apr 97 11:45 EDT
Received: from ns1.meitca.com by ietf.org id aa28450; 24 Apr 97 11:43 EDT
Received: from sextant.meitca.com by ns1.meitca.com (5.65+/1.0s)
id AA24400; Thu, 24 Apr 97 11:40:06 -0400
Sender:ietf-request at ietf.org
From: Reto Lichtensteiger <rali at meitca.com>
Received: (from rali at localhost)
by sextant.meitca.com (8.8.5/8.8.5) id LAA06788;
Thu, 24 Apr 1997 11:39:59 -0400 (EDT)
Message-Id: <199704241539.LAA06788 at sextant.meitca.com>
Subject: Re: e-mail and p-mail
In-Reply-To: <01BC509C.9DBC12C0 at ppp6-rb.exit109.com> from "Herman R. Silbiger" at "Apr 24, 97 09:25:28 am"
To: "Herman R. Silbiger" <hsilbiger at exit109.com>
Date: Thu, 24 Apr 1997 11:39:59 -0400 (EDT)
Cc: jpalme at dsv.su.se, Klaas.Wierenga at sec.nl, ietf at ietf.org
X-Restrict: no-external-archive
X-Org: Mitsubishi Electric ITA
Waltham MA 02154 [USA]
617 466 8304
X-Pgp-Key: Send me mail with "get pgp key" in subject
X-Mars-Attacks!: Nice planet, we'll take it
X-Mailer: ELM [version 2.4ME+ PL27 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Herman R. Silbiger wrote:
<> How about using UPU-mail, where UPU stands for Universal Postal Union,
<> the world administrative body for postal services.
I think Jacob's idea was to +simplify+ the terminology ...
I'll stick with email for electronic mail, mail for "real" mail and
ignore my voicemail as always <g>
Reto L.
--
R A Lichtensteiger rali at meitca.com -or- rali at world.std.com
http://www.meitca.com/ITA/People/rali
"Yes, you're doing things right, but are you doing the right things?"
"Nope. I'm just doing something dumb fast."
Received: from ietf.org by ietf.org id aa28831; 24 Apr 97 11:48 EDT
Received: from cbgw1.lucent.com by ietf.org id aa28633; 24 Apr 97 11:47 EDT
Received: from holta.ho.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
id LAA06229; Thu, 24 Apr 1997 11:36:25 -0400
Received: by holta.ho.lucent.com (5.x/EMS-L sol2)
id AA25096; Thu, 24 Apr 1997 11:44:08 -0400
Sender:ietf-request at ietf.org
From: Igor Faynberg <faynberg at lucent.com>
Received: by holta.ho.lucent.com (5.x/EMS-L sol2)
id AA25090; Thu, 24 Apr 1997 11:44:07 -0400
Date: Thu, 24 Apr 1997 11:44:07 -0400
Message-Id: <9704241544.AA25090 at holta.ho.lucent.com>
Original-From: igorf at holta.ho.lucent.com (Igor Faynberg)
To: ietf at ietf.org
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa00481; 24 Apr 97 12:10 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa00335;
24 Apr 97 12:08 EDT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA09286; Thu, 24 Apr 97 12:05:04 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA01690; Thu, 24 Apr 1997 12:05:03 -0400
Date: Thu, 24 Apr 1997 12:05:03 -0400
Message-Id: <9704241605.AA01690 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "Ole J. Jacobsen" <ole at csli.stanford.edu>
Cc: Jacob Palme <jpalme at dsv.su.se>, ietf at ietf.org
In-Reply-To: Ole J. Jacobsen's message of Thu, 24 Apr 1997 07:36:08 -0700
(PDT), <Pine.GSO.3.95.970424073249.14607B-100000 at Turing.Stanford.EDU>
Subject: Re: e-mail and p-mail
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
I don't know about everyone else, but this thread about what to call
phsical, postal, whatever mail is really silly. It has nothing to do
with the work of the IETF. Can we please stop now?
- Ted
Received: from ietf.org by ietf.org id aa00621; 24 Apr 97 12:11 EDT
Received: from gw.aeat.co.uk by ietf.org id aa00536; 24 Apr 97 12:11 EDT
Received: from pandora.harwell.aeat.co.uk by aeat.co.uk (8.8.5/AEAT-GW-1.6)
id RAA19190; Thu, 24 Apr 1997 17:07:51 +0100 (BST)
Received: from localhost by pandora.harwell.aeat.co.uk with SMTP
id RAA14881; 8.8.5/jl1.1; Thu, 24 Apr 1997 17:07:51 +0100 (BST)
Message-Id: <199704241607.RAA14881 at pandora.harwell.aeat.co.uk>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Jacob Palme <jpalme at dsv.su.se>
cc: ietf at ietf.org
Subject: Re: e-mail and p-mail
In-reply-to: Your message of "Thu, 24 Apr 1997 11:03:05 BST."
<v0300780aaf84df3dcf03 at [130.237.150.138]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 Apr 1997 17:07:50 +0100
Sender:ietf-request at ietf.org
From: John Lines <John.Lines at aeat.co.uk>
Source-Info: From (or Sender) name not authenticated.
The term e-mail, while it may seem unambiguous to this audience, could
legitimately be used to refer to X.400, or a number of proprietary interal
systems. On the other hand the terms SMTP mail, or RFC821 mail sound very
techie and are just the type of thing that causes the internet to be
criticised for its jargon.
We could simplify and clarify terms by naming our favourite email system
after the author of RFC821, and always refering to it as Postel mail ;-)
John Lines
> The word "mail" is becoming more and more ambiguous, since it can
> be used to refer to both postal mail and e-mail. The most commonly
> used word for postal mail in order to differentiate from e-mail
> is "snail-mail" but this is not really a good term, derogatory
> comments should not be part of the name of an important public
> service.
>
> I have seen "p-mail", which seems an excellent term. Can we
> agree to use "p-mail" as an abbreviation for postal mail?
>
> ------------------------------------------------------------------------
> Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
> for more info see URL: http://www.dsv.su.se/~jpalme
>
>
Received: from ietf.org by ietf.org id aa00975; 24 Apr 97 12:13 EDT
Received: from [208.211.196.5] by ietf.org id aa00867; 24 Apr 97 12:12 EDT
Received: from GW#u#Miami-Message_Server by stratasyscorp.com
with Novell_GroupWise; Thu, 24 Apr 1997 12:09:35 -0400
Message-Id: <s35f4d7f.048 at stratasyscorp.com>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 24 Apr 1997 12:08:56 -0400
Sender:ietf-request at ietf.org
From: =?ISO-8859-1?Q?Jos=E9 Tamayo?= <jtamayo at stratasyscorp.com>
To: bstewart at cisco.com, ietf at ietf.org
Subject: Re: RE: e-mail and p-mail
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Source-Info: From (or Sender) name not authenticated.
I like p-mail. I don't know where the industry is in terms of Pegasus Mail (PMail).
Jose.
>>> Bob Stewart <bstewart at cisco.com> 04/24/97 10:43AM >>>
Circa 10:12 AM -0400 4/24/97, Dunlap, Randy bitwhacked:
>hard-mail, h-mail, hc-mail:
> hard-copy mail (printed matter as opposed to soft or
> electronic matter)
Of the ideas so far I rather like hard mail, h-mail.
Although I can't claim to have noticed it first, think typical American
euphemisms and say p-mail several times...
But I suppose that might have been intentional. :-)}
Bob
Received: from ietf.org by ietf.org id aa01704; 24 Apr 97 12:25 EDT
Received: from nacho.cisco.com by ietf.org id aa01436; 24 Apr 97 12:23 EDT
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id JAA18023; Thu, 24 Apr 1997 09:20:26 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id JAA07131; Thu, 24 Apr 1997 09:20:25 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v0300785eaf8537449823 at [171.69.128.118]>
In-Reply-To: <01BC509C.9DBC12C0 at ppp6-rb.exit109.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Apr 1997 09:14:19 -0700
To: "Herman R. Silbiger" <hsilbiger at exit109.com>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: RE: e-mail and p-mail
Cc: "ietf at ietf.org" <ietf at ietf.org>
Source-Info: From (or Sender) name not authenticated.
At 9:25 AM -0400 4/24/97, Herman R. Silbiger wrote:
>How about using UPU-mail
"snail" is one syllable...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
Calvin and Hobbes (Bill Watterson)
Received: from ietf.org by ietf.org id aa03014; 24 Apr 97 12:42 EDT
Received: from zephyr.isi.edu by ietf.org id aa02810; 24 Apr 97 12:39 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA27481>; Thu, 24 Apr 1997 09:36:24 -0700
Message-Id: <199704241636.AA27481 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI 11, RFC 2116 on X.500 Implementations Catalog-96
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 24 Apr 97 09:36:24 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
FYI 11:
RFC 2116:
Title: X.500 Implementations Catalog-96
Author: C. Apple, K. Rossen
Date: April 1997
Mailbox: capple at master.control.att.com, kenr at shl.com
Pages: 164
Characters: 243994
Updates/Obsoletes: 1632
URL: ftp://ds.internic.net/rfc/rfc2116.txt
This document contains detailed description of 31 X.500
implementations - DSAs, DUAs, and DUA interfaces.
This document is a product of the Integrated Directory Services
Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970424092747.RFC at ISI.EDU>
SEND /rfc/rfc2116.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2116.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970424092747.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04175; 24 Apr 97 13:00 EDT
Received: from koobera.math.uic.edu by ietf.org id aa03976; 24 Apr 97 12:59 EDT
Received: (qmail 322 invoked by uid 666); 24 Apr 1997 17:03:14 -0000
Date: 24 Apr 1997 17:03:14 -0000
Message-ID: <19970424170314.321.qmail at koobera.math.uic.edu>
Sender:ietf-request at ietf.org
From: "D. J. Bernstein" <djb at koobera.math.uic.edu>
To: ietf at ietf.org
Subject: Re: e-mail and p-mail
Source-Info: From (or Sender) name not authenticated.
In the United States, pieces of physical mail are either ``letters'' or
``packages,'' while pieces of electronic mail are ``messages.''
> The word "mail" is becoming more and more ambiguous,
Broad != ambiguous. Example: ``Alkaloid'' is unambiguous.
---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html
Received: from ietf.org by ietf.org id aa07405; 24 Apr 97 13:42 EDT
Received: from usamrid.InnovSoftD.com by ietf.org id aa07245;
24 Apr 97 13:40 EDT
Received: from www (ded-open.InnovSoftD.com [207.1.200.27]) by usamrid.innovsoftd.com (8.7.6/8.7.1) with SMTP id MAA09519 for <ietf at ietf.org>; Thu, 24 Apr 1997 12:30:36 -0500
Message-Id: <199704241730.MAA09519 at usamrid.innovsoftd.com>
X-Mailer: Microsoft Outlook Express 4.71.0544.0
Sender:ietf-request at ietf.org
From: Jon Davis <newbreed at isd.net>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Spam Control Proposal (revision 2)
Date: Thu, 24 Apr 1997 12:45:48 -0500
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_01BC50AD.6F611950"
X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Source-Info: From (or Sender) name not authenticated.
This is a multi-part message in MIME format.
------=_NextPart_000_01BC50AD.6F611950
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
This proposal is formatted in HTML. If you would like to see the HTML =
version on your web browser, please visit =
http://www.winternet.com/~mackie/spam
| | |=20
|
|=20
| |=20
-------------------------------------------------------------------------=
-------
PURPOSE
Email spam is rampant these days, as we all know and shudder. It seems =
the lawsuits and arguments never end. No feasible resolution has been =
submitted, probably because no one dares swim against the stream of free =
speech Internet activists that bog down the issue and leave our =
mailboxes flooded with unwanted junk.
Sadly, those free speech Internet activists are, in many ways, correct. =
The communications medium of the Internet has been built to be =
completely public. While the debate continues comparing unsolicited =
faxes with unsolicited emails, the other debate also continues comparing =
unsolicited emails with unsolicited paper mail. Email is stuck in the =
middle of the two media. A fair and peaceful compromise between the =
spammers and the recipients is therefore in high demand.
While most major functions of the Internet were proposed formally by =
volunteer Internet standards groups, several other aspects of the =
Internet were not. One major aspect being overlooked by standards =
committees is the one thing that is driving the Internet at full-force, =
while at the same time bringing the Internet to its knees: industrial =
commerce and marketing. The greater commerce technologies currently =
being developed are often not built on or as universal Internet =
standards. They are instead introduced as public-appeal Internet usages =
that become "standards" only by their popularity. While this is not =
always bad, direct email marketing is an example of Internet commerce =
abusing a communications medium to an extent and in a way that it simply =
was not designed for.
BANNING SPAM
Unsolicited e-mail today is illegal in several countries, and the United =
States is not one of them, and neither is much of the UN. Spam is a =
waste of resources. It is expensive to maintain. It is annoying. It is =
theft of Internet connectivity and system functionality. It is, in fact, =
downright wrong.
Unsolicited e-mail does not appropriately compare with paper junk mail. =
In the paper junk mail system, the advertiser pays their local direct =
marketing company, who then pays the United States Postal Service (or =
your local country's postal service) to deliver the message by hand to =
your mailbox. For a single paper mail message sent costing $.32 each =
(not counting the costs for the tangible, useful, physical contents), =
1,000,000 paper mailings would cost the direct marketer $320,000. In =
contrast, with unsolicited e-mail, the advertiser pays the direct =
marketer, who then makes a simple connection to the Internet. The e-mail =
is sent to a nearby server, which has its own connection to the =
Internet. It then passes the e-mail messages to the next best servers =
for each of these recipients. Each of those servers must then forward =
the e-mail messages to the next server, and this pattern continues until =
each copy of the message is delivered to each recipient. One million =
copies of such a message would cost the direct marketer approximately =
(extremely approximately) $500, while the rest of the Internet must dish =
out approximately $20,000 to deliver each and every last message. This =
would seem to make the spammer an Internet thief, or "pirate" of =
Internet resources.
A common response is, "Spam is theft. Let's ban all spam, outright." =
While this would seem to be an easy solution, a few common questions =
remain (albeit, some less legitimate than others):
(1) What about the occasional unsolicited messages people receive =
that they desire to continue receiving? (Yes, these people exist and are =
much more common than you realize.)
(2) What about the legitimacy behind the thought of direct =
marketing?
(3) The Internet consists of a number of servers that have agreed in =
a worldwide understanding to willfully transfer Internet packets that =
may or may not be related to their interests. An example of this is the =
transfer of RealAudio packets or Internet telephone packets or even web =
page files. Why is junk e-mail such a different situation--it takes much =
less bandwidth than these other things!
(4) I have a brand new product that no one else knows about. Posting =
a web page does nothing, because no one knows it exists. I cannot afford =
"professional" means of advertising. Why can't I just e-mail at least =
those individuals who I think might be interested in my product?
(5) What if I am trying to send a message to long-lost family or =
forgotten friends or am trying to reach people I have never met before? =
How can you define what is unsolicited junk mail and what is unsolicited =
legitimate email?
(6) What about freedom of speech?Many argue that most spammers are =
not so simple-minded and willfully spam as a malicious, careless, =
unthoughtful act of greed. While many "experts" in spamming may have =
such attributes, the future of the Internet will involve extremely =
naive, ignorant netizens who don't understand Internet etiquette, and =
would be willing to conform to it if pressed by the government.
-------------------------------------------------------------------------=
-------
As an alternative to banning spam altogether, the following is a =
proposal to the IETF and to the Internet community that may help =
establish a means of resolving this issue by 1) still allowing for total =
freedom of publicly sending unsolicited email (direct mail marketing), =
while 2) providing for a complete filter for servers and people people =
who desire to keep their mailboxes clean, provided that the sender =
cooperates with this system (under the pressure of governmental law). It =
would also require the cooperation of governmental authorities to =
enforce the system, especially including the U.S. and UN governments.
-------------------------------------------------------------------------=
-------
CURRENT FILTERS
Filter technology today most commonly consists of email envelope and =
header screening. This means that the email server and/or client can =
look at the header or envelope of an email, and if it meets certain =
criteria, it will be purged. Currently, the only portions of the email =
header which the filter can examine for such screening are 1) the =
sender=92s email address; 2) the "travel path" of the email =
message=97where it came from and what servers it went through in order =
to get to the destination; and 3) the X-mailer header to determine what =
software was used to produce the message.
Therefore, the most common types of email filters are:
(1) purge emails that come from an email address that is included in =
an updated, publicly accessible "spammer" list;
(2) purge emails that come from a particular internet domain or IP =
address;
(3) purge emails that can be tracked down by looking at their =
history remarks and can be found to be included in a "spammer" list =
and/or are a member of a particular domain or IP address (1 & 2);
(4) purge the email if it was produced by a certain type of =
software; or
(5) refuse to download any incoming email messages coming from a =
particular domain or IP address (envelope screening).None of these =
methods are ideal.
(1) The first method is simply not complete in any way; there are =
millions of email users, and each one of them has the ability to spam. =
Therefore, no updated list will ever be able to keep track of all =
potential spammers on the Internet. In addition, not all email messages =
from potential spammers on the "spammer" list are spams.
(2) The second and fifth methods are worse=97they make the =
assumption that all email users of a given domain are spammers; worse =
yet, they also make the assumption that all emails coming from those =
users are spams. Therefore, this filter type will purge legitimate =
emails coming from legitimate sources, just because they come from an =
ISP or other mail server that has been known to carry spams.
(3) The third method is used to track forged email, but it is not =
only prone to error, it also carries the problems of the first two =
methods by utilizing their techniques.
(4) Finally, eliminating all email that was created by a certain =
type of email software could and would also eliminate legitimate email =
from all types of mailing lists that users are intentionally subscribed =
to.There are other filter methods being looked into, but these five =
methods are the most common filter methods today.
JUNK MAIL =3D CONTENT
The problem with header-type filters is that junk email should be =
determined by content, not by sender. It is the sender=92s intentions =
and message within the body that proves an email message as junk mail. =
The only accurate way to successfully filter spammed email, therefore, =
is to note the content and/or intent of the message, not the message=92s =
source, and if a user does not want spam, he can simply activate the =
content-type filter to purge messages with spam content.
But how is this possible? It isn=92t. No artificial intelligence will =
EVER, by any means, be able to determine what is junk mail and what is =
legitimate. Please, DO NOT WASTE YOUR TIME trying to develop this =
technology, because the spammers will simply find another way to =
communicate their message to "sound" personal, bypassing your filter.
Therefore, we=92re stuck. Literally. There is currently no way for a =
filter to determine spams from non-spams with 100% accuracy. The only =
way filters can currently work is by asking, "Where did it come from?" =
not, "Is this a spam?" and we NEED to find a way to develop such a =
filter, one that can determine, "Is this a spam?"
WITH A LITTLE COOPERATION, EVERYONE CAN BE HAPPY.
There is a way such a filter can be done. It requires a little =
cooperation from the IETF, governmental authorities, and, yes, spammers. =
It=92s actually quite simple, and, if accepted, would arguably be the =
most peaceful resolution to date.
If one were to develop a perfect "spam filter" that was universally =
available, and, in fact, FREE, would email spammers still spam? Of =
course. And they would still be happy. Why? Because there would still be =
10% or more Internet users that would not know how to activate this =
filter, that would not have access to this filter, or that otherwise =
wouldn=92t mind email spam and would deactivate this filter, or else =
tweak it so that only topics that interest them can be received. With =
the current pace of Internet growth, that number would still well-exceed =
millions at its lowest.
What if this filter required that the spammers had to admit they were =
spamming? Would they cooperate? No=85. Not unless the international =
governmental authorities (i.e. U.S. government, the UN government, etc.) =
stepped in and demanded a fine for invading the privacy of netizens =
without representation. That representation is simple: utilize a tag =
which e-mail clients can add to their outgoing bulk messages, showing =
that they are, indeed, bulk e-mail messages.
MESSAGE-TAG: PLENTY OF USEFUL INFO
The following tagging proposal comes from ReplyNet:
Pass a law that requires all unsolicited junk emailers to "code" their =
messages. This means the advertisement would leave the advertisers site =
with a six digit code in a standard location in the header of their =
message. The code could look like this:
=20
UAB031
=20
The first three characters would state what type of ad is being =
sent. (UAB might mean "unsolicited advertisement, blind recipient list") =
and the second three characters would state the products that are being =
offered in the ad. (The 031 might mean "lawn & garden products").
=20
Ok, why would this idea work? Because in 5 years from now your =
television set will likely be wired to the 'net and bandwidth will be =
a-plenty. Major advertisers (real ones that sell household cleaning =
products, automobiles, etc.) will want to send multimedia advertisements =
to a specific target audience via the 'net. If they all followed a =
standard coding scheme, you could easily block all, some, or groups of =
advertisers that you specify. If you didn't want any unsolicited =
advertising then you could turn on a filter to block any "UA" messages. =
But if you did want to receive ads on automobiles and auto-related =
products then you could accept UA but only group 055, for example.
=20
Received: (from adm at localhost) by icicle.yourstupiddomain.com =
(8.7.5/8.7.5) id UAA06557 for <mackie at yourstupiddomain.com>; Tue, 1 Apr =
1997 20:51:31 -0600 (CST)
Received: from here.mystupiddomain.com(204.246.64.78) by =
icicle.yourstupiddomain.com via smap (V2.0beta)
id xma006523; Tue, 1 Apr 97 20:51:05 -0600
Posted-Date: Tue, 1 Apr 1997 20:51:31 -0600 (CST)
Received-Date: Tue, 1 Apr 1997 20:51:31 -0600 (CST)
Message-Id: 199704020251.UAA06557 at icicle.yourstupiddomain.com
--> Message-Tag: UAB031
From: "Jon Davis" <mackie at yourstupiddomain.com>
To: <mackie at yourstupiddomain.com>
Subject: Spam, spam, spam, spam, green eggs & ham, spam, spam, =
spam....
Date: Tue, 1 Apr 1997 21:00:15 -0600
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=3DISO-8859-1
=20
The advantage of this method is that it adds the capability to mark =
what kind of product or service that the sender is marketing, whether =
it=92s for "Lawn & Garden" products or internet services, or whatever. =
This way the user can filter out all unsolicited messages, except for =
those that are related to their interests.
AN EXPANSION
Expanding ReplyNet's proposal could involve dividing the notations with =
a character=97say, a semicolon. This way, multiple categories and =
additional information could be entered.
For example:
Message-Tag: MUAB;C031;C382;C782
...could mean:
(a) Unsolicited Advertising Bulk mail;
(b) Lawn & Garden Services
(c) Tree & Shrubbery Information/Education
(d) Flower Therapeutic Dialogue
...where "M" denotes "Mail-type" and "C" denotes "Content/Product". In =
this way, up to 26 (or more) additional alphabetic notation types could =
be integrated in this compact line/tag.
For example:
Message-Tag: MUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N3987383
...could mean:
(a) (MUAB) Unsolicited Advertising Bulk mail;
(b) (C031) Content/Product =3D Lawn & Garden Services
(c) (C382) Content/Product =3D Tree & Shrubbery Information/Education
(d) (C782) Content/Product =3D Flower Therapeutic Dialogue
(e) (O987'Buds_Garden_Shop') Organization/company =3D #987, otherwise =
named "Buds Garden Shop" (the latter information given so that email =
programs/filters can keep a name for the company)
(f) (E34) Registered bulk email program is #34, which is "Publi-Send"
(g) (N3987383) 3,987,383 email addresses were on this list.
Each new Message-Tag tag type can be defined as the years pass by, as =
submitted to the IETF or some other Internet standards body. The =
government can then just require the MUAB tag for all unsolicited =
advertising bulk email, the other information would be done in =
cooperation (or not...)
Received: (from adm at localhost) by icicle.yourstupiddomain.com =
(8.7.5/8.7.5) id UAA06557 for <mackie at yourstupiddomain.com>; Tue, 1 Apr =
1997 20:51:31 -0600 (CST)
Received: from here.mystupiddomain.com(204.246.64.78) by =
icicle.yourstupiddomain.com via smap (V2.0beta)
id xma006523; Tue, 1 Apr 97 20:51:05 -0600
Posted-Date: Tue, 1 Apr 1997 20:51:31 -0600 (CST)
Received-Date: Tue, 1 Apr 1997 20:51:31 -0600 (CST)
Message-Id: 199704020251.UAA06557 at icicle.yourstupiddomain.com
--> Message-Tag: =
MUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N3987383
From: "Jon Davis" <mackie at yourstupiddomain.com>
To: <mackie at yourstupiddomain.com>
Subject: Spam, spam, spam, spam, green eggs & ham, spam, spam, =
spam....
Date: Tue, 1 Apr 1997 21:00:15 -0600
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=3DISO-8859-1
The DMA (Direct Marketing Association) could perhaps be contacted to =
find out how in-depth the details are concerning product information =
coding techniques used in paper mail.
DEALING WITH NETWORK TRAFFIC
One of the biggest problems with tagging bulk email in the header alone =
is that it does little for controlling network traffic. Spammed email =
messages must be fully downloaded to the recipient's mailbox or ISP =
before it can be successfully filtered, which many claim to be "theft of =
resources," not unlike unsolicited faxing. Because it may offer a form =
of "push" technology for those that wish to only receive email of =
certain topics, the mass commerce email trend would grow on the Internet =
violently. Often, users must pay for Internet access by the minute, and =
so the spam traffic can get to be quite expensive. Ultimately, the =
problem would eliminate the primary point of controlling spam: it's =
still a waste of resources.
SEPARATING THE PORT
One plausible solution for controlling spam traffic on the server end =
would be to require all unsolicited email to be sent on a separate =
Internet port than port 25, such as port number 7726. In this way, =
advertisers can network their bulk email using an alternative port, =
specially dedicated to spam. Servers not interested in receiving bulk =
e-mail can simply not install this port. Assuming the government were to =
cooperate, all bulk email sent on port 25 would be considered illegal =
and worthy of prosecution of the highest degree possible.
TAGGING THE "ENVELOPE"
Another solution could be to add the unsolicited email tag to the =
envelope of the message, in addition to the tag in the body. This way, =
SMTP servers can refuse to download any e-mail messages that have this =
tag in the envelope. In addition, the additional information within the =
tag (as explained above) beyond the spam tag could prove extremely =
useful in defining whether or not to accept or how to route an incoming =
message.
SMTP (Simple Mail Transport Protocol) consists of a message-forwarding =
tactic, where the each server in the process says to the next, "Hello. =
Here, this is an entire email message somebody wants sent to Mr. Foobar. =
Please forward the message to the next nearest server to Mr. Foobar. =
Thanks. Bye."
When a message is sent from one server to another, three fields are =
sent: MAIL (from), RCPT (to), and DATA (the message). This is currently =
the only "envelope" a message contains, outside of the message's header, =
which, again, cannot be accessed unless the entire message is =
downloaded. In other words, the message's header is part of the actual =
message.
HELO
250 ICICLE.YOURSTUPIDDOMAIN.COM (204.246.64.78)
MAIL FROM <mackie at mystupiddomain.com>
250 OK
RCPT TO <you at yourstupiddomain.com>
250 OK
DATA
354 Start mail input, end with <CALF>.<CALF>
The IETF has constructed a means of implementing additional =
extensions to the SMTP framework, a system known as ESMTP. This allows =
for additional functions to be added to our "envelope". =
Utilizing/requesting ESMTP service from a host involves changing the =
HELO (hello) command to EHLO, and the host response with a return =
"hello," along with a list of compatible extensions.
EHLO
250 dbc.mtview.ca.us says hello
250-8BITMIME
MAIL FROM <mackie at mystupiddomain.com> BODY=3D8BITMIME
250 OK... Sender and 8BITMIME ok
RCPT TO <you at yourstupiddomain.com>
250 OK
DATA
354 Start mail input, end with <CALF>.<CALF>
The "TAG" Extension
By using the TAG extension before sending the individual messages, the =
recipient server can moderate the spams that it downloads, if any. =
Incompatible systems will simply reflect a "500 SYNTAX ERROR" message =
upon connecting with the EHLO command, or else will not reflect the =
compatibility with the TAG extension, and the message will not be sent.
The sending (client) server scans each message's header to see if it =
contains the spam tag. If so, if the receiving (host) server accepts =
spammed messages, each spam is marked with another TAG extension along =
with the MAIL FROM command, marking the message as a spam (or an =
unsolicited bulk email message), along with additional TAG-related =
information.
Both systems incompatible, bulk message is sent:
HELO
250 dbc.mtview.ca.us says hello
MAIL FROM <mackie at mystupiddomain.com>
250 OK
RCPT TO <you at yourstupiddomain.com>
250 OK
DATA
354 Start mail input, end with <CALF>.<CALF>
=20
=
-------------------------------------------------------------------------=
---
Incompatible system, bulk message is not sent:
EHLO
500 SYNTAX ERROR
QUIT
=20
=
-------------------------------------------------------------------------=
---
Incompatible system, bulk message is not sent:
EHLO
250 dbc.mtview.ca.us says hello
250-EXPN
250-HELP
250-8BITMIME
250-XONE
250 XVRB
QUIT
=20
=
-------------------------------------------------------------------------=
---
Incompatible system, bulk message is not sent, non-bulk messages are =
sent in same session:
EHLO
500 SYNTAX ERROR
HELO
250 dbc.mtview.ca.us says hello
MAIL FROM <george at foobar.com>
250 OK
RCPT TO <you at yourstupiddomain.com>
250 OK
DATA
354 Start mail input, end with <CALF>.<CALF>
=20
=
-------------------------------------------------------------------------=
---
Compatible system, refused spam:
EHLO
250 dbc.mtview.ca.us says hello
250-EXPN
250-HELP
250-8BITMIME
250-XONE
250 XVRB
250-TAG
MAIL FROM <mackie at mystupiddomain.com> =
TAG=3DMUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N3987383
523 Refused--no spam allowed
QUIT
=20
=
-------------------------------------------------------------------------=
---
Compatible system, no spam allowed, other non-spam messages sent in =
the same session:
EHLO
250 dbc.mtview.ca.us says hello
250-EXPN
250-HELP
250-8BITMIME
250-XONE
250 XVRB
250-TAG
MAIL FROM <george at foobar.com> =
TAG=3DMUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N3987383
523 Refused--no spam allowed
MAIL FROM <george at foobar.com>
250 OK
RCPT TO <you at yourstupiddomain.com>
250 OK
DATA
354 Start mail input, end with <CALF>.<CALF>
=20
=
-------------------------------------------------------------------------=
---
Compatible system, accepted spam:
EHLO
250 dbc.mtview.ca.us says hello
250-EXPN
250-HELP
250-8BITMIME
250-XONE
250 XVRB
250-TAG
MAIL FROM <mackie at mystupiddomain.com> =
TAG=3DMUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N3987383
250 Ok.
RCPT TO <you at yourstupiddomain.com>
250 OK
DATA
354 Start mail input, end with <CALF>.<CALF>
=20
GOVERNMENTAL AUTHORIY SUPPORT
By legally requiring all unsolicited email messages to contain the bulk =
mail identifier tag in the header, netizens can be guaranteed that no =
spam will enter their emailboxes without the ability to filter every one =
of them. In this way, spammers=97or net-savvy marketers=97will still be =
able to legally send as much unsolicited email as they please. All that =
they are required to do is to admit what they are doing. Not doing so =
should be cause for a fine, not unlike the current fine established by =
the U.S. government for unsolicited faxes. Such a fine should be a bit =
smaller; remember, it=92s easier to send bulk email than bulk faxes, so =
fines for each complaining recipient could add up to a great deal, =
beyond payment ability. Also, obviously, a time lapse of at least two =
years should be given before such fines would actually start taking =
place, allowing for email software producers to upgrade the =
functionality of their email client software to include the new header =
tag.
While it is unrealistic to expect all countries involved with the =
Internet to cooperate, if the U.S. and UN Governments alone were to =
cooperate, this would allow control for 90% of all bulk emailings. Other =
countries not cooperating would be pressured into joining the etiquette. =
U.S. and UN citizens hiring businesses in other countries to spam =
without adding the header tag would still be at fault if the email =
business does not assume responsibility for the non-tagged messages, =
since the spam was created by the citizen. If the business does assume =
responsibility for the non-tagged messages, they would not only =
jeopardize their business, but also, in many ways, their country.
Unfortunately, for the U.S., finding government involvement has been a =
chore. More often than not, our leaders have been regularly advised to =
keep out of the affairs of the Internet. While freedom of speech has =
been a joy to toy with in this "lawless paradise", the arguments used in =
suggesting that governing bodies should keep out of its affairs are =
nothing short of absurd. These are the same individuals that think that =
cyberspace is nothing more than several cables spanned out across the =
States and to other countries, for the exchange of pretty pictures and =
educational data. The truth, however, is that Internet cyberspace has =
become a communications medium, as well as many other things, and, for =
the U.S. and its citizens, it belongs in the hands of the Federal =
Communications Commission. Spam is just one of many, many ways the =
Internet, a communications medium, is being seriously abused, and its =
results are not unlike the abuse of telephones and facsimiles. This =
reality should be taken seriously.
ON THE DOWN SIDE
Several valid arguments in response to this proposal have been =
presented. A common argument is the problem of "revamping the entire =
email system" in order to see this tagging system implemented. Granted, =
compatible systems would have to conform to the standard, but remember: =
the Internet is young--it is still being founded. We have seen very =
little in comparison to what lies ahead, spam included. Even if it does =
take a couple years for this system to be successfully implemented, it =
would be a worthwhile trip, and patience is the key.
Other common arguments are generally poor, however, as they do not =
reflect the entire proposal presented here. One such argument is that =
there is no guarantee that the spammer will include this tag. First, a =
law to make tagged spams mandatory would require the spammer to do so if =
the spammer is a citizen of that government, or else lead the spammer to =
be charged a serious fine or face other similar prosecution. Since most =
spams originate from the U.S. or the UN, these governments alone would =
cover a broad spectrum of spams. Second, by making the tag an =
Internet-wide standard, all major email programs would include the tag =
in its design, requiring the "newbie" spam author to tag which type of =
message he is sending, without pressure from the recipients. Also, =
eliminating such pressure from "spam haters" by partially legalizing =
spam as long as it has this header would cause the spammers to be much =
less defiant/uncooperative/cheating of the system. Third, anyone caught =
"cheating the system" (changing the header, throwaway accounts, account =
fraudulence, posting on another private SMTP server, etc.) should be =
prosecuted severely. For the U.S., this is an issue the FCC is =
increasingly urged to comply with.
LAST WORDS
While regulation must be taken very carefully when dealing with the =
Internet, this kind of cooperation between netizens and international =
government authorities could be among the healthiest and wisest =
implementations of Internet and government merges to date on the =
Internet. I feel this is perhaps the best method of controlling spam =
currently being proposed, as it continues to give all users complete =
freedom of speech, while at the same time giving all users freedom of =
privacy.
I hope this presentation is both clear and precise, and I hope it =
provides a closer answer to the Internet peace we are all looking for.
Presented by Jon Davis, newbreed at isd.net
"Shh dear, don't cause a fuss. I'll have your spam. I love it. I'm =
having spam, spam, spam, spam, spam, spam, spam, baked beans, spam, =
spam, spam and spam."
------=_NextPart_000_01BC50AD.6F611950
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<HTML><META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR>
</HEAD>
<BODY background=3Dhttp://www.winternet.com/~mackie/spam/images/spam.gif =
bgColor=3D#FFFFFF link=3D#004080 vLink=3D#3C7997><FONT face=3DArial =
size=3D2>
<H1 align=3Dcenter><FONT color=3D#FFFFFF face=3D"" size=3D-2>This =
proposal is formatted=20
in HTML. If you would like to see the HTML version on your web browser, =
please=20
visit http://www.winternet.com/~mackie/spam</FONT></H1>
<H1 align=3Dcenter><IMG alt=3D"Spam Control Proposal: Tagging =
Bulk/Unsoliced E-mail"=20
height=3D194 readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/spamcontrol.gif"=20
width=3D450></H1>
<P align=3Dcenter> </P>
<H1 align=3Dcenter><A href=3D"#Purpose"><FONT size=3D6><IMG =
align=3Dmiddle alt=3DPURPOSE=20
border height=3D25 readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/purpose.gif"=20
width=3D47></FONT></A><FONT size=3D6> | </FONT><A =
href=3D"#Banning_Spam"><FONT=20
size=3D6><IMG align=3Dmiddle alt=3D"BANNING SPAM" border height=3D25 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/banning_spam.gif"=20
width=3D85></FONT></A><FONT size=3D6> | </FONT><A =
href=3D"#Junk_Mail"><FONT=20
size=3D6><IMG align=3Dmiddle alt=3D"JUNK EMAIL =3D CONTENT" border =
height=3D25=20
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/JunkMailContent.gif"; =
width=3D127></FONT></A><FONT size=3D6> | </FONT><A =
href=3D"#Current_Filters"><FONT=20
size=3D6><IMG align=3Dmiddle alt=3D"CURRENT FILTERS" border height=3D22 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/CurrentFilters.gif"=20
width=3D86></FONT></A></H1>
<H1 align=3Dcenter><A href=3D"#Cooperation"><FONT size=3D6><IMG =
align=3Dmiddle=20
alt=3D"WITH A LITTLE COOPERATION, EVERYONE CAN BE HAPPY" border =
height=3D25=20
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/cooperationhappy.gif"=
=20
width=3D298></FONT></A><FONT color=3D#FFFFFF size=3D6>|</FONT></H1>
<H1 align=3Dcenter><A href=3D"#Message-Tag"><FONT size=3D6><IMG =
align=3Dmiddle=20
alt=3D"MESSAGE-TAG: PLENTY OF USEFUL INFO" border height=3D25 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/message-tag.gif"=20
width=3D211></FONT></A><FONT size=3D6> | </FONT><A =
href=3D"#Network_Traffic"><FONT=20
size=3D6><IMG align=3Dmiddle alt=3D"DEALING WITH NETWORK TRAFFIC" border =
height=3D25=20
readyState=3D4 =
src=3D"http://www.winternet.com/~mackie/spam/images/nt-traffic.gif"=20
width=3D178></FONT></A></H1>
<H1 align=3Dcenter><A href=3D"#Government_Support"><FONT =
size=3D6><STRONG><IMG=20
align=3Dmiddle alt=3D"GOVERNMENTAL AUTHORITY SUPPORT" border height=3D25 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/governmentalsupport.g=
if"=20
width=3D196></STRONG></FONT></A><FONT size=3D6> | </FONT><A =
href=3D"#Down_Side"><FONT=20
size=3D6><IMG align=3Dmiddle alt=3D"ON THE DOWN SIDE" border height=3D22 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/downside.gif"=20
width=3D108></FONT></A><FONT size=3D6> | </FONT><A =
href=3D"#Last_Words"><FONT=20
size=3D6><IMG align=3Dmiddle alt=3D"LAST WORDS" border height=3D22 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/lastwords.gif"=20
width=3D65></FONT></A></H1>
<HR color=3D#000000 noShade SIZE=3D3 width=3D80%>
<P><A name=3DPurpose><FONT size><IMG alt=3DPURPOSE height=3D25 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/purpose.gif"=20
width=3D47></FONT></A><FONT size><FONT color=3D#FFFFFF face=3D""=20
size=3D-2>PURPOSE</FONT><BR>
</FONT><A href=3D"http://www.pcwebopaedia.com/spam.htm";><FONT size>Email =
spam</FONT></A><FONT size> is rampant these days, as we all know and =
shudder. It=20
seems the lawsuits and arguments never end. No feasible resolution has =
been=20
submitted, probably because no one dares swim against the stream of free =
speech=20
Internet activists that bog down the issue and leave our mailboxes =
flooded with=20
unwanted junk.</FONT></P>
<P><FONT size>Sadly, those free speech Internet activists are, in many =
ways,=20
correct. The communications medium of the Internet has been built to be=20
completely public. While the debate continues comparing unsolicited =
faxes with=20
unsolicited emails, the other debate also continues comparing =
unsolicited emails=20
with unsolicited paper mail. Email is stuck in the middle of the two =
media. A=20
fair and peaceful compromise between the spammers and the recipients is=20
therefore in high demand.</FONT></P>
<P><FONT size>While most major functions of the Internet were proposed =
formally=20
by volunteer Internet standards groups, several other aspects of the =
Internet=20
were <EM>not. </EM>One major aspect being overlooked by standards =
committees is=20
the one thing that is driving the Internet at full-force, while at the =
same time=20
bringing the Internet to its knees: industrial commerce and marketing. =
The=20
greater commerce technologies currently being developed are often not =
built on=20
or as universal Internet standards. They are instead introduced as =
public-appeal=20
Internet usages that become "standards" only by their =
popularity.=20
While this is not always <EM>bad, </EM>direct email marketing is an =
example of=20
Internet commerce <EM>abusing</EM> a communications medium to an extent =
and in a=20
way that it simply was not designed for.</FONT></P>
<P><A name=3DBanning_Spam><FONT size=3D6><IMG align=3Dmiddle =
alt=3D"BANNING SPAM"=20
height=3D25 readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/banning_spam.gif"=20
width=3D85></FONT></A><FONT size><FONT color=3D#FFFFFF face=3D"" =
size=3D-2>BANNING=20
SPAM</FONT><BR>
Unsolicited e-mail today is illegal in several countries, and the United =
States=20
is <EM>not</EM> one of them, and neither is much of the UN. Spam is a =
waste of=20
resources. It is expensive to maintain. It is annoying. It is theft of =
Internet=20
connectivity and system functionality. It is, in fact, downright=20
<EM>wrong.</EM></FONT></P>
<P><FONT size>Unsolicited e-mail does not appropriately compare with =
paper junk=20
mail. In the paper junk mail system, the advertiser pays their local =
direct=20
marketing company, who then pays the United States Postal Service (or =
your local=20
country's postal service) to deliver the message by hand to your =
mailbox. For a=20
single paper mail message sent costing $.32 each (not counting the costs =
for the=20
tangible, useful, physical contents), 1,000,000 paper mailings would =
cost the=20
direct marketer $320,000. In contrast, with unsolicited e-mail, the =
advertiser=20
pays the direct marketer, who then makes a simple connection to the =
Internet.=20
The e-mail is sent to a nearby server, which has its own connection to =
the=20
Internet. It then passes the e-mail messages to the next best servers =
for each=20
of these recipients. Each of those servers must then forward the e-mail =
messages=20
to the next server, and this pattern continues until each copy of the =
message is=20
delivered to each recipient. One million copies of such a message would =
cost the=20
direct marketer <EM>approximately</EM> (extremely approximately) $500, =
while the=20
rest of the Internet must dish out <EM>approximately</EM> $20,000 to =
deliver=20
each and every last message. This would seem to make the spammer an =
Internet=20
thief, or "pirate" of Internet resources.</FONT></P>
<P><FONT size>A common response is, "Spam is theft. Let's =
<EM>ban</EM> all=20
spam, outright." While this would seem to be an easy solution, a =
few common=20
questions remain (albeit, some less legitimate than others):</FONT></P>
<OL>
<LI><FONT size>What about the occasional unsolicited messages people =
receive that they desire to continue receiving? (Yes, these =
people exist=20
and are much more common than you realize.)</FONT></LI>
<LI><FONT size>What about the legitimacy behind the thought of =
direct=20
marketing?</FONT></LI>
<LI><FONT size>The Internet consists of a number of servers that =
have=20
agreed in a worldwide understanding to willfully transfer =
Internet=20
packets that may or may not be related to their interests. An =
example of=20
this is the transfer of RealAudio packets or Internet telephone =
packets=20
or even web page files. Why is junk e-mail such a different=20
situation--it takes much less bandwidth than these other=20
things!</FONT></LI>
<LI><FONT size>I have a brand new product that no one else knows =
about.=20
Posting a web page does nothing, because no one knows it exists. =
I=20
cannot afford "professional" means of advertising. Why =
can't I=20
just e-mail at least those individuals who I think might be =
interested=20
in my product?</FONT></LI>
<LI><FONT size>What if I am trying to send a message to long-lost =
family=20
or forgotten friends or am trying to reach people I have never =
met=20
before? How can you <EM>define</EM> what is unsolicited junk =
mail and=20
what is unsolicited legitimate email?</FONT></LI>
<LI><FONT size>What about freedom of speech?</FONT></LI>
</OL>
<P><FONT size>Many argue that most spammers are not so simple-minded and =
willfully spam as a malicious, careless, unthoughtful act of greed. =
While many=20
"experts" in spamming may have such attributes, the future of =
the=20
Internet will involve extremely naive, ignorant netizens who don't =
understand=20
Internet etiquette, and would be willing to conform to it if pressed by =
the=20
government.</FONT></P>
<HR align=3Dleft SIZE=3D1 width=3D50%>
<P><FONT size>As an alternative to banning spam altogether, the =
following is a=20
proposal to the IETF and to the Internet community that may help =
establish a=20
means of resolving this issue by 1) still allowing for total freedom of =
publicly=20
sending unsolicited email (direct mail marketing), while 2) providing =
for a=20
complete filter for servers and people people who desire to keep their =
mailboxes=20
clean, provided that the sender cooperates with this system (under the =
pressure=20
of governmental law). It would also require the cooperation of =
governmental=20
authorities to enforce the system, especially including the U.S. and UN=20
governments.</FONT></P>
<HR align=3Dleft color=3D#000000 noShade SIZE=3D3 width=3D50%>
<P><A name=3DCurrent_Filters><FONT size><IMG alt=3D"CURRENT FILTERS" =
height=3D22=20
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/CurrentFilters.gif"=20
width=3D86></FONT></A><FONT size><FONT color=3D#FFFFFF face=3D"" =
size=3D-2>CURRENT=20
FILTERS</FONT><BR>
Filter technology today most commonly consists of email envelope and =
header=20
screening. This means that the email server and/or client can look at =
the header=20
or envelope of an email, and if it meets certain criteria, it will be =
purged.=20
Currently, the only portions of the email header which the filter can =
examine=20
for such screening are 1) the sender=92s email address; 2) the =
"travel=20
path" of the email message=97where it came from and what servers it =
went=20
through in order to get to the destination; and 3) the X-mailer header =
to=20
determine what software was used to produce the message.</FONT></P>
<P><FONT size>Therefore, the most common types of email filters =
are:</FONT></P>
<OL>
<LI><FONT size>purge emails that come from an email address that is=20
included in an updated, publicly accessible "spammer"=20
list;</FONT></LI>
<LI><FONT size>purge emails that come from a particular internet =
domain=20
or IP address;</FONT></LI>
<LI><FONT size>purge emails that can be tracked down by looking at =
their=20
history remarks and can be found to be included in a =
"spammer"=20
list and/or are a member of a particular domain or IP address (1 =
&=20
2);</FONT></LI>
<LI><FONT size>purge the email if it was produced by a certain type =
of=20
software; or</FONT></LI>
<LI><FONT size>refuse to download any incoming email messages coming =
from a particular domain or IP address (envelope =
screening).</FONT></LI>
</OL>
<P><FONT size>None of these methods are ideal.</FONT></P>
<OL>
<LI><FONT size>The first method is simply not complete in any way; =
there=20
are millions of email users, and each one of them has the =
ability to=20
spam. Therefore, no updated list will ever be able to keep track =
of all=20
potential spammers on the Internet. In addition, not all email =
messages=20
from potential spammers on the "spammer" list are=20
spams.</FONT></LI>
<LI><FONT size>The second and fifth methods are worse=97they make =
the=20
assumption that all email users of a given domain are spammers; =
worse=20
yet, they also make the assumption that all emails coming from =
those=20
users are spams. Therefore, this filter type will purge =
legitimate=20
emails coming from legitimate sources, just because they come =
from an=20
ISP or other mail server that has been known to carry =
spams.</FONT></LI>
<LI><FONT size>The third method is used to track forged email, but =
it is=20
not only prone to error, it also carries the problems of the =
first two=20
methods by utilizing their techniques.</FONT></LI>
<LI><FONT size>Finally, eliminating all email that was created by a=20
certain type of email software could and would also eliminate =
legitimate=20
email from all types of mailing lists that users are =
intentionally=20
subscribed to.</FONT></LI>
</OL>
<P><FONT size>There are other filter methods being looked into, but =
these five=20
methods are the most common filter methods today.</FONT></P>
<P><FONT size><BR>
</FONT><A name=3DJunk_Mail><FONT size><IMG alt=3D"JUNK EMAIL =3D =
CONTENT" height=3D25=20
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/JunkMailContent.gif"; =
width=3D127></FONT></A><FONT size><FONT color=3D#FFFFFF face=3D"" =
size=3D-2>JUNK MAIL =3D=20
CONTENT</FONT><BR>
The problem with header-type filters is that junk email should be =
determined by=20
content, not by sender. It is the sender=92s intentions and message =
within the=20
body that proves an email message as junk mail. The only accurate way to =
successfully filter spammed email, therefore, is to note the content =
and/or=20
intent of the message, not the message=92s source, and if a user does =
not want=20
spam, he can simply activate the content-type filter to purge messages =
with spam=20
content.</FONT></P>
<P><FONT size>But how is this possible? It isn=92t. No artificial =
intelligence=20
will EVER, by any means, be able to determine what is junk mail and what =
is=20
legitimate. Please, DO NOT WASTE YOUR TIME trying to develop this =
technology,=20
because the spammers will simply find another way to communicate their =
message=20
to "sound" personal, bypassing your filter.</FONT></P>
<P><FONT size>Therefore, we=92re stuck. Literally. There is currently no =
way for a=20
filter to determine spams from non-spams with 100% accuracy. The only =
way=20
filters can currently work is by asking, "Where did it come =
from?"=20
not, "Is this a spam?" and we NEED to find a way to develop =
such a=20
filter, one that can determine, "Is this a spam?"</FONT></P>
<P><FONT size><BR>
</FONT><A name=3DCooperation><FONT size><IMG=20
alt=3D"WITH A LITTLE COOPERATION, EVERYONE CAN BE HAPPY" height=3D25 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/cooperationhappy.gif"=
=20
width=3D298></FONT></A><FONT size><FONT color=3D#FFFFFF face=3D"" =
size=3D-2>WITH A=20
LITTLE COOPERATION, EVERYONE CAN BE HAPPY.</FONT><BR>
There <I>is</I> a way such a filter can be done. It requires a little=20
cooperation from the IETF, governmental authorities, and, yes, spammers. =
It=92s=20
actually quite simple, and, if accepted, would arguably be the most =
peaceful=20
resolution to date.</FONT></P>
<P><FONT size>If one were to develop a perfect "spam filter" =
that was=20
universally available, and, in fact, FREE, would email spammers still =
spam? Of=20
course. And they would still be happy. Why? Because there would still be =
10% or=20
more Internet users that would not know how to activate this filter, =
that would=20
not have access to this filter, or that otherwise wouldn=92t mind email =
spam and=20
would deactivate this filter, or else tweak it so that only topics that =
interest=20
them can be received. With the current pace of Internet growth, that =
number=20
would still well-exceed millions at its lowest.</FONT></P>
<P><FONT size>What if this filter required that the spammers had to =
admit they=20
were spamming? Would they cooperate? <EM>No</EM>=85. Not unless the =
international=20
governmental authorities (i.e. U.S. government, the UN government, etc.) =
stepped=20
in and demanded a fine for invading the privacy of netizens without=20
representation. That representation is simple: utilize a tag which =
e-mail=20
clients can add to their outgoing bulk messages, showing that they are, =
indeed,=20
bulk e-mail messages.</FONT></P>
<P><FONT size><BR>
</FONT><A name=3DMessage-Tag><FONT size><IMG=20
alt=3D"MESSAGE-TAG: PLENTY OF USEFUL INFO" height=3D25 readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/message-tag.gif"=20
width=3D211></FONT></A><FONT color=3D#FFFFFF face=3D"" =
size=3D-2>MESSAGE-TAG: PLENTY OF=20
USEFUL INFO</FONT></P>
<P><FONT size>The following tagging proposal comes from </FONT><A=20
href=3D"http://www.reply.net";><FONT size>ReplyNet</FONT></A><FONT=20
size>:</FONT></P>
<BLOCKQUOTE>
<P><FONT color=3D#004080 size=3D2><STRONG>Pass a law that requires =
all=20
unsolicited junk emailers to "code" their messages. This =
means the=20
advertisement would leave the advertisers site with a six digit code =
in a=20
standard location in the header of their message. The code could =
look like=20
this:<BR>
<BR>
UAB031<BR>
<BR>
The first three characters would state what type of ad is being =
sent. (UAB=20
might mean "unsolicited advertisement, blind recipient =
list") and=20
the second three characters would state the products that are being =
offered=20
in the ad. (The 031 might mean "lawn & garden =
products").<BR>
<BR>
Ok, why would this idea work? Because in 5 years from now your =
television=20
set will likely be wired to the 'net and bandwidth will be a-plenty. =
Major=20
advertisers (real ones that sell household cleaning products, =
automobiles,=20
etc.) will want to send multimedia advertisements to a specific =
target=20
audience via the 'net. If they all followed a standard coding =
scheme, you=20
could easily block all, some, or groups of advertisers that you =
specify. If=20
you didn't want any unsolicited advertising then you could turn on a =
filter=20
to block any "UA" messages. But if you did want to receive =
ads on=20
automobiles and auto-related products then you could accept UA but =
only=20
group 055, for example.</STRONG></FONT></P>
=20
<P> </P>
=20
<P><FONT size=3D1><STRONG>Received: (from adm at localhost) by=20
icicle.yourstupiddomain.com (8.7.5/8.7.5) id UAA06557 for=20
<mackie at yourstupiddomain.com>; Tue, 1 Apr 1997 20:51:31 -0600=20
(CST)<BR>
Received: from here.mystupiddomain.com(204.246.64.78) by=20
icicle.yourstupiddomain.com via smap (V2.0beta)<BR>
id xma006523; Tue, 1 Apr 97 20:51:05 -0600<BR>
Posted-Date: Tue, 1 Apr 1997 20:51:31 -0600 (CST)<BR>
Received-Date: Tue, 1 Apr 1997 20:51:31 -0600 (CST)<BR>
Message-Id: 199704020251.UAA06557 at icicle.yourstupiddomain.com<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>--> =
Message-Tag:=20
UAB031</STRONG></FONT><FONT size=3D1><STRONG><BR>
From: "Jon Davis" <mackie at yourstupiddomain.com><BR>
To: <mackie at yourstupiddomain.com><BR>
Subject: Spam, spam, spam, spam, green eggs & ham, spam, spam,=20
spam....<BR>
Date: Tue, 1 Apr 1997 21:00:15 -0600<BR>
X-MSMail-Priority: Normal<BR>
X-Priority: 3<BR>
X-Mailer: Microsoft Internet Mail 4.70.1161<BR>
MIME-Version: 1.0<BR>
Content-Transfer-Encoding: 7bit<BR>
Content-Type: text/plain; charset=3DISO-8859-1</STRONG></FONT></P>
=20
<P> </P>
=20
</BLOCKQUOTE>
<P><FONT size=3D+0>The advantage of this method is that it adds the =
capability to=20
mark what kind of product or service that the sender is marketing, =
whether it=92s=20
for "Lawn & Garden" products or internet services, or =
whatever.=20
This way the user can filter out all unsolicited messages, except for =
those that=20
are related to their interests.</FONT></P>
<P><STRONG>AN EXPANSION</STRONG><BR>
<FONT size>Expanding ReplyNet's proposal could involve dividing the =
notations=20
with a character</FONT><FONT size=3D4>=97</FONT><FONT size>say, a =
semicolon. This=20
way, multiple categories and additional information could be =
entered.</FONT></P>
<P><FONT size=3D2><STRONG>For example:<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D2><STRONG>Message-Tag:=20
</STRONG></FONT><FONT color=3D#804040 =
size=3D2><STRONG>MUAB</STRONG></FONT><FONT=20
color=3D#FF0000 size=3D2><STRONG>;C031;</STRONG></FONT><FONT =
color=3D#804040=20
size=3D2><STRONG>C382</STRONG></FONT><FONT color=3D#FF0000=20
size=3D2><STRONG>;C782</STRONG></FONT></P>
<P><FONT size=3D2><STRONG>...could mean:</STRONG></FONT></P>
<UL>
<LI><FONT size=3D2>Unsolicited Advertising Bulk mail;</FONT></LI>
<LI><FONT size=3D2>Lawn & Garden Services</FONT></LI>
<LI><FONT size=3D2>Tree & Shrubbery =
Information/Education</FONT></LI>
<LI><FONT size=3D2>Flower Therapeutic Dialogue</FONT></LI></UL>
<P><FONT size>...where "M" denotes "Mail-type" and=20
"C" denotes "Content/Product". In this way, up to 26 =
(or=20
more) additional alphabetic notation types could be integrated in this =
compact=20
line/tag.</FONT></P>
<P><FONT size><STRONG>For example:</STRONG></FONT><FONT size=3D2><BR>
</FONT><FONT color=3D#FF0000 size=3D2><STRONG>Message-Tag: =
</STRONG></FONT><FONT=20
color=3D#804040 size=3D2><STRONG>MUAB;</STRONG></FONT><FONT =
color=3D#FF0000=20
size=3D2><STRONG>C031;</STRONG></FONT><FONT color=3D#804040=20
size=3D2><STRONG>C382;</STRONG></FONT><FONT color=3D#FF0000=20
size=3D2><STRONG>C782;</STRONG></FONT><FONT color=3D#804040=20
size=3D2><STRONG>O987'Buds_Garden_Shop';</STRONG></FONT><FONT =
color=3D#FF0000=20
size=3D2><STRONG>E34;</STRONG></FONT><FONT color=3D#804040=20
size=3D2><STRONG>N3987383</STRONG></FONT></P>
<P><FONT size><STRONG>...could mean:</STRONG></FONT></P>
<UL>
<LI><FONT size=3D2>(</FONT><FONT color=3D#804040=20
size=3D2><STRONG>MUAB</STRONG></FONT><FONT size=3D2>) Unsolicited =
Advertising=20
Bulk mail;</FONT></LI>
<LI><FONT size=3D2>(</FONT><FONT color=3D#FF0000=20
size=3D2><STRONG>C031</STRONG></FONT><FONT size=3D2>) =
Content/Product =3D Lawn=20
& Garden Services</FONT></LI>
<LI><FONT size=3D2>(</FONT><FONT color=3D#804040=20
size=3D2><STRONG>C382</STRONG></FONT><FONT size=3D2>) =
Content/Product =3D Tree=20
& Shrubbery Information/Education</FONT></LI>
<LI><FONT size=3D2>(</FONT><FONT color=3D#FF0000=20
size=3D2><STRONG>C782</STRONG></FONT><FONT size=3D2>) =
Content/Product =3D Flower=20
Therapeutic Dialogue</FONT></LI>
<LI><FONT size=3D2>(</FONT><FONT color=3D#804040=20
size=3D2><STRONG>O987'Buds_Garden_Shop</STRONG>'</FONT><FONT =
size=3D2>)=20
Organization/company =3D #987, otherwise named "Buds Garden =
Shop"=20
(the latter information given so that email programs/filters can =
keep a name=20
for the company)</FONT></LI>
<LI><FONT size=3D2>(</FONT><FONT color=3D#FF0000=20
size=3D2><STRONG>E34</STRONG></FONT><FONT size=3D2>) Registered bulk =
email=20
program is #34, which is "Publi-Send"</FONT></LI>
<LI><FONT size=3D2>(</FONT><FONT color=3D#804040=20
size=3D2><STRONG>N3987383</STRONG></FONT><FONT size=3D2>) 3,987,383 =
email=20
addresses were on this list.</FONT></LI></UL>
<P><FONT size>Each new Message-Tag tag type can be defined as the years =
pass by,=20
as submitted to the IETF or some other Internet standards body. The =
government=20
can then just require the MUAB tag for all unsolicited advertising bulk =
email,=20
the other information would be done in cooperation (or =
not...)</FONT></P>
<BLOCKQUOTE>
<P><FONT size=3D1><STRONG>Received: (from adm at localhost) by=20
icicle.yourstupiddomain.com (8.7.5/8.7.5) id UAA06557 for=20
<mackie at yourstupiddomain.com>; Tue, 1 Apr 1997 20:51:31 -0600=20
(CST)<BR>
Received: from here.mystupiddomain.com(204.246.64.78) by=20
icicle.yourstupiddomain.com via smap (V2.0beta)<BR>
id xma006523; Tue, 1 Apr 97 20:51:05 -0600<BR>
Posted-Date: Tue, 1 Apr 1997 20:51:31 -0600 (CST)<BR>
Received-Date: Tue, 1 Apr 1997 20:51:31 -0600 (CST)<BR>
Message-Id: 199704020251.UAA06557 at icicle.yourstupiddomain.com<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>--> =
Message-Tag:=20
=
MUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N3987383</STRONG></FONT><F=
ONT=20
size=3D1><STRONG><BR>
From: "Jon Davis" <mackie at yourstupiddomain.com><BR>
To: <mackie at yourstupiddomain.com><BR>
Subject: Spam, spam, spam, spam, green eggs & ham, spam, spam,=20
spam....<BR>
Date: Tue, 1 Apr 1997 21:00:15 -0600<BR>
X-MSMail-Priority: Normal<BR>
X-Priority: 3<BR>
X-Mailer: Microsoft Internet Mail 4.70.1161<BR>
MIME-Version: 1.0<BR>
Content-Transfer-Encoding: 7bit<BR>
Content-Type: text/plain; charset=3DISO-8859-1</STRONG></FONT></P>
=20
</BLOCKQUOTE>
<P><FONT size>The DMA (Direct Marketing Association) could perhaps be =
contacted=20
to find out how in-depth the details are concerning product information =
coding=20
techniques used in paper mail.<BR>
</FONT></P>
<P><FONT size=3D6><A name=3DNetwork_Traffic><IMG align=3Dmiddle=20
alt=3D"DEALING WITH NETWORK TRAFFIC" height=3D25 readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/nt-traffic.gif"=20
width=3D178></FONT></A><FONT size><FONT color=3D#FFFFFF face=3D"" =
size=3D-2>DEALING WITH=20
NETWORK TRAFFIC</FONT><BR>
One of the biggest problems with tagging bulk email in the header alone =
is that=20
it does little for controlling network traffic. Spammed email messages =
must be=20
fully downloaded to the recipient's mailbox or ISP before it can be =
successfully=20
filtered, which many claim to be "theft of resources," not =
unlike=20
unsolicited faxing. Because it may offer a form of "push" =
technology=20
for those that wish to only receive email of certain topics, the mass =
commerce=20
email trend would grow on the Internet violently. Often, users must pay =
for=20
Internet access by the minute, and so the spam traffic can get to be =
quite=20
expensive. Ultimately, the problem would eliminate the primary point of=20
controlling spam: it's still a waste of resources.</FONT></P>
<P><STRONG><FONT size=3D+0>SEPARATING THE PORT</STRONG><BR>
One plausible solution for controlling spam traffic on the server end =
would be=20
to require all unsolicited email to be sent on a separate Internet port =
than=20
port 25, such as port number 7726. In this way, advertisers can network =
their=20
bulk email using an alternative port, specially dedicated to spam. =
Servers not=20
interested in receiving bulk e-mail can simply not install this port. =
Assuming=20
the government were to cooperate, all bulk email sent on port 25 would =
be=20
considered illegal and worthy of prosecution of the highest degree=20
possible.</FONT></P>
<P><FONT size><STRONG>TAGGING THE "ENVELOPE</STRONG>"<BR>
Another solution could be to add the unsolicited email tag to the =
envelope of=20
the message, in addition to the tag in the body. This way, SMTP servers =
can=20
refuse to download any e-mail messages that have this tag in the =
envelope. In=20
addition, the additional information within the tag (as explained above) =
beyond=20
the <EM>spam</EM> tag could prove extremely useful in defining whether =
or not to=20
accept or how to route an incoming message.</FONT></P>
<P><FONT size>SMTP (Simple Mail Transport Protocol) consists of a=20
message-forwarding tactic, where the each server in the process says to =
the=20
next, "Hello. Here, this is an entire email message somebody wants =
sent to=20
Mr. Foobar. Please forward the message to the next nearest server to Mr. =
Foobar.=20
Thanks. Bye."</FONT></P>
<P><FONT size>When a message is sent from one server to another, three =
fields=20
are sent: MAIL (from), RCPT (to), and DATA (the message). This is =
currently the=20
only "envelope" a message contains, outside of the message's =
header,=20
which, again, cannot be accessed unless the entire message is =
downloaded. In=20
other words, the message's header is part of the actual =
message.</FONT></P>
<BLOCKQUOTE>
<P><FONT color=3D#FF0000 size=3D1><STRONG>HELO<BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250=20
ICICLE.YOURSTUPIDDOMAIN.COM (204.246.64.78)<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>MAIL FROM=20
<mackie at mystupiddomain.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>RCPT TO=20
<you at yourstupiddomain.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>DATA<BR>
</STRONG></FONT><FONT size=3D1><STRONG>354 Start mail input, end =
with=20
<CALF>.<CALF></STRONG></FONT></P>
=20
</BLOCKQUOTE>
<P><FONT size=3D+0>The IETF has constructed a means of implementing =
additional=20
extensions to the SMTP framework, a system known as <A=20
href=3D"http://info.internet.isi.edu/in-notes/rfc/files/rfc1869.txt";>ESMT=
P</A>.=20
This allows for additional functions to be added to our =
"envelope".=20
Utilizing/requesting ESMTP service from a host involves changing the =
HELO=20
(hello) command to EHLO, and the host response with a return =
"hello,"=20
along with a list of compatible extensions.</FONT></P>
<BLOCKQUOTE>
<P><FONT color=3D#FF0000 size=3D1><STRONG>EHLO<BR>
</STRONG></FONT><FONT size=3D1><STRONG>250 dbc.mtview.ca.us says=20
hello</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250-8BITMIME<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>MAIL FROM=20
<mackie at mystupiddomain.com> BODY=3D8BITMIME<BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK... =
Sender and=20
8BITMIME ok<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>RCPT TO=20
<you at yourstupiddomain.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>DATA<BR>
</STRONG></FONT><FONT size=3D1><STRONG>354 Start mail input, end =
with=20
<CALF>.<CALF></STRONG></FONT></P>
=20
</BLOCKQUOTE>
<P><STRONG><FONT size=3D+0>The "TAG" Extension<BR>
</STRONG>By using the TAG extension before sending the individual =
messages, the=20
recipient server can moderate the spams that it downloads, if any. =
Incompatible=20
systems will simply reflect a "500 SYNTAX ERROR" message upon=20
connecting with the EHLO command, or else will not reflect the =
compatibility=20
with the TAG extension, and the message will not be sent.</FONT></P>
<P><FONT size=3D+0>The sending (client) server scans each message's =
header to see=20
if it contains the spam tag. If so, if the receiving (host) server =
accepts=20
spammed messages, each spam is marked with another TAG extension along =
with the=20
MAIL FROM command, marking the message as a spam (or an unsolicited bulk =
email=20
message), along with additional TAG-related information.</FONT></P>
<BLOCKQUOTE>
<P><FONT size>Both systems incompatible, bulk message is sent:<BR>
</FONT><FONT color=3D#FF0000 size=3D1><STRONG>HELO<BR>
</STRONG></FONT><FONT size=3D1><STRONG>250 dbc.mtview.ca.us says =
hello<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>MAIL FROM=20
<mackie at mystupiddomain.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>RCPT TO=20
<you at yourstupiddomain.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>DATA<BR>
</STRONG></FONT><FONT size=3D1><STRONG>354 Start mail input, end =
with=20
<CALF>.<CALF></STRONG></FONT></P>
=20
<HR align=3Dleft color=3D#000000 SIZE=3D1 width=3D50%>
=20
<P><FONT size>Incompatible system, bulk message is not =
sent:</FONT><BR>
<FONT color=3D#FF0000 size=3D1><STRONG>EHLO</STRONG></FONT><FONT =
color=3D#000000=20
size=3D1><STRONG><BR>
500 SYNTAX ERROR<BR>
</STRONG></FONT><FONT color=3D#FF0000 =
size=3D1><STRONG>QUIT</STRONG></FONT></P>
=20
</BLOCKQUOTE>
<BLOCKQUOTE>
<HR align=3Dleft color=3D#000000 noShade SIZE=3D1 width=3D50%>
=20
</BLOCKQUOTE>
<BLOCKQUOTE>
<P><FONT size>Incompatible system, bulk message is not =
sent:</FONT><BR>
<FONT color=3D#FF0000 size=3D1><STRONG>EHLO</STRONG></FONT><FONT =
color=3D#000000=20
size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250 dbc.mtview.ca.us says=20
hello</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250-EXPN<BR>
250-HELP<BR>
250-8BITMIME<BR>
250-XONE<BR>
250 XVRB</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT color=3D#FF0000 =
size=3D1><STRONG>QUIT</STRONG></FONT></P>
=20
<HR align=3Dleft color=3D#000000 noShade SIZE=3D1 width=3D50%>
=20
<P><FONT size>Incompatible system, bulk message is not sent, =
non-bulk=20
messages are sent in same session:</FONT><BR>
<FONT color=3D#FF0000 size=3D1><STRONG>EHLO</STRONG></FONT><FONT =
color=3D#000000=20
size=3D1><STRONG><BR>
500 SYNTAX ERROR<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>HELO<BR>
</STRONG></FONT><FONT size=3D1><STRONG>250 dbc.mtview.ca.us says=20
hello</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>MAIL FROM=20
<george at foobar.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>RCPT TO=20
<you at yourstupiddomain.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>DATA<BR>
</STRONG></FONT><FONT size=3D1><STRONG>354 Start mail input, end =
with=20
<CALF>.<CALF></STRONG></FONT></P>
=20
<HR align=3Dleft color=3D#000000 noShade SIZE=3D1 width=3D50%>
=20
<P>Compatible system, refused spam:<FONT color=3D#FF0000 =
size=3D1><STRONG><BR>
EHLO</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250 dbc.mtview.ca.us says=20
hello</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250-EXPN<BR>
250-HELP<BR>
250-8BITMIME<BR>
250-XONE<BR>
250 XVRB<BR>
</STRONG></FONT><FONT color=3D#004080 size=3D1><STRONG>250-TAG<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>MAIL FROM=20
<mackie at mystupiddomain.com>=20
=
TAG=3DMUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N3987383</STRONG></F=
ONT><FONT=20
color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>523 Refused--no spam =
allowed<BR>
</STRONG></FONT><FONT color=3D#FF0000 =
size=3D1><STRONG>QUIT</STRONG></FONT></P>
=20
<HR align=3Dleft color=3D#000000 noShade SIZE=3D1 width=3D50%>
=20
<P>Compatible system, no spam allowed, other non-spam messages sent =
in the=20
same session:<FONT color=3D#FF0000 size=3D1><STRONG><BR>
EHLO</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250 dbc.mtview.ca.us says=20
hello</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250-EXPN<BR>
250-HELP<BR>
250-8BITMIME<BR>
250-XONE<BR>
250 XVRB<BR>
</STRONG></FONT><FONT color=3D#004080 size=3D1><STRONG>250-TAG<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>MAIL FROM=20
<george at foobar.com></STRONG></FONT><FONT color=3D#000000 =
size=3D1><STRONG>=20
</STRONG></FONT><FONT color=3D#FF0000=20
=
size=3D1><STRONG>TAG=3DMUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N39=
87383</STRONG></FONT><FONT=20
color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>523 Refused--no spam =
allowed<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>MAIL FROM=20
<george at foobar.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>RCPT TO=20
<you at yourstupiddomain.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>DATA<BR>
</STRONG></FONT><FONT size=3D1><STRONG>354 Start mail input, end =
with=20
<CALF>.<CALF></STRONG></FONT></P>
=20
<HR align=3Dleft color=3D#000000 noShade SIZE=3D1 width=3D50%>
=20
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Compatible system, accepted spam:<BR>
<FONT color=3D#FF0000 size=3D1><STRONG>EHLO</STRONG></FONT><FONT =
color=3D#000000=20
size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250 dbc.mtview.ca.us says=20
hello</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG><BR>
</STRONG></FONT><FONT size=3D1><STRONG>250-EXPN<BR>
250-HELP<BR>
250-8BITMIME<BR>
250-XONE<BR>
250 XVRB<BR>
</STRONG></FONT><FONT color=3D#004080 size=3D1><STRONG>250-TAG<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>MAIL FROM=20
<mackie at mystupiddomain.com>=20
=
TAG=3DMUAB;C031;C382;C782;O987'Buds_Garden_Shop';E34;N3987383</STRONG></F=
ONT><FONT=20
color=3D#000000 size=3D1><STRONG><BR>
250 Ok.<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>RCPT TO=20
<you at yourstupiddomain.com><BR>
</STRONG></FONT><FONT color=3D#000000 size=3D1><STRONG>250 OK<BR>
</STRONG></FONT><FONT color=3D#FF0000 size=3D1><STRONG>DATA<BR>
</STRONG></FONT><FONT size=3D1><STRONG>354 Start mail input, end =
with=20
<CALF>.<CALF></STRONG></FONT></P>
=20
</BLOCKQUOTE>
<P> </P>
<P><FONT size><STRONG><A name=3DGovernment_Support><IMG=20
alt=3D"GOVERNMENTAL AUTHORITY SUPPORT" height=3D25 readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/governmentalsupport.g=
if"=20
width=3D196></STRONG></FONT></A><FONT size><FONT color=3D#FFFFFF =
face=3D""=20
size=3D-2>GOVERNMENTAL AUTHORIY SUPPORT</FONT><STRONG><BR>
</STRONG>By legally requiring all unsolicited email messages to contain =
the bulk=20
mail identifier tag in the header, netizens can be guaranteed that no =
spam will=20
enter their emailboxes without the ability to filter every one of them. =
In this=20
way, spammers=97or net-savvy marketers=97will still be able to legally =
send as much=20
unsolicited email as they please. All that they are required to do is to =
admit=20
what they are doing. Not doing so should be cause for a fine, not unlike =
the=20
current fine established by the U.S. government for unsolicited faxes. =
Such a=20
fine should be a bit smaller; remember, it=92s easier to send bulk email =
than bulk=20
faxes, so fines for each complaining recipient could add up to a great =
deal,=20
beyond payment ability. Also, obviously, a time lapse of at least two =
years=20
should be given before such fines would actually start taking place, =
allowing=20
for email software producers to upgrade the functionality of their email =
client=20
software to include the new header tag.</FONT></P>
<P><FONT size>While it is unrealistic to expect <EM>all </EM>countries =
involved=20
with the Internet to cooperate, if the U.S. and UN Governments alone =
were to=20
cooperate, this would allow control for 90% of all bulk emailings. Other =
countries not cooperating would be pressured into joining the etiquette. =
</FONT><A href=3D"http://www.ai/"; target=3D_top><FONT size>U.S. and UN =
citizens=20
hiring businesses in other countries</FONT></A><FONT size> to spam =
without=20
adding the header tag would still be at fault if the email business does =
not=20
assume responsibility for the non-tagged messages, since the spam was =
created by=20
the citizen. If the business does assume responsibility for the =
non-tagged=20
messages, they would not only jeopardize their business, but also, in =
many ways,=20
their country.</FONT></P>
<P><FONT size>Unfortunately, for the U.S., finding government =
involvement has=20
been a chore. More often than not, our leaders have been regularly =
advised to=20
keep out of the affairs of the Internet. While freedom of speech has =
been a joy=20
to toy with in this "lawless paradise", the arguments used in=20
suggesting that governing bodies should keep out of its affairs are =
nothing=20
short of <EM>absurd.</EM> These are the same individuals that think that =
cyberspace is nothing more than several cables spanned out across the =
States and=20
to other countries, for the exchange of pretty pictures and educational =
data.=20
The truth, however, is that Internet cyberspace has become a =
<EM>communications=20
medium,</EM> as well as many other things, and, for the U.S. and its =
citizens,=20
it <EM>belongs</EM> in the hands of the Federal Communications =
Commission. Spam=20
is just one of many, many ways the Internet, a communications medium, is =
being=20
seriously abused, and its results are not unlike the abuse of telephones =
and=20
facsimiles. This reality should be taken <EM>seriously.</EM></FONT></P>
<P><FONT size><BR>
</FONT><A name=3DDown_Side><FONT size><IMG alt=3D"ON THE DOWN SIDE" =
height=3D22=20
readyState=3D4 =
src=3D"http://www.winternet.com/~mackie/spam/images/downside.gif"=20
width=3D108></FONT></A><FONT size><FONT color=3D#FFFFFF face=3D"" =
size=3D-2>ON THE DOWN=20
SIDE</FONT><BR>
Several valid arguments in response to this proposal have been =
presented. A=20
common argument is the problem of "revamping the entire email =
system"=20
in order to see this tagging system implemented. Granted, compatible =
systems=20
would have to conform to the standard, but remember: the Internet is =
young--it=20
is still being founded. We have seen <EM>very little</EM> in comparison =
to what=20
lies ahead, spam included. Even if it does take a couple years for this =
system=20
to be successfully implemented, it would be a worthwhile trip, and =
patience is=20
the key.</FONT></P>
<P><FONT size>Other common arguments are generally poor, however, as =
they do not=20
reflect the entire proposal presented here. One such argument is that =
there is=20
</FONT><A =
href=3D"http://www.winternet.com/~mackie/spam/noguarantee.htm";><FONT=20
size>no guarantee</FONT></A><FONT size> that the spammer will include =
this tag.=20
First, a law to make tagged spams mandatory would require the spammer to =
do so=20
if the spammer is a citizen of that government, or else lead the spammer =
to be=20
charged a serious fine or face other similar prosecution. Since most =
spams=20
originate from the U.S. or the UN, these governments alone would cover a =
broad=20
spectrum of spams. Second, by making the tag an Internet-wide standard, =
all=20
major email programs would include the tag in its design, requiring the=20
"newbie" spam author to tag which type of message he is =
sending,=20
without pressure from the recipients. Also, eliminating such pressure =
from=20
"spam haters" by partially legalizing spam as long as it has =
this=20
header would cause the spammers to be much less =
defiant/uncooperative/cheating=20
of the system. Third, anyone caught "cheating the system" =
(changing=20
the header, throwaway accounts, account fraudulence, posting on another =
private=20
SMTP server, etc.) should be prosecuted <EM>severely</EM>. For the U.S., =
this is=20
an issue the FCC is increasingly <EM>urged</EM> to comply with.<BR>
</FONT></P>
<P><A name=3DLast_Words><IMG alt=3D"LAST WORDS" height=3D22 =
readyState=3D4=20
src=3D"http://www.winternet.com/~mackie/spam/images/lastwords.gif"=20
width=3D65></A><FONT color=3D#FFFFFF face=3D"" size=3D-2>LAST =
WORDS</FONT></P>
<P><FONT size>While regulation must be taken <EM>very carefully</EM> =
when=20
dealing with the Internet, this kind of cooperation between netizens and =
international government authorities could be among the healthiest and =
wisest=20
implementations of Internet and government merges to date on the =
Internet. I=20
feel this is perhaps the best method of controlling spam currently being =
proposed, as it continues to give all users complete freedom of speech, =
while at=20
the same time giving all users freedom of privacy.</FONT></P>
<P><FONT size>I hope this presentation is both clear and precise, and I =
hope it=20
provides a closer answer to the Internet peace we are all looking=20
for.</FONT></P>
<P> </P>
<P><FONT size><B><I>Presented by </I></B></FONT><A=20
href=3D"mailto:Jon Davis, newbreed at isd.net"><FONT size><B><I>Jon =
Davis</FONT><FONT=20
size>, newbreed at isd.net</I></B></FONT></A></P>
<P><FONT size><I>"Shh dear, don't cause a fuss. I'll have your =
spam. I love=20
it. I'm having spam, spam, spam, spam, spam, spam, spam, baked beans, =
spam,=20
spam, spam and spam."</I></FONT></P>
</FONT>
</BODY></HTML>
------=_NextPart_000_01BC50AD.6F611950--
Received: from ietf.org by ietf.org id aa10557; 24 Apr 97 14:19 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa10325; 24 Apr 97 14:18 EDT
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id OAA24422
for <ietf at ietf.org>; Thu, 24 Apr 1997 14:15:19 -0400
Message-Id: <199704241815.OAA24422 at black-ice.cc.vt.edu>
To: ietf at ietf.org
Subject: Re: e-mail and p-mail
In-Reply-To: Your message of "Thu, 24 Apr 1997 11:03:05 BST."
<v0300780aaf84df3dcf03 at [130.237.150.138]>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <v0300780aaf84df3dcf03 at [130.237.150.138]>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-895276624P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 24 Apr 1997 14:15:18 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-895276624P
Content-Type: text/plain; charset=us-ascii
On Thu, 24 Apr 1997 11:03:05 BST, you said:
> I have seen "p-mail", which seems an excellent term. Can we
> agree to use "p-mail" as an abbreviation for postal mail?
tree-mail.
Its major advantage is you can float a check longer. Disadvantages
are environmental, and the fact that you can't grep a dead tree.
This message printed on 100% recycled electrons.
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-895276624P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM1+jM9QBOOoptg9JAQHGdgQAppRMK9FRQ5NrpDH8YKjSFzSZSVCZfAQH
UEJRcE6EcGp+lCMAA4gSkB3ZevfwnpiezDhTJddsmHIDU53M8LQcXR5ZBR2NUzx8
IpMDG0ToE6W19hKYp52JiTwCvmNl72mkr8TNuFpeJzVMp+sMLYkcdeZ7Dk2Otsyx
xRSJpn95GSQ=
=wHSC
-----END PGP MESSAGE-----
--==_Exmh_-895276624P--
Received: from ietf.org by ietf.org id aa12628; 24 Apr 97 14:48 EDT
Received: from dub-img-1.compuserve.com by ietf.org id aa12489;
24 Apr 97 14:47 EDT
Received: by dub-img-1.compuserve.com (8.6.10/5.950515)
id OAA05738; Thu, 24 Apr 1997 14:43:47 -0400
Date: 24 Apr 97 14:42:13 EDT
Sender:ietf-request at ietf.org
From: DAVEH at grolier.ccmail.compuserve.com
MMDF-Warning: Parse error in original version of preceding line at ietf.org
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject:
Message-ID: <970424184212_702420.204300_BHD37-44 at CompuServe.COM>
Source-Info: From (or Sender) name not authenticated.
Unsubscribe
Received: from ietf.org by ietf.org id aa13713; 24 Apr 97 15:02 EDT
Received: from tigger.jvnc.net by ietf.org id aa13429; 24 Apr 97 15:00 EDT
Received: from ntsrvr2.mier.jvnc.net (mier.jvnc.net) by tigger.jvnc.net with SMTP id AA07706
(5.65c/IDA-1.4.4 for ietf at ietf.org); Thu, 24 Apr 1997 14:57:23 -0400
Received: by NTSRVR2 with Internet Mail Service (5.0.1389.3)
id <01BC50BC.2AE02E60 at NTSRVR2>; Thu, 24 Apr 1997 14:31:16 -0400
Message-Id: <114FD478AB86D011BCE300608CED870D0F55 at NTSRVR2>
Sender:ietf-request at ietf.org
From: Ed Mier <Ed at mier.com>
To: 'Dr-X' <raidesj at arrakis.es>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: e-mail and p-mail
Date: Thu, 24 Apr 1997 14:31:09 -0400
X-Priority: 3
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1389.3)
Content-Type: text/plain
Source-Info: From (or Sender) name not authenticated.
somebody on this thread said:
> > The most commonly
> > used word for postal mail in order to differentiate from e-mail
> > is "snail-mail" but this is not really a good term, derogatory
> > comments should not be part of the name of an important public
> > service.
>
as an American consumer in New Jersey, where everything everybody says
is derogatory, I'll stick with snail-mail, thank you very much. this
name is popular, accurate, and deserved. and it's not nearly as
derogatory as the slugs in my local post office deserve, given the way
they treat the public.
ed mier
Received: from ietf.org by ietf.org id aa14071; 24 Apr 97 15:05 EDT
Received: from [208.211.196.5] by ietf.org id aa13885; 24 Apr 97 15:04 EDT
Received: from GW#u#Miami-Message_Server by stratasyscorp.com
with Novell_GroupWise; Thu, 24 Apr 1997 15:01:37 -0400
Message-Id: <s35f75d1.053 at stratasyscorp.com>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 24 Apr 1997 15:01:15 -0400
Sender:ietf-request at ietf.org
From: =?ISO-8859-1?Q?Jos=E9 Tamayo?= <jtamayo at stratasyscorp.com>
To: ole at csli.stanford.edu, tytso at mit.edu
Cc: jpalme at dsv.su.se, ietf at ietf.org
Subject: Re: e-mail and p-mail
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Source-Info: From (or Sender) name not authenticated.
Thank you!
>>> "Theodore Y. Ts'o" <tytso at mit.edu> 04/24/97 12:05PM >>>
I don't know about everyone else, but this thread about what to call
phsical, postal, whatever mail is really silly. It has nothing to do
with the work of the IETF. Can we please stop now?
- Ted
Received: from ietf.org by ietf.org id aa14393; 24 Apr 97 15:08 EDT
Received: from puli.cisco.com by ietf.org id aa14313; 24 Apr 97 15:07 EDT
Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id MAA16970; Thu, 24 Apr 1997 12:03:48 -0700
X-Sender: bstewart at puli.cisco.com
Message-Id: <v0310252aaf855ebef057 at [171.69.128.42]>
In-Reply-To: <199704241730.MAA09519 at usamrid.innovsoftd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Apr 1997 15:03:42 -0400
To: Jon Davis <newbreed at isd.net>
Sender:ietf-request at ietf.org
From: Bob Stewart <bstewart at cisco.com>
Subject: Re: Spam Control Proposal (revision 2)
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Circa 12:45 PM -0500 4/24/97, Jon Davis bitwhacked:
>This proposal is formatted in HTML. If you would like to
If a spam filter would have trashed this message it would have been a
useful service.
That was waaay to much stuff to send to this many marginally interested
people. We're busy figuring out what to call mail.
Bob
Received: from ietf.org by ietf.org id aa15394; 24 Apr 97 15:23 EDT
Received: from atl_xch_srvr1.hayes.com by ietf.org id aa15278;
24 Apr 97 15:21 EDT
Received: by atl_xch_srvr1.hayes.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <01BC50C2.CC425CF0 at atl_xch_srvr1.hayes.com>; Thu, 24 Apr 1997 15:18:44 -0400
Message-ID: <c=US%a=_%p=Hayes_Microcompu%l=ATL_XCH_SRVR1-970424191843Z-2571 at atl_xch_srvr1.hayes.com>
Sender:ietf-request at ietf.org
From: "Dunlap, Randy" <rdunlap at hayes.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: e-mail and p-mail
Date: Thu, 24 Apr 1997 15:18:43 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I like tree-mail, but after reading all of these,
I have come to think that p-mail is the best.
It can mean any of physical mail, postal/postel mail, or
paper mail (but NOT pager mail).
____________________________________________________________
Randy Dunlap, Software Engineer 770/840-9200 x-2442
rdunlap at hayes.com fax: 770/447-0178
Network Systems
US Mail: P.O. Box 105203, Atlanta, GA 30348-5203
street: 5923 Peachtree Industrial Blvd., Norcross, GA 30092-3405
>----------
>From: Valdis.Kletnieks at vt.edu[SMTP:Valdis.Kletnieks at vt.edu]
>Sent: Thursday, April 24, 1997 2:15 PM
>To: ietf at ietf.org
>Subject: Re: e-mail and p-mail
>
>
>On Thu, 24 Apr 1997 11:03:05 BST, you said:
>> I have seen "p-mail", which seems an excellent term. Can we
>> agree to use "p-mail" as an abbreviation for postal mail?
>
>tree-mail.
>
>Its major advantage is you can float a check longer. Disadvantages
>are environmental, and the fact that you can't grep a dead tree.
>
>This message printed on 100% recycled electrons.
>
>--
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
>
>
>
>
Received: from ietf.org by ietf.org id aa24632; 24 Apr 97 20:03 EDT
Received: from hail.ncr.disa.mil by ietf.org id aa24451; 24 Apr 97 19:55 EDT
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id TAA17309 for <ietf at ietf.org>; Thu, 24 Apr 1997 19:49:15 -0400 (EDT)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA861936723; Thu, 24 Apr 97 19:48:26 EST
Date: Thu, 24 Apr 97 19:48:26 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9703248619.AA861936723 at ncr.disa.mil>
To: ietf at ietf.org
Subject: Re[2]: e-mail and p-mail
Source-Info: From (or Sender) name not authenticated.
Hi Ted,
Finally, some adult supervision! Thank you, sir.
Bill Flanigan
P.S. "e-mail and p-mail" = ietf-list junk mail (which is dangerously
close to spam mail).
______________________________ Reply Separator _________________________________
Subject: Re: e-mail and p-mail
Author: "Theodore Y. Ts'o" <tytso at mit.edu> at smtp
Date: 4/24/97 1:40 PM
I don't know about everyone else, but this thread about what to call
phsical, postal, whatever mail is really silly. It has nothing to do
with the work of the IETF. Can we please stop now?
- Ted
Received: from ietf.org by ietf.org id aa27355; 24 Apr 97 22:04 EDT
Received: from bast.livingston.com by ietf.org id aa27238; 24 Apr 97 22:00 EDT
Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA03670 for <ietf at ietf.org>; Thu, 24 Apr 1997 18:55:43 -0700 (PDT)
Received: (from megazone at localhost) by server.livingston.com (8.8.5/8.6.9) id SAA06724 for ietf at ietf.org; Thu, 24 Apr 1997 18:55:49 -0700 (PDT)
Message-Id: <199704250155.SAA06724 at server.livingston.com>
Subject: e-mail and p-mail (fwd)
To: ietf at ietf.org
Date: Thu, 24 Apr 1997 18:55:49 -0700 (PDT)
Sender:ietf-request at ietf.org
From: MegaZone <megazone at livingston.com>
Precedence: special-delivery
Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe
X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me.
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Once upon a time Jacob Palme shaped the electrons to say...
>be used to refer to both postal mail and e-mail. The most commonly
>used word for postal mail in order to differentiate from e-mail
>is "snail-mail" but this is not really a good term, derogatory
I intend to continue using snail-mail as long as I live.
That's how I feel about it.
-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone at livingston.com
For support requests: support at livingston.com <http://www.livingston.com/>
Snail mail: 4464 Willow Road, Pleasanton, CA 94588
Received: from ietf.org by ietf.org id aa09007; 25 Apr 97 3:46 EDT
Received: from wentzl.cdg.chalmers.se by ietf.org id aa08712; 25 Apr 97 3:40 EDT
Received: from wilfer1.cdg.chalmers.se (wilfer1.cdg.chalmers.se [129.16.12.11])
by wentzl.cdg.chalmers.se (8.8.5/8.8.5) with ESMTP id JAA06488;
Fri, 25 Apr 1997 09:36:31 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Gunnar Lindberg <lindberg at cdg.chalmers.se>
Received: (from lindberg at localhost)
by wilfer1.cdg.chalmers.se (8.8.5/8.8.5) id JAA00496;
Fri, 25 Apr 1997 09:36:30 +0200 (MET DST)
Date: Fri, 25 Apr 1997 09:36:30 +0200 (MET DST)
Message-Id: <199704250736.JAA00496 at wilfer1.cdg.chalmers.se>
To: ietf at ietf.org, newbreed at isd.net
Subject: Re: Spam Control Proposal (revision 2)
X-Mailer: UCB Mail 5.3.8 96-10-07 (MIME)
Source-Info: From (or Sender) name not authenticated.
>Date: Thu, 24 Apr 1997 12:45:48 -0500
>From: Jon Davis <newbreed at isd.net>
>To: ietf at ietf.org
>Message-Id: <199704241730.MAA09519 at usamrid.innovsoftd.com>
>Subject: Spam Control Proposal (revision 2)
>This is a multi-part message in MIME format.
> ...
I admit I'm unable to grasp the contents in this message within
the time I can spend on it (I did try, sigh :-). Let me, however,
hand in another proposal, not without controversy, but "simpler":
Why not have all mail delivery agents make some rudimentary check
on "From" address and at least assure the domain exists? We've
done so for some time now (rather small hack to sendmail) and it
seems to work fairly well (we've received few mail complaints :-).
This will stop spam from people that hide behind "un.known.com"
(ooops, "known.com" exists, sorry, but you understand, see below).
It will not stop people that hide behind "ietf.org" (or "ibm.com"
or any other existing domain) but I assume using someone else's
domain may cause legal action, at least in the US?
It will certainly not stop the "honest spam" where someone wants
to promote his product, but just the volume of "no thanks" (not
to mention other responses...) will handle that - a full mailbox
actually means he will miss the single "yes please" response...
Gunnar Lindberg
Received: from ietf.org by ietf.org id aa11007; 25 Apr 97 5:20 EDT
Received: from mersey.hursley.ibm.com by ietf.org id aa10672; 25 Apr 97 5:12 EDT
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
id AA21820; Fri, 25 Apr 1997 10:09:37 +0100
Date: Fri, 25 Apr 1997 10:09:37 +0100
Message-Id: <9704250909.AA21820 at hursley.ibm.com>
Sender:ietf-request at ietf.org
From: "(Brian E Carpenter)" <brian at hursley.ibm.com>
Subject: IAB message on IAHC (fwd)
To: ietf at ietf.org
Reply-To: brian at hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1071
Source-Info: From (or Sender) name not authenticated.
IETF,
FYI
Brian Carpenter
> To: heath at linus.isoc.org (Don Heath)
> Date: Fri, 25 Apr 1997 10:06:09 +0100 (BST)
> Cc: iab at isi.edu
> Reply-to: brian at hursley.ibm.com
>
> Don,
>
> The IAB has concluded that since it is not a legal entity,
> it cannot meaningfully sign the gTLD MOU, but we have agreed
> on the following statement. Please feel free to distribute
> this as you wish. I will be forwarding this message to the IETF
> list.
>
> "The Internet Architecture Board, in its role as an advisory
> group to the Internet Society, has extensively discussed
> the administration of top level domain names in the Internet
> over the last two years, and was glad to appoint two members
> of the Interim Ad Hoc Committee on this subject. The IAB
> broadly supports the final report of the IAHC, with some
> diversity of views on the technical details, and encourages
> the Internet community as a whole to follow the approach
> proposed by the IAHC."
>
> Regards,
> Brian Carpenter (IAB Chair) April 25, 1997
>
>
Received: from ietf.org by ietf.org id aa13288; 25 Apr 97 7:18 EDT
Received: from smtp.tele.fi by ietf.org id aa12844; 25 Apr 97 7:00 EDT
Received: from IDENT-NOT-QUERIED at www.siemens.fi (port 3575 [193.210.133.150]) by smtp.tele.fi with SMTP id <18384-6352>; Fri, 25 Apr 1997 13:54:47 +0300
Received: by www.siemens.fi(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 42256484.0041AF53 ; Fri, 25 Apr 1997 13:57:27 +0200
X-Lotus-FromDomain: SIEMENS FINLAND
Sender:ietf-request at ietf.org
From: pekka.sahlsten at siemens.fi
To: ietf at ietf.org
Message-ID: <42256484.00410AAE.00 at www.siemens.fi>
Date: Fri, 25 Apr 1997 13:54:49 +0200
Subject: Re: Spam Control Proposal (revision 2)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Pekka Sahlsten at SIEMENS FINLAND
25.04.97 13:54
>It will certainly not stop the "honest spam" where someone wants
>to promote his product, but just the volume of "no thanks" (not
>to mention other responses...) will handle that - a full mailbox
>actually means he will miss the single "yes please" response...
As long as Netiquette dictates a mandatory "no thanks" response
to all such "benign spam" messages ;-)
-- Pekka Sahlsten
Received: from ietf.org by ietf.org id aa17068; 25 Apr 97 9:36 EDT
Received: from ietf.ietf.org by ietf.org id aa16232; 25 Apr 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-wessels-icp-v2-02.txt
Date: Fri, 25 Apr 1997 09:25:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704250925.aa16232 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Cache Protocol (ICP), version 2
Author(s) : D. Wessels
Filename : draft-wessels-icp-v2-02.txt
Pages : 9
Date : 04/23/1997
This draft document describes the Internet Cache Protocol (ICP) as
currently implemented in a couple of World-Wide Web proxy cache packages.
A companion document (RFCXXXX, <draft-wessels-icp-v2-appl-00.txt>)
describes the application of ICP to Web caches. ICP was initially
developed by Peter Danzig, et. al. at the University of Southern
California. It evolved as an important part of hierarchical caching
on the Harvest research project.
Internet-Drafts are 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-wessels-icp-v2-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-wessels-icp-v2-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-wessels-icp-v2-02.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970423115549.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-wessels-icp-v2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-wessels-icp-v2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970423115549.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17075; 25 Apr 97 9:36 EDT
Received: from ietf.ietf.org by ietf.org id aa16301; 25 Apr 97 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: agentx at fv.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-agentx-ext-pro-03.txt
Date: Fri, 25 Apr 1997 09:25:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704250926.aa16301 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNMP Agent Extensibility
Working Group of the IETF.
Title : Agent Extensibility (AgentX) Protocol Version 1
Author(s) : M. Daniele, B. Wijnen, D. Francisco
Filename : draft-ietf-agentx-ext-pro-03.txt
Pages : 81
Date : 04/23/1997
This memo defines a standardized framework for extensible SNMP agents. It
defines processing entities called master agents and subagents, a protocol
(AgentX) used to communicate between them, and the elements of procedure by
which the extensible agent processes SNMP protocol messages.
Internet-Drafts are 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-agentx-ext-pro-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-agentx-ext-pro-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-agentx-ext-pro-03.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970423145027.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-agentx-ext-pro-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-agentx-ext-pro-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970423145027.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17076; 25 Apr 97 9:36 EDT
Received: from ietf.ietf.org by ietf.org id aa16297; 25 Apr 97 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-fax at imc.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-fax-tiff-01.txt
Date: Fri, 25 Apr 1997 09:25:02 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704250926.aa16297 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Fax Working Group
of the IETF.
Title : Tag Image File Format (TIFF) - Class F
Author(s) : G. Parsons, J. Rafferty
Filename : draft-ietf-fax-tiff-01.txt
Pages : 20
Date : 04/23/1997
This document formalizes the reference for the Tag Image File Format (TIFF)
and formally defines TIFF Class F that is used to store facsimile images.
As well, the original registration for image/TIFF from RFC 1528 is refined
by this document.
Internet-Drafts are 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-fax-tiff-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-fax-tiff-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-fax-tiff-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970423113828.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-fax-tiff-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-fax-tiff-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970423113828.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17073; 25 Apr 97 9:36 EDT
Received: from ietf.ietf.org by ietf.org id aa16302; 25 Apr 97 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: rps at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rps-rpsl-02.txt, .ps
Date: Fri, 25 Apr 1997 09:25:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704250926.aa16302 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Routing Policy System
Working Group of the IETF.
Title : Routing Policy Specification Language (RPSL)
Author(s) : C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg,
D. Meyer, M. Terpstra, C. Villamizar
Filename : draft-ietf-rps-rpsl-02.txt, .ps
Pages : 49
Date : 04/23/1997
This Internet Draft is the reference document for the Routing Policy
Specification Language (RPSL). RPSL allows a network operator to be able to
specify routing policies at various levels in the Internet hierarchy; for
example at the Autonomous System (AS) level. At the same time, policies
can be specified with sufficient detail in RPSL so that low level router
configurations can be generated from them. RPSL is extensible; new routing
protocols and new protocol features can be introduced at any time.
RPSL is a replacement for the current Internet de-facto standard routing
policy specification language known as RIPE-181 [6] or RFC-1786 [7].
RIPE-81 [8] was the first language deployed in the Internet for specifying
routing policies. It was later replaced by RIPE-181 [6].
Internet-Drafts are 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-rps-rpsl-02.txt".
Or
"get draft-ietf-rps-rpsl-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rps-rpsl-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rps-rpsl-02.txt".
Or
"FILE /internet-drafts/draft-ietf-rps-rpsl-02.ps".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970423152847.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rps-rpsl-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rps-rpsl-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970423152847.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17077; 25 Apr 97 9:36 EDT
Received: from ietf.ietf.org by ietf.org id aa16298; 25 Apr 97 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-urn-biblio-00.txt
Date: Fri, 25 Apr 1997 09:25:12 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704250926.aa16298 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Names
Working Group of the IETF.
Title : Using Existing Bibliographic Identifiers as
Uniform Resource Names
Author(s) : C. Lynch, C. Preston, R. Daniel
Filename : draft-ietf-urn-biblio-00.txt
Pages : 10
Date : 04/23/1997
A system for Uniform Resource Names (URNs) must be capable of supporting
identifiers from existing widely-used naming systems. This document
discusses how three major bibliographic identifiers (the ISBN, ISSN and
SICI) can be supported within the URN framework and the currently proposed
syntax for URNs.
Internet-Drafts are 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-urn-biblio-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-biblio-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-urn-biblio-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970423144527.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-biblio-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-biblio-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970423144527.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17074; 25 Apr 97 9:36 EDT
Received: from ietf.ietf.org by ietf.org id aa16303; 25 Apr 97 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-acap+ at andrew.cmu.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-acap-type-ext-00.txt
Date: Fri, 25 Apr 1997 09:25:25 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704250926.aa16303 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Application Configuration
Access Protocol Working Group of the IETF.
Title : ACAP TYPE Extension
Author(s) : R. Earhart
Filename : draft-ietf-acap-type-ext-00.txt
Pages : 5
Date : 04/23/1997
The Application Configuration Access Protocol [ACAP] defines rough typing
information in the form of an attribute naming convention. This extension
to ACAP allows a MIME content-type/subtype with parameters to be associated
with a given piece of data, providing knowledgeable clients with useful
information in a way which maintains compatability with innocent clients
and servers.
Internet-Drafts are 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-acap-type-ext-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-acap-type-ext-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-acap-type-ext-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970423162446.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-acap-type-ext-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-acap-type-ext-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970423162446.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18734; 25 Apr 97 9:55 EDT
Received: from ietf.ietf.org by ietf.org id aa16220; 25 Apr 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-weltman-java-ldap-00.txt
Date: Fri, 25 Apr 1997 09:25:05 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704250925.aa16220 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Java LDAP Application Program Interface
Author(s) : R. Weltman
Filename : draft-weltman-java-ldap-00.txt
Pages : 45
Date : 04/23/1997
This document defines a java language application program interface to the
lightweight directory access protocol (LDAP), in the form of a class
library. It complements but does not replace RFC 1823 ([9]), which
describes a C language application program interface.
Internet-Drafts are 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-weltman-java-ldap-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-weltman-java-ldap-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-weltman-java-ldap-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970423114719.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-weltman-java-ldap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-weltman-java-ldap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970423114719.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19763; 25 Apr 97 10:03 EDT
Received: from caladan.arrakis.es by ietf.org id aa19425; 25 Apr 97 9:59 EDT
Received: from pc-de-raides-j. (ia-91.arrakis.es [195.5.70.91]) by arrakis.es (8.7.5/8.7.3) with SMTP id PAA02506 for <ietf at ietf.org>; Fri, 25 Apr 1997 15:56:20 +0200 (MET DST)
Message-Id: <199704251356.PAA02506 at arrakis.es>
Comments: Authenticated sender is <raidesj at pop3.arrakis.es>
Sender:ietf-request at ietf.org
From: Dr-X <raidesj at arrakis.es>
Organization: Dr-X Enterprises, Ltd.
To: ietf at ietf.org
Date: Fri, 25 Apr 1997 14:58:13 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Subject: RE: Re: Spam Control Proposal (revision 2)
Priority: normal
In-reply-to: <v0310252aaf855ebef057 at [171.69.128.42]>
References: <199704241730.MAA09519 at usamrid.innovsoftd.com>
X-mailer: Pegasus Mail for Win32 (v2.53/R1)
Source-Info: From (or Sender) name not authenticated.
> Bob Stewart said:
>
> Circa 12:45 PM -0500 4/24/97, Jon Davis bitwhacked:
> >This proposal is formatted in HTML. If you would like to
>
> If a spam filter would have trashed this message it would have been a
> useful service.
>
> That was waaay to much stuff to send to this many marginally interested
> people. We're busy figuring out what to call mail.
>
> Bob
>
>
Hahahahahahahaha ... I think this is a good example of Net Irony! :)
By the way, and after my complains about all the unuseful e-mail
I've received whining with M=FCnich affairs, I must also complain about
what I initially took as a good game ... Now I'm even more annoyed
than with IETF meeting postings. Stop the thread, please! I don=B4t
know which part of me decided to participate on it but I'm deleting
this kind of junk-e-mail at 12 or more per day! ...
So said ...
XXX XXX
DDDD RRRR XX XX
D D R R XX XX
D D R R XX XX
D D RRRR ----- XXXX ... ON THE EDGE OF TECHNOLOGY
D D R R XX XX
D D R R XX XX
DDDD R R XX XX
XXX XXX
(Yeah! It's technology what makes it possible, but ... what's technology =
without
the people behind it? ... )
Received: from ietf.org by ietf.org id aa19766; 25 Apr 97 10:03 EDT
Received: from caladan.arrakis.es by ietf.org id aa19427; 25 Apr 97 9:59 EDT
Received: from pc-de-raides-j. (ia-91.arrakis.es [195.5.70.91]) by arrakis.es (8.7.5/8.7.3) with SMTP id PAA02492; Fri, 25 Apr 1997 15:56:13 +0200 (MET DST)
Message-Id: <199704251356.PAA02492 at arrakis.es>
Comments: Authenticated sender is <raidesj at pop3.arrakis.es>
Sender:ietf-request at ietf.org
From: Dr-X <raidesj at arrakis.es>
Organization: Dr-X Enterprises, Ltd.
To: Jon Davis <newbreed at isd.net>
Date: Fri, 25 Apr 1997 14:58:13 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Spam Control Proposal (revision 2)
CC: ietf at ietf.org
Priority: normal
In-reply-to: <199704241730.MAA09519 at usamrid.innovsoftd.com>
X-mailer: Pegasus Mail for Win32 (v2.53/R1)
Source-Info: From (or Sender) name not authenticated.
After carefull reading of your Proposal -sent opportunistically in
the middle of a "thread spamming" which shows what can we do when
we're bored- I must admit that it's one of the most equilibrated
proposals I've read on the subject. It's a good idea to make
governmets feel well because they'll have a hand over the Net just to
control intentional-but-not-standard-conforming spam. The intentional
but law-conformer spammers will be glad to be sure that their
spamming will reach just the interested potential
customers/followers, because they'll be sure that filter-mail rules
will let the uninterested people outside without resorting to very
expensive form-filling-and-proccesing affairs, followed by
data-mining to find trends and such just to know who will be
interested on the particular product. Only by providing a mechanism
to let the sender know how much of the sent copies have arrived their
destinations, they'll have the number of potential customers ready to
be proccesed. To know sex, age, religious tendencies and other
questions, they can make a sort of straight to the recipient
questionary sending and proccess the results the usual way (letting
the marketing consultants on bussines). In the other hand, the
potential customer will ensure itself the protection against a huge
volume of unwanted spam-mail just with a minimal tuning of his/her
e-mail client. And the free-speech defenders will feel better because
they would be able to write what -and about what- they want to
without having to fear a government snuffing on their data (providing
they don't spam as their usual way of saying things, of course).
Sometimes I see that it's not an easy task to please everybody
involved in a determinate project or relation, but you've just shown
that, with a bit of effort in the related parts, it CAN (and SHOULD
be done). I spent some times in my life just trying to see the "big
picture" of usual problems so I can find intermediate solutions with
the minimal effort involved and the maximun happiness resulting (both
conditions at once, cause any of them alone will sacrifice the
other). I think you've been very close to that -even you could have
done it- but now the ball it's in the other's field!...
XXX XXX
DDDD RRRR XX XX
D D R R XX XX
D D R R XX XX
D D RRRR ----- XXXX ... ON THE EDGE OF TECHNOLOGY
D D R R XX XX
D D R R XX XX
DDDD R R XX XX
XXX XXX
(Yeah! It's technology what makes it possible, but ... what's technology without
the people behind it? ... )
Received: from ietf.org by ietf.org id aa28967; 25 Apr 97 12:17 EDT
Received: from proxy1.ba.best.com by ietf.org id aa28575; 25 Apr 97 11:59 EDT
Received: from [205.149.180.135] (boo.vip.best.com [205.149.180.135]) by proxy1.ba.best.com (8.8.5/8.8.3) with ESMTP id IAA01839 for <ietf at ietf.org>; Fri, 25 Apr 1997 08:52:05 -0700 (PDT)
X-Sender: boo at shell5.ba.best.com
Message-Id: <v03007837af8680a06bba at [205.149.180.135]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Web-Site: http://www.natural-innovations.com/
X-Quote: I wasn't innocent till I got older. --WIK
Date: Fri, 25 Apr 1997 08:51:57 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Walter Ian Kaye <walter at natural-innovations.com>
Subject: Re: Spam Control Proposal (revision 2)
Source-Info: From (or Sender) name not authenticated.
At 12:45p -0500 04/24/97, Jon Davis <newbreed at isd.net> wrote:
> This proposal is formatted in HTML. If you would like to see the HTML
> version on your web browser, please visit
> http://www.winternet.com/~mackie/spam/
>
>
>
> Presented by Jon Davis, newbreed at isd.net
>
> "Shh dear, don't cause a fuss. I'll have your spam. I love it.
> I'm having spam, spam, spam, spam, spam, spam, spam, baked beans,
> spam, spam, spam and spam."
Heh, I deleted all but the above from that email (thank you Qualcomm for
letting Eudora 3.0 edit incoming messages -- I often fix spellings, too!).
I visited the web site, and it was much easier to read than that awful
email message! Very thoughtful <frame> implementation, too. :-)
I especially liked the Message-Tag idea, and your expansion of the idea
from <http://www.reply.net/junkmail.html>. It gave me some ideas of my
own, so I thank you and them for that. Someday, we will indeed have
mostly spam-free mailboxes. ::toasting to the future::
-Walter :)
__________________________________________________________________________
Walter Ian Kaye <boo_at_best*com> Programmer - Excel, AppleScript,
Mountain View, CA ProTERM, FoxPro, HTML
http://www.natural-innovations.com/ Musician - Guitarist, Songwriter
Received: from ietf.org by ietf.org id aa00525; 25 Apr 97 12:47 EDT
Received: from myco.InnovSoftD.com by ietf.org id aa00347; 25 Apr 97 12:42 EDT
Received: from www (ded-open.InnovSoftD.com [207.1.200.27]) by myco.isd.net (8.7.6/8.7.3) with SMTP id LAA31201; Fri, 25 Apr 1997 11:38:30 -0500
Message-Id: <199704251638.LAA31201 at myco.isd.net>
X-Mailer: Microsoft Outlook Express 4.71.0544.0
Sender:ietf-request at ietf.org
From: Jon Davis <newbreed at isd.net>
To: Gunnar Lindberg <lindberg at cdg.chalmers.se>
Cc: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: domain checking / SMTP host (was Re: Spam Control Proposal (revision 2))
Date: Fri, 25 Apr 1997 11:48:17 -0500
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Source-Info: From (or Sender) name not authenticated.
>Why not have all mail delivery agents make some rudimentary check
>on "From" address and at least assure the domain exists?
I'm not sure this would be related to spam. It would eliminate some of the
problems associated with forging, throwaway accounts/domains, and other
forms of cheating the SMTP netiquitte guidelines, and might affect spammers
but also anyone causing trouble via e-mail who tries to cover their tracks
in this way.
What you are proposing, then, is that the IETF should implement a standard
way for SMTP hosts to seek out the domain to see if it's still there. I
believe such a protocol/software-device has already been created and has
been around for some time, known as PING.
In that respect, I think it's just a matter of taking two different
technologies and putting them together in one server, which would be
something to take to the developers, not the IETF, I don't think. It *is* a
good idea, though. Sounds like a winner. You might want to forward the
idea to major SMTP server software developers. Or, if you are a
programmer, you could make quite a bit of money selling such a server.
Regards,
Jon
----
From: Gunnar Lindberg <lindberg at cdg.chalmers.se>
Newsgroups: info.ietf
Date: Friday, April 25, 1997 2:55 AM
Subject: Re: Spam Control Proposal (revision 2)
>>Date: Thu, 24 Apr 1997 12:45:48 -0500
>>From: Jon Davis <newbreed at isd.net>
>>To: ietf at ietf.org
>>Message-Id: <199704241730.MAA09519 at usamrid.innovsoftd.com>
>>Subject: Spam Control Proposal (revision 2)
>
>>This is a multi-part message in MIME format.
>> ...
>
>I admit I'm unable to grasp the contents in this message within
>the time I can spend on it (I did try, sigh :-). Let me, however,
>hand in another proposal, not without controversy, but "simpler":
>
>Why not have all mail delivery agents make some rudimentary check
>on "From" address and at least assure the domain exists? We've
>done so for some time now (rather small hack to sendmail) and it
>seems to work fairly well (we've received few mail complaints :-).
>
>This will stop spam from people that hide behind "un.known.com"
>(ooops, "known.com" exists, sorry, but you understand, see below).
>
>It will not stop people that hide behind "ietf.org" (or "ibm.com"
>or any other existing domain) but I assume using someone else's
>domain may cause legal action, at least in the US?
>
>It will certainly not stop the "honest spam" where someone wants
>to promote his product, but just the volume of "no thanks" (not
>to mention other responses...) will handle that - a full mailbox
>actually means he will miss the single "yes please" response...
>
> Gunnar Lindberg
>
>
Received: from ietf.org by ietf.org id aa01380; 25 Apr 97 12:51 EDT
Received: from gatekeeper.eop.gov by ietf.org id aa01106; 25 Apr 97 12:49 EDT
Received: from pmdf.eop.gov by gatekeeper.eop.gov; (5.65v3.2/1.1.8.2/17Oct95-0424PM)
id AA26588; Fri, 25 Apr 1997 12:45:39 -0400
Received: from mr.eop.gov by PMDF.EOP.GOV (PMDF V5.0-4 #6879)
id <01II4FQGKM9C0049CB at PMDF.EOP.GOV> for ietf at ietf.org; Fri,
25 Apr 1997 12:45:36 -0500 (EST)
Received: with PMDF-MR; Fri, 25 Apr 1997 12:45:32 -0500 (EST)
Mr-Received: by mta EOPMRX; Relayed; Fri, 25 Apr 1997 12:45:32 -0500
Alternate-Recipient: prohibited
Disclose-Recipients: prohibited
Date: Fri, 25 Apr 1997 12:35:00 -0500 (EST)
Sender:ietf-request at ietf.org
From: Thomas_A._Kalil at oa.eop.gov
Subject: Next Generation Internet concept paper
To: ietf at ietf.org
Message-Id: <01II4FQH1HWM0049CB at mr.eop.gov>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Ua-Content-Id: MBLINKAA
X400-Mts-Identifier: [;23542152407991/5194576 at EOPMRX]
Hop-Count: 1
Source-Info: From (or Sender) name not authenticated.
Message Creation Date was at 25-APR-1997 12:35:00
Dear IETFers:
A draft version of the Next Generation Internet concept paper is available on
the Web
for public comment. The paper has been available since April 8th - but the URL
has not
yet been widely disseminated.
See http://www.hpcc.gov/ngi-concept-08Apr97/
Comments are welcome, and can be sent to ngi at hpcc.gov. They will be most
helpful if provided by May 15th.
As I said at the IETF San Jose plenary, we're well aware that there is a great
deal more
Internet expertise outside the federal government than there is inside, so
comments
will be taken seriously.
A list of the current endorsements from industry and university leaders is at:
http://www.hpcc.gov/white-house/internet/endorsements.html
Thanks!
Tom Kalil
The White House
kalil_t at a1.eop.gov
Received: from ietf.org by ietf.org id aa06209; 25 Apr 97 14:23 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa05702; 25 Apr 97 14:17 EDT
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id OAA16236;
Fri, 25 Apr 1997 14:14:05 -0400
Message-Id: <199704251814.OAA16236 at black-ice.cc.vt.edu>
To: Jon Davis <newbreed at isd.net>
cc: Gunnar Lindberg <lindberg at cdg.chalmers.se>, ietf at ietf.org
Subject: Re: domain checking / SMTP host (was Re: Spam Control Proposal (revision 2))
In-reply-to: Your message of "Fri, 25 Apr 1997 11:48:17 CDT."
<199704251638.LAA31201 at myco.isd.net>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="<Valdis.Kletnieks at vt.edu>"
X-URL: http://black-ice.cc.vt.edu/~valdis/
References: <199704251638.LAA31201 at myco.isd.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32356.861992041.1 at black-ice.cc.vt.edu>
Date: Fri, 25 Apr 1997 14:14:01 -0400
Source-Info: From (or Sender) name not authenticated.
On Fri, 25 Apr 1997 11:48:17 CDT, Jon Davis said:
> What you are proposing, then, is that the IETF should implement a standard
> way for SMTP hosts to seek out the domain to see if it's still there. I
> believe such a protocol/software-device has already been created and has
> been around for some time, known as PING.
This doesn't work.
Consider a domain corporate.com that is MX'ed to an ISP that
happens to be down at the moment. Or even consider that due
to network congestion, your PING can get lost. If you happen
to be having a bad day and losing 30% of your packets on your
link to the world, you have to be careful to not also drop 30% of your
incoming mail on the floor just because the ping loses.
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.org by ietf.org id aa07637; 25 Apr 97 14:46 EDT
Received: from wentzl.cdg.chalmers.se by ietf.org id aa07537;
25 Apr 97 14:45 EDT
Received: (from lindberg at localhost)
by wentzl.cdg.chalmers.se (8.8.5/8.8.5) id UAA00100;
Fri, 25 Apr 1997 20:41:43 +0200 (MET DST)
Date: Fri, 25 Apr 1997 20:41:43 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Gunnar Lindberg <lindberg at cdg.chalmers.se>
Message-Id: <199704251841.UAA00100 at wentzl.cdg.chalmers.se>
To: Valdis.Kletnieks at vt.edu, newbreed at isd.net
Subject: Re: domain checking / SMTP host (was Re: Spam Control Proposal (revision 2))
Cc: ietf at ietf.org
X-Mailer: UCB Mail 5.3.8 96-10-07 (MIME)
Source-Info: From (or Sender) name not authenticated.
What we do is check out MX and A records and if we get a NXdomain
we basically say "553 you don't exist, go away". If we get TMPfail
etc we accept the mail anyway, assuming that it would be quite much
for anyone to figure out which TMPfail domain to hide in today (for
mail from our local domain - $#local - we also check local part to
assure it's from a valid user or an alias).
What came to my mind was that perhaps the IETF could recommend this
practice for general use in MTAs and hope that implementors do that.
I got some positive response from Eric Allman but with more and more
Internet players, an IETF recommendation might help.
Perhaps we should move this discussion elsewhere, to spare the IETF
general list from this spam :-).
Gunnar Lindberg
>From: Valdis.Kletnieks at vt.edu
>Date: Fri, 25 Apr 1997 14:14:01 -0400
>To: Jon Davis <newbreed at isd.net>
>cc: Gunnar Lindberg <lindberg at cdg.chalmers.se>, ietf at ietf.org
>Message-Id: <199704251814.OAA16236 at black-ice.cc.vt.edu>
>Subject: Re: domain checking / SMTP host (was Re: Spam Control Proposal (revision 2))
>On Fri, 25 Apr 1997 11:48:17 CDT, Jon Davis said:
>> What you are proposing, then, is that the IETF should implement a standard
>> way for SMTP hosts to seek out the domain to see if it's still there. I
>> believe such a protocol/software-device has already been created and has
>> been around for some time, known as PING.
>This doesn't work.
>Consider a domain corporate.com that is MX'ed to an ISP that
>happens to be down at the moment. Or even consider that due
>to network congestion, your PING can get lost. If you happen
>to be having a bad day and losing 30% of your packets on your
>link to the world, you have to be careful to not also drop 30% of your
>incoming mail on the floor just because the ping loses.
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
Received: from ietf.org by ietf.org id aa09149; 25 Apr 97 15:03 EDT
Received: from callandor.cybercash.com by ietf.org id aa08639;
25 Apr 97 14:59 EDT
Received: by callandor.cybercash.com; id OAA15770; Fri, 25 Apr 1997 14:47:13 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma015750; Fri, 25 Apr 97 14:46:45 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA26493; Fri, 25 Apr 97 14:51:48 EDT
Date: Fri, 25 Apr 1997 14:51:48 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Jon Davis <newbreed at isd.net>
Cc: ietf at ietf.org
Subject: Re: domain checking / SMTP host (was Re: Spam Control Proposal (revision 2))
In-Reply-To: <199704251814.OAA16236 at black-ice.cc.vt.edu>
Message-Id: <Pine.SUN.3.91.970425144030.25222D-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
At most, this should be a Best Current Practice, not a Standard as you
suggested. It should be up to each mail server how closely it wishes to
screen incoming mail. Certainly, determining that there is at least a
possibility of replying to the mail by checking that the envelope address
and from address are well formed and use an existing domain name would
normally be reasonable (yes, it's more complex than that due to reply-to,
null envelope addresses for error reports, etc., but I hope you get the
idea). Checking that those addresses are pingable seems wrong. They
might not even be Internet hosts, being connected by UUCP for example.
This would cut some spam, avoid problems with those who have
misconfigured their mail client software, etc.
Some sites/mailing-lists/whatever might want to impose more stringent
requirements, like requiring a non-null subject line, rejecting mail with
"too many" "to" or "cc" addresses, screening "from" type (and received)
header lines for certain domain names, requiring security (see
draft-eastlake-muse-*), etc.
The more restrictions you add, of course, the greater the chance of
blocking legitimate desired mail.
An RFC reviewing the pros and cons of such possible restrictions would be
useful.
Donald
On Fri, 25 Apr 1997 Valdis.Kletnieks at vt.edu wrote:
> Date: Fri, 25 Apr 1997 14:14:01 -0400
> From: Valdis.Kletnieks at vt.edu
> To: Jon Davis <newbreed at isd.net>
> Cc: Gunnar Lindberg <lindberg at cdg.chalmers.se>, ietf at ietf.org
> Subject: Re: domain checking / SMTP host (was Re: Spam Control Proposal (revision 2))
>
> On Fri, 25 Apr 1997 11:48:17 CDT, Jon Davis said:
> > What you are proposing, then, is that the IETF should implement a standard
> > way for SMTP hosts to seek out the domain to see if it's still there. I
> > believe such a protocol/software-device has already been created and has
> > been around for some time, known as PING.
>
> This doesn't work.
>
> Consider a domain corporate.com that is MX'ed to an ISP that
> happens to be down at the moment. Or even consider that due
> to network congestion, your PING can get lost. If you happen
> to be having a bad day and losing 30% of your packets on your
> link to the world, you have to be careful to not also drop 30% of your
> incoming mail on the floor just because the ping loses.
>
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
>
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from cnri by ietf.org id aa21258; 25 Apr 97 16:50 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19190;
25 Apr 97 16:50 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA19971 at pad-thai.cam.ov.com>; Fri, 25 Apr 1997 19:09:31 GMT
Message-Id: <3.0.32.19970425120454.00963750 at pop-srvr.cybersafe.com>
X-Sender: matth at pop-srvr.cybersafe.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 25 Apr 1997 12:04:55 -0700
To: cat-ietf at mit.edu, kerberos at mit.edu
From: Matt Hur <matt.hur at cybersafe.com>
Subject: Kerberos error data type sequence in revised RFC 1510
Cc: bcn at isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
The revisions to the KRB-ERROR message add the optional e-cksum field (see
excerpt below). As was suggested in the draft "Integrity Protection for
the Kerberos Error Message", presented at the Memphis IETF, I propose that
the optional e-cksum field be changed to an optional sequence that
specifies a type and value pair
e.g.
TypedData ::= SEQUENCE {
data-type [1] INTEGER,
data-value [2] OCTET STRING,
}
The KRB-ERROR message would then change as follows:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL,
e-typed-data[13] SEQUENCE TypedData OPTIONAL
}
This would allow for any number of data types to be defined and returned in
any KRB-ERROR message regardless of the error code. Currently, any
additional data that is returned in a KRB-ERROR message is explicitly bound
to the error code; this solution would allow for extensibility.
A checksum e-typed-data type would be defined as follows:
data-type = CHECKSUM
data-value = Checksum (as defined in RFC 1510)
-- Matt
=====================================================
EXCERPT from the revised RFC 1510
The KRB_ERROR message consists of the following fields:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL,
e-cksum[13] Checksum OPTIONAL
}
e-data This field contains additional data about the
error for use by the application to help it
recover from or handle the error. If the error-
code is KDC_ERR_PREAUTH_REQUIRED, then the e-data
field will contain an encoding of a sequence of
padata fields, each corresponding to an acceptable
pre-authentication method and optionally contain-
ing data for the method:
e-cksum This field contains an optional checksum for the
KRB-ERROR message. The checksum is calculated
over the Kerberos ASN.1 encoding of the KRB-ERROR
message with the checksum absent. The checksum is
then added to the KRB-ERROR structure and the mes-
sage is re-encoded. The Checksum should be calcu-
lated using the session key from the ticket grant-
ing ticket or service ticket, where available. If
Section 5.9.1. - 71 - Expires 11 October 1997
Version 5 - Specification Revision 6
the error is in response to a TGS or AP request,
the checksum should be calculated uing the the
session key from the client's ticket. If the
error is in response to an AS request, then the
checksum should be calulated using the client's
secret key ONLY if there has been suitable preau-
thentication to prove knowledge of the secret key
by the client If a checksum can not be computed
because the key to be used is not available, no
checksum will be included.
----------------------------------------------------------------
Matt Hur CyberSafe
matt.hur at cybersafe.com 1605 NW Sammamish Road, Suite 310
(206) 391-6000 Issaquah, WA 98027-5378
http://www.cybersafe.com
Received: from ietf.org by ietf.org id aa27037; 25 Apr 97 18:28 EDT
Received: from mail-relay.EU.net by ietf.org id aa26905; 25 Apr 97 18:24 EDT
Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by mail-relay.EU.net (8.8.5/8.6.10) with SMTP id AAA11607 for <ietf at ietf.org>; Sat, 26 Apr 1997 00:21:24 +0200 (MET DST)
Received: by jotun.EU.net id AA03139
(5.67a/IDA-1.5 for ietf at ietf.org); Sat, 26 Apr 1997 00:21:23 +0200
Message-Id: <199704252221.AA03139 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <pgb at eu.net>
Date: Sat, 26 Apr 1997 00:21:23 +0200
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: ietf at ietf.org
Subject: Autonomous System Sanity Protocol
Source-Info: From (or Sender) name not authenticated.
I guess people have seen/heard about today's spectacular routing
meltdown. If not, short version is that somebody redistributed the
entire global routing table into a classful IGP, then re-exported the
prefix set with the added twist that the classful IGP had stripped
the mask information, and they were thus announcing the first classful
network in each CIDR block (and this is then a more specific prefix).
Given that the number of operators who for one reason or another are
unable to perform customer prefix filtering probably is increasing
rather than decreasing, this probably isn't the last time we have
seen this happen. Looking back, it hasn't happened too often (the
last time I recall something on a similar scale was during the
Stockholm IETF meeting), but it is very likely happening on a smaller
scale quite frequently; and I'm afraid it will happen on a larger
scale more and more frequently.
A solution would be to disallow export from an autonomous system of
routes which has been through the infamous EGP->IGP->EGP chain,
provided there are no legitimate uses for this; I can't think of such
a situation.
In the perfect solution, all prefixes carried within an IGP would be
accompanied by origin information (E or I). The IGP would set origin
E when receiving routes from an EGP; it would set origin I when
picking up statically configured prefixes and would import the
already existing origin information when picking up prefixes from
another IGP. Prefixes with IGP origin E would never be allowed to
leave the AS (ie, the EGP would treat them as having eg BGP community
no-export, or possibly ignore them altogether). This would not
interfere with normal transit AS operation, where prefixes are
distributed through an internal BGP mesh -- the IGP origin
information would only be at play in redistribution between IGP and
EGP. But as this solution would require a unified revision of all
common IGPs, in order for them to carry origin information, it is
probably too ambitious.
An alternative solution would be to try to simulate the perfect
solution, by retrofitting a sanity check to BGP4. In this scenario
the EGP (BGP4) in an external border gateway (ie, one which is
speaking to border gateways in other ASs) would (be required to) have
at its disposal redistribution information from all other such
external border gateways. The EGP would then refuse to export routes
it had learnt from an IGP and which had previously been redistributed
from an EGP into -any- IGP by any other external border gateway. The
protocol for this -could- be piggybacked on top of the real iBGP
mesh, which would carry it across route reflectors and confederations
(tricky), but that would leave a gaping hole in the situation where
there is no iBGP mesh (just imagine two external border gateways not
having any iBGP session between them). Hence, this solution will
have to be integrated in a separate protocol also performing router
discovery. It is not as obviously straight and clean as the perfect
solution described above, and, in particular, it would need to base
itself on additions to RFC1812 (Requirements for IP Version 4
Routers), whereby an IGP would not be allowed to establish
adjacencies/whatever over an interface where the Autonomous System
Sanity Protocol was disabled (this requirement could be relaxed to
only apply to routers having an EGP configured). In practice, this
would probably have to be further relaxed to a best effort
implementation, whereby the ASSP does its job if its neighbours also
implement the protocol, otherwise not. But maybe all of this is too
ambitious too, given the need for multi-vendor integration, problems
with coordinated software upgrades and roll-out, etc; at least, it
would take considerable time (12-24 months) before one could expect
anything looking like widespread penetration. There are also
potential inconsistency problems looming, given that the ASSP is
disjoint from the IGPs; reasonable defaults in the face of missing
ASSP information could render it useless.
In fact, having described the idea of the ASSP, I'm inclined to believe
that a unified revision of all common IGPs, in order for them to carry
origin information as previously described, would be an easier and
more reliable way to implement the idea.
Does anybody feel anything in particular wrt these ideas?
--
------ ___ --- Per G. Bilse, Director Network Eng & Ops
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net
Received: from ietf.org by ietf.org id aa00410; 25 Apr 97 20:44 EDT
Received: from ginger.lcs.mit.edu by ietf.org id aa00229; 25 Apr 97 20:37 EDT
Received: by ginger.lcs.mit.edu
id AA14066; Fri, 25 Apr 97 20:34:32 -0400
Date: Fri, 25 Apr 97 20:34:32 -0400
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9704260034.AA14066 at ginger.lcs.mit.edu>
To: ietf at ietf.org, pgb at eu.net
Subject: Re: Autonomous System Sanity Protocol
Cc: jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: Per Gregers Bilse <pgb at eu.net>
I guess people have seen/heard about today's spectacular routing
meltdown. ... I'm afraid it will happen on a larger scale more and more
frequently. ... Does anybody feel anything in particular wrt these
ideas?
IMNSHO, you're re-arranging deckchairs on the Titanic.
The whole model of passing around routing tables is the Wrong Thing. We
need to move to a routing architecture where maps are distributed, *not*
routing tables.
As an added benfit, in such a paradigm, you get all kinds of extra routing
capability, such as:
- QOS routing
- all the industrial-strength security you want - see Radia Perlman's PhD
thesis work
- much easier policy controls (i.e. basic knobs which are fundamentally
much closer to what you are trying to achieve)
- more robust routing
- etc, etc.
This stuff is not exactly a new idea. It's been worked on for over 10
years now.
Noel
Received: from ietf.org by ietf.org id aa11504; 26 Apr 97 0:41 EDT
Received: from red.jnx.com by ietf.org id aa11365; 26 Apr 97 0:35 EDT
Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.6])
by red.jnx.com (8.8.5/8.8.5) with ESMTP id VAA12772;
Fri, 25 Apr 1997 21:32:06 -0700 (PDT)
Received: (from tli at localhost) by chimp.jnx.com (8.7.6/8.7.3) id VAA26979; Fri, 25 Apr 1997 21:31:55 -0700 (PDT)
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
cc: ietf at ietf.org
Reply-to: big-internet at munnari.oz.au
Subject: Re: Autonomous System Sanity Protocol
References: <9704260034.AA14066 at ginger.lcs.mit.edu>
Sender:ietf-request at ietf.org
From: Tony Li <tli at jnx.com>
Date: 25 Apr 1997 21:31:54 -0700
In-Reply-To: jnc at ginger.lcs.mit.edu's message of 26 Apr 97 00:34:32 GMT
Message-ID: <82lo66z9ol.fsf at chimp.jnx.com>
Lines: 10
X-Mailer: Gnus v5.3/Emacs 19.34
Source-Info: From (or Sender) name not authenticated.
jnc at ginger.lcs.mit.edu (Noel Chiappa) writes:
> The whole model of passing around routing tables is the Wrong Thing. We
> need to move to a routing architecture where maps are distributed, *not*
> routing tables.
Exactly how does this prevent the exchange of bad information?
Tony
Received: from ietf.org by ietf.org id aa15733; 26 Apr 97 5:51 EDT
Received: from cnri by ietf.org id aa15492; 26 Apr 97 5:47 EDT
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa05690;
26 Apr 97 5:47 EDT
Received: by ginger.lcs.mit.edu
id AA19156; Sat, 26 Apr 97 05:44:04 -0400
Date: Sat, 26 Apr 97 05:44:04 -0400
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9704260944.AA19156 at ginger.lcs.mit.edu>
To: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Subject: Re: Autonomous System Sanity Protocol
Cc: jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: Tony Li <tli at jnx.com>
> We need to move to a routing architecture where maps are distributed,
> *not* routing tables.
Exactly how does this prevent the exchange of bad information?
Well, a full-scale explanation is a major tome (we can explore that on Big-I
in more detail if you want), but *briefly*, the idea is that you can i) prevent
lots of kinds of bad information, and ii) deal much better with the kinds you
can't stop.
For instance, use of public key cryptography can prevent anyone else from
originating bad information about connectivity inside or to X - their map
updates will not be correctly signed with X's private key. Only "auhorized"
agents of topological entity X (i.e. those allowed to distribute maps or
abstractions of X, outside X) have the key to sign map data about X.
(X and Y can still cooperate to lie about having connectivity between them,
when in fact they do not, but you can (albeit with some work) detect that and
work around it, if you have not only a map distribution system, but explicit
routing too.)
It can certainly prevent all unilateral bad information, i.e. based on someone
incorrectly configuring their routers (or software/hardware bugs).
Noel
Received: from ietf.org by ietf.org id aa21400; 26 Apr 97 12:12 EDT
Received: from mail-relay.EU.net by ietf.org id aa21013; 26 Apr 97 11:57 EDT
Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by mail-relay.EU.net (8.8.5/8.6.10) with SMTP id RAA21545; Sat, 26 Apr 1997 17:54:24 +0200 (MET DST)
Received: by jotun.EU.net id AA05191
(5.67a/IDA-1.5); Sat, 26 Apr 1997 17:54:22 +0200
Message-Id: <199704261554.AA05191 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <pgb at eu.net>
Date: Sat, 26 Apr 1997 17:54:22 +0200
In-Reply-To: <9704260034.AA14066 at ginger.lcs.mit.edu>
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Subject: Re: Autonomous System Sanity Protocol
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
On Apr 25, 20:34, Noel Chiappa <jnc at ginger.lcs.mit.edu> wrote:
> IMNSHO, you're re-arranging deckchairs on the Titanic.
I don't see the relevance of this analogy, unless you believe
disaster is imminent. If so, when do you expect what to happen?
> The whole model of passing around routing tables is the Wrong Thing. We
Quite possibly, but this is nevertheless the state of the industry
today, and gradual improvements have always been introduced
everywhere as long as it appears that they will do something useful
before they're obsolete. You are arguing that one should not improve
the seaworthiness of ships, because in the future there will be
aeroplanes.
> need to move to a routing architecture where maps are distributed, *not*
> routing tables.
> As an added benfit, in such a paradigm, you get all kinds of extra routing
>[...]
> This stuff is not exactly a new idea. It's been worked on for over 10
> years now.
And where are we today? IOW, where can I buy one, and which internet
can I plug it into? I have no principal/philosophical objections wrt
interesting changes, but we need something that is for real, today.
--
------ ___ --- Per G. Bilse, Director Network Eng & Ops
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net
Received: from ietf.org by ietf.org id aa22056; 26 Apr 97 12:24 EDT
Received: from cnri by ietf.org id aa21968; 26 Apr 97 12:22 EDT
Received: from mail-relay.EU.net by CNRI.Reston.VA.US id aa10718;
26 Apr 97 12:22 EDT
Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by mail-relay.EU.net (8.8.5/8.6.10) with SMTP id SAA22105; Sat, 26 Apr 1997 18:19:06 +0200 (MET DST)
Received: by jotun.EU.net id AA05241
(5.67a/IDA-1.5); Sat, 26 Apr 1997 18:19:05 +0200
Message-Id: <199704261619.AA05241 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <pgb at eu.net>
Date: Sat, 26 Apr 1997 18:19:05 +0200
In-Reply-To: <9704260944.AA19156 at ginger.lcs.mit.edu>
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Subject: Re: Autonomous System Sanity Protocol
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
On Apr 26, 5:44, Noel Chiappa <jnc at ginger.lcs.mit.edu> wrote:
>[...]
> It can certainly prevent all unilateral bad information, i.e. based on someone
> incorrectly configuring their routers (or software/hardware bugs).
We have the "technology" to do this today. It is called "customer
prefix filtering", but it doesn't happen because for one reason
or another a number of operators are unable to implement it.
My point is that the current paradigm (which is for real, whether we
like it or not) has a gaping hole in it: the infamous EGP->IGP->EGP
redistribution chain, where information which is vital for consistent
behaviour can and will be lost. I'm looking for a way to plug that hole.
--
------ ___ --- Per G. Bilse, Director Network Eng & Ops
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net
Received: from ietf.org by ietf.org id aa24059; 26 Apr 97 13:57 EDT
Received: from cnri by ietf.org id aa23947; 26 Apr 97 13:53 EDT
Received: from trix.Cisco.com by CNRI.Reston.VA.US id aa11932;
26 Apr 97 13:53 EDT
Received: (roque at localhost) by trix.cisco.com (8.6.12/8.6.5) id KAA21019; Sat, 26 Apr 1997 10:50:21 -0700
Date: Sat, 26 Apr 1997 10:50:21 -0700
Message-Id: <199704261750.KAA21019 at trix.cisco.com>
Sender:ietf-request at ietf.org
From: Pedro Marques <roque at cisco.com>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Subject: Re: Autonomous System Sanity Protocol
In-Reply-To: <9704260944.AA19156 at ginger.lcs.mit.edu>
References: <9704260944.AA19156 at ginger.lcs.mit.edu>
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
>>>>> "Noel" == Noel Chiappa <jnc at ginger.lcs.mit.edu> writes:
Noel> From: Tony Li <tli at jnx.com>
>> We need to move to a routing architecture where maps are
>> distributed, *not* routing tables.
Noel> Exactly how does this prevent the exchange of bad
Noel> information?
Noel> Well, a full-scale explanation is a major tome (we can
Noel> explore that on Big-I in more detail if you want), but
Noel> *briefly*, the idea is that you can i) prevent lots of kinds
Noel> of bad information, and ii) deal much better with the kinds
Noel> you can't stop.
Noel> For instance, use of public key cryptography can prevent
Noel> anyone else from originating bad information about
Noel> connectivity inside or to X - their map updates will not be
Noel> correctly signed with X's private key. Only "auhorized"
Noel> agents of topological entity X (i.e. those allowed to
Noel> distribute maps or abstractions of X, outside X) have the
Noel> key to sign map data about X.
s/map/BGP route/g
... and everything you said still holds.
./Pedro.
Received: from ietf.org by ietf.org id aa25322; 26 Apr 97 14:15 EDT
Received: from ginger.lcs.mit.edu by ietf.org id aa25223; 26 Apr 97 14:14 EDT
Received: by ginger.lcs.mit.edu
id AA20597; Sat, 26 Apr 97 14:10:56 -0400
Date: Sat, 26 Apr 97 14:10:56 -0400
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9704261810.AA20597 at ginger.lcs.mit.edu>
To: jnc at ginger.lcs.mit.edu, pgb at eu.net
Subject: Re: Autonomous System Sanity Protocol
Cc: ietf at ietf.org, jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: Per Gregers Bilse <pgb at eu.net>
> IMNSHO, you're re-arranging deckchairs on the Titanic.
I don't see the relevance of this analogy, unless you believe
disaster is imminent.
Perhaps it wasn't the best phrase: I meant to imply that the changes you
propose are not really going to result in any substantial improvement (i.e.
fix all the problems that are looming) - the problem is the existing model.
> The whole model of passing around routing tables is the Wrong Thing.
Quite possibly, but this is nevertheless the state of the industry
today, and gradual improvements have always been introduced everywhere as
long as it appears that they will do something useful before they're
obsolete.
Gradual improvements are certainly viable, but the history of technology
shows (quite commonly) that there are times for gradual improvement, and
times for more radical changes - and trying to do the former when the
situation is more suited to the latter is rarely useful.
You are arguing that one should not improve the seaworthiness of
ships, because in the future there will be aeroplanes.
No, I'm arguing that further improvements to horse-drawn vehicles are a waste
of time, there is a far better technology available to do the same thing,
i.e. vehicles with engines.
IOW, where can I buy one, and which internet can I plug it into? I have
no principal/philosophical objections wrt interesting changes, but we
need something that is for real, today.
Well, we've got something of a chicken and egg problem. As long as everyone
feels that something like this is "too radical" and "too complicated" and
"not viable", etc, etc, it's not going to get done. Nobody wants to work on
something that's not going to happen.
Unfortunately, switching to a new routing architecture is a more difficult
process because it doesn't have what I call "self-deployability", which is
just a word to mean that it 'deploys itself', by being so useful to 1% who do
deploy it that 5% of the people start using it, and so on.
I don't have any easy answer on how to overcome this. (If I did, I'd have
used it by now! :-) I think it will just have to wait until the defects
and deficiencies of the old model are just so painful no other choice is
left.
I can't stop people from making the kind of changes you suggest, I'm merely
suggesting that, in future hindsight, we might think that putting that
energy into switching now would be a more productive use of our time and
energy.
Can I prove that? No.
> It can certainly prevent all unilateral bad information, i.e. based on
> someone incorrectly config uring their routers (or software/hardware
> bugs).
We have the "technology" to do this today. It is called "customer
prefix filtering", but it doesn't happen because for one reason
or another a number of operators are unable to implement it.
No, it's *not* the functional equivalent. Configuration methods of the kind
you mention are i) much more work (due to the need to configure lots of
stuff), and ii) still much more vulnerable (for a variety of reasons,
including single-point security solutions are always more robust than
solutions which rely on correct configuration in all manner of places).
(Also, for technical reasons, destination-vector architectures are more
vulnerable since you *have* to depend on all the entities between you and the
source of the route.)
My point is that the current paradigm (which is for real, whether we
like it or not)
You needn't state the obvious.
has a gaping hole in it: the infamous EGP->IGP->EGP redistribution chain,
where information which is vital for consistent behaviour can and will be
lost. I'm looking for a way to plug that hole.
You can fix that problem, sure. However, I think there are more effective
ways to spend our time and energy, in the long term. Other problems are going
to crop up with this basic architecture fairly shortly, and we can be
continually working around them (the ones we *can* work around, some of them
are fundamental), or we can put much the same amount of effort into something
that has a higher cost/benefit ratio.
Noel
Received: from ietf.org by ietf.org id aa26319; 26 Apr 97 14:34 EDT
Received: from cnri by ietf.org id aa26230; 26 Apr 97 14:33 EDT
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa12450;
26 Apr 97 14:33 EDT
Received: by ginger.lcs.mit.edu
id AA20681; Sat, 26 Apr 97 14:29:41 -0400
Date: Sat, 26 Apr 97 14:29:41 -0400
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9704261829.AA20681 at ginger.lcs.mit.edu>
To: jnc at ginger.lcs.mit.edu, roque at cisco.com
Subject: Re: Autonomous System Sanity Protocol
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US,
jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
<My apologies to the IETF list for getting into routing grup, but I can't
allow these erroneous statements to go uncorrected.>
From: Pedro Marques <roque at cisco.com>
> use of public key cryptography can prevent anyone else from originating
> bad information about connectivity inside or to X
s/map/BGP route/g
... and everything you said still holds.
No. There is a fundamental difference.
If I'm X, I know, *authoritatively and definitively*, who is attached to me.
I can then originate this information and sign it, in the form of map element
information ("Hi, I'm X, and I'm attached to A, B and C, and here's the seal
for that, encrypted with my private key".) You can use the concatentation of
all such data (modulo, as I said, issues like people co-operating to lie
about non-existent connections) to produce routing which is resistant to
single-point failure and/or malice.
However, in a destination vector system, such as BGP, X cannot know,
authoritatively, the details of connectivity elsewhere. That means that Y can
pass on to Z information about a route which Y has to X, and there is no way
for X to sign *that* data, or even to verify that it is correct.
(Extra detail, ignore if you don't care: Saying you can recursively sign the
route doesn't help, I don't think - you can strip off later elements and work
with a partial, and fully signed, route. In other words, if I get a route to
X which is Z->Y->X, it *can't* be the case that when Z signed it, he only
signed an indivisible composite - if so, how can you check that the Y->X
portion is legitimate, and not something Z made up? You have to be able to
check the Y->X component, and the X source, separately - and if you can do
that you can snarf the Y->X component and discard the Z component.)
Please think about the issues some, and study Radia Perlman's PhD thesis,
(where you will find it all laid out) before claiming that the two are
equivalently protectable, when they are not.
Connectivity information is *fundamentally* different from *reachability*
information.
Noel
Received: from ietf.org by ietf.org id aa27486; 26 Apr 97 15:02 EDT
Received: from cnri by ietf.org id aa27384; 26 Apr 97 15:00 EDT
Received: from pinky.junction.net by CNRI.Reston.VA.US id aa12803;
26 Apr 97 15:00 EDT
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id LAA22339; Sat, 26 Apr 1997 11:56:37 -0700
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id LAA28805; Sat, 26 Apr 1997 11:52:00 -0700
Date: Sat, 26 Apr 1997 11:51:58 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: big-internet at munnari.oz.au
cc: roque at cisco.com, ietf at CNRI.Reston.VA.US
Subject: Re: Autonomous System Sanity Protocol
In-Reply-To: <9704261829.AA20681 at ginger.lcs.mit.edu>
Message-ID: <Pine.BSI.3.93.970426114843.6580D-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sat, 26 Apr 1997, Noel Chiappa wrote:
> Connectivity information is *fundamentally* different from *reachability*
> information.
Using maps implies that there is a central database that records the
current state of this fairly static connectivity information and that
routing announcements would be verified against this database to ensure
that the announced routes correspond to edges on the map. So, who will
manage the database and how will it be distributed so that this database
does not become a single point of failure?
Also, do you know if Perlman's thesis is available on the net?
Michael Dillon - Internet & ISP Consulting
Memra Software Inc. - Fax: +1-250-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from ietf.org by ietf.org id aa19431; 27 Apr 97 10:15 EDT
Received: from cnri by ietf.org id aa19046; 27 Apr 97 10:04 EDT
Received: from postoffice.Reston.mci.net by CNRI.Reston.VA.US id aa09004;
27 Apr 97 10:04 EDT
Received: from mci.net (marvinthemartian [166.45.4.32])
by postoffice.Reston.mci.net (8.8.5/8.8.5) with ESMTP id KAA28676;
Sun, 27 Apr 1997 10:00:03 -0400 (EDT)
Message-Id: <199704271400.KAA28676 at postoffice.Reston.mci.net>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
cc: roque at cisco.com, big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Subject: Re: Autonomous System Sanity Protocol
In-reply-to: Your message of "Sat, 26 Apr 1997 14:29:41 EDT."
<9704261829.AA20681 at ginger.lcs.mit.edu>
Date: Sun, 27 Apr 1997 10:00:02 -0400
Sender:ietf-request at ietf.org
From: Jeff Young <young at mci.net>
Source-Info: From (or Sender) name not authenticated.
so in addition to the registries that hold the routing information
we need some kind of key repository for the exchange of information.
then there's the new or improved protocol to handle passing and
authenticating the information.
that'd protect us from a lot (an even bigger previous - 192/8 - fiasco
comes to mind). sounds like the use of registries is still a good start.
Jeff Young
young at mci.net
> Return-Path: owner-Big-Internet at munnari.OZ.AU
> Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5])
> by postoffice.Reston.mci.net (8.8.5/8.8.5) with SMTP id PAA20824;
> Sat, 26 Apr 1997 15:00:11 -0400 (EDT)
> Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
> id EAA09755; Sun, 27 Apr 1997 04:37:20 +1000
> Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
> id EAA09734; Sun, 27 Apr 1997 04:29:47 +1000
> Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56)
> id SA04656; Sun, 27 Apr 1997 04:29:45 +1000 (from jnc at ginger.lcs.mit.edu)
> Received: by ginger.lcs.mit.edu
> id AA20681; Sat, 26 Apr 97 14:29:41 -0400
> Date: Sat, 26 Apr 97 14:29:41 -0400
> From: jnc at ginger.lcs.mit.edu (Noel Chiappa)
> Message-Id: <9704261829.AA20681 at ginger.lcs.mit.edu>
> To: jnc at ginger.lcs.mit.edu, roque at cisco.com
> Subject: Re: Autonomous System Sanity Protocol
> Cc: big-internet at munnari.OZ.AU, ietf at cnri.reston.va.us, jnc at ginger.lcs.mit.edu
> Precedence: bulk
> Content-Type: text
> Content-Length: 2081
>
> <My apologies to the IETF list for getting into routing grup, but I can't
> allow these erroneous statements to go uncorrected.>
>
> From: Pedro Marques <roque at cisco.com>
>
> > use of public key cryptography can prevent anyone else from originating
> > bad information about connectivity inside or to X
>
> s/map/BGP route/g
> ... and everything you said still holds.
>
> No. There is a fundamental difference.
>
> If I'm X, I know, *authoritatively and definitively*, who is attached to me.
> I can then originate this information and sign it, in the form of map element
> information ("Hi, I'm X, and I'm attached to A, B and C, and here's the seal
> for that, encrypted with my private key".) You can use the concatentation of
> all such data (modulo, as I said, issues like people co-operating to lie
> about non-existent connections) to produce routing which is resistant to
> single-point failure and/or malice.
>
> However, in a destination vector system, such as BGP, X cannot know,
> authoritatively, the details of connectivity elsewhere. That means that Y can
> pass on to Z information about a route which Y has to X, and there is no way
> for X to sign *that* data, or even to verify that it is correct.
>
> (Extra detail, ignore if you don't care: Saying you can recursively sign the
> route doesn't help, I don't think - you can strip off later elements and work
> with a partial, and fully signed, route. In other words, if I get a route to
> X which is Z->Y->X, it *can't* be the case that when Z signed it, he only
> signed an indivisible composite - if so, how can you check that the Y->X
> portion is legitimate, and not something Z made up? You have to be able to
> check the Y->X component, and the X source, separately - and if you can do
> that you can snarf the Y->X component and discard the Z component.)
>
> Please think about the issues some, and study Radia Perlman's PhD thesis,
> (where you will find it all laid out) before claiming that the two are
> equivalently protectable, when they are not.
>
> Connectivity information is *fundamentally* different from *reachability*
> information.
>
> Noel
Received: from ietf.org by ietf.org id aa21901; 27 Apr 97 11:50 EDT
Received: from proxy2.ba.best.com by ietf.org id aa21793; 27 Apr 97 11:46 EDT
Received: from [205.149.180.135] (boo.vip.best.com [205.149.180.135]) by proxy2.ba.best.com (8.8.5/8.8.3) with ESMTP id IAA26090 for <ietf at ietf.org>; Sun, 27 Apr 1997 08:43:00 -0700 (PDT)
X-Sender: boo at shell5.ba.best.com
Message-Id: <v03102800af891ff4b72e at [205.149.180.135]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Quote: I wasn't innocent till I got older. --WIK
X-Calibur: Signifying that I, Arthur, was to become King of the Britons
X-Mailer: Eudora Pro 3.1 for MacOS
Date: Sun, 27 Apr 1997 08:42:48 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Walter Ian Kaye <walter at natural-innovations.com>
Subject: Arriving at a transfer protocol?
Source-Info: From (or Sender) name not authenticated.
Ok, let's say a person has an idea for sending data structures across the
'Net (in this case, broadcasting tickertape-like messages). How does one go
about finding the "right" protocol? Or, more basically, what are the
options for such a thing? I looked at Netscape's "push" documentation, but
it makes me wonder if it might use up too many server resources (I don't
have my own server machine; I have to use my ISP, which just switched from
IRIX to FreeBSD). Are "netcasting" programs expensive? I don't even know if
my ISP would let me run something like that (I can run my own CGIs, but
only up to a certain number of cpu-seconds per day -- only fair to other
users of the ISP). Also, how do URL scheme names relate to protocols? Like,
could I use HTTP but have a foobar:// scheme?
thanks in advance,
-Walter
__________________________________________________________________________
Walter Ian Kaye <boo_at_best*com> Programmer - Excel, AppleScript,
Mountain View, CA ProTERM, FoxPro, HTML
http://www.natural-innovations.com/ Musician - Guitarist, Songwriter
Received: from ietf.org by ietf.org id aa11869; 28 Apr 97 2:14 EDT
Received: from cnri by ietf.org id aa11538; 28 Apr 97 2:04 EDT
Received: from callandor.cybercash.com by CNRI.Reston.VA.US id aa02844;
28 Apr 97 2:04 EDT
Received: by callandor.cybercash.com; id BAA25318; Mon, 28 Apr 1997 01:50:17 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma025312; Mon, 28 Apr 97 01:49:46 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA24447; Mon, 28 Apr 97 01:54:56 EDT
Date: Mon, 28 Apr 1997 01:54:55 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Jeff Young <young at mci.net>
Cc: roque at cisco.com, big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Subject: Re: Autonomous System Sanity Protocol
In-Reply-To: <199704271400.KAA28676 at postoffice.Reston.mci.net>
Message-Id: <Pine.SUN.3.91.970428014945.24064F-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
See RFC 2065. DNSSEC provides a way to securely distribute keys
associated with domain names. By populating the in-addr.arpa tree with
keys and securing the DNS tree above that point, you could provide for
authoritative messages signed by an IP address as to what local
connectivity it sees.
Donald
(Alternatively you could distribute the key and server list for the
in-addr.arpa (and ip6.int or whatever it is) nodes and not have to secure
the tree above that point. And I'm sure there are complication
associated with classless in-addr delegation...but these are probably
surmoutable.)
On Sun, 27 Apr 1997, Jeff Young wrote:
> Date: Sun, 27 Apr 1997 10:00:02 -0400
> From: Jeff Young <young at mci.net>
> To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
> Cc: roque at cisco.com, big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
> Subject: Re: Autonomous System Sanity Protocol
>
> so in addition to the registries that hold the routing information
> we need some kind of key repository for the exchange of information.
> then there's the new or improved protocol to handle passing and
> authenticating the information.
>
> that'd protect us from a lot (an even bigger previous - 192/8 - fiasco
> comes to mind). sounds like the use of registries is still a good start.
>
> Jeff Young
> young at mci.net
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa16024; 28 Apr 97 6:43 EDT
Received: from Ostrogoth.gv-itf.unisource.nl by ietf.org id aa15886;
28 Apr 97 6:38 EDT
Received: from localhost (localhost [127.0.0.1])
by ostrogoth.gv-itf.unisource.nl (8.8.5/8.8.5) with SMTP id MAA01249;
Mon, 28 Apr 1997 12:33:43 +0200
Date: Mon, 28 Apr 1997 12:33:43 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Frank de Lange <frank at animalhouse.ml.org>
X-Orig-Sender: frank at ostrogoth.gv-itf.unisource.nl
Reply-To: Frank de Lange <frank at animalhouse.ml.org>
Subject: Re: Re: Spam Control Proposal (revision 2)
To: Dr-X <raidesj at arrakis.es>
cc: ietf at ietf.org
In-Reply-To: <199704251356.PAA02506 at arrakis.es>
Message-ID: <ML-3.3.862223623.7349.frank at ostrogoth.gv-itf.unisource.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Err, Dr-X, please,
Could you trim the size of your .sig please? I mean, talking on spamming, that
.sig is almost a spam in it's own right. How about DR-X? A certain Malcolm
became famous with it, and he didn't need such a humongous .sig too...
Cheers,
Frank de Lange
Unisource Business Networks NL bv
Received: from ietf.org by ietf.org id aa22215; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa21492; 28 Apr 97 9:37 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-long-external-obj-lang-00.txt
Date: Mon, 28 Apr 1997 09:37:29 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280937.aa21492 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : XODL: External Object Description Language
Author(s) : B. Long
Filename : draft-long-external-obj-lang-00.txt
Pages : 49
Date : 04/25/1997
This document describes a data structure (XODL: Object Description
Language) and an associated method which, together, provide a means of
representing situations or types of situations. It can thus be used to
represent objects, events, or systems of objects and events or types of
objects, events or systems. Objects represented can be computer data
objects ("stack", "word processor", "user interface", etc.) or "real"
objects such as computers, networks, users, and so on.
Internet-Drafts are 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-long-external-obj-lang-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-long-external-obj-lang-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-long-external-obj-lang-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425101745.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-long-external-obj-lang-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-long-external-obj-lang-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425101745.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22225; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa20976; 28 Apr 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: disman at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-disman-express-mib-00.txt
Date: Mon, 28 Apr 1997 09:33:41 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280933.aa20976 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Distributed Management
Working Group of the IETF.
Title : Expression MIB
Author(s) : B. Stewart
Filename : draft-ietf-disman-express-mib-00.txt
Pages : 20
Date : 04/25/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
expressions of MIB objects.
Internet-Drafts are 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-disman-express-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-express-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-disman-express-mib-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425103212.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-express-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-express-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425103212.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22226; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa21024; 28 Apr 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: disman at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-disman-mgt-target-mib-00.txt
Date: Mon, 28 Apr 1997 09:33:46 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280933.aa21024 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Distributed Management
Working Group of the IETF.
Title : Management Target MIB
Author(s) : B. Stewart
Filename : draft-ietf-disman-mgt-target-mib-00.txt
Pages : 26
Date : 04/25/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing a
list of network management destinations (targets) and the information
needed to get to them and to group them.
Internet-Drafts are 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-disman-mgt-target-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-mgt-target-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-disman-mgt-target-mib-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425103413.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-mgt-target-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-mgt-target-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425103413.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22228; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa21278; 28 Apr 97 9:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-wessels-icp-v2-appl-00.txt
Date: Mon, 28 Apr 1997 09:36:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280936.aa21278 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Application of Internet Cache Protocol (ICP), version 2
Author(s) : D. Wessels, K. Claffy
Filename : draft-wessels-icp-v2-appl-00.txt
Pages : 20
Date : 04/25/1997
This draft document describes the Application of the Internet Cache
Protocol (ICP) as currently implemented in several World-Wide Web
proxy cache packages. A companion document (RFCXXXX,
<draft-wessels-icp-v2-02.txt>) describes the ICP protocol itself.
ICP was initially developed by Peter Danzig, et. al. at the
University of Southern California as a central part of hierarchical
caching in the Harvest research project[3]. Several independent
caching implementations now use ICP, and although it is not yet
a formal standard we consider it important to codify the existing
practical uses of ICP for those trying to implement, deploy, and
extend its use for their own purposes. We specifically do not
include judgments about whether or how one should use ICP;
we merely document current practice.
Internet-Drafts are 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-wessels-icp-v2-appl-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-wessels-icp-v2-appl-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-wessels-icp-v2-appl-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425093541.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-wessels-icp-v2-appl-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-wessels-icp-v2-appl-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425093541.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22230; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa21396; 28 Apr 97 9:37 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-acap+ at andrew.cmu.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-acap-dewinter-dtype-00.txt
Date: Mon, 28 Apr 1997 09:37:12 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280937.aa21396 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Application Configuration
Access Protocol Working Group of the IETF.
Title : ACAP Datatyping and Datatyping Discovery
Author(s) : J. De Winter
Filename : draft-ietf-acap-dewinter-dtype-00.txt
Pages : 6
Date : 04/25/1997
The Application Configuration Access Protocol (ACAP) is designed to support
remote storage and access of program option, configuration and preference
information. In certain circumstances, it is desirable or necessary to
deal with information that has a limit imposed on it. While the general
ACAP specification does provide for a (SYNTAX) alert to inform the
submittor that the stored information was not in a valid syntax for that
field, there is no generic method to discover that syntax.
There is strong feeling in the ACAP working group that variable length
strings should be used for data where possible, but there is also the
knowledge that ACAP will be used to configure and access existing
systems where the use of such variable length strings may be difficult
or impossible.
Internet-Drafts are 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-acap-dewinter-dtype-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-acap-dewinter-dtype-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-acap-dewinter-dtype-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425150845.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-acap-dewinter-dtype-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-acap-dewinter-dtype-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425150845.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22213; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa21737; 28 Apr 97 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-dun-calsch-schema-00.txt
Date: Mon, 28 Apr 1997 09:38:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280938.aa21737 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Schema for Storing Calendaring Information in a
Directory Service
Author(s) : A. Dun, D. Hennessy
Filename : draft-dun-calsch-schema-00.txt
Pages : 6
Date : 04/25/1997
The Lightweight Directory Access Protocol [1][2] defines a standard
protocol for accessing diverse directory services. One common use of a
directory service is the location of application services, among which are
a user's calendar and a user's free busy time.
This document defines a set of object classes and attributes for storing
information including URLs to the user's calendar and free/busy time.
Internet-Drafts are 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-dun-calsch-schema-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dun-calsch-schema-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-dun-calsch-schema-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425114153.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dun-calsch-schema-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dun-calsch-schema-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425114153.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22224; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa21565; 28 Apr 97 9:37 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: rsvp at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rsvp-partial-service-00.txt
Date: Mon, 28 Apr 1997 09:37:48 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280937.aa21565 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : Partial Service Deployment in the Integrated Services
Architecture
Author(s) : L. Breslau, S. Shenker
Filename : draft-ietf-rsvp-partial-service-00.txt
Pages : 7
Date : 04/25/1997
Specifications for providing enhanced qualities of service in the Internet
have been defined in [2,4]. Technical and administrative concerns may
prevent a network element from offering one or more of these services. In
this document, we present a mechanism for dealing with heterogeneity in the
set of services offered by different network elements. This approach
enables end-to-end service to be composed of different per-hop services
while not requiring end systems to be aware of the details of the service
provided at each hop.
Internet-Drafts are 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-rsvp-partial-service-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-partial-service-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-partial-service-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425110737.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-partial-service-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-partial-service-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425110737.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22227; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa21067; 28 Apr 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: disman at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-disman-notify-mib-00.txt
Date: Mon, 28 Apr 1997 09:33:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280933.aa21067 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Distributed Management
Working Group of the IETF.
Title : Notification MIB
Author(s) : B. Stewart
Filename : draft-ietf-disman-notify-mib-00.txt
Pages : 27
Date : 04/25/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
SNMP notifications.
Internet-Drafts are 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-disman-notify-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-notify-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-disman-notify-mib-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425103642.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-notify-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-notify-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425103642.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22217; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa20961; 28 Apr 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: disman at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-disman-event-mib-00.txt
Date: Mon, 28 Apr 1997 09:33:38 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280933.aa20961 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Distributed Management
Working Group of the IETF.
Title : Event MIB
Author(s) : B. Stewart
Filename : draft-ietf-disman-event-mib-00.txt
Pages : 24
Date : 04/25/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
monitoring of MIB objects and taking action through events.
Internet-Drafts are 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-disman-event-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-event-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-disman-event-mib-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425103013.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-event-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-event-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425103013.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22229; 28 Apr 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa21802; 28 Apr 97 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-radius at livingston.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-radius-servmib-03.txt
Date: Mon, 28 Apr 1997 09:38:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280938.aa21802 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Remote Authentication
Dial-In User Service Working Group of the IETF.
Title : RADIUS Server MIB
Author(s) : G. Zorn, B. Aboba
Filename : draft-ietf-radius-servmib-03.txt
Pages : 10
Date : 04/25/1997
This memo defines a set of extensions which instrument RADIUS server
functions. These extensions represent a portion of the Management
Information Base (MIB) for use with network management protocols in the
Internet community. Using these extensions IP-based management stations
can manage RADIUS servers.
Internet-Drafts are 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-radius-servmib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-servmib-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-radius-servmib-03.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425114627.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-servmib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-servmib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425114627.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22432; 28 Apr 97 9:42 EDT
Received: from ietf.ietf.org by ietf.org id aa21635; 28 Apr 97 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: mboned at ns.uoregon.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mboned-admin-ip-space-02.txt
Date: Mon, 28 Apr 1997 09:37:58 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280938.aa21635 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MBONE Deployment Working
Group of the IETF.
Title : Administratively Scoped IP Multicast
Author(s) : D. Meyer
Filename : draft-ietf-mboned-admin-ip-space-02.txt
Pages : 7
Date : 04/25/1997
This document defines the "administratively scoped IPv4 multicast space" to
be the range 239.0.0.0 to 239.255.255.255 . In addition, it describes a
simple set of semantics for the implementation of Administratively Scoped
IP Multicast. Finally, it provides a mapping between the IPv6 multicast
address classes [RFC1884] and IPv4 multicast address classes.
This memo is a product of the MBONE Deployment Working Group (MBONED in the
Operational Requirements area of the Internet Engineering Task Force.
Submit comments to <mboned at ns.uoregon.edu> or the author.
Internet-Drafts are 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-mboned-admin-ip-space-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-admin-ip-space-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mboned-admin-ip-space-02.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425113239.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-admin-ip-space-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-admin-ip-space-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425113239.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24202; 28 Apr 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa23652; 28 Apr 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-adams-00.txt
Date: Mon, 28 Apr 1997 09:55:24 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280955.aa23652 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The CAST-128 Encryption Algorithm
Author(s) : C. Adams
Filename : draft-rfced-info-adams-00.txt
Pages : 15
Date : 04/25/1997
There is a need in the Internet community for an unencumbered encryption
algorithm with a range of key sizes that can provide security for a variety
of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to
satisfy this requirement. Included are a description of the
cipher and the key scheduling algorithm (Section 2),
the s-boxes (Appendix A), and a set of test vectors (Appendix B).
Internet-Drafts are 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-rfced-info-adams-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-adams-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-adams-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425132813.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-adams-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-adams-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425132813.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24207; 28 Apr 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa23868; 28 Apr 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-murakami-00.txt
Date: Mon, 28 Apr 1997 09:55:57 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280955.aa23868 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MAPOS Version 1 Assigned Numbers
Author(s) : M. Maruyama, K. Murakami
Filename : draft-rfced-info-murakami-00.txt
Pages : 3
Date : 04/25/1997
This document describes the protocol parameters used in the Multiple Access
Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and
provides multiple access capability over SONET/SDH links.
Internet-Drafts are 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-rfced-info-murakami-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-murakami-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-murakami-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425133656.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-murakami-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-murakami-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425133656.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24200; 28 Apr 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa23609; 28 Apr 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-kessler-00.txt
Date: Mon, 28 Apr 1997 09:55:20 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280955.aa23609 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Primer On Internet and TCP/IP Tools and Utilities
Author(s) : G. Kessler, S. Shepard
Filename : draft-rfced-info-kessler-00.txt
Pages : 53
Date : 04/25/1997
This memo is an introductory guide to many of the most commonly-available
TCP/IP and Internet tools and utilities. It also describes discussion lists
accessible from the Internet, ways to obtain Internet and TCP/IP documents,
and some resources that help users weave their way through the Internet.
Internet-Drafts are 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-rfced-info-kessler-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-kessler-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-kessler-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425132521.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-kessler-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-kessler-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425132521.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24229; 28 Apr 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa23928; 28 Apr 97 9:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-ken-00.txt
Date: Mon, 28 Apr 1997 09:56:05 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280956.aa23928 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A MAPOS version 1 Extension - Node Switch Protocol
Author(s) : K. Murakami, M. Maruyama
Filename : draft-rfced-info-ken-00.txt
Pages : 6
Date : 04/25/1997
This document describes a MAPOS extension, Node Switch Protocol, for
automatic node address assignment. MAPOS is a multiple access protocol for
transmission of network-protocol datagrams, encapsulated in High-Level Data
Link Control (HDLC) frames, over SONET/SDH. NSP automates the HDLC address
configuration of each node. Using NSP, a node retrieves its its HDLC
address from the switch to which it is connected.
Internet-Drafts are 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-rfced-info-ken-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-ken-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-ken-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425133930.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-ken-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-ken-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425133930.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24311; 28 Apr 97 9:57 EDT
Received: from ietf.ietf.org by ietf.org id aa24017; 28 Apr 97 9:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-mitsuru-00.txt
Date: Mon, 28 Apr 1997 09:56:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280956.aa24017 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A MAPOS version 1 Extension - Switch-Switch Protocol
Author(s) : K. Murakami, M. Maruyama
Filename : draft-rfced-info-mitsuru-00.txt
Pages : 21
Date : 04/25/1997
This document describes a MAPOS version 1 extension, SSP (Switch Switch
Protocol). MAPOS is a multiple access protocol for transmission of
network-protocol packets, encapsulated in High-Level Data Link Control
(HDLC) frames, over SONET/SDH. In MAPOS network, A SONET switch provides
the multiple access capability to end nodes. SSP is a protocol of Distance
Vector family and provides unicast and broadcast/multicast routing for
multiple SONET switch environment.
Internet-Drafts are 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-rfced-info-mitsuru-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-mitsuru-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-mitsuru-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425134202.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-mitsuru-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-mitsuru-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425134202.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24342; 28 Apr 97 9:57 EDT
Received: from ietf.ietf.org by ietf.org id aa23799; 28 Apr 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-maruyama-01.txt
Date: Mon, 28 Apr 1997 09:55:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280955.aa23799 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IP over MAPOS Version 1
Author(s) : K. Murakami, M. Maruyama
Filename : draft-rfced-info-maruyama-01.txt
Pages : 6
Date : 04/25/1997
This document describes a protocol for transmission of the Internet
Protocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS)
version 1. MAPOS is a link layer protocol and provides multiple access
capability over SONET/SDH links. IP runs on top of MAPOS. This document
explains IP datagram encapsulation in HDLC frame of MAPOS, and the Address
Resolution Protocol (ARP).
Internet-Drafts are 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-rfced-info-maruyama-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-maruyama-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-maruyama-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425133358.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-maruyama-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-maruyama-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425133358.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab24342; 28 Apr 97 9:57 EDT
Received: from ietf.ietf.org by ietf.org id aa24146; 28 Apr 97 9:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-bryant-01.txt
Date: Mon, 28 Apr 1997 09:56:31 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280956.aa24146 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : APPN Implementer's Workshop Closed Pages Document
DLSw v2.0 Enhancements
Author(s) : D. Bryant, P. Brittain
Filename : draft-rfced-info-bryant-01.txt
Pages : 32
Date : 04/25/1997
This document specifies
- a set of extensions to RFC 1795 designed to improve the
scalability of DLSw
- clarifications to RFC 1795 in the light of the
implementation experience to-date.
It is assumed that the reader is familiar with DLSw and RFC 1795.
No effort has been made to explain these existing protocols or
associated terminology.
This document was developed in the DLSw Related Interest Group (RIG) of the
APPN Implementers Workshop (AIW). If you would like to participate in
future DLSw discussions, please subscribe to the DLSw RIG mailing lists by
sending a mail to majordomo at raleigh.ibm.com specifying 'subscribe aiw-dlsw'
as the body of the message.
Internet-Drafts are 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-rfced-info-bryant-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-bryant-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-bryant-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425111629.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-bryant-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-bryant-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425111629.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24204; 28 Apr 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa23749; 28 Apr 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-maruyama-mapos-sonet-01.txt
Date: Mon, 28 Apr 1997 09:55:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704280955.aa23749 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MAPOS - Multiple Access Protocol
over SONET/SDH Version 1
Author(s) : K. Murakami, M. Maruyama
Filename : draft-maruyama-mapos-sonet-01.txt
Pages : 8
Date : 04/25/1997
This document describes the protocol MAPOS, Multiple Access Protocol over
SONET/SDH, for transmitting network-protocol datagrams over SONET/SDH. It
focuses on the core protocol -- other documents listed in the bibliography
may be referenced in conjunction with this document to provide support and
services for protocols at higher layers.
Internet-Drafts are 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-maruyama-mapos-sonet-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-maruyama-mapos-sonet-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-maruyama-mapos-sonet-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425133109.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-maruyama-mapos-sonet-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-maruyama-mapos-sonet-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425133109.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25882; 28 Apr 97 10:09 EDT
Received: from ietf.ietf.org by ietf.org id aa25733; 28 Apr 97 10:08 EDT
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IPv6 Router Alert Option to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 28 Apr 1997 10:08:01 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704281008.aa25733 at ietf.org>
The IESG has received a request from the IPNG Working Group to consider
"IPv6 Router Alert Option" <draft-ietf-ipngwg-ipv6router-alert-01.txt> for
the status of Proposed Standard.
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
iesg at ietf.org or ietf at ietf.org mailing lists by May 12, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa00478; 28 Apr 97 10:59 EDT
Received: from ietf.ietf.org by ietf.org id aa29908; 28 Apr 97 10:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-esp-rc5-cbc-00.txt
Date: Mon, 28 Apr 1997 10:52:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704281052.aa29908 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : The ESP RC5-CBC Algorithm
Author(s) : R. Pereira, R. Baldwin
Filename : draft-ietf-ipsec-esp-rc5-cbc-00.txt
Pages : 5
Date : 04/25/1997
This draft describes the RC5 block cipher algorithm as to be used with the
IPSec Encapsulating Security Payload (ESP).
Internet-Drafts are 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-ipsec-esp-rc5-cbc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425145805.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-esp-rc5-cbc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425145805.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07204; 28 Apr 97 12:14 EDT
Received: from ZAFU.BBN.COM by ietf.org id aa06927; 28 Apr 97 12:10 EDT
Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id MAA17318; Mon, 28 Apr 1997 12:06:35 -0400 (EDT)
X-Sender: kent at po1.bbn.com
Message-Id: <v0300780faf8a752bdf23 at [128.89.0.110]>
In-Reply-To: <199704252221.AA03139 at jotun.EU.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 28 Apr 1997 12:02:40 -0400
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Sender:ietf-request at ietf.org
From: Stephen Kent <kent at bbn.com>
Subject: Re: Autonomous System Sanity Protocol
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Noel,
I'm not sure that a change to distribution of maps (ala' Nimrod) vs.
routing tables (ala' BGP/IDRP) is necessary. There is work underway to
provide inter-router authentication and integrity, and some work we are
implementing now for DARPA include a simple, efficient key management
mechanism to fill in the gap in that area. However, even with that in
place, we lack an authorization mechanism for EGPs, and fixing that will
provide a means to avert the sort of problems just publicized.
Address allocation is a strict, top-down procedure, rooted at the IANA.
Delegation of portions of the address space to ISPs, DSPs, subscriber
organizations, etc. is all hierarchic. It fits well with the notion of a
certification scheme, one that authorizes certificate holders as
(temporary) "owners" of addresses or portions of the address space. This
need not result in new registeries, per se; each player can sign
certificates representing the portions of the address space that it
delegates, and the results can be passed around in messages.
Alternatively, the DNS can be used to hold this info, either using the
signed record structures defined in the DNS Security WG, or just storing
certificates. (We're doing the latter in some mobile IP security work for
DARPA and the code to store and retrieve X.509 v3 certificates in the DNS
will be made available this summer.)
One can imagine subsequent signing of data to represent authorization of a
router or an AS to represent a poriton of the address space, and cascaded
authorizations in BGP updates or in a separate protocol. Ease of
deployment is important, so a transitio strategy is a big issue here. A
team of folks at BBN has justed staretd work on the solution approach
alluded to above, under DoD sponsorship, and the output will be both design
documentation and sample code (for routed or gated). So, there is some
work underway to address this problem, with an eye towards technology
transfer of the results to the community.
Steve
Received: from ietf.org by ietf.org id aa12753; 28 Apr 97 13:10 EDT
Received: from ginger.lcs.mit.edu by ietf.org id aa12611; 28 Apr 97 13:07 EDT
Received: by ginger.lcs.mit.edu
id AA00440; Mon, 28 Apr 97 13:04:21 -0400
Date: Mon, 28 Apr 97 13:04:21 -0400
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9704281704.AA00440 at ginger.lcs.mit.edu>
To: jnc at ginger.lcs.mit.edu, kent at bbn.com
Subject: Re: Autonomous System Sanity Protocol
Cc: ietf at ietf.org, jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: Stephen Kent <kent at bbn.com>
I'm not sure that a change to distribution of maps .. vs. routing tables
.. is necessary. ... One can imagine subsequent signing of data to
represent authorization of a router or an AS to represent a poriton of
the address space
Ah. You've not seen the recent messages to Big-Internet, about how MD systems
are probably a lot more workable at this than DV systems. Here's an excerpt:
> In an MD system, you should only get updates from R1 when the
> topology next to R1 changes (i.e. it's [connection to some other
> router, or a piece of the nework, changes), and each topology change is
> [this] *guaranteed* to send you only a small amount of data .. I.e. you
> don't get all of whatever routing table entries have changed - which
> could be a lot of data items, each one of which would have to be
> checked, [as you would] in a DV system ..
> You then use that, together with pre-checked data already in your map
> (note this, you checked the correctness of that data in the past, when
> you first got it, and don't have to do so again now), to do the
> recomputation of all the routing table entries locally.
> This is clearly much more tractable than applying PKS to a DV system,
> where you'd have to check each routing table entry as it came in, which
> could be rather painful after a topology change which caused lots of
> routes to change.
Routing table flaps are bad enough now - can you imagine what they'd look
like if you have to check the signatures on *each* route as they came in?
Remember also that real-time delay in processing the updates through is going
to increase the stabilization time of the routing network-wide, and that's not
good. Any increase in stabilization time is of great concern to routing
algorithm people - and especially an increase in the stabilization time for a
network that's so large, and growing rapidly. What's specially of concern is
that that increase is going to be serialized, i.e. routers R1...Rn can't do
that signature checking in parallel, but by the very nature of DV it has to be
done serially.
(Also, to be effective, you'd probably have to sign each step in the path
vector, otherwise bad guy Z can take path X->Y->Z, strip off the last
elements, and send out X->Z; this obviously makes even more work.)
A team of folks at BBN has justed staretd work on the solution approach
alluded to above, under DoD sponsorship, and the output will be both
design documentation and sample code (for routed or gated).
Ah. I hope that they look at the signature problem in both the MD and
DV systems, to enable maximum utilization of their work.
Noel
Received: from cnri by ietf.org id aa17179; 28 Apr 97 14:06 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15463;
28 Apr 97 14:06 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA09177 at pad-thai.cam.ov.com>; Mon, 28 Apr 1997 15:49:48 GMT
From: Jacques Lebastard <J.Lebastard at frcl.bull.fr>
Message-Id: <9704281547.AA17537 at ronde.frcl.bull.fr>
Subject: GSS-API context transfer and delegation
To: IETF CAT Group <cat-ietf at mit.edu>
Date: Mon, 28 Apr 1997 17:47:18 +0200 (EET)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Precedence: bulk
CAT fanciers,
On April 9, I wrote:
> I am wondering what kind of operations should be permitted to a process
> which import a security context using a call to gss_import_sec_context ?
> In particular, for GSS-API mechanisms which supports delegation, should
> that process be able to use attributes/credentials imported with the
> context in order to establish a new context and act as a delegate ?
Theodore Tso replied:
> Yes.
and John Wray replied:
> No. There is no GSSAPI call to extract a delegated credential from a context,
> imported or otherwise. To get a delegated credential, you have to call
> accept_sec_context().
I think both Ted and John are right : "yes" it _should_ be possible to
use an imported context to initiate another context as a delegate but
"no" this is not permitted by RFC2078 as it _currently_ stands.
gss_import_sec_context is actually missing an output delegated_credential
handle to allow delegation from an imported context.
John Wray also wrote:
> This functionality (extracting a delegated credential from a security context)
> has been proposed, but we postponed it to the next major revision of GSSAPI.
I reckon acting as a delegate from an imported context would be possible
for mechanisms which implements both GSS-API Version 2 and XGSS-API :
draft-ietf-cat-xgssapi-acc-cntrl-02.txt specifies the ability to extract
the delegated credentials from an established context at the acceptor's side
using GSS_Get_received_creds ; it may also control further use of these
credentials using GSS_Get_cred_controls/GSS_Set_cred_controls.
XGSS-API draft currently reads :
> 6.2.1. GSS_Get_received_creds
> To extract credential handles from a GSS-API context (established
> with GSS_Accept_sec_context function). This is only applicable for
> some forms of delegation supporting multiple incoming credentials,
> and can only be invoked by a context acceptor. A call to
> GSS_Get_received_creds is an intermediary step for an acceptor,
> before extracting the security attributes of each set of credentials
> with a call to GSS_Get_sec_attributes. The credential handles are
> ordered. They start with the credentials of the first initiator and
> finish with the the credentials of the immediate invoker.
John Wray also wrote:
> If/when it is introduced, I think we'll also have to provide a way for the
> exporter to control whether or not any delegated credential is exported along
> with the context.
This seems a bit redundant with X-GSSAPI : GSS_Set_cred_controls and
GSS_Set_cred_attributes already allow context initiators to control/restrict
credentials used while establishing contexts all along the delegation chain.
Why should an imported context give access to a different set of credentials ?
GSS-API V2 + XGSS-API would allow to secure very nice situations
where, for instance, all clients send requests to a single dispatcher
which is in charge of verifying clients' access (authentication + authori-
zation) and which transfers the established context to the proper request
handler ; that handler would then be able to use the initiator's credentials
to establish another security context with a 3rd party while processing the
initiator's request :
clients dispatcher request handlers 3rd party entities
+---+ +---+ +---+
! ! ------------ \ /---------- ! ! --------------- ! !
+---+ \ / +---+ +---+
\ /
+---+ \ +---+ / +---+ +---+
! ! ----------------- ! ! -------------- ! ! --------------- ! !
+---+ / +---+ \ +---+ +---+
/ \
+---+ / \ +---+ +---+
! ! ------------ / \---------- ! ! --------------- ! !
+---+ +---+ +---+
< establishment > < transfer > < delegation >
Set_cred_controls
Set_cred_attributes
Init_context
Accept_context
Get_sec_attributes
Export_context
Import_context
Get_received_creds
Get_sec_controls
Set_cred_controls
Init_context
Accept_context
Best regards,
--
Jacques LEBASTARD mailto:J.Lebastard at frcl.bull.fr
BULL SA - ISM AccessMaster http://www-ism.bull.com/ism/
Rue Jean Jaures - A5/146 Tel: +33 (0)1 30 80 77 86
F-78340 Les Clayes sous Bois Fax: +33 (0)1 30 80 77 99
Received: from ietf.org by ietf.org id aa20535; 28 Apr 97 14:41 EDT
Received: from ns.research.att.com by ietf.org id aa20424; 28 Apr 97 14:39 EDT
Received: from research.att.com ([135.205.32.20]) by ns; Mon Apr 28 14:35:09 EDT 1997
Received: from raptor.research.att.com ([135.205.49.32]) by research; Mon Apr 28 14:34:22 EDT 1997
Received: from research.att.com (raptor.research.att.com [135.205.49.32])
by raptor.research.att.com (8.8.5/8.8.5) with ESMTP id OAA28434;
Mon, 28 Apr 1997 14:34:21 -0400 (EDT)
Message-Id: <199704281834.OAA28434 at raptor.research.att.com>
To: Stephen Kent <kent at bbn.com>
cc: Noel Chiappa <jnc at ginger.lcs.mit.edu>, ietf at ietf.org
Subject: Re: Autonomous System Sanity Protocol
Date: Mon, 28 Apr 1997 14:34:21 -0400
Sender:ietf-request at ietf.org
From: Steven Bellovin <smb at research.att.com>
Source-Info: From (or Sender) name not authenticated.
Alternatively, the DNS can be used to hold this info, either
using the signed record structures defined in the DNS Security
WG, or just storing certificates. (We're doing the latter in
some mobile IP security work for DARPA and the code to store
and retrieve X.509 v3 certificates in the DNS
will be made available this summer.)
I think that this fails the ``turn it all off'' test. That is, suppose
we turned off the entire Internet -- every host, router, etc., for a day
or two. Could we turn it back on? If I need DNS connectivity to verify
routes, but I can't get to the DNS until my routing information has
been accepted -- well, I think you see the problem...
Received: from cnri by ietf.org id aa23774; 28 Apr 97 15:33 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17463;
28 Apr 97 15:33 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA15881 at pad-thai.cam.ov.com>; Mon, 28 Apr 1997 18:23:15 GMT
Date: Mon, 28 Apr 1997 20:22:53 +0200
Message-Id: <199704281822.UAA14071 at p18509.wdf.sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
To: cat-ietf at mit.edu
Cc: Martin.Rex at sap-ag.de
Subject: acquire_cred() and initiating credentials
Precedence: bulk
I mentioned this before (23-Aug-1996): I don't like the following
paragraph in the descriptions of gss_acquire_cred() in the current
C-Bindings draft, and I strongly object the last sentence:
This routine is expected to be used primarily by context acceptors,
since implementations are likely to provide mechanism-specific ways of
obtaining GSS-API initiator credentials from the system login process.
Some implementations may therefore not support the acquisition of
GSS_C_INITIATE or GSS_C_BOTH credentials via gss_acquire_cred for any
name other than an empty name.
Any gssapi implementation should be required to support at least that
subset of the functionality that is provided by gss_init_sec_context()
and gss_accept_sec_conttext() when using GSS_C_NO_CREDENTIAL.
Anything less will be a pain in the butt for portable applications.
i.e. Any gssapi implementation must be able to create a credential
handle for the default initiator when gss_init_sec_context() would
be able use such credentials internally. Similarly, acquiring
initiating credentials for an explicit name must always work
for the identity/principal that would be authenticated to the
context acceptor if the client used gss_init_sec_context() with
the default credentials or an explicit reference of the default
credentials.
Currently, the high level spec "doesn't encourage application writers
to make heavy use of acquire_cred() -- which is fine. But to me the
current C-Bindings sounds like it would be ok for a gssapi mechanism
to only half-implement this call ...
I have implemented security context refresh in my application, because
(a) security context expiration is allowed to gssapi implementations and
(b) it happens to be implemented&enforced by the Kerberos gssapi mechanism.
In my implementation, the security context refresh is completely
hidden from the application layer; internally it is done as the
establishment of a new security context for the same initiator and
acceptor as the previous security context which is close to or
already expired. For the newly established security context,
it must be verified at some level that it still refers to the same
initiator as the previous context (some sort of re-authentication),
and that the features/attributes of the security context (rec_flags)
still meet the policy.
In order to make this operation relatively foolproof at the initiator
side, I do always acquire the DEFAULT initiating credentials prior
to the first context establishment, inquire these credentials and
memorize the returned name. For all future attempts to
refresh/replace the security context with a new version, I
try to acquire the credentials for this explicit memorized name.
Acquiring explicitly named credentials serves several purposes:
I can check on the initiator side if the necessary/correct credentials
are both: available and not expired; and I know reliably that any
re-authentication of a user with a different identity must be an
active attack and can be logged as such on the server.
-Martin
Received: from ietf.org by ietf.org id aa25191; 28 Apr 97 16:03 EDT
Received: from callandor.cybercash.com by ietf.org id aa25017;
28 Apr 97 15:58 EDT
Received: by callandor.cybercash.com; id PAA10957; Mon, 28 Apr 1997 15:45:48 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma010883; Mon, 28 Apr 97 15:45:18 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA09346; Mon, 28 Apr 97 15:50:29 EDT
Date: Mon, 28 Apr 1997 15:50:29 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Steven Bellovin <smb at research.att.com>
Cc: ietf at ietf.org
Subject: Re: Autonomous System Sanity Protocol
In-Reply-To: <199704281834.OAA28434 at raptor.research.att.com>
Message-Id: <Pine.SUN.3.91.970428153919.8334C-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
You have a spectrum of choices. At one end, you can staticly configure loads
and loads of security keys into every node and then things can pretty much
cold boot securely. At the other extreme, you could (looking only at IPv4)
just configre each node with its private key and the public key and address
of in-addr.arpa or whatever and route insecurely until you get verifiable
secure routing info at which time you can start rejecting any conflicting
bogus routing info. Assuming your communications are also secured, the worst
you can get with the second case is denial of service.
The circularity has little to do with DNS. Any means of storing any of the
security info non locally (PGP key servers, whatever) requires that you route
insecurely for a while until you can retrieve the information you need to
route securely. As I say, the alternative is lots of local configuration (or
at least long lived caching), which you can do with DNS data is you want.
Donald
On Mon, 28 Apr 1997, Steven Bellovin wrote:
> Date: Mon, 28 Apr 1997 14:34:21 -0400
> From: Steven Bellovin <smb at research.att.com>
> To: Stephen Kent <kent at bbn.com>
> Cc: Noel Chiappa <jnc at ginger.lcs.mit.edu>, ietf at ietf.org
> Subject: Re: Autonomous System Sanity Protocol
>
> Alternatively, the DNS can be used to hold this info, either
> using the signed record structures defined in the DNS Security
> WG, or just storing certificates. (We're doing the latter in
> some mobile IP security work for DARPA and the code to store
> and retrieve X.509 v3 certificates in the DNS
> will be made available this summer.)
>
> I think that this fails the ``turn it all off'' test. That is, suppose
> we turned off the entire Internet -- every host, router, etc., for a day
> or two. Could we turn it back on? If I need DNS connectivity to verify
> routes, but I can't get to the DNS until my routing information has
> been accepted -- well, I think you see the problem...
>
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa25624; 28 Apr 97 16:10 EDT
Received: from ns.research.att.com by ietf.org id aa25486; 28 Apr 97 16:09 EDT
Received: from research.att.com ([135.205.32.20]) by ns; Mon Apr 28 16:05:06 EDT 1997
Received: from raptor.research.att.com ([135.205.49.32]) by research; Mon Apr 28 16:03:01 EDT 1997
Received: from research.att.com (raptor.research.att.com [135.205.49.32])
by raptor.research.att.com (8.8.5/8.8.5) with ESMTP id QAA07893;
Mon, 28 Apr 1997 16:03:00 -0400 (EDT)
Message-Id: <199704282003.QAA07893 at raptor.research.att.com>
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
cc: ietf at ietf.org
Subject: Re: Autonomous System Sanity Protocol
Date: Mon, 28 Apr 1997 16:03:00 -0400
Sender:ietf-request at ietf.org
From: Steven Bellovin <smb at research.att.com>
Source-Info: From (or Sender) name not authenticated.
You have a spectrum of choices. At one end, you can staticly
configure loads and loads of security keys into every node and
then things can pretty much cold boot securely. At the other
extreme, you could (looking only at IPv4) just configre each
node with its private key and the public key and address of
in-addr.arpa or whatever and route insecurely until you get
verifiable secure routing info at which time you can start
rejecting any conflicting bogus routing info. Assuming your
communications are also secured, the worst you can get with the
second case is denial of service.
The circularity has little to do with DNS. Any means of
storing any of the security info non locally (PGP key servers,
whatever) requires that you route insecurely for a while until
you can retrieve the information you need to route securely.
As I say, the alternative is lots of local configuration (or at
least long lived caching), which you can do with DNS data is
you want.
Well, the other choice -- and the one I'd lean towards -- would be
inclusion of the address certificate with the routing information.
For BGP especially, where TCP connections are used, this shouldn't
be a problem.
Received: from ietf.org by ietf.org id aa29846; 28 Apr 97 17:50 EDT
Received: from ietf.ietf.org by ietf.org id aa29707; 28 Apr 97 17:45 EDT
To: IETF-Announce: ;
cc: rem-conf at es.net
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: RTP Payload Format for H.263 Video Streams to Proposed
Standard
Reply-to: iesg at ietf.org
Date: Mon, 28 Apr 1997 17:45:40 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704281745.aa29707 at ietf.org>
The IESG has received a request from the Audio/Video Transport Working
Group to consider the following Internet-Drafts "for the status of Proposed
Standard.
1. RTP Payload Format for H.263 Video Streams
<draft-ietf-avt-rtp-payload-03.txt>
2. RTP Payload for Redundant Audio Data
<draft-perkins-rtp-redundancy-03.txt>
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
iesg at ietf.org or ietf at ietf.org mailing lists by May 12, 1997
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa00202; 28 Apr 97 18:01 EDT
Received: from ietf.ietf.org by ietf.org id aa00065; 28 Apr 97 17:58 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: The "data" URL scheme to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 28 Apr 1997 17:58:29 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704281758.aa00065 at ietf.org>
The IESG has received a request to consider "The "data" URL scheme
<draft-masinter-url-data-03.txt> as a Proposed Standard. This has
been reviewed in the IETF but is not the product of an IETF Working
Group.
The IESG will also consinder Returning Values from Forms:
multipart/form-data <draft-masinter-form-data-00.txt> as a Proposed
Standard.
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
iesg at ietf.org or ietf at ietf.org mailing lists by May 28, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa00306; 28 Apr 97 18:02 EDT
Received: from ietf.org by ietf.org id aa00274; 28 Apr 97 18:02 EDT
Received: from ietf.ietf.org by ietf.org id aa00260; 28 Apr 97 18:02 EDT
To: IETF-Announce: ;
Subject: Last Call: The Use of RSVP with Integrated Services to Proposed
Standard
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Date: Mon, 28 Apr 1997 18:02:19 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704281802.aa00260 at ietf.org>
NOTE: The Last Call for theser documents was sent on April 3, 1997. One
of the intended status levels was incorrectly listed. Specifically,
o General Characterization Parameters for Integrated
Service Network Elements
<draft-ietf-intserv-charac-02.txt>
is a candidate for PROPOSED Standard.
The IESG has received a request from the Integrated Services Working
Group and the Resource Reservation Setup Protocol Working Group to
consider publication of the following Internet-Drafts as Proposed
Standards:
o Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification
<draft-ietf-rsvp-spec-14.txt>
o RSVP Cryptographic Authentication
<draft-ietf-rsvp-md5-02.txt>
o RSVP Management Information Base
<draft-ietf-rsvp-mib-05.txt>
o RSVP Extensions for IPSEC Data Flows
<draft-berger-rsvp-ext-07.txt>
o The Use of RSVP with IETF Integrated Services
<draft-ietf-intserv-rsvp-use-01.txt>
o Specification of the Controlled-Load Network Element Service
<draft-ietf-intserv-ctrl-load-svc-04.txt>
o Specification of Guaranteed Quality of Service
<draft-ietf-intserv-guaranteed-svc-07.txt>
o Integrated Services Management Information Base
<draft-ietf-intserv-mib-05.txt>
o Integrated Services Management Information Base
Guaranteed Service Extensions
<draft-ietf-intserv-guaranteed-mib-03.txt>
o General Characterization Parameters for Integrated
Service Network Elements
<draft-ietf-intserv-charac-02.txt>
The IESG will also consider publication of the following
Internet-Drafts as Informational RFCs:
o Resource ReSerVation Protocol (RSVP) -- Version 1
Applicability Statement
<draft-ietf-rsvp-intsrv-analysis-00.txt>
o Resource ReSerVation Protocol (RSVP) --
Version 1 Message Processing Rules
<draft-ietf-rsvp-procrules-00.txt >
o Network Element Service Specification Template
<draft-ietf-intserv-svc-template-03.txt>
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
iesg at ietf.org or ietf at ietf.org mailing lists by April 25, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa00543; 28 Apr 97 18:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00464; 28 Apr 97 18:03 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: The Kitchen Sink Resource Record to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 28 Apr 1997 18:03:51 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704281803.aa00464 at ietf.org>
The IESG has received a request to consider The Kitchen Sink Resource
Record <draft-eastlake-kitchen-sink-02.txt> as a Proposed Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
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
iesg at ietf.org or ietf at ietf.org mailing lists by May 28, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa01989; 28 Apr 97 18:31 EDT
Received: from ZAFU.BBN.COM by ietf.org id aa01897; 28 Apr 97 18:30 EDT
Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id SAA04036; Mon, 28 Apr 1997 18:27:28 -0400 (EDT)
X-Sender: kent at po1.bbn.com
Message-Id: <v03007828af8ad209b26d at [128.89.0.110]>
In-Reply-To: <199704282003.QAA07893 at raptor.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 28 Apr 1997 18:25:06 -0400
To: Steven Bellovin <smb at research.att.com>
Sender:ietf-request at ietf.org
From: Stephen Kent <kent at bbn.com>
Subject: Re: Autonomous System Sanity Protocol
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Steve,
I was pointing out the range of possibilities, but you and Don are
right, i.e., passing certs along with signed data structures makes the
system less dependent on any repository. Since routing must work for
access to respositories, it is important to avoid what could easily become
a circular dependency! Also, it seems that one could pass the necessary
certs and many of the analogous, long-lived at the time BGP connections are
established, so that routing updates need not be burdned with the overhead
of this stuff. We're just beginning to do the work, so we have not yet
addressed all of the details.
Steve
Received: from ietf.org by ietf.org id aa02349; 28 Apr 97 18:39 EDT
Received: from ZAFU.BBN.COM by ietf.org id aa02286; 28 Apr 97 18:38 EDT
Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id SAA04548; Mon, 28 Apr 1997 18:35:21 -0400 (EDT)
X-Sender: kent at po1.bbn.com
Message-Id: <v03007829af8ad56f7ee5 at [128.89.0.110]>
In-Reply-To: <9704281704.AA00440 at ginger.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 28 Apr 1997 18:33:52 -0400
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Sender:ietf-request at ietf.org
From: Stephen Kent <kent at bbn.com>
Subject: Re: Autonomous System Sanity Protocol
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Noel,
You're right, I'm not on the Big Internet list, so I had not seen
the messages there. I agree with the analysis you cite; it would make life
easier and faster than the sort of things we are looking at in the BGP
context. However, my clients also have an understandable concern about
deployment and the existing BGP base, so it's not unreasonable to look at
how to make life safer in the current context. We may be able to adopt a
hybrid approach: use of route servers in ASs allows for offloading
computation in a fashion analogous to the MD approach you described,
although it's not as elegant or as completely effective as in a pure MD
system.
Thanks for the info; we'll keep in touch and try to track the Big-I list
discussions.
Steve
Received: from ietf.org by ietf.org id aa04614; 28 Apr 97 20:00 EDT
Received: from mailhost.infi.net by ietf.org id aa04529; 28 Apr 97 19:58 EDT
Received: from default (pa5dsp16.nr.infi.net [208.128.85.136])
by mh004.infi.net (Infinet-S-8.8.5) with SMTP id TAA23638
for <ietf at ietf.org>; Mon, 28 Apr 1997 19:56:45 -0400 (EDT)
Message-ID: <33653944.9E4 at nr.infi.net>
Date: Mon, 28 Apr 1997 19:56:52 -0400
Sender:ietf-request at ietf.org
From: rena mcleod <rmcleod at nr.infi.net>
Reply-To: rmcleod at nr.infi.net
Organization: InfiNet
X-Mailer: Mozilla 3.0C-SurferKit (Win95; U)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from cnri by ietf.org id aa16833; 29 Apr 97 2:42 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa03777; 29 Apr 97 2:42 EDT
Received: from ietf.org by ietf.org id aa16824; 29 Apr 97 2:42 EDT
Received: from roam.psg.com by ietf.org id aa16811; 29 Apr 97 2:42 EDT
Received: by roam.psg.com
id m0wM4JA-000IV6C; Mon, 28 Apr 97 21:14 PDT (Smail3.1.29.1#2)
Message-Id: <m0wM4JA-000IV6C at roam.psg.com>
Date: Mon, 28 Apr 97 21:14 PDT
Sender:iesg-request at ietf.org
From: Randy Bush <randy at psg.com>
To: iesg at ietf.org
Cc: ietf <ietf at ietf.org>
Subject: Re: Last Call: The Kitchen Sink Resource Record to Proposed Standard
References: <9704281803.aa00464 at ietf.org>
> The IESG has received a request to consider The Kitchen Sink Resource
> Record <draft-eastlake-kitchen-sink-02.txt> as a Proposed Standard.
> This has been reviewed in the IETF but is not the product of an IETF
> Working Group.
Actually, dnsind has agreed to give it a home.
randy
Received: from ietf.org by ietf.org id aa21708; 29 Apr 97 8:23 EDT
Received: from ietf.ietf.org by ietf.org id aa21605; 29 Apr 97 8:20 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: MIME Parameter Value and Encoded Word Extensions:
Character Sets, Languages, and Continuations to Proposed Standard
Reply-to: iesg at ietf.org
Date: Tue, 29 Apr 1997 08:20:47 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704290820.aa21605 at ietf.org>
The IESG has received a request to consider MIME Parameter Value and
Encoded Word Extensions: Character Sets, Languages, and Continuations
<draft-freed-pvcsc-02.txt> as a Proposed Standard. This has been
reviewed in the IETF but is not the product of an IETF Working Group.
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
iesg at ietf.org or ietf at ietf.org mailing lists by May 29, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa24245; 29 Apr 97 10:00 EDT
Received: from cnri by ietf.org id aa23695; 29 Apr 97 9:53 EDT
Received: from leporello.cs.unibo.it by CNRI.Reston.VA.US id aa10120;
29 Apr 97 9:49 EDT
Received: from ciociosan.cs.unibo.it by leporello.cs.unibo.it (5.67b/96.09.13)
id AA19453; Tue, 29 Apr 1997 15:44:09 +0200
Sender:ietf-request at ietf.org
From: Nadia Busi <busi at cs.unibo.it>
Received: by ciociosan.cs.unibo.it (5.67b/CS-14.10.96)
id AA16428; Tue, 29 Apr 1997 15:44:06 +0200
Date: Tue, 29 Apr 1997 15:44:06 +0200
Message-Id: <199704291344.AA16428 at ciociosan.cs.unibo.it>
To: IETF at CNRI.Reston.VA.US
Subject: ICALP'97 - preliminary programme
Source-Info: From (or Sender) name not authenticated.
*******************************************************
* *
* ICALP '97 *
* ========= *
* 24th International Colloquium on Automata, *
* Languages, and Programming *
* *
* Silver Jubilee of EATCS *
* *
* Bologna, Italy, July 7th - 11th, 1997 *
* *
*******************************************************
PRELIMINARY PROGRAMME
*******************************************************
This announcement and more information about the conference is available
per www under
http://www.cs.unibo.it/icalp97/
or by sending e-mail to icalp97 at cs.unibo.it
Please address inquiries, registration form and hotel reservation form
to the Conference Office:
Italiana & Co. - ICALP'97
Via Altabella 3
I-40126 BOLOGNA (Italy)
Phone: + 39 51 228716
Fax: + 39 51 222881
Email: italiana at bo.nettuno.it
-------------------------------------------------------------------------------
GENERAL INFORMATION
^^^^^^^^^^^^^^^^^^^
The 24th annual meeting of the European Association for Theoretical Computer
Science (EATCS) will take place in Bologna, Italy, July 7-11 1997.
ICALP '97 comes in conjunction with the 25th anniversary of the foundation
of EATCS. To celebrate the SILVER JUBILEE, this edition of ICALP includes
several new events:
- Celebration of EATCS and of its founders (keynote speaker M. Nivat - Paris)
- Invited Lectures on major advances in theoretical computer science since
EATCS has been established:
R. Milner (Cambridge) M.O. Rabin (Jerusalem and Harvard)
C. Papadimitriou (Berkeley) D.S. Scott (Pittsburgh)
- Invited Lectures on the state of the art and new promising trends:
K.R. Apt (Amsterdam) K. Mehlhorn (Saarbruecken)
R.J. Lipton (Princeton) D. Perrin (Marne-la-Vallee)
- A panel on 'Funding Policies for Theoretical Computer Science' with
representatives from major research agencies and from the European Community.
- A number of Satellite Workshops, listed below, on theory and applications.
ICALP SATELLITE WORKSHOPS
^^^^^^^^^^^^^^^^^^^^^^^^^
- Workshop on New Trends in Semantics - Bologna (4-5 July) Organizers:
A.Asperti (Bologna), E.Moggi (Genova) and G.Rosolini (Genova).
Invited Speakers: S.Abramski (Edinburgh), V.Danos (Paris), A.Joyal
(Montreal), D.Sangiorgi (Sophia-Antipolis).
http://www.disi.unige.it/conferences/new-trends97/
- Second International ERCIM Workshop on Formal Methods in Industrial
Critical Systems - Cesena (4-5 July) - Organizers: S. Gnesi, D. Latella,
L. Simoncini (Pisa).
Invited Speakers: E.Brinksma (Twente), U.Herzog (Erlangen), R.Mazzeo
(Sasib Railways), G.Mongardi (Ansaldo Trasporti).
http://fdt.cnuce.cnr.it/~latella/FMICS/WS/Cesena97/workshop.html
- Second International Workshop on Advanced Intelligent Networks (AIN'97) -
Cesena (4-5 July) - Organizers: T. Margaria and B. Steffen (Passau).
Invited Speakers: P.Zave (AT&T), M.Decina (Milano), A.Limongiello
(Telecom Italia).
http://brahms.fmi.uni-passau.de/bs/organization/ain97/ain97.html
- Workshop on Approximation and Randomized Techniques in Computer Science
(Random) - Bologna (11-12 July) - Organizers: J. Rolim (Geneva) and
A. Clementi (Rome).
Invited Speakers: S.Arora (Princeton), P.Crescenzi (Rome), R.Impagliazzo
(San Diego), M.Karpinski (Bonn).
http://cuiwww.unige.ch/~random97
- Workshop on Recent Developments in Formal Languages - Bologna (11-12 July)
Organizer: S.Varricchio (L'Aquila), G.Pirillo (Firenze).
Invited Speaker: D. Perrin (Marne-la-Vallee).
http://univaq.it/~varricch/workshop.html
- Workshop on Algorithmic Aspects of Communication - Bologna (11-12 July) -
Organizers: M. Bonuccelli (Pisa) and A. Marchetti-Spaccamela (Rome).
http://www.di.unipi.it/~bonucce/AlAsCo.html
- Second International Workshop on Verification of Infinite State Systems
(Infinity) - Bologna (11-12 July) - Organizer: F.Moller (Uppsala).
http://www.csd.uu.se/~fm/infinity97cfp.html
-------------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% %
% CONFERENCE PROGRAMME %
% %
% ICALP '97 %
% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Sunday, July 6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Registration: Aula Prodi, 18:30-20:30
Reception: Aula Prodi, 20:30-21:30
Monday, July 7
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Registration: Aula Absidale, 8:30- 9:15
Welcome address: 9:15- 9:30
9:30 Invited Lecture: Dana Scott (CMU, Pittsburgh)
(title to be announced)
10:30 An abstract data type for real numbers
P. Di Gianantonio
Coffee Break: 10:55 - 11:15
-------------------------------------------------------------------------
11:15 - 12:55 Parallel Sessions
A : Formal Languages I B : Computability
-------------------------------------------------------------------------
Enumerative sequences of leaves Recursive Computational Depth
in rational trees J.Lathrop, J. Lutz
F.Bassino, M.-P. Beal,
D. Perrin
A completion algorithm for codes Some bounds on the computational
with bounded synchronization delay power of Piecewise Constant
V. Bruyere Derivative systems
O. Bournez
The expressibility of languages Monadic simultaneous rigid
and relations by word equations E-unification and related problems
J.Karhumaeki, W.Plandowski, Y.Gurevich, A.Voronkov
F.Mignosi
Finite loops recognize exactly Computability on the Probability
the regular open languages Measures on the Borel Sets of the
M.Beaudry, F.Lemieux, D.Therien Unit Interval
K.Weihrauch
-------------------------------------------------------------------------
Lunch: 12:55 - 14:45
14:45 Invited Lecture: Michael O. Rabin (Hebrew U. of Jerusalem &
Harvard U.)
Randomization and the Correctness of Programs
15:45 Tilings and quasiperiodicity
B. Durand
Coffee Break: 16:10 - 16:30
-------------------------------------------------------------------------
16:30 - 18:10 Parallel Sessions
A : Computational Complexity B : Semantics I
-------------------------------------------------------------------------
Results on Resource-Bounded Measure Game Theoretic Analysis of
H.Buhrman, S.Fenner, L.Fortnow Call-by-value Computation
K.Honda, N.Yoshida
Randomization and nondeterminism On modular properties of higher
are incomparable for ordered order extensional lambda calculi
read-once branching programs R. Di Cosmo, N. Ghani
F. Ablayev
Checking Properties of Polynomials On Explicit Substitution and Names
B.Codenotti, F.Ergun, P.S. Gemmell, E. Ritter, V. de Paiva
S.Ravi Kumar
Exact Analysis of Dodgson Elections: On the Dynamics of Sharing Graphs
Lewis Carroll's 1876 Voting System A. Asperti, C. Laneve
is Complete for Parallel Access to NP
E.Hemaspaandra, L.Hemaspaandra,
J.Rothe
-------------------------------------------------------------------------
Tuesday, July 8
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9:00 Invited Lecture: Robin Milner (U. Cambridge)
Graphical Calculi for Interaction
10:00 Bisimulation for probabilistic transition systems:
A coalgebraic approach
E. de Vink, J. Rutten
Coffee Break: 10:25 - 10:45
-------------------------------------------------------------------------
10:45 - 12:00 Parallel Sessions
A : Algorithms I B : Calculi for Concurrency I
-------------------------------------------------------------------------
Minimizing Diameters of Dynamic The name discipline of uniform
Trees receptiveness
S.Alstrup,J.Holm,K.de Lichtenberg, D. Sangiorgi
M.Thorup
Improving Spanning Trees by On confluence in the pi-calculus
Upgrading Nodes A. Philippou, D. Walker
S.Krumke, M.Marathe, H. Noltemeier,
R.Ravi,SS Ravi, R.Sundaram,
H.-C. Wirth
Dynamic algorithms for graphs of A proof theoretical approach to
bounded treewidth communication
T. Hagerup Y. Fu
Break: 12:00 - 12:10
-------------------------------------------------------------------------
12:10 - 13:00 Parallel Sessions
A : Formal Languages II B : Calculi for Concurrency II
-------------------------------------------------------------------------
Solving Trace Equations Using An Algebra-Based Method to
Lexicographical Normal Forms Associate Rewards with EMPA Terms
V.Diekert, Y.Matiyasevich, M. Bernardo
A. Muscholl
Star-free picture expressions are A Semantically Sound Actor
strictly weaker than 1st-order logic Translation
T. Wilke I. Mason, C. Talcott
-------------------------------------------------------------------------
Lunch: 13:00 - 14:45
-------------------------------------------------------------------------
14:45 - 16:00 Parallel Sessions
A : Algorithms II B : Logic and Verification
-------------------------------------------------------------------------
Periodic and Non-periodic Min-Max Computation Paths Logic: An
Equations Expressive, yet Elementary,
U.Schwiegelshohn, L.Thiele Process Logic
D.Harel, E.Singerman
Efficient Parallel Graph Algorithms Model Checking the Full Modal
For Coarse Grained Multicomputers Mu-Calculus for Infinite Sequential
and BSP Processes
E.Caceres, F.Dehne, A.Ferreira, O.Burkart, B.Steffen
P.Flocchini, I.Rieping, A.Roncato,
N.Santoro, S.Song
Upper bound on communication Symbolic Model Checking for
complexity of private information Probabilistic Processes
retrieval C.Baier, E.Clarke, V.Hartonas-
A.Ambainis Garmhausen, M.Kwiatkowska, M.Ryan
-------------------------------------------------------------------------
Coffee Break: 16:00 - 16:20
-------------------------------------------------------------------------
16:20 - 17:10 Parallel Sessions
A : Analysis of Algorithms B : Process Equivalences
-------------------------------------------------------------------------
On the concentration of the height Distributed Processes and Location
of binary search trees Failures
J.M. Robson J.Riely, M.Hennessy
An improved master theorem for Basic Observables for Processes
divide-and-conquer recurrences M.Boreale, R.De Nicola, R.Pugliese
S. Roura
-------------------------------------------------------------------------
Break: 17:10 - 17:15
17:15 - 18:15 Panel:
Funding Policies for Theoretical Computer Science
(with the participation of G. Metakides, DG III-EU,
and G. D'Addona, MURST Italy)
-------------------------------------------------------------------------
Wednesday, July 9
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9:00 - 11:30 Excursion: Guided tour to the city of Bologna
11:30 - 12:30 Laurea Honoris Causa in Computer Science tributed to
Robin Milner and Maurice Nivat by the University
of Bologna
Lunch: 12:30 - 14:45
14:45 - 15:45 Invited Lecture: Christos Papadimitriou (Berkeley)
NP-completeness: A Retrospective
15:45 - 16:10 Worst-case hardness suffices for derandomization: a new
method for hardness-randomness trade-offs
A. Andreev, A. Clementi, J. Rolim
Coffee Break: 16:10 - 16:30
-------------------------------------------------------------------------
16:30 - 18:10 Parallel Sessions
A : Routing Algorithms B : Petri Nets and Process Theory
-------------------------------------------------------------------------
Constrained Bipartite Edge Coloring Efficiency of Asynchronous Systems
with Applications to Wavelength and Read Arcs in Petri Nets
Routing W.Vogler
C.Kaklamanis,G.Persiano,T.Erlebach,
K.Jansen
Colouring Paths in Directed Bisimulation equivalence is
Symmetric Trees with Applications decidable for one-counter processes
to WDM Routing P.Jancar
L.Gargano, P.Hell, S.Perennes
On-line Routing in All-Optical Symbolic Reachability Analysis of
Networks FIFO Channel Systems with Nonregular
Y.Bartal, S.Leonardi Sets of Configurations
A.Bouajjani, P.Habermehl
A Complete Characterization of the Axiomatizations for the Perpetual
Path Layout Construction Problem for Loop in Process Algebra
ATM Networks with Given Hop Count W.Fokkink
and Load
T.Eilam, M.Flammini, S.Zaks
-------------------------------------------------------------------------
Break: 18:10 - 18:20
18:20 - 18:45 Goedel Prize
18:45 - 19:30 EATCS General Assembly
-------------------------------------------------------------------------
Thursday, July 10
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9:00 Invited Lecture: Kurt Mehlhorn (Max-Planck Institut,
Saarbruecken)
The LEDA Platform of Combinatorial and
Geometric Computing
(joint work with S. Naeher and C. Uhrig)
10:00 Maintaining Minimum Spanning Trees in Dynamic Graphs
M. Rauch Henzinger, V. King
Coffee Break: 10:25 - 10:45
-------------------------------------------------------------------------
10:45 - 12:00 Parallel Sessions
A : Algorithms III B : Rewriting
-------------------------------------------------------------------------
Efficient Splitting and Merging The Word Matching Problem is
Algorithms for Order Decomposable Undecidable for Finite Special
Problems String-Rewriting Systems that
R.Grossi, G.F.Italiano are Confluent
P.Narendran, F.Otto
Efficient Array Partitioning The Geometry of Orthogonal
S.Khanna, S.Muthukrishnan, S.Skiena Reduction Spaces
Z.Khasidashvili, J.Glauert
Constructive Linear Time Algorithms The Theory of Vaccines
for Branchwidth M.Marchiori
H.Bodlaender, D.Thilikos
Break: 12:00 - 12:10
-------------------------------------------------------------------------
12:10 - 13:00 Parallel Sessions
A : Formal Languages III B : Cryptography
-------------------------------------------------------------------------
On recognizable and rational formal On Characterization of Escrow
power series in partially commuting Encryption Schemes
variables Y.Frankel, M.Yung
M.Droste, P.Gastin
On a conjecture of J. Shallit Randomness-Efficient Non-
J.Cassaigne Interactive Zero-Knowledge
A.De Santis, G.Di Crescenzo,
G.Persiano
-------------------------------------------------------------------------
Lunch: 13:00 - 14:45
14:45 Invited Lecture: Dominique Perrin (U. de Marne-la-Vallee)
The Wedge-Wegner Hierarchy of
omega-rational Sets
(joint work with O. Carton)
15:45 The Equivalence Problem for Deterministic Pushdown
Automata is Decidable
G. Senizergues
Coffee Break: 16:10 - 16:30
-------------------------------------------------------------------------
16:30 - 18:10 Parallel Sessions
A : Algorithms IV B : Semantics II and Automata
-------------------------------------------------------------------------
Approximation results for the Refining and Compressing Abstract
optimum cost partition problem Domains
K.Jansen R.Giacobazzi, F.Ranzato
The Minimum Color Sum of Bipartite Labelled Reductions, Runtime
Graphs Errors, and Operational Subsumption
A.BarNoy, G.Kortsarz L.Dami
A Primal-Dual Approach to A Complete and Efficiently
Approximation of Node-Deletion Computable Topological
Problems for Matroidal Properties Classification of D-dimensional
T.Fujito Linear Cellular Automata over Z_m
G.Manzini, L.Margara
Independent sets in asteroidal Recognizability Equals Definability
triple-free graphs for Partial k-Paths
H.Broersma, T.Kloks, D.Kratsch, V. Kabanets
H.Mueller
-------------------------------------------------------------------------
18:10 - 18:40 Celebration of the Silver Jubilee of the EATCS
Keynote speaker: Maurice Nivat (Paris 7)
Towards a History of Automata: Why Were They Introduced?
What Are They Good for?
20:30 Banquet
-------------------------------------------------------------------------
Friday, July 11
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9:00 Invited Lecture: Krzysztof R. Apt (CWI, Amsterdam and
University of Amsterdam)
From Chaotic Iteration to Constraint
Propagation
10:00 Discrete-time control for rectangular hybrid automata
Thomas A. Henzinger, Peter W. Kopke
Coffee Break: 10:25 - 10:45
10:45 Invited Lecture: Richard J. Lipton (Princeton Univ.)
DNA ^2 DNA Computations: A Potential
"Killer App"?
(joint work with L. F. Landweber)
Break: 11:45 - 12:00
-------------------------------------------------------------------------
12:00 - 12:50 Parallel Sessions
A : Biocomputing B : Logic Programming
-------------------------------------------------------------------------
Molecular Computing, Bounded Termination of Constraint Logic
Nondeterminism, and Efficient Programs
Recursion
R.Beigel, B.Fu S.Ruggieri
Constructing Big Trees from Short The expressive power of unique
Sequences total stable model semantics
P.Erdos, M.Steel, L.Szekely, F.Buccafurri, S.Greco, D.Sacca'
T.Warnow
End of ICALP'97
-------------------------------------------------------------------------
RELATED CONFERENCES
^^^^^^^^^^^^^^^^^^^
ICALP'97 will be preceded by LICS'97 and CONCUR'97, which will be
held in Warsaw, Poland, the week before. For more details see
http://www.bell-labs.com/topic/conferences/lics/
http://www.ipipan.waw.pl/conferences/concur97/
Warsaw is easily connected to Bologna via Vienna, Frankfurt, Munich,
Rome, Paris, Bruxelles, Amsterdam, London and others.
Further information for participants will be sent in a next mail and may
be found per www.
Received: from ietf.org by ietf.org id aa24865; 29 Apr 97 10:15 EDT
Received: from callandor.cybercash.com by ietf.org id aa24774;
29 Apr 97 10:14 EDT
Received: by callandor.cybercash.com; id KAA21230; Tue, 29 Apr 1997 10:01:05 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma021211; Tue, 29 Apr 97 10:00:52 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA24607; Tue, 29 Apr 97 10:06:05 EDT
Date: Tue, 29 Apr 1997 10:06:04 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Steven Bellovin <smb at research.att.com>
Cc: ietf at ietf.org
Subject: Re: Autonomous System Sanity Protocol
In-Reply-To: <199704282003.QAA07893 at raptor.research.att.com>
Message-Id: <Pine.SUN.3.91.970429100336.24408B-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Steve,
Good idea. See draft-ietf-dnssec-ddi-02.txt for how to format detached DNS
information which could be included with routing infomration.
Donald
On Mon, 28 Apr 1997, Steven Bellovin wrote:
> Date: Mon, 28 Apr 1997 16:03:00 -0400
> From: Steven Bellovin <smb at research.att.com>
> To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
> Cc: ietf at ietf.org
> Subject: Re: Autonomous System Sanity Protocol
>
> You have a spectrum of choices. At one end, you can staticly
> configure loads and loads of security keys into every node and
> then things can pretty much cold boot securely. At the other
> extreme, you could (looking only at IPv4) just configre each
> node with its private key and the public key and address of
> in-addr.arpa or whatever and route insecurely until you get
> verifiable secure routing info at which time you can start
> rejecting any conflicting bogus routing info. Assuming your
> communications are also secured, the worst you can get with the
> second case is denial of service.
>
> The circularity has little to do with DNS. Any means of
> storing any of the security info non locally (PGP key servers,
> whatever) requires that you route insecurely for a while until
> you can retrieve the information you need to route securely.
> As I say, the alternative is lots of local configuration (or at
> least long lived caching), which you can do with DNS data is
> you want.
>
> Well, the other choice -- and the one I'd lean towards -- would be
> inclusion of the address certificate with the routing information.
> For BGP especially, where TCP connections are used, this shouldn't
> be a problem.
>
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa25539; 29 Apr 97 10:35 EDT
Received: from cnri by ietf.org id aa25456; 29 Apr 97 10:33 EDT
Received: from leporello.cs.unibo.it by CNRI.Reston.VA.US id aa11135;
29 Apr 97 10:32 EDT
Received: from ciociosan.cs.unibo.it by leporello.cs.unibo.it (5.67b/96.09.13)
id AA19510; Tue, 29 Apr 1997 15:45:24 +0200
Sender:ietf-request at ietf.org
From: Nadia Busi <busi at cs.unibo.it>
Received: by ciociosan.cs.unibo.it (5.67b/CS-14.10.96)
id AA16478; Tue, 29 Apr 1997 15:45:19 +0200
Date: Tue, 29 Apr 1997 15:45:19 +0200
Message-Id: <199704291345.AA16478 at ciociosan.cs.unibo.it>
To: IETF at CNRI.Reston.VA.US
Subject: ICALP'97 - information for participants
Source-Info: From (or Sender) name not authenticated.
*******************************************************
* *
* ICALP '97 *
* ========= *
* 24th International Colloquium on Automata, *
* Languages, and Programming *
* *
* Silver Jubilee of EATCS *
* *
* Bologna, Italy, July 7th - 11th, 1997 *
* *
*******************************************************
CALL FOR PARTICIPATION
*******************************************************
This announcement and more information about the conference is available
per www under
http://www.cs.unibo.it/icalp97/
or by sending e-mail to icalp97 at cs.unibo.it
Please address inquiries, registration form and hotel reservation form
to the Conference Office:
Italiana & Co. - ICALP'97
Via Altabella 3
I-40126 BOLOGNA (Italy)
Phone: + 39 51 228716
Fax: + 39 51 222881
Email: italiana at bo.nettuno.it
-------------------------------------------------------------------------------
GENERAL INFORMATION
^^^^^^^^^^^^^^^^^^^
The 24th annual meeting of the European Association for Theoretical Computer
Science (EATCS) will take place in Bologna, Italy, July 7-11 1997.
ICALP '97 comes in conjunction with the 25th anniversary of the foundation
of EATCS. To celebrate the SILVER JUBILEE, this edition of ICALP includes
several new events:
- Celebration of EATCS and of its founders (keynote speaker M. Nivat - Paris)
- Invited Lectures on major advances in theoretical computer science since
EATCS has been established:
R. Milner (Cambridge) M.O. Rabin (Jerusalem and Harvard)
C. Papadimitriou (Berkeley) D.S. Scott (Pittsburgh)
- Invited Lectures on the state of the art and new promising trends:
K.R. Apt (Amsterdam) K. Mehlhorn (Saarbruecken)
R.J. Lipton (Princeton) D. Perrin (Marne-la-Vallee)
- A panel on 'Funding Policies for Theoretical Computer Science' with
representatives from major research agencies and from the European Community.
- A number of Satellite Workshops on theory and applications.
AWARDS
^^^^^^
Best student paper award: the recipient of this prize is Salvador
Roura (Univ. Politecnica de Catalunya, Barcelona), author of the paper
"An improved master theorem for divide-and-conquer recurrences".
SPONSORS
^^^^^^^^
ICALP'97 is organized under the auspices of the European Association for
Theoretical Computer Science, the Universities of Bologna, Pisa and
Roma "La Sapienza", and the Regione Emilia Romagna.
Other sponsoring institutions are: EU-DGIII, Unesco Venice Office,
Italian National Council of Researches (Comitati 01, 07, 12), GNIM-CNR,
IEI-CNR, Telecom Italia.
SPECIAL EVENTS
^^^^^^^^^^^^^^
- Laurea Honoris Causa in Computer Science: Robin Milner and Maurice Nivat
will receive such a title from the University of Bologna.
- Goedel prize (sponsored jointly by EATCS and ACM-SIGACT). For information,
please contact Grzegorz Rozenberg: rozenber at wi.leidenuniv.nl
- EATCS General Assembly, with renewal of the Board and of the President.
SOCIAL PROGRAMME
^^^^^^^^^^^^^^^^
Included in the registration fee:
- reception on the evening of Sunday, July 6th, from 8:30pm until 9:30pm.
- excursion (guided walk through the city of Bologna) on Wednesday 9.
- banquet on Thursday 10 (evening).
Extra (please contact the conference office):
- Social programme for accompanying persons and guests, with guided
tours to cities of arts.
- Opera at the Arena in Verona, by night.
RELATED CONFERENCES
^^^^^^^^^^^^^^^^^^^
ICALP'97 will be preceded by LICS'97 and CONCUR'97, which will be
held in Warsaw, Poland, the week before. For more details see
http://www.bell-labs.com/topic/conferences/lics/
http://www.ipipan.waw.pl/conferences/concur97/
Warsaw is easily connected to Bologna via Vienna, Frankfurt, Munich,
Rome, Paris, Bruxelles, Amsterdam, London and others.
CLIMATE
^^^^^^^
The average weather in Bologna in July is sunny and warm (daytime
temperatures around 28-30 degrees Celsius).
LOCATION
^^^^^^^^
The City of Bologna
~~~~~~~~~~~~~~~~
Visiting Bologna means a real immersion in history and art. Its historical
medieval centre stands out thanks to the Two (leaning) Towers, the old
markets and the labyrinth of narrow streets which suddenly open to reveal
treasures of art such as the Abbey and the Square of Santo Stefano, Piazza
della Mercanzia and the Archiginnasio, as well as other splendid churches:
S.Petronio, S.Domenico and S.Francesco. In Bologna, moreover, it is possible
to find numerous restaurants and taverns where to taste the most renown
Italian and Bolognese specialities!
The Conference Hall for ICALP'97
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The venue of the congress ICALP'97 will be the magnificent Aula Magna of
Santa Lucia. It was originally a church, begun in 1623 on the basis of
Girolamo Rainaldi's plan. The front and the apse have never been finished;
inside, however, it appears really striking thanks to its stately
proportions and its stucco works.
Deconsecrated in 1946, now it is the Aula Magna of the University of
Bologna, where the most important events and ceremonies are held.
Actually, we will use the Aula Absidale (entrance from Via De' Chiari 23)
inside the Church of Santa Lucia. The second hall for the parallel session
is the Aula Prodi (entrance from Piazza S.Giovanni in Monte 2), about 50
meters from Santa Lucia. Both are in the very centre of the city and are
air-conditioned.
See the map on the web for more details.
TRAVEL
^^^^^^
Bologna is located in the central southern area of Northern Italy and
it is easily reachable.
By air
~~~ Travellers arrive at Bologna `Marconi' Airport, which is
connected to several European cities (London, Paris, Frankfurt, Munich,
Amsterdam, Bruxelles, Madrid, Lisbon, Copenhagen, Vienna, Barcelona,
Milan, Rome, Lyon, Oporto, Nice, Lugano). Shuttle buses (Aerobus)
operate every 30 min. between the airport and the Centre of Bologna
(ask the driver for the stop Via Indipendenza, S. Pietro). Tickets for
Aerobus cost 6,000 ITL and can be purchased on board. Taxi fare from
the airport to the centre of the city should not exceed 30,000 ITL.
By train
~~~~~ Bologna is the main railroad centre of Italy, as all the trains
connecting the south and the north of Italy have to pass through it.
See the web page for the train timetable.
By road
~~~~ Bologna is directly linked to three highways (A1 Milano-Roma,
A13 Padova-Bologna and A14 Bologna - Bari). The centre of the city is
however limited to residents and the streets are often quite narrow.
Limited car parking facilities are available for some hotels. Ask the
hotel reception for more information.
SOCIAL PROGRAMME FOR ACCOMPANYING PEOPLE AND GUESTS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The conference office will organize trips for spouses and guests (or
lazy participants) with cities of arts as destination:
- Ravenna (ITL 55,000)
- Ferrara (ITL 55,000)
- Venice (ITL 60,000)
(Each fee includes the journey by private coach and the guided tour of the
city. It does not include the tickets to enter museums and monuments and,
with relation to Venice, the ticket to take ferries).
Each tour will be organized only if a minimum of 20 people register.
At the reception of the congress a complete social programme for accompanying
persons will be available, including further trips and events.
REGISTRATION
^^^^^^^^^^^^
Registration to ICALP and related workshops can be done with one single
operation. Please, complete the attached registration form and either
e-mail, fax, or physically mail it with the preferred payment to the Conference
Office at the above address.
GRANTS
^^^^^^
- Unesco Venice Office will partially support (e.g. fees and/or accommodation)
participants coming from less developed countries.
Requests should be sent to the conference office (e-mail or fax)
by May 20, specifying nationality, age, status and affiliation.
Applicants will be notified by June 1.
- A grant for partially supporting the participation of young
researchers (35 years old or below) citizens of countries
belonging to the EU is pending (EU-DGXII project TMR).
Requests should be sent by June 1; applicants will be notified
soon after we will receive positive information on the grant request
from EU.
REGISTRATION FEES FOR ICALP
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The registration fees are the following (1 ECU = 2,100 ITL,
1 US$ = 1,700 ITL, 1 DM = 1,000 ITL, 1 FF = 300 ITL):
Registration and Registration and
payment received payment received
by May 31, 1997 after May 31, 1997
Industry
Registration* 1,200,000 ITL 1,400,000 ITL
Industry EATCS Member
Registration* 1,150,000 ITL 1,350,000 ITL
Academic
Registration* 600,000 ITL 700,000 ITL
Academic EATCS Member
Registration* 550,000 ITL 650,000 ITL
Accompanying
Person** 350,000 ITL 400,000 ITL
Student
Registration*** 250,000 ITL 300,000 ITL
Additional Banquet
Ticket 100,000 ITL 100,000 ITL
*Includes proceedings, reception, lunches, coffee breaks, excursion and
conference banquet.
**Includes reception, lunches, coffee breaks, excursion and
conference banquet.
***Includes reception, lunches, coffee breaks, excursion.
A few additional copies of the proceedings are available and can be
purchased on the spot. The student rate applies to full time students only.
Students must enclose a certification of a full-time student status.
IMPORTANT:
~~~~~~~ All participants paying the registration fee will become
members of EATCS for one year.
REGISTRATION FEES FOR SATELLITE WORKSHOPS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. The registration fees for the two pre-ICALP workshops located in Cesena
(Advanced Intelligent Networks - AIN - and ERCIM Workshop on Formal
Methods in Industrial Critical Systems - FMICS) are cumulated in one
single fee as follows:
Registration and Registration and
payment received payment received
by May 31, 1997 after May 31, 1997
Industry
Registration 300,000 ITL 400,000 ITL
Academic
Registration 150,000 ITL 200,000 ITL
Student
Registration 100,000 ITL 150,000 ITL
The fees include lunches, coffee breaks and a social dinner.
2. The participation to the pre-ICALP workshop in Bologna (New Trends
in Semantics) is free provided that the participants register for ICALP.
3. The registration fees for the four post-ICALP workshops (Random, Formal
Languages, Algorithms of Communication, Infinity) are cumulated in one
single fee as follows:
Registration and Registration and
payment received payment received
by May 31, 1997 after May 31, 1997
Industry
Registration 300,000 ITL 400,000 ITL
Academic
Registration 150,000 ITL 200,000 ITL
Student
Registration 100,000 ITL 150,000 ITL
The fees include lunches and coffee breaks.
PAYMENT
^^^^^^^
The conference fees may be paid by
- Eurocheque drawn in Italian Lira.
Please don't use normal physical mail as the mail system in Italy
is sometimes slow.
- Bank transfer to:
A.I.E.R., account No. 492
ROLO Banca 1473
Agenzia Sede di Bologna
Via Rizzoli, 34
I-40126 Bologna
From Italy, the bank coordinates are: ABI code 3556 and CAB code 2400.
From abroad, the Swift code is ROLO IT 2B200. Please, consider the
extra charge for the bank operation which consists of 20,000 ITL, to
be added to the registration fee.
Be sure to clearly state your name and address; please, confirm by
e-mail or fax to the conference office.
- Credit card (Visa, MasterCard/Eurocard only): payment by credit card
can be accepted only at the desk, when you are in Bologna (hence only
for late registrations).
All payments should be in Italian Lira. The Conference Office will
send confirmation of your payment by fax or e-mail. Receipts will be
distributed at the conference.
REFUND POLICY
^^^^^^^^^^^^^
No refunds will be made unless a written (fax or e-mail) request for
cancellation is received prior to June 29, 1997. All refunds are subject
to a 10% processing fee. Substitutions will be accepted at any moment.
ACCOMMODATION
^^^^^^^^^^^^^
Bologna offers a variety of hotels. Special rates have been negotiated for
attendees in the following hotels. All prices (per night) include breakfast,
service and taxes.
- Holiday Hotel*** - Via Bertiera, 13
It is a modern hotel in a walking distance from the railway station and
Piazza Maggiore. Prices:
Single room ITL 120,000*; Double room ITL 150,000
- University Hotel*** - Via Mentana, 7
A short walk from the university area, it is a modern hotel not very distant
from the railway station and Piazza Maggiore. Prices:
Single room ITL 120,000*; Double room ITL 150,000
- Hotel Regina*** - Via Indipendenza, 51
Located inside the historical centre, 200 metres distant from the
railway station. Entirely provided with all comforts to offer a very
pleasant stay. Fee-paying parking available. Prices:
Single room ITL 115,000; Double room ITL 160,000; Three beds room
ITL 200,000
- Hotel Europa*** - Via C.Boldrini, 4
A modern hotel, recently renovated, a few steps away from the railway
station and a short walk from the centre. Fee-paying parking available.
Prices:
Single room ITL 115,000; Double room ITL 160,000; Three beds room
ITL 200,000
- Hotel Tre Vecchi**** - Via Indipendenza, 47
Situated in the very heart of Bologna centre, it is a first class hotel.
The railway station is just 200 metres away from it. Fee-paying parking
available. Prices:
Single room ITL 159,500; Double room ITL 180,000; Three beds room
ITL 220,000
- Hotel Orologio*** - Via IV Novembre, 10
A few steps away from Piazza Maggiore and Basilica of San Petronio, Hotel
Orologio - so called because it stands just in front of the city hall and
its clock tower - is a delicious cozy hotel with a delightful view of the
most ancient monuments and buildings of the town. Fee-paying parking
available. Prices:
Single room ITL 155,000 (ITL 192,000*); Double room ITL 230,000
- Hotel Commercianti*** - Via De' Pignattari, 11
Hotel Commercianti "The Merchants Hotel" - the first seat of Town Hall in
the XII century - is situated in a quiet street flanked by the Basilica of
S. Petronio in the very central pedestrian area adjoining Piazza Maggiore.
The hotel is functionally restyled and has been redecorated recently.
Fee-paying parking available. Prices:
Single room ITL 155,000 (ITL 192,000*); Double room ITL 230,000
- Hotel Corona D'Oro**** - Via Oberdan, 12
A short walk from the Two Leaning Towers and Piazza Maggiore, in the quint
picture frame of medieval Bologna. The elegantly designed construction, the
residence of the noble family Azzoguidi in the XV century, conserves
architectural elements of various periods. This unique hotel joins the
refined atmosphere to the perfection of a modern 4-stars treatment.
Fee-paying parking available. Prices:
Single room ITL 230,000 (ITL 280,000*); Double room ITL 330,000
*This price is referred to double rooms which will be supplied when all the
single rooms have been assigned.
All hotel rooms are provided with telephone, television, air conditioning
and accept all major credit cards.
Cheaper accommodation can be found in a comfortable building of the
University of Bologna, that is, however, not air conditioned.
- Collegio Erasmus
A former convent, that has been completely renovated and is now a university
residence, 50 meters from the venue of the congress. Free parking available.
Credit cards are not accepted.
Prices (breakfast included):
Single room Itl. 60,000; Double room Itl. 75,000
Accomodation for the workshops in Cesena: please contact the Conference
Office.
CHILD CARE
^^^^^^^^^^
It is possible to organize baby sitting for a group of children aged
2 - 5. If you are interested, please mention it in the registration form
and contact the Conference Office for details.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% %
% REGISTRATION FORM %
% %
% ICALP '97 %
% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Please return this form to Italiana & Co. - ICALP'97
Via Altabella 3
I-40126 BOLOGNA (Italy)
Fax: + 39 51 222881
Email: italiana at bo.nettuno.it
If you are paying by bank transfer, you may return the registration
form by e-mail or by fax. If you are paying by Eurocheque, you should
return your registration form and cheque by physical mail.
Name: _____________________________________________________
Affiliation: ______________________________________________
Address: __________________________________________________
___________________________________________________________
Country: __________________________________________________
Phone: _______________________ Fax: _______________________
Email: ____________________________________________________
Date of Arrival:_____________Date of Departure:____________
For lunches, do you have any special dietary requirements?
vegetarian [ ] Other dietary restrictions, please specify:
___________________________________________________________
I will attend the conference banquet (y/n) :_______________
I need extra banquet tickets (number) :____________________
Item Amount
ICALP registration fee _________ ITL
AIN-FMICS registration fee _________ ITL
Post-Workshops registration fee _________ ITL
Extra banquet tickets _________ ITL
Other expenses (specify below) _________ ITL
Bank charge (20,000 ITL) _________ ITL
TOTAL _________ ITL
Specification for other expenses:__________________________
___________________________________________________________
- Check enclosed [ ]
- Payment by Bank transfer [ ]
- Payment by Credit card at the desk (late registration only) [ ]
Eurocard/MasterCard [ ] VISA [ ]
Name of card holder ____________________________________
Card number ____________________________________________
Expiration date ________________________________________
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% %
% HOTEL RESERVATION FORM %
% %
% ICALP '97 %
% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Please return this form to Italiana & Co. - ICALP'97
Via Altabella 3
I-40126 BOLOGNA (Italy)
Fax: + 39 51 222881
Email: italiana at bo.nettuno.it
Name: _____________________________________________________
Affiliation: ______________________________________________
Type of room(single/double/triple):______ Number of nights: _______
I wish to share my room with:______________________________
Hotel choice (please number 1st choice 1, 2nd choice 2, ...):
Holiday Hotel*** ______
University Hotel*** ______
Hotel Regina*** ______
Hotel Europa*** ______
Hotel Tre Vecchi**** ______
Hotel Orologio*** ______
Hotel Commercianti*** ______
Hotel Corona D'Oro**** ______
Collegio Erasmus ______
Arrival date ___________ time __________
Departure date ___________ time __________
In order to guarantee your accommodation, please indicate the
references of your credit card:
Eurocard/MasterCard [ ] VISA [ ]
Others credit cards [ ] (specify)_______________________
Name of card holder ______________________________
Card number ______________________________________
Expiration date __________________________________
daytime telephone ________________________________
************************************************************************
Received: from ietf.org by ietf.org id aa26695; 29 Apr 97 10:56 EDT
Received: from ietf.ietf.org by ietf.org id aa26294; 29 Apr 97 10:54 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-panabaker-ip-vbi-00.txt
Date: Tue, 29 Apr 1997 10:54:30 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704291054.aa26294 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : THE TRANSMISSION OF IP OVER THE VERTICAL BLANKING
INTERVAL OF A TELEVISION SIGNAL
Author(s) : R. Panabaker, C. Witty
Filename : draft-panabaker-ip-vbi-00.txt
Pages : 15
Date : 04/28/1997
This is an Internet-Draft, which describes a method for broadcasting
multicast IP data using the vertical blanking interval of a television
signal. It includes a description for compressing multicast IP headers on
unidirectional networks, a framing protocol identical to SLIP, and a
forward error correction scheme for the NABTS standard.
Keywords: VBI, NTSC, broadcast, push, FEC, television, NABTS, IP
Internet-Drafts are 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-panabaker-ip-vbi-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-panabaker-ip-vbi-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-panabaker-ip-vbi-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970428161523.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-panabaker-ip-vbi-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-panabaker-ip-vbi-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970428161523.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26697; 29 Apr 97 10:56 EDT
Received: from ietf.ietf.org by ietf.org id aa26145; 29 Apr 97 10:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-costales-subscribe-00.txt
Date: Tue, 29 Apr 1997 10:53:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704291053.aa26145 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : E-Mail Headers to Facilitate Mailing List
Subscriptions and Unsubscriptions
Author(s) : B. Costales
Filename : draft-costales-subscribe-00.txt
Pages : 4
Date : 04/28/1997
The number of ways to subscribe-to (and to unsubscribe-from) e-mail mailing
lists is as varied as the number of programmers designing mailing list
software. For some lists, for example, users (un)subscribe by sending a
request to <listname>-request at host.domain. For others lists the address is
majordomo at host.domain with the request to (un)subscribe embedded in the
message body. Yet others set up special hosts to satisfy this need, such as
<listname>@list-off.domain. In this Internet Draft we offer two new e-mail
headers intended to make mailing list subscription and unsubscription
easier and more uniform: List-Subscribe and List-Unsubscribe.
Internet-Drafts are 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-costales-subscribe-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-costales-subscribe-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-costales-subscribe-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970428101705.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-costales-subscribe-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-costales-subscribe-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970428101705.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26688; 29 Apr 97 10:56 EDT
Received: from ietf.ietf.org by ietf.org id aa26257; 29 Apr 97 10:54 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snanaumib at external.cisco.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snanau-dlurmib-01.txt
Date: Tue, 29 Apr 1997 10:54:25 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704291054.aa26257 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNA NAU Services MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for DLUR
Author(s) : B. Clouston, B. Moore
Filename : draft-ietf-snanau-dlurmib-01.txt
Pages : 23
Date : 04/28/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for monitoring and controlling network
devices with DLUR (Dependent LU Requester) capabilities. This memo
identifies managed objects for the DLUR protocol.
This memo does not specify a standard for the Internet community.
Internet-Drafts are 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-snanau-dlurmib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snanau-dlurmib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snanau-dlurmib-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970428151200.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snanau-dlurmib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snanau-dlurmib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970428151200.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26682; 29 Apr 97 10:56 EDT
Received: from ietf.ietf.org by ietf.org id aa26276; 29 Apr 97 10:54 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snanaumib at external.cisco.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snanau-hprmib-01.txt
Date: Tue, 29 Apr 1997 10:54:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704291054.aa26276 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNA NAU Services MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for HPR
Author(s) : B. Clouston, B. Moore
Filename : draft-ietf-snanau-hprmib-01.txt
Pages : 38
Date : 04/28/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for monitoring and controlling network
devices with HPR (High Performance Routing) capabilities. This memo
identifies managed objects for the HPR protocol.
This memo does not specify a standard for the Internet community.
Internet-Drafts are 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-snanau-hprmib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snanau-hprmib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snanau-hprmib-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970428151446.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snanau-hprmib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snanau-hprmib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970428151446.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26694; 29 Apr 97 10:56 EDT
Received: from ietf.ietf.org by ietf.org id aa26181; 29 Apr 97 10:54 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-pep-03.txt
Date: Tue, 29 Apr 1997 10:54:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704291054.aa26181 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : PEP - an Extension Mechanism for HTTP
Author(s) : H. Frystyk
Filename : draft-ietf-http-pep-03.txt
Pages : 24
Date : 04/28/1997
HTTP is used increasingly in applications that need more facilities than
the standard version of the protocol provides, from distributed authoring,
collaboration and printing, to various remote procedure call mechanisms.
The Protocol Extension Protocol (PEP) is an extension mechanism designed to
address the tension between private agreement and public specification and
to accommodate extension of HTTP clients and servers by software
components.
Internet-Drafts are 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-http-pep-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-pep-03.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970428132415.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-pep-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-pep-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970428132415.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26696; 29 Apr 97 10:56 EDT
Received: from ietf.ietf.org by ietf.org id aa26163; 29 Apr 97 10:54 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-dittert-host-sys-char-00.txt
Date: Tue, 29 Apr 1997 10:54:02 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704291054.aa26163 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : DHCP Options For Host System Characteristics
Author(s) : M. Henry, E. Dittert
Filename : draft-dittert-host-sys-char-00.txt
Pages : 6
Date : 04/28/1997
The interoperability of configuration services based on the Dynamic Host
Configuration Protocol (DHCP) [1] in an environment of heterogeneous
clients depends on clients accurately identifying themselves and their
relevant characteristics to configuration servers. The class identifier
provided through DHCP option 60 [2] helps in this regard, but such
identifiers essentially only enable clients and servers that are "good
friends" to find each other. This draft proposes the definition of two
options that convey particular, generally useful information about the
client system. This enables all servers to recognize this information,
and is a step toward a richer form of interoperability for
configuration services.
Internet-Drafts are 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-dittert-host-sys-char-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dittert-host-sys-char-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-dittert-host-sys-char-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970428103059.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dittert-host-sys-char-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dittert-host-sys-char-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970428103059.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26693; 29 Apr 97 10:56 EDT
Received: from ietf.ietf.org by ietf.org id aa26234; 29 Apr 97 10:54 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snmpv3 at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snmpv3-next-gen-arch-00.txt
Date: Tue, 29 Apr 1997 10:54:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704291054.aa26234 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNMP Version 3 Working Group
of the IETF.
Title : Architecture for the Next Generation Simple Network
Management Protocol (SNMPng)
Author(s) : D. Harrington, B. Wijnen
Filename : draft-ietf-snmpv3-next-gen-arch-00.txt
Pages : 31
Date : 04/28/1997
This document describes an architecture for the Next-Generation of the
Simple Network Management Protocol (SNMPng). The architecture is designed
to be modular to allow the evolution of the protocol over time. The major
portions of the architecture are 1) a message processing and control
framework, 2) a security framework, and 3) a local processing framework.
Internet-Drafts are 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-snmpv3-next-gen-arch-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-next-gen-arch-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snmpv3-next-gen-arch-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970428140811.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-next-gen-arch-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-next-gen-arch-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970428140811.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01671; 29 Apr 97 11:45 EDT
Received: from ietf.ietf.org by ietf.org id aa01223; 29 Apr 97 11:42 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-esp-rc5-cbc-00.txt
Date: Tue, 29 Apr 1997 11:42:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704291142.aa01223 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : The ESP RC5-CBC Algorithm
Author(s) : R. Pereira, R. Baldwin
Filename : draft-ietf-ipsec-esp-rc5-cbc-00.txt
Pages : 5
Date : 04/25/1997
This draft describes the RC5 block cipher algorithm as to be used with the
IPSec Encapsulating Security Payload (ESP).
Internet-Drafts are 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-ipsec-esp-rc5-cbc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970425145805.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-esp-rc5-cbc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970425145805.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02010; 29 Apr 97 11:48 EDT
Received: from gizmo.lut.ac.uk by ietf.org id aa01772; 29 Apr 97 11:47 EDT
Received: from mrrl.lut.ac.uk [127.0.0.1] (martin)
by gizmo.lut.ac.uk with esmtp (Exim 1.61 #1)
id 0wMEnz-0007Uz-00; Tue, 29 Apr 1997 16:26:59 +0100
X-Mailer: exmh version 2.0gamma 1/27/97
To: martin at mail.loughborough.leics.uk.eu.org
X-Uri: <URL:http://www.net.lut.ac.uk/~martin>
Subject: European WWW indexing coordination
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-901064592P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 29 Apr 1997 16:26:31 +0100
Sender:ietf-request at ietf.org
From: Martin Hamilton <martin at mrrl.lut.ac.uk>
Message-Id: <E0wMEnz-0007Uz-00 at gizmo.lut.ac.uk>
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-901064592P
Content-Type: text/plain; charset=us-ascii
[Apologies for cross-posting :-)]
TF-CHIC:
TERENA Task Force on Cooperative Hierarchical Indexing Coordination
When a user wishes to find specific information on the World-Wide Web
today a common approach is to use one of the established commercial
search engines such as AltaVista, Lycos, or WebCrawler. The majority
of these services make inefficient use of international bandwidth by
running their data gathering robots across the commodity Internet from
central sites (typically in the United States), and by requiring end
users to connect to these central sites in order to perform searches.
Whilst World-Wide Web indexing and searching would appear to be major
consumers of international bandwidth, little hard information on the
cost of these activities is available.
In addition to these commercial services, a number of local, regional
and topical WWW indexes have been created, as grass-roots volunteer
projects or with public funding. These are of particular interest to
the academic and research community because they can provide a higher
signal to noise ratio in search results, and in several cases employ
advanced techniques such as distributed data gathering and searching
so as to make more effective use of network bandwidth.
In order that the current situation and possibilities for future
development be better understood, a TERENA task force has been formed.
This will initially be:
(a) gathering statistics on the usage of WWW search engines from
proxy cache server and network managers.
(b) gathering statistics on robot activity from HTTP server
administrators.
(c) identifying existing grass-roots WWW indexing and searching
initiatives, and the potential for coordination.
(d) identifying technologies currently in use for distributed
indexing and searching, and emerging technologies.
Whilst this effort is primarily aimed at members of the European
academic and research community, any constructive participation would
be very welcome. Please feel free to forward this message on to anyone
who might be interested.
You can join the task force's mailing list by sending email to:
mailserver at terena.nl
containing only the text:
subscribe tf-chic My Name
replacing "My Name" as appropriate.
As the task force progresses, we will be putting our findings up on the
TERENA WWW server, at:
<URL:http://www.terena.nl/task-forces/tf-chic/>
Our first face to face meeting will be just before the Joint European
Networking Conference, on the morning of May 11th in Edinburgh, UK.
Cheers!
Martin Hamilton <martin at mrrl.lut.ac.uk>
Sigfrid Lundberg <siglun at gungner.ub2.lu.se>
-TF-CHIC co-chairs
--==_Exmh_-901064592P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.3i
iQCVAwUBM2YTJNZdpXZXTSjhAQEJTgP+NlYig+qbqw/spx6hShWOE/DqeTDjuG0w
8EiWl9U3GKxSJf6zyzg9hqS17XTXUoQGUa9ZvZoXXiq4CHSlzZp4ECAtJu4uRGKQ
0sO9kcqyDCyhMH1LqYCKsLjSQGW63cRGBUapCJx8Eni4QidJI0vK9vidgzNDsUc8
ZQxlix/B6T0=
=8+c/
-----END PGP MESSAGE-----
--==_Exmh_-901064592P--
Received: from ietf.org by ietf.org id aa04574; 29 Apr 97 12:53 EDT
Received: from zephyr.isi.edu by ietf.org id aa04322; 29 Apr 97 12:45 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA01516>; Tue, 29 Apr 1997 09:41:57 -0700
Message-Id: <199704291641.AA01516 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2140 on TCP Control Block Interdependence
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 29 Apr 97 09:41:56 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2140:
Title: TCP Control Block Interdependence
Author: J. Touch
Date: April 1997
Mailbox: touch at isi.edu
Pages: 11
Characters: 26032
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2140.txt
This memo makes the case for interdependent TCP control blocks, where
part of the TCP state is shared among similar concurrent connections,
or across similar connection instances.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970429093637.RFC at ISI.EDU>
SEND /rfc/rfc2140.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2140.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970429093637.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa08157; 29 Apr 97 14:40 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16930;
29 Apr 97 14:40 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA02989 at pad-thai.cam.ov.com>; Tue, 29 Apr 1997 17:23:30 GMT
Message-Id: <F0C5060A8699D011A2B100805F14C869829B64 at RED-75-MSG.dns.microsoft.com>
From: Mike Swift <mikesw at microsoft.com>
To: D.Pinkas at frcl.bull.fr, CAT-IETF WG <cat-ietf at mit.edu>
Subject: RE: SP-NEGO
Date: Tue, 29 Apr 1997 10:23:17 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Precedence: bulk
Looking at this latest draft the only major concern I have (so far) is
the mechListMIC field. While it is more concise to just MIC the mech
list, with commercial ASN1 compilers it is difficult to take a
negotiation token and produce juse the mechanism list - usually you have
to decode the token and re-encode just the mechanism list. I also think
it would make more sense to compute a hash, such as MD5 or SHA-1, of the
whole initial token when it arrives and then compute a MIC of that hash.
The advantages of this are (1) the SPNEGO code doesn't have to hang on
to either the mech list or the initial token, and (2) the actual data
MICd is fairly small.
- Mike Swift
> -----Original Message-----
> From: Denis Pinkas [SMTP:D.Pinkas at frcl.bull.fr]
> Sent: Tuesday, April 22, 1997 4:55 PM
> To: CAT-IETF WG
> Subject: SP-NEGO
>
> CATfanciers,
>
> I have prepared the document that is the successor of the
> draft-ietf-cat-snego-03.txt.
>
> It is NOT <draft-ietf-cat-snego-03.txt>
> but <draft-ietf-cat-spnego-01.txt>
>
> because the title is now :
>
> The Simple and Protected GSS-API Negotiation Mechanism
>
> When making the changes it appeared that we have in most cases a
> protected negotiation and the new title seemed to me more appropriate.
>
>
> I have made multiple changes from the text originally provided by
> Bill.
>
> I will be away till next week, so you have plenty of time to review it
>
> before sending comments.
>
> 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa08477; 29 Apr 97 14:50 EDT
Received: from ginger.lcs.mit.edu by ietf.org id aa08301; 29 Apr 97 14:45 EDT
Received: by ginger.lcs.mit.edu
id AA07333; Tue, 29 Apr 97 14:42:24 -0400
Date: Tue, 29 Apr 97 14:42:24 -0400
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9704291842.AA07333 at ginger.lcs.mit.edu>
To: jnc at ginger.lcs.mit.edu, kent at bbn.com
Subject: Re: Autonomous System Sanity Protocol
Cc: ietf at ietf.org, jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: Stephen Kent <kent at bbn.com>
I agree with the analysis you cite
It turns out to be more complicated than I thought, now that I think about it
some more. On the plus side (for DV) there are some places you can cache
results from previous checks (e.g. "is router R allowed to claim connectivity
to network X"), which can save you a fair amount of overhead.
On the negative side, iff you don't want to be vulnerable to replays (which
could easily be accidental, as well as malicious - a good part of the recent
routing meltdown was due to routes hanging around in the system afer they
were supposed to disappear), you need to timestamp all routes, so that an old
reachability advertisement (one which is no longer correct) cannot be reused.
(E.g. if X->Y->Z is a working path, and Z keeps a copy of the correctly
signed route, and Y goes away, there's nothing to stop Z continuing to repeat
the route.)
Fixing this with timestamps means you can't do the caching, which puts you
straight back into the soup of more overhead to process routing updates, with
consequent negative effects on stabilization times...
my clients also have an understandable concern about deployment and the
existing BGP base, so it's not unreasonable to look at how to make life
safer in the current context
I understand that concern. However, my perspective is that sooner or later
we're going to have to make a switch *anyway*, and i) the longer we put it
off, the more painful and expensive that switch will be, and ii) the effort
going into improving the current architecture (which is, I believe, a
"diminishing returns" situation) could perhaps be expended at higher
cost/benefit ratio on working on a new architecture.
use of route servers in ASs allows for offloading computation in a
fashion analogous to the MD approach you described
Sorry, I didn't follow this. My chief reason for liking MD architectures has
to do with the fact that map element data is quite different from routing
table entry data, and results in a fundamentally very dissimilar system - and
implementation details such as use of route servers doesn't change any of
that.
Noel
Received: from cnri by ietf.org id aa12847; 29 Apr 97 16:33 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19454;
29 Apr 97 16:33 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA05846 at pad-thai.cam.ov.com>; Tue, 29 Apr 1997 18:33:08 GMT
Message-Id: <F0C5060A8699D011A2B100805F14C869844669 at RED-75-MSG.dns.microsoft.com>
From: Mike Swift <mikesw at microsoft.com>
To: Mike Swift <mikesw at microsoft.com>, D.Pinkas at frcl.bull.fr,
CAT-IETF WG <cat-ietf at mit.edu>
Subject: RE: SP-NEGO
Date: Tue, 29 Apr 1997 11:31:01 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Precedence: bulk
There is another issues that the current draft doesn't address. The
first is that the additional controls passed to init_sec_context (the
req_flags parameter) are not used when negotiating - they only apply to
the final mechanism used. This means that if a caller of SP-NEGO asks
for a set of capabilities such as sequence detection and anonymous
authentication they may end up with a mechanism that supports neither
but was higher up the list of mech-types on the server. One possibility
is to trim the list of mechanisms negotiated to only include those that
support the requested attributes. This goes against the definition of
those flags in the GSS-API spec, which states that the caller is
responsible for checking the flags. Another possibility would be to
include the requested controls in the initial negotiation token to allow
the server to do the filtering. This has the advantage that packages
that don't support the requested controls may still be used but the
server can try to accommodate the request.
- Mike Swift
> -----Original Message-----
> From: Mike Swift
> Sent: Tuesday, April 29, 1997 10:23 AM
> To: D.Pinkas at frcl.bull.fr; CAT-IETF WG
> Subject: RE: SP-NEGO
>
> Looking at this latest draft the only major concern I have (so far) is
> the mechListMIC field. While it is more concise to just MIC the mech
> list, with commercial ASN1 compilers it is difficult to take a
> negotiation token and produce juse the mechanism list - usually you
> have
> to decode the token and re-encode just the mechanism list. I also
> think
> it would make more sense to compute a hash, such as MD5 or SHA-1, of
> the
> whole initial token when it arrives and then compute a MIC of that
> hash.
> The advantages of this are (1) the SPNEGO code doesn't have to hang on
> to either the mech list or the initial token, and (2) the actual data
> MICd is fairly small.
>
> - Mike Swift
>
>
> > -----Original Message-----
> > From: Denis Pinkas [SMTP:D.Pinkas at frcl.bull.fr]
> > Sent: Tuesday, April 22, 1997 4:55 PM
> > To: CAT-IETF WG
> > Subject: SP-NEGO
> >
> > CATfanciers,
> >
> > I have prepared the document that is the successor of the
> > draft-ietf-cat-snego-03.txt.
> >
> > It is NOT <draft-ietf-cat-snego-03.txt>
> > but <draft-ietf-cat-spnego-01.txt>
> >
> > because the title is now :
> >
> > The Simple and Protected GSS-API Negotiation Mechanism
> >
> > When making the changes it appeared that we have in most cases a
> > protected negotiation and the new title seemed to me more
> appropriate.
> >
> >
> > I have made multiple changes from the text originally provided by
> > Bill.
> >
> > I will be away till next week, so you have plenty of time to review
> it
> >
> > before sending comments.
> >
> > 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa15253; 29 Apr 97 17:01 EDT
Received: from ZAFU.BBN.COM by ietf.org id aa14798; 29 Apr 97 16:56 EDT
Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id QAA18697; Tue, 29 Apr 1997 16:53:12 -0400 (EDT)
X-Sender: kent at po1.bbn.com
Message-Id: <v03007812af8c0b384f4d at [128.89.0.110]>
In-Reply-To: <9704291842.AA07333 at ginger.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 29 Apr 1997 16:40:48 -0400
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Sender:ietf-request at ietf.org
From: Stephen Kent <kent at bbn.com>
Subject: Re: Autonomous System Sanity Protocol
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Noel,
We're looking at this issue from two perspectives: authentication
and authorization. There are already protocol enhancements defined that
allow for point-to-point authentication of all traffic between BGP peers.
There also was a paper (in SNDSS, this February) on how to authenticate DV
updates, to provide multicast authentication of that data, on an
incremental basis. One aspect that has not been addressed in these
previous activities is the authorization of a BGP speaker to advertise
reachability info. This is the focus of the work we have just embarked
upon. We are looking at both initial authorization for "ownership" of a
portion of the address space, and for route advertisement authorization.
Even if one implemented all of the other proposals I've seen for
routing security, we would still be vulnerable to attacks or benign conig
errors unless we have an authorization scheme in place. However, the
nature of the scehme also needs to match the routing
authentication/integrity requirements that it supports. In that sense,
you're right that an MD system would have different requirements from a DV
system, and thus the authorization and authentication approaches might
differ in significant ways. I'm not totally happy with the likely overhead
for what we know how to do so far, but at least we understand the security
functionality that we can achieve and we'll be able to see what the
performance hits will be. Then we can explore caching and other
optimizations and see how well we can do.
Steve
Received: from ietf.org by ietf.org id aa20339; 29 Apr 97 18:37 EDT
Received: from ietf.ietf.org by ietf.org id aa20247; 29 Apr 97 18:34 EDT
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Telnet Comport Control Option to Proposed Standard
Reply-to: iesg at ietf.org
Date: Tue, 29 Apr 1997 18:34:07 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704291834.aa20247 at ietf.org>
The IESG has received a request to consider "Telnet Comport Control
Option <draft-clark-telnet-control-02.txt> as a Proposed Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
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
iesg at ietf.org or ietf at ietf.org mailing lists by June 30, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa20573; 29 Apr 97 18:43 EDT
Received: from ietf.ietf.org by ietf.org id aa20490; 29 Apr 97 18:42 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Communicating Presentation Information in Internet
Messages: The Content-Disposition Header Field to Proposed
Standard
Reply-to: iesg at ietf.org
Date: Tue, 29 Apr 1997 18:42:45 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9704291842.aa20490 at ietf.org>
The IESG has received a request to consider Communicating Presentation
Information in Internet Messages: The Content-Disposition Header Field
<draft-moore-mime-cdisp-00.txt> as a Proposed Standard. This has
been reviewed in the IETF but is not the product of an IETF Working
Group.
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
iesg at ietf.org or ietf at ietf.org mailing lists by May 30, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa23111; 29 Apr 97 21:02 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24580;
29 Apr 97 21:02 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA14926 at pad-thai.cam.ov.com>; Tue, 29 Apr 1997 22:35:25 GMT
From: brian at isi.edu
Date: Tue, 29 Apr 1997 15:33:43 -0700
Posted-Date: Tue, 29 Apr 1997 15:33:43 -0700
Message-Id: <199704292233.AA04234 at dot.isi.edu>
To: cat-ietf at mit.edu
Subject: second pass PKINIT
Precedence: bulk
Here's the most recent revision of the PKINIT draft. Most of the issues
have been resolved. There is a new section on proposed database
modifications; comments?
One major outstanding issue: in the digital signature option, how should
the client obtain the public key certificate of the KDC, if it does not
already possess it?
b
=====
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-04.txt Clifford Neuman
Updates: RFC 1510 ISI
expires October 31, 1997 John Wray
Digital Equipment Corporation
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
Jonathan Trostle
Novell
Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-04.txt, and expires October 31,
1997. Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
key cryptography during initial authentication. The methods
defined specify the ways in which preauthentication data fields and
error data fields in Kerberos messages are to be used to transport
public key data.
2. Introduction
The popularity of public key cryptography has produced a desire for
its support in Kerberos [2]. The advantages provided by public key
cryptography include simplified key management (from the Kerberos
perspective) and the ability to leverage existing and developing
public key certification infrastructures.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to associate a key pair with each realm, which can
then be used to facilitate cross-realm authentication; this is the
topic of another draft proposal. Another way is to allow users with
public key certificates to use them in initial authentication. This
is the concern of the current document.
One of the guiding principles in the design of PKINIT is that
changes should be as minimal as possible. As a result, the basic
mechanism of PKINIT is as follows: The user sends a request to the
KDC as before, except that if that user is to use public key
cryptography in the initial authentication step, his certificate
accompanies the initial request, in the preauthentication fields.
Upon receipt of this request, the KDC verifies the certificate and
issues a ticket granting ticket (TGT) as before, except that instead
of being encrypted in the user's long-term key (which is derived
from a password), it is encrypted in a randomly-generated key. This
random key is in turn encrypted using the public key from the
certificate that came with the request and signed using the KDC's
private key, and accompanies the reply, in the preauthentication
fields.
PKINIT also allows for users with only digital signature keys to
authenticate using those keys, and for users to store and retrieve
private keys on the KDC.
The PKINIT specification may also be used for direct peer to peer
authentication without contacting a central KDC. This application
of PKINIT is described in PKTAPP [4] and is based on concepts
introduced in [5, 6]. For direct client-to-server authentication,
the client uses PKINIT to authenticate to the end server (instead
of a central KDC), which then issues a ticket for itself. This
approach has an advantage over SSL [7] in that the server does not
need to save state (cache session keys). Furthermore, an
additional benefit is that Kerberos tickets can facilitate
delegation (see [8]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following changes to RFC 1510 are proposed:
--> Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity.
--> Users may store private keys on the KDC for retrieval during
Kerberos initial authentication.
This proposal addresses two ways that users may use public key
cryptography for initial authentication. Users may present public
key certificates, or they may generate their own session key,
signed by their digital signature key. In either case, the end
result is that the user obtains an ordinary TGT that may be used for
subsequent authentication, with such authentication using only
conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 and 3.3 describe the extensions for the two initial
authentication methods. Section 3.4 describes a way for the user to
store and retrieve his private key on the KDC, as an adjunct to the
initial authentication.
3.1. Definitions
Encryption types will be specified using ENCTYPE tags; we propose
the addition of the following types:
dsa-sign 8
rsa-priv 9
rsa-pub 10
The extensions involve new preauthentication fields; we propose the
addition of the following types:
PA-PK-AS-REQ 14
PA-PK-AS-REP 15
PA-PK-AS-SIGN 16
PA-PK-KEY-REQ 17
PA-PK-KEY-REP 18
The extensions also involve new error types; we propose the addition
of the following types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
In the exposition below, we use the terms public key and private
key generically. It should be understood that the term "public
key" may be used to refer to either a public encryption key or a
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys.
All additional symmetric keys specified in this draft shall use the
same encryption type as the session key in the response from the
KDC. These include the temporary keys used to encrypt the signed
random key encrypting the response, as well as the key derived from
Diffie-Hellman agreement. In the case of Diffie-Hellman, the key
shall be produced from the agreed bit string as follows:
* Truncate the bit string to the appropriate length.
* Rectify parity in each byte (if necessary) to obtain the key.
For instance, in the case of a DES key, we take the first eight
bytes of the bit stream, and then adjust the least significant bit
of each byte to ensure that each byte has odd parity.
3.2. Standard Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with PKINIT.
It is assumed that all public keys are signed by some certification
authority (CA). The initial authentication request is sent as per
RFC 1510, except that a preauthentication field containing data
signed by the user's private key accompanies the request:
PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14
signedAuthPack [0] SignedAuthPack
userCert [1] SEQUENCE OF Certificate OPTIONAL,
-- the user's certificate chain
trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL
-- CAs that the client trusts
}
SignedAuthPack ::= SEQUENCE {
authPack [0] AuthPack,
authPackSig [1] Signature,
-- of authPack
-- using user's private key
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- if client is using Diffie-Hellman
}
PKAuthenticator ::= SEQUENCE {
kdcName [0] PrincipalName,
cusec [1] INTEGER,
-- for replay prevention
ctime [2] KerberosTime,
-- for replay prevention
nonce [3] INTEGER
}
Signature ::= SEQUENCE {
signedHash [0] EncryptedData
-- of type Checksum
}
Checksum ::= SEQUENCE {
cksumtype [0] INTEGER,
checksum [1] OCTET STRING
} -- as specified by RFC 1510
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm [0] algorithmIdentifier,
subjectPublicKey [1] BIT STRING
} -- as specified by the X.509 recommendation [9]
Certificate ::= SEQUENCE {
certType [0] INTEGER,
-- type of certificate
-- 1 = X.509v3 (DER encoding)
-- 2 = PGP (per PGP specification)
certData [1] OCTET STRING
-- actual certificate
-- type determined by certType
}
The PKAuthenticator carries information to foil replay attacks,
to bind the request and response, and to optionally pass the
client's Diffie-Hellman public value (i.e. for using DSA in
combination with Diffie-Hellman). The PKAuthenticator is signed
with the private key corresponding to the public key in the
certificate found in userCert (or cached by the KDC).
In the PKAuthenticator, the client may specify the KDC name in one
of two ways:
* The Kerberos principal name K/M@<realm_name>, where
<realm_name> is replaced by the applicable realm name.
* The name in the KDC's certificate (e.g., an X.500 name, or a
PGP name).
Note that the first case requires that the certificate name and the
Kerberos principal name be bound together (e.g., via an X.509v3
extension).
The userCert field is a sequence of certificates, the first of which
must be the user's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the user's
certificate. These cerificates may be used by the KDC to verify the
user's public key. This field may be left empty if the KDC already
has the user's certificate.
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate.
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(userCert), if one is provided in the request. This is done by
verifying the certification path against the KDC's policy of
legitimate certifiers. This may be based on a certification
hierarchy, or it may be simply a list of recognized certifiers in a
system like PGP. If the certification path does not match one of
the KDC's trusted certifiers, the KDC sends back an error message of
type KDC_ERR_CLIENT_NOT_TRUSTED, and it includes in the error data
field a list of its own trusted certifiers, upon which the client
resends the request.
If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
verifies that it has a certificate issued by one of the certifiers
trusted by the client. If it does not have a suitable certificate,
the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
the client.
If a trust relationship exists, the KDC then verifies the client's
signature on PKAuthenticator. If that fails, the KDC returns an
error message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses
the timestamp in the PKAuthenticator to assure that the request is
not a replay. The KDC also verifies that its name is specified in
the PKAuthenticator.
If the clientPublicValue field is filled in, indicating that the
client wishes to use Diffie-Hellman key agreement, then the KDC
checks to see that the parameters satisfy its policy. If they do
not (e.g., the prime size is insufficient for the expected
encryption type), then the KDC sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
private values for the response.
Assuming no errors, the KDC replies as per RFC 1510, except as
follows: The user's name in the ticket is as represented in the
certificate, unless a Kerberos principal name is bound to the name
in the certificate (e.g., via an X.509v3 extension). Moreover, the
KDC encrypts the reply not with the user's long-term key, but with a
random key generated only for this particular response. This random
key is sealed in the preauthentication field:
PA-PK-AS-REP ::= SEQUENCE {
-- PA TYPE 15
encSignedReplyKeyPack [0] EncryptedData,
-- of type SignedReplyKeyPack
-- using the temporary key
-- in encTmpKey
encTmpKeyPack [1] EncryptedData,
-- of type TmpKeyPack
-- using either the client public
-- key or the Diffie-Hellman key
-- specified by SignedDHPublicValue
signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL
-- if one was passed in the request
kdcCert [3] SEQUENCE OF Certificate OPTIONAL,
-- the KDC's certificate chain
}
SignedReplyKeyPack ::= SEQUENCE {
replyKeyPack [0] ReplyKeyPack,
replyKeyPackSig [1] Signature,
-- of replyEncKeyPack
-- using KDC's private key
}
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- used to encrypt main reply
nonce [1] INTEGER
-- binds response to the request
-- must be same as the nonce
-- passed in the PKAuthenticator
}
TmpKeyPack ::= SEQUENCE {
tmpKey [0] EncryptionKey,
-- used to encrypt the
-- SignedReplyKeyPack
}
SignedKDCPublicValue ::= SEQUENCE {
kdcPublicValue [0] SubjectPublicKeyInfo,
kdcPublicValueSig [1] Signature
-- of kdcPublicValue
-- using KDC's private key
}
The kdcCert field is a sequence of certificates, the first of which
must be the KDC's public key certificate. The name represented in
the certificate must be either a PrincipalName or a string which
directly translates to the name "K/M at realm.name" where "realm.name"
is replaced by the name of the KDC's realm. Any subsequent
certificates will be certificates of the certifiers of the KDC's
certificate. The last of these must have as its certifier one of
the certifiers sent to the KDC in the PA-PK-AS-REQ. These
cerificates may be used by the client to verify the KDC's public
key. This field is empty if the client did not send to the KDC a
list of trusted certifiers (the trustedCertifiers field was empty).
Since each certifier in the certification path of a user's
certificate is essentially a separate realm, the name of each
certifier shall be added to the transited field of the ticket. The
format of these realm names shall follow the naming constraints set
forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will
require new nametypes to be defined for PGP certifiers and other
types of realms as they arise. If applicable, the
transit-policy-checked flag should be set in the issued ticket.
The KDC's certificate must bind the public key to a name derivable
from the name of the realm for that KDC. The client then extracts
the random key used to encrypt the main reply. This random key (in
encPaReply) is encrypted with either the client's public key or
with a key derived from the DH values exchanged between the client
and the KDC.
3.3. Digital Signature
Implementation of the changes in this section are OPTIONAL for
compliance with PKINIT.
We offer this option with the warning that it requires the client to
generate a random key; the client may not be able to guarantee the
same level of randomness as the KDC.
If the user registered, or presents a certificate for, a digital
signature key with the KDC instead of an encryption key, then a
separate exchange must be used. The client sends a request for a
TGT as usual, except that it (rather than the KDC) generates the
random key that will be used to encrypt the KDC response. This key
is sent to the KDC along with the request in a preauthentication
field, encrypted with the KDC's public key:
PA-PK-AS-SIGN ::= SEQUENCE {
-- PA TYPE 16
encSignedRandomKeyPack [0] EncryptedData,
-- of type SignedRandomKeyPack
-- using the key in encTmpKeyPack
encTmpKeyPack [1] EncryptedData,
-- of type TmpKeyPack
-- using the KDC's public key
userCert [2] SEQUENCE OF Certificate OPTIONAL
-- the user's certificate chain
}
SignedRandomKeyPack ::= SEQUENCE {
randomkeyPack [0] RandomKeyPack,
randomkeyPackSig [1] Signature
-- of keyPack
-- using user's private key
}
RandomKeyPack ::= SEQUENCE {
randomKey [0] EncryptionKey,
-- will be used to encrypt reply
randomKeyAuth [1] PKAuthenticator
-- nonce copied from AS-REQ
}
If the KDC does not accept client-generated random keys as a matter
of policy, then it sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as
follows.
Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
the randomKey. It then replies as per RFC 1510, except that the
reply is encrypted not with a password-derived user key, but with
the randomKey sent in the request. Since the client already knows
this key, there is no need to accompany the reply with an extra
preauthentication field. The transited field of the ticket should
specify the certification path as described in Section 3.2.
3.4. Retrieving the User's Private Key from the KDC
Implementation of the changes described in this section are OPTIONAL
for compliance with PKINIT.
When the user's private key is not stored local to the user, he may
choose to store the private key (normally encrypted using a
password-derived key) on the KDC. In this case, the client makes a
request as described above, except that instead of preauthenticating
with his private key, he uses a symmetric key shared with the KDC.
For simplicity's sake, this shared key is derived from the password-
derived key used to encrypt the private key, in such a way that the
KDC can authenticate the user with the shared key without being able
to extract the private key.
We provide this option to present the user with an alternative to
storing the private key on local disk at each machine where he
expects to authenticate himself using PKINIT. It should be noted
that it replaces the added risk of long-term storage of the private
key on possibly many workstations with the added risk of storing the
private key on the KDC in a form vulnerable to brute-force attack.
Denote by K1 the symmetric key used to encrypt the private key.
Then construct symmetric key K2 as follows:
* Perform a hash on K1.
* Truncate the digest to Length(K1) bytes.
* Rectify parity in each byte (if necessary) to obtain K2.
The KDC stores K2, the public key, and the encrypted private key.
This key pair is designated as the "primary" key pair for that user.
This primary key pair is the one used to perform initial
authentication using the PA-PK-AS-REP preauthentication field. If
he desires, he may also store additional key pairs on the KDC; these
may be requested in addition to the primary. When the client
requests initial authentication using public key cryptography, it
must then include in its request, instead of a PA-PK-AS-REQ, the
following preauthentication sequence:
PA-PK-KEY-REQ ::= SEQUENCE {
-- PA TYPE 17
signedPKAuth [0] SignedPKAuth,
trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
-- CAs that the client trusts
keyIDList [2] SEQUENCE OF Checksum OPTIONAL
-- payload is hash of public key
-- corresponding to desired
-- private key
-- if absent, KDC will return all
-- stored private keys
}
SignedPKAuth ::= SEQUENCE {
pkAuth [0] PKAuthenticator,
pkAuthSig [1] Signature
-- of pkAuth
-- using the symmetric key K2
}
If a keyIDList is present, the first identifier should indicate
the primary private key. No public key certificate is required,
since the KDC stores the public key along with the private key.
If there is no keyIDList, all the user's private keys are returned.
Upon receipt, the KDC verifies the signature using K2. If the
verification fails, the KDC sends back an error of type
KDC_ERR_INVALID_SIG. If the signature verifies, but the requested
keys are not found on the KDC, then the KDC sends back an error of
type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as
described in Section 3.2, except that in addition, the KDC appends
the following preauthentication sequence:
PA-PK-KEY-REP ::= SEQUENCE {
-- PA TYPE 18
encKeyRep [0] EncryptedData
-- of type EncKeyReply
-- using the symmetric key K2
}
EncKeyReply ::= SEQUENCE {
keyPackList [0] SEQUENCE OF KeyPack,
-- the first KeyPair is
-- the primary key pair
nonce [1] INTEGER
-- binds reply to request
-- must be identical to the nonce
-- sent in the SignedAuthPack
}
KeyPack ::= SEQUENCE {
keyID [0] Checksum,
encPrivKey [1] OCTET STRING
}
Upon receipt of the reply, the client extracts the encrypted private
keys (and may store them, at the client's option). The primary
private key, which must be the first private key in the keyPack
SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
this key in turn is used to decrypt the main reply as described in
Section 3.2.
4. Logistics and Policy
The database record for Kerberos clients shall be modified to
include three additional flags in the attributes field.
The first flag, use_standard_pk_init, indicates that the user should
authenticate using standard PKINIT as described in Section 3.2. The
second flag, use_digital_signature, indicates that the user should
authenticate using digital signature PKINIT as described in Section
3.3. The third flag, store_private_key, indicates that the user
has stored his private key on the KDC and should retrieve it using
the exchange described in Section 3.4.
In the event that none of the preauthentication fields defined above
are included in the request, the KDC checks to see if any of the
above flags are set. If the first flag is set, then it sends back
an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
preauthentication field of type PA-PK-AS-REQ must be included in the
request.
Otherwise, if the first flag is clear, but the second flag is set,
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-AS-SIGN must
be included in the request.
Lastly, if the first two flags are clear, but the third flag is set,
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-KEY-REQ must
be included in the request.
If one of the preauthentication fields defined above is included in
the request, then the KDC shall respond as described in Sections 3.2
through 3.4. If more than one of the preauthentication fields is
present, the KDC shall respond with an error of type
KDC_ERR_PREAUTH_FAILED.
5. Dependence on Transport Mechanisms
Certificate chains can potentially grow quite large and span several
UDP packets; this in turn increases the probability that a Kerberos
message involving PKINIT extensions will be broken in transit. In
light of the possibility that the Kerberos specification will
allow TCP as a transport mechanism, we solicit discussion on whether
using PKINIT should encourage the use of TCP.
6. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
Transport Layer Security (TLS).
draft-ietf-tls-kerb-cipher-suites-00.txt
[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL
Protocol, Version 3.0 - IETF Draft.
[8] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993.
[9] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
7. Acknowledgements
Some of the ideas on which this proposal is based arose during
discussions over several years between members of the SAAG, the IETF
CAT working group, and the PSRG, regarding integration of Kerberos
and SPX. Some ideas have also been drawn from the DASS system.
These changes are by no means endorsed by these groups. This is an
attempt to revive some of the goals of those groups, and this
proposal approaches those goals primarily from the Kerberos
perspective. Lastly, comments from groups working on similar ideas
in DCE have been invaluable.
8. Expiration Date
This draft expires October 31, 1997.
9. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian, bcn} at isi.edu
John Wray
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA 01460
Phone: +1 508 486 5210
E-mail: wray at tuxedo.enet.dec.com
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road Suite 310
Issaquah WA 98027-5378
Phone: +1 206 391 6000
E-mail: {ari.medvinsky, matt.hur} at cybersafe.com
Jonathan Trostle
Novell Corporation
Provo UT
E-mail: jtrostle at novell.com
Received: from ietf.org by ietf.org id aa12644; 30 Apr 97 10:34 EDT
Received: from ietf.ietf.org by ietf.org id aa12401; 30 Apr 97 10:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-williamson-00.txt
Date: Wed, 30 Apr 1997 10:30:29 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704301030.aa12401 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Referral Whois (RWhois) Protocol V1.5
Author(s) : S. Williamson, M. Kosters, D. Blacka,
J. Singh, K. Zeilstra
Filename : draft-rfced-info-williamson-00.txt
Pages : 45
Date : 04/29/1997
This memo describes Version 1.5 of the client/server interaction of RWhois.
RWhois provides a distributed system for the discovery, retrieval, and
maintenance of directory information. This system is primarily hierarchical
by design. It allows for the deterministic routing of a query based on
hierarchical tags, referring the user closer to the maintainer of the
information. While RWhois can be considered a generic directory services
protocol, it distinguishes itself from other protocols by providing an
integrated, hierarchical architecture and query routing mechanism.
Internet-Drafts are 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-rfced-info-williamson-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-williamson-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-williamson-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970429144347.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-williamson-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-williamson-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970429144347.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12640; 30 Apr 97 10:34 EDT
Received: from ietf.ietf.org by ietf.org id aa11852; 30 Apr 97 10:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-engan-ip-compress-00.txt
Date: Wed, 30 Apr 1997 10:20:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704301020.aa11852 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IP Header Compression over PPP
Author(s) : M. Engan, S. Casner, C. Borman
Filename : draft-engan-ip-compress-00.txt
Pages : 11
Date : 04/29/1997
This document describes an option for negotiating the use of header
compression on IP datagrams transmitted over the Point-to-Point Protocol
[RFC1661]. It defines extensions to the PPP Control Protocols for IPv4 and
IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6
datagrams in combination with TCP, UDP and RTP transport protocols as
specified in [IPv6HC] and [CRTP].
Internet-Drafts are 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-engan-ip-compress-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-engan-ip-compress-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-engan-ip-compress-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970429160922.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-engan-ip-compress-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-engan-ip-compress-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970429160922.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12650; 30 Apr 97 10:34 EDT
Received: from ietf.ietf.org by ietf.org id aa11809; 30 Apr 97 10:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: rem-conf at es.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-avt-mpeg-new-00.txt
Date: Wed, 30 Apr 1997 10:19:54 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704301019.aa11809 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Audio/Video Transport
Working Group of the IETF.
Title : RTP Payload Format for MPEG1/MPEG2 Video
Author(s) : D. Hoffman, G. Fernando, V. Goyal, R. Civanlar
Filename : draft-ietf-avt-mpeg-new-00.txt
Pages : 15
Date : 04/29/1997
This memo describes a packetization scheme for MPEG video and audio
streams. The scheme proposed can be used to transport such a video or
audio flow over the transport protocols supported by RTP. Two approaches
are described. The first is designed to support maximum interoperability
with MPEG System environments. The second is designed to provide maximum
compatibility with other RTP-encapsulated media streams and future
conference control work of the IETF.
This memo is a revision of RFC 2038, an Internet standards track protocol,
prepared for publication as a revised RFC. In this revision, the packet
loss resiliance mechanisms in Section 3.4 were extended to include
additional picture header information required for MPEG2.
Internet-Drafts are 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-avt-mpeg-new-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-avt-mpeg-new-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-avt-mpeg-new-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970429143233.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-avt-mpeg-new-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-mpeg-new-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970429143233.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12649; 30 Apr 97 10:34 EDT
Received: from ietf.ietf.org by ietf.org id aa11916; 30 Apr 97 10:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-calendar at imc.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-calsch-ical-issues-01.txt
Date: Wed, 30 Apr 1997 10:20:38 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704301020.aa11916 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Calendaring and Scheduling
Working Group of the IETF.
Title : Core Object Specification - Issues Document
Author(s) : A. Ganguly, F. Dawson, D. Stenerson
Filename : draft-ietf-calsch-ical-issues-01.txt
Pages : 11
Date : 04/29/1997
This document is an IETF CALSCH working group document. The document is
used as a tool for recording issues and their resolution with mailing list
discussions.
This Issues Document is intended to track the resolution of issues related
to the "Core Object Specification" deliverable.
The most current version of this document can be found on the IETF CALSCH
Working Group document archive at http://www.imc.org.
Issues within this document are classified as either being OPEN or
RESOLVED. Additionally, an issue may be found to no longer be a concern and
may be classified as WITHDRAWN. Issues falling into each of these
categories are listed in a separate section.
An issue is documented with a short summary title, a brief description, and
a list of identified alternatives. A resolved issue will also include a
description of the resolution and the date/venue that the resolution was
reached.
Distribution of this document is unlimited.
Internet-Drafts are 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-calsch-ical-issues-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-ical-issues-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-calsch-ical-issues-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970430101301.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-calsch-ical-issues-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-calsch-ical-issues-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430101301.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12647; 30 Apr 97 10:34 EDT
Received: from ietf.ietf.org by ietf.org id aa12419; 30 Apr 97 10:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-livingston-00.txt
Date: Wed, 30 Apr 1997 10:30:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704301030.aa12419 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SNDM Protocol Specification
Author(s) : K. Dobbins, T. Grant, J. Livingston, D. Ruffen
Filename : draft-rfced-info-livingston-00.txt
Pages : 9
Date : 04/29/1997
The Switch Neighbor Discovery and Maintenance (SNDM) protocol is part of
the InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate
interswitch communication within distributed connection-oriented switching
networks. Switches use the SNDM protocol to discover their neighboring
switches and establish the topology of the switch fabric.
Internet-Drafts are 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-rfced-info-livingston-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-livingston-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-livingston-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970429144853.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-livingston-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-livingston-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970429144853.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12668; 30 Apr 97 10:34 EDT
Received: from ietf.ietf.org by ietf.org id aa11870; 30 Apr 97 10:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ospf at gated.cornell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ospf-version2-11.txt
Date: Wed, 30 Apr 1997 10:20:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704301020.aa11870 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Open Shortest Path First IGP
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : OSPF Version 2
Author(s) : J. Moy
Filename : draft-ietf-ospf-version2-11.txt
Pages : 220
Date : 04/29/1997
This memo documents version 2 of the OSPF protocol. OSPF is a link-state
routing protocol. It is designed to be run internal to a single Autonomous
System. Each OSPF router maintains an identical database describing the
Autonomous System's topology. From this database, a routing table is
calculated by constructing a shortest-path tree.
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of
routing protocol traffic. OSPF provides support for equal-cost multipath.
An area routing capability is provided, enabling an additional level of
routing protection and a reduction in routing protocol traffic. In
addition, all OSPF routing protocol exchanges are authenticated.
The differences between this memo and RFC 1583 are explained in
Appendix G. All differences are backward-compatible in nature.
Implementations of this memo and of RFC 1583 will interoperate.
Please send comments to ospf at gated.cornell.edu.
Internet-Drafts are 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-ospf-version2-11.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-version2-11.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ospf-version2-11.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970429145907.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-version2-11.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-version2-11.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970429145907.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa13792; 30 Apr 97 11:04 EDT
Received: from uscore-1.mv.com by CNRI.Reston.VA.US id aa12356;
30 Apr 97 11:04 EDT
Received: from localhost (daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA20487 for <ietf-archive at cnri.reston.va.us>; Wed, 30 Apr 1997 11:00:29 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Wed, 30 Apr 1997 10:55:26 -0400
Received: (from daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20174 for pwg-outgoing; Wed, 30 Apr 1997 10:50:49 -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: pwg at pwg.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: PWG> I-D ACTION:draft-ietf-printmib-job-monitor-00.txt
Date: Wed, 30 Apr 1997 10:19:49 -0400
Message-ID: <9704301019.aa11788 at ietf.org>
Sender: owner-pwg at pwg.org
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Printer MIB Working Group of
the IETF.
Title : Job Monitoring MIB - V0.81
Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis
Filename : draft-ietf-printmib-job-monitor-00.txt
Pages : 78
Date : 04/29/1997
This Internet-Draft specifies a set of 13 SNMP MIB objects for (1)
monitoring the status and progress of print jobs (2) obtaining resource
requirements before a job is processed, (3) monitoring resource consumption
while a job is being processed and (4) collecting resource accounting data
after the completion of a job. This MIB is intended to be implemented (1)
in a printer or (2) in a server that supports one or more printers. Use of
the object set is not limited to printing. However, support for services
other than printing is outside the scope of this Job Monitoring MIB.
Future extensions to this MIB may include, but are not limited to, fax
machines and scanners.
Internet-Drafts are 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-printmib-job-monitor-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-printmib-job-monitor-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970429141239.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-printmib-job-monitor-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-printmib-job-monitor-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970429141239.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa15040; 30 Apr 97 11:43 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13195;
30 Apr 97 11:43 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <NAA13823 at pad-thai.cam.ov.com>; Wed, 30 Apr 1997 13:48:34 GMT
Message-Id: <3367CBCC.15B at frcl.bull.fr>
Date: Wed, 30 Apr 1997 15:46:36 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: Mike Swift <mikesw at microsoft.com>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: SP-NEGO
References: <F0C5060A8699D011A2B100805F14C869829B64 at RED-75-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Mike Swift wrote:
> Looking at this latest draft the only major concern I have (so far) is
> the mechListMIC field. While it is more concise to just MIC the mech
> list, with commercial ASN1 compilers it is difficult to take a
> negotiation token and produce juse the mechanism list - usually you have
> to decode the token and re-encode just the mechanism list. I also think
> it would make more sense to compute a hash, such as MD5 or SHA-1, of the
When wanted the negotiation to be algorithm independent. None of the
negotiated algorithms may support MD5 or SHA. Also if the security of
MD5 is broken, we do not want to change anything.
Hence the support of *any* specific algorithm is not desirable.
We could keep in memory the whole token received and compute the MIC on
it, but I do not see a major advantage on this.
> whole initial token when it arrives and then compute a MIC of that hash.
> The advantages of this are (1) the SPNEGO code doesn't have to hang on
> to either the mech list or the initial token, and (2) the actual data
> MICd is fairly small.
>
> - Mike Swift
Regards,
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from cnri by ietf.org id aa16779; 30 Apr 97 12:43 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14582;
30 Apr 97 12:43 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA14482 at pad-thai.cam.ov.com>; Wed, 30 Apr 1997 14:03:48 GMT
Message-Id: <3367CFCC.1E6F at frcl.bull.fr>
Date: Wed, 30 Apr 1997 16:03:40 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: Mike Swift <mikesw at microsoft.com>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: SP-NEGO
References: <F0C5060A8699D011A2B100805F14C869844669 at RED-75-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Mike Swift wrote:
> There is another issues that the current draft doesn't address. The
> first is that the additional controls passed to init_sec_context (the
> req_flags parameter) are not used when negotiating - they only apply to
> the final mechanism used.
This is one possible interpretation; but since the document is silent on
this, multiple interpretations are possible (see later).
> This means that if a caller of SP-NEGO asks
> for a set of capabilities such as sequence detection and anonymous
> authentication they may end up with a mechanism that supports neither
> but was higher up the list of mech-types on the server. One possibility
> is to trim the list of mechanisms negotiated to only include those that
> support the requested attributes. This goes against the definition of
> those flags in the GSS-API spec, which states that the caller is
> responsible for checking the flags.
No. The caller sets the req_flags and is responsible for checking the
ret_flags. I do not see why the filtering cannot be done by the caller,
first.
> Another possibility would be to
> include the requested controls in the initial negotiation token to allow
> the server to do the filtering. This has the advantage that packages
> that don't support the requested controls may still be used but the
> server can try to accommodate the request.
The filtering has to be done by the server anyway. We would need to
include the req_flags in the token, in addition to the mech_list and
compute the MIC
on it, as well.
This would mean that the req_flags apply to the mechanism that will be
finally negotiated.
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from cnri by ietf.org id aa17999; 30 Apr 97 13:47 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16130;
30 Apr 97 13:47 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <QAA20487 at pad-thai.cam.ov.com>; Wed, 30 Apr 1997 16:31:20 GMT
Message-Id: <F0C5060A8699D011A2B100805F14C86985E90C at RED-75-MSG.dns.microsoft.com>
From: Mike Swift <mikesw at microsoft.com>
To: D.Pinkas at frcl.bull.fr
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: RE: SP-NEGO
Date: Wed, 30 Apr 1997 09:30:34 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.14)
Precedence: bulk
> -----Original Message-----
> From: Denis Pinkas [SMTP:D.Pinkas at frcl.bull.fr]
> Sent: Wednesday, April 30, 1997 4:04 PM
>
>
> No. The caller sets the req_flags and is responsible for checking the
> ret_flags. I do not see why the filtering cannot be done by the
> caller,
> first.
> [Mike Swift] I don't quite understand - how does the caller do the
> filtering first? If the client package filters out based on the flags
> then the negotation may fail because no packages that support all the
> requested flags are supported by the server. By having the server do
> the filtering it can do a best-effort by finding a package both client
> & server support that also supports the requested flags.
>
> > Another possibility would be to
> > include the requested controls in the initial negotiation token to
> allow
> > the server to do the filtering. This has the advantage that packages
> > that don't support the requested controls may still be used but the
> > server can try to accommodate the request.
>
> The filtering has to be done by the server anyway. We would need to
> include the req_flags in the token, in addition to the mech_list and
> compute the MIC
> on it, as well.
>
> [Mike Swift] This is exactly what I'm proposing. By including the
> flags in the initial token the server can choose which package best
> fits both its security needs and the requirements of the client.
> Currently the client can request certain capabilities but those have
> little bearing on the actual package chosen.
>
> This would mean that the req_flags apply to the mechanism that will be
> finally negotiated.
>
>
> Denis
>
>
> --
>
> Denis Pinkas Bull S.A. E-mail :
> D.Pinkas at frcl.bull.fr
> Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
> 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from cnri by ietf.org id aa19747; 30 Apr 97 14:55 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17482;
30 Apr 97 14:55 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <QAA21115 at pad-thai.cam.ov.com>; Wed, 30 Apr 1997 16:47:17 GMT
Message-Id: <3367F608.2129 at frcl.bull.fr>
Date: Wed, 30 Apr 1997 18:46:48 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: Mike Swift <mikesw at microsoft.com>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: SP-NEGO
References: <F0C5060A8699D011A2B100805F14C86985E90C at RED-75-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
>> I do not see why the filtering cannot be done by the caller, first.
[Mike Swift] I don't quite understand - how does the caller do the
filtering first? If the client package filters out based on the flags
then the negotation may fail because no packages that support all the
requested flags are supported by the server. By having the server do
the filtering it can do a best-effort by finding a package both client
& server support that also supports the requested flags.
I meant the caller implementation of the APIs. The caller's
implementation may simply suppress from the list the mechanisms that do
not support some requested flags since anyway they will be refused by
the server. Now this is may be over-optimisation since any way the
server will detect it.
[Mike Swift] This is exactly what I'm proposing.
So we both agree.
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from cnri by ietf.org id aa20821; 30 Apr 97 15:36 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18445;
30 Apr 97 15:36 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA22879 at pad-thai.cam.ov.com>; Wed, 30 Apr 1997 17:33:56 GMT
Message-Id: <199704301601.MAA15534 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: D.Pinkas at frcl.bull.fr
Cc: CAT-IETF WG <cat-ietf at mit.edu>, linn at cam.ov.com
Subject: Re: SP-NEGO
In-Reply-To: Your message of "Tue, 22 Apr 1997 16:54:44 PDT."
<335D4FC4.7E8 at frcl.bull.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 30 Apr 1997 12:01:41 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Here are some comments and questions on snego-04:
A fairly subtle point strikes me regarding the 4th paragraph on page
3. Consider the possibility that the target accepts the preferred
mechanism but does not perform optimistic negotiation so doesn't
process the enclosed preferredToken; such a target would respond with
a negResult of "accept" and a supportedMech indicating the preferred
mechanism. For the case of a preferred mechanism which (a) employs a
single-token context setup and (b) does not support the integrity
facility which would cause a mechListMIC to be generated and enclosed,
how does the initiator disambiguate whether such a reply constitutes
successfully completed context establishment or whether it must
instead resend (or regenerate) the mechanism's token for transfer in
what one might describe as "pessimistic fallback mode"?
p. 6, description of mechType, 2nd para: should cite definition of
extension as within "GSS-API mechanism specification" rather than
"GSS-API specification".
p. 6, description of negTokenInit: this refers to use of preferredToken
only within the first token sent. If initiators need to transfer
additional context tokens after the negotiation step, how is this
accomplished?
For encapsulated transfers of context tokens after the negotiation
step, are negResult and supportedMech required within their enclosing
NegTokenTargs?
Editorial notes:
Typos, p. 4, bullet (b): 1st line should be headed by "(b)", not "b)";
second line's "mechanism" should be plural.
Proposed clarification, p. 4, bullet (d), 4th para: "If a proposed
mechanism other than the preferred mechanism is accepted ..."
Proposed clarifications, p. 5, 1st full paragraph: "carries an accept
result" -> "carries an accept result and further tokens must be
transferred in order to complete context establishment for the
selected mechanism". 4th line: suggest adding, after "... as
output_token", "(with the selected mechanism's context token
encapsulated within that output_token)".
p. 5, 4th full para: "application may know" -> "application may need
to know".
--jl
Received: from ietf.org by ietf.org id aa22781; 30 Apr 97 16:47 EDT
Received: from zephyr.isi.edu by ietf.org id aa22561; 30 Apr 97 16:38 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA06813>; Wed, 30 Apr 1997 13:34:48 -0700
Message-Id: <199704302034.AA06813 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2135 on ISOC By-Laws
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 30 Apr 97 13:34:47 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2135:
Title: Internet Society By-Laws
Author: ISOC Board of Trustees
Date: April 1997
Mailbox: isoc-trustees at isoc.org
Pages: 9
Characters: 20467
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2135.txt
These are the by-laws of the Internet Society, as amended, as
of June 1996. They are published for the information of the
IETF community at the request of the poisson working group.
Please refer to the ISOC web page (www.isoc.org) for the
current version of the by-laws.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970430133038.RFC at ISI.EDU>
SEND /rfc/rfc2135.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2135.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970430133038.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26540; 30 Apr 97 20:09 EDT
Received: from borate.Stanford.EDU by ietf.org id aa26426; 30 Apr 97 20:05 EDT
Received: from borate.Stanford.EDU (macii-morgan.Stanford.EDU [36.53.0.167]) by borate.Stanford.EDU (8.8.5/8.7.3) with ESMTP id RAA21517 for <ietf at ietf.org>; Wed, 30 Apr 1997 17:01:42 -0700 (PDT)
Date: Wed, 30 Apr 1997 17:01:42 -0700
Sender:ietf-request at ietf.org
From: RL Bob Morgan <Bob.Morgan at stanford.edu>
Subject: report from IAB security workshop?
To: ietf at ietf.org
Message-ID: <Mailstrom_v2PT15.11126.4294964738.morgan at borate.stanford.edu>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I missed the IAB session in Memphis at which the recent IAB security
workshop was discussed. I understand there is to be a report published
about the workshop. Has it been published already? If not, is there
any summary of key points available?
Thanks,
- RL "Bob" Morgan
Stanford
Received: from ietf.org by ietf.org id aa27161; 30 Apr 97 20:37 EDT
Received: from lint.cisco.com by ietf.org id aa27018; 30 Apr 97 20:36 EDT
Received: from big-dawgs.cisco.com (herndon-dhcp-96.cisco.com [171.68.53.96]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id RAA29176; Wed, 30 Apr 1997 17:32:36 -0700 (PDT)
Message-Id: <3.0.1.32.19970430203234.006b9884 at lint.cisco.com>
X-Sender: pferguso at lint.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 30 Apr 1997 20:32:34 -0400
To: RL Bob Morgan <Bob.Morgan at stanford.edu>
Sender:ietf-request at ietf.org
From: Paul Ferguson <pferguso at cisco.com>
Subject: Re: report from IAB security workshop?
Cc: ietf at ietf.org
In-Reply-To: <Mailstrom_v2PT15.11126.4294964738.morgan at borate.stanford.e
du>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Bob,
I haven't seen a 'report', but you might want to ping
Steve Bellovin. According to the snippet in the minutes
for the March 11 IAB teleconference, Steve is handling
the preparation of the security workshop report.
ref: http://info.internet.isi.edu:80/IAB/IABmins.970311
- paul
At 05:01 PM 04/30/97 -0700, RL Bob Morgan wrote:
>
>I missed the IAB session in Memphis at which the recent IAB security
>workshop was discussed. I understand there is to be a report published
>about the workshop. Has it been published already? If not, is there
>any summary of key points available?
>
>Thanks,
>
> - RL "Bob" Morgan
> Stanford
>
Received: from ietf.org by ietf.org id aa00253; 30 Apr 97 22:37 EDT
Received: from zephyr.isi.edu by ietf.org id aa00135; 30 Apr 97 22:32 EDT
Received: from zen.isi.edu (zen-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA01503>; Wed, 30 Apr 1997 19:29:17 -0700
Date: Wed, 30 Apr 1997 19:29:17 -0700
Sender:ietf-request at ietf.org
From: postel at isi.edu
Posted-Date: Wed, 30 Apr 1997 19:29:17 -0700
Message-Id: <199705010229.AA23696 at zen.isi.edu>
Received: by zen.isi.edu (5.65c/4.0.3-6)
id <AA23696>; Wed, 30 Apr 1997 19:29:17 -0700
To: Bob.Morgan at stanford.edu
Subject: Re: report from IAB security workshop?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Bob:
See http://www.iab.org/iab/secrets.html
--jon.
Date: Wed, 30 Apr 1997 17:01:42 -0700
Sender: ietf-request at ietf.org
From: RL Bob Morgan <Bob.Morgan at stanford.edu>
Subject: report from IAB security workshop?
To: ietf at ietf.org
I missed the IAB session in Memphis at which the recent IAB security
workshop was discussed. I understand there is to be a report
published about the workshop. Has it been published already? If
not, is there any summary of key points available?
Thanks,
- RL "Bob" Morgan
Stanford
Received: from ietf.org by ietf.org id aa10912; 1 May 97 5:20 EDT
Received: from cnri by ietf.org id aa10820; 1 May 97 5:16 EDT
Received: from ng.netgate.net by CNRI.Reston.VA.US id aa06060; 1 May 97 5:16 EDT
Received: from [156.106.143.9] ([156.106.143.9])
by ng.netgate.net (8.8.5/8.8.5) with ESMTP id CAA13819;
Thu, 1 May 1997 02:08:58 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03102845af8dfef0c5cf at [156.106.143.9]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1 (Highest)
Date: Thu, 1 May 1997 10:59:33 +0200
To: com-priv at lists.psi.com
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: 80 Organizations Formally Declare Support for gTLD MoU
Cc:
Source-Info: From (or Sender) name not authenticated.
1 May 97, 10:00, GENEVA (Personal Comments):
After two days of intense, challenging, frank and open exchange
(and debate) we have just completed the formal signing ceremony for the
gTLD Memorandum of Understanding, as developed by the IAHC. At the
beginning of this conference, approximately 50 organizations had stated
their intent to sign. After the frank and open exchange, approximately 80
organization have signed.
Signatories come from all over globe and a wide range of
organizations and industries. The complete list will be posted shortly.
Many participants in the conference arrived with deep concerns
about the plan and the two days of discussion developed a very strong
consensus. It is uniformly agreed that the structure being put into place
is a beginning -- not an end -- of the development effort and will very
much be expected to evolve. By signing the Memorandum of Understanding,
organizations are stating their desire to participate in the creating the
evolution.
Signatories have the option of joining the Policy Advisory Body
(PAB) which is the portion of the gTLD structure intended to provide
broad-based community review and advise. Participants in the conference
developed a strong sense of concern and hope that the PAB would become
active and constructive in the process of gTLD evolution.
An example of the energy and commitment which was produced over the
course of the conference is the spontaneous decision to hold an immediate
meeting of those PAB members present, for the remainder of this morning.
As with all Internet-based bodies, formal and continued discussion with be
conducted over the net, with a PAB mailing list. The list will be
operational shortly.
Speaking personally, I would like to express my own, very deep
appreciation for both the seriousness of the concerns expressed and the
degree of the enthusiasm which developed over the course of the conference.
We have by no means resolved everyone's concerns but we have developed a
basis for pursuing them. This is a major achievement and it requires a
basic sense of personal ownership by each participant, for the tasks facing
us.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa12696; 1 May 97 7:25 EDT
Received: from mersey.hursley.ibm.com by ietf.org id aa12589; 1 May 97 7:19 EDT
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
id AA93711; Thu, 1 May 1997 12:15:33 +0100
Date: Thu, 1 May 1997 12:15:33 +0100
Message-Id: <9705011115.AA93711 at hursley.ibm.com>
Sender:ietf-request at ietf.org
From: "(Brian E Carpenter)" <brian at hursley.ibm.com>
Subject: Re: report from IAB security workshop?
To: Bob.Morgan at stanford.edu
Cc: ietf at ietf.org
In-Reply-To: <199705010229.AA23696 at zen.isi.edu> from "postel at isi.edu" at Apr 30, 97 07:29:17 pm
Reply-To: brian at hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 908
Source-Info: From (or Sender) name not authenticated.
And of course, the full workshop report and various other
documents will be published as Internet Drafts and hopefully
RFCs in due course... with the usual delay due to the
use of volunteer labour.
Brian Carpenter (IAB Chair)
>- postel at isi.edu said:
>
>
> Bob:
>
> See http://www.iab.org/iab/secrets.html
>
> --jon.
>
>
> Date: Wed, 30 Apr 1997 17:01:42 -0700
> Sender: ietf-request at ietf.org
> From: RL Bob Morgan <Bob.Morgan at stanford.edu>
> Subject: report from IAB security workshop?
> To: ietf at ietf.org
>
>
> I missed the IAB session in Memphis at which the recent IAB security
> workshop was discussed. I understand there is to be a report
> published about the workshop. Has it been published already? If
> not, is there any summary of key points available?
>
> Thanks,
>
> - RL "Bob" Morgan
> Stanford
>
>
>
>
>
Received: from ietf.org by ietf.org id aa15768; 1 May 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa15315; 1 May 97 9:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-mixer at innosoft.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mixer-bodymap-07.txt
Date: Thu, 01 May 1997 09:49:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705010949.aa15315 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME - X.400 Gateway Working
Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Mapping between X.400 and RFC-822/MIME Message Bodies
Author(s) : H. Alvestrand
Filename : draft-ietf-mixer-bodymap-07.txt
Pages : 56
Date : 04/30/1997
This document is a companion to [MIXER], which defines the principles
and translation of headers for interworking between MIME-based
RFC-822 mail and X.400 mail.
This document defines how to map body parts of X.400 messages into
MIME entities and vice versa, including the handling of
multipart messages and forwarded messages.
A table of contents that should be quite useful for locating specific
sections is given in the back of the document.
Internet-Drafts are 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-mixer-bodymap-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mixer-bodymap-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mixer-bodymap-07.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970430114908.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mixer-bodymap-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mixer-bodymap-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430114908.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15769; 1 May 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa15457; 1 May 97 9:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: ipsec-dev at terisa.com
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-simpson-ipsec-enhancement-01.txt
Date: Thu, 01 May 1997 09:50:15 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705010950.aa15457 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Security Transform Enhancements
Author(s) : W. Simpson, D. Wagner
Filename : draft-simpson-ipsec-enhancement-01.txt
Pages : 8
Date : 04/30/1997
This document describes several generic security transform enhancements
for the IP Security Protocols (AH and ESP).
Internet-Drafts are 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-simpson-ipsec-enhancement-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-ipsec-enhancement-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-simpson-ipsec-enhancement-01.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970430152135.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-simpson-ipsec-enhancement-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-simpson-ipsec-enhancement-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430152135.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15771; 1 May 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa15366; 1 May 97 9:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-dn-03.txt
Date: Thu, 01 May 1997 09:50:03 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705010950.aa15366 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names
Author(s) : M. Wahl, S. Kille, T. Howes
Filename : draft-ietf-asid-ldapv3-dn-03.txt
Pages : 7
Date : 04/30/1997
The X.500 Directory uses distinguished names as the primary keys to entries
in the directory. Distinguished Names are encoded in ASN.1 in the X.500
Directory protocols. In the Lightweight Directory Access Protocol, a
string representation of distinguished names is transferred. This
specification defines the string format for representing names, which is
designed to give a clean representation of commonly used distinguished
names, while being able to represent any distinguished name.
Internet-Drafts are 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-asid-ldapv3-dn-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-dn-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-dn-03.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970430120132.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-dn-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-dn-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430120132.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15767; 1 May 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa15279; 1 May 97 9:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: stdguide at midnight.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-stdguide-ops-03.txt
Date: Thu, 01 May 1997 09:49:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705010949.aa15279 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Guide for Internet Standards
Writers Working Group of the IETF.
Title : Guide for Internet Standards Writers
Author(s) : G. Scott
Filename : draft-ietf-stdguide-ops-03.txt
Pages : 20
Date : 04/30/1997
This document is a guide for Internet standard writers. It defines those
characteristics that make standards coherent, unambiguous, and easy to
interpret. Also, it singles out usage believed to have led to unclear
specifications, resulting in non-interoperable interpretations in the past.
These guidelines are to be used with RFC 1543, "Instructions to RFC
Authors."
This version of the document is a draft. It is intended to generate
further discussion and addition by the STDGUIDE working group. Please send
comments to stdguide at midnight.com.
Internet-Drafts are 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-stdguide-ops-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-stdguide-ops-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-stdguide-ops-03.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970430113008.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-stdguide-ops-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-stdguide-ops-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430113008.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15770; 1 May 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa15384; 1 May 97 9:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-stager-pdc-netapp-backup-02.txt
Date: Thu, 01 May 1997 09:50:07 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705010950.aa15384 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : PDC/NetApp Backup Protocol
Author(s) : R. Stager, D. Hitz
Filename : draft-stager-pdc-netapp-backup-02.txt
Pages : 76
Date : 04/30/1997
The Network Data Management Protocol ("NDMP") is an open protocol for
enterprise-wide network based backup. The NDMP architecture allows
network-attached file servers to ship with a "universal agent," which can
be used by any NDMP-compliant backup administration application. This same
universal agent architecture is also used for network-attached backup
devices, such as a tape drives and tape libraries.
Internet-Drafts are 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-stager-pdc-netapp-backup-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-stager-pdc-netapp-backup-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-stager-pdc-netapp-backup-02.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970430141338.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-stager-pdc-netapp-backup-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-stager-pdc-netapp-backup-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430141338.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15763; 1 May 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa15297; 1 May 97 9:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ids-ds-bcp-04.txt
Date: Thu, 01 May 1997 09:49:52 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705010949.aa15297 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Directory
Services Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Best Current Practice for the Internet White Pages
Service
Author(s) : H. Alvestrand, P. Jurg
Filename : draft-ietf-ids-ds-bcp-04.txt
Pages : 18
Date : 04/30/1997
The Internet is used for information exchange and communication between its
users. It can only be effective as such if users are able to find each
other's addresses. Therefore the Internet benefits from an adequate White
Pages Service, i.e., a directory service offering (Internet) address
information related to people and organizations.
Internet-Drafts are 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-ids-ds-bcp-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-ds-bcp-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ids-ds-bcp-04.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970430114617.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-ds-bcp-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-ds-bcp-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430114617.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15892; 1 May 97 9:55 EDT
Received: from ietf.ietf.org by ietf.org id aa15402; 1 May 97 9:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-gahrns-imap-namespace-00.txt
Date: Thu, 01 May 1997 09:50:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705010950.aa15402 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 Namespace
Author(s) : M. Gahrns, J. Myers, J. De Winter
Filename : draft-gahrns-imap-namespace-00.txt
Pages : 6
Date : 04/30/1997
IMAP4[RFC-2060] does not define a default mailbox namespace and hierarchy.
As such, server behavior regarding namespaces can differ, creating
difficulties for certain client operations.
This document defines a #personal namespace for identifying a user's
personal mailbox scope and a CANONICAL command that allows the
discovery of the preferred name of a mailbox within the server's
default mailbox hierarchy.
By using the #personal namespace, a client is able to automatically create
or access a mailbox without first configuring a server specific personal
mailbox prefix. For example, many clients often create at initial start up
time a "Sent Mail" or "Draft" mailbox.
In addition, the #personal mailbox namespace allows a client to present
a view to the user that is completely restricted to the user's personal
folders without displaying any shared mailboxes.
By using the CANONICAL command, a client is able to
determine where a mailbox exists in the server's entire default mailbox
hierarchy. Used in conjunction with #personal namespace, a graphical client
is able to display a server's entire default hierarchy, starting the
user at their personal space.
Internet-Drafts are 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-gahrns-imap-namespace-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-namespace-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-gahrns-imap-namespace-00.txt".
NOTE: The mail server at ds.internic.net 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.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970430150230.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-namespace-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gahrns-imap-namespace-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430150230.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16947; 1 May 97 10:15 EDT
Received: from ietf.ietf.org by ietf.org id aa16835; 1 May 97 10:14 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS to Proposed Standard
Date: Thu, 01 May 1997 10:14:08 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705011014.aa16835 at ietf.org>
The IESG has approved the Internet-Draft "MAILBOX NAMES FOR COMMON
SERVICES, ROLES AND FUNCTIONS" <draft-crocker-stdaddr-02.txt> as a
Proposed Standard. The IESG contact persons are Harald Alvestrand and
Keith Moore.
Technical Summary
This document attempts to build upon the success of the POSTMASTER
convention and make other standard addresses available like INFO,
ABUSE, NEWS and <listname>-REQUEST.
Working Group Summary
This document was not the product of a WG. There has been substantial
debate as a result of the Last Call; parts of it is documented on
http://www.apps.ietf.org/last-call/stdaddr.html
Protocol Quality
The document has been reviewed for the IESG by Harald Alvestrand
Received: from ietf.org by ietf.org id aa17127; 1 May 97 10:19 EDT
Received: from ietf.ietf.org by ietf.org id aa17059; 1 May 97 10:18 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: URN Syntax to Proposed Standard
Date: Thu, 01 May 1997 10:18:29 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705011018.aa17059 at ietf.org>
The IESG has approved the Internet-Draft "URN Syntax"
<draft-ietf-urn-syntax-04.txt> as a Proposed Standard. This document
is the product of the Uniform Resource Names Working Group. The IESG
contact persons are Keith Moore and Harald Alvestrand.
Technical Summary
Uniform Resource Names (URNs) are intended to serve as persistent,
location-independent, resource identifiers. This is in contrast
with Uniform Resource Locators (URLs) which typically have short
lifetimes and are tied to a particular resource location.
This document specifies the syntax to be used for URNs, the
requirements for transmission of URNs, and the use of the
URN syntax for both new and pre-existing namespaces.
The syntax described in this document is compatible with URL
syntax (for ease of adding URN support to applications which
already support URLs).
Working Group Summary
There has been considerable discussion in the working group,
regarding the compatibility of URNs with URLs (including the
notion of relative URNs) and the possible internationalization
of URNs. This document leaves relative URNs (with syntax
compatible with that of URLs) for future study, by reserving
the '/' character. Internationalization is also left undefined,
but this document specifies that URNs must be transmitted in
a pure-ASCII representation, and that all URN aware applications
must make URNs available for display in the pure-ASCII form
to enable reliable transcription by humans.
With these compromises, there is strong working group consensus
on the document.
Protocol Quality
Keith Moore reviewed the specification for IESG.
Received: from cnri by ietf.org id aa18898; 1 May 97 11:20 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa12648;
1 May 97 11:20 EDT
Received: (from daemon at localhost)
by services.bunyip.com (8.8.5/8.8.5) id LAA29739
for uri-out; Thu, 1 May 1997 11:02:08 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
by services.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA29733
for <uri at services.bunyip.com>; Thu, 1 May 1997 11:02:04 -0400 (EDT)
Received: from ncsa.uiuc.edu (sdgmail.ncsa.uiuc.edu [141.142.103.66])
by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA10648;
Thu, 1 May 1997 11:02:02 -0400 (EDT)
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id KAA10715; Thu, 1 May 1997 10:02:11 -0500 (CDT)
From: Daniel LaLiberte <liberte at ncsa.uiuc.edu>
Received: (from liberte at localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id KAA22206; Thu, 1 May 1997 10:01:58 -0500 (CDT)
Date: Thu, 1 May 1997 10:01:58 -0500 (CDT)
Message-Id: <199705011501.KAA22206 at void.ncsa.uiuc.edu>
To: "Ron Daniel, Jr." <rdaniel at lanl.gov>
Cc: URN Workgroup <urn-ietf at bunyip.com>, uri at bunyip.com
Subject: Re: [URN] About realtive URNs
In-Reply-To: <3.0.32.19970430160525.00999dc0 at cic-mail.lanl.gov>
References: <3.0.32.19970430160525.00999dc0 at cic-mail.lanl.gov>
Sender: owner-uri at bunyip.com
Precedence: bulk
Ron Daniel, Jr. writes:
> As several people on this list know, I'm not a big fan of relative
> URNs. However, I think they are pretty much unavoidable.
Your statement that relative URNs are unavoidable is news to me, and
I'm curious why you think that is so.
> There are about three conditions I would like to see fullfilled by
> any relative URN scheme.
> 1) Unambiguous determination of the base URN
No problem. This is well defined by the relative URI document with
the one clarification (that I mentioned previously) that the default
base URI for a document, if not specified by the document or the
delivery package of the document, is the last URI known by the client
in accessing the document, not the first URI.
This means that if the client uses a proxy is in resolving a URI and
the proxy receives a redirection to another URI, then the proxy must
return that redirection URI to the client whether or not the proxy also
follows the redirection to continue the resolution itself. I expect
that HTTP proxies behave this way already since redirections are
already in widespread use.
BTW, this same requirement is also important even if there are no
relative URNs. If a URN is redirected to a URL, and the URL is
resolved to a document containing relative URIs, then they are
relative to the URL (if the base is not otherwise specified), not the
URN.
> 2) Allowing some namespaces to say that they are not to be processed
> as relative URNs.
No problem. If naming authorities never use unencoded '/' in any
identifier that is registered, then there is never any chance of it
allowing relative URNs, is there?
> 3) Using the same rules for building relative URNs as are used for
> relative URLs. (This one is a pragmatic concern, not a principle).
Absolutely.
> I am not so sure how to handle relative URNs when the document does not
> cleary indicate one and only one base identifier. Dan has put up the
> rules for resolving relative URLs before, we need to make sure they
> will generalize to different protocols in the future. If we can't come
> up with rules that can guarantee unique base IDs, then we are
> begging for trouble with relative URNs.
I believe that the above clarification should be sufficient.
> Some namespaces may hide a hierarchical structure. If they are hiding it,
> we should not presume to make them expose it. I think that if we are to
> have relative URNs, some namespaces should be able to say not to ever
> try to build a URN in that namespace using relative processing rules.
> This means that they can't use unencoded '/' characters, and the document
> specifying such a namespace needs to say that they are not to be handled
> in a relative manner.
Actually, I think it might be possible to allow unencoded '/' in
identifiers without any implication of support for relative URIs. The
author of a document should know what base URI is intended to be used
with any relative URIs that the author puts in the document. Any
other relative URIs that are not "published" by the author would be
mere guesses on the part of users. Unless we require servers to
provide some non-trivial response to requests for any '/'-terminated
prefix of a URI, then there does not appear to be any requirement that
the existence of '/'s in an identifier means anything. The only
context in which '/' in an identifier means anything (currently) is if
the identifier is used as a base URI *and* there are relative URIs
that are relative to that base.
There might be another context in which '/' has meaning. Security
realms are relative to directories. So two URIs with the same
'/'-terminated prefix may be identifiers for resources contained in
the same security realm, and clients may cache security info relative
to that realm. I'm not clear on whether this is the case or where it
is specified.
As much as I've argued above that '/' doesn't mean much (currently),
I'd also argue that it should be reserved to mean only things relative
to hierarchical contexts.
--
Daniel LaLiberte (liberte at ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/
Received: from cnri by ietf.org id aa20402; 1 May 97 12:01 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa13163;
1 May 97 11:52 EDT
Received: (from daemon at localhost)
by services.bunyip.com (8.8.5/8.8.5) id LAA00968
for uri-out; Thu, 1 May 1997 11:34:36 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
by services.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA00960
for <uri at services.bunyip.com>; Thu, 1 May 1997 11:34:32 -0400 (EDT)
Received: from acl.lanl.gov (root at acl.lanl.gov [128.165.147.1])
by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA11115;
Thu, 1 May 1997 11:34:25 -0400 (EDT)
Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.8.5) with SMTP id JAA00702; Thu, 1 May 1997 09:34:22 -0600 (MDT)
Message-Id: <3.0.32.19970501093256.009c2970 at cic-mail.lanl.gov>
X-Sender: u114212 at cic-mail.lanl.gov
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 May 1997 09:33:05 -0600
To: Daniel LaLiberte <liberte at ncsa.uiuc.edu>
From: "Ron Daniel, Jr." <rdaniel at lanl.gov>
Subject: Re: [URN] About realtive URNs
Cc: URN Workgroup <urn-ietf at bunyip.com>, uri at bunyip.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-uri at bunyip.com
Precedence: bulk
At 10:01 AM 5/1/97 -0500, Daniel LaLiberte wrote:
>Ron Daniel, Jr. writes:
> > 1) Unambiguous determination of the base URN
>
>No problem.
I wish I shared your faith on this Dan. However, I'm uneasy about
it.
>the default
>base URI for a document, if not specified by the document or the
>delivery package of the document, is the last URI known by the client
>in accessing the document,
But this only works if resources that refer to each other using relative
links are migrated together. There are several reasonable scenarios where
this will not hold:
1) The owner of a set of such resources sells 1/2 of them to another
party, who takes charge of their storage. Now, 1/2 of the relative
links will have the wrong base if it is determined using the "last
URI known by the client" rule.
2) Automated replication mechanisms spring up, and the most popular
resource in an interlinked set gets widely replicated while less
frequently used ones are not replicated.
>If a URN is redirected to a URL, and the URL is
>resolved to a document containing relative URIs, then they are
>relative to the URL (if the base is not otherwise specified), not the
>URN.
Right, and this can break in the two scenarios I mentioned above.
I'm more in favor of explicit determination of the base URI, either
by the BASE tag in HTML or the "destination" field mentioned in the
message yesterday. But here I think we have to be very careful to
say that only one BASE tag is allowed. People may associate any
number of identifiers with a work, only one of which will make the
relative URNs function correctly.
Ron Daniel Jr. voice:+1 505 665 0597
Advanced Computing Lab fax:+1 505 665 4939
MS B287 email:rdaniel at lanl.gov
Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545
Received: from ietf.org by ietf.org id aa20544; 1 May 97 12:07 EDT
Received: from mailer.scri.fsu.edu by ietf.org id aa20437; 1 May 97 12:03 EDT
Received: from ibm8.scri.fsu.edu (ibm8.scri.fsu.edu [144.174.131.8]) by mailer.scri.fsu.edu (8.8.5/8.7.5) with SMTP id LAA06167 for <ietf at ietf.org>; Thu, 1 May 1997 11:59:45 -0400 (EDT)
Received: by ibm8.scri.fsu.edu (5.67b) id AA19787; Thu, 1 May 1997 11:59:44 -0400
Date: Thu, 1 May 1997 11:59:44 -0400
Message-Id: <199705011559.AA19787 at ibm8.scri.fsu.edu>
Sender:ietf-request at ietf.org
From: Dana Lutton <lutton at scri.fsu.edu>
To: ietf at ietf.org
Subject:
Source-Info: From (or Sender) name not authenticated.
Received: from ietf.org by ietf.org id aa24801; 1 May 97 14:30 EDT
Received: from aland.bbn.com by ietf.org id aa24663; 1 May 97 14:25 EDT
Received: (from craig at localhost) by aland.bbn.com (8.7.1/8.7.1) id LAA13054; Thu, 1 May 1997 11:22:12 -0700 (PDT)
Message-Id: <199705011822.LAA13054 at aland.bbn.com>
To: ietf at ietf.org
Subject: second Europe trip for IETFers...
Reply-To: Craig Partridge <craig at aland.bbn.com>
Sender:ietf-request at ietf.org
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 01 May 97 11:22:11 -0700
X-Orig-Sender: craig at aland.bbn.com
Source-Info: From (or Sender) name not authenticated.
As we all prepare to go to Munich in August, I just wanted to let folks know
that at least some IETFers are likely to want to go to SIGCOMM '97 in
Cannes, France in late September (and not just for the location:-)).
There are several papers that have relevance to IETF work:
* Two papers on improved route lookup algorithms. Both could make today's
routers substantially faster. One, the Lulea algorithm, has an amazingly
tight packing, such that you can fit all of today's Internet routing table
in about 100KB (a large CPU cache). The other, the WashU algorithm, has
a wonderful scaling property - it takes O(log w) lookups (where w is the
number of bits in an address) vs. O(w) for Patricia. The implication is
that an IPv6 address takes only 40% more time to lookup than an IPv4
address. Ditto a flow lookup.
* Two papers on Internet packet dynamics.
* A paper that demonstrates a way to do scalable secure multicasting
* A much better class of byte stuffing algorithms than have been used
before (especially useful in mobile networks, since this new class tightly
bounds the maximum amount a packet can be expanded -- thus increasing the
effective MTU on wireless links limited by FCC transmission time rules).
SIGCOMM '97 home page is http://www.inria.fr/rodeo/sigcomm97/
Complete registration info, etc., is not yet on-line last I checked
but will be shortly.
Craig
E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from ietf.org by ietf.org id aa25073; 1 May 97 14:38 EDT
Received: from zephyr.isi.edu by ietf.org id aa24991; 1 May 97 14:36 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA05710>; Thu, 1 May 1997 11:33:13 -0700
Message-Id: <199705011833.AA05710 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2134 on ISOC Articles of Incorporation
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 01 May 97 11:33:13 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2134:
Title: Articles of Incorporation of Internet Society
Author: ISOC Board of Trustees
Date: April 1997
Mailbox: isoc-trustees at isoc.org
Pages: 5
Characters: 9131
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2134.txt
These are the articles of incorporation of the Internet Society.
They are published for the information of the
IETF community at the request of the poisson working group.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970501113041.RFC at ISI.EDU>
SEND /rfc/rfc2134.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2134.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970501113041.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa25632; 1 May 97 14:54 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa09773;
1 May 97 14:54 EDT
Received: (from daemon at localhost)
by services.bunyip.com (8.8.5/8.8.5) id OAA04870
for uri-out; Thu, 1 May 1997 14:07:42 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
by services.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA04863
for <uri at services.bunyip.com>; Thu, 1 May 1997 14:07:37 -0400 (EDT)
Received: from ncsa.uiuc.edu (sdgmail.ncsa.uiuc.edu [141.142.103.66])
by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA12288;
Thu, 1 May 1997 14:07:34 -0400 (EDT)
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id NAA13025; Thu, 1 May 1997 13:07:44 -0500 (CDT)
From: Daniel LaLiberte <liberte at ncsa.uiuc.edu>
Received: (from liberte at localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id NAA23146; Thu, 1 May 1997 13:07:31 -0500 (CDT)
Date: Thu, 1 May 1997 13:07:31 -0500 (CDT)
Message-Id: <199705011807.NAA23146 at void.ncsa.uiuc.edu>
To: "Ron Daniel, Jr." <rdaniel at lanl.gov>
Cc: URN Workgroup <urn-ietf at bunyip.com>, uri at bunyip.com
Subject: Re: [URN] About realtive URNs
In-Reply-To: <3.0.32.19970501093256.009c2970 at cic-mail.lanl.gov>
References: <3.0.32.19970501093256.009c2970 at cic-mail.lanl.gov>
Sender: owner-uri at bunyip.com
Precedence: bulk
> > > 1) Unambiguous determination of the base URN
> >
> >No problem.
Ron Daniel, Jr. writes:
> I wish I shared your faith on this Dan. However, I'm uneasy about
> it.
There is not any problem (I am aware of) that is specific to URNs.
There are interesting problems having to do with splitting collections
and replication, as you mention. But these problems are orthogonal to
URNs. And there are solutions in any event.
> >the default
> >base URI for a document, if not specified by the document or the
> >delivery package of the document, is the last URI known by the client
> >in accessing the document,
>
> But this only works if resources that refer to each other using relative
> links are migrated together.
Indeed, relative URIs depend on being used in the context of their
base URI. This is an advantage if the relative URIs stay in
the correct context and a disadvantage if not. But all is not lost.
(And again, this is independent of URNs.)
> There are several reasonable scenarios where
> this will not hold:
> 1) The owner of a set of such resources sells 1/2 of them to another
> party, who takes charge of their storage. Now, 1/2 of the relative
> links will have the wrong base if it is determined using the "last
> URI known by the client" rule.
In the case of splitting resources that refer to each other by
relative URIs, it will be necessary to make some changes, not
necessarily to the documents themselves. We can change some of the
relative URIs into absolute URIs. Or we can designate one of the
locations of the split resources as the base for all the resources and
any requests for resources that are actually at another location will
get a redirect. (Each such redirect can be remembered by clients to
avoid returning to the base server each time a resource needs to
be requested.)
One must ask how likely it is that resources that refer to each other
by relative URIs will be split up. Relative URIs ought not be used
generally except when resources are likely to stay together.
> 2) Automated replication mechanisms spring up, and the most popular
> resource in an interlinked set gets widely replicated while less
> frequently used ones are not replicated.
The same kinds of solutions I described for the problem of splitting
resources can apply here too. Replicas of collections may be full or
partial, and the replicas should probably know which kind they are. A
partial replica probably needs to work via redirections from the full
base replica, whereas a full replica can let relative URIs use the
replica directly.
Another kind of solution is to dynamically, automatically rewrite
the appropriate relative URIs as the replica is created. Rewriting
is generally to be avoided though.
> >If a URN is redirected to a URL, and the URL is
> >resolved to a document containing relative URIs, then they are
> >relative to the URL (if the base is not otherwise specified), not the
> >URN.
>
> Right, and this can break in the two scenarios I mentioned above.
So you are really pointing out the problems of relative URIs. URNs
have nothing to do with it, once you have a way of deciding what the
base URI is.
> I'm more in favor of explicit determination of the base URI, either
> by the BASE tag in HTML or the "destination" field mentioned in the
> message yesterday.
Even a single explicit base URI is not sufficient if some of the relative
URIs in a document are relative to one base and some are relative to
another base. This occurs in the splitting and partial replica cases.
> But here I think we have to be very careful to
> say that only one BASE tag is allowed. People may associate any
> number of identifiers with a work, only one of which will make the
> relative URNs function correctly.
It is possible that muliple base URIs will in fact work
simultaneously. This will work as long as the neighborhoods of the
name spaces used by all the relative URIs are all the same.
Another kind of multiple base URI that I am interested in is nested
base URIs. For example, at the top level of a document one base URI
would apply. But in one particular section that uses lots of icons,
say, another base URI could be designated (e.g. /my/cool/icons).
Nested base URIs will be even more valuable when embedded documents
are supported. So the relative URIs in a document that is embedded in
another can be specified as relative to their own base URI. At every
point in the document, only one base URI applies, but it can be a
different base URI at each point.
Furthermore, while I'm at it, instead of only one base URI applying at
any one point in a document, I'd like to see multiple named base URIs
available simultaneously so that several contexts could be mixed.
And then there is the "root" which is always the same for documents on
a server. A relative URI starting with '/' is rooted relative to that
one server, and there is no way to specify a different root that might
be elsewhere. This would be useful when replicating a collection of
documents on another server but not relative to the same root. (One
might put each replica in a directory named after the server it came
from.) Or I might want to say that all the documents under
/groups/sdg/people/liberte/ are "rooted" at that prefix, so
'/resume.html' would be in that directory rather than all the way back
at the server root. This is much like the Unix chroot.
--
Daniel LaLiberte (liberte at ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/
Received: from ietf.org by ietf.org id aa26390; 1 May 97 15:10 EDT
Received: from cnri by ietf.org id aa26271; 1 May 97 15:09 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10359;
1 May 97 15:09 EDT
Received: from mailer.dir.org by venera.isi.edu (5.65c/5.61+local-27)
id <AA10009>; Thu, 1 May 1997 12:05:46 -0700
Received: from CISPPP by mailer.dir.org (8.6.12/8.6.9) with SMTP id NAA00450; Thu, 1 May 1997 13:39:20 -0400
Message-Id: <3368F0A6.41AF at dir.org>
Date: Thu, 01 May 1997 15:36:06 -0400
Sender:ietf-request at ietf.org
From: Press Office <press at dir.org>
Reply-To: press at dir.org
Organization: Directory Corporation
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: iar at helix.xiii.com, ibb at boursy.news.erols.com, ibm at svpal.svpal.org,
ic1 at fdma.fdma.com, icd at ionews.ionet.net, icm at news1.iamerica.net,
id7 at twwells.com, ietf at isi.edu, if3 at chronicle.concentric.net,
iff at grog.ric.edu, ifg at chronicle.concentric.net,
igeldard at capital.demon.co.uk, ihi at natasha.rmii.com,
iiiybrmahzewso at harding.demon.co.uk, iimagine at onramp.net,
ik2 at murrow.corp.sgi.com, il at taunivm.tau.ac.il, ilu at twwells.com,
ima at twwells.com, imalunatic at the.aslyum, in at individual.net,
inezewcm at ferjani.demon.co.uk, inf at iname.com, inkygrr at airmail.net,
inoctavo at mail.dotcom.fr, interest at relay.sgi.com, internet at munnari.oz.au,
ion at pacbell.net, ip3spwauwqkzewhj at harding.demon.co.uk,
ipf at newsops.execpc.com, ipsnake at redline.ru, ir0 at geolabserver.geo,
irelandurby1_7m8 at maestro.clari.net
Subject: Directory Corporation signs IAHC gTLD Geneva, May 1
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Source-Info: From (or Sender) name not authenticated.
YOUR READERS ARE INVITED TO JOIN THE CONTACTS DIRECTORY AT _NO_ CHARGE
The Directory Corporation is pleased to support proposals to expand the
global Top Level Domain Space.
Since the inception of the IAHC, officers from this organization have
participated in some of the many discussions, which have now been
concluded in this Memorandum of Understanding.
Mr John Harvey, Director of Online Information Services said "This
proposal to allows competing companies to register in Generic Top Level
Internet Domain names other than ".COM". The IAHC has moved quickly to
address the issues of expanding the Name Space and has formulated this
workable solution based on policies supported by internationally
recognized institutions.
To assist end-users identify the web sites of Domain Name owners in the
"expanded" DNS, it is important for customers to be able to use
non-discriminatory listing facilities, such as ours, as a "bridge"
between the various competing operators, domains and registries.
Like an internet phonebook accessible to all, the Contacts Directory
(http://www.dir.org) enables end-users to search for Email and web
addresses as well as fax, cellular, satellite, mobile, videoconferencing
telephone numbers for companies and individuals, at work and home. The
facility is free to search and Telcos and ISPs are charged a nominal fee
for their customers who submit details to the service. From the
operators perspective additional call revenue is generated and customer
satisfaction increased. All ISPs and their customers are invited to use
this world unique facility.
End users are in complete control of their communications accessibility.
They enter their own details to provide up-to-the-minute accuracy and
the level of privacy desired. As at April 28, the Contacts Directory
had received 741,039 voluntary entries. All companies and individulas
connectged to the Internet may submit their details for publication in
the Contacts Directory, free to end-users. As a promotional offer,
Telcos and ISPs will not be charged until 1 million entries have been
received.
Who is the Directory Corporation?
The Directory Corporation is a non-profit making international
organization, based in the Commonwealth of the Bahamas. As a developing
economy unattached to any of the main trading blocks, the Bahamas
provides an impartial environment in which to promote the
non-discriminatory exchange of information whilst having excellent
communication links with the North America, Europe and the Far East.
Questions may be addressed to John Harvey (John.Harvey at DIR.org) and
additional information is available from the Press Office
(press at dir.org).
The Directory Corporation.
Street Address:
Universal House,
Elizabeth Avenue,
Nassau.
Bahamas.
Postal Address:
P.O. Box N-3401
Fax:+1242 326 4105
Email: Press at dir.org
Received: from ietf.org by ietf.org id aa26391; 1 May 97 15:10 EDT
Received: from SYNW06.elettra.trieste.it by ietf.org id aa26232;
1 May 97 15:09 EDT
Date: Thu, 1 May 1997 21:05:48 +0200
To: ietf at ietf.org
CC: ALLOCCHIO at elettra.trieste.it
Message-Id: <970501210548.2020090f at elettra.trieste.it>
Sender:ietf-request at ietf.org
From: "Claudio Allocchio, +39 40 3758523" <Claudio.Allocchio at elettra.trieste.it>
Subject: Re: 80 Organizations Formally Declare Support for gTLD MoU
Source-Info: From (or Sender) name not authenticated.
For Your "complete" Information, also the position of one organization
which did not signed the MoU.
Regards
Claudio
--------------------- forwarded message -----------------------------
To: Christopher.Wilkinson at bxl.dg13.cec.be
Cc: k13 at nikhef.nl, Daniel.Karrenberg at ripe.net, tld-admin at ripe.net,
Claudio.Allocchio at elettra.trieste.it, S.Trumpy at cnuce.cnr.it,
D.Vannozzi at cnuce.cnr.it
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
From: (Vittore Casarosa) <casarosa at guest.cnuce.cnr.it>
Subject: Meeting at EU on IAHC proposal for new gTLDs
Dear Mr. Wilkinson
First of all, many thanks for the useful meeting, which stimulated a number
of comments and positions, most of which we do share.
In Italy, the administration of the .it TLD is done by two bodies. The
Naming Authority is a committee (called ITA-PE) formed by representatives
of public and private organizations (industry, university, research,
government) which sets the rules for the registration of domain names under
the .it TLD. The basic rule is that a domain name (and only one) can be
requested by any public or private organization which is legally
represented in Italy. The requestor is required to sign a letter stating
his responsibility for the correct usage of the assigned name, including
responsibilty for any trade mark infringement. These same rules are valid
also for registering names in the ISO X.400 domain, and the Registration
Authority acts also as the official registrar of the ISO domain. Steps are
under way to make the naming rules endorsed and published by UNI, which is
the Italian counterpart of ISO.
The Registration Authority is the Department for Telematics Application of
the CNUCE Institute (CNUCE is an institue of CNR - the National Research
Council) which performs all the technical steps needed for the
administration of the .it TLD, including a validity check of requests for
new domain names. Presently the registration of a domain name is free, but
in the future we expect to start charging a nominal annual fee to cover the
operational costs of the Registration Authority.
We are in agreement with the position that the administration of the
national TLDs is a national matter, but at the same time we believe that
the meeting at the EU revealed the need for a better coordination among the
registrars of the nTLD, at least at the European level. RIPE is a good
starting point, and we invite it to take actions, in concert with the EU,
to begin this coordination.
Another big point debated at the meeting was the position of the national
registrars vis--vis the proposed signing of the MoU and the establishment
of the POC. There is no need to sign any MoU now, and we are not
participating to the ITU meeting in Geneva. However we believe that the
IAHC proposal will go on, and a set of new commercial registrars will
administer the new gTLDs. That will soon establish a sort of de facto
standard which will be impossible to ignore on the part of the national
registrars, regardless of the signing of the MoU. Given the short time
available, it is not possible to come up with a firm alternative proposal
on the part of the EU (meaning here the set of European countries at
large). We recommend therefore to try and reach quickly a reasonable common
position and to take actions to make sure that Europe has its saying in the
implementation of the IAHC proposal, including the selection of registrars
and the definition of new TLDs.
The Italian Registration Authority is available to take part in any work
group and to work with RIPE and the EU in order to reach and bring forward
a common European position.
Best regards, Vittore Casarosa.
--------------------------------------------------------------------------
From: Vittore Casarosa E-mail: casarosa at guest.cnuce.cnr.it
CNR - CNUCE/RAT Phone : +39-50-593 325
36 Via Santa Maria Fax : +39-50-904 052
56126 PISA - ITALY Home : +39-50-372 69
Received: from ietf.org by ietf.org id aa02869; 1 May 97 21:09 EDT
Received: from toltec.cse.UCSC.EDU by ietf.org id aa02708; 1 May 97 20:59 EDT
Received: from toltec.cse.ucsc.edu (brad at localhost) by toltec.cse.ucsc.edu (8.6.9/8.6.9) with ESMTP id RAA04830 for <ietf at ietf.org>; Thu, 1 May 1997 17:56:10 -0700
Message-Id: <199705020056.RAA04830 at toltec.cse.ucsc.edu>
To: ietf at ietf.org
Subject: Re: Autonomous System Sanity Protocol
In-reply-to: Your message of "Tue, 29 Apr 1997 16:40:48 EDT."
<v03007812af8c0b384f4d at [128.89.0.110]>
Date: Thu, 01 May 1997 17:56:09 PDT
Sender:ietf-request at ietf.org
From: Brad Smith <brad at cse.ucsc.edu>
Source-Info: From (or Sender) name not authenticated.
Am just catching up with this thread, and have a couple of comments
to a few different points made so far....
** From Noel Chiappa...
> > use of public key cryptography can prevent anyone else from originating
> > bad information about connectivity inside or to X
>
> s/map/BGP route/g
> ... and everything you said still holds.
>
> No. There is a fundamental difference.
>
> If I'm X, I know, *authoritatively and definitively*, who is attached to me.
> I can then originate this information and sign it, in the form of map element
> information ("Hi, I'm X, and I'm attached to A, B and C, and here's the seal
> for that, encrypted with my private key".) You can use the concatentation of
> all such data (modulo, as I said, issues like people co-operating to lie
> about non-existent connections) to produce routing which is resistant to
> single-point failure and/or malice.
>
> However, in a destination vector system, such as BGP, X cannot know,
> authoritatively, the details of connectivity elsewhere. That means that Y can
> pass on to Z information about a route which Y has to X, and there is no way
> for X to sign *that* data, or even to verify that it is correct.
But if it's a valid route then X would have initiated it... at the
time it initiated it it could have signed it. Speaking very
simplisticly, since BGP already carries connectivity information in
the AS_PATH, X could sign the first link in that path, and these
signed parent links can be used to validate paths (remember, a tree is
fully defined by parent relationships, ref. "oriented trees" in Knuth
v.1, and shortest- path routing algorithms main function is to compute
shortest-path spanning trees). This is overly simplistic because
there is a subtle problem here w.r.t. the policy-based nature of links
in BGP. Specifically, a link only exists in the context of a given
destination... so these parent links can't be used to reconstruct
paths to arbitrary destinations in a BGP context. But this seems
resolvable, and, in any case, the general DV class of algorithms
should not be indicted (add the signed name of the second-to-last hop
and off you go... again, a little simplistic, but you get the idea).
> Please think about the issues some, and study Radia Perlman's PhD thesis,
> (where you will find it all laid out) before claiming that the two are
> equivalently protectable, when they are not.
I have, and I still make the claim (although "equivalently" is perhaps a
little stronger than I'd put it).
> Connectivity information is *fundamentally* different from *reachability*
> information.
But adequate connectivity information can easily be added to DV protocols
in the form of this parent information.
> I'm not sure that a change to distribution of maps .. vs. routing tables
> .. is necessary. ... One can imagine subsequent signing of data to
> represent authorization of a router or an AS to represent a poriton of
> the address space
>
> Ah. You've not seen the recent messages to Big-Internet, about how MD systems
> are probably a lot more workable at this than DV systems. Here's an excerpt:
>
> > In an MD system, you should only get updates from R1 when the
> > topology next to R1 changes (i.e. it's [connection to some other
> > router, or a piece of the nework, changes), and each topology change is
> > [this] *guaranteed* to send you only a small amount of data .. I.e. you
> > don't get all of whatever routing table entries have changed - which
> > could be a lot of data items, each one of which would have to be
> > checked, [as you would] in a DV system ..
> > You then use that, together with pre-checked data already in your map
> > (note this, you checked the correctness of that data in the past, when
> > you first got it, and don't have to do so again now), to do the
> > recomputation of all the routing table entries locally.
> > This is clearly much more tractable than applying PKS to a DV system,
> > where you'd have to check each routing table entry as it came in, which
> > could be rather painful after a topology change which caused lots of
> > routes to change.
>
> Routing table flaps are bad enough now - can you imagine what they'd look
> like if you have to check the signatures on *each* route as they came in?
This seems like a tradeoff between flooding a single link change to the
whole internet in MD (I assume this translates to link-state) vs
propagating a number of route updates to the affected subset of an internet
in DV. Something like how, on average, do the following two quantities
compare:
o number-of-nodes-affected * number-of-updates-generated (DV)
o number-of-nodes (MD)
This needs looking into, but it seems likely that each will have their
place.
> (Also, to be effective, you'd probably have to sign each step in the path
> vector, otherwise bad guy Z can take path X->Y->Z, strip off the last
> elements, and send out X->Z; this obviously makes even more work.)
Referring back to my first paragraph, this is not the case... just the first
hop should do it.
** From Steve Kent...
> There also was a paper (in SNDSS, this February) on how to authenticate DV
> updates, to provide multicast authentication of that data, on an
> incremental basis.
The points I raised above are what we presented in that paper.
> One aspect that has not been addressed in these
> previous activities is the authorization of a BGP speaker to advertise
> reachability info. This is the focus of the work we have just embarked
> upon. We are looking at both initial authorization for "ownership" of a
> portion of the address space, and for route advertisement authorization.
This is an excellent point, and it applies to both styles of protocol.
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
![http://www.winternet.com/~mackie/spam/images/spamcontrol.gif"=20](http://www.winternet.com/~mackie/spam/images/spamcontrol.gif"=20){kind=link}
![http://www.winternet.com/~mackie/spam/images/purpose.gif"=20](http://www.winternet.com/~mackie/spam/images/purpose.gif"=20){kind=link}
![http://www.winternet.com/~mackie/spam/images/banning_spam.gif"=20](http://www.winternet.com/~mackie/spam/images/banning_spam.gif"=20){kind=link}
![http://www.winternet.com/~mackie/spam/images/JunkMailContent.gif"](http://www.winternet.com/~mackie/spam/images/JunkMailContent.gif"){kind=link}
![http://www.winternet.com/~mackie/spam/images/CurrentFilters.gif"=20](http://www.winternet.com/~mackie/spam/images/CurrentFilters.gif"=20){kind=link}
![http://www.winternet.com/~mackie/spam/images/cooperationhappy.gif"=](http://www.winternet.com/~mackie/spam/images/cooperationhappy.gif"=){kind=link}
![http://www.winternet.com/~mackie/spam/images/message-tag.gif"=20](http://www.winternet.com/~mackie/spam/images/message-tag.gif"=20){kind=link}
![http://www.winternet.com/~mackie/spam/images/nt-traffic.gif"=20](http://www.winternet.com/~mackie/spam/images/nt-traffic.gif"=20){kind=link}
![http://www.winternet.com/~mackie/spam/images/downside.gif"=20](http://www.winternet.com/~mackie/spam/images/downside.gif"=20){kind=link}
![http://www.winternet.com/~mackie/spam/images/lastwords.gif"=20](http://www.winternet.com/~mackie/spam/images/lastwords.gif"=20){kind=link}