[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Brad Smith
Computer Sciences
UC Santa Cruz
brad at cs.ucsc.edu
Received: from ietf.org by ietf.org id aa13746; 2 May 97 2:32 EDT
Received: from ginger.lcs.mit.edu by ietf.org id aa13632; 2 May 97 2:28 EDT
Received: by ginger.lcs.mit.edu
id AA23044; Fri, 2 May 97 02:24:36 -0400
Date: Fri, 2 May 97 02:24:36 -0400
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9705020624.AA23044 at ginger.lcs.mit.edu>
To: brad at cse.ucsc.edu, ietf at ietf.org
Subject: Re: Autonomous System Sanity Protocol
Cc: jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
<My apologies the IETF list about the further inundation of routing
minutiae, but again, I don't want to leave incorrect statements
unanswered.>
From: Brad Smith <brad at cse.ucsc.edu>
> in a [DV] 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 [i.e. the element of the PV showing the Y->Z link]
> 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.
I don't see how that's different from what I said. X can certainly sign the
part of the path vector at the origin, but X usually *cannot* make any
statements about the correctness of the downstream links - "and there is no
way for X to sign *that* data, or even to verify that it is correct".
in any case, the general DV class of algorithms should not be indicted
DV path-selection algorithms are still inherently distributed, and such
algorithms are almost inherently less robust than non-distributed algorithms.
The correct operation of the algorithm is a whole is reliant on the correct
operation of all the components, and it only takes one mistake, or one
compromised participant, to produce problems.
Yes, you can augment DV system to construct a chain of signatures to make
sure that the data actually was passed along the path it says it came along,
and adding all this extra mechanism (and it's a lot of overhead, *especially*
if you want to protect against replays and/or stale data) will protect
against some classes of failures that we are currently vulnerable too.
However, the resulting system will still be vulnerable to various classes of
failure and/or attack - because of the distributed nature of the path
selection algorithm - which *is* fundamental to *all* DV algorithms.
> 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.
Apparently I didn't convey my point clearly. When I say "connectivity
information", I mean "information about what connectivity actually exists
between various entities" (i.e. information from an entity about what *that
entity* is connected to), and when I say "reachability information", I mean
"routing tables" (i.e. someone's assertion that they can reach a given
destination, and how).
The two are quite different, since the latter data is the output of a
distributed computation, in which you must, *by the very nature of the
algorithm*, trust that the entities doing the intermediate computations have
done so correctly. In general, you have no way of knowing whether or not
those intermediate computations were performed completely correctly or not.
In contrast, data about connectivity *cannot* be affected by intermediaries
who are either confused or malicious. One of two things will happen: you get
the data, and can verify (via the signature) that it's exactly as the source
originated it - or you do not have useable data - and you *always* know
*precisely* which case you are in.
MD (I assume this translates to link-state)
No. LS is a subset of MD (and one I don't like anything like as highly as I
like other kinds of MD systems). MD simply means that you distribute maps,
not routing tables - and I see this as the single most significant divide in
the universe of routing architectures. The second most significant is whether
paths are selected on a hop-by-hop basis, or whether they are specified over
longer sections of path by a single entity (called "explicit" or "unitary"
routing).
(You may call this "source routing", but I prefer not to use that term since
it brings along a number of unfortunate mental images to too many listeners,
e.g. that the source host has to be responsible for inserting a source
route in the packet - which is absolutely not so - and in fact, there are
unitary designs in which the packet *never* contains a source route.)
LS is a member of the MD/HbH quadrant, but there is a whole range of MD
designs which are not HbH.
This seems like a tradeoff between flooding a single link change to the
whole internet in MD
You seem to be operating under a false assumption. I don't know of any design
for using MD at the scale of the entire Internet which proposes to inform the
entire Internet of the change in a single link. The map will consist of a
hierarchy of abstractions, and this will allow the scope of topology changes
to be limited. (For a simpler version of this, look at OSPF, which does not
propogate link changes in a low-level area outside that area.)
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)
Your comparison is wrong. It should be:
o number-of-nodes-affected * number-of-updates-generated * path-length (DV)
o number-of-nodes-affected * 2 (MD)
Both have a "n-o-n-a" term since in both, the scope of updates is limited.
(Actually, since this cost also is distributed over the exact same number of
nodes, it should be dropped - it scales as O(1) in terms of the computation
cost at each node - who cares about the total cost for the system as a
whole.)
For the second term, on average, a single topology change will result in a
number of routes changing, but usually at most two updates in an MD system
(i.e. the case where a router-router link fails). This number can be quite
large for DV, in the hundreds or thousands in core routers, depending on
what happened.
As to the third term, this gets back to my point at the top - if you want to
make sure that bad paths are not being injected, you need to sign each step
in the path-vector. Thus, the number of signatures you have to check (and
this is likely to be the most computationally intensive part of the process)
scales as the average path lengh in DV - whereas in MD systems all you
*ever* have to check is the source's signature - scales as O(1).
> 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.
Perhaps we are not understanding each other, but I don't see where. If router
R1 is allowed to advertise network X, having R1 sign all routes to X which
start at it doesn't prevent all sorts of possible problems which can happen
downstream from R1.
E.g. if R1 passes a route to R2, which then passes it on to R3, etc, and
thence to R9, what's to stop R9 stripping out the R3-R8 elements in the path
vector and passing on a path vector which looks like X->R1->R2->R9? Since R1
has no knowledge of downstream connectivity from R2, it can't possibly sign
any of that stuff.
Yes, if you have each router sign for the next stage (which is how I
interpreted your first paragraph), you can prevent this kind of attack - but I
thought you were saying here ("just the first hop should do it") that you
didn't need to do that, only sign the first hop.
Noel
Received: from ietf.org by ietf.org id aa14221; 2 May 97 3:05 EDT
Received: from email.archlab.tuwien.ac.at by ietf.org id aa14141;
2 May 97 3:04 EDT
Received: by email.archlab.tuwien.ac.at (950413.SGI.8.6.12/940406.SGI.AUTO)
id IAA13237; Fri, 2 May 1997 08:59:09 +0200
Date: Fri, 2 May 1997 08:59:09 +0200 (MDT)
Sender:ietf-request at ietf.org
From: Sascha Ignjatovic <signato at email.archlab.tuwien.ac.at>
To: Dave Crocker <dcrocker at brandenburg.com>
cc: ietf at ietf.org
Subject: iahc
In-Reply-To: <v03102811af7a699d46c6 at [205.214.160.117]>
Message-ID: <Pine.SGI.3.91.970502085336.13221B-100000 at email.archlab.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
dear mr.ckrocker and other members of the iahc
just come from geneva iahc meeting back home and my first duty is to
please you to accept my humble respect and many thanks for the job you
and your colegues have done
i hope sam more qualifide person can glorify your work in a more
apropriate and proffesional way
thank you all very much
we will never forget
sascha
Received: from ietf.org by ietf.org id aa16288; 2 May 97 5:46 EDT
Received: from cache.lib.ITB.ac.id by ietf.org id aa16153; 2 May 97 5:41 EDT
Received: from cyberlib.itb.ac.id. (cyberlib.ITB.ac.id [167.205.57.97]) by cache.lib.itb.ac.id. (8.7.5/8.7.3) with SMTP id QAA22424 for <ietf at ietf.org>; Fri, 2 May 1997 16:40:03 GMT
Received: from CYBERLIB/MAILQ by cyberlib.itb.ac.id. (Mercury 1.11);
Fri, 2 May 97 16:41:49 +0700
Received: from MAILQ by CYBERLIB (Mercury 1.11); Fri, 2 May 97 16:41:31 +0700
Sender:ietf-request at ietf.org
From: Mohammad Riza <MOHAMMAD123 at cyberlib.itb.ac.id>
Organization: Computer Center ITB
To: ietf at ietf.org
Date: Fri, 2 May 1997 16:41:30 +07
Subject:
Priority: normal
X-mailer: Pegasus Mail v3.1 (R1a)
Message-ID: <653757334C at cyberlib.itb.ac.id.>
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa19365; 2 May 97 8:54 EDT
Received: from ietf.ietf.org by ietf.org id aa19185; 2 May 97 8:45 EDT
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: PPP Extensible Authentication Protocol (EAP) to
Proposed Standard
Reply-to: iesg at ietf.org
Date: Fri, 02 May 1997 08:45:40 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705020845.aa19185 at ietf.org>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "PPP Extensible Authentication
Protocol (EAP)" <draft-ietf-pppext-eap-auth-02.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 15, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa21122; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20299; 2 May 97 9: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-exp-rupp-00.txt
Date: Fri, 02 May 1997 09:30:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20299 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Protocol for the Transmission of Net News Articles
Author(s) : H. Rupp
Filename : draft-rfced-exp-rupp-00.txt
Pages : 8
Date : 05/01/1997
This protocol provides a way to use the IP multicast infrastructure to
transmit NetNews articles between news servers. Doing so will reduce the
bandwidth that is actually needed for transmission via NNTP. This does not
affect how news reading clients communicate with 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-rfced-exp-rupp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-exp-rupp-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-exp-rupp-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: <19970501144705.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-exp-rupp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-exp-rupp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501144705.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21133; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20257; 2 May 97 9: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-ballou-nntpsrch-03.txt
Date: Fri, 02 May 1997 09:30:31 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20257 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : NNTP Full-text Search Extension
Author(s) : N. Ballou, B. Hernacki, B. Polk
Filename : draft-ballou-nntpsrch-03.txt
Pages : 11
Date : 05/01/1997
This document describes a set of enhancements to the Network News
Transport Protocol [NNTP-977] that allows full-text searching of news
articles in multiple newsgroups. The proposed SEARCH command supports
functionality similar to the [IMAP4] SEARCH command, minus user specific
search keys (i.e., ANSWERED, DRAFT, FLAGGED, KEYWORD, NEW, OLD, RECENT,
SEEN) and minus search keys based on headers that do not exist in news
(i.e., CC, BCC, TO).
The availability of the extensions described here will be advertised
by the server using the extension negotiation-mechanism described
in the new NNTP protocol specification currently being developed [NNTP-NEW].
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-ballou-nntpsrch-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ballou-nntpsrch-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-ballou-nntpsrch-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: <19970501135456.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ballou-nntpsrch-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ballou-nntpsrch-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501135456.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21116; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20237; 2 May 97 9: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-thaler-dvmrp-mib-04.txt
Date: Fri, 02 May 1997 09:30:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20237 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Distance-Vector Multicast Routing Protocol MIB
Author(s) : D. Thaler
Filename : draft-thaler-dvmrp-mib-04.txt
Pages : 23
Date : 04/30/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
the Distance-Vector Multicast Routing Protocol (DVMRP) protocol [5,6].
This MIB module is applicable to IP multicast routers which implement
DVMRP.
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-thaler-dvmrp-mib-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-thaler-dvmrp-mib-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-thaler-dvmrp-mib-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: <19970430115843.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-thaler-dvmrp-mib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-thaler-dvmrp-mib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430115843.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21126; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20219; 2 May 97 9:30 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-referral-00.txt
Date: Fri, 02 May 1997 09:30:26 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20219 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 Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Referrals and Knowledge References in LDAP Directories
Author(s) : T. Howes, M. Wahl
Filename : draft-ietf-asid-ldapv3-referral-00.txt
Pages : 8
Date : 05/01/1997
This document defines a "ref" attribute and associated "referral" object
class for representing generic knowledge information in LDAP directories
[LDAP]. The attribute uses URIs [RFC1738] to represent knowledge, enabling
LDAP and non-LDAP services alike to be referenced. The object class can be
used to construct entries in an LDAP directory containing references to
other directories or services. This document also defines procedures
directory servers should follow when supporting these schema elements.
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-referral-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-referral-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-asid-ldapv3-referral-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: <19970501134609.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-referral-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-referral-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501134609.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21115; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20280; 2 May 97 9: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-evans-v2-scp-00.txt
Date: Fri, 02 May 1997 09:30:39 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20280 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Session Control Protocol V 2.0
Author(s) : K. Evans, J. Klein, J. Lyon, S. Spero
Filename : draft-evans-v2-scp-00.txt
Pages : 4
Date : 05/01/1997
This document describes version 2.0 of the Session Control Protocol
(SCP)[1]. SCP provides a simple mechanism for creating multiple lightweight
connections over a single TCP connection. Several such lightweight
connections can be active simultaneously. SCP provides a byte oriented
service, but allows message boundaries to be marked.
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-evans-v2-scp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-evans-v2-scp-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-evans-v2-scp-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: <19970501141545.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-evans-v2-scp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-evans-v2-scp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501141545.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21114; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20422; 2 May 97 9:31 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-opaque-01.txt
Date: Fri, 02 May 1997 09:30:36 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020931.aa20422 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.
Title : The OSPF Opaque LSA Option
Author(s) : R. Coltun
Filename : draft-ietf-ospf-opaque-01.txt
Pages : 13
Date : 05/01/1997
This memo documents enhancements to the OSPF protocol to support a new
class of link-state advertisements (LSA) called Opaque LSAs. The Opaque
LSA option defines a general mechanism to allow for future extensibility of
OSPF. The information contained in Opaque LSAs may be used directly by OSPF
or by other protocols. Opaque LSAs contain some number of octets padded to
32-bit alignment. The standard OSPF link-state database flooding
mechanisms are use for distribution of Opaque LSAs. Opaque LSAs are
flooded throughout all or some limited portion of the OSPF topology.
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-opaque-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-opaque-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-ospf-opaque-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: <19970501140217.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-opaque-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-opaque-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501140217.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21132; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20336; 2 May 97 9: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-maruyama-mapos-sonet-02.txt
Date: Fri, 02 May 1997 09:30:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20336 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-02.txt
Pages : 8
Date : 05/01/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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-maruyama-mapos-sonet-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-maruyama-mapos-sonet-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: <19970501145335.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-maruyama-mapos-sonet-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-maruyama-mapos-sonet-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501145335.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21129; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20318; 2 May 97 9: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-mitsuru-01.txt
Date: Fri, 02 May 1997 09:30:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20318 at ietf.org>
--NextPart
A Revised 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-01.txt
Pages : 21
Date : 05/01/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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-mitsuru-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-mitsuru-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: <19970501145126.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-mitsuru-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-mitsuru-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501145126.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21136; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20390; 2 May 97 9:31 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-01.txt
Date: Fri, 02 May 1997 09:30:59 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020931.aa20390 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPv4 over MAPOS Version 1
Author(s) : M. Maruyama, K. Murakami
Filename : draft-rfced-info-murakami-01.txt
Pages : 6
Date : 05/01/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-murakami-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-murakami-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-murakami-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: <19970501150308.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-murakami-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-murakami-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501150308.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21128; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20354; 2 May 97 9: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-maruyama-02.txt
Date: Fri, 02 May 1997 09:30:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20354 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPv4 over MAPOS Version 1
Author(s) : K. Murakami, M. Maruyama
Filename : draft-rfced-info-maruyama-02.txt
Pages : 6
Date : 05/01/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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-maruyama-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-rfced-info-maruyama-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: <19970501145634.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-maruyama-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-maruyama-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501145634.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21135; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20200; 2 May 97 9:30 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-iplpdn-frmib-dte-10.txt
Date: Fri, 02 May 1997 09:30:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020930.aa20200 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.
Note: This revision reflects comments received during the last call period.
Title : Management Information Base for Frame Relay DTEs
Author(s) : C. Brown, F. Baker
Filename : draft-ietf-iplpdn-frmib-dte-10.txt
Pages : 38
Date : 05/01/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing Frame Relay interfaces on DTEs.
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-iplpdn-frmib-dte-10.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-iplpdn-frmib-dte-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-ietf-iplpdn-frmib-dte-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: <19970501132838.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-iplpdn-frmib-dte-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iplpdn-frmib-dte-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501132838.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21123; 2 May 97 9:35 EDT
Received: from ietf.ietf.org by ietf.org id aa20410; 2 May 97 9:31 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-murakami2-00.txt
Date: Fri, 02 May 1997 09:31:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705020931.aa20410 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MAPOS 16 - Multiple Access Protocol over SONET/SDH
with 16 Bit Addressing
Author(s) : K. Murakami, M. Maruyama
Filename : draft-rfced-info-murakami2-00.txt
Pages : 6
Date : 05/01/1997
This document describes the protocol MAPOS 16, Multiple Access Protocol
over SONET/SDH with 16 Bit Addressing, for transmitting network-protocol
datagrams over SONET/SDH. The primary difference with MAPOS version 1 is
that it has 16 bit address field that offers significant wide address
space. It first describes the major differences between MAPOS and MAPOS 16
briefly. Then, it explains the header format and its 16 bit address format.
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-murakami2-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-murakami2-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-murakami2-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: <19970501162007.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-murakami2-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-murakami2-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501162007.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23589; 2 May 97 10:51 EDT
Received: from ietf.ietf.org by ietf.org id aa23388; 2 May 97 10:44 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-cast-128-cbc-00.txt
Date: Fri, 02 May 1997 10:44:57 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705021044.aa23388 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 CAST-128-CBC Algorithm
Author(s) : R. Pereira, G. Carter
Filename : draft-ietf-ipsec-esp-cast-128-cbc-00.txt
Pages : 5
Date : 05/01/1997
This draft describes the CAST-128 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-cast-128-cbc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-cast-128-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-cast-128-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: <19970501162454.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-cast-128-cbc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-esp-cast-128-cbc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970501162454.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa28118; 2 May 97 13:12 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15851;
2 May 97 13:12 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA29364 at pad-thai.cam.ov.com>; Fri, 2 May 1997 14:40:42 GMT
Message-Id: <199705021440.KAA21254 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: RFC2078bis: draft actions and issues
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 02 May 1997 10:40:33 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT/GSS-V2 fanciers:
Here's my long-awaited working document for preparation of RFC2078bis,
divided into two sections: (I) actions assumed agreed or
non-contentious and (II) issues warranting review or discussion. A
few points fold back with possible effect against cbind-04. Please
comment to the list (preferably opening descriptive sub-threads as
appropriate for easy sifting) if you believe that any pending actions
or issues are missing or miscategorized, or if you disagree with
actions proposed against any identified issues. Balancing the desire
for timely closure with the recognition that a list of this scope
requires non-trivial review time, I'd like to solicit any comments
within the next two weeks, i.e., NLT 16 May. Thanks.
I: ACTIONS ASSUMED AGAINST RFC-2078:
GENERAL:
Need to align RFC-2078bis to match C bindings by deleting
gss_release_oid(), gss_oid_to_str() and gss_str_to_oid() and removing
references to them.
State that zero-length tokens are never returned by GSS routines for
transfer to a peer, though it is possible for a zero-length object to
be passed by a caller into gss_wrap(), in which case the corresponding
peer calling gss_unwrap() will receive an empty object. Similarly,
it's presumably possible to call gss_getmic() on an empty object,
yielding a MIC which gss_verifymic() would successfully verify against
the context if it were also passed a zero-length object.
Align RFC-2078bis to match C bindings' text which, within descriptions
of routines returning dynamic data, discusses the circumstances under
which objects are returned and identifies which routine should be used
to free that data.
Add explicit statement that "release" routines may be omitted from
GSS-API implementations in environments where they are not required.
Clarify byte ordering in exported name object (sec. 3.2) to a
statement of big-endian / IP network byte order / most significant
byte first. Desirably, include concrete octet-level description and
example for exported name object.
For gss_delete_sec_context(), add explicit statement that routine can
support and should be used for, deletion of "half-built" security
contexts resulting from an incomplete sequence of context
establishment calls following an initial successful call to
gss_init_sec_context() or gss_accept_sec_context(), as well as for
deletion of fully-established contexts.
Add GSS_S_BAD_MIC as an alias for GSS_S_BAD_SIG.
Align gss_export_sec_context() discussion with cbind-04, by stating
(1) specifically that the context is deactivated from the viewpoint of
the calling process upon a successful export, and (2) regarding
behavior in case of errors in the course of a context export
operation.
For gss_import_sec_context(), clarify that the imported context is
usable for all per-message operations and may be deleted or exported
by its importer. The inability to receive delegated credentials
through gss_import_sec_context() precludes establishment of new
contexts based on information delegated to the importer's end system
within the context which is being imported, unless those delegated
credentials are obtained through separate routines (e.g., XGSS-API
calls) outside the GSS-V2 definition.
For gss_verify_mic(), reword reference to "confidentiality fields of
output qop_state", since no such fields or structure are globally
defined in a cross-mechanism fashion.
Fix formatting of comments in argument descriptions: should
consistently be set off with " -- ", not single hyphens.
Adapt cbind-04's Secs. 6.1, Delegation, and 6.6, Inter-Process Context
Transfer, as basis for new and corresponding subsections of Section
1.2, providing clarifying material alongside RFC-2078 discussions of
other context-level features.
Adapt intro text to cbind-04's Sec. 6 (Additional Controls), providing
clarifying material concerning support for optional services, into
Sec. 1.2.
CREDENTIAL-RELATED:
Re gss_release_cred() called with GSS_C_NO_CREDENTIAL, align with
cbind-04 by stating that this action, if requested, will complete
successfully but will have no other effect.
State that gss_inquire_cred() and gss_inquire_cred_by_mech() with
GSS_C_NO_CREDENTIAL queries default initiator creds.
In gss_add_cred(), align with C bindings description of behavior
when addition of elements to default credential is requested via
GSS_C_NO_CREDENTIAL input_cred_handle.
For gss_acquire_cred() and gss_add_cred(), adopt text from cbind-04's
description of gss_acquire_cred concerning behavior when GSS_C_NO_NAME
provided for desired_name. [ISSUE FOR CBIND: I believe that this
text (or suitable variant thereof) should appear under gss_add_cred()
as well as gss_acquire_cred(); as of cbind-04, there's no commentary
about gss_add_cred()'s behavior with this case.]
For gss_acquire_cred() and gss_add_cred(), add
GSS_S_CREDENTIALS_EXPIRED as returnable major_status.
Deprecate GSS_S_CREDENTIALS_EXPIRED returns from per-message calls,
and from context-level calls other than gss_init_sec_context() and
gss_accept_sec_context().
For gss_acquire_cred(), add GSS_S_NO_CRED as returnable major_status.
Upgrade recommendation in Section 1.1.1.3, concerning behavior for
default credential resolution, to status of requirement for initiator
credentials. GSS_S_NO_CRED to be returned if credentials can't
be resolved.
NAME-RELATED:
Align description of gss_inquire_mechs_for_name() with C bindings.
Remove GSS_S_BAD_NAMETYPE as return value from gss_duplicate_name(),
gss_display_name(). For gss_compare_name(), constrain description of
GSS_S_BAD_NAMETYPE return as being applicable only to attempted
comparisons between incomparable name types.
For gss_import_name() with GSS_C_NO_OID input_name_type, adopt
cbind statement that a mechanism-specific default printable syntax
for the associated name is used and state that GSS-V2 mechanism
specifications shall define the corresponding processing to
be performed by their mechanisms.
In gss_canonicalize_name(), include text similar to that included
for gss_duplicate_name() about the fact that the name is duplicated
and then the duplicate is reduced to the MN without impact on the
already existing input_name.
Per Sec. 4.1, change reference to use of DNS lookup as means for name
canonicalization from definitional to example.
Adapt text from 2 paragraphs in cbind-04, p. 16, regarding use and
semantics of name comparisons with exported name objects, into
Sec. 1.1.5 (Naming).
NEGOTIATION-RELATED:
Incorporate a general statement about the distinction between
negotiating and non-negotiating mechanisms, and the properties of
each. State that applications requesting a specific mechanism shall
not receive another mechanism unless the definition of the mechanism
specified indicates that it is a negotiating mechanism. (See also
Martin Rex 19 Mar 97 msg)
II: RESIDUAL ISSUES, DISTILLED:
GENERAL ISSUES:
Expand HL discussion of gss_display_status(), based on C bindings?
The message_context() facility to iteratively return multiple status
indicators doesn't appear in the HL spec at all. Should it? Martin
Rex suggested (29 Jan 97) that it should, at least eventually.
[PROPOSED ACTION: Leave RFC-2078 as is; another set of bindings for a
different environment could plausibly return all translatable
major_status or minor_status error information for a call within a
single operation.]
Per gss_accept_sec_context(), discussion (initiated 26 Mar 97, Marc
Horowitz) about inability upon gss_accept_sec_context() error to
ascertain OID of relevant mechanism, as needed to perform minor_status
translation with gss_display_status(). Suggestion to allow emitted
mech_type return to be valid before GSS_S_COMPLETE, and to change upon
successive calls for the negotiation mechanism case. (Note: the same
rationale presumably applies to gss_init_sec_context() as well?)
[PROPOSED ACTION: Allow, but do not require, that implementations
return mech_type values before GSS_S_COMPLETE.]
CREDENTIAL-RELATED ISSUES:
For both gss_acquire_cred() and gss_add_cred(), describe GSS_S_NO_CRED
as the appropriate error to return on temporary, user-fixable
credential unavailability conditions, per Martin Rex 6 Dec 96 mail?
[PROPOSED ACTION: Seems reasonable to me, but couldn't locate any
follow-up discussion. Review solicited.]
Upgrade recommendation in Section 1.1.1.3, concerning behavior for
default credential resolution, to status of requirement for acceptor
credentials? GSS_S_NO_CRED would be returned if credentials can't be
resolved. [PROPOSED ACTION: Discussion needed.]
For gss_acquire_cred() and gss_add_cred(), align with cbind-04
statement of likely non-support for INITIATE and BOTH credentials if a
non-empty name is specified? Martin Rex objects (28 Apr 97,
reiterating earlier comment) to cbind-04 statement, recommends
requiring same scope of function as gss_init_sec_context() and
gss_accept_sec_context() provide with GSS_C_NO_CREDENTIAL. [PROPOSED
ACTION: I also believe that, at a minimum, an explicit specification
of the same name which would result from inquiring against the default
credential should be acceptable, and would like to specifically allow
this.]
Transfer of delegated credentials via gss_export_sec_context(); access
to delegated credentials by gss_import_sec_context() caller? [PROPOSED
ACTION: This issue has been recognized for some time; assumed plan is
to defer beyond GSS-V2.]
NAME-RELATED ISSUES:
Should UID name forms be indicated as optional and possibly
environment-dependent, as they had been in RFC-1964? Should their
descriptions be revised, and, if so, how? [PROPOSED ACTION: State as
optional and environment-dependent. Leave descriptions as is.]
Should user name form be indicated as optional and possibly
environment-dependent, as it had been in RFC-1964? Should its
description be revised, and, if so, how? [PROPOSED ACTION: State as
optional and environment-dependent. Leave description as is.]
Should Host-Based Service name form be stated as mandatory for the
Internet environment? (Ted Ts'o recommends, 9 Apr 97) [PROPOSED
ACTION: Discussion needed; absent follow-up, add no specific
statement re mandatory vs. optional.]
Per late March-early April discussion, is it feasible or appropriate
to define and adopt a generic "distributed user name" type? [PROPOSED
ACTION: Add no new type at this time; consensus not apparent.]
Allow GSS_S_NAME_NOT_MN as optional return value from
gss_compare_name(), per 2 Apr 97 mail? [PROPOSED ACTION: Do not
incorporate: return of this GSS-V2 major_status code could confuse
GSS-V1 callers.]
NEGOTIATION-RELATED ISSUES:
Attempt any treatment of the "mechanism family" concept at this time?
List discussion on 19 March proposed the concept of mechanism families
with multiple individual OIDs, each of which can support the same name
types. See also Martin Rex questions re gss_canonicalize_name(), 3
Apr 97, and follow-up discussion. [PROPOSED ACTION: Defer beyond
GSS-V2.]
ISSUES RE STATUS VALUES AND OPERATIONAL BEHAVIOR:
Can we tighten any requirements statements per Martin Rex's 14 Mar
query about required/optional/etc, and follow-up correspondence?
[PROPOSED ACTION: Many, but not all, of the points raised in this
message appear in this listing as separate actions or issues, and some
of the points raised may have answers which are mechanism-specific,
and comprehensive follow-up about requirements levels was not
apparent. I propose, therefore, not to make text changes in response
to the cited message unless further discussion ensues; additional
issues or actions can be opened subsequently as dictated by
discussion.]
Page 22 of cbind-04, re GSS_S_DUPLICATE_TOKEN, states that the status
may be returned for some cases even if replay detection isn't being
provided; this diverges from RFC-2078. John Linn and Ted Ts'o suggest
that cbind should align with GSS-V1 and RFC-2078, precluding this
prospect. [PROPOSED ACTION: No change to RFC-2078, anticipating
possible alignment by C bindings.]
--jl
Received: from ietf.org by ietf.org id aa29384; 2 May 97 14:11 EDT
Received: from ietf.ietf.org by ietf.org id aa29221; 2 May 97 14:06 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: namedroppers at internic.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-eastlake-kitchen-sink-02.txt
Date: Fri, 02 May 1997 14:06:31 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705021406.aa29221 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 DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : The Kitchen Sink Resource Record
Author(s) : D. Eastlake
Filename : draft-eastlake-kitchen-sink-02.txt
Pages : 9
Date : 04/28/1997
Periodically people are seized with a desire to put complex, bulky, and/or
obscurely structured data into the Domain Name System (DNS). This draft
defines a kitchen sink Resource Record that will satisfy this lust by
defining a new DNS resource record for the storage of miscellaneous
structured information.
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-eastlake-kitchen-sink-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-eastlake-kitchen-sink-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-eastlake-kitchen-sink-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: <19970502140549.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-eastlake-kitchen-sink-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-eastlake-kitchen-sink-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502140549.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07540; 2 May 97 18:42 EDT
Received: from aland.bbn.com by ietf.org id aa07339; 2 May 97 18:33 EDT
Received: (from craig at localhost) by aland.bbn.com (8.7.1/8.7.1) id PAA14966; Fri, 2 May 1997 15:29:21 -0700 (PDT)
Message-Id: <199705022229.PAA14966 at aland.bbn.com>
To: ietf at ietf.org
Subject: where is Munich Hotel
Reply-To: Craig Partridge <craig at aland.bbn.com>
Sender:ietf-request at ietf.org
From: Craig Partridge <craig at aland.bbn.com>
Date: Fri, 02 May 97 15:29:21 -0700
X-Orig-Sender: craig at aland.bbn.com
Source-Info: From (or Sender) name not authenticated.
Hi folks:
The maps of Munich in the Michelin red guide don't list the street the
Munich hotel is on. Can anyone describe roughly where the hotel is in town
vis-a-vis some major landmark? (Given the main hotel is largely full, I
figured I'd find a nice hotel in the Michelin guide that is reasonably nearby)?
Thanks!
Craig
E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from ietf.org by ietf.org id aa13677; 2 May 97 22:49 EDT
Received: from bolero.rahul.net by ietf.org id aa13564; 2 May 97 22:42 EDT
Received: from waltz.rahul.net by bolero.rahul.net with SMTP id AA09719
(5.67b8/IDA-1.5 for <ietf at ietf.org>); Fri, 2 May 1997 19:39:22 -0700
Sender:ietf-request at ietf.org
From: Wolfgang Henke <wolfgang at whnet.com>
Received: by waltz.rahul.net (5.67b8/jive-a2i-1.0)
id AA00189; Fri, 2 May 1997 19:39:21 -0700
Message-Id: <199705030239.AA00189 at waltz.rahul.net>
Subject: Re: where is Munich Hotel
To: craig at aland.bbn.com
Date: Fri, 2 May 1997 19:39:21 -0700 (PDT)
Cc: ietf at ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 251
Source-Info: From (or Sender) name not authenticated.
The Sheraton is a bit north of the Muenchener Freiheit close to
the Englischer Garden. Not particularly favored by locals.
If BBN picks up the tap try Hotel Vier Jahreszeiten close to
the opera. The underground U-Bahn is clean and fast.
Wolfgang
Received: from ietf.org by ietf.org id aa22261; 3 May 97 3:18 EDT
Received: from cnefw.nctsl.navy.mil by ietf.org id aa22104; 3 May 97 3:13 EDT
Received: by cnefw1.nctsl.navy.mil; id AA100712422; Sat, 3 May 1997 07:53:42 +0100
Received: from unknown(198.17.81.181) by cnefw.nctsl.navy.mil via smap (V3.1.1)
id xma010060; Sat, 3 May 97 07:53:22 +0100
Received: by 29BLLNT with Microsoft Mail
id <01BC5712.98EFA000 at 29BLLNT>; Fri, 2 May 1997 16:05:04 +0100
Message-Id: <01BC5712.98EFA000 at 29BLLNT>
Sender:ietf-request at ietf.org
From: Paul Powenski <powenski at post1.nctsl.navy.mil>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject:
Date: Fri, 2 May 1997 16:05:03 +0100
Return-Receipt-To: <powenski at post1.nctsl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa28370; 3 May 97 11:48 EDT
Received: from ftp.com by ietf.org id aa28199; 3 May 97 11:36 EDT
Received: from ftp.com by ftp.com ; Sat, 3 May 1997 11:32:40 -0400
Received: from mailserv-2high-a.ftp.com by ftp.com ; Sat, 3 May 1997 11:32:40 -0400
Received: by MAILSERV-2HIGH-A.FTP.COM (SMI-8.6/SMI-SVR4)
id LAA04610; Sat, 3 May 1997 11:34:14 -0400
Date: Sat, 3 May 1997 11:34:14 -0400
Message-Id: <199705031534.LAA04610 at MAILSERV-2HIGH-A.FTP.COM>
To: Craig Partridge <craig at aland.bbn.com>
Subject: Re: where is Munich Hotel
Sender:ietf-request at ietf.org
From: Frank Kastenholz <kasten at ftp.com>
Reply-To: kasten at ftp.com
Cc: ietf at ietf.org
X-Orig-Sender: kasten at mailserv-2high-a.ftp.com
Repository: mailserv-2high-a.ftp.com, [message accepted at Sat May 3 11:34:06 1997]
Originating-Client: resource
Source-Info: From (or Sender) name not authenticated.
My (10 year old) map has the Shearaton on Arabellastrasse on the east
side of the Isar, roughly at the intersection of Isar Ring Strasse
and Effner Strasse -- it looks like the intersection is called
Effnerplatz (and it seems that Isarring Str. turns into Richard
Strauss Str there.
It looks like the neighborhood's name is Bogenhausen
> The maps of Munich in the Michelin red guide don't list the street the
> Munich hotel is on. Can anyone describe roughly where the hotel is in town
> vis-a-vis some major landmark? (Given the main hotel is largely full, I
> figured I'd find a nice hotel in the Michelin guide that is reasonably nearby)?
>
> Thanks!
>
> Craig
>
> E-mail: craig at aland.bbn.com or craig at bbn.com
--
Frank Kastenholz
Received: from ietf.org by ietf.org id aa05207; 3 May 97 20:14 EDT
Received: from toltec.cse.UCSC.EDU by ietf.org id aa05066; 3 May 97 20:06 EDT
Received: from toltec.cse.ucsc.edu (brad at localhost) by toltec.cse.ucsc.edu (8.6.9/8.6.9) with ESMTP id RAA05625; Sat, 3 May 1997 17:02:52 -0700
Message-Id: <199705040002.RAA05625 at toltec.cse.ucsc.edu>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
cc: ietf at ietf.org
Subject: Re: Autonomous System Sanity Protocol
In-reply-to: Your message of "Fri, 02 May 1997 02:24:36 EDT."
<9705020624.AA23044 at ginger.lcs.mit.edu>
Date: Sat, 03 May 1997 17:02:50 PDT
Sender:ietf-request at ietf.org
From: Brad Smith <brad at cse.ucsc.edu>
Source-Info: From (or Sender) name not authenticated.
> <My apologies the IETF list about the further inundation of routing
> minutiae, ...
Agreed... I'll take this off-line. If others are interested, let me
know.
Brad
Received: from cnri by ietf.org id aa29069; 4 May 97 20:46 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18962;
4 May 97 20:46 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA21911 at pad-thai.cam.ov.com>; Sun, 4 May 1997 23:08:08 GMT
To: cat-ietf at mit.edu
Subject: scope: HL vs ANSI C bindings
From: Marc Horowitz <marc at cygnus.com>
Date: 04 May 1997 19:08:04 -0400
Message-Id: <t53enbmbzu3.fsf at rover.cygnus.com>
Lines: 15
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
There are long discussions in the C bindings document about the
semantics of gssapi. These discussions are useful, but in general
they are either redundant with the HL spec, which will cause trouble
when they drift apart, or they are missing from the HL spec, and
should be moved there. It seems that the C bindings document should
be essentially a mapping of C onto the high-level spec. I figure
about 90% of this can be accomplished by a header file annotated by
references to the HL spec. The other 10% is C-specific details, such
as the iterative approach to gss_display_name and example code for
init and accept_sec_context.
I'd like to see the C bindings mostly gutted, and the stuff which
isn't redundant rolled into rfc2078.
Marc
Received: from cnri by ietf.org id aa29768; 4 May 97 21:36 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19594;
4 May 97 21:36 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA21518 at pad-thai.cam.ov.com>; Sun, 4 May 1997 22:55:41 GMT
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu
Subject: Re: RFC2078bis: draft actions and issues
References: <199705021440.KAA21254 at gza-client1.cam.ov.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 04 May 1997 18:54:59 -0400
In-Reply-To: John Linn's message of Fri, 02 May 1997 10:40:33 -0400
Message-Id: <t53g1w2c0fw.fsf at rover.cygnus.com>
Lines: 87
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
John Linn <linn at cam.ov.com> writes:
>> I: ACTIONS ASSUMED AGAINST RFC-2078:
All this looks fine to me.
>> II: RESIDUAL ISSUES, DISTILLED:
>>
>> GENERAL ISSUES:
>>
>> Expand HL discussion of gss_display_status(), based on C bindings?
>> The message_context() facility to iteratively return multiple status
>> indicators doesn't appear in the HL spec at all. Should it? Martin
>> Rex suggested (29 Jan 97) that it should, at least eventually.
>> [PROPOSED ACTION: Leave RFC-2078 as is; another set of bindings for a
>> different environment could plausibly return all translatable
>> major_status or minor_status error information for a call within a
>> single operation.]
I think it would be reasonable to state in the HL spec that particular
languages may choose to use an iterative approach, but not to describe
any particular approach.
>> Per gss_accept_sec_context(), discussion (initiated 26 Mar 97, Marc
>> Horowitz) about inability upon gss_accept_sec_context() error to
>> ascertain OID of relevant mechanism, as needed to perform minor_status
>> translation with gss_display_status(). Suggestion to allow emitted
>> mech_type return to be valid before GSS_S_COMPLETE, and to change upon
>> successive calls for the negotiation mechanism case. (Note: the same
>> rationale presumably applies to gss_init_sec_context() as well?)
I think so.
>> [PROPOSED ACTION: Allow, but do not require, that implementations
>> return mech_type values before GSS_S_COMPLETE.]
In a perfect world, I would require this, but for compatibility with
existing mechanisms, just recommending it seems best.
>> CREDENTIAL-RELATED ISSUES:
>>
>> For both gss_acquire_cred() and gss_add_cred(), describe GSS_S_NO_CRED
>> as the appropriate error to return on temporary, user-fixable
>> credential unavailability conditions, per Martin Rex 6 Dec 96 mail?
>> [PROPOSED ACTION: Seems reasonable to me, but couldn't locate any
>> follow-up discussion. Review solicited.]
Seems reasonable to me, too.
>> For gss_acquire_cred() and gss_add_cred(), align with cbind-04
>> statement of likely non-support for INITIATE and BOTH credentials if a
>> non-empty name is specified? Martin Rex objects (28 Apr 97,
>> reiterating earlier comment) to cbind-04 statement, recommends
>> requiring same scope of function as gss_init_sec_context() and
>> gss_accept_sec_context() provide with GSS_C_NO_CREDENTIAL. [PROPOSED
>> ACTION: I also believe that, at a minimum, an explicit specification
>> of the same name which would result from inquiring against the default
>> credential should be acceptable, and would like to specifically allow
>> this.]
It seems that some mechanisms will be unable to support GSS_C_BOTH
credentials in most cases. This does not seem to be dealt with well
in either the HL or ansi c bindings spec. In particular, the most
recommended behavior in rfc2078 1.1.1.3 for init and accept could
easily result in credentials with different names (using krb5 as an
example, marc at CYGNUS.COM as the initiator, and
host/rover.cygnus.com at CYGNUS.COM as the acceptor). In this situation,
what does gss_inquire_cred on the default cred handle return as the
cred_name? What does it return as cred_usage?
>> NAME-RELATED ISSUES:
>>
>> Should Host-Based Service name form be stated as mandatory for the
>> Internet environment? (Ted Ts'o recommends, 9 Apr 97) [PROPOSED
>> ACTION: Discussion needed; absent follow-up, add no specific
>> statement re mandatory vs. optional.]
I believe this should be strongly recommended, but not mandated, as
such a mapping does not necessarily exist. However, when such a
mechanism does exist, it should be made mandatory in the mechanism
specification.
There is a more general issue I would like to bring up, but I'll do it
in a separate messge to avoid confusion.
Marc
Received: from ietf.org by ietf.org id aa08638; 4 May 97 23:36 EDT
Received: from www.atr.net by ietf.org id aa08062; 4 May 97 23:16 EDT
Received: from www.atr.net (www.atr.net [206.232.44.253]) by www.atr.net (NTMail 3.02.10) with ESMTP id ia000684 for <ietf at ietf.org>; Sun, 4 May 1997 23:14:50 +0100
Message-ID: <336D50A9.7D2A at atr.net>
Date: Sun, 04 May 1997 23:14:49 -0400
Sender:ietf-request at ietf.org
From: "Turner W Rentz , III" <treyr at atr.net>
Reply-To: treyr at atr.net
Organization: Advanced Technology and Research, Inc.
X-Mailer: Mozilla 3.01 (WinNT; I)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: Yay! Deep Blue wins one!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Kasparov loses game 2, deep blue playing the E2-E4 OPENING!!
Three cheers for Deep Blue from the IETF !!
--
T. Rentz, III "The Internet is the Garden of Eden."
http://www.atr.net/people/treyr
Received: from ietf.org by ietf.org id aa17481; 5 May 97 9:34 EDT
Received: from ietf.ietf.org by ietf.org id aa16506; 5 May 97 9:25 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-02.txt
Date: Mon, 05 May 1997 09:25:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705050925.aa16506 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-02.txt
Pages : 5
Date : 05/02/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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-url-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-asid-ldapv3-url-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: <19970502143119.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-url-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-url-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502143119.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17465; 5 May 97 9:34 EDT
Received: from ietf.ietf.org by ietf.org id aa16560; 5 May 97 9:25 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-01.txt
Date: Mon, 05 May 1997 09:25:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705050925.aa16560 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 Distributed Management
Working Group of the IETF.
Title : Notification MIB
Author(s) : B. Stewart
Filename : draft-ietf-disman-notify-mib-01.txt
Pages : 27
Date : 05/02/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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-notify-mib-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-disman-notify-mib-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: <19970502155111.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-notify-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-notify-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502155111.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17484; 5 May 97 9:34 EDT
Received: from ietf.ietf.org by ietf.org id aa16459; 5 May 97 9:24 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-imip-00.txt
Date: Mon, 05 May 1997 09:24:52 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705050924.aa16459 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 Calendaring and Scheduling
Working Group of the IETF.
Title : iCalendar Message-based Interoperability Protocol (iMIP)
Author(s) : F. Dawson
Filename : draft-ietf-calsch-imip-00.txt
Pages : 90
Date : 05/02/1997
This document defines an iCalendar Message-based Interoperability Protocol
(iMIP), intended to be used to convey calendaring and scheduling semantics
between different applications. This document is also being offered as a
specification for demonstrating industry-wide, calendaring and scheduling
interoperability.
The message-based protocol defined by this document is useful not only
in traditional electronic messaging (e-mail) transports, but also
is applicable for conveying calendaring and scheduling information
across any reliable transport; including memory-based clipboards,
drag/drop protocols, wireless pagers, and the Infra-red Data
Association (IrDA) object transfer protocol. This format is useful for
both client-to-server communication, server-to-server communication,
and client-to-client, peer communication (e.g., PDA synchronization
with a PIM).
This design document is heavily based on the prior work of the
Versit Consortium's Personal Data Interchange (PDI) project team; including
the vCard v2.1 and the vCalendar v1.0 specifications. More information
about the PDI project and these documents can be found on the Internet Mail
Consortium (IMC) website at http://www.imc.org/pdi.
In addition, this design document makes use of the work within the
Internet Engineering Task Force (IETF) Calendaring and Scheduling
(CALSCH) working group. More information about the IETF CALSCH
working group activities can be found on the IMC website at
http://www.imc.org, the IETF website at
http://www.ietf.org/html.charters/calsch-charter.html. Refer to the
references within this document for further information on how to
access these various documents.
Distribution of this document is unlimited. Comments and suggestions
for improvement should be sent as MIME email to 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-calsch-imip-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-imip-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-calsch-imip-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: <19970502115649.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-calsch-imip-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-calsch-imip-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502115649.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17483; 5 May 97 9:34 EDT
Received: from ietf.ietf.org by ietf.org id aa16524; 5 May 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-newman-url-imap-07.txt
Date: Mon, 05 May 1997 09:25:04 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705050925.aa16524 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 : IMAP URL Scheme
Author(s) : C. Newman
Filename : draft-newman-url-imap-07.txt
Pages : 15
Date : 05/02/1997
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It
provides an ideal mechanism for accessing public mailing list archives as
well as private and shared message stores. This document defines a URL
scheme for referencing objects on an IMAP 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-newman-url-imap-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-url-imap-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-newman-url-imap-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: <19970502145358.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-url-imap-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-url-imap-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502145358.I-D at ietf.org>
--OtherAccess--
--NextPart--
IMAP server.
Received: from ietf.org by ietf.org id aa17474; 5 May 97 9:34 EDT
Received: from ietf.ietf.org by ietf.org id aa16644; 5 May 97 9:25 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-stdreport-02.txt
Date: Mon, 05 May 1997 09:25:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705050925.aa16644 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.
Title : OSPF Standardization Report
Author(s) : J. Moy
Filename : draft-ietf-ospf-stdreport-02.txt
Pages : 8
Date : 05/02/1997
This memo documents how the requirements for advancing a routing protocol
to Full Standard, set out in [Ref2], have been met for OSPFv2.
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-stdreport-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-stdreport-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-ospf-stdreport-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: <19970502172341.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-stdreport-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-stdreport-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502172341.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17487; 5 May 97 9:34 EDT
Received: from ietf.ietf.org by ietf.org id aa16605; 5 May 97 9:25 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-01.txt
Date: Mon, 05 May 1997 09:25:17 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705050925.aa16605 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 Distributed Management
Working Group of the IETF.
Title : Expression MIB
Author(s) : B. Stewart
Filename : draft-ietf-disman-express-mib-01.txt
Pages : 20
Date : 05/02/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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-express-mib-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-disman-express-mib-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: <19970502155343.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-express-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-express-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502155343.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17486; 5 May 97 9:34 EDT
Received: from ietf.ietf.org by ietf.org id aa16621; 5 May 97 9:25 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-01.txt
Date: Mon, 05 May 1997 09:25:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705050925.aa16621 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 Distributed Management
Working Group of the IETF.
Title : Event MIB
Author(s) : B. Stewart
Filename : draft-ietf-disman-event-mib-01.txt
Pages : 24
Date : 05/02/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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-event-mib-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-disman-event-mib-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: <19970502155516.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-event-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-event-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502155516.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa18555; 5 May 97 10:10 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa10795;
5 May 97 10:10 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id KAA23415; Mon, 5 May 1997 10:06:20 -0400 (EDT)
Received: (from root at localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id JAA12678 for disman-out; Mon, 5 May 1997 09:57:35 -0400 (EDT)
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id JAA12646 for <disman at nexen.com>; Mon, 5 May 1997 09:57:25 -0400 (EDT)
Received: from ietf.org (ietf.org [132.151.1.19]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id JAA09812 for <disman at nexen.com>; Mon, 5 May 1997 09:57:20 -0400 (EDT)
Received: from ietf.ietf.org by ietf.org id aa16556; 5 May 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: disman at nexen.com
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-disman-mgt-target-mib-01.txt
Date: Mon, 05 May 1997 09:25:10 -0400
Message-ID: <9705050925.aa16556 at ietf.org>
Sender: owner-disman at nexen.com
Precedence: bulk
X-Info: [Un]Subscribe to disman-request at nexen.com, submissions to disman at nexen.com
--NextPart
A Revised 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-01.txt
Pages : 26
Date : 05/02/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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-mgt-target-mib-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-disman-mgt-target-mib-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: <19970502154906.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-mgt-target-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-mgt-target-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502154906.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19435; 5 May 97 10:40 EDT
Received: from ietf.ietf.org by ietf.org id aa19253; 5 May 97 10:34 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-lpm-00.txt
Date: Mon, 05 May 1997 10:34:36 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705051034.aa19253 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 : Local Processing Model for the Next Generation
Author(s) : B. Wijnen, D. Harrington
Filename : draft-ietf-snmpv3-lpm-00.txt
Pages : 37
Date : 04/30/1997
This document describes the Local Processing Model (LPM) for the
Next-Generation of the Simple Network Management Protocol (SNMPng). It is
part of the overall Architectural Model for the Next Generation Simple
Network Management Protocol (SNMPng).
This document includes a MIB for remotely monitoring/managing the
configuration paramters for this LPM.
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-lpm-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-lpm-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-lpm-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: <19970430112254.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-lpm-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-lpm-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970430112254.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19823; 5 May 97 10:56 EDT
Received: from jupiter.esker.fr by ietf.org id aa19696; 5 May 97 10:53 EDT
Received: from vianne.esker.fr (yvianne.esker.fr [194.51.34.71]) by jupiter.esker.fr (/Esker 1.0) with ESMTP id QAA08958 for <ietf at ietf.org>; Mon, 5 May 1997 16:51:03 +0200
Message-Id: <199705051451.QAA08958 at jupiter.esker.fr>
Sender:ietf-request at ietf.org
From: goetz at esker.fr
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Date: Mon, 05 May 97 16:30:46 +0000
To: ietf at ietf.org
Subject: RFCs
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=__===-=-2069101371703947174868839-=-==-_=="
X-Mailer: <Tun MAIL version 3.1(0)>
Source-Info: From (or Sender) name not authenticated.
--=-=__===-=-2069101371703947174868839-=-==-_==
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Please, could you tell me where I can find (on the web or in books) the =0D=
=0Atranslation of RFCs in french ? It will be a great help for me, because=
=0D=0Ait's difficult for me to understand all the technicalities of the texts=
=2E=0D=0A=0D=0Agoetz at esker=2Efr
--=-=__===-=-2069101371703947174868839-=-==-_==--
Received: from ietf.org by ietf.org id aa20218; 5 May 97 11:10 EDT
Received: from ietf.ietf.org by ietf.org id aa20113; 5 May 97 11:07 EDT
To: IETF-Announce: ;
cc: mbeaulie at ietf.org
Subject: 39th IETF - Additional Hotels
Date: Mon, 05 May 1997 11:07:03 -0400
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9705051107.aa20113 at ietf.org>
I have contacted the following three hotels to hold a block of rooms
for the IETF attendees for the 39th IETF meeting in Munich. I have
contacted three other hotels that are further away from the Sheraton
but easily reached via the underground and will send out information
on these hotels after I finalize arrangements with them.
Marcia
IETF Meeting Coordinator
Arabella Hotel Bogenhausen, Munich
Arabellstra. 5
81925 Munich
Tel: 49-89-92 32-0
Fax: 49-89-92-32-44 49
Specify: IETF Group
Block of 100 rooms (over dates of August 8-16, 1997) until July 18, 1997
Single: DM 190 inclusive of tax and breakfast
Double: DM 230 inclusive of tax and breakfast
Arabella Hotel is located across the street from the Sheraton.
Hotel Rothof Bogenhausen, Munich
Denningerstr. 114
81925 Munich
Tel: 49-89-91-50-61
Fax: 49-89-91-50-66
Prefers reservations made by fax.
Specify: IETF Group
Block of 25 rooms (over dates of August 8-16, 1997) until July 8, 1997
Single: DM 216 (weekday); DM 158 (weekend) inclusive of tax and breakfast
Double: DM 278 (weekday); DM 198 (weekend) inclusive of tax and breakfast
Hotel Rothof is about an 8 minute walk from the Sheraton.
Queens Hotel, Munich
Effnerstr. 99
81925 Munich
Tel: 49-89-92-79-80
Fax: 49-89-98-38-13
Specify: IETF Group
Block of 50 rooms (over dates of August 8-16, 1997) until July 18, 1997
Single: DM 185 inclusive of tax and breakfast
Double: DM 210 inclusive of tax and breakfast
Please use fax form below to make your reservation.
Queens Hotel is about a 10 minute walk from the Sheraton. The hotel also
offer guests a complimentary shuttle service to the Arabellapark where the
Sheraton Hotel is located, service is only Monday-Friday.
To: Queens Hotel Munchen
EffnerstraBe 99
81925 Munchen
Heike Haage - Reservation
Fax: 49-89-98-38-13
From: ___________________________________
Address: ___________________________________
___________________________________
Phone/Fax: ___________________________________
Ref: IETF (Internet Engineering Task Force) - August 1997
Phone/Fax: ___________________________________
Ref: IETF (Internet Engineering Task Force) - August 1997
Please reserve Name: _______________________________
Date: _______________________________
_____ DM 185,-- Single room/breakfast included
per night
_____ DM 210,-- Double room/breakfast included
per night
Arrival: _____ before 6:00 PM
_____ after 6:00 PM - reservation is guaranteed
Credit card: Number: ______________________
Type: ________________________
Expiration Date: _____________
Received: from ietf.org by ietf.org id aa22845; 5 May 97 12:48 EDT
Received: from cnri by ietf.org id aa22731; 5 May 97 12:44 EDT
Received: from comsun.comm.utoronto.ca by CNRI.Reston.VA.US id aa14308;
5 May 97 12:44 EDT
Received: by comsun.comm.toronto.edu id <33833>; Mon, 5 May 1997 12:38:23 -0400
Sender:ietf-request at ietf.org
From: Irene Katzela <irene at comm.toronto.edu>
To: enternet at bbn.com, cnom at maestro.bellcore.com, comsoc.bog at tab.ieee.org,
sigmedia at bellcore.com, comsoc-gicb at ieee.org, commsoft at cc.bellcore.com,
testnet at canarie.ca, ietf at CNRI.Reston.VA.US, itc at fokus.gmd.de,
comsoc-tcii at ieee.com, dbworld at cs.wisc.edu, ieeetcpc at ccvm.sunysb.edu,
comsoc-chapter at ieee.org
Subject: Call for Papers - MC2R ,3rd Issue REMINDER!!!
Cc: irene at comm.toronto.edu
Content-Type: X-sun-attachment
Message-Id: <97May5.123823edt.33833 at comsun.comm.toronto.edu>
Date: Mon, 5 May 1997 12:37:37 -0400
Source-Info: From (or Sender) name not authenticated.
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 121
I apologize if you receive this mail more than once.
***********************************************************************
CALL FOR PAPERS (3rd Issue)
Mobile Computing and Communications Review
(A publication of the ACM SIGMOBILE society)
with guest editor
Irene Katzela
University of Toronto
Canada
PUBLICATION PURPOSE
The wireless communication revolution is bringing fundamental changes
to telecommunication and computing. Wide-area cellular systems and
wireless LANs promise to make integrated networks a reality and provide
fully distributed and ubiquitous mobile computing and communications,
thus bringing an end to the tyranny of geography. Furthermore, services
for the mobile user are maturing and are poised to change the nature and
scope of communication. This publication serves to enhance the ability
of ACM SIGMOBILE members to keep up-to-date in this rapidly moving field,
as well as serve as a major focal point for the discussion of new directions
of portable computation and mobile networks for both the research and
market-driven communities.
TOPICS
Technical papers describing original research are solicited on topics
at the link layer and above. Topics will include, but are not limited
to:
- Network management and control for wireless and mobile networks:
network management architectures and planning; signalling, routing,
and handoff management; resource allocation; mobile tracking and
location
- Integration of wired and wireless networks: internetworking and
interoperability issues; service integration
- Protocols to cope with mobility, limited bandwidth, or intermittent
connectivity.
- Wireless networking standards
- Future trends in mobile and wireless networks, economic
and business impact
- Multimedia and wireless: support for multimedia applications
over wireless; multimedia services and mobility; design of
multimedia wireless terminals
- ATM and wireless: Wireless ATM LANs; integrated services and
wireless ATM.
- Security and reliability issues for mobile/wireless systems
HOW TO SUBMIT
Paper submission will be handled electronically. Authors should Email
a PostScript version of their full paper to:
editors at bcn.bu.edu
Detailed submission instructions can be found on the MC2R web page:
http://bcn.bu.edu/MC2R
SUBMISSION DUE : May 15, 1997
NOTIFICATION OF ACCEPTANCE: July 15, 1997
FOR MORE INFORMATION
Please contact Irene Katzela at irene at comm.utoronto.ca, or the editors of MC2R at editors at bcn.bu.edu
GUEST EDITOR EDITOR-IN-CHIEF
Irene Katzela Victor Bahl
University of Toronto, ECE Digital Equipment Corporation
10 King's College Road 110 Spitbrook Road, ZK1-1/E37
GB204, Toronto, Ontario Corporate Research
M5S 3G4, Canada Nashua, NH 03062-2698, USA
Tel: 416 946 312 Tel: (603) 881-2321
Fax: 416 971 3020 Fax: (603) 881-0585
e-mail: irene at comm.utoronto.edu email: bahl at samson.enet.dec.com
ASSOCIATE EDITOR ASSOCIATE EDITOR
Charles Perkins (IBM) Jason Redi (BCN)
****************************************************************************
----- End Included Message -----
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: sigm.txt
X-Sun-Content-Lines: 111
X-Sun-Charset: us-ascii
***********************************************************************
CALL FOR PAPERS (3rd Issue)
Mobile Computing and Communications Review
(A publication of the ACM SIGMOBILE society)
with guest editor
Irene Katzela
University of Toronto
Canada
PUBLICATION PURPOSE
The wireless communication revolution is bringing fundamental changes
to telecommunication and computing. Wide-area cellular systems and
wireless LANs promise to make integrated networks a reality and provide
fully distributed and ubiquitous mobile computing and communications,
thus bringing an end to the tyranny of geography. Furthermore, services
for the mobile user are maturing and are poised to change the nature and
scope of communication. This publication serves to enhance the ability
of ACM SIGMOBILE members to keep up-to-date in this rapidly moving field,
as well as serve as a major focal point for the discussion of new directions
of portable computation and mobile networks for both the research and
market-driven communities.
TOPICS
Technical papers describing original research are solicited on topics
at the link layer and above. Topics will include, but are not limited
to:
- Network management and control for wireless and mobile networks:
network management architectures and planning; signalling, routing,
and handoff management; resource allocation; mobile tracking and
location
- Integration of wired and wireless networks: internetworking and
interoperability issues; service integration
- Protocols to cope with mobility, limited bandwidth, or intermittent
connectivity.
- Wireless networking standards
- Future trends in mobile and wireless networks, economic
and business impact
- Multimedia and wireless: support for multimedia applications
over wireless; multimedia services and mobility; design of
multimedia wireless terminals
- ATM and wireless: Wireless ATM LANs; integrated services and
wireless ATM.
- Security and reliability issues for mobile/wireless systems
HOW TO SUBMIT
Paper submission will be handled electronically. Authors should Email
a PostScript version of their full paper to:
editors at bcn.bu.edu
Detailed submission instructions can be found on the MC2R web page:
http://bcn.bu.edu/MC2R
SUBMISSION DUE : May 15, 1997
NOTIFICATION OF ACCEPTANCE: July 15, 1997
FOR MORE INFORMATION
Please contact Irene Katzela at irene at comm.utoronto.ca, or the editors of MC2R at editors at bcn.bu.edu
GUEST EDITOR EDITOR-IN-CHIEF
Irene Katzela Victor Bahl
University of Toronto, ECE Digital Equipment Corporation
10 King's College Road 110 Spitbrook Road, ZK1-1/E37
GB204, Toronto, Ontario Corporate Research
M5S 3G4, Canada Nashua, NH 03062-2698, USA
Tel: 416 946 312 Tel: (603) 881-2321
Fax: 416 971 3020 Fax: (603) 881-0585
e-mail: irene at comm.utoronto.edu email: bahl at samson.enet.dec.com
ASSOCIATE EDITOR ASSOCIATE EDITOR
Charles Perkins (IBM) Jason Redi (BCN)
****************************************************************************
Received: from ietf.org by ietf.org id aa00648; 5 May 97 17:06 EDT
Received: from zephyr.isi.edu by ietf.org id aa00460; 5 May 97 16:56 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA11513>; Mon, 5 May 1997 13:53:28 -0700
Message-Id: <199705052053.AA11513 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2141 on URN Syntax
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 05 May 97 13:53:28 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 2141:
Title: URN Syntax
Author: R. Moats
Date: May 1997
Mailbox: jayhawk at ds.internic.net
Pages: 8
Characters: 14077
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2141.txt
Uniform Resource Names (URNs) are intended to serve as persistent,
location-independent, resource identifiers. This document sets
forward the canonical syntax for URNs. A discussion of both existing
legacy and new namespaces and requirements for URN presentation and
transmission are presented. Finally, there is a discussion of URN
equivalence and how to determine it. This document is the product of
the Uniform Resource Names 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: <970505134933.RFC at ISI.EDU>
SEND /rfc/rfc2141.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2141.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970505134933.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04316; 5 May 97 20:02 EDT
Received: from cnri by ietf.org id aa04154; 5 May 97 19:55 EDT
Received: from emout01.mx.aol.com by CNRI.Reston.VA.US id aa23780;
5 May 97 19:54 EDT
Received: (from root at localhost)
by emout01.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0)
id TAA02322;
Mon, 5 May 1997 19:51:27 -0400 (EDT)
Date: Mon, 5 May 1997 19:51:27 -0400 (EDT)
Sender:ietf-request at ietf.org
From: JAWilson57 at aol.com
Message-ID: <970505195126_-30572525 at emout01.mail.aol.com>
To: ietf at CNRI.Reston.VA.US
cc: www.JAWilson.com at aol.com
Subject: Disney Anniversary savings
Source-Info: From (or Sender) name not authenticated.
I am requesting imformation on the travel savings and savings deals for
Disney World thank you
Received: from ietf.org by ietf.org id aa17711; 6 May 97 3:41 EDT
Received: from wentzl.cdg.chalmers.se by ietf.org id aa17103; 6 May 97 3:04 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 JAA25926
for <ietf at ietf.org>; Tue, 6 May 1997 09:00:38 +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 JAA25181
for ietf at ietf.org; Tue, 6 May 1997 09:00:39 +0200 (MET DST)
Date: Tue, 6 May 1997 09:00:39 +0200 (MET DST)
Message-Id: <199705060700.JAA25181 at wilfer1.cdg.chalmers.se>
To: ietf at ietf.org
Subject: Re: where is Munich Hotel
X-Mailer: UCB Mail 5.3.8 96-10-07 (MIME)
Source-Info: From (or Sender) name not authenticated.
I've just had a word with Sheraton Munich... It seems like I'm on
the waiting list for the single night Aug 14-15, which is Thu-Fri,
but that the rest of my reservation is OK. Of course they can be
fully booked just one single night in the middle of the week, but
it could also be that they prefer to let their rooms to somebody
else, somebody at full rate without the IETF group discount.
Hope I'm wrong,
Gunnar Lindberg
Received: from ietf.org by ietf.org id aa19718; 6 May 97 6:01 EDT
Received: from ecrc.de by ietf.org id aa19605; 6 May 97 5:57 EDT
Received: from scorpio.ecrc.de (scorpio.ecrc.de [141.1.4.100]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with ESMTP id LAA22055; Tue, 6 May 1997 11:53:26 +0200 (MET DST)
Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125])
by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP
id LAA08561; Tue, 6 May 1997 11:53:22 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Dave Morton <Dave.Morton at ecrc.de>
Received: (from dave at localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id LAA22846; Tue, 6 May 1997 11:53:19 +0200 (MET DST)
Date: Tue, 6 May 1997 11:53:19 +0200 (MET DST)
Message-Id: <199705060953.LAA22846 at acrab25.ecrc.de>
To: craig at aland.bbn.com, ietf at ietf.org
Subject: Re: where is Munich Hotel
Cc: f at ecrc.de
Source-Info: From (or Sender) name not authenticated.
>Hi folks:
>
>The maps of Munich in the Michelin red guide don't list the street the
>Munich hotel is on. Can anyone describe roughly where the hotel is in town
>vis-a-vis some major landmark? (Given the main hotel is largely full, I
>figured I'd find a nice hotel in the Michelin guide that is reasonably nearby)?
Craig - your Michelin guide must be rather ancient. Arabellastr. and the
Sheraton Hotel have been around as long as I remember and thats since about
1980, the first time I remember coming to Munich.
To answer your question though, the Sheraton is on the Arabellastr. to the
east of Munich in a district called Bogenhausen. There is an underground (tube,
metro, call it what you will) called Arabellapark - line no. U4 and it takes about
12 minutes to get there from the centre of town. I have given the IETF folks
the coordinates for other hotels, they should be appearing on the IETF meeting
pages soon. I guess there are still contractual issues they need to sort out.
This is not the task of the local host.
Hope this helps.
Dave
PS: If your guide doesn't have a map of the underground either then its time to get
a upgrade....
Hint: check out http://www.munich-tourist.de/english/m41.htm for a map of the
underground system and perhaps http://www.munich-online.de/hotels if you want to
find something yourself.
>Thanks!
>
>Craig
>
>E-mail: craig at aland.bbn.com or craig at bbn.com
>
Received: from ietf.org by ietf.org id aa19988; 6 May 97 6:16 EDT
Received: from info.dsv.su.se by ietf.org id aa19918; 6 May 97 6:15 EDT
Received: from [130.237.157.127] (phmac7.dsv.su.se [130.237.157.127])
by info.dsv.su.se (8.8.5/8.8.5) with ESMTP
id MAA19888 for <ietf at ietf.org>;
Tue, 6 May 1997 12:11:28 +0200 (MET DST)
X-Sender: jpalme at dsv.su.se (Unverified)
Message-Id: <v0300780eaf94bbe14841 at [130.237.158.12]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 6 May 1997 11:48:32 +0100
To: IETF general mailing list <ietf at ietf.org>
Sender:ietf-request at ietf.org
From: Jacob Palme <jpalme at dsv.su.se>
Subject: Hotel in Munich
Source-Info: From (or Sender) name not authenticated.
I tried to book a room at Sheraton, all rooms were occupied.
I then asked them for the name of another nearby hotel.
They recommended hotel Arabella. I booked a room there
at the special rate of 190 DM for IETF participants.
The phone number for Arabella is +49-89-92 320
and the fax number +49-89-92 32 44 48
------------------------------------------------------------------------
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 aa23693; 6 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa23444; 6 May 97 9:44 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-state-man-mec-01.txt, .ps
Date: Tue, 06 May 1997 09:44:53 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705060944.aa23444 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 : HTTP State Management Mechanism (Rev1)
Author(s) : D. Kristol, L. Montulli
Filename : draft-ietf-http-state-man-mec-01.txt, .ps
Pages : 21
Date : 05/05/1997
This document specifies a way to create a stateful session with HTTP
requests and responses. It describes two new headers, Cookie and
Set-Cookie2, which carry state information between participating origin
servers and user agents. The method described here differs from Netscape's
Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use
Netscape's method. (See the HISTORICAL section.)
This document reflects implementation experience with RFC 2109
and obsoletes it.
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-state-man-mec-01.txt".
Or
"get draft-ietf-http-state-man-mec-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-man-mec-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-http-state-man-mec-01.txt".
Or
"FILE /internet-drafts/draft-ietf-http-state-man-mec-01.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: <19970505184558.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-state-man-mec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-state-man-mec-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970505184558.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23825; 6 May 97 9:51 EDT
Received: from ietf.ietf.org by ietf.org id aa23360; 6 May 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-masinter-url-i18n-00.txt
Date: Tue, 06 May 1997 09:44:27 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705060944.aa23360 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Using UTF-8 for non-ASCII Characters in URLs
Author(s) : L. Masinter
Filename : draft-masinter-url-i18n-00.txt
Pages : 2
Date : 05/02/1997
Traditionally, URLs have been written in ASCII and used both as a method of
transcription and identification, but also in advertising, magazines and
newspapers. This document specifies a uniform way of representing non-ASCII
scripts in URLs so that they can be used for the world's languages.
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-masinter-url-i18n-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-masinter-url-i18n-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-masinter-url-i18n-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: <19970502114800.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-masinter-url-i18n-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-masinter-url-i18n-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970502114800.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23823; 6 May 97 9:51 EDT
Received: from ietf.ietf.org by ietf.org id aa23297; 6 May 97 9:43 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-syntax-05.txt
Date: Tue, 06 May 1997 09:43:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705060943.aa23297 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 Uniform Resource Names
Working Group of the IETF.
Title : URN Syntax
Author(s) : R. Moats
Filename : draft-ietf-urn-syntax-05.txt
Pages : 7
Date : 05/05/1997
Uniform Resource Names (URNs) are intended to serve as persistent,
location-independent, resource identifiers. This document sets forward the
canonical syntax for URNs. A discussion of both existing legacy and new
namespaces and requirements for URN presentation and transmission are
presented. Finally, there is a discussion of URN equivalence and how to
determine it.
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-syntax-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-05.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-syntax-05.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: <19970505173055.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-syntax-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-syntax-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970505173055.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23817; 6 May 97 9:51 EDT
Received: from ietf.ietf.org by ietf.org id aa23414; 6 May 97 9:44 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-ldapv3ext-04.txt
Date: Tue, 06 May 1997 09:44:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705060944.aa23414 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): Extensions
for Dynamic Directory Services
Author(s) : Y. Yaacovi, M. Wahl, T. Genovese
Filename : draft-ietf-asid-ldapv3ext-04.txt
Pages : 8
Date : 05/05/1997
This document defines the requirements for dynamic directory services and
specifies the format of request and response extended operations for
supporting client-server interoperation in a dynamic directories
environment.
The Lightweight Directory Access Protocol (LDAP) [1]
supports lightweight access to static directory services, allowing
relatively fast search and update access. Static directory services store
information about people that persists in its accuracy and value over a
long period of time.
Dynamic directory services are different in that they store information
that only persists in its accuracy and value when it is being
periodically refreshed. This information is stored as dynamic
entries in the directory. A typical use will be a client or a
person that is either online - in which case it has an entry in the
directory, or is offline - in which case its entry disappears from the
directory. Though the protocol operations and attributes used by dynamic
directory services are similar to the ones used for static directory
services, clients that store dynamic information in the directory need to
periodically refresh this information, in order to prevent it from
from disappearing. If dynamic entries are not refreshed
within a given timeout, they will be removed from the directory. For
example, this will happen if the client that set them goes offline.
A flow control mechanism from the server is also described that allows
a server to inform clients how often they should refresh their
presence.
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-ldapv3ext-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3ext-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-asid-ldapv3ext-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: <19970505182829.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3ext-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3ext-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970505182829.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23822; 6 May 97 9:51 EDT
Received: from ietf.ietf.org by ietf.org id aa23387; 6 May 97 9:44 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-nssa-update-01.txt
Date: Tue, 06 May 1997 09:44:32 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705060944.aa23387 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.
Title : The OSPF NSSA Option
Author(s) : R. Coltun, V. Fuller, P. Murphy
Filename : draft-ietf-ospf-nssa-update-01.txt
Pages : 25
Date : 05/05/1997
This memo documents of an optional type of OSPF area which is somewhat
humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are
similar to the existing OSPF stub area configuration option but have the
additional capability of importing AS external routes in a limited fashion.
The OSPF NSSA Option was originally defined in RFC 1587. The functional
differences between this memo and RFC 1587 are explained in Appendix D.
All differences, while expanding capability, are backward-compatible in
nature. Implementations of this memo and of RFC 1587 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-nssa-update-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-nssa-update-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-ospf-nssa-update-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: <19970505182024.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-nssa-update-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-nssa-update-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970505182024.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23824; 6 May 97 9:51 EDT
Received: from ietf.ietf.org by ietf.org id aa23324; 6 May 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-transition-01.txt
Date: Tue, 06 May 1997 09:44:18 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705060944.aa23324 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 to NHRP Transition
Author(s) : J. Luciani
Filename : draft-ietf-ion-transition-01.txt
Pages : 5
Date : 05/05/1997
This document describes methods and procedures for the graceful transition
from an ATMARP LIS[1] to an NHRP LIS[2] network model over ATM.
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-transition-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-transition-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-ion-transition-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: <19970506093422.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-transition-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-transition-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970506093422.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24712; 6 May 97 10:22 EDT
Received: from fliptop.pilsnet.sunet.se by ietf.org id aa24630;
6 May 97 10:20 EDT
Received: from fliptop.pilsnet.sunet.se (liman at localhost [127.0.0.1])
by fliptop.pilsnet.sunet.se (8.8.Beta.2/8.8.Beta.2) with ESMTP
id QAA00334 for <ietf at ietf.org>;
Tue, 6 May 1997 16:17:26 +0200 (MET DST)
Message-Id: <199705061417.QAA00334 at fliptop.pilsnet.sunet.se>
To: ietf at ietf.org
Subject: Re: Hotel in Munich
X-Mailer: Mew version 1.54 on Emacs 19.28.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 06 May 1997 16:17:20 +0200
Sender:ietf-request at ietf.org
From: Lars-Johan Liman <liman at sunet.se>
Source-Info: From (or Sender) name not authenticated.
May I suggest that we instate the mailing list
ietf-hotel at ietf.org
Please?
Cheers,
/Liman
#-------------------------------------------------------------------------
# Lars-Johan Liman ! Internet: liman at sunet.se
# Ebone/NORDUnet/SUNET Operations Centre ! BITNET : LIMAN at SEARN
# Royal Institute of Technology, Sweden ! HTTP : //www.sunet.se/~liman
# ! Voice : Int +46 8 - 790 65 60
#-------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa25995; 6 May 97 11:04 EDT
Received: from dns1.Cent.Org by ietf.org id aa25867; 6 May 97 11:02 EDT
Received: from localhost (qjansen at localhost)
by dns1.cent.org (8.8.5/8.8.5) with SMTP id IAA12425;
Tue, 6 May 1997 08:02:02 -0700 (PDT)
Date: Tue, 6 May 1997 08:02:02 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Quinton Jansen <qjansen at dns1.cent.org>
To: Lars-Johan Liman <liman at sunet.se>
cc: ietf at ietf.org
Subject: Re: Hotel in Munich
In-Reply-To: <199705061417.QAA00334 at fliptop.pilsnet.sunet.se>
Message-ID: <Pine.BSF.3.95q.970506080141.12403A-100000 at dns1.cent.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I'll go for that!
Quinton Jansen
qjansen at cent.org
Next to being shot at and missed, nothing is really quite as satisfying
as an income tax refund.
-- F. J. Raymond
On Tue, 6 May 1997, Lars-Johan Liman wrote:
> May I suggest that we instate the mailing list
>
> ietf-hotel at ietf.org
>
> Please?
>
> Cheers,
> /Liman
> #-------------------------------------------------------------------------
> # Lars-Johan Liman ! Internet: liman at sunet.se
> # Ebone/NORDUnet/SUNET Operations Centre ! BITNET : LIMAN at SEARN
> # Royal Institute of Technology, Sweden ! HTTP : //www.sunet.se/~liman
> # ! Voice : Int +46 8 - 790 65 60
> #-------------------------------------------------------------------------
>
Received: from ietf.org by ietf.org id aa00204; 6 May 97 14:02 EDT
Received: from zephyr.isi.edu by ietf.org id aa29992; 6 May 97 13:55 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA03195>; Tue, 6 May 1997 10:52:26 -0700
Message-Id: <199705061752.AA03195 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2142 on Mailbox Names
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 06 May 97 10:52:26 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 2142:
Title: Mailbox Names for Common Services, Roles
and Functions
Author: D. Crocker
Date: May 1997
Mailbox: dcrocker at imc.org
Pages: 6
Characters: 12195
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2142.txt
This specification enumerates and describes Internet mail addresses
(mailbox name @ host reference) to be used when contacting personnel
at an organization.
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: <970506104804.RFC at ISI.EDU>
SEND /rfc/rfc2142.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2142.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970506104804.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07739; 6 May 97 19:48 EDT
Received: from cnri by ietf.org id aa07594; 6 May 97 19:40 EDT
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa22372;
6 May 97 19:40 EDT
Received: from wisdom.home.vix.com (wisdom.home.vix.com [192.5.5.7])
by gw.home.vix.com (8.8.4/) via ESMTP id QAA07439
for <ietf at cnri.reston.va.us>; Tue, 6 May 1997 16:36:27 -0700
env-from (vixie at vix.com)
Received: by wisdom.home.vix.com; id QAA13639; Tue, 6 May 1997 16:36:27 -0700
Message-Id: <199705062336.QAA13639 at wisdom.home.vix.com>
X-Authentication-Warning: wisdom.home.vix.com: localhost [127.0.0.1] didn't use HELO protocol
To: ietf at CNRI.Reston.VA.US
Subject: BIND 8.1-REL announcement
Date: Tue, 06 May 1997 16:36:27 -0700
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Source-Info: From (or Sender) name not authenticated.
-----BEGIN PGP SIGNED MESSAGE-----
This is the long-awaited successor to BIND Version 4 (i.e., 4.9.5 et al).
Many private releases have been run by the BIND developer community, and
several public releases have been tested by the Internet community at large.
We run BIND 8.1 on the root name server we operate (F.ROOT-SERVERS.NET),
and on all of our internal name servers (GW.HOME.VIX.COM, et al). BIND 8.1
is known to be running successfully at UUNET PIPEX (24,000 zones) and a
number of other large sites around the 'net.
The changes from BIND 8.1-T5B to 8.1-REL are small, but no patch will be
released since we would really like the "final cut" to be the only thing
on any FTP caches.
BIND 8 features are too numerous to mention here, but they include:
-> DNS Dynamic Updates (RFC 2136).
-> DNS Change Notification (RFC 1996).
-> Completely new configuration syntax (and HTML docs for same).
-> Flexible, categorized logging system (blackhole lame delegations!).
-> IP-address-based access control for queries, zone transfers, and
updates that may be specified on a zone-by-zone basis.
-> More efficient zone transfers (no fork() on outbound!).
-> Improved performance for servers with thousands of zones.
-> get*by*() functions can now use Sun NIS if desired/available.
-> Many bug fixes, including patches for all known security holes.
See the CHANGES file in the source kit for a detailed listing of all changes.
Bob and I would like to thank Viraj Bais of Intel for his reference
implementation of Dynamic DNS, which 8.1's dynamic DNS is built upon. We'd
also like to thank everyone who has sent us bug reports, patches, or
operating system ports.
The release files are:
ftp://ftp.isc.org/isc/bind/src/8.1/bind-contrib.tar.gz ~same as 4.9.5
ftp://ftp.isc.org/isc/bind/src/8.1/bind-contrib.tar.gz.asc PGP sig
ftp://ftp.isc.org/isc/bind/src/8.1/bind-doc.tar.gz new HTML,MAN
ftp://ftp.isc.org/isc/bind/src/8.1/bind-doc.tar.gz.asc PGP sig
ftp://ftp.isc.org/isc/bind/src/8.1/bind-src.tar.gz 8.1 source
ftp://ftp.isc.org/isc/bind/src/8.1/bind-src.tar.gz.asc PGP sig
Those PGP signatures are signed with the new <pgpkey at isc.org> key, which has
been submitted to the MIT key ring a lot of well known signatures on it.
It can also be found at <URL:http://www.isc.org/isc/> along with a lot of
other ISC related material that we hope you'll glance through. (If you see
it as a crass request for funding, well, we didn't mean it to be "crass".)
There is a newish mailing list: <bind-bugs at isc.org>. Submit bug reports to
it so that both Bob Halley and Paul Vixie will see them, and they will be
archived. This is not a mailing list in the traditional sense -- there are
no external subscribers.
Corresponding security fixes for BIND 4.9.5 will be released shortly, even
though the release of BIND 8.1 officially puts BIND 4.9.5 in "end of life."
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBM2/ACHcdkq6JcsfBAQEWFwP/WAldrVaypxOtjvkGgTyd4Kw6wbLovdBK
kSIGgpEx9hrpBKpVSaY+PcBEAIQqrjVRGSDxmgSm/9UhDb0qd9Os8tZmM0CwZY6H
IPWxyXoBFd0lly9ut+IPae0vkPTzmp8jwN5LoKb9YHvKHStoMq8dGkqHSo4DRT8U
gyXFElUBJrw=
=t/qo
-----END PGP SIGNATURE-----
Received: from cnri by ietf.org id aa17584; 6 May 97 23:36 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa00752;
6 May 97 23:36 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <CAA09401 at pad-thai.cam.ov.com>; Wed, 7 May 1997 02:14:42 GMT
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: oncrpc-wg at sunroof.eng.sun.com
Cc: cat-ietf at mit.edu
Subject: Re: problem with RPCSEC_GSS specification
References: <199705070126.SAA09042 at jurassic.eng.sun.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 May 1997 22:14:17 -0400
In-Reply-To: Michael.Eisler at Eng.Sun.COM's message of Tue, 6 May 1997 18:26:48 -0700
Message-Id: <t53u3kgdo5i.fsf at rover.cygnus.com>
Lines: 25
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Michael.Eisler at Eng.Sun.COM (Mike Eisler) writes:
>>
>> > Date: Tue, 6 May 1997 17:52:15 -0700
>> > From: mre at jurassic (Mike Eisler)
>> > To: oncrpc-wg at sunroof
>> > Subject: problem with RPCSEC_GSS specification
>> >
>> > ONC RPC'ers:
>> >
>> > While debugging a problem, I noticed that RFC2078, the GSS-API
>> > specification, does not define the numerical values for GSS-API major
>> > status codes. (Please correct me if I'm wrong). The RPCSEC_GSS
>> ^^^^^^^^^^^^^^^^^^^^^^^
>>
>> That took less than a half hour. :-) Roland Schemers points out that
>> the C-bindings GSS-API spec (RFC1509 and
>> draft-ietf-cat-gssv2-cbind-04.txt) have defined values. So instead, I
>> propose just referencing draft-ietf-cat-gssv2-cbind-04.txt.
The right answer is to define them in rfc2078. Although these values
never appear on the wire, rfc2078 defines numeric values for other
arguments already.
Marc
Received: from cnri by ietf.org id aa28084; 7 May 97 9:55 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10316;
7 May 97 9:55 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <MAA26080 at pad-thai.cam.ov.com>; Wed, 7 May 1997 12:26:55 GMT
Message-Id: <199705071226.IAA29249 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Marc Horowitz <marc at cygnus.com>
Cc: Mike Eisler <Michael.Eisler at eng.sun.com>, oncrpc-wg at sunroof.eng.sun.com,
cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: problem with RPCSEC_GSS specification
In-Reply-To: Your message of "06 May 1997 22:14:17 EDT."
<t53u3kgdo5i.fsf at rover.cygnus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 07 May 1997 08:26:50 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT and ONCRPC-ers:
For the benefit of oncrpc-wg subscribers who don't read cat-ietf, the latter
list has recently been discussing a compilation of errata against rfc-2078,
clarifying/correcting rfc-2078 largely for purposes of alignment with
subsequent work on the C bindings. It seems reasonable to me to propose,
as an addition to that compilation, replicating the numeric values from
draft-ietf-cat-gssv2-cbind-04, Table 5-2 (Routine Errors), and Table 5-3
(Supplementary Status Bits) when the successor to rfc-2078 is next advanced.
In conjunction, some reworking would be required in rfc-2078 to make
more explicit the separate treatment (as evolved in the C bindings) of
supplementary major stati CONTINUE_NEEDED, DUPLICATE_TOKEN, OLD_TOKEN,
UNSEQ_TOKEN, and GAP_TOKEN, which are represented in a separate element
within a structured status result and can, in some cases, be indicated in
conjunction with a non-zero Routine Error.
--jl
> Michael.Eisler at Eng.Sun.COM (Mike Eisler) writes:
>
> >>
> >> > Date: Tue, 6 May 1997 17:52:15 -0700
> >> > From: mre at jurassic (Mike Eisler)
> >> > To: oncrpc-wg at sunroof
> >> > Subject: problem with RPCSEC_GSS specification
> >> >
> >> > ONC RPC'ers:
> >> >
> >> > While debugging a problem, I noticed that RFC2078, the GSS-API
> >> > specification, does not define the numerical values for GSS-API major
> >> > status codes. (Please correct me if I'm wrong). The RPCSEC_GSS
> >> ^^^^^^^^^^^^^^^^^^^^^^^
> >>
> >> That took less than a half hour. :-) Roland Schemers points out that
> >> the C-bindings GSS-API spec (RFC1509 and
> >> draft-ietf-cat-gssv2-cbind-04.txt) have defined values. So instead, I
> >> propose just referencing draft-ietf-cat-gssv2-cbind-04.txt.
>
> The right answer is to define them in rfc2078. Although these values
> never appear on the wire, rfc2078 defines numeric values for other
> arguments already.
>
> Marc
>
Received: from ietf.org by ietf.org id aa28268; 7 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa27442; 7 May 97 9:41 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-hoffman-pkcs-crypt-msg-00.txt
Date: Wed, 07 May 1997 09:41:36 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705070941.aa27442 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : PKCS #7: Cryptographic Message Syntax
Version 1.5
Author(s) : P. Hoffman
Filename : draft-hoffman-pkcs-crypt-msg-00.txt
Pages : 31
Date : 05/06/1997
This standard describes a general syntax for data that may have
cryptography applied to it, such as digital signatures and digital
envelopes. The syntax admits recursion, so that, for example, one envelope
can be nested inside another, or one party can sign some previously
enveloped digital data. It also allows arbitrary attributes, such as
signing time, to be authenticated along with the content of a message, and
provides for other attributes such as countersignatures to be associated
with a signature. A degenerate case of the syntax provides a means for
disseminating certificates and certificate-revocation lists.
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-hoffman-pkcs-crypt-msg-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-pkcs-crypt-msg-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-hoffman-pkcs-crypt-msg-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: <19970506123943.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-pkcs-crypt-msg-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-pkcs-crypt-msg-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970506123943.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28272; 7 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa27482; 7 May 97 9:41 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-ph-03.txt
Date: Wed, 07 May 1997 09:41:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705070941.aa27482 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.
Title : The CCSO Nameserver (Ph) Architecture
Author(s) : R. Hedberg, P. Pomes
Filename : draft-ietf-ids-ph-03.txt
Pages : 19
Date : 05/06/1997
The PH Nameserver from the [Computing and Communications Services Office
(CCSO),] University of Illinois at Urbana-Champaign has for some time now
been used by several organizations as their choice of publicly available
database for information about people as well as other things. It is now
widely felt that the Internet community would benefit from having a more
rigorous definition of the client-server protocol, this document will
hopefully achieve that goal. The Ph service as specified in this document
is built around an information model, a client command language and the
server responses.
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-ph-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-ph-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-ids-ph-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: <19970506135502.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-ph-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-ph-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970506135502.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28273; 7 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa27462; 7 May 97 9:41 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-hoffman-pkcs-certif-req-00.txt
Date: Wed, 07 May 1997 09:41:42 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705070941.aa27462 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : PKCS #10: Certification Request Syntax
Version 1.5
Author(s) : P. Hoffman
Filename : draft-hoffman-pkcs-certif-req-00.txt
Pages : 8
Date : 05/06/1997
This standard describes a syntax for certification requests.
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-hoffman-pkcs-certif-req-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-pkcs-certif-req-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-hoffman-pkcs-certif-req-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: <19970506124240.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-pkcs-certif-req-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-pkcs-certif-req-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970506124240.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28267; 7 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa27420; 7 May 97 9:41 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-hoffman-pkcs-rsa-encrypt-00.txt
Date: Wed, 07 May 1997 09:41:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705070941.aa27420 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : PKCS #1: RSA Encryption
Version 1.5
Author(s) : P. Hoffman
Filename : draft-hoffman-pkcs-rsa-encrypt-00.txt
Pages : 18
Date : 05/06/1997
This standard describes a method for encrypting data using the RSA
public-key cryptosystem.
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-hoffman-pkcs-rsa-encrypt-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-pkcs-rsa-encrypt-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-hoffman-pkcs-rsa-encrypt-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: <19970506123420.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-pkcs-rsa-encrypt-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-pkcs-rsa-encrypt-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970506123420.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28265; 7 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa27820; 7 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-rfced-info-murakami-02.txt
Date: Wed, 07 May 1997 09:50:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705070950.aa27820 at ietf.org>
--NextPart
A Revised 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-02.txt
Pages : 3
Date : 05/06/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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-murakami-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-rfced-info-murakami-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: <19970506112525.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-murakami-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-murakami-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970506112525.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa00426; 7 May 97 10:56 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11707;
7 May 97 10:56 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <MAA26991 at pad-thai.cam.ov.com>; Wed, 7 May 1997 12:48:20 GMT
Message-Id: <199705071248.IAA29305 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Marc Horowitz <marc at cygnus.com>
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: RFC2078bis: draft actions and issues
In-Reply-To: Your message of "04 May 1997 18:54:59 EDT."
<t53g1w2c0fw.fsf at rover.cygnus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 07 May 1997 08:48:15 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Re:
> >> For gss_acquire_cred() and gss_add_cred(), align with cbind-04
> >> statement of likely non-support for INITIATE and BOTH credentials if a
> >> non-empty name is specified? Martin Rex objects (28 Apr 97,
> >> reiterating earlier comment) to cbind-04 statement, recommends
> >> requiring same scope of function as gss_init_sec_context() and
> >> gss_accept_sec_context() provide with GSS_C_NO_CREDENTIAL. [PROPOSED
> >> ACTION: I also believe that, at a minimum, an explicit specification
> >> of the same name which would result from inquiring against the default
> >> credential should be acceptable, and would like to specifically allow
> >> this.]
>
> It seems that some mechanisms will be unable to support GSS_C_BOTH
> credentials in most cases. This does not seem to be dealt with well
> in either the HL or ansi c bindings spec. In particular, the most
> recommended behavior in rfc2078 1.1.1.3 for init and accept could
> easily result in credentials with different names (using krb5 as an
> example, marc at CYGNUS.COM as the initiator, and
> host/rover.cygnus.com at CYGNUS.COM as the acceptor). In this situation,
> what does gss_inquire_cred on the default cred handle return as the
> cred_name? What does it return as cred_usage?
Per discussion (reflected in ACTIONS ASSUMED section) I believe we've
agreed that gss_inquire_cred() with default credential handle returns
information about the initiator-side credentials.
--jl
Received: from cnri by ietf.org id aa04774; 7 May 97 13:53 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16117;
7 May 97 13:53 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <QAA06136 at pad-thai.cam.ov.com>; Wed, 7 May 1997 16:31:39 GMT
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
Wed, 7 May 1997 15:57:14 +0200
X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
Wed, 7 May 1997 15:57:14 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Wed, 7 May 1997 15:57:04 +0200
X400-Received: by /PRMD=sept/ADMD=ATLAS/C=FR/; Relayed;
Wed, 7 May 1997 17:59:04 +0200
Date: Wed, 7 May 1997 17:59:04 +0200
X400-Originator: didier.guerin at sept.fr
X400-Recipients: cat-ietf at mit.edu
X400-Mts-Identifier: [/PRMD=sept/ADMD=ATLAS/C=FR/;863009944122470000guerind]
X400-Content-Type: P2-1984 (2)
Content-Identifier: UCOMX
Alternate-Recipient: Allowed
From: Didier GUERIN <didier.guerin at sept.fr>
Message-Id: <863009944122470000guerind*/G=didier/S=guerin/PRMD=sept/ADMD=ATLAS/C=FR/@MHS>
To: " (IETF CAT Group)" <cat-ietf at mit.edu>
In-Reply-To: <9704281547.AA17537 at ronde.frcl.bull.fr>
Subject: CAT: GSS-API security products (research)
Precedence: bulk
I'm looking for security products using GSS-API. I have made some research with those keywords and find the following products/references:
- SecuDE from GMD,
- DCE from OSF,
- SESAME from a RACE research project,
- ISM/AccessMaster from Bull.
Does anybody knows some other references, including products that can be used with TCP/IP?
I'm interesting on authentication, access control and integrity features (optionaly encryption capabilities).
Thanks in advance
Didier
didier.guerin at sept.fr
Received: from cnri by ietf.org id aa07242; 7 May 97 15:41 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18914;
7 May 97 15:41 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA08858 at pad-thai.cam.ov.com>; Wed, 7 May 1997 17:37:53 GMT
Message-Id: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970507172029Z-1688 at bwdldb.ott.bnr.ca>
From: Paul McBride <pmcbride at entrust.com>
To: "' (IETF CAT Group)'" <cat-ietf at mit.edu>,
'Didier GUERIN' <didier.guerin at sept.fr>
Subject: RE: GSS-API security products (research)
Date: Wed, 7 May 1997 13:20:29 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 26 TEXT
Precedence: bulk
Entrust toolkits support GSS-API.
Entrust Technologies "Orchestrating Enterprise Security"
Telephone: 613-763-2461 Fax: 613-765-3520 www.entrust.com
Entrust Public Key Authorization String: DDCB-HF6C-6LDA
>----------
>From: Didier GUERIN[SMTP:didier.guerin at sept.fr]
>Sent: Wednesday, May 07, 1997 11:59 AM
>To: (IETF CAT Group)
>Subject: CAT: GSS-API security products (research)
>
>I'm looking for security products using GSS-API. I have made some research
>with those keywords and find the following products/references:
>- SecuDE from GMD,
>- DCE from OSF,
>- SESAME from a RACE research project,
>- ISM/AccessMaster from Bull.
>
>Does anybody knows some other references, including products that can be used
>with TCP/IP?
>I'm interesting on authentication, access control and integrity features
>(optionaly encryption capabilities).
>Thanks in advance
>Didier
>didier.guerin at sept.fr
>
Received: from ietf.org by ietf.org id aa23003; 8 May 97 0:39 EDT
Received: from cnri by ietf.org id aa22870; 8 May 97 0:31 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01470; 8 May 97 0:31 EDT
Received: from sirius.ctr.columbia.edu by venera.isi.edu (5.65c/5.61+local-27)
id <AA18395>; Wed, 7 May 1997 21:28:17 -0700
Received: from coltrane (coltrane.ocs.columbia.edu [128.59.240.174]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id AAA04457; Thu, 8 May 1997 00:28:14 -0400 (EDT)
Message-Id: <33715499.673F at ctr.columbia.edu>
Date: Thu, 08 May 1997 00:20:41 -0400
Sender:ietf-request at ietf.org
From: "Andrew T. Campbell" <campbell at ctr.columbia.edu>
Organization: Center for Telecommunications Research, Columbia University
X-Mailer: Mozilla 2.01 (WinNT; I)
Mime-Version: 1.0
To: ietf at isi.edu
Cc: campbell at ctr.columbia.edu
Subject: Hot QOS Workshop: Advance Program
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from 8bit to quoted-printable by sirius.ctr.columbia.edu id AAA04457
Source-Info: From (or Sender) name not authenticated.
-
A D V A N C E P R O G R A M
IFIP 5th International Workshop on Quality=20
of Service
IWQOS'97
- Building QOS into Distributed Systems=20
-
Columbia University, New York
May 21-23, 1997
=20
http://comet.ctr.columbia.edu/iwqos97/
The objective of the IFIP 5th International=20
Workshop on Quality
of Service (IWQOS) is to bring together=20
researchers and
practitioners working in all facets of QOS=20
research. While many
workshops and conferences offer technical sessions=20
on the topic
of QOS, none other than IWQOS provides a single=20
track workshop
dedicated to QOS research.
We think we have a great technical program lined
up for you this year. The program reflects our=20
desire to hear
about new ideas, experimental results,=20
controversial QOS
subjects and perspectives on where we are and=20
where we are going.
IWQOS=9297 is designed to be an interactive workshop=20
and
not a =91sit and listen=92 conference. To reflect that=20
goal,
technical sessions include long and short papers=20
followed
by a thirty minute panel discussion of topics=20
raised during
the session.
THE PROGRAM AT A GLANCE:
--------------------------------------------------
Wednesday May 21, 1997
--------------------------------------------------
1 Keynote address
"Programming Telecommunications Networks"
Aurel A. Lazar
=20
2 Mobile Communications
Session Chair: Mahmound Nagshineh
3 Traffic Management
Session Chair: Ed Knightly
4 QOS Routing
Session Chair: Mischa Schwartz
5 QoS and Video Systems
Session Chair: Alexandros Eleftheriadis
6 Reception and Demos
--------------------------------------------------
Thursday May 22, 1997
--------------------------------------------------
7 QoS Management
Session Chair: Andreas Vogel
8 Panel I: "QOS for Distributed Object Computing=20
Middleware
- Fact or Fiction?"
Chair and Organizer: Douglas C. Schmidt
9 Workshop Invited Paper "Quality of Service:=20
Where are we ?"
R. Steinmetz and L. C. Wolf
10 Distributed Object Computing
Session Chair: Douglas Schmidt
11 Advanced Reservation
Session Chair: Hideyuki Tokuda
12 Workshop banquet and boat cruise around the Big=20
Apple
--------------------------------------------------
Friday May 23, 1997
--------------------------------------------------
13 QOS-based Transport Protocols
Session Chair: Steve Pink
=20
14 Panel II: Reservations about Reservations
Chair and Organizer: Henning G. Schulzrinne
15 QoS Mapping
Session Chair: Jean-Peirre Huaux
16 QoS Adaptation
Session Chair: Klara Nahrstedt
--------------------------------------------------
REGISTRATION INFORMATION
For on line registration, workshop information and=20
technical
program details click on:
=20
http://comet.ctr.columbia.edu/iwqos97/
DETAILED PROGRAM:
--------------------------------------------------
------------------
Wednesday Day 1 : 21 May 1997
--------------------------------------------------
------------------
8:50-9:00 am Workshop Welcome
Andrew T. Campbell, Columbia=20
University
Klara Nahrstedt, University=20
of Illinois at
Urbana-Champaign
9:00-10:00 am Keynote Address
"Programming=20
Telecommunications Networks",
Aurel A. Lazar, Columbia=20
University, USA
10:30-12:30pm Technical Session 1 - Mobile=20
Communications
Session Chair: Mahmound=20
Nagshineh, IBM, USA
Long Paper Presentations
Adaptive Service in=20
Mobile Computing
Environments
S. Lu, K.-W. Lee and V.=20
Bharghavan
University of Illinois=20
at Urbana-
Champaign, USA
Quality of Service=20
Support in a Mobile
Environment: An=20
Approach Based on Tuple
Spaces
G. Blair, N.Davies, A.=20
Friday and S.Wade
(Lancaster University,=20
UK)
Short Paper Presentations
IPv6 + Mobile-IP +=20
MRSVP =3D Internet Cellular
Phone ?
B. R. Badrinath and A.=20
K. Talukdar (Rutgers
University, USA)
QoS Challenges for Next=20
Generation Mobile
Middleware
A. T. Campbell=20
(Columbia University, USA)
Link Error Impact on=20
MPEG Video over Wireless
Broadband Networks
J. G.- Castellanos=20
(Columbia University, USA)
and M. Naghshineh (IBM,=20
USA)
QoS Support for Mobile=20
Computing
S. Pope and P. Webster=20
(Olivetti & Oracle
Research Lab, UK)
Session Panel Discussion
12:30-1:30pm L u n=20
c h
1:30-3:00pm Technical Session 2 -=20
Traffic Management
Session Chair: Ed Knightly,=20
Rice University, USA
Long Paper Presentations
Worst Case Arrivals of=20
Leaky
Bucket Constrained=20
Sources:
The Myth of the On-Off=20
source
P. Oechslin (University=20
College of
London, UK)
Guaranteeing Multiple=20
Cell Loss Classes in
Shared ATM Output=20
Buffer
H. Lee (Korea Telecom,=20
Korea)
Comprehensive Queueing=20
Analysis for a Partial
Buffer System with=20
Discrete Markovian Arrival
Processes
D. Becker (Aachen=20
University of Technology,
Germany)
Short Paper Presentation
Real-Time Estimation of=20
the Link Capacity in
Multimedia Networks
P. Maryni (University=20
of Genoa, Italy) and G.
Pacifici (IBM,USA)
Session Panel Discussion
3:15-4:15pm Technical Session 3 - QOS=20
Routing
Session Chair: Mischa=20
Schwartz,
Columbia University,USA
Long Paper Presentation
Quality of Service=20
Routing for Traffic with
Performance Guarantees
Q. Ma and P. Steenkiste=20
(Carnegie Mellon
University, USA)
Short Paper Presentation
QoS Based Multicast=20
Routing for Multimedia
Communications
S. Verma, R. K. Pankaj=20
and A. Leon-Garcia
(University of Toronto,=20
Canada)
Session Panel Discussion
4:30-6:00pm Technical Session 4 - QoS=20
and Video Systems
Session Chair: Alexandros=20
Eleftheriadis, Columbia
University, USA
Long Paper Presentations
Supporting=20
Multiple-tier QoS in a Video
Bridging Application
R. Koodli, and C. M.=20
Krishna (University of
Massachusetts, USA)
Playout Management of=20
Interactive Video - an
Adaptive Approach
S. K. Jha, P. A. Wright=20
and M. Fry
University of=20
Technology, Sydney, Australia
Short Paper Presentations
A Temporal QoS based=20
CPU Scheduling Model for
Multimedia Applications=20
in General Purpose
Operating Systems
D. B. Waldegg (Telecom=20
Bretagne, France)
Adaptive Video=20
Applications for Non-QoS
Networks, S. Jacobs and=20
A. Eleftheriadis
Columbia University,=20
USA
Session Panel Discussion
6:00-8:00 Reception and Demos
--------------------------------------------------
------------
Thursday Day 2: 22 May=20
1997
--------------------------------------------------
------------
8:30-10:15am Technical Session 5 - QoS=20
Management
Session Chair: Andreas Vogel,=20
Visgenic Corp., USA
Long Paper Presentations
Integrated CPU and Network=20
I/O QoS Management in an
Endsystem
K. Lakshman, R. Yavatkar and=20
R. Finkel (Intel, USA)
Service-Tailored QoS=20
Management in High Performance
Networks
R. Bless, M. Jacob and C.=20
Schmidt (University of
Karlsruhe, Germany)
Short Paper Presentations
Application Design for=20
Cooperative QoS Management
S. Fischer, M.-V. O. M. Salem=20
and G. v. Bochmann
(University of Montreal,=20
Canada)
On the Specification of=20
End-to-End QoS Control
J. B. de Meer (GMD FOKUS,=20
Germany)
Using attribute-managed=20
storage to achieve QoS
E. Borowsky, R. Golding, A.=20
Merchant,
L. Schreier, E. Shriver, M.=20
Spasojevic
and J. Wilkes=20
(Hewlett-Packard
Laboratories, USA)
Session Panel Discussion
10:30-12:00m Panel I - QOS for Distributed=20
Object Computing
Middleware - Fact or Fiction ?
Chair: Douglas C. Schmidt,=20
Washington University, USA
Panelists:
Max Ott, NEC, USA
Guru Parulkar, Washington U., USA
Rolf Stadler, Columbia U., USA
Andreas Vogel, Visigenic, USA
12:00-1:00pm L u n c h
1:00-2:00pm Invited Speaker
Quality of Service: Where are we ?
R. Steinmetz and L. C. Wolf
(Darmstadt University, Germany)
2:15-4:00pm Technical Session 6 - Distributed=20
Object Computing
Session Chair: Douglas Schmidt,=20
Washington University at
St. Louis, USA
Long Paper Presentations
Integrating QoS Restrictions=20
into the Process of
Service Selection
C. Linnhoff-Popien and D.=20
Thissen (Aachen
University of Technology,=20
Germany)
Quality of Service (QoS) in=20
Communication APIs
W. Almesberger (EPFL DI-LRC,=20
Switzerland), S.
Sasyan (Hewlett Packard,=20
France) and S. Wright (
Fujitsu
Network Communications,=20
France)
Short Paper Presentations
Managing Systemic Meta-Data=20
for Creating
QoS-Adaptive CORBA=20
Applications
J. A. Zinky and D. E. Bakken=20
(BBN Systems and
Technologies, USA)
Support Components for=20
Quality of Service in
Distributed Environments:=20
Monitoring Service
D. A. Reed and K. J. Turner=20
(University of
Sterling, UK)
A QoS Configuration System=20
for Distributed
Applications
A. Smith and A. Grace=20
(Distributed Systems
Group, BT Laboratories, UK)
Session Panel Discussion
4:15-5:15pm Technical Session 7 - Advanced=20
Reservation
Session Chair: Hideyuki Tokuda,=20
Keio University, Japan
Long Paper Presentations
Sharing Resources through=20
Advance Reservation
Agents
O. Schelen & S. Pink (Swedish=20
Institute of
Computer Science, Sweden)
Providing a Scalable=20
Video-on-Demand System using
Future Reservation of=20
Resources and Multicast
Communications
A. Hafid (Computer Research=20
Institute of Montreal,
Canada)
Session Panel Discussion
7.30-10.30 Workshop Banquet and Cruise around=20
the Big Apple
=20
--------------------------------------------------
-------------------
Friday Day 3: 23 May=20
1997
--------------------------------------------------
-------------------
9:00-10:30am Technical Session 8 - QOS-based=20
Transport Protocols
Session Chair: Steven Pink,=20
Swedish Institute
of Computer Science, Sweden
Long Paper Presentations
QoS Mapping between User's=20
Preference and
Bandwidth Control for Video=20
Transport
K. Fukuda, N. Wakamiya, M.=20
Murata and H. Miyahara
(Osaka University, Japan)
On End-to-End QoS Mapping
J.-F. Huard and A. A. Lazar=20
(Columbia University,
USA)
Short Paper Presentations
Transport QoS over=20
Unreliable Networks: No
Guarantees, No Free Lunch!
P. Conrad, P. Amer, E.=20
Golden, S. Iren, R. Marasli
and A. Caro (University of=20
Delaware, USA)
QoS-Based Transport
G. Mapp and S. Hodges=20
(Olivetti & Oracle Research
Lab, UK)
Session Panel Discussion
10:45-12:00pm Panel II - Reservations about=20
Reservations
Chair: Henning G. Schulzrinne,=20
Columbia University, USA
Panelists:
Fred Baker, CISCO, USA
Jon Crowcroft, UCL, UK
Roch Guerin, IBM, USA
Lixa Zhang, UCLA, USA
12:00-1:00pm L u n c=20
h
1:00-2:30pm Technical Session 9 - QoS Mapping
Session Chair: Jean-Peirre Huaux,=20
EPFL, Switzerland
Long Paper Presentations
Simplified Method for=20
Session Coordination Using
Multi-level QOS=20
Specification and Translation
N. Nishio and H. Tokuda=20
(Keio University, Japan)
Quantitative QoS-Mapping: A=20
Unifying Approach
H. Knoche and H. de Meer=20
(University of Hamburg,
Germany)
Short Paper Presentations
QoS Translation and=20
Admission Control for
MPEG Video
K. Kim and K. Nahrstedt=20
(University of Illinois at
Urbana-Champaign, USA)
Towards Specifying=20
QoS-Enabling Software
Architectures
V. Issarny, C. Bidan, F.=20
Leleu and T. Saridakis
(IRISA/INRIA, France)
Session Panel Discussion
2:45-4:15pm Technical Session 10 - QoS=20
Adaptation
Session Chair: Klara Nahrstedt,=20
University of Illionis
AT Urbana-Champaign, USA
Long Paper Presentations
Terminal QoS of Adaptive=20
Applications and its
Analytical Computation
P. Moghe and A. Kalavade=20
(Bell-Labs, USA)
End-to-End Quality of=20
Service Control Using
Adaptive Applications
D. Sisalem (GMD FOKUS,=20
Germany)
Short Paper Presentations
Adaptive QoS and in=20
Multimedia Systems
M. Ott, G. Michelitsch, D.=20
Reininger and G.
Welling (NEC, USA)
A Dynamic QoS Adaptation for=20
Networked Virtual
Reality
S. Oh, H. Sugano, S.=20
Shimojo, H. Miyahara (Osaka
University, Japan), K.=20
Fujikawa (Nara Institute of
Science and Technology,=20
Japan), T. Matsuura (Osaka
City University, Japan),=20
M.Arikawa(Hiroshima City
University, Japan)
Predictable File Access=20
Latency for Multimedia
D. Revel, C. Cowan, D.=20
McNamee,
C. Pu and J. Walpole
(Oregan State Institute,=20
USA)
Session Panel Discussion
--
Andrew T. Campbell =20
http://comet.ctr.columbia.edu/~campbell
Wireless Media Systems Project=20
http://comet.ctr.columbia.edu/wireless
Received: from cnri by ietf.org id aa23902; 8 May 97 1:31 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02323;
8 May 97 1:31 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <DAA02159 at pad-thai.cam.ov.com>; Thu, 8 May 1997 03:59:30 GMT
Message-Id: <2.2.32.19970508035650.006d6cdc at nitro.openhorizon.com>
X-Sender: jmoreh at nitro.openhorizon.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 07 May 1997 20:56:50 -0700
To: Didier GUERIN <didier.guerin at sept.fr>
From: Jahan Moreh <jmoreh at openhorizon.com>
Subject: Re: CAT: GSS-API security products (research)
Cc: " (IETF CAT Group)" <cat-ietf at mit.edu>
Precedence: bulk
Didier,
At 05:59 PM 5-7-97 +0200, Didier GUERIN (Tel 3331759219) wrote:
>I'm looking for security products using GSS-API. I have made some research
with those keywords and find the following products/references:
>- SecuDE from GMD,
>- DCE from OSF,
>- SESAME from a RACE research project,
>- ISM/AccessMaster from Bull.
Checkout
CyberSafe Challenger (Kerberso underneath GSS API)
EntrustSession (Public key underneath GSS API)
>Does anybody knows some other references, including products that can be
used with TCP/IP?
GSS API is communication independent. All implementations of the GSS API, by
definition, have nothing to say about the
network protocols.
>I'm interesting on authentication, access control and integrity features
(optionaly encryption capabilities).
>Thanks in advance
>Didier
>didier.guerin at sept.fr
>
>
-------------------------------------------------
Jahan Moreh
Security Architect
Open Horizon, Inc.
tel: 310 476 3767
fax: 310 476 7189
email: jmoreh at openhorizon.com
For additional information about Open Horizon
please send email to info at openhorizon.com or
visit our web site at http://www.openhorizon.com
Received: from cnri by ietf.org id aa29478; 8 May 97 8:46 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07798;
8 May 97 8:46 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <LAA18394 at pad-thai.cam.ov.com>; Thu, 8 May 1997 11:27:00 GMT
Message-Id: <3371A960.156A at gil.com.au>
Date: Thu, 08 May 1997 21:22:24 +1100
From: Robert Fox <rfox at gil.com.au>
X-Mailer: Mozilla 2.02 (Win95; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu
Subject: GSS-API at different levels
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Is it possible that a site may have an application secured with the
GSS-API, that this application may also use say ONC-RPC which also
may use the GSS-API, and that the RPC may use SocksV5 which also uses
the GSS-API ?
In which case each layer will authenticate the relevant identities in
the communication and if each layer chooses to encrypt the message it
may well be triple encrypted.
Is there a problem in the GSS-API being used at different "functional
levels".
Robert Fox
Student @ Queensland University of Technology
Brisbane Queensland
Australia
Received: from cnri by ietf.org id aa01242; 8 May 97 9:37 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08800;
8 May 97 9:37 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <MAA20277 at pad-thai.cam.ov.com>; Thu, 8 May 1997 12:01:46 GMT
Message-Id: <199705081201.IAA01232 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Marc Horowitz <marc at cygnus.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: scope: HL vs ANSI C bindings
In-Reply-To: Your message of "04 May 1997 19:08:04 EDT."
<t53enbmbzu3.fsf at rover.cygnus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 08:01:41 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Re:
>There are long discussions in the C bindings document about the
>semantics of gssapi. These discussions are useful, but in general
>they are either redundant with the HL spec, which will cause trouble
>when they drift apart, or they are missing from the HL spec, and
>should be moved there. It seems that the C bindings document should
>be essentially a mapping of C onto the high-level spec. I figure
>about 90% of this can be accomplished by a header file annotated by
>references to the HL spec. The other 10% is C-specific details, such
>as the iterative approach to gss_display_name and example code for
>init and accept_sec_context.
>
>I'd like to see the C bindings mostly gutted, and the stuff which
>isn't redundant rolled into rfc2078.
Had history evolved differently, we might have arrived at the result
Marc suggests. However, we've worked for some time with the
high-level specification and the C bindings within their established
scopes and relationships, both are now fairly mature documents, and
both would require non-trivial reworking to adapt to a new model; this
would add delay to the current process (which I believe to be near to
convergence) of advancing the C bindings and identifying specific
alignments needed in RFC2078bis. Further, I've heard several people
indicate that they appreciate the self-sufficiency of the current C
bindings as a convenient single reference for coding purposes, and it
can sometimes be a good and useful thing to have two consistent
expositions of the same material, presenting an agreed concept in
different terms. At this juncture, therefore, I suggest that we
continue to focus on aligning the documents in their current form,
recognizing that some content is represented in both documents. Where
semantic discussions with environment-independent scope appear in the
C bindings, I believe that their content should also be reflected in
RFC2078bis; any such discussions should be consistent between the
documents.
--jl
Received: from ietf.org by ietf.org id aa01425; 8 May 97 9:40 EDT
Received: from ietf.ietf.org by ietf.org id aa00797; 8 May 97 9:31 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-dusse-smime-cert-01.txt
Date: Thu, 08 May 1997 09:31:12 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705080931.aa00797 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : S/MIME Certificate Handling
Author(s) : S. Dusse, P. Hoffman, B. Ramsdell,
L. Lundblade, L. Repka
Filename : draft-dusse-smime-cert-01.txt
Pages : 12
Date : 05/07/1997
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a standard way to send and receive secure MIME
messages. In order to validate the keys of a message sent to it, an S/MIME
agent needs to certify that the key is valid. This draft describes the
mechanisms S/MIME uses to create and validate keys using certificates.
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-dusse-smime-cert-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dusse-smime-cert-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-dusse-smime-cert-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: <19970507140938.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dusse-smime-cert-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dusse-smime-cert-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507140938.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01426; 8 May 97 9:40 EDT
Received: from ietf.ietf.org by ietf.org id aa00779; 8 May 97 9:31 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-hoffman-smtp-ssl-01.txt
Date: Thu, 08 May 1997 09:31:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705080931.aa00779 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SMTP Service Extension for Secure SMTP over TLS
Author(s) : P. Hoffman
Filename : draft-hoffman-smtp-ssl-01.txt
Pages : 4
Date : 05/07/1997
This document describes an extension to the SMTP service that allows an
SMTP server and client to use transport-layer security to provide private,
authenticated communication over the Internet. This gives SMTP agents the
ability to protect some or all of their communications from eavesdroppers
and attackers.
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-hoffman-smtp-ssl-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-smtp-ssl-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-hoffman-smtp-ssl-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: <19970507140554.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-smtp-ssl-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-smtp-ssl-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507140554.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01428; 8 May 97 9:40 EDT
Received: from ietf.ietf.org by ietf.org id aa00835; 8 May 97 9:31 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-inarp-update-01.txt
Date: Thu, 08 May 1997 09:31:18 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705080931.aa00835 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 : Inverse Address Resolution Protocol
Author(s) : T. Bradley, C. Brown, A. Malis
Filename : draft-ietf-ion-inarp-update-01.txt
Pages : 7
Date : 05/07/1997
This memo describes additions to ARP that will allow a station to request a
protocol address corresponding to a given hardware address. Specifically,
this applies to Frame Relay stations that may have a Data Link Connection
Identifier (DLCI), the Frame Relay equivalent of a hardware address,
associated with an established Permanent Virtual Circuit (PVC), but do not
know the protocol address of the station on the other side of this
connection. It will also apply to other networks with similar
circumstances.
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-inarp-update-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-inarp-update-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-ion-inarp-update-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: <19970507153544.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-inarp-update-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-inarp-update-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507153544.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01424; 8 May 97 9:40 EDT
Received: from ietf.ietf.org by ietf.org id aa00816; 8 May 97 9:31 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-dusse-smime-msg-01.txt
Date: Thu, 08 May 1997 09:31:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705080931.aa00816 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : S/MIME Message Specification
Author(s) : S. Dusse, P. Hoffman, B. Ramsdell,
L. Lundblade, L. Repka
Filename : draft-dusse-smime-msg-01.txt
Pages : 21
Date : 05/07/1997
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a standard
way to send and receive secure MIME data. Based on the popular Internet
MIME standard, S/MIME provides the following cryptographic security
services for electronic messaging applications: authentication, message
integrity and non-repudiation of origin (using digital signatures) and
privacy and data security (using encryption).
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-dusse-smime-msg-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dusse-smime-msg-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-dusse-smime-msg-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: <19970507141359.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dusse-smime-msg-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dusse-smime-msg-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507141359.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01427; 8 May 97 9:40 EDT
Received: from ietf.ietf.org by ietf.org id aa00725; 8 May 97 9:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: grip-wg at uu.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-grip-framework-irt-05.txt
Date: Thu, 08 May 1997 09:31:05 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705080931.aa00725 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 G and R for Security
Incident Processing Working Group of the IETF.
Title : Expectations for Security Incident Response
Author(s) : N. Brownlee, E. Guttman
Filename : draft-ietf-grip-framework-irt-05.txt
Pages : 32
Date : 05/07/1997
The purpose of this document is to express the general Internet community's
expectations of Security Incident Response Teams (SIRTs). It is not
possible to define a set of requirements that would be appropriate for all
teams, but it is possible and helpful to list and describe the general set
of topics and issues which are of concern and interest to constituent
communities.
SIRT constituents have a legitimate need and right to fully understand the
policies and procedures of "their" Security Incident Response Team. One
way to support this understanding is to supply detailed information which
users may consider, in the form of a formal template completed by the SIRT.
An outline of such a template and a filled in example are provided.
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-grip-framework-irt-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-grip-framework-irt-05.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-grip-framework-irt-05.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: <19970507110907.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-grip-framework-irt-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-grip-framework-irt-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507110907.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01422; 8 May 97 9:40 EDT
Received: from ietf.ietf.org by ietf.org id aa00889; 8 May 97 9:31 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-sig-uni4.0-03.txt
Date: Thu, 08 May 1997 09:31:32 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705080931.aa00889 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 : ATM Signalling Support for IP over ATM - UNI 4.0 Update
Author(s) : M. Maher
Filename : draft-ietf-ion-sig-uni4.0-03.txt
Pages : 25
Date : 05/07/1997
This memo describes how to efficiently use the ATM call control signalling
procedures defined in UNI 4.0 [UNI96] to support IP over ATM environments
as described in RFC 1577 [LAUB94] and in [LUC97]. Among the new features
found in UNI 4.0 signalling are Available Bit Rate (ABR) signalling and
traffic parameter negotiation. This draft highlights the features of UNI
4.0 signalling that provide IP entities capabilities for requesting ATM
service in sites with SVC support, whether it is private ATM or publicly
provisioned ATM, in which case the SVC support is probably configured
inside PVPs.
This document is only relevant to IP when used as the well known "best
effort" connectionless service. In particular, this means that this
document does not pertain to IP in the presence of implemented IP
Integrated Services (ISS). The topic of IP with ISS over ATM will be
handled by a different specification or set of specifications being worked
on in the ISSLL WG.
This specification is follow-on to RFC 1755, "ATM Signaling Support
for IP over ATM", which is based on UNI signalling 3.1.
Readers are assumed to be familiar with RFC 1755.
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-sig-uni4.0-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-sig-uni4.0-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-ion-sig-uni4.0-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: <19970507165734.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-sig-uni4.0-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-sig-uni4.0-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507165734.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01423; 8 May 97 9:40 EDT
Received: from ietf.ietf.org by ietf.org id aa00853; 8 May 97 9:31 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-newman-url-imap-08.txt
Date: Thu, 08 May 1997 09:31:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705080931.aa00853 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 : IMAP URL Scheme
Author(s) : C. Newman
Filename : draft-newman-url-imap-08.txt
Pages : 15
Date : 05/07/1997
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It
provides an ideal mechanism for accessing public mailing list archives as
well as private and shared message stores. This document defines a URL
scheme for referencing objects on an IMAP 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-newman-url-imap-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-url-imap-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-newman-url-imap-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: <19970507160112.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-url-imap-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-url-imap-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507160112.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01421; 8 May 97 9:40 EDT
Received: from ietf.ietf.org by ietf.org id aa00871; 8 May 97 9:31 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-fr-update-03.txt
Date: Thu, 08 May 1997 09:31:27 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705080931.aa00871 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.
Note: This revision reflects comments received during the last call period.
Title : Multiprotocol Interconnect over Frame Relay
Author(s) : C. Brown, A. Malis
Filename : draft-ietf-ion-fr-update-03.txt
Pages : 34
Date : 05/07/1997
This memo describes an encapsulation method for carrying network
interconnect traffic over a Frame Relay backbone. It covers aspects of
both Bridging and Routing.
Systems with the ability to transfer both the encapsulation method
described in this document, and others must have a priori knowledge of
which virtual circuits will carry which encapsulation method and this
encapsulation must only be used over virtual circuits that have been
explicitly configured for its use.
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-fr-update-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-fr-update-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-ion-fr-update-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: <19970507160746.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-fr-update-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-fr-update-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507160746.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08824; 8 May 97 12:44 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa08613; 8 May 97 12:38 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 MAA24062;
Thu, 8 May 1997 12:34:24 -0400
Message-Id: <199705081634.MAA24062 at black-ice.cc.vt.edu>
To: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org
Cc: Karl Mulder <KMULDER at vm.nmu.edu>, Brad Knowles <BKnowles at aol.net>
Subject: Re: AOL mail traffic
In-Reply-To: Your message of "Thu, 08 May 1997 11:28:14 EST."
<IBMTCP-L%97050811273669 at VM.MARIST.EDU>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <IBMTCP-L%97050811273669 at VM.MARIST.EDU>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1975136936P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 08 May 1997 12:34:20 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1975136936P
Content-Type: text/plain; charset=us-ascii
On Thu, 08 May 1997 11:28:14 EST, you said:
> We run the MUSIC operating system as a guest under VM. Today I received
> the following reply when trying to send email from MUSIC via VM SMTP to
> AOL.
>
> VM.NMU.EDU unable to deliver following mail to recipient(s):
> <whaske at aol.com>
> VM.NMU.EDU received negative reply:
> 553 <@VM.NMU.EDU:SPKM at NMU.EDU>... Source routed envelope sender
> rejected (See RFC 822, section 6.2.7)
>
> Has anyone else seen anything like this? It was working last week and
> its my "belief" that I didn't change anything...
(Am CC'ing this reply to several places - apparently more people are
complaining now....)
AOL has decided to unilaterally violate RFC1123, sections 5.2.19,
which requires accepting source routes, in favor of an
as-yet-still-draft future standard that permits rejecting these. We
have already contacted AOL, and they seem to feel that the language in
RFC1123, section 5.2.6 which permits simply ignoring the source route,
is insufficient.
We have been informed by Brad Knowles of AOL that they consider
section 7.5 of draft-ietf-drums-smtpupd-04.txt (still in draft status)
to be more important than RFC1123, which is in full standard status.
Quite frankly, this is no way to run an Internet. Once the DRUMS
document moves up to Proposed Standard status or so, I'll support
AOL's right to implement it. But disregarding the standards in favor
of a draft is no way to do business, even if you do have the most
market share.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_-1975136936P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM3IAiNQBOOoptg9JAQGhgwP9HTrEMfmOps0tLKofanOwdnW7vlfMx32V
xf4RfezAVEuJI9cA/4fxNWKcJP89nNttJtCa51q1H8gO6/AmC78Rd0YzKMMQ1xBo
SZ1+A538iNNdYjpb7ds0PzSzz+ns4X9CM7NIuyWlyev8Lvcu4FjpCMMvgT+GXRBi
0LbenpVHRy0=
=L8tg
-----END PGP MESSAGE-----
--==_Exmh_-1975136936P--
Received: from ietf.org by ietf.org id aa09416; 8 May 97 12:58 EDT
Received: from dragonfly.cisco.com by ietf.org id aa09313; 8 May 97 12:56 EDT
Received: from groeck-pc.cisco.com (dhcp-o-44-233.cisco.com [171.71.44.233]) by dragonfly.cisco.com (8.6.12/8.6.5) with SMTP id JAA01412; Thu, 8 May 1997 09:52:35 -0700
Message-Id: <2.2.32.19970508164939.00981d88 at dragonfly.cisco.com>
X-Sender: groeck at dragonfly.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 08 May 1997 09:49:39 -0700
To: Valdis.Kletnieks at vt.edu
Sender:ietf-request at ietf.org
From: Guenter Roeck <groeck at cisco.com>
Subject: Re: AOL mail traffic
Cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org, Karl Mulder <KMULDER at vm.nmu.edu>,
Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
If the intention is to prevent spamming I fully agree with AOL.
IMHO, if an existing standard is broken it should not be used,
but replaced with a better approach, even if it is not standardized.
Guenter
At 12:34 PM 5/8/97 -0400, Valdis.Kletnieks at vt.edu wrote:
>On Thu, 08 May 1997 11:28:14 EST, you said:
>> We run the MUSIC operating system as a guest under VM. Today I received
>> the following reply when trying to send email from MUSIC via VM SMTP to
>> AOL.
>>
>> VM.NMU.EDU unable to deliver following mail to recipient(s):
>> <whaske at aol.com>
>> VM.NMU.EDU received negative reply:
>> 553 <@VM.NMU.EDU:SPKM at NMU.EDU>... Source routed envelope sender
>> rejected (See RFC 822, section 6.2.7)
>>
>> Has anyone else seen anything like this? It was working last week and
>> its my "belief" that I didn't change anything...
>
>(Am CC'ing this reply to several places - apparently more people are
>complaining now....)
>
>AOL has decided to unilaterally violate RFC1123, sections 5.2.19,
>which requires accepting source routes, in favor of an
>as-yet-still-draft future standard that permits rejecting these. We
>have already contacted AOL, and they seem to feel that the language in
>RFC1123, section 5.2.6 which permits simply ignoring the source route,
>is insufficient.
>
>We have been informed by Brad Knowles of AOL that they consider
>section 7.5 of draft-ietf-drums-smtpupd-04.txt (still in draft status)
>to be more important than RFC1123, which is in full standard status.
>
>Quite frankly, this is no way to run an Internet. Once the DRUMS
>document moves up to Proposed Standard status or so, I'll support
>AOL's right to implement it. But disregarding the standards in favor
>of a draft is no way to do business, even if you do have the most
>market share.
>
>--
> Valdis Kletnieks
> Computer Systems Senior Engineer
> Virginia Tech
>
>
>
>Attachment Converted: C:\Data\Email\Attachments\Re AOL mail traffic
>
Received: from ietf.org by ietf.org id aa10379; 8 May 97 13:18 EDT
Received: from janus.border.com by ietf.org id aa10292; 8 May 97 13:17 EDT
Received: by janus.border.com id <11649>; Thu, 8 May 1997 13:08:23 -0400
Message-Id: <97May8.130823edt.11649 at janus.border.com>
To: Valdis.Kletnieks at vt.edu
cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org, Karl Mulder <KMULDER at vm.nmu.edu>,
Brad Knowles <BKnowles at aol.net>, PDMAtropos at aol.com
Subject: Re: AOL mail traffic
References: <IBMTCP-L%97050811273669 at VM.MARIST.EDU>
<199705081634.MAA24062 at black-ice.cc.vt.edu>
In-reply-to: Valdis.Kletnieks's message of "Thu, 08 May 1997 12:34:20 -0400".
<199705081634.MAA24062 at black-ice.cc.vt.edu>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at utcc.utoronto.ca>
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did at Pr9
Date: Thu, 8 May 1997 13:12:42 -0400
X-Orig-Sender: chk at rafael.rnd.border.com
Source-Info: From (or Sender) name not authenticated.
In message <199705081634.MAA24062 at black-ice.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes:
> On Thu, 08 May 1997 11:28:14 EST, you said:
> > We run the MUSIC operating system as a guest under VM. Today I received
> > the following reply when trying to send email from MUSIC via VM SMTP to
> > AOL.
> >
> > VM.NMU.EDU unable to deliver following mail to recipient(s):
> > <whaske at aol.com>
> > VM.NMU.EDU received negative reply:
> > 553 <@VM.NMU.EDU:SPKM at NMU.EDU>... Source routed envelope sender
> > rejected (See RFC 822, section 6.2.7)
> >
> > Has anyone else seen anything like this? It was working last week and
> > its my "belief" that I didn't change anything...
I too have seen this. We use ZMailer, a somewhat popular MTA written by
Rayan Zachariassen. ZMailer routinely inserts source routing information in
the envelope From: entries when it is used as a mail relay. Many Internet
sites still use "smart-hosts" for off-site mail delivery. I suspect that AOL
is suddenly bouncing alot of mail.
> We have been informed by Brad Knowles of AOL that they consider
> section 7.5 of draft-ietf-drums-smtpupd-04.txt (still in draft status)
> to be more important than RFC1123, which is in full standard status.
This section talks about "use of the relay function through arbitrary
sites". However, AOL's solution is also blocking *legitimate* use of the
relay function. Internet firewalls and site-wide smart hosts are a couple of
examples of legitimate uses.
I run a mailing list from a machine at home, connected to the Internet via a
skinny pipe. I forward messages from the list to my ISPs smart-host, and let
them do the expansion of the message into multiple copies. That allows me to
preserve the bandwidth of my connection, and actually increases reliability
(since my ISP pays more attention to host uptimes than I do).
My ISP uses ZMailer (sense a pattern here?). AOL is now denying mail to some
of my subscribers as a result of my attempts to *legitimately* use SMTP
relays. My requests to postmaster have so far been met with silence; I've
recommended that my subscribers switch ISPs :-).
I realize that AOL is simply responding to customer requests to eliminate
spam. However, they've over-stepped the boundary between that and keeping
legitimate e-mail flowing.
--
Harald Koch <chk at utcc.utoronto.ca>
Received: from ietf.org by ietf.org id aa11694; 8 May 97 13:28 EDT
Received: from mail-relay.EU.net by ietf.org id aa11362; 8 May 97 13:26 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 TAA01700; Thu, 8 May 1997 19:23:02 +0200 (MET DST)
Received: by jotun.EU.net id AA08330
(5.67a/IDA-1.5); Thu, 8 May 1997 19:23:01 +0200
Message-Id: <199705081723.AA08330 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <pgb at eu.net>
Date: Thu, 8 May 1997 19:23:00 +0200
In-Reply-To: <199705081634.MAA24062 at black-ice.cc.vt.edu>
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Valdis.Kletnieks at vt.edu
Subject: Re: AOL mail traffic
Cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org, Karl Mulder <KMULDER at vm.nmu.edu>,
Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
On May 8, 12:34, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu> wrote:
> AOL has decided to unilaterally violate RFC1123, sections 5.2.19,
Ahh, but then RFC1123 is dated October 1989, and says:
Security Considerations
There are many security issues in the application and support
programs of host software, but a full discussion is beyond the scope
of this RFC.
Things were different in those days.
> Quite frankly, this is no way to run an Internet. Once the DRUMS
Have you tried talking to spammers about that? Obviously, I don't
know exactly why AOL has implemented this change, but there probably
is a good reason (if not, why do it?). Here's a note from one of
our customers in a somewhat remote, small European country:
> Dear all
>
> Ours machines are already in the spammer lists :-(
>
> Last Sunday someone from answerme.com used our relay to SPAM thousands
> of AOL users. This action began at 2 a.m. and the result was that by 9
> a.m. our server went down.
>
> Take care.
>
> David
--
------ ___ --- 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 domain
Received: from ietf.org by ietf.org id aa12311; 8 May 97 13:37 EDT
Received: from mailbag.jf.intel.com by ietf.org id aa12244; 8 May 97 13:36 EDT
Received: from aahz.jf.intel.com (aahz.jf.intel.com [192.198.161.2])
by mailbag.jf.intel.com (8.8.5/8.8.4) with SMTP
id KAA18268; Thu, 8 May 1997 10:34:14 -0700 (PDT)
Received: by aahz.jf.intel.com (Smail3.1.28.1 #13)
id m0wPX2n-000hxlC; Thu, 8 May 97 10:31 PDT
Message-Id: <m0wPX2n-000hxlC at aahz.jf.intel.com>
Sender:ietf-request at ietf.org
From: Alan Batie <batie at aahz.jf.intel.com>
Subject: Re: AOL mail traffic
To: Per Gregers Bilse <pgb at eu.net>
Date: Thu, 8 May 1997 10:31:53 -0700 (PDT)
Cc: Valdis.Kletnieks at vt.edu, IBMTCP-L at vm.marist.edu,
lstsrv-l at peach.ease.lsoft.com, ietf at ietf.org, KMULDER at vm.nmu.edu,
BKnowles at aol.net
In-Reply-To: <199705081723.AA08330 at jotun.EU.net> from "Per Gregers Bilse" at May 8, 97 07:23:00 pm
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> > Quite frankly, this is no way to run an Internet. Once the DRUMS
>
> Have you tried talking to spammers about that? Obviously, I don't
> know exactly why AOL has implemented this change, but there probably
> is a good reason (if not, why do it?).
Having recently implemented the latest sendmail to block my site from
being used as a relay, I can fully understand why they did it --- dealing
with source routes greatly complicated matters, and I'm still not certain
I got it right. I'm quite tempted to follow their lead.
Disclaimer: I'm referring to a non-Intel system, and I'm not speaking for
or representing Intel.
--
Alan Batie ------ What goes up, must come down.
batie at aahz.jf.intel.com \ / Ask any system administrator.
+1 503-264-8844 (voice) \ / --unknown
D0 D2 39 0E 02 34 D6 B4 \/ 5A 41 21 8F 23 5F 08 9D
Received: from ietf.org by ietf.org id aa13511; 8 May 97 14:04 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa13421; 8 May 97 14:03 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 NAA23796;
Thu, 8 May 1997 13:59:43 -0400
Message-Id: <199705081759.NAA23796 at black-ice.cc.vt.edu>
To: Per Gregers Bilse <pgb at eu.net>
Cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, ietf at ietf.org
Subject: Re: AOL mail traffic
In-Reply-To: Your message of "Thu, 08 May 1997 19:23:00 +0200."
<199705081723.AA08330 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199705081723.AA08330 at jotun.EU.net>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1726580432P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 08 May 1997 13:59:42 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1726580432P
Content-Type: text/plain; charset=us-ascii
On Thu, 08 May 1997 19:23:00 +0200, Per Gregers Bilse said:
> Ahh, but then RFC1123 is dated October 1989, and says:
>
> Security Considerations
>
> There are many security issues in the application and support
> programs of host software, but a full discussion is beyond the scope
> of this RFC.
>
> Things were different in those days.
Very True. However, if we're going to start unilaterally violating
standards, we better be *quite* sure why, and what the impact is. It
also helps if we're sure that it in fact fixes the problem.
> Have you tried talking to spammers about that? Obviously, I don't
> know exactly why AOL has implemented this change, but there probably
> is a good reason (if not, why do it?). Here's a note from one of
Why do it? Probably in an attempt to Do Something About Spam.
Whether it's the right answer or not seems to be irrelevant.
So far, I have not seen any clear technical explanation from anybody
at AOL why totally rejecting source routed SMTP (in violation of the
standards) is a Good Thing, and why they cannot follow the standards
by simply accepting and then discarding the source route. In fact,
this is *more* likely to stop spammage, as it prevents a number of
different scenarios involving broken/nonexistent addresses that are
reachable only via the SMTP relay mentioned in the source route.
I'm sure that in a week or so, the spammers will realize tha using a
source route to AOL doesn't work, and will start using %-hacks
instead. So AOL will bounce legitimate source-routed mail, not bounce
any spam based source routed mail, and start considering turning off
%-hacks as well.
Sounds like a business opportunity for a mail forwarding service just
waiting to happen.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_-1726580432P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM3IUjNQBOOoptg9JAQFr5AP+JHMQ0RaZ863WeadLg00UgW2ulQKbuOhe
Yw3HSwZ7Stj3Qa+p2G4EugxH4bCuaabenu6jVJLqweNbZTybw31H97mnIqAV3++i
8XBnKbKJXY3kInl+Nr4G+Ax/FEQphccB/CHYNoF3BfLb1FKhyVUqkgg3wZLUlTj/
3B1XS7GKdXg=
=+qli
-----END PGP MESSAGE-----
--==_Exmh_-1726580432P--
Received: from ietf.org by ietf.org id aa13625; 8 May 97 14:06 EDT
Received: from ns.jck.com by ietf.org id aa13539; 8 May 97 14:05 EDT
Received: from tp7.Jck.com ("port 1288"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0E9VJEF1500N40 at a4.jck.com>
for ietf at ietf.org; Thu, 8 May 1997 14:01:28 -0400 (EDT)
Date: Thu, 08 May 1997 14:01:27 -0400 (EDT)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: AOL mail traffic
In-reply-to: <97May8.130823edt.11649 at janus.border.com>
To: "C. Harald Koch" <chk at utcc.utoronto.ca>
Cc: Valdis.Kletnieks at vt.edu, PDMAtropos at aol.com,
Brad Knowles <BKnowles at aol.net>, Karl Mulder <KMULDER at vm.nmu.edu>,
ietf at ietf.org, lstsrv-l at peach.ease.lsoft.com,
IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9705081427.A at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Thu, 08 May 1997 13:12:42 -0400 "C. Harald Koch"
<chk at utcc.utoronto.ca> wrote:
> > We have been informed by Brad Knowles of AOL that they consider
> > section 7.5 of draft-ietf-drums-smtpupd-04.txt (still in draft status)
> > to be more important than RFC1123, which is in full standard status.
>
> This section talks about "use of the relay function through arbitrary
> sites". However, AOL's solution is also blocking *legitimate* use of the
> relay function. Internet firewalls and site-wide smart hosts are a couple of
> examples of legitimate uses.
>...
As the author of that text, there are three separate issues
here; confusion among them is unfortunate:
Q1: Is a site required to handle relay traffic that starts
from arbitrary sources and is destined for arbitrary sinks?
A: Nope. Sites can decline to accept mail for
substantially any reason they feel like. If the
sender or the intended recipient doesn't like it, he or she
can find a service with more attractive policies. This
answer is unchanged from 1123 and, really, from 821.
Choosing to invoke this rule and refuse to accept mail is
essentially a business decision, even if it is motivated
by, e.g., moral outrage.
Q2: What is a receiving host which chooses to relay mail
expected to do about source routes?
A: RFC1123 and ...smtpudp-04 really differ very little
here. Both permit the receiver to either follow the source
route chain or to discard it and just use the target
address. 1123 is slightly weighted toward preferring the
former, smtpupd-04 is significantly weighted toward
preferring the latter, but neither behavior is prohibited
by either spec as long as it is done properly.
Q3: If you can find a host that is willing to accept your
relay traffic, do you need source routes to make that
happen?
A: Nope. If I am sending mail to abc at d.e.f, and using
x.y.z as a relay, I can open an SMTP connection to x.y.z
and then send it a message whose envelope contains
RCPT TO:<abc at d.e.f>
Use of
RCPT TO:<@x.y.z:abc at d.e.f>
is neither necessary nor desirable. It was necessary for a
time in pre-DNS/ pre-MX days, but those are long gone.
Conversely, if I'm running host x.y.z, and I refuse to
accept your traffic for relaying, I'm going to do so
because I don't like you for some reason, and probably not
because you have chosen one of those forms over the other.
john
Received: from ietf.org by ietf.org id aa14953; 8 May 97 14:52 EDT
Received: from chrome.office.aol.com by ietf.org id aa14778; 8 May 97 14:48 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id OAA08984;
Thu, 8 May 1997 14:44:32 -0400 (EDT)
Message-Id: <199705081844.OAA08984 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: Valdis.Kletnieks at vt.edu
cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org, Karl Mulder <KMULDER at vm.nmu.edu>
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Thu, 08 May 1997 12:34:20 EDT."
<199705081634.MAA24062 at black-ice.cc.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 14:44:32 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Thu, 08 May 1997 12:34:20 EDT
> AOL has decided to unilaterally violate RFC1123, sections 5.2.19,
> which requires accepting source routes, in favor of an
> as-yet-still-draft future standard that permits rejecting these. We
> have already contacted AOL, and they seem to feel that the language in
> RFC1123, section 5.2.6 which permits simply ignoring the source route,
> is insufficient.
>
> We have been informed by Brad Knowles of AOL that they consider
> section 7.5 of draft-ietf-drums-smtpupd-04.txt (still in draft status)
> to be more important than RFC1123, which is in full standard status.
The concept presented in section 7.5 of
draft-ietf-drums-smtpupd-04.txt is older than the Internet itself.
It's been around as long as personal and group property laws have been
in existance.
Specifically, it's based on the "trespass against chattels"
issue, which has been the basis of a number of legal cases against
junkmailers.
Essentially, anyone has the right to protect themselves (or
their property) against abuse from others, especially against being
compelled to bear the brunt of the cost of the act of abuse.
Thus, section 7.5 of draft-ietf-drums-smtpupd-04.txt is merely
publicly recognizing a fact that has been well-known for hundreds of
years, so well known that it previously was not considered necessary
to actually put it down on paper as part of an RFC or draft.
If you refute this position, then I have a bridge to drop on you
that I'd like to force you to pay me for, as well as the resulting
legal fees that would result from the action that your estate would
presumably take against me. ;-)
In this specific case, I regret that a small number of legitimate
mail messages will be caught by this measure we've taken to protect
the AOL mail system, but when you do the cost/benefits analysis of
the value of those few messages to the value of the entire AOL mail
system (and the value of that system to our eight million users),
you'll see that we simply had no choice.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa15025; 8 May 97 14:52 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa14907; 8 May 97 14:51 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 OAA22660;
Thu, 8 May 1997 14:48:09 -0400
Message-Id: <199705081848.OAA22660 at black-ice.cc.vt.edu>
To: John C Klensin <klensin at mci.net>
Cc: ietf at ietf.org, lstsrv-l at peach.ease.lsoft.com,
IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Subject: Re: AOL mail traffic
In-Reply-To: Your message of "Thu, 08 May 1997 14:01:27 EDT."
<SIMEON.9705081427.A at tp7.Jck.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <SIMEON.9705081427.A at tp7.Jck.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1013931208P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 08 May 1997 14:48:08 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1013931208P
Content-Type: text/plain; charset=us-ascii
On Thu, 08 May 1997 14:01:27 EDT, John C Klensin said:
> As the author of that text, there are three separate issues
> here; confusion among them is unfortunate:
Umm.. John? Actually, there's a few more issues than just 3.
> Q1: Is a site required to handle relay traffic that starts
> from arbitrary sources and is destined for arbitrary sinks?
>
> A: Nope. Sites can decline to accept mail for
> substantially any reason they feel like. If the
This is 2 issues. The question asked is the specific question of
whether you must act as a relay for 2 other parties when you wish
not to. I don't think anybody disagrees that AOL has the right to
refuse to act as a mail relay. I don't have a problem with AOL's
refusing to act as a relay for 2 3rd parties. I don't have a
problem with AOL refusing to accept any email from a list of
known spam sites (AOL has a list of such sites on the web at
http://www.idot.aol.com/preferredmail/). I don't have a
problem with AOL rejecting source routing from known spam
havens.
The second issue is what your answer actually addresses - do sites
have a *generic* right to reject arbitrary mail (not just relaying for
2 other sites, or other specific case), and if so, what grounds are
considered justifiable?
I *do* have a problem with their refusing to accept mail merely
because it had passed through a relay sometime before they received
it, on purely syntactic grounds that the RFC's mandate support of.
> Conversely, if I'm running host x.y.z, and I refuse to
> accept your traffic for relaying, I'm going to do so
> because I don't like you for some reason, and probably not
> because you have chosen one of those forms over the other.
Ahh.. but AOL is rejecting mail *PRECISELY* because sites have chosen
one form over another. That's the crux of the problem.
AOL set up Preferredmail as part of the CyberPromo lawsuit(s). Are
their users aware that some *OTHER* mail may be getting rejected as
well, with no warning and no option for the users? It sounds like the
users whos mail is being rejected would have even MORE grounds for a
lawsuit than CyberPromo did....
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_-1013931208P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM3If5dQBOOoptg9JAQEVBAQAzTJR9Au18HbCw1/cIfbl7wcgkVziCM56
trcP6lZsZNWXevPPKs33516DzsmPMbQJQQt6rpjIcfsVI538LdMrN8vJwuAD1Gc8
L/R7KPSrmQqZ8Vktx61oefkVRPSUhAWakfYJMTcN44VTkBKjoSj4ea4KlVbt53Lz
z3rw1Gpa720=
=H9Wc
-----END PGP MESSAGE-----
--==_Exmh_-1013931208P--
Received: from ietf.org by ietf.org id aa16338; 8 May 97 15:32 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa16253; 8 May 97 15:30 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 PAA18192;
Thu, 8 May 1997 15:26:44 -0400
Message-Id: <199705081926.PAA18192 at black-ice.cc.vt.edu>
To: KnowlesB at aol.net
Cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org
Subject: Re: AOL mail traffic
In-Reply-To: Your message of "Thu, 08 May 1997 14:44:32 EDT."
<199705081844.OAA08984 at chrome.office.aol.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199705081844.OAA08984 at chrome.office.aol.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1395178376P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 08 May 1997 15:26:40 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1395178376P
Content-Type: text/plain; charset=us-ascii
On Thu, 08 May 1997 14:44:32 EDT, Brad Knowles said:
> The concept presented in section 7.5 of
> draft-ietf-drums-smtpupd-04.txt is older than the Internet itself.
> It's been around as long as personal and group property laws have been
> in existance.
>
> Specifically, it's based on the "trespass against chattels"
> issue, which has been the basis of a number of legal cases against
> junkmailers.
If you can find a citation that says that it's legal for an entity to
refuse payment for a debt merely because the person uses twenty dollar
bills to do so, and you will only accept one, five, and fifty dollar
bills (modulo rulings regarding paying in pennies, etc), I'll be more
willing to listen. Currently, source routes are in the same category
as $2 US bills - you don't see them often, but they're still legal
tender.
> In this specific case, I regret that a small number of legitimate
> mail messages will be caught by this measure we've taken to protect
> the AOL mail system, but when you do the cost/benefits analysis of
> the value of those few messages to the value of the entire AOL mail
> system (and the value of that system to our eight million users),
> you'll see that we simply had no choice.
Tell you what Brad - if you explain to me in technical terms *why* you
had no choice (specifically, why it was *NOT* an option to accept and
then discard the source route, as is permitted by RFC1123), I'll be
more than happy to shut up.
Please note that most of the complaints of bounced mail I've seen were
of the form MAIL FROM:<@host1:user at host2>, where either host1 and
host2 were identical literals (so it is perfectly safe to just discard
the @host1: part), or host1 and host2 were in the same domain, and
host1 was a mail gateway for host2. In this case, discarding the
@host1: is probably safe as well, as either host2 will accept mail or
the MX entry for it will point back to host1 anyhow.
Perhaps a more reasonable policy would be to reject source-routed mail
only if a comparison of host1 and host2 indicates a probable spamming
attempt through a relay (for instance, if they do not match to at
least a second level domain.name). That would be, to me, a policy
based rejection, not a rejection based merely on use of valid syntax.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_-1395178376P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM3Io7NQBOOoptg9JAQFVOgP+LlL2yhdeVehZ+50pOLOM2/fPiO7NI/zW
4beBcT8NGJp1hBIU+KTBMLbaYJkP4OP5dY+PMWpnl1bgPjttyW/Twqhw8Di4Ufmt
VfkG1RCWVYSSA850m9ZA5Sdbtxf/XyB7fUy2flquO14ZAbfFuk3whrn4RKU0kFph
SEJ2OZVkJWE=
=Pilt
-----END PGP MESSAGE-----
--==_Exmh_-1395178376P--
Received: from ietf.org by ietf.org id aa17179; 8 May 97 15:51 EDT
Received: from cnri by ietf.org id aa17061; 8 May 97 15:49 EDT
Received: from SGI.COM by CNRI.Reston.VA.US id aa16436; 8 May 97 15:49 EDT
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id MAA09313
for <@sgi.engr.sgi.com:ietf at cnri.reston.va.us>; Thu, 8 May 1997 12:45:37 -0700
env-from (vjs at mica.denver.sgi.com)
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA02128 for ietf at cnri.reston.va.us; Thu, 8 May 1997 13:45:33 -0600
Date: Thu, 8 May 1997 13:45:33 -0600
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199705081945.NAA02128 at mica.denver.sgi.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: AOL mail traffic
Source-Info: From (or Sender) name not authenticated.
> From: Valdis.Kletnieks at vt.edu
> I'm sure that in a week or so, the spammers will realize tha using a
> source route to AOL doesn't work, and will start using %-hacks
> instead. So AOL will bounce legitimate source-routed mail, not bounce
> any spam based source routed mail, and start considering turning off
> %-hacks as well.
I'm sorry, but I think you are too late. The %-kludge is so long dead
it has been removed from the morgue. !-paths are on resuscitation and
not expected to survive the week.
Source routes, %-kludge, and !-paths may continue to work inside
private internets, but they are now neither significantly used (as
opposed to abused) nor usable on the Internet. You dare not honor any
source route except when it bounces around purely inside your network,
and then what is the point?
I've used all three source routes in the good ol' days for testing and
debugging, but those were the old days. What can you do but tell the
young whippersnappers how good they were?
Besides, what is your complaint? Why would you want to send any of the
three kinds of source route to some other outfit without prior special
arrangement, or in any case? Why don't you rewrite all addresses, both
sender and receipient, to simple user at FQDN before they leave your
network? (your ISP may be part of "your network")
Vernon Schryver, vjs at sgi.com
Received: from ietf.org by ietf.org id aa17473; 8 May 97 15:59 EDT
Received: from chrome.office.aol.com by ietf.org id aa17348; 8 May 97 15:56 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id PAA10084;
Thu, 8 May 1997 15:52:12 -0400 (EDT)
Message-Id: <199705081952.PAA10084 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: Valdis.Kletnieks at vt.edu
cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Thu, 08 May 1997 15:26:40 EDT."
<199705081926.PAA18192 at black-ice.cc.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 15:52:12 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Thu, 08 May 1997 15:26:40 EDT
> If you can find a citation that says that it's legal for an entity to
> refuse payment for a debt merely because the person uses twenty dollar
> bills to do so, and you will only accept one, five, and fifty dollar
> bills (modulo rulings regarding paying in pennies, etc), I'll be more
> willing to listen. Currently, source routes are in the same category
> as $2 US bills - you don't see them often, but they're still legal
> tender.
Describe to me how this relates to "trespass of chattels",
whereby someone is preventing abuse of their property, especially
whereby they are being compelled to pay for the abuse of said
property.
We are not obliged, BY LAW, to accept anything, since the AOL
mail system is private property. Therefore, your entire argument
is null and void.
And that's the last I'll say on this particular issue.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa17511; 8 May 97 15:59 EDT
Received: from janus.border.com by ietf.org id aa17422; 8 May 97 15:58 EDT
Received: by janus.border.com id <11654>; Thu, 8 May 1997 15:49:39 -0400
Message-Id: <97May8.154939edt.11654 at janus.border.com>
To: John C Klensin <klensin at mci.net>
cc: Valdis.Kletnieks at vt.edu, PDMAtropos at aol.com,
Brad Knowles <BKnowles at aol.net>, Karl Mulder <KMULDER at vm.nmu.edu>,
ietf at ietf.org, lstsrv-l at peach.ease.lsoft.com,
IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Subject: Re: AOL mail traffic
References: <SIMEON.9705081427.A at tp7.Jck.com>
In-reply-to: klensin's message of "Thu, 08 May 1997 14:01:27 -0400".
<SIMEON.9705081427.A at tp7.Jck.com>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at utcc.utoronto.ca>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 813 2054
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did at Pr9
Date: Thu, 8 May 1997 15:54:20 -0400
X-Orig-Sender: chk at rafael.rnd.border.com
Source-Info: From (or Sender) name not authenticated.
In message <SIMEON.9705081427.A at tp7.Jck.com>, John C Klensin writes:
> RCPT TO:<abc at d.e.f>
> Use of
> RCPT TO:<@x.y.z:abc at d.e.f>
John, this example shows that you misunderstand the situation.
AOL is rejecting the mail at the MAIL From: command when the SENDER contains
a source route, i.e.
MAIL From:<@elgreco.border.com:owner-chatter at ve3tla.ampr.org>
I have no problem with people being unwilling to act as mail relayers to
arbitrary domains. I object *strongly* to them *denying* me the ability to
use mail relayers outside of their administrative purview.
--
Harald Koch <chk at utcc.utoronto.ca>
Received: from ietf.org by ietf.org id aa17603; 8 May 97 16:01 EDT
Received: from ns.jck.com by ietf.org id aa16656; 8 May 97 15:40 EDT
Received: from tp7.Jck.com ("port 1289"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0E9VNTR1P00N40 at a4.jck.com>
for ietf at ietf.org; Thu, 8 May 1997 15:37:07 -0400 (EDT)
Date: Thu, 08 May 1997 15:37:03 -0400 (EDT)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: AOL mail traffic
To: Valdis.Kletnieks at vt.edu
Cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9705081503.F at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Thu, 08 May 1997 14:48:08 -0400 Valdis.Kletnieks at vt.edu
wrote:
> On Thu, 08 May 1997 14:01:27 EDT, John C Klensin said:
> > As the author of that text, there are three separate issues
> > here; confusion among them is unfortunate:
>
> Umm.. John? Actually, there's a few more issues than just 3.
Ok, It is *really* complicated.
> The second issue is what your answer actually addresses - do sites
> have a *generic* right to reject arbitrary mail (not just relaying for
> 2 other sites, or other specific case), and if so, what grounds are
> considered justifiable?
>
> I *do* have a problem with their refusing to accept mail merely
> because it had passed through a relay sometime before they received
> it, on purely syntactic grounds that the RFC's mandate support of.
I understand, I think, "your problem". Starting from the
principle that either there is no such thing as a free
lunch, or, if there is, that AOL is under no obvious
obligation to provide you with one... I personally believe
that sides providing a certain amount of "free" relaying is
good for the network. But, as the volume rises enough that
one must consider either limiting relaying (even from
perfectly nice non-customers) or going off and buying more
hardware, which do you expect them to do? And, if the
latter, how you expect them to pay for the stuff? Let me
suggest some alternatives to see which one you like:
-- Taxing their customers to pay for their non-customers?
-- Applying to the government for a subsidy?
....
> Ahh.. but AOL is rejecting mail *PRECISELY* because sites have chosen
> one form over another. That's the crux of the problem.
Ok. I think that particular mechanism is silly. If I felt
like rejecting relaying, I wouldn't mess with source routes
one way or the other -- but I haven't seen AOL's usage
profile; if I had, I might change my mind. You think it is
immoral (I assume, or you might not be getting so excited).
Add your opinion to my opinion to a half-buck, and maybe it
buys a cup of coffee. The alternatives are either
regulation and/or subsidy (see above) and the provision of
free lunches, or AOL has to have the right to make business
decisions. If those decisions are bad enough, their
customers will go elsewhere or do unpleasant things and
AOL will either change their minds or go out of business.
If they are good decisions, then their profitability and
ROI will improve, and our opinions don't count.
Even if the standards contained "you must not bounce/
reject because someone use source routes, you must report
some other reason like 'general cussedness'", it would be
basically useless. Writing stuff into standards that
"requires" organizations to behave differently than they
believe it is in their business interests to behave is a
really efficient way to get the standards ignored.
regards,
john
Received: from ietf.org by ietf.org id aa18191; 8 May 97 16:14 EDT
Received: from janus.border.com by ietf.org id aa17985; 8 May 97 16:11 EDT
Received: by janus.border.com id <11658>; Thu, 8 May 1997 16:03:03 -0400
Message-Id: <97May8.160303edt.11658 at janus.border.com>
To: Valdis.Kletnieks at vt.edu
cc: KnowlesB at aol.net, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>,
lstsrv-l at peach.ease.lsoft.com, ietf at ietf.org
Subject: Re: AOL mail traffic
References: <199705081844.OAA08984 at chrome.office.aol.com>
<199705081926.PAA18192 at black-ice.cc.vt.edu>
In-reply-to: Valdis.Kletnieks's message of "Thu, 08 May 1997 15:26:40 -0400".
<199705081926.PAA18192 at black-ice.cc.vt.edu>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at utcc.utoronto.ca>
Date: Thu, 8 May 1997 16:07:42 -0400
X-Orig-Sender: chk at rafael.rnd.border.com
Source-Info: From (or Sender) name not authenticated.
In message <199705081926.PAA18192 at black-ice.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes:
>
> MAIL From:<@host1:user at host2>
>
> Perhaps a more reasonable policy would be to reject source-routed mail
> only if a comparison of host1 and host2 indicates a probable spamming
> attempt through a relay (for instance, if they do not match to at
> least a second level domain.name). That would be, to me, a policy
> based rejection, not a rejection based merely on use of valid syntax.
And I think that even this can be unreasonable. I cite my two cases again:
1) host1 is the corporate firewall, that just happens to also protect my
machine at home. Specifically:
MAIL From:<@elgreco.border.com:owner-chatter at ve3tla.ampr.org>
2) host1 is an ISP's mail relay host, provided as a service to its less
technically savvy customers:
MAIL From:<@mail.uunet.ca:owner-chatter at ve3tla.ampr.org>
(Yes, both of these are real examples :-).
Again, to reiterate:
- I have no objection to filtering known spam sources. (I use AOLs
PreferredMail list of hosts to filter my own incoming e-mail, thanks to
some perl scripts by YAPH).
- I have no objection to refusing to act as a mail relayer for hosts outside
your administrative purview (i.e. denying RCPT To:<@host1:user at host2).
- I merely object to rejecting mail based on a source route appearing in the
MAIL From: command.
--
Harald Koch <chk at utcc.utoronto.ca>
Received: from ietf.org by ietf.org id aa18324; 8 May 97 16:17 EDT
Received: from chrome.office.aol.com by ietf.org id aa18254; 8 May 97 16:16 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id QAA10519;
Thu, 8 May 1997 16:11:34 -0400 (EDT)
Message-Id: <199705082011.QAA10519 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: "C. Harald Koch" <chk at utcc.utoronto.ca>
cc: John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org,
lstsrv-l at peach.ease.lsoft.com, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Thu, 08 May 1997 15:54:20 EDT."
<97May8.154939edt.11654 at janus.border.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 16:11:33 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Thu, 08 May 1997 15:54:20 EDT
> I have no problem with people being unwilling to act as mail relayers to
> arbitrary domains. I object *strongly* to them *denying* me the ability to
> use mail relayers outside of their administrative purview.
You're free to use whatever mail relayers outside of our
administrative purview that you like, but if they add source routes
to the envelope addresses, you have to be aware that those messages
will be refused.
Get those SMTP MTAs to be compliant with RFC 1123 with regards
to not adding source routes, and you won't have any problems.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa18773; 8 May 97 16:23 EDT
Received: from chrome.office.aol.com by ietf.org id aa18531; 8 May 97 16:21 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id QAA10654;
Thu, 8 May 1997 16:17:20 -0400 (EDT)
Message-Id: <199705082017.QAA10654 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: "C. Harald Koch" <chk at utcc.utoronto.ca>
cc: Valdis.Kletnieks at vt.edu, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>,
lstsrv-l at peach.ease.lsoft.com, ietf at ietf.org
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Thu, 08 May 1997 16:07:42 EDT."
<97May8.160303edt.11658 at janus.border.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 16:17:20 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Thu, 08 May 1997 16:07:42 EDT
> - I merely object to rejecting mail based on a source route appearing in the
> MAIL From: command.
Object all you want. It was already a "SHOULD NOT generate"
in RFC 1123 (over six years ago), and the practice is becoming more
and more deprecated as the days go by.
If you want to guarantee that entire world will always be 100%
backwards compatible, I guess that means that you'd better travel
back in time a few years and keep them from inventing this thing
called "fire". Or the "wheel", for that matter.
Alternatively, invest in Microsoft. When they own the world (and
you are compelled to accept ActiveX applets when they push them down
to your brain), everything will be guaranteed to be 100% compatible.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa18780; 8 May 97 16:24 EDT
Received: from ns.jck.com by ietf.org id aa18669; 8 May 97 16:22 EDT
Received: from tp7.Jck.com ("port 1295"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0E9VPRS2E00N40 at a4.jck.com>
for ietf at ietf.org; Thu, 8 May 1997 16:19:04 -0400 (EDT)
Date: Thu, 08 May 1997 16:19:04 -0400 (EDT)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: AOL mail traffic
In-reply-to: <97May8.154939edt.11654 at janus.border.com>
To: "C. Harald Koch" <chk at utcc.utoronto.ca>
Cc: IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org, Karl Mulder <KMULDER at vm.nmu.edu>,
Brad Knowles <BKnowles at aol.net>, PDMAtropos at aol.com,
Valdis.Kletnieks at vt.edu
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9705081604.A at muahost.mci.net>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Thu, 08 May 1997 15:54:20 -0400 "C. Harald Koch"
<chk at utcc.utoronto.ca> wrote:
>...
> AOL is rejecting the mail at the MAIL From: command when the SENDER contains
> a source route, i.e.
>
> MAIL From:<@elgreco.border.com:owner-chatter at ve3tla.ampr.org>
>
> I have no problem with people being unwilling to act as mail relayers to
> arbitrary domains. I object *strongly* to them *denying* me the ability to
> use mail relayers outside of their administrative purview.
Sorry. But the bottom line is the same. You can object
all you like. If they want to make a business decision to
not let particular messages flow through to their users (on
any basis at all), there is little that the IETF community
--or the sender-- can do about it besides suggest that your
correspondents find a different ISP.
This isn't ultimately a discussion about standards, it is a
discussion about whether AOL has the right to manage their
business as they see fit, even it they see fit to do things
you find obnoxious or I think constitute shooting
themselves in the foot (neither of those may be the case,
they are just examples). I fear that I think they do --
the alternatives are too horrible to contemplate.
For whatever my biases are worth:
* You shouldn't be sending out source routes. There really
is no good reason for them.
* AOL should probably not reject things on the basis of
what is in the envelope sender address unless they have
specific cause.
* In my time, I've taken a lot of people off of mailing
lists because I got tired of dealing with their email
system and how it was managed. I usually found a way to
explain to them that, if they found a more reasonable (as
defined exclusively by me) supplier, I'd be happy to put
them back on. In a few cases, that strategy ultimately
resulted in some fixes being made. In others,...
john
Received: from ietf.org by ietf.org id aa21423; 8 May 97 16:48 EDT
Received: from janus.border.com by ietf.org id aa21248; 8 May 97 16:47 EDT
Received: by janus.border.com id <11661>; Thu, 8 May 1997 16:39:05 -0400
Message-Id: <97May8.163905edt.11661 at janus.border.com>
To: KnowlesB at aol.net
cc: John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org,
lstsrv-l at peach.ease.lsoft.com, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Subject: Re: AOL mail traffic
References: <199705082011.QAA10519 at chrome.office.aol.com>
In-reply-to: BKnowles's message of "Thu, 08 May 1997 16:11:33 -0400".
<199705082011.QAA10519 at chrome.office.aol.com>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at utcc.utoronto.ca>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 813 2054
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did at Pr9
Date: Thu, 8 May 1997 16:43:41 -0400
X-Orig-Sender: chk at rafael.rnd.border.com
Source-Info: From (or Sender) name not authenticated.
In message <199705082011.QAA10519 at chrome.office.aol.com>, Brad Knowles writes:
>
> Get those SMTP MTAs to be compliant with RFC 1123 with regards
> to not adding source routes, and you won't have any problems.
Look guys, I hate spam as much as the next guy. But I still think the
solution you've come up with is unecessarily penalizing legitimate e-mail.
Based on perusing AOL's web page, I think that's what happening here is
quite simple:
You're using the same sendmail ruleset to filter BOTH RCPT TO: addresses
*and* MAIL FROM: addresses. To be perfectly blunt, This is laziness in
implementation on your part, and you shouldn't be quoting standards to
justify it (especially when the standards don't support your claim).
Filtering RCPT TO: is just fine (RFC1123 does say "A Sender-SMTP SHOULD NOT
send a RCPT TO: command containing an explicit source route using the "@...:"
address form." I support your move to *not* relay other people's e-mail for
them.
Filtering MAIL FROM: is not mentioned anywhere in RFC 1123, AND IS BREAKING
EXISTING, LEGITIMATE, E-MAIL.
This is my last word on the subject. After all, the only legitimate recourse
I have is to recommend that my correspondents switch to other, less
draconian, service providers, and I've already done that.
--
Harald Koch <chk at utcc.utoronto.ca>
Received: from ietf.org by ietf.org id aa21939; 8 May 97 17:01 EDT
Received: from janus.border.com by ietf.org id aa21823; 8 May 97 16:58 EDT
Received: by janus.border.com id <11661>; Thu, 8 May 1997 16:50:04 -0400
Message-Id: <97May8.165004edt.11661 at janus.border.com>
To: KnowlesB at aol.net
cc: Valdis.Kletnieks at vt.edu, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>,
lstsrv-l at peach.ease.lsoft.com, ietf at ietf.org
Subject: Re: AOL mail traffic
References: <199705081952.PAA10084 at chrome.office.aol.com>
In-reply-to: BKnowles's message of "Thu, 08 May 1997 15:52:12 -0400".
<199705081952.PAA10084 at chrome.office.aol.com>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at utcc.utoronto.ca>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 813 2054
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did at Pr9
Date: Thu, 8 May 1997 16:54:39 -0400
X-Orig-Sender: chk at rafael.rnd.border.com
Source-Info: From (or Sender) name not authenticated.
In message <199705081952.PAA10084 at chrome.office.aol.com>, Brad Knowles writes:
>
> Describe to me how this relates to "trespass of chattels",
> whereby someone is preventing abuse of their property, especially
> whereby they are being compelled to pay for the abuse of said
> property.
Since I'm *not* trying to abuse your property, but merely supply a (free!)
service to one of your paying subscribers, you'd think that you'd be a bit
more open about this discussion.
The bottom line is that I'm trying to send (legitimate) e-mail to one of
your customers (rhyssan at aol.com, if it matters), and you're denying it
because I happen to be using a local mail relayer to make my network more
efficient, and that mail relayer adds itself to the MAIL FROM: address.
--
Harald Koch <chk at utcc.utoronto.ca>
Received: from ietf.org by ietf.org id aa22161; 8 May 97 17:03 EDT
Received: from janus.border.com by ietf.org id aa22032; 8 May 97 17:01 EDT
Received: by janus.border.com id <11660>; Thu, 8 May 1997 16:53:24 -0400
Message-Id: <97May8.165324edt.11660 at janus.border.com>
To: KnowlesB at aol.net
cc: Valdis.Kletnieks at vt.edu, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>,
lstsrv-l at peach.ease.lsoft.com, ietf at ietf.org
Subject: Re: AOL mail traffic
References: <199705082017.QAA10654 at chrome.office.aol.com>
In-reply-to: BKnowles's message of "Thu, 08 May 1997 16:17:20 -0400".
<199705082017.QAA10654 at chrome.office.aol.com>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at utcc.utoronto.ca>
Date: Thu, 8 May 1997 16:58:13 -0400
X-Orig-Sender: chk at rafael.rnd.border.com
Source-Info: From (or Sender) name not authenticated.
In message <199705082017.QAA10654 at chrome.office.aol.com>, Brad Knowles writes:
> Your message dated: Thu, 08 May 1997 16:07:42 EDT
>
> > - I merely object to rejecting mail based on a source route appearing in the
> > MAIL From: command.
>
> Object all you want. It was already a "SHOULD NOT generate"
> in RFC 1123 (over six years ago), and the practice is becoming more
> and more deprecated as the days go by.
Sorry to inject some facts here, but that passage in RFC 1123 refers
specifically to RCPT TO: addresses. There is no mention of source routing in
the context of MAIL FROM: anywhere in RFC 1123.
--
Harald
Received: from ietf.org by ietf.org id aa22979; 8 May 97 17:08 EDT
Received: from cnri by ietf.org id aa22514; 8 May 97 17:07 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa18900;
8 May 97 17:07 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 RAA17716;
Thu, 8 May 1997 17:03:47 -0400
Message-Id: <199705082103.RAA17716 at black-ice.cc.vt.edu>
To: Vernon Schryver <vjs at mica.denver.sgi.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: AOL mail traffic
In-Reply-To: Your message of "Thu, 08 May 1997 13:45:33 MDT."
<199705081945.NAA02128 at mica.denver.sgi.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199705081945.NAA02128 at mica.denver.sgi.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-957205624P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 08 May 1997 17:03:46 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-957205624P
Content-Type: text/plain; charset=us-ascii
On Thu, 08 May 1997 13:45:33 MDT, you said:
> Besides, what is your complaint? Why would you want to send any of the
> three kinds of source route to some other outfit without prior special
> arrangement, or in any case? Why don't you rewrite all addresses, both
> sender and receipient, to simple user at FQDN before they leave your
> network? (your ISP may be part of "your network")
Vernon: Not all the world is *yet* the Internet. If %-hacking breaks,
then I am going to be lookin at a *significant* (on the order or
40,000 pieces of mail a day) of bounced mail in my lap. I have a
*lot* of mail outbound from here that goes out as 'From:
user%node.bitet at vtbit.cc.vt.edu'. As long as the destination site
behaves and treats 'user%node.bitnet' as an opaque "userid" field, it
all works fine. If however sites start bouncing it just because
there's a % in it, things will get ugly.
And remember - there exist X.400 sites that use % to replace a blank
in an X.400 address - so they'll not be happy when they can't mail out
from their e-mail address '/o=Dept%23/u=fred/@x400gate.corp.com'.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_-957205624P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM3I/sNQBOOoptg9JAQGpHgQAp+F008XoB2MIP3RfOHinWbuII2/zJZ4w
cepQXkqNjPHH8zYglyzvp1CN6sJOGie4iT9BY0iQmc6P4sNCqVE9iLY++ZpaCFcp
HDQ9A/NTRGHULlr0SDzE4sq5grkWTH1/aFdWo/H/LZj6x0rYNzOHmpwPoObS8MXT
D6P/e1Ew078=
=uWMj
-----END PGP MESSAGE-----
--==_Exmh_-957205624P--
Received: from ietf.org by ietf.org id aa26272; 8 May 97 17:19 EDT
Received: from chrome.office.aol.com by ietf.org id aa25811; 8 May 97 17:17 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id RAA11540;
Thu, 8 May 1997 17:12:06 -0400 (EDT)
Message-Id: <199705082112.RAA11540 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: "C. Harald Koch" <chk at utcc.utoronto.ca>
cc: John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org,
lstsrv-l at peach.ease.lsoft.com, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Thu, 08 May 1997 16:43:41 EDT."
<97May8.163905edt.11661 at janus.border.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 17:12:06 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Thu, 08 May 1997 16:43:41 EDT
> Filtering MAIL FROM: is not mentioned anywhere in RFC 1123, AND IS BREAKING
> EXISTING, LEGITIMATE, E-MAIL.
As has been quoted here before:
RFCs 821, 822, and 1123 specify how email should be
done in a Perfect World by the Angels, for the Angels, and
of the Angels.
However, this is 1997 -- there are no more Angels
left, and this is about the most imperfect world as could
possibly exist.
Lose your love affair with that part of RFC 1123, because it
*is* going away, sooner or later. Maybe not with whatever will
become of draft-ietf-drums-smtpupd-04.txt, but sooner or later it
*will* go away.
There's simply no other possible outcome for a feature that
was marked as "SHOULD NOT generate" six years ago, and is marked as
"MUST NOT generate" now.
If we don't move forward, then by definition, we are moving
backwards (relatively speaking, since everyone and everything else
is moving forwards at astonishing speeds).
Well, it's time to move forwards on this one.
> This is my last word on the subject. After all, the only legitimate recourse
> I have is to recommend that my correspondents switch to other, less
> draconian, service providers, and I've already done that.
If that's what it takes to get your last word on the subject,
then I'm sorry that those few users will be lost, but I believe
that we'll more than make up for it in new users that flock to the
system because of the aggresive things we are doing to protect it
(and them) against things they constantly tell us they don't want
to receive (junkmail being the single number one complaint before
the flat fee/access debacle, and now the number one complaint again).
Although there has been quite a bit of negative feedback from
certain people on these lists, I've still gotten more positive
feedback than negative, and there is a fundamental difference in the
sources of those two types of feedback.
The positive feedback appears to be coming from folks who don't
really care too much how the underlying system works, they just
want it to work and prevent them from getting buried by junkmail.
The negative feedback appears to be coming from people who care
about little else *other* than how the mail system works, and want
to shackle the world to a feature that was already deprecated six
years ago.
Meanwhile, I'll continue to bop management over the head any
time they suggest that we should refuse to accept mail from "<>",
or require that envelope addresses match the corresponding header
addresses, etc.....
Folks should consider themselves lucky that I'm here to preach
the sermon on standards around here. May Ghu help you all when I
get so fed up with all this that I decide to just up and leave.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa27056; 8 May 97 17:38 EDT
Received: from cnri by ietf.org id aa26916; 8 May 97 17:36 EDT
Received: from SGI.COM by CNRI.Reston.VA.US id aa19484; 8 May 97 17:36 EDT
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id OAA06738; Thu, 8 May 1997 14:32:30 -0700
env-from (vjs at mica.denver.sgi.com)
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA02400; Thu, 8 May 1997 15:32:19 -0600
Date: Thu, 8 May 1997 15:32:19 -0600
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199705082132.PAA02400 at mica.denver.sgi.com>
To: Valdis.Kletnieks at vt.edu
Subject: Re: AOL mail traffic
Cc: ietf at CNRI.Reston.VA.US
References: <199705081945.NAA02128 at mica.denver.sgi.com>
Source-Info: From (or Sender) name not authenticated.
> From: Valdis.Kletnieks at vt.edu
> > Besides, what is your complaint? Why would you want to send any of the
> > three kinds of source route to some other outfit without prior special
> > arrangement, or in any case? Why don't you rewrite all addresses, both
> > sender and receipient, to simple user at FQDN before they leave your
> > network? (your ISP may be part of "your network")
>
> Vernon: Not all the world is *yet* the Internet. If %-hacking breaks,
> then I am going to be lookin at a *significant* (on the order or
> 40,000 pieces of mail a day) of bounced mail in my lap.
(I'm sorry. You have my sympathy, but nothing else. SGI used to use
the %-hack a lot. We still use RFC-822 source routes internally
quite heavily.)
> I have a
> *lot* of mail outbound from here that goes out as 'From:
> user%node.bitet at vtbit.cc.vt.edu'. As long as the destination site
> behaves and treats 'user%node.bitnet' as an opaque "userid" field, it
> all works fine. If however sites start bouncing it just because
> there's a % in it, things will get ugly.
>
> And remember - there exist X.400 sites that use % to replace a blank
> in an X.400 address - so they'll not be happy when they can't mail out
> from their e-mail address '/o=Dept%23/u=fred/@x400gate.corp.com'.
So as long as you expect the next hop to treat % as just another letter,
your uses would work fine?
I previously had modified the on sgi.com rules to not parse % and !,
but that is not as clean, nor as easy as my current scheme, which is to
remove them from sendmail's list of special characters. I think that
meets your needs.
Perhaps you could convince AOL to do the same.
Vernon Schryver, vjs at sgi.com
Received: from ietf.org by ietf.org id aa28188; 8 May 97 18:16 EDT
Received: from star.centurasoft.com by ietf.org id aa28088; 8 May 97 18:14 EDT
Received: by centurasoft.com (4.1/SMI-4.1-r1)
id AA27618; Thu, 8 May 97 15:06:31 PDT
Received: from smtplink(192.234.114.23) by star via smap (V1.3mjr)
id sma027607; Thu May 8 15:06:02 1997
Received: from ccMail by smtplink.Gupta.COM (SMTPLINK V2.11 PreRelease 4)
id AA863129315; Thu, 08 May 97 14:58:43 PST
Date: Thu, 08 May 97 14:58:43 PST
Sender:ietf-request at ietf.org
From: David Holmes-Kinsella <David.Holmes-Kinsella at centurasoft.com>
Message-Id: <9704088631.AA863129315 at smtplink.Gupta.COM>
To: chk at utcc.utoronto.ca, KnowlesB at aol.net
Cc: Valdis.Kletnieks at vt.edu, IBMTCP-L at vm.marist.edu,
lstsrv-l at peach.ease.lsoft.com, ietf at ietf.org
Subject: Re[2]: AOL mail traffic
Source-Info: From (or Sender) name not authenticated.
One of the reasons people pay money to an ISP is for service -- and
that's more than simply a modem answering an an IP address. If AOL
feels compelled to take action based on the business needs of their
community (which includes themselves), well then so be it.
Some time ago, we started working on a set of business and technology
plans that would support the notion of "atolls" wherein users would
reside within these private high value network and most of the 'net
would be filtered - not so much as to censor that which was somehow
deemed to be inappropriate, but to ensure that the information flowing
into the atoll was qualified, in whatever sense it needed to be.
And that's an issue which far outweighs any consideration of source
routing or whatever else. When I was a kid, I'd go into the library
to do research for school projects - and somehow I knew that
Encylopedia Britannica was more likely to have sound information
(Vonnegut notwithstanding) than the rantings that were inscribed on
the lavatory walls.
What opportunity does a child have to make the same distinction when
all they're reading are web pages? If the veracity of the information
is to be determined by the quality of the presentation, then there
would be an uncomfortably large number of Silicon Valley companies
whose Web presence would be a significant disservice to their
ventures.
So if AOL chooses to do this? Well, good on them. However, what cost
this compartmentalization?
<End Soapbox>
dhk
______________________________ Reply Separator _________________________________
Subject: Re: AOL mail traffic
Author: KnowlesB at aol.net at SMTPLINK-GC
Date: 5/8/97 2:07 PM
Your message dated: Thu, 08 May 1997 16:07:42 EDT
> - I merely object to rejecting mail based on a source route appearing in the
> MAIL From: command.
Object all you want. It was already a "SHOULD NOT generate"
in RFC 1123 (over six years ago), and the practice is becoming more
and more deprecated as the days go by.
If you want to guarantee that entire world will always be 100%
backwards compatible, I guess that means that you'd better travel
back in time a few years and keep them from inventing this thing
called "fire". Or the "wheel", for that matter.
Alternatively, invest in Microsoft. When they own the world (and
you are compelled to accept ActiveX applets when they push them down
to your brain), everything will be guaranteed to be 100% compatible.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa29497; 8 May 97 18:52 EDT
Received: from janus.border.com by ietf.org id aa29429; 8 May 97 18:50 EDT
Received: by janus.border.com id <11649>; Thu, 8 May 1997 18:41:54 -0400
Message-Id: <97May8.184154edt.11649 at janus.border.com>
To: KnowlesB at aol.net
cc: John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org,
lstsrv-l at peach.ease.lsoft.com, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Subject: Re: AOL mail traffic
References: <199705082112.RAA11540 at chrome.office.aol.com>
In-reply-to: BKnowles's message of "Thu, 08 May 1997 17:12:06 -0400".
<199705082112.RAA11540 at chrome.office.aol.com>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at utcc.utoronto.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7677.863131600.1 at rafael.rnd.border.com>
Date: Thu, 8 May 1997 18:46:40 -0400
X-Orig-Sender: chk at rafael.rnd.border.com
Source-Info: From (or Sender) name not authenticated.
Ok, I'll ask this a different way.
How does denying source-routing in MAIL FROM: headers IN ANY WAY change
whether or not you receive junk e-mail? All I'm asking you to do is be a
little bit more picky about the filtering you're doing. Is that such a
horrible thing?
In message <199705082112.RAA11540 at chrome.office.aol.com>, Brad Knowles writes:
> The positive feedback appears to be coming from folks who don't
> really care too much how the underlying system works, they just
> want it to work and prevent them from getting buried by junkmail.
These sample people would probably also not notice if you started denying
mail from, say, all of Compuserve. But you would never do that, would you?
I'm reminded of a Prodigy episode. Remember, they were actively filtering
messages for "indencent content". Everyone applauded until the day someone
decided that the word "breast" was indecent, and suddenly there was no
discussion happening in the Forum for supporting sufferrers of Breast Cancer.
I think this is a similar situation. The goals are fine, but the
implementation is slightly suspect. It only requires a small tweak to fix.
Sure, all of us will eventually get around to "fixing" our mailers. But some
of us are running commercial software, and it takes time to get new releases
from vendors...
--
Harald Koch <chk at utcc.utoronto.ca>
Received: from ietf.org by ietf.org id aa29773; 8 May 97 18:57 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa29696;
8 May 97 18:56 EDT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA20103; Thu, 8 May 97 18:52:20 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA15640; Thu, 8 May 1997 18:52:20 -0400
Date: Thu, 8 May 1997 18:52:20 -0400
Message-Id: <9705082252.AA15640 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "C. Harald Koch" <chk at utcc.utoronto.ca>
Cc: KnowlesB at aol.net, John C Klensin <klensin at mci.net>,
Valdis.Kletnieks at vt.edu, PDMAtropos at aol.com,
Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org,
lstsrv-l at peach.ease.lsoft.com, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
In-Reply-To: C. Harald Koch's message of Thu, 8 May 1997 16:43:41 -0400,
<97May8.163905edt.11661 at janus.border.com>
Subject: Re: AOL mail traffic
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
From: "C. Harald Koch" <chk at utcc.utoronto.ca>
This is my last word on the subject. After all, the only legitimate recourse
I have is to recommend that my correspondents switch to other, less
draconian, service providers, and I've already done that.
Actually, you have another recourse, which is to fix your mailers to
follow RFC 1123's statement that mailers SHOULD NOT create an RFC-822
header containing an address with an explicit source route.....
- Ted
Received: from ietf.org by ietf.org id aa00005; 8 May 97 19:11 EDT
Received: from WLV.IIPO.GTEGSC.COM by ietf.org id aa29908; 8 May 97 19:06 EDT
Received: from MCC.IIPO.GTEGSC.COM (MCC.IIPO.GTEGSC.COM [199.107.242.254]) by wlv.iipo.gtegsc.com (8.8.5/8.7.3) with SMTP id PAA13451; Thu, 8 May 1997 15:53:09 -0700 (PDT)
Date: Thu, 8 May 1997 15:51:02 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>
To: KnowlesB at aol.net
cc: "C. Harald Koch" <chk at utcc.utoronto.ca>, Valdis.Kletnieks at vt.edu,
IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org
Subject: Re: AOL mail traffic
In-Reply-To: <199705082017.QAA10654 at chrome.office.aol.com>
Message-ID: <Pine.WNT.3.96.970508151041.-299965G-100000 at MCC.IIPO.GTEGSC.COM>
X-Orig-Sender: mcc at wlv.iipo.gtegsc.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 8 May 1997, Brad Knowles wrote:
} Your message dated: Thu, 08 May 1997 16:07:42 EDT
}
} > - I merely object to rejecting mail based on a source route appearing in the
} > MAIL From: command.
}
} Object all you want. It was already a "SHOULD NOT generate"
} in RFC 1123 (over six years ago), and the practice is becoming more
} and more deprecated as the days go by.
RFC1123 also stated that the target location "MUST accept" mail with source
routes.
@mail.cerf.net:GandGC at aol.com
While AOL MUST accept mail address as shown, CERF is not obligated to
implement a mail relay function and need not accept mail as addressed. Nor
would AOL be obligated if the address were
@aol.com:GandGC at mail.cerf.net
The latter would be "trespass of chattel". The former "breach of contract".
Now if only something could be done about the a.mx....
Merton Campbell Crockett
Hasenthaler InfoSysteme
Received: from ietf.org by ietf.org id aa00533; 8 May 97 19:22 EDT
Received: from [204.94.142.33] by ietf.org id aa00329; 8 May 97 19:21 EDT
Received: (from egoshin at localhost) by leonid.genesyslab.com (8.7.5/8.7.3) id QAA00698; Thu, 8 May 1997 16:16:24 -0700
Date: Thu, 8 May 1997 16:16:24 -0700
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199705082316.QAA00698 at leonid.genesyslab.com>
To: IBMTCP-L at vm.marist.edu, ietf at ietf.org, KnowlesB at aol.net,
lstsrv-l at peach.ease.lsoft.com
Subject: Re: AOL mail traffic
Source-Info: From (or Sender) name not authenticated.
>From: Brad Knowles <BKnowles at aol.net>
>
>> Filtering MAIL FROM: is not mentioned anywhere in RFC 1123, AND IS BREAKING
>> EXISTING, LEGITIMATE, E-MAIL.
>
> As has been quoted here before:
>
> RFCs 821, 822, and 1123 specify how email should be
> done in a Perfect World by the Angels, for the Angels, and
> of the Angels.
>
> However, this is 1997 -- there are no more Angels
> left, and this is about the most imperfect world as could
> possibly exist.
>
>
Hey, Brad - that you speaking about ? It is only draft and there are
a lot of arguments against it. For exam, address in MAIL FROM was
constructed to return errors from mail-transfer-agent (look sendmail),
and address in From: is for user-agent. And routing in MAIL FROM can be
used to deliver transfer errors in any case, even you can't send
mail to From: address.
(If you want to protect users from spam you can use something
more beautifull)
> Lose your love affair with that part of RFC 1123, because it
>*is* going away, sooner or later. Maybe not with whatever will
>become of draft-ietf-drums-smtpupd-04.txt, but sooner or later it
>*will* go away.
>
If this draft would be incompatible with SMTP (all RFCs set) and practice,
please request and use ANOTHER TCP port for this service. Period.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa00698; 8 May 97 19:26 EDT
Received: from chrome.office.aol.com by ietf.org id aa00587; 8 May 97 19:25 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id TAA20172;
Thu, 8 May 1997 19:20:17 -0400 (EDT)
Message-Id: <199705082320.TAA20172 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: "C. Harald Koch" <chk at utcc.utoronto.ca>
cc: John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org,
lstsrv-l at peach.ease.lsoft.com, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Thu, 08 May 1997 18:46:40 EDT."
<97May8.184154edt.11649 at janus.border.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 19:20:16 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Thu, 08 May 1997 18:46:40 EDT
> These sample people would probably also not notice if you started denying
> mail from, say, all of Compuserve. But you would never do that, would you?
If we determined that CompuServe was being used as a relay
point for junkmail, and had exhausted all other avenues of recourse
(we do have direct phone and email contacts over there), then yes --
we would refuse to accept any and all SMTP connections from them.
Hell, we've been within a hairs-breadth of putting them in a
AOL-wide router filter before, and only at the last minute did we
get any positive response from them.
On the same basis as I gave before (protecting the system
against abuse, and preventing others from compelling us to allow
them to abuse our system), we'll do *whatever* it takes. If that
means we cut off all email from CompuServe, so be it. I expect
them to act the same way towards us.
However, that said, I find it highly unlikely that they would
be so unresponsive so as to force us to take that kind of action.
The community of Internet mail professionals at the various large
service providers is too tightly knit a community for that.
If nothing else, the cost of forcing us to take that kind of
action is so prohibitively high that even the most pointy-haired
management realizes that they have to fix the problem before we're
required to stop accepting any mail from them whatsoever.
> Sure, all of us will eventually get around to "fixing" our mailers. But some
> of us are running commercial software, and it takes time to get new releases
> from vendors...
I've been kept up fifty-six hours straight in the past, trying to
breathe life back into a dead email system, as a result of various
different types of problems inflicted upon me by outside influences.
I've implemented the best solution I can find for the overall
problem, and I don't see why I should be required to continue to
risk the very existance of the AOL mail system (and spend untold
millions of dollars) trying to bend over backwards to accomodate
a few sites that can't themselves be put out enough to put in that
same kind of effort to fix their systems.
You're now in essentially the same boat as users of Microsoft
Exchange, various products based on Novell Netware, etc.... You have
to upgrade your systems, if you want to talk to the AOL mail system.
We can't help you do that any more than we can help other sites
upgrade their copies of Microsoft Exchange.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa00888; 8 May 97 19:30 EDT
Received: from [204.94.142.33] by ietf.org id aa00823; 8 May 97 19:29 EDT
Received: (from egoshin at localhost) by leonid.genesyslab.com (8.7.5/8.7.3) id QAA00712; Thu, 8 May 1997 16:24:31 -0700
Date: Thu, 8 May 1997 16:24:31 -0700
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199705082324.QAA00712 at leonid.genesyslab.com>
To: chk at utcc.utoronto.ca, tytso at mit.edu
Subject: Re: AOL mail traffic
Cc: IBMTCP-L at vm.marist.edu, ietf at ietf.org, klensin at mci.net,
KMULDER at vm.nmu.edu, KnowlesB at aol.net, lstsrv-l at peach.ease.lsoft.com,
PDMAtropos at aol.com, Valdis.Kletnieks at vt.edu
Source-Info: From (or Sender) name not authenticated.
>From: "Theodore Y. Ts'o" <tytso at mit.edu>
> From: "C. Harald Koch" <chk at utcc.utoronto.ca>
>
> This is my last word on the subject. After all, the only legitimate recourse
> I have is to recommend that my correspondents switch to other, less
> draconian, service providers, and I've already done that.
>
>Actually, you have another recourse, which is to fix your mailers to
>follow RFC 1123's statement that mailers SHOULD NOT create an RFC-822
>header containing an address with an explicit source route.....
MAIL FROM: is _not_ the part of header and can be seen the only
in Return-Path: header line.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa01167; 8 May 97 19:36 EDT
Received: from chrome.office.aol.com by ietf.org id aa00977; 8 May 97 19:35 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id TAA20314;
Thu, 8 May 1997 19:30:38 -0400 (EDT)
Message-Id: <199705082330.TAA20314 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>
cc: "C. Harald Koch" <chk at utcc.utoronto.ca>, Valdis.Kletnieks at vt.edu,
IBM TCP/IP List <IBMTCP-L at vm.marist.edu>, lstsrv-l at peach.ease.lsoft.com,
ietf at ietf.org
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Thu, 08 May 1997 15:51:02 PDT."
<Pine.WNT.3.96.970508151041.-299965G-100000 at MCC.IIPO.GTEGSC.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 19:30:38 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Thu, 08 May 1997 15:51:02 PDT
> Now if only something could be done about the a.mx....
You mean pointing MX RRs at CNAME RRs?
Unfortunately, although John does a good job of detailing
why listing large numbers of MXes for a domain is bad (see
<ftp://ds.internic.net/internet-drafts/draft-myers-mail-largesite-00.t
xt>),
he doesn't provide any real solutions. That's because they don't
exist yet, at least, not that will work on the really large scale.
We're working with Paul Vixie to implement "variadic zones"
(work which we are paying for and which we will contribute back
to the public version of BIND, for the benefit of the entire 'net
community), but until that's been delivered and they are proven to
work, there's just not a whole lot of options there.
In the meanwhile, more and more sites are depending on pointing
MXes at RRs, because that's the only way they can list a suitably
small set of MXes for their domain (along the recommendations of
draft-myers-mail-largesite-00.txt), while still making use of,
and doing decent load balancing across, their entire set of MXes.
In AOL's case, that's now almost sixty machines.
Those sites using MXes pointed at CNAMEs should count themselves
lucky. We came within a hairs breadth of having that option
removed from BIND 8.1, which would have shut down mail to places
like AOL, CompuServe, MCImail, Juno, etc... after they upgraded
their nameservers.
You're welcome.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa01330; 8 May 97 19:43 EDT
Received: from chrome.office.aol.com by ietf.org id aa01250; 8 May 97 19:42 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id TAA20372;
Thu, 8 May 1997 19:37:25 -0400 (EDT)
Message-Id: <199705082337.TAA20372 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: "C. Harald Koch" <chk at utcc.utoronto.ca>
cc: Jered J Floyd <jered at mit.edu>, klensin at mci.net, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org,
lstsrv-l at peach.ease.lsoft.com, IBM TCP/IP List <IBMTCP-L at vm.marist.edu>
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Thu, 08 May 1997 19:28:28 EDT."
<97May8.192336edt.11649 at janus.border.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 May 1997 19:37:25 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Thu, 08 May 1997 19:28:28 EDT
> In message <s56wwp9ft9g.fsf at the-great-machine.mit.edu>, Jered J Floyd writes:
> >
> > Something similar may have happened at Prodigy; but the one that springs
> > to mind for me is when America OnLine decided 'breast' was not an
> > appropriate word for member profiles or chat rooms, and zapped a bunch of
> > users in a Breast Cancer Survivors forum on AOL.
> >
> > <http://cgi.pathfinder.com/netly/editorial/0,1012,29,00.html>
>
> You're right, that was AOL. Oh, that's just too perfect.
Yup, AOL does some pretty stupid stuff, too. One of my
favourites was when they banned a certain word that also kept you
from discussing Shiitake mushrooms.
However, that doesn't change my views on the original subject.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa02021; 8 May 97 20:08 EDT
Received: from segate.sunet.se by ietf.org id aa01948; 8 May 97 20:06 EDT
Received: from SEARN.SUNET.SE by SEGATE.SUNET.SE (LSMTP for OpenVMS v1.1a) with SMTP id <15.8F34BAB0 at SEGATE.SUNET.SE>; Fri, 9 May 1997 2:02:49 +0100
Received: from SEARN.SUNET.SE by SEARN.SUNET.SE (IBM VM SMTP V2R3)
with BSMTP id 9658; Fri, 09 May 97 02:03:26 +0200
Received: from SEARN.SUNET.SE (NJE origin ERIC at SEARN) by SEARN.SUNET.SE (LMail V1.2c/1.8c) with RFC822 id 0809; Fri, 9 May 1997 02:03:25 +0200
Date: Fri, 9 May 1997 01:12:02 +0200
Sender:ietf-request at ietf.org
From: Eric Thomas <ERIC at vm.se.lsoft.com>
Subject: Re: AOL mail traffic
To: KnowlesB at aol.net, "C. Harald Koch" <chk at utcc.utoronto.ca>
cc: John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>,
ietf at ietf.org
In-Reply-To: Message of Thu, 8 May 1997 18:46:40 -0400 from
ietf-request at ietf.org
Message-ID: <9705082006.aa01948 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
First, I suggest we take LSTSRV-L and IBMTCP-L off the cc: list. While
announcing and describing the problem on these lists was perfectly
appropriate, I don't think that this continued discussion is.
On Thu, 8 May 1997 18:46:40 -0400 "C. Harald Koch" <chk at utcc.utoronto.ca>
said:
>How does denying source-routing in MAIL FROM: headers IN ANY WAY change
>whether or not you receive junk e-mail?
Brad has yet to give a TECHNICAL explanation which does not take the form
of "Doing otherwise would threaten the very existence of AOL for reasons
that I won't tell you, and anyway the DRUMS group agrees with me and
RFC1123 says you shouldn't put source routes in MAIL FROM:, and you are
violating this standard (me too, but that's besides the point)". However,
from bits and pieces gleaned here and there among Brad's comments, I have
assembled the following explanation:
- Some popular spam program out there sends MAIL FROM: addresses with a
source route pointing to a box that you cannot deliver mail to. Why, I
have no idea. Spammers are not the most technically competent people in
the world, but Brad clearly said he was getting a lot of spam in that
format.
- This creates a problem for AOL because the bounces just pile up in the
sendmail queue (since they can't be delivered) and impact overall
service. Eventually they get purged from the queue but meanwhile they
can add up to a whole bunch of files.
- Brad added the MAIL FROM: source route filter and all these spams have
been bounced. AOL users are of course delighted. Problem solved, we can
all go home. Too bad if some legitimate mail is lost.
The problem of course is that, while spammers may not be the biggest mail
experts in the planet, they aren't stupid either. Some have their own AOL
account and spam themselves to make sure it went through. Well, it's no
longer going through, so they will switch to another spam mailer, or
maybe the developer will read on usenet that AOL now has this filter, and
a new version of the spam program will come out. Instead of saying:
MAIL FROM:<@router.xyz.com:blah at blah>
It will say:
MAIL FROM:<blah at router.xyz.com>
'router.xyz.com' being some cisco or other - a perfectly valid host but
with no port 25 listener. AOL can't tell this from a valid host whose MTA
is currently down, and there are more than enough ciscos to build a table
of hundreds or thousands of hosts that can be used randomly, etc.
This will take anywhere from a few days to a few weeks. At that point of
course AOL will be back to square one with the spam going through, the
bounces piling up, etc. The only difference will be that a lot of dollars
will have been lost in the form of lost correspondence, manpower, support
calls, flame wars and so on.
It has been pointed out many times that RFC1123 supposedly says that
source routes should be stripped from MAIL FROM: commands and that only
evil, broken software would do otherwise and needs to be fixed. Actually,
RFC1123 says that you SHOULD NOT use source route information from the
MAIL FROM: field when generating a bounce. It does not say, as far as I
can see, that you should strip source routes from in-transit messages.
For instance, let's say I run ISP.NET and I provide a service to my
customers whereby they can use my MTA as a mail relay. One of my
customers sends me:
MAIL FROM:<@zeus.customer.com:joe at customer.com>
RCPT TO:<joe at aol.com>
Some say that my MTA should proactively remove the '@zeus.customer.com'
source route when forwarding the message to AOL.COM. Actually, I don't
agree. I don't see anything in any of the current mail standards which
would support removing this *information*, and removal of information
should always be justified. When acting as a pure in-transit relay, one
does not normally try to second guess the sender's intent. One tries to
keep one's processing as simple and straightforward as possible, letting
the source and target servers determine what should be done with the
message. Passing the MAIL FROM: intact appears to be the soundest design
decision and the one least likely to lead to undesirable results. As a
mail relay, I don't know that the target site will not honour the source
route, and I don't know that the source site did not provide the source
route for a good reason. Besides, the MAIL FROM: information is of no
relevance to me (unless the message bounces). What it contains is none of
my business, as long as it matches proper syntax. Why should I take the
liberty of removing something which might have been added for a good
reason? Whether Brad likes it or not, it looks like a lot of MTAs will
preserve the source route in this context (without adding one of their
own), and I think they're doing the right thing. There are also a lot of
MTAs that will generate a MAIL FROM: source route when you tell them to
route a particular message through a particular host (typical case, a
mailing list using an off-site mail relay).
Of course, Brad's decision had some positive side effects. For instance,
we got a lot of calls today from customers who have a MTA that preserves
source routes in MAIL FROM, and who aren't going to be able to get a
"fix" in any acceptable time frame. They were evaluating LSMTP previously
and they are now sending us a PO at the fastest rate their purchasing
department is capable of, because LSMTP has an option (implemented
yesterday and off by default) which allows you to suppress in-transit
source routes, and this will allow them to communicate with AOL.COM
again. Someone in marketing even asked if we shouldn't be making a press
release to announce this new "major enhancement" of LSMTP (luckily there
was no wall within range to bang my head on). So I guess I should be
thanking Brad for the business, but really, I would much rather we didn't
get all these POs today, because each of them represents hundreds or
thousands of messages that were lost for no good reason (until TECHNICAL
proof of the contrary is presented).
Eric
Received: from ietf.org by ietf.org id aa04207; 8 May 97 21:46 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa04026;
8 May 97 21:37 EDT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA14247; Thu, 8 May 97 21:31:38 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA15702; Thu, 8 May 1997 21:31:38 -0400
Date: Thu, 8 May 1997 21:31:38 -0400
Message-Id: <9705090131.AA15702 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Eric Thomas <ERIC at vm.se.lsoft.com>
Cc: KnowlesB at aol.net, "C. Harald Koch" <chk at utcc.utoronto.ca>,
John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org
In-Reply-To: Eric Thomas's message of Fri, 9 May 1997 01:12:02 +0200,
<9705082006.aa01948 at ietf.org>
Subject: Re: AOL mail traffic
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Fri, 9 May 1997 01:12:02 +0200
From: Eric Thomas <ERIC at vm.se.lsoft.com>
It has been pointed out many times that RFC1123 supposedly says that
source routes should be stripped from MAIL FROM: commands and that only
evil, broken software would do otherwise and needs to be fixed. Actually,
RFC1123 says that you SHOULD NOT use source route information from the
MAIL FROM: field when generating a bounce. It does not say, as far as I
can see, that you should strip source routes from in-transit messages.
For instance, let's say I run ISP.NET and I provide a service to my
customers whereby they can use my MTA as a mail relay. One of my
customers sends me:
MAIL FROM:<@zeus.customer.com:joe at customer.com>
RCPT TO:<joe at aol.com>
Some say that my MTA should proactively remove the '@zeus.customer.com'
source route when forwarding the message to AOL.COM.
Actually, I believe the claim which has been made is that the *source*
mailer should not be generating a MAIL FROM that contains a source
route, and it is the source mailer which is broken. I'd tend to agree
with you that an MTA which is acting as a mail relay shouldn't need to
mangle the MAIL FROM: field.
- Ted
Received: from ietf.org by ietf.org id aa12368; 8 May 97 23:19 EDT
Received: from THOR.INNOSOFT.COM by ietf.org id aa12244; 8 May 97 23:14 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694)
id <01IIMOPDC4F499GM4I at INNOSOFT.COM> for ietf at ietf.org; Thu,
8 May 1997 20:09:26 PDT
Date: Thu, 08 May 1997 19:55:10 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Ned Freed <Ned.Freed at innosoft.com>
Subject: Re: AOL mail traffic
In-reply-to: "Your message dated Fri, 09 May 1997 01:12:02 +0200"
<9705082006.aa01948 at ietf.org>
To: Eric Thomas <ERIC at vm.se.lsoft.com>
Cc: KnowlesB at aol.net, "C. Harald Koch" <chk at utcc.utoronto.ca>,
John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org
Message-id: <01IIN1187KKW99GM4I at INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
References: <"8 May 1997 18:46:40 -0400 from ietf-request"@ietf.org>
Source-Info: From (or Sender) name not authenticated.
> Of course, Brad's decision had some positive side effects. For instance,
> we got a lot of calls today from customers who have a MTA that preserves
> source routes in MAIL FROM, and who aren't going to be able to get a
> "fix" in any acceptable time frame. They were evaluating LSMTP previously
> and they are now sending us a PO at the fastest rate their purchasing
> department is capable of, because LSMTP has an option (implemented
> yesterday and off by default) which allows you to suppress in-transit
> source routes, and this will allow them to communicate with AOL.COM
> again. Someone in marketing even asked if we shouldn't be making a press
> release to announce this new "major enhancement" of LSMTP (luckily there
> was no wall within range to bang my head on). So I guess I should be
> thanking Brad for the business, but really, I would much rather we didn't
> get all these POs today, because each of them represents hundreds or
> thousands of messages that were lost for no good reason (until TECHNICAL
> proof of the contrary is presented).
FWIW, I am in complete agreement with everything Eric said except for this last
part I've quoted. And the only problem with this part is that it is incomplete:
It is quite true that companies like LSoft (and Innosoft for that matter --
we've had this capability in PMDF for several years now and if AOL persists in
this I suppose we also will get some sales as a result) and that in the
meantime lots of mail will be lost.
But this is all short term stuff -- in the longer term this sort of nonsense
hurts everyone connected with the Internet. Simply put, there are a lot of
naysayers and doomsayers out there these days who prate on and on about the
Internet collapsing, how unreliable Internet applications are, and so on. And
this sort of behavior on the part of AOL is just more ammunition for them to
use. The creation more Internet FUD is not good and that is the result of this
that I deplore the most.
I wouldn't mind so much if there was a some chance of AOL actually getting
some medium to long term benefit out of what they are doing. But there's
little if any chance of that, as Eric already pointed out. So what we have
here is a classic case of tossing out the baby with the bathwater.
Ned
Received: from ietf.org by ietf.org id aa17237; 9 May 97 1:27 EDT
Received: from proxy3.ba.best.com by ietf.org id aa17110; 9 May 97 1:19 EDT
Received: from [205.149.180.135] (boo.vip.best.com [205.149.180.135]) by proxy3.ba.best.com (8.8.5/8.8.3) with ESMTP id WAA11217; Thu, 8 May 1997 22:15:14 -0700 (PDT)
X-Sender: boo at shell5.ba.best.com
Message-Id: <v03102815af984d20fdc1 at [205.149.180.135]>
In-Reply-To: <199705082337.TAA20372 at chrome.office.aol.com>
References: Your message of "Thu, 08 May 1997 19:28:28 EDT."
<97May8.192336edt.11649 at janus.border.com>
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: Thu, 8 May 1997 20:56:18 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Walter Ian Kaye <walter at natural-innovations.com>
Subject: Re: AOL mail traffic
Cc: Brad Knowles <BKnowles at aol.net>, Jered J Floyd <jered at mit.edu>,
klensin at mci.net, PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>
Source-Info: From (or Sender) name not authenticated.
At 7:37p -0400 05/08/97, Brad Knowles wrote:
>
> Yup, AOL does some pretty stupid stuff, too. One of my
> favourites was when they banned a certain word that also kept you
> from discussing Shiitake mushrooms.
Huh? What, did they misspell it? Sounds to me like you've got the makings of a system-wide interactive spell checker. If I were AOL, I'd pursue that... ;)
-Walter
"I spell perfectly; I jsut cna't tpye."
__________________________________________________________________________
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 cnri by ietf.org id aa17425; 9 May 97 1:40 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02601;
9 May 97 1:40 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <DAA09472 at pad-thai.cam.ov.com>; Fri, 9 May 1997 03:55:43 GMT
Date: Thu, 8 May 1997 23:55:04 -0400
Message-Id: <9705090355.AA16015 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Cc: Mark Eichin <eichin at cygnus.com>, kerberos at mit.edu, bcn at isi.edu
Cc: cat-ietf at mit.edu
In-Reply-To: Bill Sommerfeld's message of Wed, 07 May 1997 12:09:31 -0400,
<199705071609.MAA02709 at thunk.ch.apollo.hp.com>
Subject: Re: Looking for advice on inter-machine timestamp epoch problem
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 07 May 1997 12:09:31 -0400
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
I've seen this behavior in the past; for all I know it may still be
there. off the top of my head, I believe that there is one of the
timestamps which is *NOT* an ASN.1 OPTIONAL but which probably should
have been (I think it's the requested end time, but, being away from
my source tree I'm not certain).
Bill's right. Endtime is NOT an ASN.1 optional field, probably because
sometime during the krb5 protocol development people considered infinite
lifetime tickets to be too dangerous. Unfortunately it looks like once
again the code never tracked the changes made during the protocol
definition.
Again, (*if* I'm remembering it correctly) the KDC interprets the zero
time_t as meaning either "as long as possible" or "default lifetime"..
Cleaning this up will be, umm, entertaining..
What will need to do is in RFC-1510 bis is to acknowledge the current
(broken) behavior, and then I'd suggest that we make endtime be ASN.1
OPTIONAL, where implementations SHOULD treat a time of January 1, 1970
(or 1966) as the same as if the endtime field was not specified at all
--- where if the endtime field is not specified, it should mean
"as long as possible" (subject to KDC policy) in a KDC request, and
"indefinite lifetime" in a Kerberos ticket. (Site policy would likely
often prohibit indefinitely lifetime Kerberos tickets, because of the
inherent security risks that they raise, though.)
- Ted
Received: from ietf.org by ietf.org id aa21916; 9 May 97 6:19 EDT
Received: from cnri by ietf.org id aa21712; 9 May 97 6:11 EDT
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa06430; 9 May 97 6:10 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id LAA29647
; Fri, 9 May 1997 11:59:29 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id LAA02268
; Fri, 9 May 1997 11:29:41 +0200 (MET DST)
Received: from faw.uni-ulm.de (merlin.faw.uni-ulm.de [134.60.100.2])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id LAA28902
; Fri, 9 May 1997 11:29:28 +0200 (METDST)
Received: from pc.faw.uni-ulm.de (faw128.faw.uni-ulm.de [134.60.102.128]) by faw.uni-ulm.de (8.7.5/8.7.3) with SMTP id XAA24011; Thu, 8 May 1997 23:00:23 +0200
Posted-Date: Thu, 8 May 1997 23:00:23 +0200
Received: by pc.faw.uni-ulm.de with Microsoft Mail
id <3372B117 at pc.faw.uni-ulm.de>; Thu, 08 May 97 22:07:35 PDT
Sender:ietf-request at ietf.org
From: Benking Heiner <BENKING at faw.uni-ulm.de>
To: 2IN97 <2IN97 at prism.uvsq.fr>, congres <congres at prism.uvsq.fr>
Subject: Re: 21N97
Date: Thu, 08 May 97 13:50:00 PDT
Message-ID: <3372B117 at pc.faw.uni-ulm.de>
Encoding: 179 TEXT
X-Mailer: Microsoft Mail V3.0
Source-Info: From (or Sender) name not authenticated.
----------
> Von: 2IN97
> An: congres
> Betreff: 21N97
> Datum: Mittwoch, 5. M{rz 1997 12:48
>
> I have just received part of a message about a call for papers but the
> important part is missing. Would you send the message again, please?
>
> Regards,
>
> Niall O'Loughlin
>
>
empty rooms in mental flats - looking for locomotion?
in the last line you find some sources and orientation for this message
maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group
list !??
Heiner BENKING
re: SHARING MENTAL HOMES - a QUEST for more MENTAL MOBILITY
here an up-date and maybe a starter in form of a message just needed to send
somewhere
Heiner Benking
_-_
Dear list members,
I try to bridge two lists, as the topics are too close
and it gets boring always getting a grip or grasp and then letting go..
Heiner
> ----------
> Von: owner-debono
> An: DEBONO
> Betreff: Creativity and Rods & Cones
> Datum: Mittwoch, 7. Mai 1997 11:48
>
> In a message dated 97-05-06 11:01:15 EDT, you write:
>
> << ... Have you ever noticed how night vision works. Part of your mind
picks
> up clear images on the periphery of your line of sight, but when you shift
> your focus to where the image was, it loses its definition. I think
> creativity works a little like this: it occurs on the edge of our line of
> sight. If we're not too focussed on what we're looking at, we notice the
> creative image and try to bring it into focus, but if we persist in
peering
> straight ahead, we fail to notice that we even "saw" something "off to the
> side"... I apologize if this musing is self-indulgent and thank you for
the
> provocation. >>
>
> Metaphors are the furnishings of our mental home. Thank you for making a
> very insightful addition to my decor, although I can really only see this
> item peripherally, I guess.
>
> Adam Hansen
> The Generativity Group
----------
> Von: list
> An: unis
> Cc: ThomasM451
> Betreff: Re: simple language & Korea
> Datum: Mittwoch, 7. Mai 1997 23:30
>
> In a message dated 97-05-07 16:17:07 EDT, you write:
>
> <<
> In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
>
> << I admitted up front that I knew nothing about Korea, except that they
> are about to go to war again. What I am asking is not for "ideal"
> situations, but fundamental situations. (this is the second time simple
language has
> been mistaken for idealistic language, interesting) The foundation for
my
> "fantasy" is simply the principle of a loving relationship - mutual
synergy.
>
>
> Hello:
> If the language of form requires us to frame a discussion through a
> particular lense, then we would need to agree to the form/lense up-front.
We
> would also be able to predict all the unconscious variables that would
> surely 'come up' into our field of awareness, as a result of framing such
a
> discussion..........and without saying much more its clear to me why many
> theorists state there is no such thing as com-unication, let alone
'simple
> language'!
>
> My admittedlly incomplete appreciation of Stytematics has me feeling like
we
> are in all the forms at once. .....
_____________________________________________
BEGIN OF MESSAGE:
Hi,
Well I think our mental homes are 'not in order'. We try with precision,
forcing focus on the specifics, but camouflage the whole' as Steve Kurtz
once wrote, but not daring to look for the context, the relations and
connections. As Kant was looking with his carcateristica universalis, i call
it an 'organizing glass' into the inner structure (remember Alice in
WONDERLAND) we can at least build a conceptual house of knowledge, beyond
languages, if we restrict ourselves !! to the general overview, the birds
eye.
The result is that we can suddenly see and get awe as we grasp how little we
know !! See wholeness and worldview discussion and the recent work on:
Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).
I think this focussing on words, as some lists do, can work in coherent
groups, but the moment you jump over the fence, you are lost, as the
NOMINALISTS, go for 'exact words' their code, in a hierarchical order,
knowledge trees. My position is absolutely to the contrary, I am a
CONCEPTUALIST, looking for 'concepts in their context' and try to move,
merge and transform along and across scales.
We have, if we ever want to bridge 'schools' and mental territories have to
see the deeper connections. The mind's eye pondering above shows the way!
I would like to show that Einstein was pondering also about words:
The word or the language, written or spoken,
do not seem to have any impact (role)
in the mechanism of my line of thought.
The mental building blocks of thinking
are certain signs/symbols and more or less clear pictures,
which can be reproduced and combined at will (according desire/wish?)
Albert Einstein
maybe someone can help with the best words !?? as I only have a German
version:
Das Wort oder die Sprache, geschrieben oder gesprochen,
scheinen im Mechanismus meines Gedankenablaufes
}berhaupt keine Rolle zu spielen.
Die psychischen Grundelemente des Denkens
sind bestimmte Zeichen und mehr oder weniger klare Bilder,
die nach Wunsch reproduziert und kombiniert werden k|nnen.
Albert Einstein
I would like to sum up by saying that I profit most by learning the style
and the class of the different lists, my English is not good enough to
discuss with any one of you 'seriously' (I appreciate the braod wandwith
personal aprach anyway!)
but I can tell you that we are all very close, but are typically not aware
of it, all living in our private MENTAL HOMES, in cocoons, and ponder about
details...
As I like to share and feel that I live in some mental homes in parallel (my
cognitive panorama) you are most welcome to visit and move in...
warmely
Heiner
http://www.uia.org/uiadocs/spatialm.htm
http://www.newciv.org/ISSS_Primer/seminrva.html
http://heri.cicv.fr/council/speeches/benkingtxt.html
http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm
Received: from ietf.org by ietf.org id aa22572; 9 May 97 6:52 EDT
Received: from cnri by ietf.org id aa22452; 9 May 97 6:49 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07004; 9 May 97 6:49 EDT
Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA18611>; Fri, 9 May 1997 03:45:59 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id MAA01288
; Fri, 9 May 1997 12:43:47 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id MAA03869
; Fri, 9 May 1997 12:36:24 +0200 (MET DST)
Received: from zuno.com (www.dlib.com [194.72.55.3])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id MAA00951
; Fri, 9 May 1997 12:36:12 +0200 (METDST)
Received: from chatahoochee by zuno.com
id LAA00672; Fri, 9 May 1997 11:41:16 +0100
Received: from indus by chatahoochee (NX5.67g/NX3.0M)
id AA18772; Fri, 9 May 97 11:41:15 +0100
Received: by indus.dlib.com with Microsoft Mail
id <01BC5C6D.59268AA0 at indus.dlib.com>; Fri, 9 May 1997 11:37:17 +0100
Message-Id: <01BC5C6D.59268AA0 at indus.dlib.com>
Sender:ietf-request at ietf.org
From: Joerg Mueller <jpm at zuno.com>
To: 'Benking Heiner' <BENKING at faw.uni-ulm.de>, 2IN97 <2IN97 at prism.uvsq.fr>,
congres <congres at prism.uvsq.fr>
Subject: RE: 21N97
Date: Fri, 9 May 1997 11:37:16 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Hi,
whoever is responsible for this list, PLEASE remove me from it. I am not interested at all in receiving that crap.
Thanks
-- joerg
----------
> Von: 2IN97
> An: congres
> Betreff: 21N97
> Datum: Mittwoch, 5. M{rz 1997 12:48
>
> I have just received part of a message about a call for papers but the
> important part is missing. Would you send the message again, please?
>
> Regards,
>
> Niall O'Loughlin
>
>
empty rooms in mental flats - looking for locomotion?
in the last line you find some sources and orientation for this message
maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group
list !??
Heiner BENKING
re: SHARING MENTAL HOMES - a QUEST for more MENTAL MOBILITY
here an up-date and maybe a starter in form of a message just needed to send
somewhere
Heiner Benking
_-_
Dear list members,
I try to bridge two lists, as the topics are too close
and it gets boring always getting a grip or grasp and then letting go..
Heiner
> ----------
> Von: owner-debono
> An: DEBONO
> Betreff: Creativity and Rods & Cones
> Datum: Mittwoch, 7. Mai 1997 11:48
>
> In a message dated 97-05-06 11:01:15 EDT, you write:
>
> << ... Have you ever noticed how night vision works. Part of your mind
picks
> up clear images on the periphery of your line of sight, but when you shift
> your focus to where the image was, it loses its definition. I think
> creativity works a little like this: it occurs on the edge of our line of
> sight. If we're not too focussed on what we're looking at, we notice the
> creative image and try to bring it into focus, but if we persist in
peering
> straight ahead, we fail to notice that we even "saw" something "off to the
> side"... I apologize if this musing is self-indulgent and thank you for
the
> provocation. >>
>
> Metaphors are the furnishings of our mental home. Thank you for making a
> very insightful addition to my decor, although I can really only see this
> item peripherally, I guess.
>
> Adam Hansen
> The Generativity Group
----------
> Von: list
> An: unis
> Cc: ThomasM451
> Betreff: Re: simple language & Korea
> Datum: Mittwoch, 7. Mai 1997 23:30
>
> In a message dated 97-05-07 16:17:07 EDT, you write:
>
> <<
> In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
>
> << I admitted up front that I knew nothing about Korea, except that they
> are about to go to war again. What I am asking is not for "ideal"
> situations, but fundamental situations. (this is the second time simple
language has
> been mistaken for idealistic language, interesting) The foundation for
my
> "fantasy" is simply the principle of a loving relationship - mutual
synergy.
>
>
> Hello:
> If the language of form requires us to frame a discussion through a
> particular lense, then we would need to agree to the form/lense up-front.
We
> would also be able to predict all the unconscious variables that would
> surely 'come up' into our field of awareness, as a result of framing such
a
> discussion..........and without saying much more its clear to me why many
> theorists state there is no such thing as com-unication, let alone
'simple
> language'!
>
> My admittedlly incomplete appreciation of Stytematics has me feeling like
we
> are in all the forms at once. .....
_____________________________________________
BEGIN OF MESSAGE:
Hi,
Well I think our mental homes are 'not in order'. We try with precision,
forcing focus on the specifics, but camouflage the whole' as Steve Kurtz
once wrote, but not daring to look for the context, the relations and
connections. As Kant was looking with his carcateristica universalis, i call
it an 'organizing glass' into the inner structure (remember Alice in
WONDERLAND) we can at least build a conceptual house of knowledge, beyond
languages, if we restrict ourselves !! to the general overview, the birds
eye.
The result is that we can suddenly see and get awe as we grasp how little we
know !! See wholeness and worldview discussion and the recent work on:
Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).
I think this focussing on words, as some lists do, can work in coherent
groups, but the moment you jump over the fence, you are lost, as the
NOMINALISTS, go for 'exact words' their code, in a hierarchical order,
knowledge trees. My position is absolutely to the contrary, I am a
CONCEPTUALIST, looking for 'concepts in their context' and try to move,
merge and transform along and across scales.
We have, if we ever want to bridge 'schools' and mental territories have to
see the deeper connections. The mind's eye pondering above shows the way!
I would like to show that Einstein was pondering also about words:
The word or the language, written or spoken,
do not seem to have any impact (role)
in the mechanism of my line of thought.
The mental building blocks of thinking
are certain signs/symbols and more or less clear pictures,
which can be reproduced and combined at will (according desire/wish?)
Albert Einstein
maybe someone can help with the best words !?? as I only have a German
version:
Das Wort oder die Sprache, geschrieben oder gesprochen,
scheinen im Mechanismus meines Gedankenablaufes
}berhaupt keine Rolle zu spielen.
Die psychischen Grundelemente des Denkens
sind bestimmte Zeichen und mehr oder weniger klare Bilder,
die nach Wunsch reproduziert und kombiniert werden k|nnen.
Albert Einstein
I would like to sum up by saying that I profit most by learning the style
and the class of the different lists, my English is not good enough to
discuss with any one of you 'seriously' (I appreciate the braod wandwith
personal aprach anyway!)
but I can tell you that we are all very close, but are typically not aware
of it, all living in our private MENTAL HOMES, in cocoons, and ponder about
details...
As I like to share and feel that I live in some mental homes in parallel (my
cognitive panorama) you are most welcome to visit and move in...
warmely
Heiner
http://www.uia.org/uiadocs/spatialm.htm
http://www.newciv.org/ISSS_Primer/seminrva.html
http://heri.cicv.fr/council/speeches/benkingtxt.html
http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm
Received: from ietf.org by ietf.org id aa23456; 9 May 97 7:36 EDT
Received: from cnri by ietf.org id aa23264; 9 May 97 7:30 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07583; 9 May 97 7:30 EDT
Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA19320>; Fri, 9 May 1997 04:26:31 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA02715
; Fri, 9 May 1997 13:20:48 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA04799
; Fri, 9 May 1997 13:12:20 +0200 (MET DST)
Received: from durandal.ibp.fr (durandal.ibp.fr [132.227.60.2])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA02295
; Fri, 9 May 1997 13:12:19 +0200 (METDST)
Received: from masi.ibp.fr (masi.ibp.fr [132.227.64.100])
by durandal.ibp.fr (8.8.5/jtpda-5.2) with ESMTP id NAA11897
; Fri, 9 May 1997 13:12:17 +0200 (MET DST)
Received: from hera.ibp.fr (hera-gw.ibp.fr [132.227.60.32])
by masi.ibp.fr (8.6.11/jtpda-5.0) with ESMTP id NAA16257
; Fri, 9 May 1997 13:09:47 +0200
Received: from enee.ipv6.ibp.fr (root at enee.ipv6.ibp.fr [132.227.61.53])
by hera.ibp.fr (8.8.5/jtpda-5.0) with ESMTP id NAA13911
; Fri, 9 May 1997 13:09:33 +0200 (MET DST)
Received: from enee.ipv6.ibp.fr (localhost [127.0.0.1]) by enee.ipv6.ibp.fr (8.8.4/8.7.3) with ESMTP id NAA00886; Fri, 9 May 1997 13:12:04 +0200
X-Orig-Sender: Yoan.Adida at masi.ibp.fr
Message-Id: <3373067F.3E400605 at masi.ibp.fr>
Date: Fri, 09 May 1997 13:11:59 +0200
Sender:ietf-request at ietf.org
From: Yoan ADIDA <adida at masi.ibp.fr>
X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.1.23 i586)
Mime-Version: 1.0
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: REMOVE
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Hi,
could you please remove me from the mailing-list.
I never asked to get into it.
--
Adida Yoan
"Honni soit qui manigance , bien mal acquis ne profite qu'apres"
-- Coluche
Received: from ietf.org by ietf.org id aa23690; 9 May 97 7:42 EDT
Received: from cnri by ietf.org id aa23566; 9 May 97 7:38 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07712; 9 May 97 7:38 EDT
Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA19500>; Fri, 9 May 1997 04:34:37 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA03345
; Fri, 9 May 1997 13:30:16 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA05121
; Fri, 9 May 1997 13:22:12 +0200 (MET DST)
Received: from kvikk.uit.no (kvikk.Uit.No [129.242.4.32])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA02846
; Fri, 9 May 1997 13:22:06 +0200 (METDST)
Received: from sprint.cc.uit.no (sprint.Cc.Uit.No [129.242.5.198])
by kvikk.uit.no (8.8.5/8.8.5) with ESMTP id NAA09670;
Fri, 9 May 1997 13:20:44 +0200 (METDST)
Received: from mohican.cc.uit.no (mohican.Cc.Uit.No [129.242.6.93])
by sprint.cc.uit.no (8.8.5/8.8.5) with ESMTP id NAA00138;
Fri, 9 May 1997 13:20:43 +0200 (METDST)
Received: from localhost (svenn at localhost)
by mohican.cc.uit.no (8.8.5/8.8.5) with ESMTP id NAA16335;
Fri, 9 May 1997 13:20:41 +0200 (METDST)
Message-Id: <199705091120.NAA16335 at mohican.cc.uit.no>
X-Authentication-Warning: mohican.cc.uit.no: svenn owned process doing -bs
X-Mailer: exmh version 2.0gamma 1/27/96
To: Joerg Mueller <jpm at zuno.com>
Cc: 'Benking Heiner' <BENKING at faw.uni-ulm.de>, 2IN97 <2IN97 at prism.uvsq.fr>,
congres <congres at prism.uvsq.fr>, svenn at cc.uit.no
Subject: Re: 21N97
In-Reply-To: Your message of "Fri, 09 May 1997 11:37:16 METDST."
<01BC5C6D.59268AA0 at indus.dlib.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 May 1997 13:19:40 +0200
Sender:ietf-request at ietf.org
From: Svenn Hanssen <Svenn.Agnar.Hanssen at cc.uit.no>
Source-Info: From (or Sender) name not authenticated.
I concur!!!
-Svenn
> Hi,
>
> whoever is responsible for this list, PLEASE remove me from it. I am not interested at all in receiving that crap.
>
> Thanks
>
> -- joerg
>
> ----------
> > Von: 2IN97
> > An: congres
> > Betreff: 21N97
> > Datum: Mittwoch, 5. M{rz 1997 12:48
> >
> > I have just received part of a message about a call for papers but the
> > important part is missing. Would you send the message again, please?
> >
> > Regards,
> >
> > Niall O'Loughlin
> >
> >
> empty rooms in mental flats - looking for locomotion?
> in the last line you find some sources and orientation for this message
>
> maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group
> list !??
>
> Heiner BENKING
>
>
> re: SHARING MENTAL HOMES - a QUEST for more MENTAL MOBILITY
>
>
> here an up-date and maybe a starter in form of a message just needed to send
> somewhere
>
> Heiner Benking
>
> _-_
>
> Dear list members,
> I try to bridge two lists, as the topics are too close
> and it gets boring always getting a grip or grasp and then letting go..
> Heiner
>
> > ----------
> > Von: owner-debono
> > An: DEBONO
> > Betreff: Creativity and Rods & Cones
> > Datum: Mittwoch, 7. Mai 1997 11:48
> >
> > In a message dated 97-05-06 11:01:15 EDT, you write:
> >
> > << ... Have you ever noticed how night vision works. Part of your mind
> picks
> > up clear images on the periphery of your line of sight, but when you shift
> > your focus to where the image was, it loses its definition. I think
> > creativity works a little like this: it occurs on the edge of our line of
> > sight. If we're not too focussed on what we're looking at, we notice the
> > creative image and try to bring it into focus, but if we persist in
> peering
> > straight ahead, we fail to notice that we even "saw" something "off to the
> > side"... I apologize if this musing is self-indulgent and thank you for
> the
> > provocation. >>
> >
> > Metaphors are the furnishings of our mental home. Thank you for making a
> > very insightful addition to my decor, although I can really only see this
> > item peripherally, I guess.
> >
> > Adam Hansen
> > The Generativity Group
>
> ----------
> > Von: list
> > An: unis
> > Cc: ThomasM451
> > Betreff: Re: simple language & Korea
> > Datum: Mittwoch, 7. Mai 1997 23:30
> >
> > In a message dated 97-05-07 16:17:07 EDT, you write:
> >
> > <<
> > In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
> >
> > << I admitted up front that I knew nothing about Korea, except that they
> > are about to go to war again. What I am asking is not for "ideal"
> > situations, but fundamental situations. (this is the second time simple
> language has
> > been mistaken for idealistic language, interesting) The foundation for
> my
> > "fantasy" is simply the principle of a loving relationship - mutual
> synergy.
> >
> >
> > Hello:
> > If the language of form requires us to frame a discussion through a
> > particular lense, then we would need to agree to the form/lense up-front.
> We
> > would also be able to predict all the unconscious variables that would
> > surely 'come up' into our field of awareness, as a result of framing such
> a
> > discussion..........and without saying much more its clear to me why many
> > theorists state there is no such thing as com-unication, let alone
> 'simple
> > language'!
> >
> > My admittedlly incomplete appreciation of Stytematics has me feeling like
> we
> > are in all the forms at once. .....
>
> _____________________________________________
> BEGIN OF MESSAGE:
>
> Hi,
>
> Well I think our mental homes are 'not in order'. We try with precision,
> forcing focus on the specifics, but camouflage the whole' as Steve Kurtz
> once wrote, but not daring to look for the context, the relations and
> connections. As Kant was looking with his carcateristica universalis, i call
> it an 'organizing glass' into the inner structure (remember Alice in
> WONDERLAND) we can at least build a conceptual house of knowledge, beyond
> languages, if we restrict ourselves !! to the general overview, the birds
> eye.
> The result is that we can suddenly see and get awe as we grasp how little we
> know !! See wholeness and worldview discussion and the recent work on:
> Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).
>
> I think this focussing on words, as some lists do, can work in coherent
> groups, but the moment you jump over the fence, you are lost, as the
> NOMINALISTS, go for 'exact words' their code, in a hierarchical order,
> knowledge trees. My position is absolutely to the contrary, I am a
> CONCEPTUALIST, looking for 'concepts in their context' and try to move,
> merge and transform along and across scales.
>
> We have, if we ever want to bridge 'schools' and mental territories have to
> see the deeper connections. The mind's eye pondering above shows the way!
>
> I would like to show that Einstein was pondering also about words:
>
> The word or the language, written or spoken,
> do not seem to have any impact (role)
> in the mechanism of my line of thought.
> The mental building blocks of thinking
> are certain signs/symbols and more or less clear pictures,
> which can be reproduced and combined at will (according desire/wish?)
>
> Albert Einstein
>
> maybe someone can help with the best words !?? as I only have a German
> version:
>
> Das Wort oder die Sprache, geschrieben oder gesprochen,
> scheinen im Mechanismus meines Gedankenablaufes
> }berhaupt keine Rolle zu spielen.
> Die psychischen Grundelemente des Denkens
> sind bestimmte Zeichen und mehr oder weniger klare Bilder,
> die nach Wunsch reproduziert und kombiniert werden k|nnen.
>
> Albert Einstein
>
>
> I would like to sum up by saying that I profit most by learning the style
> and the class of the different lists, my English is not good enough to
> discuss with any one of you 'seriously' (I appreciate the braod wandwith
> personal aprach anyway!)
>
> but I can tell you that we are all very close, but are typically not aware
> of it, all living in our private MENTAL HOMES, in cocoons, and ponder about
> details...
>
> As I like to share and feel that I live in some mental homes in parallel (my
> cognitive panorama) you are most welcome to visit and move in...
>
> warmely
>
> Heiner
> http://www.uia.org/uiadocs/spatialm.htm
> http://www.newciv.org/ISSS_Primer/seminrva.html
> http://heri.cicv.fr/council/speeches/benkingtxt.html
> http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm
>
>
>
>
Received: from ietf.org by ietf.org id aa24258; 9 May 97 8:02 EDT
Received: from cnri by ietf.org id aa23994; 9 May 97 7:56 EDT
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa07986; 9 May 97 7:56 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA04511
; Fri, 9 May 1997 13:52:44 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA06091
; Fri, 9 May 1997 13:44:13 +0200 (MET DST)
Received: from ufc (ufc.univ-fcomte.fr [194.57.91.200])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id NAA03986
; Fri, 9 May 1997 13:44:12 +0200 (METDST)
Received: from comte.univ-fcomte. (comte.univ-fcomte.fr) by ufc (5.x/SMI-SVR4)
id AA08973; Fri, 9 May 1997 13:38:37 +0100
Received: from localhost by comte.univ-fcomte. (SMI-8.6/SMI-SVR4)
id NAA18945; Fri, 9 May 1997 13:42:35 +0100
Date: Fri, 9 May 1997 13:42:34 +0100 (WET DST)
Sender:ietf-request at ietf.org
From: Romain Bigeard <bigeard at comte.univ-fcomte.fr>
X-Sender: bigeard at comte
Cc: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: Re: REMOVE
In-Reply-To: <3373067F.3E400605 at masi.ibp.fr>
Message-Id: <Pine.SOL.3.96.970509134131.18931A-100000 at comte>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Please Remove me from this mailing list. Il have better things to do than
to read that crap !
***************************************************
Romain Bigeard
Laboratoire d'Informatique de Besancon
16 Route de Gray 25030 Besancon Cedex FRANCE
Tel : +(33) 3 81 66 64 60 Fax : +(33) 3 81 66 64 50
***************************************************
Received: from ietf.org by ietf.org id aa24328; 9 May 97 8:02 EDT
Received: from cnri by ietf.org id aa24085; 9 May 97 7:58 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08015; 9 May 97 7:58 EDT
Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA19880>; Fri, 9 May 1997 04:55:18 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA04523
; Fri, 9 May 1997 13:52:52 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA06068
; Fri, 9 May 1997 13:43:33 +0200 (MET DST)
Received: from rap.cefriel.it (rap3.cefriel.it [131.175.3.6])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA03969
; Fri, 9 May 1997 13:43:22 +0200 (METDST)
Received: from polo (polo [131.175.5.37])
by rap.cefriel.it (8.8.5/8.8.5) with SMTP id NAA21690;
Fri, 9 May 1997 13:41:25 +0200 (MET DST)
X-Orig-Sender: campanal at rap3.cefriel.it
Message-Id: <33730D3B.55A at mailer.cefriel.it>
Date: Fri, 09 May 1997 13:40:43 +0200
Sender:ietf-request at ietf.org
From: Giuseppe Fabio Campanale <campanal at rap3.cefriel.it>
Organization: CEFRIEL - COGEFO
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: REMOVE
References: <3373067F.3E400605 at masi.ibp.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
>
> Hi,
>
> could you please remove me from the mailing-list.
>
> I never asked to get into it.
>
--
++++++++++++++++++++++++++++++++++++++++++++++
Giuseppe Fabio Campanale
c/o CEFRIEL - Politecnico di Milano
Via L. Emanueli, 15
20126 MILANO - Italy
mailto:campanal at mailer.cefriel.it
fax : +39-2-66-100-448
URL : http://www.cefriel.it/
Life is what happens to you while you're busy
making other plans.
- John Lennon
++++++++++++++++++++++++++++++++++++++++++++++
Received: from ietf.org by ietf.org id aa24895; 9 May 97 8:18 EDT
Received: from cnri by ietf.org id aa24648; 9 May 97 8:14 EDT
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa08362; 9 May 97 8:14 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA05791
; Fri, 9 May 1997 14:07:52 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA06829
; Fri, 9 May 1997 13:59:34 +0200 (MET DST)
Received: from ufc (ufc.univ-fcomte.fr [194.57.91.200])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id NAA05012
; Fri, 9 May 1997 13:59:32 +0200 (METDST)
Received: from comte.univ-fcomte. (comte.univ-fcomte.fr) by ufc (5.x/SMI-SVR4)
id AA09069; Fri, 9 May 1997 13:53:58 +0100
Received: from localhost by comte.univ-fcomte. (SMI-8.6/SMI-SVR4)
id NAA19247; Fri, 9 May 1997 13:57:18 +0100
Date: Fri, 9 May 1997 13:57:17 +0100 (WET DST)
Sender:ietf-request at ietf.org
From: Romain Bigeard <bigeard at comte.univ-fcomte.fr>
X-Sender: bigeard at comte
To: Romain Bigeard <bigeard at comte.univ-fcomte.fr>
Cc: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: UNSUSCRIBE
In-Reply-To: <Pine.SOL.3.96.970509134131.18931A-100000 at comte>
Message-Id: <Pine.SOL.3.96.970509135710.18931C-100000 at comte>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Received: from ietf.org by ietf.org id aa24903; 9 May 97 8:18 EDT
Received: from cnri by ietf.org id aa24680; 9 May 97 8:14 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08367; 9 May 97 8:14 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA20221>; Fri, 9 May 1997 05:10:36 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id NAA08792
; Fri, 9 May 1997 13:58:43 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA06182
; Fri, 9 May 1997 13:48:36 +0200 (MET DST)
Received: from teco01a.teco.uni-karlsruhe.de (teco01a.teco.uni-karlsruhe.de [129.13.170.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA04128
; Fri, 9 May 1997 13:48:29 +0200 (METDST)
Received: from teco11a.teco.uni-karlsruhe.de by teco01a.teco.uni-karlsruhe.de (8.8.5)
id NAA11288; Fri, 9 May 1997 13:48:28 +0200 (MET DST)
Received: by teco11a.teco.uni-karlsruhe.de (8.8.5)
id NAA02310; Fri, 9 May 1997 13:48:28 +0200 (MET DST)
Date: Fri, 9 May 1997 13:48:28 +0200 (MET DST)
Message-Id: <199705091148.NAA02310 at teco11a.teco.uni-karlsruhe.de>
Sender:ietf-request at ietf.org
From: Hans-Werner Gellersen <hwg at teco.uni-karlsruhe.de>
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
In-Reply-To: <3373067F.3E400605 at masi.ibp.fr> (message from Yoan ADIDA on Fri,
09 May 1997 13:11:59 +0200)
Subject: Re: REMOVE
Source-Info: From (or Sender) name not authenticated.
Please remove me from the mailing-list NOW.
I never asked to get into it.
Received: from ietf.org by ietf.org id aa25323; 9 May 97 8:26 EDT
Received: from cnri by ietf.org id aa25075; 9 May 97 8:21 EDT
Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa08567;
9 May 97 8:21 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id NAA08791
; Fri, 9 May 1997 13:58:45 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA06173
; Fri, 9 May 1997 13:48:09 +0200 (MET DST)
Received: from diane.univ-poitiers.fr (diane.univ-poitiers.fr [193.55.161.66])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id NAA04113
; Fri, 9 May 1997 13:48:08 +0200 (METDST)
Received: from [193.55.163.74] by diane.univ-poitiers.fr, Fri, 9 May 97 13:45:13 +0200
Date: Fri, 9 May 97 13:45:13 +0200
X-Sender: cottet at diane.univ-poitiers.fr
Message-Id: <v01540b00af98db595f3f at [193.55.163.74]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Sender:ietf-request at ietf.org
From: Francis Cottet <cottet at diane.univ-poitiers.fr>
Subject: REMOVE
Source-Info: From (or Sender) name not authenticated.
Hi,
could you please remove me from the mailing-list.
I never asked to get into it.
Francis Cottet
*********************************************************************
Francis Cottet Professeur
LISI - ENSMA Tel: 05-49-49-80-52 / Fax: 05-49-49-80-64
B.P. 109 e-mail: cottet at ensma.univ-poitiers.fr
86960 Futuroscope FRANCE
*********************************************************************
Received: from ietf.org by ietf.org id aa26545; 9 May 97 8:56 EDT
Received: from cnri by ietf.org id aa26416; 9 May 97 8:50 EDT
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa09731; 9 May 97 8:50 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA09147
; Fri, 9 May 1997 14:46:13 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id OAA07107
; Fri, 9 May 1997 14:03:16 +0200 (MET DST)
Received: from PAPRIKA.MIT.EDU (PAPRIKA.MIT.EDU [18.244.0.30])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA05326
; Fri, 9 May 1997 14:03:09 +0200 (METDST)
Received: (from luka at localhost)
by PAPRIKA.MIT.EDU (8.8.5/8.8.5) id IAA01810;
Fri, 9 May 1997 08:02:45 -0400
Sender:ietf-request at ietf.org
From: Luka (Peter) <luka at mit.edu>
Message-Id: <199705091202.IAA01810 at PAPRIKA.MIT.EDU>
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: list/removals
Date: Fri, 09 May 1997 08:02:44 EDT
Source-Info: From (or Sender) name not authenticated.
everyone:
please stop sending removal requests to the list
(at least temporarily - until the listmaint has a chance to respond).
listmaint:
1. remove me from this list.
2. please post to the list a message on where/how to send unsubscription
requests, other than to the main list itself.
-peter luka, luka at mit.edu
Received: from ietf.org by ietf.org id aa26882; 9 May 97 9:03 EDT
Received: from cnri by ietf.org id aa26781; 9 May 97 9:01 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa09994; 9 May 97 9:01 EDT
Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA21439>; Fri, 9 May 1997 05:57:32 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA10059
; Fri, 9 May 1997 14:54:38 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id OAA07129
; Fri, 9 May 1997 14:03:35 +0200 (MET DST)
Received: from sanson.dit.upm.es ([138.4.2.10])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id OAA09071
; Fri, 9 May 1997 14:01:20 +0200 (METDST)
Received: from maja.dit.upm.es (maja-gw.dit.upm.es [138.4.2.53]) by sanson.dit.upm.es (8.8.4/3.13) with SMTP id NAA28314; Fri, 9 May 1997 13:54:46 +0200 (MET DST)
Received: (aalvarez at localhost) by maja.dit.upm.es (8.6.10/3.13) id NAA26268; Fri, 9 May 1997 13:54:41 +0200
Date: Fri, 9 May 1997 13:54:41 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Angel Alvarez <aalvarez at dit.upm.es>
X-Sender: aalvarez at maja
To: Yoan ADIDA <adida at masi.ibp.fr>
Cc: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: Re: REMOVE
In-Reply-To: <3373067F.3E400605 at masi.ibp.fr>
Message-Id: <Pine.SUN.3.91.970509135421.26179C-100000 at maja>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Same with me ...
Angel Alvarez
On Fri, 9 May 1997, Yoan ADIDA wrote:
> Hi,
>
> could you please remove me from the mailing-list.
>
> I never asked to get into it.
>
> --
> Adida Yoan
>
> "Honni soit qui manigance , bien mal acquis ne profite qu'apres"
> -- Coluche
>
Received: from ietf.org by ietf.org id aa27488; 9 May 97 9:09 EDT
Received: from cnri by ietf.org id aa27217; 9 May 97 9:06 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10139; 9 May 97 9:06 EDT
Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA21592>; Fri, 9 May 1997 06:02:38 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA10479
; Fri, 9 May 1997 14:59:40 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id OAA08192
; Fri, 9 May 1997 14:16:45 +0200 (MET DST)
Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA06609
; Fri, 9 May 1997 14:16:41 +0200 (METDST)
Message-Id: <199705091216.OAA06609 at soleil.uvsq.fr>
Received: from bcarsfba.ott.bnr.ca (actually bcarsfba.bnr.ca)
by bcarsde4.localhost; Fri, 9 May 1997 08:10:57 -0400
Received: from bnr.ca by bcarsfba.bnr.ca id <02811-0 at bcarsfba.bnr.ca>;
Fri, 9 May 1997 08:08:09 -0400
Date: 09 May 1997 08:08 EDT
X-Orig-Sender: Paul Coverdale <paulcov at nortel.ca>
To: bigeard at comte.univ-fcomte.fr
Cc: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Sender:ietf-request at ietf.org
From: Paul Coverdale <paulcov at nortel.ca>
Subject: Re: REMOVE
Source-Info: From (or Sender) name not authenticated.
It's not my mailing list ! I don't know who originated the first
message, but it wasn't me !
In message " REMOVE", bigeard at comte.univ-fcomte.fr writes:
>
>Please Remove me from this mailing list. Il have better things to do
than
>to read that crap !
>
>
>***************************************************
>Romain Bigeard
>Laboratoire d'Informatique de Besancon
>16 Route de Gray 25030 Besancon Cedex FRANCE
>Tel : +(33) 3 81 66 64 60 Fax : +(33) 3 81 66 64 50
>***************************************************
>
>
Received: from ietf.org by ietf.org id aa27981; 9 May 97 9:22 EDT
Received: from ns.jck.com by ietf.org id aa27775; 9 May 97 9:19 EDT
Received: from tp7.Jck.com ("port 3883"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0E9X0TR5600N40 at a4.jck.com>
for ietf at ietf.org; Fri, 9 May 1997 09:15:28 -0400 (EDT)
Date: Fri, 09 May 1997 09:15:25 -0400 (EDT)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: AOL mail traffic
In-reply-to: <199705082316.QAA00698 at leonid.genesyslab.com>
To: Leonid Yegoshin <egoshin at genesyslab.com>
Cc: KnowlesB at aol.net, ietf at ietf.org
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9705090925.V at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Thu, 08 May 1997 16:16:24 -0700 Leonid Yegoshin
<egoshin at genesyslab.com> wrote:
> >From: Brad Knowles <BKnowles at aol.net>
> >...
> > Lose your love affair with that part of RFC 1123, because it
> >*is* going away, sooner or later. Maybe not with whatever will
> >become of draft-ietf-drums-smtpupd-04.txt, but sooner or later it
> >*will* go away.
> >
> If this draft would be incompatible with SMTP (all RFCs set) and practice,
> please request and use ANOTHER TCP port for this service. Period.
Please don't criticize --at least on the IETF list-- what
your obviously haven't read. The difference between the
text relating to this issue in 1123 and that in smtpupd-04
is a slight shading of the recommended behavior. Both are
unfavorable to the use of source routes; the newer document
(with the consensus of the WG and as part of a very clear
evolutionary trend) discourages them more strongly than the
older one. Neither document requires that sites bounce
mail whose envelope contains source routes -- we try to
avoid writing requirements which we know will be ignored
(the small excursion in a similar direction in 1123 has
been removed from smptupd-04). Conversely, neither
document requires that badly-formatted mail be delivered,
pretty much for the same reason:
Some sites will conclude that delivering everything that
can be delivered, no matter what problems occur later, is
the correct behavior. Other sites will conclude that
delivering trash just leads to more trash and that the
system and support costs are too high and will try to
bounce the stuff.
The only thing the standards and drafts (821, 1123,
smtpupd-04) try to insist upon is that whatever is done be
done in an orderly fashion, e.g., once something is
accepted for delivery, throwing it away without either
delivering it or attempting to send out an NDN is a bad
idea.
john
Received: from ietf.org by ietf.org id aa28452; 9 May 97 9:35 EDT
Received: from cnri by ietf.org id aa28310; 9 May 97 9:32 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10830; 9 May 97 9:32 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA22360>; Fri, 9 May 1997 06:29:00 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id PAA15599
; Fri, 9 May 1997 15:23:40 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id PAA11427
; Fri, 9 May 1997 15:05:07 +0200 (MET DST)
Received: from asterix.gi.utc (asterix.hds.utc.fr [193.104.177.49])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id PAA10983
; Fri, 9 May 1997 15:05:05 +0200 (METDST)
Received: (from aloria at localhost) by asterix.gi.utc (8.8.3/8.6.12) id OAA04905; Fri, 9 May 1997 14:48:07 +0200 (MET DST)
Date: Fri, 9 May 1997 14:48:07 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Antonio Loria <Antonio.Loria at hds.utc.fr>
Message-Id: <199705091248.OAA04905 at asterix.gi.utc>
To: postmaster at prism.uvsq.fr
Subject: REMOVE
Cc: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr
X-Sun-Charset: US-ASCII
Source-Info: From (or Sender) name not authenticated.
Received: from ietf.org by ietf.org id aa28781; 9 May 97 9:38 EDT
Received: from ietf.ietf.org by ietf.org id aa28569; 9 May 97 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: srvloc at corp.home.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-svrloc-advertising-01.txt
Date: Fri, 09 May 1997 09:35:25 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705090935.aa28569 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 Service Location Protocol
Working Group of the IETF.
Title : Advertising Services (Providing information to support
service discovery)
Author(s) : R. Moats, M. Hamilton
Filename : draft-ietf-svrloc-advertising-01.txt
Pages : 11
Date : 05/08/1997
This document proposes a solution to the problem of finding information
about that services are being offered at a particular Internet domain,
based on deployment experience with the Netfind White Pages directory
software.
This approach makes it possible to supply clients with more information
than the DNS aliases that have been widely deployed in this role - notably
the port numbers being used by servers. However, it is not without
problems, and we have tried to take account of these.
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-svrloc-advertising-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-advertising-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-svrloc-advertising-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: <19970508113232.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-advertising-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-advertising-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970508113232.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28778; 9 May 97 9:38 EDT
Received: from ietf.ietf.org by ietf.org id aa28526; 9 May 97 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: srvloc at corp.home.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-svrloc-discovery-01.txt
Date: Fri, 09 May 1997 09:35:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705090935.aa28526 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 Service Location Protocol
Working Group of the IETF.
Title : Finding Stuff (How to discover services)
Author(s) : R. Moats, M. Hamilton, P. Leach
Filename : draft-ietf-svrloc-discovery-01.txt
Pages : 6
Date : 05/08/1997
This document proposes a solution to the problem of finding information
about that services are being offered at a particular Internet domain.
Therefore, it is possible for clients, using this approach, to locate
services in a domain with only prior knowledge of the domain 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-svrloc-discovery-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-discovery-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-svrloc-discovery-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: <19970508112750.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-discovery-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-discovery-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970508112750.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28782; 9 May 97 9:38 EDT
Received: from ietf.ietf.org by ietf.org id aa28605; 9 May 97 9:35 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-01.txt
Date: Fri, 09 May 1997 09:35:32 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705090935.aa28605 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 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-01.txt
Pages : 33
Date : 05/08/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
subsystem, 2) a security subsystem, and 3) a local processing subsystem.
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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-next-gen-arch-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-snmpv3-next-gen-arch-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: <19970508173627.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-next-gen-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-next-gen-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970508173627.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28774; 9 May 97 9:38 EDT
Received: from ietf.ietf.org by ietf.org id aa28457; 9 May 97 9:35 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-fr-update-03.txt
Date: Fri, 09 May 1997 09:35:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705090935.aa28457 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.
Note: This revision reflects comments received during the last call period.
Title : Multiprotocol Interconnect over Frame Relay
Author(s) : C. Brown, A. Malis
Filename : draft-ietf-ion-fr-update-03.txt
Pages : 34
Date : 05/07/1997
This memo describes an encapsulation method for carrying network
interconnect traffic over a Frame Relay backbone. It covers aspects of
both Bridging and Routing.
Systems with the ability to transfer both the encapsulation method
described in this document, and others must have a priori knowledge of
which virtual circuits will carry which encapsulation method and this
encapsulation must only be used over virtual circuits that have been
explicitly configured for its use.
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-fr-update-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-fr-update-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-ion-fr-update-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: <19970507160746.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-fr-update-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-fr-update-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970507160746.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28776; 9 May 97 9:38 EDT
Received: from ietf.ietf.org by ietf.org id aa28507; 9 May 97 9:35 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-gellens-submit-05.txt
Date: Fri, 09 May 1997 09:35:15 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705090935.aa28507 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Message Submission and Relay
Author(s) : R. Gellens, H. Alvestrand
Filename : draft-gellens-submit-05.txt
Pages : 11
Date : 05/08/1997
SMTP was defined as a message *relay* protocol, that is, a means for
message transfer agents (MTAs) to route finished (complete) messages.
SMTP forbids MTAs from altering the message text, except to add 'Received'
header fields.
However, SMTP is now also widely used as a message *submission* protocol,
that is, a means for message user agents (MUAs) to introduce
new messages into the MTA routing network. Regardless of whether
this is good or bad, it is far too late to change.
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-gellens-submit-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gellens-submit-05.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-gellens-submit-05.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: <19970508105826.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gellens-submit-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gellens-submit-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970508105826.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29146; 9 May 97 9:46 EDT
Received: from cnri by ietf.org id aa28917; 9 May 97 9:41 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11371; 9 May 97 9:41 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA22578>; Fri, 9 May 1997 06:37:43 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id PAA17216
; Fri, 9 May 1997 15:34:16 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id PAA12452
; Fri, 9 May 1997 15:28:00 +0200 (MET DST)
Received: from piraya.electrum.kth.se (piraya.electrum.kth.se [130.237.212.130])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id PAA16171
; Fri, 9 May 1997 15:27:59 +0200 (METDST)
Received: from [130.237.212.88] (jekyll2.it.kth.se [130.237.212.88])
by piraya.electrum.kth.se (8.7.3/8.7.3) with SMTP
id PAA01099;
Fri, 9 May 1997 15:27:50 +0200 (MET DST)
Message-Id: <v02110100af98d6dfc938 at [130.237.14.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 9 May 1997 15:28:59 +0200
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Sender:ietf-request at ietf.org
From: =?iso-8859-1?Q?Bj=F6rn?= Pehrson <bjorn at it.kth.se>
Subject: remove please!
Source-Info: From (or Sender) name not authenticated.
Could you please remove me from these mailing-lists.
Received: from ietf.org by ietf.org id ab29745; 9 May 97 10:00 EDT
Received: from cnri by ietf.org id aa29481; 9 May 97 9:56 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11766; 9 May 97 9:56 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA23156>; Fri, 9 May 1997 06:52:32 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id PAA18739
; Fri, 9 May 1997 15:45:19 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id PAA13317
; Fri, 9 May 1997 15:39:55 +0200 (MET DST)
Received: from mailhub.fokus.gmd.de ([193.175.132.209])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id OAA11683
; Fri, 9 May 1997 14:33:20 +0200 (METDST)
Received: from donald.fokus.gmd.de (donald [193.175.132.118])
by mailhub.fokus.gmd.de (8.8.5/8.8.5) with ESMTP id OAA24124;
Fri, 9 May 1997 14:30:19 +0200 (MET DST)
Received: from fokus.gmd.de (localhost [127.0.0.1]) by donald.fokus.gmd.de (SMI-8.6/8.6.12) with ESMTP id OAA05441; Fri, 9 May 1997 14:30:18 +0200
Message-Id: <199705091230.OAA05441 at donald.fokus.gmd.de >
To: Svenn Hanssen <Svenn.Agnar.Hanssen at cc.uit.no>
Cc: Joerg Mueller <jpm at zuno.com>, 'Benking Heiner' <BENKING at faw.uni-ulm.de>,
2IN97 <2IN97 at prism.uvsq.fr>, congres <congres at prism.uvsq.fr>,
svenn at cc.uit.no
Subject: Re: 21N97
In-Reply-To: Your message of "Fri, 09 May 1997 13:19:40 +0200."
<199705091120.NAA16335 at mohican.cc.uit.no>
Date: Fri, 09 May 1997 14:30:14 +0200
Sender:ietf-request at ietf.org
From: Dorgham Sisalem <sisalem at fokus.gmd.de>
Source-Info: From (or Sender) name not authenticated.
would the responsible for this list arrange for a seperate way to delete
the peopole from this list. I do not really want to receive all the delete me
messages and surely not the "I concur" ones in reply. I do not know who is responsible for this mess but who ever it is please fix it quickly. I already received more than 15 mails today from this list on which I DID NOT ASK TO GET ON. So
remove me as well
Dorgham
Received: from ietf.org by ietf.org id aa29857; 9 May 97 10:02 EDT
Received: from cnri by ietf.org id aa29640; 9 May 97 9:59 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11846; 9 May 97 9:59 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA23290>; Fri, 9 May 1997 06:55:39 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id PAA19777
; Fri, 9 May 1997 15:52:36 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id PAA13660
; Fri, 9 May 1997 15:46:06 +0200 (MET DST)
Received: from pawnee.imag.fr (pawnee.imag.fr [129.88.60.35])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id PAA18900
; Fri, 9 May 1997 15:46:02 +0200 (METDST)
Received: from pawnee (ginzburg at localhost [127.0.0.1]) by pawnee.imag.fr (8.6.12/8.6.9) with SMTP id PAA00197; Fri, 9 May 1997 15:55:42 +0200
X-Orig-Sender: ginzburg at pawnee.imag.fr
Message-Id: <33732CDD.7E186A55 at imag.fr>
Date: Fri, 09 May 1997 15:55:41 +0200
Sender:ietf-request at ietf.org
From: Ilan Ginzburg <Ilan.Ginzburg at imag.fr>
Organization: LMC-IMAG, Grenoble, France.
X-Mailer: Mozilla 3.0Gold (X11; I; Linux 1.2.13 i586)
Mime-Version: 1.0
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: Re: UNSUSCRIBE
References: <Pine.SOL.3.96.970509135710.18931C-100000 at comte>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
There is no point in everybody posting 'unsubscribe me' to the whole
lists. This generates A LOT of traffic.
Instead, I mailed a complaint to:
postmaster at shiva.jussieu.fr and postmaster at soleil.uvsq.fr
and another one to postmaster at tristan.faw.uni-ulm.de
Please...
Regards, Ilan Ginzburg.
Received: from ietf.org by ietf.org id aa00728; 9 May 97 10:34 EDT
Received: from cnri by ietf.org id aa00479; 9 May 97 10:30 EDT
Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa12469;
9 May 97 10:30 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA22742
; Fri, 9 May 1997 16:21:07 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id QAA14606
; Fri, 9 May 1997 16:14:58 +0200 (MET DST)
Received: from hugo.int-evry.fr (hugo.int-evry.fr [157.159.100.81])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA21678
; Fri, 9 May 1997 16:14:57 +0200 (METDST)
Received: from iznogoud.int-evry.fr (iznogoud [157.159.100.40]) by hugo.int-evry.fr (8.8.0/8.8.0) with ESMTP id QAA02294; Fri, 9 May 1997 16:01:52 +0200 (MET DST)
Received: from localhost (michel at localhost) by iznogoud.int-evry.fr (8.6.10/8.6.4) with SMTP id QAA16196; Fri, 9 May 1997 16:01:46 +0200
X-Authentication-Warning: iznogoud.int-evry.fr: michel owned process doing -bs
Date: Fri, 9 May 1997 16:01:43 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: "Michel Gardie (LOR-AIGRI)" <michel at hugo.int-evry.fr>
X-Sender: michel at iznogoud
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: remove
Message-ID: <Pine.SUN.3.95.970509160016.11149C-100000 at iznogoud>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Hello.
Could you please remove me from this mailing list?
I never asked to get into it.
--
Michel Gardie | Phone: +33 1 60 76 47 89
Institut National des Telecommunications | Fax: +33 1 60 76 47 11
9, rue Charles Fourier | Email: michel.gardie at int-evry.fr
91011 EVRY Cedex France |
Received: from ietf.org by ietf.org id aa00994; 9 May 97 10:40 EDT
Received: from cnri by ietf.org id aa00626; 9 May 97 10:33 EDT
Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa12567;
9 May 97 10:33 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA23441
; Fri, 9 May 1997 16:25:46 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id PAA13868
; Fri, 9 May 1997 15:50:00 +0200 (MET DST)
Received: from durandal.ibp.fr (durandal.ibp.fr [132.227.60.2])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id PAA19338
; Fri, 9 May 1997 15:49:44 +0200 (METDST)
Received: from masi.ibp.fr (masi.ibp.fr [132.227.64.100])
by durandal.ibp.fr (8.8.5/jtpda-5.2) with ESMTP id PAA17724
; Fri, 9 May 1997 15:37:23 +0200 (MET DST)
Received: from cao-vlsi.ibp.fr (cao-vlsi.ibp.fr [132.227.60.20])
by masi.ibp.fr (8.6.11/jtpda-5.0) with ESMTP id PAA21046
; Fri, 9 May 1997 15:34:53 +0200
Received: from trash.ibp.fr by cao-vlsi.ibp.fr
(8.6.10/jtpda-5.0) with SMTP id PAA04362
; Fri, 9 May 1997 15:36:24 +0200
Sender:ietf-request at ietf.org
From: Nizar ABDALLAH <Nizar.Abdallah at masi.ibp.fr>
Message-Id: <199705091336.PAA04362 at cao-vlsi.ibp.fr>
Subject: REMOVE
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Date: Fri, 9 May 1997 15:36:23 +0200 (MET DST)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Please Remove me from the mailing list
--
Received: from ietf.org by ietf.org id aa01288; 9 May 97 10:53 EDT
Received: from merit.edu by ietf.org id aa00911; 9 May 97 10:37 EDT
Received: from Bill.Simpson.DialUp.Mich.Net (pm047-08.dialip.mich.net [141.211.6.50])
by merit.edu (8.8.5/8.8.5) with SMTP id KAA12531
for <ietf at ietf.org>; Fri, 9 May 1997 10:33:48 -0400 (EDT)
Date: Fri, 9 May 97 14:10:50 GMT
Sender:ietf-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <5840.wsimpson at greendragon.com>
To: ietf at ietf.org
Subject: IETF mail list management suggestions
Source-Info: From (or Sender) name not authenticated.
We have just seen yet another mail exploder "joining". This happened to
the end2end-interest at isi.edu at the same time. My guess is that this
was a deliberate attack of some kind. But it hit IETF 3 times as hard.
1) Perhaps it is time to retire the ietf at isi.edu forward?
This shouldn't be very controversial, since the list hasn't been
maintained there for a very long time. This only affects posting.
2) Perhaps it is time to retire the ietf at cnri.reston.va.us forward?
This is probably more controversial, as the changeover to a new
address was fairly recent. But the members of this list are all
supposedly involved in the IETF, and we probably can handle it
better than members of other lists. This only affects posting.
3) Perhaps it is time to gradually change the name of the list over the
next few months to ietf-discuss at ietf.org, in conjunction with the
existing ietf-announce? Or ietf-members, or some such?
My reason for doing this would be to frustrate remaining usenet
crossfeeds, at least forcing them to check their configuration.
I suspect that crossfeeds to ietf at isi.edu are the ultimate culprit
in this attack.
4) Perhaps the list software could be set to allow postings from list
members only?
OK, maybe that should be a demand rather than a question! Folks
have been asking for this feature to be turned on for years, and it
has been very successful for other mailing lists.
Yes, a small database would need to be maintained for those who have
multiple sending addresses, or are behind local exploders themselves.
But, we really really need this turned on!!!
5) And directly to the point of the present problem: in order to
obviate future attacks like this one, other lists have a
confirmation handshake. Can our software require that, too?
WSimpson at UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson at MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Received: from ietf.org by ietf.org id aa01391; 9 May 97 10:55 EDT
Received: from cnri by ietf.org id aa01111; 9 May 97 10:43 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa12832;
9 May 97 10:42 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA24962>; Fri, 9 May 1997 07:38:46 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA24621
; Fri, 9 May 1997 16:32:53 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id PAA12571
; Fri, 9 May 1997 15:30:10 +0200 (MET DST)
Received: from tidos.tid.es (tidos.tid.es [193.145.240.2])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id PAA16242
; Fri, 9 May 1997 15:28:47 +0200 (METDST)
Received: from delmono.yp.delmono by tidos.tid.es (5.x/SMI-SVR4)
id AA16606; Fri, 9 May 1997 15:21:41 +0200
Received: from guanche by delmono.yp.delmono (4.1/SMI-4.1)
id AA16271; Fri, 9 May 97 15:19:17 +0200
Received: (from jtous at localhost) by guanche (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA03608; Fri, 9 May 1997 15:21:14 +0200
Date: Fri, 9 May 1997 15:21:14 +0200
Sender:ietf-request at ietf.org
From: Juan Tous Fajardo <jtous at guanche.tid.es>
Message-Id: <9705091521.ZM3607 at guanche>
In-Reply-To: Benking Heiner <BENKING at faw.uni-ulm.de>
"Re: 21N97" (May 8, 1:50pm)
References: <3372B117 at pc.faw.uni-ulm.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Benking Heiner <BENKING at faw.uni-ulm.de>, 2IN97 <2IN97 at prism.uvsq.fr>,
congres <congres at prism.uvsq.fr>
Subject: Re: 21N97
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Source-Info: From (or Sender) name not authenticated.
please, unsubscribe.
Received: from ietf.org by ietf.org id aa01855; 9 May 97 10:59 EDT
Received: from hiway1.exit109.com by ietf.org id aa01775; 9 May 97 10:57 EDT
Received: from ppp4-rb.exit109.com (ppp4-rb.exit109.com [205.164.176.131]) by hiway1.exit109.com (8.8.5/8.7.3) with SMTP id KAA09203; Fri, 9 May 1997 10:54:13 -0400 (EDT)
Received: by ppp4-rb.exit109.com with Microsoft Mail
id <01BC5C67.488083A0 at ppp4-rb.exit109.com>; Fri, 9 May 1997 10:53:52 -0400
Message-ID: <01BC5C67.488083A0 at ppp4-rb.exit109.com>
Sender:ietf-request at ietf.org
From: "Herman R. Silbiger" <hsilbiger at exit109.com>
To: "'Valdis.Kletnieks at vt.edu'" <Valdis.Kletnieks at vt.edu>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>,
"'lstsrv-l at peach.ease.lsoft.com'" <lstsrv-l at peach.ease.lsoft.com>
Subject: RE: AOL mail traffic
Date: Fri, 9 May 1997 00:21:35 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
I have a lot of sympathy for system operators trying to limit spamming. =
I don't understand where issues of "legitimacy" originate. I may be =
mistaken, but most of the internet operates on a cooperative basis, not =
a basis formed by contractual agreements. Therefore there are no =
agreements to break. =20
Postal and telephony traffic arrangements are on a contractual or treaty =
basis which usually makes it clear what legitimacy is. End users of the =
internet usually have some contractual arrangements with ISPs and ISPs =
with some backbone operators but mostly these are local arrangements. =
Perhaps the internet is now arriving at a stage where some legal =
structure is becoming necessary so that all participants know what their =
legitimate responsibilities are.
Herman Silbiger
---------
From: Valdis.Kletnieks at vt.edu[SMTP:Valdis.Kletnieks at vt.edu]
Sent: Thursday, May 08, 1997 2:48 PM
To: John C Klensin
Cc: ietf at ietf.org; lstsrv-l at peach.ease.lsoft.com; IBM TCP/IP List
Subject: Re: AOL mail traffic=20
<<File: ATT00017.att>>
On Thu, 08 May 1997 14:01:27 EDT, John C Klensin said:
> As the author of that text, there are three separate issues=20
> here; confusion among them is unfortunate:
Umm.. John? Actually, there's a few more issues than just 3.
> Q1: Is a site required to handle relay traffic that starts=20
> from arbitrary sources and is destined for arbitrary sinks?
>=20
> A: Nope. Sites can decline to accept mail for=20
> substantially any reason they feel like. If the=20
This is 2 issues. The question asked is the specific question of
whether you must act as a relay for 2 other parties when you wish
not to. I don't think anybody disagrees that AOL has the right to
refuse to act as a mail relay. I don't have a problem with AOL's
refusing to act as a relay for 2 3rd parties. I don't have a
problem with AOL refusing to accept any email from a list of
known spam sites (AOL has a list of such sites on the web at
http://www.idot.aol.com/preferredmail/). I don't have a
problem with AOL rejecting source routing from known spam
havens.
The second issue is what your answer actually addresses - do sites
have a *generic* right to reject arbitrary mail (not just relaying for
2 other sites, or other specific case), and if so, what grounds are
considered justifiable?
I *do* have a problem with their refusing to accept mail merely
because it had passed through a relay sometime before they received
it, on purely syntactic grounds that the RFC's mandate support of.
> Conversely, if I'm running host x.y.z, and I refuse to=20
> accept your traffic for relaying, I'm going to do so=20
> because I don't like you for some reason, and probably not=20
> because you have chosen one of those forms over the other.
Ahh.. but AOL is rejecting mail *PRECISELY* because sites have chosen
one form over another. That's the crux of the problem.
AOL set up Preferredmail as part of the CyberPromo lawsuit(s). Are
their users aware that some *OTHER* mail may be getting rejected as
well, with no warning and no option for the users? It sounds like the
users whos mail is being rejected would have even MORE grounds for a
lawsuit than CyberPromo did....
--=20
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
Received: from ietf.org by ietf.org id aa02972; 9 May 97 11:32 EDT
Received: from cnri by ietf.org id aa02848; 9 May 97 11:30 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa13945;
9 May 97 11:30 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA26675>; Fri, 9 May 1997 08:26:27 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA26964
; Fri, 9 May 1997 16:49:17 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id QAA16423
; Fri, 9 May 1997 16:44:04 +0200 (MET DST)
Received: from eamail1.unisys.com (eamail1.unisys.com [192.61.103.80])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA26143
; Fri, 9 May 1997 16:43:32 +0200 (METDST)
Received: from unislc.slc.unisys.com ([192.60.224.1]) by eamail1.unisys.com (8.8.5/8.6.12) with SMTP id OAA28847; Fri, 9 May 1997 14:43:00 GMT
Received: from slc-exchange-1 by unislc.slc.unisys.com (5.61/1.35)
id AA29936; Fri, 9 May 97 08:41:16 -0600
Received: by slc-exchange-1.slc.unisys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <01BC5C54.580EBB60 at slc-exchange-1.slc.unisys.com>; Fri, 9 May 1997 08:38:18 -0600
Message-Id: <c=US%a=ATTMAIL%p=UNISYS%l=SLC-EXCHANGE-970509143815Z-19617 at slc-exchange-1.slc.unisys.com>
Sender:ietf-request at ietf.org
From: "Deyo, Mary" <Mary.Deyo at unisys.com>
To: "'2IN97 at prism.uvsq.fr'" <2IN97 at prism.uvsq.fr>,
"'congres at prism.uvsq.fr'" <congres at prism.uvsq.fr>,
"'BENKING at faw.uni-ulm.de'" <BENKING at faw.uni-ulm.de>
Subject: Remove from mailing lists
Date: Fri, 9 May 1997 08:38:15 -0600
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.
What lists are these??!! Never heard of them!
Please remove me from these lists.
Mary Deyo
Received: from ietf.org by ietf.org id aa03218; 9 May 97 11:35 EDT
Received: from cnri by ietf.org id aa03072; 9 May 97 11:34 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14068;
9 May 97 11:34 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA26810>; Fri, 9 May 1997 08:30:18 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id RAA00547
; Fri, 9 May 1997 17:27:11 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id RAA17848
; Fri, 9 May 1997 17:21:15 +0200 (MET DST)
Received: from lego.metainfo.com (lego.metainfo.com [204.29.28.6])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id RAA29567
; Fri, 9 May 1997 17:21:11 +0200 (METDST)
Received: by lego.metainfo.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52)
id <01BC5C51.B41654C0 at lego.metainfo.com>; Fri, 9 May 1997 08:19:24 -0700
Message-Id: <c=US%a=_%p=MetaInfo%l=LEGO-970509151922Z-1532 at lego.metainfo.com>
Sender:ietf-request at ietf.org
From: Kevin Dunlap <KevinD at metainfo.com>
To: "'2IN97 at prism.uvsq.fr'" <2IN97 at prism.uvsq.fr>,
"'congres at prism.uvsq.fr'" <congres at prism.uvsq.fr>,
"'BENKING at faw.uni-ulm.de'" <BENKING at faw.uni-ulm.de>
Subject: RE: REMOVE
Date: Fri, 9 May 1997 08:19:22 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
Encoding: 13 TEXT
Source-Info: From (or Sender) name not authenticated.
Remove the IETF mailing list from these other mailing lists.
-Kevin
>-----Original Message-----
>From: Hans-Werner Gellersen [SMTP:hwg at teco.uni-karlsruhe.de]
>Sent: Friday, May 09, 1997 4:48 AM
>To: 2IN97 at prism.uvsq.fr; congres at prism.uvsq.fr; BENKING at faw.uni-ulm.de
>Subject: Re: REMOVE
>
>Please remove me from the mailing-list NOW.
>I never asked to get into it.
Received: from ietf.org by ietf.org id aa04589; 9 May 97 12:13 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa04474; 9 May 97 12:10 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 MAA22646;
Fri, 9 May 1997 12:07:05 -0400
Message-Id: <199705091607.MAA22646 at black-ice.cc.vt.edu>
To: Dorgham Sisalem <sisalem at fokus.gmd.de>
Cc: 2IN97 <2IN97 at prism.uvsq.fr>, postmaster at prism.uvsq.fr, ietf at ietf.org
Subject: Re: 21N97
In-Reply-To: Your message of "Fri, 09 May 1997 14:30:14 +0200."
<199705091230.OAA05441 at donald.fokus.gmd.de >
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199705091230.OAA05441 at donald.fokus.gmd.de >
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1811606352P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 09 May 1997 12:07:05 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1811606352P
Content-Type: text/plain; charset=us-ascii
On Fri, 09 May 1997 14:30:14 +0200, Dorgham Sisalem said:
> would the responsible for this list arrange for a seperate way to
> delete > the peopole from this list. I do not really want to receive
> all the delete me > messages and surely not the "I concur" ones
> in reply. I do not know who is responsible for this mess but who
> ever it is please fix it quickly. I already received more than 15
> mails today from this list on which I DID NOT ASK TO GET ON. So
> > > remove me as well > > Dorgham >
Argh. Yet Another Bozo added ietf at ietf.org to the 2IN97 mailing list.
1) If you're creating a mailing list, don't add other lists to it without
asking for permission first.
2) Replying to the list to be taken off is usually a waste of time -
try 'listname-request' or 'postmaster' first.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_1811606352P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM3NLp9QBOOoptg9JAQFC8gQAxskOKjaO/ib5tpcJ6xC1KDG/+WRsFFwW
dtC4xBq5wwblyvqpP26c3X+a2z4X2rZyJJOoWj81z5P7xDgUYk92eaJ5XOxu+guw
dtqvi012UYUtEcV0qvj2CkHvuhAgrei9d6NWxW1BuUUlkodOys4766f0DsSfcbQv
YKrwTG2Ekl4=
=FTIr
-----END PGP MESSAGE-----
--==_Exmh_1811606352P--
Received: from ietf.org by ietf.org id aa04944; 9 May 97 12:19 EDT
Received: from cnri by ietf.org id aa04808; 9 May 97 12:17 EDT
Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa15057;
9 May 97 12:17 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id SAA05285
; Fri, 9 May 1997 18:03:54 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id RAA18181
; Fri, 9 May 1997 17:27:57 +0200 (MET DST)
Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id RAA00650
; Fri, 9 May 1997 17:27:43 +0200 (METDST)
Received: (from geihs at localhost) by diamant.vsb.informatik.uni-frankfurt.de (AIX4.2/UCB 8.7/8.7) id QAA24798; Fri, 9 May 1997 16:58:28 +0200 (CST)
Sender:ietf-request at ietf.org
From: Kurt Geihs <geihs at vsb.informatik.uni-frankfurt.de>
Message-Id: <199705091458.QAA24798 at diamant.vsb.informatik.uni-frankfurt.de>
Subject: REMOVE
To: geihs at vsb.informatik.uni-frankfurt.de
Date: Fri, 9 May 1997 16:58:27 +0200 (CST)
Cc: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
In-Reply-To: <199705091225.OAA14092 at resu1.ulb.ac.be> from "Guy Latouche" at May 9, 97 02:26:07 pm
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
REMOVE ME FROM LIST
Received: from ietf.org by ietf.org id aa05720; 9 May 97 12:38 EDT
Received: from cnri by ietf.org id aa05598; 9 May 97 12:35 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15439;
9 May 97 12:35 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA00677>; Fri, 9 May 1997 09:32:00 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id SAA07812
; Fri, 9 May 1997 18:26:38 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA20365
; Fri, 9 May 1997 18:21:14 +0200 (MET DST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id SAA07022
; Fri, 9 May 1997 18:21:07 +0200 (METDST)
Received: from W20-575-37.MIT.EDU by MIT.EDU with SMTP
id AA06078; Fri, 9 May 97 12:21:05 EDT
Received: by w20-575-37.MIT.EDU (5.x/4.7) id AA27880; Fri, 9 May 1997 12:20:50 -0400
Message-Id: <9705091620.AA27880 at w20-575-37.MIT.EDU>
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: REMOVE
Date: Fri, 09 May 1997 12:20:49 EDT
Sender:ietf-request at ietf.org
From: Shiva Sean Sandy <sssandy at mit.edu>
Source-Info: From (or Sender) name not authenticated.
please remove me form this list
thank you
Received: from ietf.org by ietf.org id aa06506; 9 May 97 12:57 EDT
Received: from chrome.office.aol.com by ietf.org id aa06391; 9 May 97 12:55 EDT
Received: from localhost (brad at localhost)
by chrome.office.aol.com (8.8.6.Beta1/8.8.5/AOL-0.0.7)
with ESMTP id MAA26336;
Fri, 9 May 1997 12:50:17 -0400 (EDT)
Message-Id: <199705091650.MAA26336 at chrome.office.aol.com>
X-Mailer: exmh version 2.0gamma 1/27/96
Reply-To: KnowlesB at aol.net
Organization: America Online, Inc.
X-Telefacsimile: (703) 453-4013
X-PGP-Fingerprint: DA 2A 59 B1 A8 BD 4C B2 B0 41 CE 6E BD C3 15 54
X-Face: "HJz{ at e(gkOmJfq8b$n:zW8Kk4*`Sz1?<#`g=5p>Wuu7DkDV`m-*p[Yb=?;w(F:L'DHA{mO]=iKKKdH)r%I7K;dvYQ{3Y6"3MW at Y*U_6?>lOw;GIva\?7579Ii|/$t"\+lE<jGAh3bKjl
To: Eric Thomas <ERIC at vm.se.lsoft.com>
cc: "C. Harald Koch" <chk at utcc.utoronto.ca>,
John C Klensin <klensin at mci.net>, Valdis.Kletnieks at vt.edu,
PDMAtropos at aol.com, Karl Mulder <KMULDER at vm.nmu.edu>, ietf at ietf.org
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Fri, 09 May 1997 01:12:02 +0200."
<199705090002.UAA24171 at postman.ops.aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 May 1997 12:50:15 -0400
Sender:ietf-request at ietf.org
From: Brad Knowles <BKnowles at aol.net>
Source-Info: From (or Sender) name not authenticated.
Your message dated: Fri, 09 May 1997 01:12:02 +0200
> Brad has yet to give a TECHNICAL explanation which does not take the form
> of "Doing otherwise would threaten the very existence of AOL for reasons
> that I won't tell you, and anyway the DRUMS group agrees with me and
> RFC1123 says you shouldn't put source routes in MAIL FROM:, and you are
> violating this standard (me too, but that's besides the point)".
I see that I made a major mistaken in attempting to address
this issue in this sort of a public forum. I will not repeat
that mistake.
The next time any issue comes up, I will address it in a manner
that makes it absolutely clear that this is a statement of FACT
regarding how the AOL mail system works, and there simply are no
technical issues to be discussed.
--
Brad Knowles MIME/PGP: KnowlesB at aol.net
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
Received: from ietf.org by ietf.org id aa06929; 9 May 97 13:07 EDT
Received: from cnri by ietf.org id aa06783; 9 May 97 13:06 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa16065;
9 May 97 13:05 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA02057>; Fri, 9 May 1997 10:02:16 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id SAA11466
; Fri, 9 May 1997 18:59:35 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA20751
for <congres at prism.uvsq.fr>; Fri, 9 May 1997 18:28:48 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: adam at research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id SAA08081
for <congres at prism.uvsq.fr>; Fri, 9 May 1997 18:28:16 +0200 (METDST)
Message-Id: <199705091628.SAA08081 at shiva.jussieu.fr>
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri May 9 12:07:59 EDT 1997
Received: from rice ([135.104.10.2]) by research; Fri May 9 12:08:01 EDT 1997
Date: Fri, 9 May 97 12:07 EDT
To: 2IN97 at prism.uvsq.fr, BENKING at faw.uni-ulm.de, congres at prism.uvsq.fr
Source-Info: From (or Sender) name not authenticated.
Subject: REMOVE
REMOVE
ASAP!
Received: from ietf.org by ietf.org id aa07788; 9 May 97 13:38 EDT
Received: from cnri by ietf.org id aa07656; 9 May 97 13:36 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa16802;
9 May 97 13:36 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA03417>; Fri, 9 May 1997 10:32:27 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id TAA14384
; Fri, 9 May 1997 19:29:25 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id TAA22708
; Fri, 9 May 1997 19:04:50 +0200 (MET DST)
Received: from othello.admin.kth.se ([130.237.32.10])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id TAA12068
; Fri, 9 May 1997 19:04:48 +0200 (METDST)
Received: from localhost (localhost.admin.kth.se [127.0.0.1])
by othello.admin.kth.se (8.8.5/8.8.5) with SMTP
id TAA28462;
Fri, 9 May 1997 19:04:13 +0200 (MET DST)
Date: Fri, 9 May 1997 19:04:12 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Christer Palm <palm at admin.kth.se>
Reply-To: Christer Palm <palm at admin.kth.se>
To: 2IN97 <2IN97 at prism.uvsq.fr>, congres <congres at prism.uvsq.fr>
Subject: REMOVE ME NOW
Message-Id: <Pine.SUN.3.96.970509190242.28325A-100000 at othello.admin.kth.se>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Please remove me from the mailing-list. NOW! I never asked to get into it.
--
Christer Palm E-mail: palm at admin.kth.se
Network Manager
Technical Services Telephone: +46-8-7907234
Royal Institute of Technology Mobilephone: 070-5121738
S-100 44 Stockholm (Sweden) Fax: +46-8-102510
Received: from ietf.org by ietf.org id aa08103; 9 May 97 13:46 EDT
Received: from cnri by ietf.org id aa07969; 9 May 97 13:44 EDT
Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa17036;
9 May 97 13:44 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id TAA15219
; Fri, 9 May 1997 19:35:37 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA21699
; Fri, 9 May 1997 18:52:11 +0200 (MET DST)
Received: from msexch1.mc.utk.edu (utmck.edu [165.6.132.21])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id SAA10532
; Fri, 9 May 1997 18:52:07 +0200 (METDST)
Received: by msexch1.mc.utk.edu with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <01BC5C76.348B1E00 at msexch1.mc.utk.edu>; Fri, 9 May 1997 12:40:41 -0400
Message-ID: <c=US%a=_%p=UTMCK%l=UTMCK_NT_HEN-970509164040Z-13939 at msexch1.mc.utk.edu>
Sender:ietf-request at ietf.org
From: "Schaffer, Gregory J." <GSchaffe at mc.utk.edu>
To: 'Svenn Hanssen' <Svenn.Agnar.Hanssen at cc.uit.no>,
'Dorgham Sisalem' <sisalem at fokus.gmd.de>
Cc: 'Joerg Mueller' <jpm at zuno.com>,
'Benking Heiner' <BENKING at faw.uni-ulm.de>, '2IN97' <2IN97 at prism.uvsq.fr>,
'congres' <congres at prism.uvsq.fr>, "'svenn at cc.uit.no'" <svenn at cc.uit.no>
Subject: RE: 21N97
Date: Fri, 9 May 1997 12:40:40 -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 second the notion...what is this list about anyway?
>----------
>From: Dorgham Sisalem[SMTP:sisalem at fokus.gmd.de]
>Sent: Friday, May 09, 1997 8:30 AM
>To: Svenn Hanssen
>Cc: Joerg Mueller; 'Benking Heiner'; 2IN97; congres; svenn at cc.uit.no
>Subject: Re: 21N97
>
>would the responsible for this list arrange for a seperate way to delete
>the peopole from this list. I do not really want to receive all the delete me
>messages and surely not the "I concur" ones in reply. I do not know who is
>responsible for this mess but who ever it is please fix it quickly. I already
>received more than 15 mails today from this list on which I DID NOT ASK TO
>GET ON. So
>
>remove me as well
>
> Dorgham
>
Received: from ietf.org by ietf.org id aa08345; 9 May 97 13:49 EDT
Received: from cnri by ietf.org id aa08180; 9 May 97 13:47 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17092;
9 May 97 13:47 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA04058>; Fri, 9 May 1997 10:44:15 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id TAA16000
; Fri, 9 May 1997 19:40:37 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id TAA22724
; Fri, 9 May 1997 19:05:17 +0200 (MET DST)
Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com [131.107.3.41])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id TAA12111
; Fri, 9 May 1997 19:05:14 +0200 (METDST)
Received: by mail1.microsoft.com with Internet Mail Service (5.0.1458.30)
id <KSCNNLS8>; Fri, 9 May 1997 10:05:13 -0700
Message-Id: <1B2056104081CF11914400805F68CC1704123C25 at RED-05-MSG.dns.microsoft.com>
Sender:ietf-request at ietf.org
From: Karoly Somogyvari <karolys at microsoft.com>
To: "'2IN97 at prism.uvsq.fr'" <2IN97 at prism.uvsq.fr>,
"'congres at prism.uvsq.fr'" <congres at prism.uvsq.fr>,
"'BENKING at faw.uni-ulm.de'" <BENKING at faw.uni-ulm.de>
Subject: RE: REMOVE
Date: Fri, 9 May 1997 10:04:26 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Source-Info: From (or Sender) name not authenticated.
My impression is that someone has played a little game with these
mailing lists last night. (I never wanted to be on these lists either.)
I think the owners of the lists should remove everybody from the list
who has been added during the last day.
> -----Original Message-----
> From: Kevin Dunlap [SMTP:KevinD at metainfo.com]
> Sent: Friday, May 09, 1997 8:19 AM
> To: '2IN97 at prism.uvsq.fr'; 'congres at prism.uvsq.fr';
> 'BENKING at faw.uni-ulm.de'
> Subject: RE: REMOVE
>
> Remove the IETF mailing list from these other mailing lists.
>
> -Kevin
>
>
> >-----Original Message-----
> >From: Hans-Werner Gellersen [SMTP:hwg at teco.uni-karlsruhe.de]
> >Sent: Friday, May 09, 1997 4:48 AM
> >To: 2IN97 at prism.uvsq.fr; congres at prism.uvsq.fr;
> BENKING at faw.uni-ulm.de
> >Subject: Re: REMOVE
> >
> >Please remove me from the mailing-list NOW.
> >I never asked to get into it.
Received: from ietf.org by ietf.org id aa08665; 9 May 97 13:57 EDT
Received: from cnri by ietf.org id aa08531; 9 May 97 13:56 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17274;
9 May 97 13:56 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA04613>; Fri, 9 May 1997 10:52:36 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id TAA17172
; Fri, 9 May 1997 19:49:46 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA20589
for <congres at prism.uvsq.FR>; Fri, 9 May 1997 18:25:58 +0200 (MET DST)
Received: from QUCDN.QueensU.CA (QUCDN.QueensU.CA [130.15.126.2])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id SAA07684
for <congres at prism.uvsq.FR>; Fri, 9 May 1997 18:25:48 +0200 (METDST)
Received: from qucdnee.ee.QueensU.CA by QUCDN.QueensU.CA (IBM VM SMTP V2R2)
with TCP; Fri, 09 May 97 12:25:07 EDT
Received: from qucdnee.ee.QueensU.CA by qucdnee.ee.QueensU.CA (PMDF V4.2-15
#3234) id <01IINZ3U9NMU9FM72C at qucdnee.ee.QueensU.CA>; Fri,
9 May 1997 12:25:34 EST
Date: Fri, 09 May 1997 12:25:34 -0500 (EST)
Sender:ietf-request at ietf.org
From: PRCHOP at qucdnee.ee.queensu.ca
Subject: REMOVE
To: congres at prism.uvsq.fr
Message-Id: <01IINZ3U9NMW9FM72C at qucdnee.ee.QueensU.CA>
X-Envelope-To: congres at prism.uvsq.FR
X-Vms-To: IN%"congres at prism.uvsq.FR"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Source-Info: From (or Sender) name not authenticated.
Please remove me from your mailing list.
Received: from ietf.org by ietf.org id aa09024; 9 May 97 14:05 EDT
Received: from cnri by ietf.org id aa08894; 9 May 97 14:03 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17480;
9 May 97 14:02 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA04905>; Fri, 9 May 1997 10:58:57 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id TAA18213
; Fri, 9 May 1997 19:56:40 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA20688
for <congres at prism.uvsq.fr>; Fri, 9 May 1997 18:27:42 +0200 (MET DST)
Received: from kechara.flame.org (kechara.flame.org [192.80.44.209])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id SAA07908
for <congres at prism.uvsq.fr>; Fri, 9 May 1997 18:27:13 +0200 (METDST)
Received: (qmail 8705 invoked by uid 173); 9 May 1997 16:26:58 -0000
X-Orig-Sender: explorer at kechara.flame.org
To: Joerg Mueller <jpm at zuno.com>
Cc: 'Benking Heiner' <BENKING at faw.uni-ulm.de>, 2IN97 <2IN97 at prism.uvsq.fr>,
congres <congres at prism.uvsq.fr>, postmaster at prism.uvsq.fr
Subject: Re: 21N97
References: <01BC5C6D.59268AA0 at indus.dlib.com>
Sender:ietf-request at ietf.org
From: Michael Graff <explorer at flame.org>
Date: 09 May 1997 12:26:58 -0400
In-Reply-To: Joerg Mueller's message of Fri, 9 May 1997 11:37:16 +0100
Message-Id: <v6g1vwboh9.fsf at kechara.flame.org>
Lines: 15
X-Mailer: Gnus v5.4.37/Emacs 19.34
Source-Info: From (or Sender) name not authenticated.
Joerg Mueller <jpm at zuno.com> writes:
> whoever is responsible for this list, PLEASE remove me from it.
> I am not interested at all in receiving that crap.
It appears someone is an idiot and added tcplw at bsdi.com to some other
list.
This was in the header:
Return-Path: <tcplw-relay at external.BSDI.COM>
Someone fix this, please!
--Michael
Received: from ietf.org by ietf.org id aa09407; 9 May 97 14:11 EDT
Received: from cnri by ietf.org id aa09142; 9 May 97 14:09 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17680;
9 May 97 14:09 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA05320>; Fri, 9 May 1997 11:05:48 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id UAA18944
; Fri, 9 May 1997 20:01:53 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA21490
; Fri, 9 May 1997 18:49:49 +0200 (MET DST)
Received: from hip7.bellcore.com (hip7.bellcore.com [192.4.6.68])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id SAA10148
; Fri, 9 May 1997 18:49:21 +0200 (METDST)
Received: (from debbie at localhost) by hip7.bellcore.com (8.6.9/8.6.10) id LAA20790; Fri, 9 May 1997 11:49:49 -0400
Date: Fri, 9 May 1997 11:49:49 -0400
Sender:ietf-request at ietf.org
From: Deborah G Schmitt <debbie at bellcore.com>
Message-Id: <199705091549.LAA20790 at hip7.bellcore.com>
To: 2IN97 at prism.uvsq.fr, BENKING at faw.uni-ulm.de, bjorn at it.kth.se,
congres at prism.uvsq.fr
Subject: Re: remove please!
Source-Info: From (or Sender) name not authenticated.
Please remove me as well..
Received: from ietf.org by ietf.org id aa09451; 9 May 97 14:11 EDT
Received: from cnri by ietf.org id aa09248; 9 May 97 14:10 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17705;
9 May 97 14:10 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA05349>; Fri, 9 May 1997 11:06:40 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id UAA19395
; Fri, 9 May 1997 20:04:48 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA21714
; Fri, 9 May 1997 18:52:19 +0200 (MET DST)
Received: from sgi.sgi.com (SGI.COM [192.48.153.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id SAA10539
; Fri, 9 May 1997 18:52:12 +0200 (METDST)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id JAA10902; Fri, 9 May 1997 09:47:38 -0700
env-from (lguo at cube.engr.sgi.com)
Received: from cube.engr.sgi.com (cube.engr.sgi.com [150.166.76.49]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA26290; Fri, 9 May 1997 09:47:36 -0700
Received: (from lguo at localhost) by cube.engr.sgi.com (970321.SGI.8.8.5/960327.SGI.AUTOCF) id JAA03543; Fri, 9 May 1997 09:47:35 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Lisa Guo <lguo at cube.engr.sgi.com>
Message-Id: <9705090947.ZM3728 at cube.engr.sgi.com>
Date: Fri, 9 May 1997 09:47:34 -0700
In-Reply-To: Joerg Mueller <jpm at zuno.com>
"RE: 21N97" (May 9, 11:37am)
References: <01BC5C6D.59268AA0 at indus.dlib.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: 'Benking Heiner' <BENKING at faw.uni-ulm.de>, 2IN97 <2IN97 at prism.uvsq.fr>,
congres <congres at prism.uvsq.fr>
Subject: Re: 21N97
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Please remove me from the list.
Lisa
Received: from ietf.org by ietf.org id aa09928; 9 May 97 14:23 EDT
Received: from cnri by ietf.org id aa09790; 9 May 97 14:21 EDT
Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa18038;
9 May 97 14:21 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id UAA20963
; Fri, 9 May 1997 20:15:37 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA20829
; Fri, 9 May 1997 18:29:54 +0200 (MET DST)
Received: from europe.std.com (europe.std.com [199.172.62.20])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id SAA08336
; Fri, 9 May 1997 18:29:44 +0200 (METDST)
Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0)
id MAA18786; Fri, 9 May 1997 12:29:29 -0400 (EDT)
Received: from localhost by world.std.com (5.65c/Spike-2.0)
id AA21134; Fri, 9 May 1997 12:29:29 -0400
Date: Fri, 9 May 1997 12:29:29 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Robert E Lamm <cync at world.std.com>
To: Dorgham Sisalem <sisalem at fokus.gmd.de>
Cc: Svenn Hanssen <Svenn.Agnar.Hanssen at cc.uit.no>,
Joerg Mueller <jpm at zuno.com>, 'Benking Heiner' <BENKING at faw.uni-ulm.de>,
2IN97 <2IN97 at prism.uvsq.fr>, congres <congres at prism.uvsq.fr>,
svenn at cc.uit.no
Subject: Re: 21N97
In-Reply-To: <199705091230.OAA05441 at donald.fokus.gmd.de >
Message-Id: <Pine.SGI.3.95.970509122903.16687E-100000 at world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
What is this list about?
-Bob Lamm
CYNC Corp.
Brookline, MA USA
On Fri, 9 May 1997, Dorgham Sisalem wrote:
> would the responsible for this list arrange for a seperate way to delete
> the peopole from this list. I do not really want to receive all the delete me
> messages and surely not the "I concur" ones in reply. I do not know who is responsible for this mess but who ever it is please fix it quickly. I already received more than 15 mails today from this list on which I DID NOT ASK TO GET ON. So
>
> remove me as well
>
> Dorgham
>
Received: from ietf.org by ietf.org id aa10202; 9 May 97 14:29 EDT
Received: from cnri by ietf.org id aa10055; 9 May 97 14:28 EDT
Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa18160;
9 May 97 14:28 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id UAA21724
; Fri, 9 May 1997 20:21:02 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA20723
; Fri, 9 May 1997 18:28:23 +0200 (MET DST)
Received: from relay.dot.gov (relay.dot.gov [152.120.130.100])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id SAA08029
; Fri, 9 May 1997 18:27:56 +0200 (METDST)
Received: from mail2.hq.faa.gov (mail2.hq.faa.gov [152.123.190.6])
by relay.dot.gov (8.8.4/8.8.4) with SMTP
id LAA11737; Fri, 9 May 1997 11:16:12 -0400 (EDT)
Received: from ccMail by mail2.hq.faa.gov (ccMail Link to SMTP R6.00.01)
id AA863187225; Fri, 09 May 97 11:19:12 -0500
Message-Id: <9705098631.AA863187225 at mail2.hq.faa.gov>
X-Mailer: ccMail Link to SMTP R6.00.01
Date: Fri, 09 May 97 10:06:39 -0500
Sender:ietf-request at ietf.org
From: Alan Hayes <alan_hayes_at_ait at mail2.hq.faa.gov>
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: (oiw-dsm 13) Re: 21N97
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Please remove me from your mailing lists.
Thank you.
______________________________ Reply Separator _________________________________
Subject: (oiw-dsm 13) Re: 21N97
Author: Benking Heiner <BENKING at faw.uni-ulm.de> at smtpgate
Date: 5/8/97 1:50 PM
----------
> Von: 2IN97
> An: congres
> Betreff: 21N97
> Datum: Mittwoch, 5. M{rz 1997 12:48
>
> I have just received part of a message about a call for papers but the
> important part is missing. Would you send the message again, please?
>
> Regards,
>
> Niall O'Loughlin
>
>
empty rooms in mental flats - looking for locomotion?
in the last line you find some sources and orientation for this message
maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group
list !??
Heiner BENKING
re: SHARING MENTAL HOMES - a QUEST for more MENTAL MOBILITY
here an up-date and maybe a starter in form of a message just needed to send
somewhere
Heiner Benking
_-_
Dear list members,
I try to bridge two lists, as the topics are too close
and it gets boring always getting a grip or grasp and then letting go..
Heiner
> ----------
> Von: owner-debono
> An: DEBONO
> Betreff: Creativity and Rods & Cones
> Datum: Mittwoch, 7. Mai 1997 11:48
>
> In a message dated 97-05-06 11:01:15 EDT, you write:
>
> << ... Have you ever noticed how night vision works. Part of your mind
picks
> up clear images on the periphery of your line of sight, but when you shift
> your focus to where the image was, it loses its definition. I think
> creativity works a little like this: it occurs on the edge of our line of
> sight. If we're not too focussed on what we're looking at, we notice the
> creative image and try to bring it into focus, but if we persist in
peering
> straight ahead, we fail to notice that we even "saw" something "off to the
> side"... I apologize if this musing is self-indulgent and thank you for
the
> provocation. >>
>
> Metaphors are the furnishings of our mental home. Thank you for making a
> very insightful addition to my decor, although I can really only see this
> item peripherally, I guess.
>
> Adam Hansen
> The Generativity Group
----------
> Von: list
> An: unis
> Cc: ThomasM451
> Betreff: Re: simple language & Korea
> Datum: Mittwoch, 7. Mai 1997 23:30
>
> In a message dated 97-05-07 16:17:07 EDT, you write:
>
> <<
> In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
>
> << I admitted up front that I knew nothing about Korea, except that they
> are about to go to war again. What I am asking is not for "ideal"
> situations, but fundamental situations. (this is the second time simple
language has
> been mistaken for idealistic language, interesting) The foundation for
my
> "fantasy" is simply the principle of a loving relationship - mutual
synergy.
>
>
> Hello:
> If the language of form requires us to frame a discussion through a
> particular lense, then we would need to agree to the form/lense up-front.
We
> would also be able to predict all the unconscious variables that would
> surely 'come up' into our field of awareness, as a result of framing such
a
> discussion..........and without saying much more its clear to me why many
> theorists state there is no such thing as com-unication, let alone
'simple
> language'!
>
> My admittedlly incomplete appreciation of Stytematics has me feeling like
we
> are in all the forms at once. .....
_____________________________________________
BEGIN OF MESSAGE:
Hi,
Well I think our mental homes are 'not in order'. We try with precision,
forcing focus on the specifics, but camouflage the whole' as Steve Kurtz once
wrote, but not daring to look for the context, the relations and connections.
As Kant was looking with his carcateristica universalis, i call it an
'organizing glass' into the inner structure (remember Alice in WONDERLAND) we
can at least build a conceptual house of knowledge, beyond languages, if we
restrict ourselves !! to the general overview, the birds eye.
The result is that we can suddenly see and get awe as we grasp how little we
know !! See wholeness and worldview discussion and the recent work on:
Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).
I think this focussing on words, as some lists do, can work in coherent
groups, but the moment you jump over the fence, you are lost, as the
NOMINALISTS, go for 'exact words' their code, in a hierarchical order,
knowledge trees. My position is absolutely to the contrary, I am a
CONCEPTUALIST, looking for 'concepts in their context' and try to move,
merge and transform along and across scales.
We have, if we ever want to bridge 'schools' and mental territories have to
see the deeper connections. The mind's eye pondering above shows the way!
I would like to show that Einstein was pondering also about words:
The word or the language, written or spoken,
do not seem to have any impact (role)
in the mechanism of my line of thought.
The mental building blocks of thinking
are certain signs/symbols and more or less clear pictures,
which can be reproduced and combined at will (according desire/wish?)
Albert Einstein
maybe someone can help with the best words !?? as I only have a German
version:
Das Wort oder die Sprache, geschrieben oder gesprochen,
scheinen im Mechanismus meines Gedankenablaufes
}berhaupt keine Rolle zu spielen.
Die psychischen Grundelemente des Denkens
sind bestimmte Zeichen und mehr oder weniger klare Bilder,
die nach Wunsch reproduziert und kombiniert werden k|nnen.
Albert Einstein
I would like to sum up by saying that I profit most by learning the style
and the class of the different lists, my English is not good enough to
discuss with any one of you 'seriously' (I appreciate the braod wandwith
personal aprach anyway!)
but I can tell you that we are all very close, but are typically not aware
of it, all living in our private MENTAL HOMES, in cocoons, and ponder about
details...
As I like to share and feel that I live in some mental homes in parallel (my
cognitive panorama) you are most welcome to visit and move in...
warmely
Heiner
http://www.uia.org/uiadocs/spatialm.htm
http://www.newciv.org/ISSS_Primer/seminrva.html
http://heri.cicv.fr/council/speeches/benkingtxt.html
http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm
--
This list is managed by IDI, Inc. Requests should be sent to
oiw-dsm-request at oiw.org.
--
Received: from ietf.org by ietf.org id aa12530; 9 May 97 15:43 EDT
Received: from snat33.genesyslab.com by ietf.org id aa12440; 9 May 97 15:39 EDT
Received: (from egoshin at localhost) by leonid.genesyslab.com (8.7.5/8.7.3) id MAA01137; Fri, 9 May 1997 12:35:07 -0700
Date: Fri, 9 May 1997 12:35:07 -0700
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199705091935.MAA01137 at leonid.genesyslab.com>
To: klensin at mci.net
Subject: Re: AOL mail traffic
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: John C Klensin <klensin at mci.net>
>On Thu, 08 May 1997 16:16:24 -0700 Leonid Yegoshin
><egoshin at genesyslab.com> wrote:
>
>> >From: Brad Knowles <BKnowles at aol.net>
>> >...
>> > Lose your love affair with that part of RFC 1123, because it
>> >*is* going away, sooner or later. Maybe not with whatever will
>> >become of draft-ietf-drums-smtpupd-04.txt, but sooner or later it
>> >*will* go away.
>> >
>> If this draft would be incompatible with SMTP (all RFCs set) and practice,
>> please request and use ANOTHER TCP port for this service. Period.
>
>Please don't criticize --at least on the IETF list-- what
>your obviously haven't read. The difference between the
>
Excuse me, John, but I tryed to take in attention that any incompatible
changes in protocols can disturb existed services. And this draft is referenced
as a base for such changes. (Yes, I real read this draft by "diagonal", sorry)
As for me I satisfyed your words:
>older one. Neither document requires that sites bounce
>mail whose envelope contains source routes -- we try to
Up to day source route in MAIL FROM: is used to delivery transport errors
to non-Internet mail systems or to closed and _large_ networks with complex
internal structure. If somebody try to remove this option from SMTP
then he can setup new paradigma about mail transfering and this paradigma
can influence DNS use in mail addressing.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa12714; 9 May 97 15:48 EDT
Received: from wentzl.cdg.chalmers.se by ietf.org id aa12655; 9 May 97 15:46 EDT
Received: (from lindberg at localhost)
by wentzl.cdg.chalmers.se (8.8.5/8.8.5) id VAA07627;
Fri, 9 May 1997 21:42:50 +0200 (MET DST)
Date: Fri, 9 May 1997 21:42:50 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Gunnar Lindberg <lindberg at cdg.chalmers.se>
Message-Id: <199705091942.VAA07627 at wentzl.cdg.chalmers.se>
To: Postmaster at faw.uni-ulm.de, Postmaster at prism.uvsq.fr
Subject: Fwd:/Re: Remove from mailing lists
Cc: ietf at ietf.org
X-Mailer: UCB Mail 5.3.8 96-10-07 (MIME)
Source-Info: From (or Sender) name not authenticated.
(IETF, sorry to include you again, but this should only be once).
Postmasters!!!
It seems like at least one of these lists include the IETF list:
BENKING at faw.uni-ulm.de
2IN97 at prism.uvsq.fr
congres at prism.uvsq.fr
It also seems like that list has included a lot of people who didn't
ask for it and that there is little knowledge of how to unsubscribe.
The IETF list now receives copies of their "please remove me" messages.
1) Please stop including the IETF list.
2) Please post "unsubscribe" instructions to the other lists.
Many thanks in advance,
Gunnar Lindberg
>From ietf-request at ietf.org Fri May 9 20:59:29 1997
>Return-Path: <ietf-request at ietf.org>
>Received: from ietf.org (ietf.org [132.151.1.19])
> by wentzl.cdg.chalmers.se (8.8.5/8.8.5) with SMTP id UAA06454;
> Fri, 9 May 1997 20:59:10 +0200 (MET DST)
>Received: from ietf.org by ietf.org id aa03097; 9 May 97 11:34 EDT
>Received: from cnri by ietf.org id aa03005; 9 May 97 11:32 EDT
>Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa14038;
> 9 May 97 11:32 EDT
>Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
> by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA26964
> ; Fri, 9 May 1997 16:49:17 +0200 (METDST)
>Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
> by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id QAA16423
> ; Fri, 9 May 1997 16:44:04 +0200 (MET DST)
>Received: from eamail1.unisys.com (eamail1.unisys.com [192.61.103.80])
> by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA26143
> ; Fri, 9 May 1997 16:43:32 +0200 (METDST)
>Received: from unislc.slc.unisys.com ([192.60.224.1]) by eamail1.unisys.com (8.8.5/8.6.12) with SMTP id OAA28847; Fri, 9 May 1997 14:43:00 GMT
>Received: from slc-exchange-1 by unislc.slc.unisys.com (5.61/1.35)
> id AA29936; Fri, 9 May 97 08:41:16 -0600
>Received: by slc-exchange-1.slc.unisys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
> id <01BC5C54.580EBB60 at slc-exchange-1.slc.unisys.com>; Fri, 9 May 1997 08:38:18 -0600
>Message-Id: <c=US%a=ATTMAIL%p=UNISYS%l=SLC-EXCHANGE-970509143815Z-19617 at slc-exchange-1.slc.unisys.com>
>Sender: ietf-request at ietf.org
>From: "Deyo, Mary" <Mary.Deyo at unisys.com>
>To: "'2IN97 at prism.uvsq.fr'" <2IN97 at prism.uvsq.fr>,
> "'congres at prism.uvsq.fr'" <congres at prism.uvsq.fr>,
> "'BENKING at faw.uni-ulm.de'" <BENKING at faw.uni-ulm.de>
>Subject: Remove from mailing lists
>Date: Fri, 9 May 1997 08:38:15 -0600
>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.
>What lists are these??!! Never heard of them!
>Please remove me from these lists.
>Mary Deyo
Received: from ietf.org by ietf.org id aa13426; 9 May 97 16:18 EDT
Received: from atl.eni.net by ietf.org id aa13350; 9 May 97 16:16 EDT
Received: from swcc.UUCP (uucp at localhost)
by atl.eni.net (8.8.4/8.8.4) with UUCP
id QAA25784 for ietf at ietf.org; Fri, 9 May 1997 16:02:03 -0400
Message-Id: <199705092002.QAA25784 at atl.eni.net>
Date: 9 May 1997 15:07:09 -0400
Sender:ietf-request at ietf.org
From: Michael Kornegay <michaelk at swcc.com>
Subject: Re: AOL mail traffic
To: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
RE>AOL mail traffic
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.
