Received: from ietf.org by ietf.org id aa17374; 3 Feb 97 10:27 EST Received: from cnri by ietf.org id aa17067; 3 Feb 97 10:17 EST Received: from gatekeeper.chbs.ciba.com by CNRI.Reston.VA.US id aa11515; 3 Feb 97 10:17 EST Received: from cgchm.is.chbs by gatekeeper.chbs.ciba.com; (5.65v3.2/1.1.8.2/12Mar96-0208PM) id AA06193; Mon, 3 Feb 1997 16:15:20 +0100 Received: from mta1.is.chbs by Central.CHBS.CIBA.COM id AA29269; Mon, 3 Feb 1997 16:14:42 +0100 (5.65c8/Ciba2.0-C1.1) Received: by mta1.is.chbs (5.65v3.2/DEC-Ultrix/4.3) id AA10757; Mon, 3 Feb 1997 16:13:49 +0100 X400-Received: by /PRMD=CIBA/ADMD=attmail/C=CH/; Relayed; 3 Feb 1997 16:15:24 +0100 X400-Received: by mta chbs-mta1 in /PRMD=ciba/ADMD=attmail/C=ch/; Relayed; 3 Feb 1997 15:13:48 +0000 X400-Received: by mta chbs-exc2 in /PRMD=CIBA/ADMD=attmail/C=CH/; Relayed; 3 Feb 1997 16:15:24 +0100 X400-Received: by mta NOVARTIS/CHBSIS01R in /PRMD=CIBA/ADMD=attmail/C=CH/; Relayed; 3 Feb 1997 16:15:24 +0100 Date: 3 Feb 1997 16:15:24 +0100 X400-Originator: werner.bossart@chbs.mhs.ciba.com X400-Mts-Identifier: [/PRMD=CIBA/ADMD=attmail/C=CH/;NOVARTIS/CHBSIS01R/0006C9E7] Sender:ietf-request@ietf.org From: BOSSART WERNER MSM CF2 CH To: 'ietf' Importance: normal Autoforwarded: FALSE Message-Id: <"/GUID:80D36AE8*"@MHS> X400-Content-Type: P2-1988 (22) Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa17442; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa14931; 3 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-miller-mftp-spec-01.txt Date: Mon, 03 Feb 1997 09:56:10 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030956.aa14931@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : StarBurst Multicast File Transfer Protocol (MFTP) Specification Author(s) : K. Miller, K. Robertson, A. Tweedly, M. White Filename : draft-miller-mftp-spec-01.txt Pages : 57 Date : 01/31/1997 The Multicast File Transfer Protocol (MFTP) is a protocol that operates above UDP in the application layer to provide a reliable means for transferring files from a sender to up to thousands (potentially millions with network "aggregators" or relays) of multiple receivers simultaneously over a multicast group in a multicast IP enabled network. The protocol consists of two parts; an administrative protocol to set up and tear down groups and sessions, and a data transfer protocol used to send the actual file reliably and simultaneously to the multiple recipients residing in the group. 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-miller-mftp-spec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-miller-mftp-spec-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-miller-mftp-spec-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131114117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-miller-mftp-spec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-miller-mftp-spec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131114117.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17413; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa15007; 3 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ids-dnsnames-02.txt Date: Mon, 03 Feb 1997 09:56:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030956.aa15007@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 : Use of DNS Aliases for Network Services Author(s) : M. Hamilton, R. Wright Filename : draft-ietf-ids-dnsnames-02.txt Pages : 9 Date : 01/31/1997 It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programatically discover that an organization runs, say, a World-Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant "folklore" on naming conventions, and proposes a mechanism for accommodating new protocols. It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site. There are efforts in other IETF working groups to address the long term solution to this problem, such as the Server Location Resource Records (DNSSRV) [RFC-2052] work. 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-dnsnames-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ids-dnsnames-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ids-dnsnames-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131142243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ids-dnsnames-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ids-dnsnames-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131142243.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17458; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa14929; 3 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-nhrp-mib-01.txt Date: Mon, 03 Feb 1997 09:56:07 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030956.aa14929@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 : Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) Author(s) : M. Greene, J. Luciani Filename : draft-ietf-ion-nhrp-mib-01.txt Pages : 40 Date : 01/31/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 for the Next Hop Resolution Protocol (NHRP) as defined in [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. 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-ion-nhrp-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-nhrp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-nhrp-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131113118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-nhrp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-nhrp-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131113118.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17426; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa14876; 3 Feb 97 9:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-mib-05.txt Date: Mon, 03 Feb 1997 09:55:53 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030955.aa14876@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : RSVP Management Information Base Author(s) : F. Baker, J. Krawczyk Filename : draft-ietf-rsvp-mib-05.txt Pages : 79 Date : 01/31/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 the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu. This memo does not, in its draft form, 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-rsvp-mib-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-mib-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-mib-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131112535.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-mib-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131112535.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17450; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa14892; 3 Feb 97 9:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-mib-05.txt Date: Mon, 03 Feb 1997 09:55:55 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030955.aa14892@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 Services Working Group of the IETF. Title : Integrated Services Management Information Base Author(s) : F. Baker, J. Krawczyk Filename : draft-ietf-intserv-mib-05.txt Pages : 27 Date : 01/31/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 the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, 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-intserv-mib-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-mib-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-mib-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131112233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-mib-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131112233.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17457; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa14970; 3 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-nagami-00.txt Date: Mon, 03 Feb 1997 09:56:18 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030956.aa14970@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Flow Attribute Notification Protocol (FANP) Specification Author(s) : K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki Filename : draft-rfced-info-nagami-00.txt Pages : 18 Date : 01/31/1997 This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn't have to perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node and helps a pair of nodes manage the mapping information. By using FANP, routers (e.g., CSR; Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. 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-nagami-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-nagami-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-nagami-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131140407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-nagami-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-nagami-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131140407.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17424; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa14964; 3 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-mixer@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mixer-mail11-00.txt Date: Mon, 03 Feb 1997 09:56:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030956.aa14964@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME - X.400 Gateway Working Group of the IETF. Title : MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail Author(s) : C. Allocchio Filename : draft-ietf-mixer-mail11-00.txt Pages : 29 Date : 01/31/1997 This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU) X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol. The specifications are valid both within DECnet Phase IV and DECnet/OSI addressing and routing scheme. The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations. This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and the RFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts. This document obsoletes RFC 1405, which was a combined effort of TERENA Working Group on Messaging, and the IETF X.400 Ops Working Group. This update was prepared by IETF MIXER working group. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mixer-mail11-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mixer-mail11-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mixer-mail11-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131115142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mixer-mail11-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mixer-mail11-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131115142.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17455; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa14908; 3 Feb 97 9:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-guaranteed-mib-03.txt Date: Mon, 03 Feb 1997 09:55:58 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030955.aa14908@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 Services Working Group of the IETF. Title : Integrated Services Management Information Base Guaranteed Service Extensions Author(s) : F. Baker Filename : draft-ietf-intserv-guaranteed-mib-03.txt Pages : 14 Date : 01/31/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 the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, 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-intserv-guaranteed-mib-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-guaranteed-mib-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131111801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-guaranteed-mib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131111801.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17418; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa15023; 3 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mobile-ip@smallworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mobileip-tunnel-reverse-00.txt Date: Mon, 03 Feb 1997 09:56:26 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030956.aa15023@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 Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Reverse Tunneling for Mobile IP Author(s) : G. Montenegro Filename : draft-ietf-mobileip-tunnel-reverse-00.txt Pages : 13 Date : 01/31/1997 Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign net, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. 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-mobileip-tunnel-reverse-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-tunnel-reverse-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-tunnel-reverse-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131173346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-tunnel-reverse-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-tunnel-reverse-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131173346.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17417; 3 Feb 97 10:28 EST Received: from ietf.ietf.org by ietf.org id aa14963; 3 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-mixer@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mixer-rfc1664bis-00.txt Date: Mon, 03 Feb 1997 09:56:15 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702030956.aa14963@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME - X.400 Gateway Working Group of the IETF. Title : Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) Pages : 23 Author(s) : C. Allocchio Filename : draft-ietf-mixer-rfc1664bis-00.txt Pages : 23 Date : 01/31/1997 This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their local DNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo obsoletes RFC1664. It includes the changes introduced by MIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too. RFC1664 was a joint effort of IETF X400 operation working group (x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mixer-rfc1664bis-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mixer-rfc1664bis-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mixer-rfc1664bis-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970131120118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mixer-rfc1664bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mixer-rfc1664bis-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970131120118.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa02079; 4 Feb 97 9:30 EST Received: from ietf.ietf.org by ietf.org id aa01353; 4 Feb 97 9:07 EST To: IETF-Announce: ; Subject: IETF Nominations Committee Report Sender:ietf-announce-request@ietf.org From: Geoff Huston Date: Tue, 04 Feb 1997 09:07:52 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702040907.aa01353@ietf.org> The IETF Nominations Committee has now completed its work in selecting candidates for the positions in the IESG and IAB whose term expires at the April 1997 IETF meeting. The candidates have been selected following extensive consultation regarding the consensus view of the IETF community's perceptions of the qualifications appropriate for these positions, and the Nominations Committee has adhered strictly to the process described in the document RFC 2027 throughout its schedule. The Nominations Committee's activities commenced in mid-October 1996, so this concluding report is being passed to the IETF somewhat earlier than has been the case in previous years. We were aware that in the course of the committee's work many highly qualified individuals, and their employers, were willing to make an open commitment of the individuals' time and energies to levels in excess of 1 - 2 working days per week for a two year period. We felt that we could not request the many individuals involved to hold open this generous commitment for more than a few weeks, so we have worked diligently to bring the process through to this stage within a timely fashion, to ensure that we did not abuse their generosity any further than was strictly necessary. Four IESG positions are to be filled by the IETF Nominations process in 1997. These positions are Transport, Internet, Applications and Operations and Management. The following individuals have been selected as candidates for these positions, and their candidature confirmed by the IAB: Applications Co-Area Director Harald T. Alvestrand Harald.T.Alvestrand@uninett.no Harald is the incumbent in this position and the committee has noted a very high level of confidence in Harald's carriage of this position within the IETF. Harald is employed at UNINETT, the Norwegian academic network, in the position of "services manager". This entails oversight over UNINETT application-level services, and initiation and monitoring of UNINETT's development activities in the applications area. Harald is also actively in TERENA activities in addition to his IETF activities. He high level of acitivity in the IETF includes autorship of 7 curently active drafts and 7 RFCs. UNINETT management has committed to continue to support Harald in his IESG role. Internet Co-Area Director Thomas Narten narten@raleigh.ibm.com Thomas brings a high level of technical depth and breadth to the Area and to the IESG. Thomas has a very high level of understanding of the Internet Area, and also has a strong working knowledge of routing end to end transport and security. The committee is of the view that this will be of assistance on the IESG in understanding how the activities of various WGs impact each other. Thomas currently is employed by IBM, TCP/IP Technologies, and prior to this was an Adjunct Assistant Professor in the Computer Science Department at Duke University. He has authored RFCs 1970 and 1971 as well as numerous research publications. Operations and Management Co-Area Director John Curran jcurran@bbnplanet.com John is a well respected IETF member, currently Co-chair of the Uniform Resource Name WG (APP), a participant in the Application Area Directorate, a past participant in the Ops Area Directorate and the IPNG Directorate. He was also the 1995 IETF NomCom Chair. He is the Chief Technical Officer, BBN Planet, and brings a wealth of direct operational experience to the IETF. He has a thorough understanding of the operational and management requirements posed by complex large scale networks, and is highly respected wthin the Internet operations community. Transport Co-Area Director Scott Bradner sob@harvard.edu Scott is also a well respected IETF member, and has served as the Operations Area Director for the past 5 years. He has authored an extensive number of RFCs. Scott has been selected as the candidate for the Transport Area following much consultation within the IETF community over the status of this Area and its direction. The Nominations Committee did consider very carefully the merits of continuing with a purely transport-oriented direction, with an admitted high component of activity which borders of research activity, and weighed this against the introduction of operational expertise into the Area at the Area Director level. The committee formed the distinct impression from their consultation that the latter course of action, of the nomination of an indivdual with extensive operational expertise, was necessary at this point in time, although some potential difficulties in undertaking this were noted. Scott is perhaps the most experienced Area Director the IETF has, and certainly acknowledged to be a very capable Area manager as well as a contributor to the IETF, and there is a very high level of confidence in Scott to work with the Transport Co-Area Director (who was appointed relatively recently) and the Transport Area members to provide a level of leadership to the Area's activites which will assist in harmonising Internet operational considerations with technology development. Six IAB positions are to be filled by the IETF Nominations process in 1997. The following individuals have been selected by the IETF Nominations Committee as candidates for these positions, and the candidature confirmed by the ISOC Board of Trustees: Steve Deering deering@parc.xerox.com For the past five years, Steve has been employed as a Member of the Research Staff at Xerox PARC, engaged in research on advanced internet technologies, including multicast routing, mobile internetworking, scalable addressing, and support for multimedia applications over the Internet. Steve has recently joined the Gigabit Switching Group at Cisco, where he is continuing his involvement in internet protocol research and contributing to the design of very high speed routers. Steve has co-chaired a significant number of IETF Working Groups in areas of Ipv6, routing, multicast and mobile IP during his extensive involvement with IETF activities. Tony Hain tonyhain@microsoft.com Tony Hain has had extensive operational experience as the Associate Manager at ESNET in the period 1990 - 1995. Tony is currently employed at Microsoft in the position of Internet Architect MSN. Tony has been an active member of various Internet Operational groups, including the FEPG, the IEPG and NANOG, and has also had extensive involvement at the IETF, focussing on feedback about the operational impact of design suggestions and early implementation testing. In this role Tony is currently co-chairing the IPv6 transition tools working group. Erik Huizer Erik.Huizer@sec.nl Erik Huizer is Managing Director of the SURFnet Expertise Center. Erik has perviously worked as a network development project manager with SURFnet bv, the company that operates the Academic and Research network in The Netherlands. He manages various national and international projects on the Internet, security, E-mail, Information services and Directory services. Erik has been a member of the RARE (now Terena) Technical Committee for three years. He is an active IETF member and has chaired and acted as editor for a number of IETF Working Groups. He has also been the Area Director for the Applications Area of the Internet Engineering Task Force, and as such a member of the Internet Engineering Steering Group from 1990-1995. He is currently a member of the Internet Architecture Board. Cyndi Jung cmj@3Com.com Cyndi is the protocol architect and software development manager for 3Com's router products. Cyndi has had extensive experience in routing architectures from the perspective of vendor implementation for many years. She has been involved in the IETF routing working groups and also in the IPv6 activity domain, most recently working on technical aspects of IPv6 transition. Robert Moskowitz rgm3@chrysler.com Robert is employed by the Chrysler Corporation in Internet related activities, including email architecture, Intranet developments and EDI over TCP, and is well aware of the corporate requirements with respect to the directions of Internet technologies. He is also a member of the US Federal Networking Council Advisory Committee (appointed April 96 for a 3 year term), a body which advises the US federal research networks on policy issues. He is the co-chair of the FNCAC security committee. Robert is currently a member of the Internet Architecture Board, and has been active in the IETF, particularly within the Applications Directorate, for many years. Charlie Perkins charliep@watson.ibm.com Charlie works at the IBM T. J. Watson Research Center. Charlie has had extensive involvement in the development of various Internet technologies, and is principally known for his efforts within the MobileIP Working Group. He has also been involved with Dynamic Host Configuration, IPV6 and Service Location protocol development work. He is also serving on the US National Research Council committee and a US Cross-Industry Working Team (XIWT) group It has been a challenging task for the committee, and I'd like to take this opportunity to thank the committee members for their diligence in this work, and also to thank all other members of the IETF who participated in the 1997 Nominations process in various capacities. Thanks, Geoff Huston for IETF Nominations Committee: Guy Almes Jim Bound Matt Crawford Phill Gross Bob Hinden Dorian Kim Bill Manning Marshall Rose Mike StJohns Glen Zorn Geoff Huston (chair) Joyce Reynolds (IESG liaison) Radia Perlman (IAB liaison) Christian Huitema (ISOC liaison)   Received: from ietf.org by ietf.org id aa03962; 4 Feb 97 9:45 EST Received: from ietf.ietf.org by ietf.org id aa02994; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-netstrings-02.txt Date: Tue, 04 Feb 1997 09:42:50 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa02994@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Netstrings Author(s) : D. Bernstein Filename : draft-bernstein-netstrings-02.txt Pages : 2 Date : 02/03/1997 A netstring is a self-delimiting encoding of a string. Netstrings are very easy to generate and to parse. Any string may be encoded as a netstring; there are no restrictions on length or on allowed bytes. Another virtue of a netstring is that it declares the string size up front. Thus an application can check in advance whether it has enough space to store the entire string. Netstrings may be used as a basic building block for reliable network protocols. Most high-level protocols, in effect, transmit a sequence of strings; those strings may be encoded as netstrings and then concatenated into a sequence of characters, which in turn may be transmitted over a reliable stream protocol such as TCP. 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-bernstein-netstrings-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-netstrings-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-netstrings-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203123113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-netstrings-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-netstrings-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203123113.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03945; 4 Feb 97 9:45 EST Received: from ietf.ietf.org by ietf.org id aa02891; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-r2r-nhrp-00.txt Date: Tue, 04 Feb 1997 09:42:35 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa02891@ietf.org> --NextPart A New 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 : NHRP for Destinations off the NBMA Subnetwork Author(s) : Y. Rekhter Filename : draft-ietf-ion-r2r-nhrp-00.txt Pages : 13 Date : 02/03/1997 The NBMA Next Hop Resolution Protocol (NHRP) [NHRP] specifies a mechanism that allows a source station (e.g., a host or a router) on an NBMA subnetwork to find the NBMA subnetwork address address of a destination station when the destination station is connected to the NBMA subnetwork. For the case where the destination station is off the NBMA subnetwork the mechanism described in [NHRP] allows to determine the NBMA subnetwork address of an egress router from the NBMA subnetwork that is ``nearest'' to the destination station. However, the ability of determining the egress router is constrained to the destinations that are directly connected to the egress router. This document describes extensions to the NBMA Next Hop Resolution Protocol (NHRP) [NHRP] that allow to acquire and maintain the information about the egress router without constraining the destination(s) to be directly connected to the egress router. 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-r2r-nhrp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-r2r-nhrp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-r2r-nhrp-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203110326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-r2r-nhrp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-r2r-nhrp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203110326.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03981; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa02872; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pfenning-irc-extensions-00.txt Date: Tue, 04 Feb 1997 09:42:29 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa02872@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the Internet Relay Chat Protocol (IRCX) Author(s) : K. Cedola, T. Pfenning Filename : draft-pfenning-irc-extensions-00.txt Pages : 27 Date : 02/03/1997 This document describes extensions to the Internet Relay chat protocol defined in RFC 1459[1]. The added functionality includes optional user authentication for multiple security providers, support for UNICODE[2] characters, multilayer security, a unified property mechanism, and support for tagged data messages. Chat server implementations can optionally support channel or server services with full control over all messages and events. These services communicate with the core server over an extended IRC connection. All changes to the IRC protocol are designed in a way that existing clients will continue to work against servers implementing the extensions. Support for the extended protocol can be queried by clients to take advantage of the added functionality or to conform to the basic protocol as defined in RFC 1459. 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-pfenning-irc-extensions-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-pfenning-irc-extensions-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pfenning-irc-extensions-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203103136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pfenning-irc-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pfenning-irc-extensions-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203103136.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03994; 4 Feb 97 9:45 EST Received: from ietf.ietf.org by ietf.org id aa03072; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-qsbmf-02.txt Date: Tue, 04 Feb 1997 09:42:59 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03072@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The qmail-send Bounce Message Format (QSBMF) Author(s) : D. Bernstein Filename : draft-bernstein-qsbmf-02.txt Pages : 3 Date : 02/03/1997 When a message transport agent (MTA) finds itself permanently unable to deliver a mail message, it generates a new message, generally known as a bounce message, back to the envelope sender. Bounce messages produced by the qmail-send program display the list of failed recipient addresses, an explanation for each address, and a copy of the original message, in a format that is easy for both humans and programs to read. This document defines the 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-bernstein-qsbmf-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-qsbmf-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-qsbmf-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203124730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-qsbmf-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-qsbmf-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203124730.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03904; 4 Feb 97 9:45 EST Received: from ietf.ietf.org by ietf.org id aa02856; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: http-wg@cuckoo.hpl.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-http-pep-01.txt Date: Tue, 04 Feb 1997 09:42:22 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa02856@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. Title : PEP: an Extension Mechanism for HTTP Author(s) : D. Connolly Filename : draft-ietf-http-pep-01.txt Pages : 14 Date : 01/03/1997 HTTP is an extensible protocol. PEP is an extension mechanism designed to address the tension between private agreement and public specification and to accomodate extension of HTTP clients and servers by software components. The mechanism is to associate each extension with a URL, and use a few new header fields to carry the extension identifier and related information from HTTP clients, thru proxies and intermediaries, to servers, and back again. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-http-pep-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-pep-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203101110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-pep-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-http-pep-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203101110.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03931; 4 Feb 97 9:45 EST Received: from ietf.ietf.org by ietf.org id aa03041; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-qmtp-01.txt Date: Tue, 04 Feb 1997 09:42:56 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa03041@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Quick Mail Transfer Protocol (QMTP) Author(s) : D. Bernstein Filename : draft-bernstein-qmtp-01.txt Pages : 5 Date : 02/03/1997 The Quick Mail Transfer Protocol (QMTP) is a replacement for the Simple Mail Transfer Protocol (SMTP). QMTP eliminates any need for end-of-line scanning between hosts with the same end-of-line convention. It features automatic pipelining and chunking, 8-bit transmission, prior declaration of the message size, and efficient batching. It is designed to be very easy to implement. 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-bernstein-qmtp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-qmtp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-qmtp-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203132526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-qmtp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-qmtp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203132526.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03963; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa03158; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: namedroppers@internic.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsind-clarify-05.txt Date: Tue, 04 Feb 1997 09:43:08 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03158@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 : Clarifications to the DNS Specification Author(s) : R. Elz, R. Bush Filename : draft-ietf-dnsind-clarify-05.txt Pages : 14 Date : 02/03/1997 This draft considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. Six separate issues are considered: + IP packet header address usage from multi-homed servers, + TTLs in sets of records with the same name, class, and type, + correct handling of zone cuts, + two minor issues concerning SOA records and their use, + the issue of what is an authoritative, or canonical, name, + and the issue of what makes a valid DNS label. The first four of these are areas where the correct behaviour has been somewhat unclear, we seek to rectify that. The other two are already adequately specified, however the specifications seem to be sometimes ignored. We seek to reinforce the existing specifications. This version adds a brief discussion on the placement of an SOA record in the answer to an authoritative query, and the issue of TTLs on SOA records. It also contains rather more discussion inspired by the oddities of some of the new DNSSEC record types. The ordered list of trustworthiness of various data types was revised by grouping the last three categories together, and adding a restriction on how such data should be used. Many editorial changes were made. This paragraph will be deleted from the final version of this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsind-clarify-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-clarify-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnsind-clarify-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203133533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-clarify-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsind-clarify-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203133533.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03935; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa03017; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-pirp-02.txt Date: Tue, 04 Feb 1997 09:42:52 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa03017@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Public Information Retrieval Protocol (PIRP) Author(s) : D. Bernstein Filename : draft-bernstein-pirp-02.txt Pages : 3 Date : 02/03/1997 The Public Information Retrieval Protocol (PIRP) gives Internet hosts a simple, uniform, efficient, extensible, easily implemented method of publishing information. This document defines PIRP and outlines the structure of PIRP names. Unlike FTP and HTTP, PIRP is dedicated to publication. Implementing PIRP ought to be a small and trivial task. 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-bernstein-pirp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-pirp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-pirp-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203124054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-pirp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-pirp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203124054.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03911; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa02978; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-mail-loops-war-02.txt Date: Tue, 04 Feb 1997 09:42:47 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa02978@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tools in the War on Mail Loops Author(s) : D. Bernstein Filename : draft-bernstein-mail-loops-war-02.txt Pages : 6 Date : 02/03/1997 An automailer means any program that receives a mail message and automatically sends one or more mail messages. This term is meant to include not only a mail-based server, such as a mailing list exploder or a vacation program, but also an SMTP server, which receives a message from the network and relays it to a local or remote user. In a network full of automailers, any mistake can cause a mail loop. Since some automailers generate several outputs in response to a single input, a loop can produce an exponential explosion of mail. All the automailers in the qmail package follow a general philosophy designed to prevent mail loops and limit the damage from any loops that do occur. These automailers have been repeatedly observed to fail safe: they stop loops in the face of typical failures by other hosts. This document explains the philosophy and describes the automailers. 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-bernstein-mail-loops-war-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-mail-loops-war-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-mail-loops-war-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203122706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-mail-loops-war-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-mail-loops-war-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203122706.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03980; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa02910; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-eplf-02.txt Date: Tue, 04 Feb 1997 09:42:40 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa02910@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Easily Parsed LIST Format (EPLF) Author(s) : D. Bernstein Filename : draft-bernstein-eplf-02.txt Pages : 4 Date : 02/03/1997 The File Transfer Protocol (FTP) supports two commands that list files: NLST and LIST. The NLST response is easy to parse but provides very little information. The LIST response provides more information, but in a format that varies from system to system. The most common LIST formats are undocumented and impossible to parse reliably. This document defines Easily Parsed LIST Format (EPLF), a format for the LIST response that is usable by humans yet easy for programs to handle. This format is supported by anonftpd, a secure FTP server. One visible advantage of EPLF is that a browser can easily display dates in the viewer's time zone and native language. EPLF also makes it straightforward for an indexing program to automatically traverse an FTP area and for a mirroring program to avoid downloading the same file twice. 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-bernstein-eplf-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-eplf-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-eplf-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203121739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-eplf-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-eplf-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203121739.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04058; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa03234; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-calendar@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-ical-issues-00.txt Date: Tue, 04 Feb 1997 09:43:19 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03234@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 : Core Object Specification - Issues Document Author(s) : A. Ganguly, F. Dawson, D. Stenerson Filename : draft-ietf-calsch-ical-issues-00.txt Pages : 11 Date : 02/03/1997 This document is an IETF CALSCH working group document. The document is used as a tool for recording issues and their resolution with mailing list discussions. This Issues Document is intended to track the resolution of issues related to the _Core Object Specification_ deliverable. The most current version of this document can be found on the IETF CALSCH Working Group document archive at http://www.imc.org. Issues within this document are classified as either being OPEN or RESOLVED. Additionally, an issue may be found to no longer be a concern and may be classified as WITHDRAWN. Issues falling into each of these categories is listed in a separate section. An issues is documented with a short summary title, a brief description, and a list of identified alternatives. A resolved issue will also include a description of the resolution and the date/venue that the resolution was reached. Distribution of this document is unlimited. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-ical-issues-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-ical-issues-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-calsch-ical-issues-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203141127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-ical-issues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-ical-issues-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203141127.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04049; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa03182; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: applmib@emi-summit.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-applmib-wwwmib-01.txt Date: Tue, 04 Feb 1997 09:43:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03182@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application MIB Working Group of the IETF. Title : Definitions of Managed Objects for WWW Servers Author(s) : C. Kalbfleisch, H. Hazewinkel, J. Schoenwaelder Filename : draft-ietf-applmib-wwwmib-01.txt Pages : 56 Date : 02/03/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 a set of managed objects for WWW servers. These objects include extensions to Network Services Monitoring MIB, extensions to sysApplMIB, error reporting and document storage information. Some portions of this information are not yet defined and will be added to this document in future revisions. These attributes are applicable to the HTTP protocol of WWW but may also be applicable to other information retrieval services like ftp, nntp, gopher and wais. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-applmib-wwwmib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-applmib-wwwmib-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-applmib-wwwmib-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203134223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-applmib-wwwmib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-applmib-wwwmib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203134223.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04385; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa03334; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipng@sunroof.eng.sun.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-icmp-mib-00.txt Date: Tue, 04 Feb 1997 09:43:39 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03334@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Management Information Base for IP Version 6: ICMPv6 Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-icmp-mib-00.txt Pages : 18 Date : 02/03/1997 This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-icmp-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970203150821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-icmp-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203150821.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04397; 4 Feb 97 9:46 EST Received: from ietf.ietf.org by ietf.org id aa03438; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-aggregation-framework-00.txt Date: Tue, 04 Feb 1997 09:43:55 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03438@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for Inter-Domain Route Aggregation Author(s) : E. Chen, J. Stewart Filename : draft-chen-aggregation-framework-00.txt Pages : 13 Date : 02/03/1997 This document presents a framework for inter-domain route aggregation and shows an example router configuration which "implements" this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the "no-export" BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. 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-chen-aggregation-framework-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-chen-aggregation-framework-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-chen-aggregation-framework-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203151816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-chen-aggregation-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-chen-aggregation-framework-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203151816.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04919; 4 Feb 97 9:49 EST Received: from ietf.ietf.org by ietf.org id aa02934; 4 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-hcmssc-02.txt Date: Tue, 04 Feb 1997 09:42:43 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040942.aa02934@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Hash Convention For Mail System Status Codes (HCMSSC) Author(s) : D. Bernstein Filename : draft-bernstein-hcmssc-02.txt Pages : 1 Date : 02/03/1997 RFC 1893 defines codes for mail delivery failures. For example, code 5.1.1 means that the specified mailbox does not exist. The qmail package sprays these codes all over the place, by adding a code to the text of every error message, preceded by a hash mark and surrounded by parentheses. It avoids using hash marks elsewhere. 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-bernstein-hcmssc-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-hcmssc-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-hcmssc-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203122307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-hcmssc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-hcmssc-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203122307.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab04919; 4 Feb 97 9:49 EST Received: from ietf.ietf.org by ietf.org id aa03209; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-calendar@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-ical-00.txt Date: Tue, 04 Feb 1997 09:43:16 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03209@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 : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Author(s) : F. Dawson, D. Stenerson Filename : draft-ietf-calsch-ical-00.txt Pages : 66 Date : 02/03/1997 There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This document has been defined to provide the a definition of a common format for openly exchanging calendaring and scheduling information across the Internet. This memo is formatted as a registration for a MIME media type per [RFC1521]. However, the format in this memo is equally applicable for use outside of a MIME message content type. [Editor NOTE: This form will be changed to reflect the new MIME memos in the next draft.] The proposed media type value is "TEXT/CALENDAR". This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event and to-do information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems or using HTTP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-ical-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-ical-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-calsch-ical-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203140136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-ical-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-ical-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203140136.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ac04919; 4 Feb 97 9:49 EST Received: from ietf.ietf.org by ietf.org id aa03288; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipng@sunroof.eng.sun.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-mib-00.txt Date: Tue, 04 Feb 1997 09:43:29 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03288@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Management Information Base for IP Version 6: Textual Conventions and General Group Author(s) : D. Haskin Filename : draft-ietf-ipngwg-ipv6-mib-00.txt Pages : 40 Date : 02/03/1997 This document is one in the series of documents that provide MIB definitions for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970204090730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970204090730.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ad04919; 4 Feb 97 9:49 EST Received: from ietf.ietf.org by ietf.org id aa03470; 4 Feb 97 9:44 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: http-wg@cuckoo.hpl.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-http-state-mgmt-errata-00.txt, .ps Date: Tue, 04 Feb 1997 09:44:01 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040944.aa03470@ietf.org> --NextPart A New 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 (Errata) Author(s) : D. Kristol Filename : draft-ietf-http-state-mgmt-errata-00.txt, .ps Pages : 3 Date : 02/03/1997 This document contains miscellaneous small wording changes and clarifications to draft-inet-http-state-mgmt-05, the HTTP State Management Mechanism draft. 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-mgmt-errata-00.txt". Or "get draft-ietf-http-state-mgmt-errata-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-mgmt-errata-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-state-mgmt-errata-00.txt". Or "FILE /internet-drafts/draft-ietf-http-state-mgmt-errata-00.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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203165136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-state-mgmt-errata-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-http-state-mgmt-errata-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203165136.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05642; 4 Feb 97 9:54 EST Received: from ietf.ietf.org by ietf.org id aa03368; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipng@sunroof.eng.sun.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-udp-tcp-mib-00.txt Date: Tue, 04 Feb 1997 09:43:49 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03368@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Management Information Base for IP Version 6: UDP and TCP Groups Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-udp-tcp-mib-00.txt Pages : 19 Date : 02/03/1997 This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the UDP and TCP groups are defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-udp-tcp-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-udp-tcp-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-tcp-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970203151406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-tcp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-udp-tcp-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203151406.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06584; 4 Feb 97 10:05 EST Received: from ietf.ietf.org by ietf.org id aa03138; 4 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-nrudt-02.txt Date: Tue, 04 Feb 1997 09:43:05 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702040943.aa03138@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Notice-Requested-Upon-Delivery-To (NRUDT) Author(s) : D. Bernstein Filename : draft-bernstein-nrudt-02.txt Pages : 2 Date : 02/03/1997 The UNIX sendmail program has for many years supported a Return-Receipt-To (RRT) header field that requests a notice of successful final delivery. Notice-Requested-Upon-Delivery-To (NRUDT) has the same basic function. The big difference is that RRT lists the sender's address, while NRUDT lists the recipient's address. This change is critical. RRT works poorly for messages to multiple recipients, because it requests a notice from every recipient. RRT in a message to a large mailing list produces a giant, usually unintentional, flood of mail. This problem is so severe that RRT has been disabled in recent versions of sendmail. NRUDT is designed to be adopted immediately, with minimal disruption, as a solution to the problems of RRT. Note that NRUDT is merely a request for notification; unlike the link-level Delivery Status Notification SMTP extension, NRUDT does not provide a guarantee of notification. 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-bernstein-nrudt-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-nrudt-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-nrudt-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970203123631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-nrudt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-nrudt-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970203123631.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14133; 4 Feb 97 20:16 EST Received: from zephyr.isi.edu by ietf.org id aa13810; 4 Feb 97 20:10 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 4 Feb 1997 17:08:42 -0800 Message-Id: <199702050108.AA26165@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2101 on IPv4 Address Behavior Today Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 04 Feb 97 17:08:41 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2101: Title: IPv4 Address Behaviour Today Author: B. Carpenter, J. Crowcroft, Y. Rekhter Date: February 1997 Mailbox: brian@dxcoms.cern.ch, j.crowcroft@cs.ucl.ac.uk, yakov@cisco.com Pages: 13 Characters: 31407 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2101.txt The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970204170411.RFC@ISI.EDU> SEND /rfc/rfc2101.txt --OtherAccess Content-Type: Message/External-body; name="rfc2101.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970204170411.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14817; 4 Feb 97 20:31 EST Received: from zephyr.isi.edu by ietf.org id aa14636; 4 Feb 97 20:28 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 4 Feb 1997 17:25:56 -0800 Message-Id: <199702050125.AA27120@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2098 on Toshiba's Router Extension for ATM Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 04 Feb 97 17:25:56 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2098: Title: Toshiba's Router Architecture Extensions for ATM : Overview Author: Y. Katsube, K. Nagami, H. Esaki Date: February 1997 Mailbox: katsube@isl.rdc.toshiba.co.jp, nagami@isl.rdc.toshiba.co.jp, hiroshi@isl.rdc.toshiba.co.jp Pages: 18 Characters: 43622 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2098.txt This memo describes a new internetworking architecture which makes better use of the property of ATM. IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture. A concept of "Cell Switch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding. Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept. It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such as RSVP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970204172139.RFC@ISI.EDU> SEND /rfc/rfc2098.txt --OtherAccess Content-Type: Message/External-body; name="rfc2098.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970204172139.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14819; 4 Feb 97 20:32 EST Received: from zephyr.isi.edu by ietf.org id aa14737; 4 Feb 97 20:30 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 4 Feb 1997 17:28:23 -0800 Message-Id: <199702050128.AA27247@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2090 on TFTP Multicast Option Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 04 Feb 97 17:28:22 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2090: Title: TFTP Multicast Option Author: A. Emberson Date: February 1997 Mailbox: tom@lanworks.com Pages: 6 Characters: 11857 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2090.txt This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970204172631.RFC@ISI.EDU> SEND /rfc/rfc2090.txt --OtherAccess Content-Type: Message/External-body; name="rfc2090.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970204172631.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01981; 5 Feb 97 4:59 EST Received: from cnri by ietf.org id aa01649; 5 Feb 97 4:52 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa05928; 5 Feb 97 4:52 EST Received: from nemesis.csi.forth.gr by venera.isi.edu (5.65c/5.61+local-26) id ; Wed, 5 Feb 1997 01:49:59 -0800 Received: from clio.csi.forth.gr by nemesis.csi.forth.gr (ICS mailhost); on Wed, 5 Feb 1997 11:43:44 +0200 (EET DST); with id AA12229 Date: Wed, 5 Feb 1997 11:43:44 +0200 Sender:ietf-request@ietf.org From: Dimitris Serpanos Received: by clio.csi.forth.gr (4.1/SMI-4.1) id AA02999; Wed, 5 Feb 97 11:43:42 +0200 Message-Id: <9702050943.AA02999@clio.csi.forth.gr> Organization: Institute of Computer Science, Foundation for Research and Technology-Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385 GR 711 10 Heraklion, Crete, Greece tel.: +30 (81) 39 16 00, fax: +30 (81) 39 16 01 To: atmip@arl.wustl.edu, comsoc-tcii@ieee.org, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, end2end-interest@isi.edu, giga@tele.pitt.edu, ieeetcpc@ccvm.sunysb.edu, ietf@isi.edu, isadsoc@fokus.gmd.de, multicomm@cc.bellcore.com, tccc@ieee.org Subject: CFP: Multimedia Issue for the Journal of Telecommunication Systems Source-Info: From (or Sender) name not authenticated. I apologize if you receive this announcement more than once! ******************************************************************************* (Also available at: http://www.ics.forth.gr/events/telej/telej.html) CALL FOR PAPERS ================= JOURNAL of TELECOMMUNICATION SYSTEMS (by Baltzer Science Publishers) SPECIAL ISSUE on MULTIMEDIA Multimedia systems and applications have attracted significant attention during the last few years. The ability to deliver audio and video to end-users, in addition to data, has created possibilities which will revolutionize industries ranging from education and advertising, with applications such as digital libraries, distant learning, expert advice and real-time video clip playback, to tele-collaboration, electronic commerce and entertainment, with such applications as video-conferencing, telecommuting, video-on-demand, etc. These expectations, which originate from the marketplace, have triggered a significant amount of research and development of multimedia systems during the last decade. The success of these efforts is due to the dramatic improvements in several fronts: technology, processing systems, operating systems, and high-speed networking. These advances have brought us to a new era where practical systems are designed and dispatched in the marketplace. The Journal of Telecommunication Systems is planning a special issue on multimedia to address this emerging technology. The issue will address all issues of multimedia systems with special focus on issues related to networking and telecommunication systems. Papers are solicited for this issue in the following areas (but not limited to): - Multimedia information processing (compression/decompression) - Multimedia storage and retrieval - Network issues (QoS, protocols, performance/modeling, etc) - Telecommunication systems requirements for multimedia - Telecommunication systems architecture and implementation - Security issues - End-to-end multimedia system architecture - Multimedia applications and application design PAPER SUBMISSIONS: ------------------ Please submit 4 copies of your manuscript to either of the Guest Editors: Dimitrios Serpanos Chatschik Bisdikian Institute of Computer Science IBM Research Foundation for Research and Technology-Hellas T.J. Watson Research Ctr. Science and Technology Park of Crete 30 Saw Mill River Rd. P.O. Box 1385 (optional for express mail) M/S H2-C24 GR-71110 Heraklion Hawthorne, NY 10532 Greece USA E-mail: serpano@ics.forth.gr bisdik@watson.ibm.com Tel: +30-81-39 16 63 +1-914-784 7439 Fax: +30-81-39 16 01 +1-914-784 6219 IMPORTANT DATES: ---------------- Intention to submit: ASAP Manuscript submission: April 15, 1997 Acceptance notification: August 31, 1997 Final manuscript due: October 31, 1997 *******************************************************************************   Received: from cnri by ietf.org id aa07530; 5 Feb 97 9:49 EST Received: from newdev.harvard.edu by CNRI.Reston.VA.US id aa11624; 5 Feb 97 9:49 EST Received: from netop3.harvard.edu (netop3.harvard.edu [128.103.205.103]) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) with SMTP id JAA09039 for ; Wed, 5 Feb 1997 09:39:18 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by netop3.harvard.edu (8.6.12/8.6.12) with SMTP id JAA26594 for ; Wed, 5 Feb 1997 09:40:54 -0500 Received: from ietf.ietf.org by ietf.org id aa06828; 5 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: bmwg@harvard.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-lanswitch-03.txt Date: Wed, 05 Feb 1997 09:42:55 -0500 Sender: cclark@ietf.org Message-ID: <9702050942.aa06828@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Benchmarking Terminology for LAN Switching Devices Author(s) : B. Mandeville Filename : draft-ietf-bmwg-lanswitch-03.txt Pages : 11 Date : 02/04/1997 The purpose of this draft is to define and discuss benchmarking terminology for local area switching devices. It is meant to extend the terminology already defined for network interconnect devices in RFCs 1242 and 1944 by the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF) and prepare the way for a discussion on benchmarking methodology for local area switches. LAN switches are one of the principal sources of new bandwidth in the local area. The multiplicity of products brought to market makes it desirable to define a set of terms to be used when evaluating the performance characteristics of local area switching devices. Well-defined terminology will help in providing the user community with complete, reliable and comparable data on LAN switches. 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-bmwg-lanswitch-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-lanswitch-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-lanswitch-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970204111712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-lanswitch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-lanswitch-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970204111712.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11160; 5 Feb 97 10:20 EST Received: from ietf.ietf.org by ietf.org id aa06856; 5 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-fax@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-tiff-00.txt Date: Wed, 05 Feb 1997 09:42:59 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702050943.aa06856@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Tag Image File Format (TIFF) - Class F Author(s) : G. Parsons, J. Rafferty Filename : draft-ietf-fax-tiff-00.txt Pages : 18 Date : 02/04/1997 This document formalizes the reference for the Tag Image File Format (TIFF) and formally defines TIFF Class F that is used to store facsimile images. As well, the original registration for image/TIFF from RFC 1528 is refined by this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-tiff-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-fax-tiff-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-fax-tiff-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970204114103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-tiff-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-tiff-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970204114103.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11168; 5 Feb 97 10:20 EST Received: from ietf.ietf.org by ietf.org id aa06840; 5 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-goldsmith-utf7-01.txt Date: Wed, 05 Feb 1997 09:42:57 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702050942.aa06840@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Mail-Safe Transformation Format of Unicode Author(s) : D. Goldsmith, M. Davis Filename : draft-goldsmith-utf7-01.txt Pages : 12 Date : 02/04/1997 The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended) jointly define a character set (hereafter referred to as Unicode) which encompasses most of the world's writing systems. However, Internet mail (STD 11, RFC 822) currently supports only 7-bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extends Internet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither defines Unicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time. This document describes a transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641, "Using Unicode with MIME". 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-goldsmith-utf7-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-goldsmith-utf7-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-goldsmith-utf7-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970204113645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-goldsmith-utf7-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-goldsmith-utf7-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970204113645.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11161; 5 Feb 97 10:20 EST Received: from ietf.ietf.org by ietf.org id aa06796; 5 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-maruyama-mapos-sonet-00.txt Date: Wed, 05 Feb 1997 09:42:49 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702050942.aa06796@ietf.org> --NextPart A New 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-00.txt Pages : 8 Date : 02/04/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-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-maruyama-mapos-sonet-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-maruyama-mapos-sonet-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970204105910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-maruyama-mapos-sonet-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-maruyama-mapos-sonet-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970204105910.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11159; 5 Feb 97 10:20 EST Received: from ietf.ietf.org by ietf.org id aa06812; 5 Feb 97 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-jensen-webdav-ext-00.txt Date: Wed, 05 Feb 1997 09:42:53 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702050942.aa06812@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions for Distributed Authoring and Versioning on the World Wide Web -- WEBDAV Author(s) : Y. Goland, J. Whitehead, A. Faizi, S. Carter, D. Jensen Filename : draft-jensen-webdav-ext-00.txt Pages : 48 Date : 02/04/1997 WEBDAV (Web Distributed Authoring and Version control) specifies a set of methods and content-types ancillary to HTTP/1.1 for the management of resource meta-data, simple name space manipulation, simple resource locking (collision avoidance) and resource version control. 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-jensen-webdav-ext-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-jensen-webdav-ext-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-jensen-webdav-ext-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970204111158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jensen-webdav-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jensen-webdav-ext-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970204111158.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa24276; 5 Feb 97 12:06 EST Received: from zephyr.isi.edu by ietf.org id aa23354; 5 Feb 97 11:58 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 5 Feb 1997 08:56:27 -0800 Message-Id: <199702051656.AA18929@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2104 on HMAC Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Feb 97 08:56:26 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2104: Title: HMAC: Keyed-Hashing for Message Authentication Author: H. Krawczyk, M. Bellare, R. Canetti Date: February 1997 Mailbox: hugo@watson.ibm.com, mihir@cs.ucsd.edu, canetti@watson.ibm.com Pages: 11 Characters: 22297 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2104.txt This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This document is the product of the IP Security Protocol Working Group of the IETF. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970205085222.RFC@ISI.EDU> SEND /rfc/rfc2104.txt --OtherAccess Content-Type: Message/External-body; name="rfc2104.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970205085222.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa24278; 5 Feb 97 12:06 EST Received: from zephyr.isi.edu by ietf.org id aa23123; 5 Feb 97 11:52 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 5 Feb 1997 08:49:48 -0800 Message-Id: <199702051649.AA18149@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2085 on HMAC-MD5 Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Feb 97 08:49:48 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2085: Title: HMAC-MD5 IP Authentication with Replay Prevention Author: M. Oehler, R. Glenn Date: February 1997 Mailbox: mjo@tycho.ncsc.mil, rob.glenn@nist.gov Pages: 6 Characters: 13399 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2104.txt This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. This document is the product of the IP Security Protocol 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@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970205084222.RFC@ISI.EDU> SEND /rfc/rfc2104.txt --OtherAccess Content-Type: Message/External-body; name="rfc2104.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970205084222.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05088; 6 Feb 97 13:43 EST Received: from cnri by ietf.org id aa04064; 6 Feb 97 13:27 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17999; 6 Feb 97 13:27 EST Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-26) id ; Thu, 6 Feb 1997 10:24:54 -0800 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 TAA00293 ; Thu, 6 Feb 1997 19:23:02 +0100 (MET) Received: from Niel.prism.uvsq.fr (niel.prism.uvsq.fr [193.51.25.169]) by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id TAA01784 for ; Thu, 6 Feb 1997 19:02:04 +0100 (MET) Message-Id: <1.5.4.32.19970206175746.006a021c@guillotin.prism.uvsq.fr> X-Sender: iccc@guillotin.prism.uvsq.fr (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 06 Feb 1997 18:57:46 +0100 To: congres@prism.uvsq.fr Sender:ietf-request@ietf.org From: ICCC'97 Subject: ICCC'97 Source-Info: From (or Sender) name not authenticated. Announcement and Call for Papers International Conference for Computer Communications - ICCC'97 THEME: "Keys to a mature information society" November 19-21, 1997 Cannes, France The 13th biennal international conference organized by the International Council for Computer Communications. AIMS The conference aims is to provide an integrated perspective and a timely spectrum of computer and communications technologies in the context of present and future applications. TOPICS NEW TECHNOLOGIES Internetworking, Mobile Communications, Personal Wireless Communications, High Performance Computing, ATM, Broadband Networks, Architecture and Protocols NEW APPLICATIONS Desktop Video Conferencing, Broadband Applications e.g. Telemedicine, Telecommuting, Distance learning, Video on Demand, Multimedia, Electronic Commerce NEW SERVICES Intelligent Networks, Network Management, Virtual networks TRENDS AND STRATEGIES Information Highway, Information Filtering, Data Warehouse/Data Mining Security/ Privacy/ Legal Issues, User Acceptance/Billing, Commercialising Information POLICY AND GOVERNMENTAL ISSUES Information & communications policy, Control/Censorship Of Information, Deregulation/Liberalisation, Security/Privacy/Legal Issues, Role Of Government TARGET PARTICIPANTS Academics, accountants, advisors, auditors, consultants, doctors, engineers, investors, lawyers, planners, managers, policy makers, practitioners, researchers, scientists and others interested in communications and computer networks. CONFERENCE FORMAT The conference will last three days, November 19-21, 1977. Tutorials will be offered on November 17-18. LOCATION Cannes, a major mediterranean city on the French Riviera. SPONSORS ICCC (International Council for Computer Communications) and IFIP-TC.6 (International Federation of Information Processing, Technical Committee on Data Communications) ORGANIZER Telecom Valley, with the support of CNET (Centre National d'Etudes des T=E9l=E9communications), EURECOM, INRIA (Institut National de Recherche en Informatique et Automatique) Organizing Committee A. Andr=E9 (TV) E. Bibal (TV) P Conruyt (FT-DGSA) C. Gueguen (EURECOM) C. Juncker (INRIA) F. Jutand (CNET) T. Laurent (TV) G. Leb=E8gue (TV) L. Pouzin (ICCC) CONFERENCE CHAIR Samir Tohm=E9 (F) ENST 46 rue Barrault, 75634 Paris Cedex 13, France PROGRAMME CHAIR Guy Pujolle (F) Lab. PRiSM, University of Versailles 45 avenue des Etats-Unis, 78 035 Versailles Cedex, France PROGRAMME COMMITTEE J. Arnbak, Delft Technical Univ. (NL) F. Bar, Stanford Univ. (USA) C. Blondia, University of Antwerp (B) P. Brown, France Telecom - CNET (F) K. Boyanov, CICT (BG) A. Casaca, INESC (P) O. Casals, Universitat Politecnica de Catalunya (SP) P. Chemouil, France Telecom - CNET (F) S. J. Chung, ETRI (KR) J-P. Coudreuse, Mitsubishi (F) W. Dabbous, INRIA (F) Dang. N'Guyen, ENSTB (F) S. Fdida, University Paris VI (F) L. Fratta, Politecnico di Milano (I) D. Gaiti, Technical University of Troyes (F) C. Galand, IBM (F) N.D. Georganas, University of Ottawa (CA) A. Gravey, France Telecom - CNET (F) G. Hebuterne, INT (F) T. Housley, Housley Computer Communications (AU) C. Huitema, Bellcore (USA) P. Humblet, EURECOM (F) P. Jackson, Qualcomm (USA) F. Kamoun, ENSI (TU) M. Kato, Xerox (J) J. Kella, NET (IL) D. Khakhar, Lunds Univ. (S) P. K=FChn, Stuttgart Univ. (D) R. Kung, France Telecom - CNET (F) J. Labetoulle, EURECOM (F) J-Y. Le Boudec, EPFL (SW) O. Martikainen, Telecom Finland (FI) N. Naffah, Sabre Group (F) H. Perros, NCSU, (USA) S. Ramani, National Center for Software Technology (IN) J. Roberts, France Telecom - CNET (F) P. Rolin, ENSTB (F) O. Spaniol, Aachen Technical Univ. (D) E. Stefferud, NMA, USA Y. Takahashi, Aist-Nara (J) L. Tarouco, Univ. Federale de Rio Grande del Sul (BR) F. Tobagi, Stanford University (USA) C. Wellekens, EURECOM (F) KEY DATES IN 1997 * April 1st, papers received * June 1st, papers accepted /rejected * Sep 1st, papers received in camera ready form * Nov 17-18, Tutorials * Nov 19-21, ICCC'97 SUBMISSION OF PAPERS Paper can be submitted by mail or email * by mail: submit five copies of a full paper by April 1st, 1997 to ICCC97 Conference Lab PRiSM - University of Versailles 45 av. des Etats-Unis 78035 Versailles Cedex - France fax +33 (0) 139 254 057 http://www.prism.uvsq.fr * by email: poscript version of the paper to be sent to:= ICCC97@prism.uvsq.fr Papers are invited on the conference theme and related topics. Authors must state that their paper have neither been published before nor currently being submitted elsewhere. Full papers should be no longer than 15 pages, including tables, diagrams and pictures. The font size must be 12 points or larger. The cover page must contain an abstract of about 150 words, name and affiliation of author(s) as well as the lead author's postal address, telephone number, fax number and e-mail. Papers will be evaluated on the basis of relevance, originality and clarity. To ensure acceptance of high quality papers, each paper will be double and blind refereed. Accepted papers will be included in the conference proceedings and will be distributed to the attendees at the conference. The language of the conference is English and papers must be in this= language. For more information, fill and return the following form: ICCC97 Conference 905, rue Albert Einstein BP 261 06 921 Sophia Antipolis Cedex France ---------------------------------------------------------------------------- -------------- ICCC'97 1st Name: ...........................Last Name:...................................... email:...................................................................... ......... Title:...................................................................... ......... Organization:............................................................... ......... Postal address:....................................................................= .. ............................................................................ .......... City:.......................................Postal code:.............................. Country:.................................................................... .......... Telephone:.................................................................. ........... Fax:........................................................................ ........... Topics I am interested in : ........................................................... O Topics I am interested in :........................................................... O I wish to attend the ICCC=9297 conference. O I wish to present a paper and will submit a paper by Apil 15, 1997.=20 Title of the paper : ................................................................... ............................................................................ ............ ............................................................................ ............ _____________________________________________________________________ _____________________________________________________________________   Received: from ietf.org by ietf.org id aa10326; 6 Feb 97 16:22 EST Received: from nacho.cisco.com by ietf.org id aa10105; 6 Feb 97 16:16 EST Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id NAA06751 for ; Thu, 6 Feb 1997 13:14:30 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id NAA02503 for ; Thu, 6 Feb 1997 13:14:27 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Feb 1997 13:12:03 -0800 To: ietf@ietf.org Sender:ietf-request@ietf.org From: Fred Baker Subject: Re: IETF Nominations Committee Report Source-Info: From (or Sender) name not authenticated. I want to thank Geoff Huston for the work of the Nominating Committee in selecting new Area Directors. I would like also to thank our three outgoing Area Directors for their efforts over the past several years. These Area Directors are: Frank Kastenholz Internet Deirdre Kostick Network Management Allison Mankin Transport & IPNG The new IESG, effective the evening of 4/10/96, will therefore be: Fred Baker IETF Chair Harald Alvestrand Applications Keith Moore Applications Scott Bradner Transport Services Allyn Romanow Transport Services Jeffrey Burgan Internet Thomas Narten Internet Mike O'Dell Operations & Management John Curran Operations & Management Joyce K. Reynolds User Services Jeff Schiller Security Joel Halpern Routing Steve Coya IETF Executive Director The new IAB chair and an IAB liaison will also be members of the IESG. The IESG is acting to effect a smooth switchover, by adding Tom Narten and John Curran to its mailing list and by inviting them to join the IESG in its activities at the Memphis IETF prior to their installation. We expect that they and Scott Bradner will join the sitting Area Directors in their duties during that meeting. However, as the installation of new Area Directors occurs during the Thursday evening plenary meeting, they will not actually have that authority until Thursday, and the sitting Area Directors will be authoritative until Thursday evening. The merger of the Operations and Network Management areas will be effective as of the beginning of that meeting. For the duration of the meeting there will be three Area Directors: Mike O'Dell, Scott Bradner, and Deirdre Kostick. After the meeting ADs for the O&M area will be Mike O'Dell and John Curran.   Received: from ietf.org by ietf.org id aa15918; 6 Feb 97 20:13 EST Received: from zephyr.isi.edu by ietf.org id aa15007; 6 Feb 97 19:57 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 6 Feb 1997 16:55:00 -0800 Message-Id: <199702070055.AA01932@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2103 on Nimrod Mobility Support Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 06 Feb 97 16:55:00 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2103: Title: Mobility Support for Nimrod : Challenges and Solution Approaches Author: R. Ramanathan Date: February 1997 Mailbox: ramanath@bbn.com Pages: 17 Characters: 41352 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2103.txt This document discusses the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. This document identifies the requirements that Nimrod has of any solution for mobility support. It also classifies and compares existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, it outlines the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol. This document is the product of the New Internet Routing and Addressing Architecture Working Group of the IETF. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970206164646.RFC@ISI.EDU> SEND /rfc/rfc2103.txt --OtherAccess Content-Type: Message/External-body; name="rfc2103.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970206164646.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16364; 6 Feb 97 20:13 EST Received: from zephyr.isi.edu by ietf.org id aa16295; 6 Feb 97 20:13 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 6 Feb 1997 17:10:52 -0800 Message-Id: <199702070110.AA03063@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2107 on ATMP Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 06 Feb 97 17:10:52 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2107: Title: Ascend Tunnel Management Protocol - ATMP Author: K. Hamzeh Date: February 1997 Mailbox: kory@ascend.com Pages: 21 Characters: 44300 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2107.txt This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. IESG Note: This note documents a private protocol for tunnel management. This protocol is NOT the product of an IETF working group nor is it a standards track document. There is ongoing effort in an IETF working group which could result in a standards track document which specifies a protocol which provides similar functionality. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970206170646.RFC@ISI.EDU> SEND /rfc/rfc2107.txt --OtherAccess Content-Type: Message/External-body; name="rfc2107.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970206170646.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15914; 6 Feb 97 20:13 EST Received: from zephyr.isi.edu by ietf.org id aa15236; 6 Feb 97 20:04 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 6 Feb 1997 17:01:45 -0800 Message-Id: <199702070101.AA02468@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2106 on DLSRAP Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 06 Feb 97 17:01:45 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2106: Title: Data Link Switching Remote Access Protocol Author: S. Chiang, J. Lee, H. Yasuda Date: February 1997 Mailbox: schiang@cisco.com, jolee@cisco.com, yasuda@eme068.cow.melco.co.jp Pages: 19 Characters: 40819 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2106.txt This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970206165526.RFC@ISI.EDU> SEND /rfc/rfc2106.txt --OtherAccess Content-Type: Message/External-body; name="rfc2106.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970206165526.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04290; 7 Feb 97 6:37 EST Received: from cnri by ietf.org id aa03984; 7 Feb 97 6:35 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07652; 7 Feb 97 6:35 EST Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-26) id ; Fri, 7 Feb 1997 03:32:25 -0800 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 MAA20438 ; Fri, 7 Feb 1997 12:28:07 +0100 (MET) 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 MAA12390 ; Fri, 7 Feb 1997 12:11:20 +0100 (MET) Received: from paranoia.u-net.net (mail.u-net.net [194.119.128.80]) by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id MAA19857 ; Fri, 7 Feb 1997 12:10:48 +0100 (MET) Received: from sgml.u-net.com ([193.119.188.188]) by mail.u-net.net with SMTP id <1310037-25883>; Fri, 7 Feb 1997 11:05:29 +0000 Message-Id: <1.5.4.32.19970207110717.006b7b04@mail.u-net.com> X-Sender: mtbryan-sgml@mail.u-net.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Feb 1997 11:07:17 +0000 To: ICCC'97 , congres@prism.uvsq.fr Sender:ietf-request@ietf.org From: Martin Bryan Subject: Re: ICCC'97 Source-Info: From (or Sender) name not authenticated. At 18:57 6/2/97 +0100, ICCC'97 wrote: >FYI. Last year we were still talking about the emerging IS. >Now we are talking about the mature IS. 1998 - postmortem >on the IS? Surely senile dementia sets in before the postmortem! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/   Received: from ietf.org by ietf.org id aa08234; 7 Feb 97 8:49 EST Received: from cnri by ietf.org id aa07871; 7 Feb 97 8:44 EST Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa10089; 7 Feb 97 8:44 EST 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 OAA24635 ; Fri, 7 Feb 1997 14:41:31 +0100 (MET) 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 OAA15471 ; Fri, 7 Feb 1997 14:31:48 +0100 (MET) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id OAA24207 ; Fri, 7 Feb 1997 14:31:37 +0100 (MET) Received: by callandor.cybercash.com; id IAA10425; Fri, 7 Feb 1997 08:18:23 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma010418; Fri, 7 Feb 97 08:18:00 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA01622; Fri, 7 Feb 97 08:22:45 EST Date: Fri, 7 Feb 1997 08:22:44 -0500 (EST) Sender:ietf-request@ietf.org From: "Donald E. Eastlake 3rd" To: Martin Bryan , postmaster@prism.uvsq.fr, congres@prism.uvsq.fr Subject: PLEASE DELETE THIS MAILING LIST (Re: ICCC'97 (fwd)) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. It's bad enough that you were spamming everyone you could think of with the original message, which I got more than three copies of, now we has a damn coverstation being blasted out on a zillion mailing lists. Please stop this network abuse immeediately. Unsolicited mass email is not an appropriat way to advertise. Use web pages, appropriate news groups, and your own organizations mailing lists. Don't spam other mailing lists. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html ---------- Forwarded message ---------- Date: Fri, 07 Feb 1997 11:07:17 +0000 From: Martin Bryan To: ICCC'97 , congres@prism.uvsq.fr Subject: Re: ICCC'97 At 18:57 6/2/97 +0100, ICCC'97 wrote: >FYI. Last year we were still talking about the emerging IS. >Now we are talking about the mature IS. 1998 - postmortem >on the IS? Surely senile dementia sets in before the postmortem! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/   Received: from ietf.org by ietf.org id aa12816; 7 Feb 97 10:57 EST Received: from spinoza.terena.nl by ietf.org id aa12570; 7 Feb 97 10:49 EST Received: from [192.87.30.51] (PaulsMac.terena.nl [192.87.30.51]) by spinoza.terena.nl (8.7.6/8.7.3) with SMTP id QAA17471; Fri, 7 Feb 1997 16:46:51 +0100 (MET) X-Sender: paul@popper.terena.nl Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Feb 1997 16:51:10 +0200 To: terena-ga@terena.nl, wg-all@terena.nl, newsletters@terena.nl, ceec@terena.nl, ietf@ietf.org, ccirn@fnc.gov, apng-all@apng.org, jenc8-info@terena.nl, press@terena.nl, lhl@cs.wisc.edu, tf-atm@terena.nl, tf-cache@terena.nl, tf-chic@terena.nl, tf-etinu@terena.nl, tf-etm@terena.nl, tf-local@terena.nl, tf-ten@terena.nl, tf-tooldoc@terena.nl Sender:ietf-request@ietf.org From: Paul Rendek Subject: JENC8 "Preliminary Programme", May 12-15, 1997, Edinburgh, Scotland Source-Info: From (or Sender) name not authenticated. "8th Joint European Networking Conference" (JENC8) Edinburgh, Scotland, 12-15 May 1997 "Diversity and Integration: The New European Networking Landscape" The JENC8 "PRELIMINARY PROGRAMME" and general conference information is now available via the Web. Please visit the JENC8 conference Web site for further information at: http://www.terena.nl/jenc8/ For conference registration enquiries please send an email to For general enquiries please send an email to or contact: TERENA Secretariat Singel 466-468 NL - 1017 AW Amsterdam The Netherlands Tel: +31 20 639 1131 Fax: +31 20 639 3289 Email: jenc8-sec@TERENA.nl   Received: from ietf.org by ietf.org id aa15425; 7 Feb 97 12:21 EST Received: from ietf.ietf.org by ietf.org id aa15212; 7 Feb 97 12:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: srv-location@tgv.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-ipv6-01.txt Date: Fri, 07 Feb 1997 12:19:09 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702071219.aa15212@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 : Service Location Modifications for IPv6 Author(s) : J. Veizades, E. Guttman Filename : draft-ietf-svrloc-ipv6-01.txt Pages : 5 Date : 02/05/1997 The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network administration. The Service Location Protocol is well defined for use over IPv4 networks [SLP]: This document defines its use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. 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-ipv6-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-ipv6-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-ipv6-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970207094357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-ipv6-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970207094357.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15427; 7 Feb 97 12:21 EST Received: from ietf.ietf.org by ietf.org id aa15231; 7 Feb 97 12:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ospf@gated.cornell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-version2-10.txt Date: Fri, 07 Feb 1997 12:19:15 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702071219.aa15231@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 Version 2 Author(s) : J. Moy Filename : draft-ietf-ospf-version2-10.txt Pages : 226 Date : 02/05/1997 This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree. OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. Separate routes can be calculated for each IP Type of Service. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. The differences between this memo and RFC 1583 are explained in Appendix G. All differences are backward-compatible in nature. Implementations of this memo and of RFC 1583 will interoperate. Please send comments to ospf@gated.cornell.edu. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-version2-10.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-version2-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ospf-version2-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970207094347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-version2-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-version2-10.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970207094347.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15416; 7 Feb 97 12:21 EST Received: from ietf.ietf.org by ietf.org id aa14924; 7 Feb 97 12:08 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dns-security@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-update-04.txt Date: Fri, 07 Feb 1997 12:08:19 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702071208.aa14924@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Secure Domain Name System Dynamic Update Author(s) : D. Eastlake Filename : draft-ietf-dnssec-update-04.txt Pages : 13 Date : 02/05/1997 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services (draft-ietf-dnssec-secext-10.txt). DNS Dynamic Update operations have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed description of security for the update operation. This draft describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. [This version 04 draft differs from the previous version only in the deletion of a reference to the "in-key.int" domain from the introduction (and in having new dates and a new version number and this note).] 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-dnssec-update-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-update-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970207094337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-update-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-update-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970207094337.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19668; 7 Feb 97 13:16 EST Received: from ietf.ietf.org by ietf.org id aa19184; 7 Feb 97 13:11 EST To: IETF-Announce: ; Subject: IETF MAILING: INTRO: April 7-11, 1997 Date: Fri, 07 Feb 1997 13:11:48 -0500 Sender:ietf-announce-request@ietf.org From: Marcia Beaulieu Message-ID: <9702071311.aa19184@ietf.org> Dear IETFers: Following this message, you will receive two more regarding: REGISTRATION INFORMATION AT-A-GLANCE The following information is/will be available via the Web. Agenda At-A-Glance Registration Information Registration Form Miscellaneous: shipping information directions public transportation WG and BOF Agendas Tao: Guide for New Attendees WWW ----- Click on the link for "meetings" and you will find an entry for the Memphis meeting. The following information is available via the remote directories: Agenda At-A-Glance Registration Information Registration Form Tao: Guide for New Attendees Travel Directions FTP ----- IETF Information is available by anonymous FTP from several sites. US East Coast Address: ds.internic.net (198.49.45.10) US West Coast Address: ftp.isi.edu (128.9.0.32) Europe Address: nic.nordu.net (192.36.148.17) Pacific Rim Address: munnari.oz.au (128.250.1.21) cd ietf ls *0mtg*   Received: from ietf.org by ietf.org id aa19886; 7 Feb 97 13:18 EST Received: from ietf.ietf.org by ietf.org id aa19640; 7 Feb 97 13:16 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ietf-rsvp@ietf.org Subject: IETF MAILING: REGISTRATION INFORMATION: April 7-11, 1997 Date: Fri, 07 Feb 1997 13:16:18 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9702071316.aa19640@ietf.org> NEW ON-LINE REGISTRATION AND PAYMENT PROCEDURE A New On-line Registration Procedure is now in effect, along with a New Payment Schedule - Please Take Note! Due to the increased number of attendees at IETF meetings, automating the registration process has become a priority for the Secretariat. In doing so, we have created an On-line Registration Form, accessible via the IETF Web Home Page, making it easy and simple for you to register on-line! Simply fill out the On-line Registration form completely and click on the "Submit" button at the bottom of the page. If you forgot to fill out a certain section, you will immediately receive a reply asking for that information and you may re-submit your form. Please be sure that all information you provide is correct! You will then see an acknowledgement page on your browser listing the information you just provided. If you need to make a change, please contact the IETF Registrar at: ietf-rsvp@ietf.org. Your registration/confirmation number will come to you via e-mail, which you should receive within 24 hours of submitting your registration form. Please be sure to use this number for any future correspondence regarding your registration. The e-mail message will list your options for payment - 1) reply e-mail using PGP, 2) print & fax, 3) print & mail ( additional on-line options are planned for the future). You may choose whichever option is most convenient for you. NOTE: Your payment of US$250 must be RECEIVED by the cut-off date of 28 March 1997 in order for you to qualify for the lower registration fee. If your payment is Not Received by the cut-off date, the fee will increase to US$290 and must be paid on-site. PLEASE BE SURE TO NOTE THIS NEW PAYMENT SCHEDULE! If you are unable to access our Home Page on the Web, or if you have any questions regarding the new registration/payment procedure, please contact the IETF Registrar at: ietf-rsvp@ietf.org.   Received: from ietf.org by ietf.org id aa20380; 7 Feb 97 13:24 EST Received: from ietf.ietf.org by ietf.org id aa20266; 7 Feb 97 13:21 EST To: IETF-Announce: ; Subject: IETF MAILING: AT-A-GLANCE: April 7-11, 1997 Date: Fri, 07 Feb 1997 13:21:45 -0500 Sender:ietf-announce-request@ietf.org From: Marcia Beaulieu Message-ID: <9702071321.aa20266@ietf.org> 38th INTERNET ENGINEERING TASK FORCE Mailing Date: February 7, 1997 AT-A-GLANCE DATES: April 7-11, 1997 HOST: Keith Johnson Federal Express Corporation HOTEL/MEETING SITE: The Peabody Memphis 149 Union Avenue Memphis, TN 38103 Phone: 1 (901) 529-4000 or 1 (800) 732-2639 {fax: 1 (901) 529-9600} CI 1600; CO 11:00 325 Rooms reserved until Wednesday, March 5, 1997. US$119.00/single; US$129.00/double (please add 13.25% tax). Specify: 38th IETF Group Cancellations must be made 48 hours prior to the day of arrival in order to avoid being charged the deposit. ADDITIONAL ACCOM: TBD NEWCOMER'S Sunday, April 6, 1997 ORIENTATION: 15:30 - 16:30 The Peabody Memphis Room: Venetian Room PRE-REGISTRATION: Sunday, April 6, 1997 17:00 - 19:00 (reception) The Peabody Memphis Room: Continental Ballroom REGISTRATION: Monday, April 7, 1997 and BREAKS 08:00 - 18:00 Tuesday, April 8 - Thursday, April 10, 1997 08:30 - 18:00 Friday, April 11, 1997 08:30 - 12:00 The Peaboy Memphis Room: Memphis Foyer TERMINAL ROOM: Forest Room REGISTRATION FEE: Your payment of US$250 must be RECEIVED by the cut-off date of 28 March 1997 in order for you to qualify for the lower registration fee. If your payment is Not Received by the cut-off date, the fee will increase to US$290 and must be paid on-site. AIRPORT: Memphis International PARKING: The current charge for parking is $6.00 (self parking) or $9.00 (valet parking) - this is subject to change without notice. SHUTTLE: TBD   Received: from ietf.org by ietf.org id aa26016; 7 Feb 97 14:56 EST Received: from ietf.ietf.org by ietf.org id aa25828; 7 Feb 97 14:50 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ietf-rsvp@ietf.org Subject: IETF MAILING: REGISTRATION INFORMATION: CORRECTED Date: Fri, 07 Feb 1997 14:50:33 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9702071450.aa25828@ietf.org> This is a corrected version of the Registration Information. The previous message did not contain the URL necessary to register on-line.......sorry about that! New On-line Registration & Payment Procedure A New On-line Registration Procedure is now in effect, along with a New Payment Schedule - Please Take Note! Due to the increased number of attendees at IETF meetings, automating the registration process has become a priority for the Secretariat. In doing so, we have created an On-line Registration Form, accessible via the IETF Web Home Page, making it easy and simple for you to register on-line! Simply fill out the On-line Registration form completely and click on the "Submit" button at the bottom of the page. If you forgot to fill out a certain section, you will immediately receive a reply asking for that information and you may re-submit your form. Please be sure that all information you provide is correct! You will then see an acknowledgement page on your browser listing the information you just provided. If you need to make a change, please contact the IETF Registrar at: ietf-rsvp@ietf.org. Your registration/confirmation number will come to you via e-mail, which you should receive within 24 hours of submitting your registration form. Please be sure to use this number for any future correspondence regarding your registration. The e-mail message will list your options for payment - 1) reply e-mail using PGP, 2) print & fax, 3) print & mail ( additional on-line options are planned for the future). You may choose whichever option is most convenient for you. NOTE: Your payment of US$250 must be RECEIVED by the cut-off date of 28 March 1997 in order for you to qualify for the lower registration fee. If your payment is Not Received by the cut-off date, the fee will increase to US$290 and must be paid on-site. PLEASE BE SURE TO NOTE THIS NEW PAYMENT SCHEDULE! You can view the Memphis Meeting home page at: http://www.ietf.org/meetings/Memphis.html The URL for the on-line registration form is: http://www.ietf.org/meetings/reg_form.html If you are unable to access our Home Page on the Web, or if you have any questions regarding the new registration/payment procedure, please contact the IETF Registrar at: ietf-rsvp@ietf.org.   Received: from ietf.org by ietf.org id aa13445; 10 Feb 97 3:30 EST Received: from nw.com by ietf.org id aa12822; 10 Feb 97 3:10 EST Received: (mkl@localhost) by nw.com (8.6.12/8.6.5) id AAA15838; Mon, 10 Feb 1997 00:07:33 -0800 Date: Mon, 10 Feb 97 0:07:33 PST Sender:ietf-request@ietf.org From: Mark Lottor To: ietf@ietf.org Cc: namedroppers@internic.net Subject: Internet Domain Survey, Jan 97 Message-ID: Source-Info: From (or Sender) name not authenticated. Internet Domain Survey Network Wizards January 1997 The Domain Survey attempts to discover every host on the Internet by doing a complete search of the Domain Name System. The latest results gathered during late January 1997 are listed. For more information see RFC 1296; for more data see the zone directory on ftp.nw.com, or http://nw.com. -- Mark Lottor Number of Hosts and Domains advertised in the Domain Name System Replied Date | Hosts Domains ToPing* ------+--------------------------------- Jan 97| 16,146,000 828,000 3,392,000 Jul 96| 12,881,000 488,000 2,569,000 Jan 96| 9,472,000 240,000 1,682,000 Jul 95| 6,642,000 120,000 1,149,000 Jan 95| 4,852,000 71,000 970,000 Jul 94| 3,212,000 46,000 707,000 Jan 94| 2,217,000 30,000 576,000 Jul 93| 1,776,000 26,000 464,000 Jan 93| 1,313,000 21,000 [* estimated by pinging 1% of all hosts] Host Distribution by Top-Level Domain Name [see ftp.nw.com, zone/iso-country-codes to decode names] 3965417 com 26077 pt 807 kz 132 sv 15 cu 2654129 edu 25200 my 751 pa 122 uz 12 bz 1548575 net 19739 cn 601 lb 122 mu 10 mn 734406 jp 19094 su 590 ec 122 gu 9 bj 721847 de 15925 gr 572 mt 101 fo 7 vu 655128 mil 15885 cl 531 ni 98 aw 7 to 603325 ca 14051 si 511 pk 97 md 7 gp 591624 uk 13194 tr 477 ma 82 pr 7 aq 587175 us 12688 ar 457 sm 79 al 6 je 514760 au 11667 is 430 bo 78 gi 6 im 387280 gov 9591 id 408 hn 75 fj 6 cf 313204 org 9245 th 349 lk 73 nf 6 az 283526 fi 9148 ee 285 ir 69 sn 5 vn 270521 nl 9054 co 284 mk 60 np 5 va 245501 fr 8392 sk 274 gt 58 ai 5 tg 232955 se 8205 ro 273 ke 55 dm 5 sb 171686 no 6966 ua 262 na 52 gy 5 ne 149595 it 5192 pe 255 by 46 an 5 gg 129114 ch 4883 hr 249 jm 39 tn 4 sr 110041 es 4062 lv 226 sz 39 gb 4 ng 106476 dk 3653 bg 219 mc 38 fm 3 tz 99284 za 3628 ph 215 gl 37 ba 2 ye 91938 at 3506 lu 213 li 33 mv 2 kn 84532 nz 3491 cr 210 ge 31 mz 2 gn 77148 br 3138 in 206 bn 28 dz 2 ao 66262 kr 2920 kw 203 gh 27 mg 1 zr 64607 be 2723 yu 202 ci 27 gf 1 rw 54455 pl 2417 ve 195 bs 25 pf 1 pg 50097 ru 2301 do 187 py 24 bw 1 ls 49162 hk 1980 int 179 mo 23 nc 1 er 41164 cz 1823 uy 176 zw 21 qa 1 ck 38494 il 1802 ae 175 am 21 lc 1 cg 34650 tw 1775 lt 173 zm 21 bb 1 bi 29919 hu 1615 eg 170 ad 20 ky 1 bf 29840 mx 1481 cy 169 ag 18 vi 28892 sg 1274 bm 141 tt 17 ug 27059 ie 841 bh 140 jo 15 ml Top 100 Host Names 408382 www 3517 test 2553 mercury 1990 pc21 1688 mac2 66093 host 3259 pop 2550 proxy 1958 web 1678 beta 60798 mail 3236 pc4 2525 pc7 1957 pc22 1675 pc28 54782 ftp 3231 cisco 2484 pc14 1913 pc23 1650 ppp7 44289 ns 3134 venus 2417 pc8 1867 pc24 1636 pc 11993 ns1 2990 pc10 2358 pc15 1867 iris 1634 dns1 11863 router 2955 pc5 2300 pc16 1837 ppp5 1618 pc29 10226 ns2 2850 zeus 2298 ppp3 1827 mac 1599 ppp11 9912 user 2848 pc11 2287 pc9 1821 broadcas 1577 ppp12 9312 news 2841 mars 2216 pc17 1815 pc25 1570 hermes 6630 mailhost 2834 gate 2205 saturn 1810 apollo 1560 server1 6596 gw 2809 ppp1 2200 pc18 1804 neptune 1553 pc30 6520 www2 2798 pluto 2145 pc19 1799 eagle 1549 ppp8 5855 gateway 2759 pc12 2124 pc20 1759 pc26 1548 ppp13 5585 dns 2729 jupiter 2112 admin 1740 ws1 1538 demo 5255 smtp 2709 home 2103 orion 1735 ppp6 1534 relay 4586 server 2680 pc6 2088 www1 1714 pc27 1528 ppp14 4475 pc1 2662 alpha 2038 ppp4 1710 ppp10 1515 ws2 4047 pc2 2618 pc13 1993 mac1 1707 gopher 1503 ppp15 3579 pc3 2598 ppp2 1993 bbs 1690 gatekeep 1501 newton   Received: from ietf.org by ietf.org id aa22345; 10 Feb 97 10:53 EST Received: from cnri by ietf.org id aa21986; 10 Feb 97 10:46 EST Received: from cinna.ultra.net by CNRI.Reston.VA.US id aa12361; 10 Feb 97 10:46 EST Received: from techno (techno.musys.com [199.190.178.75]) by cinna.ultra.net (8.8.5/ult1.04) with SMTP id KAA06558 for ; Mon, 10 Feb 1997 10:44:19 -0500 (EST) Received: by techno (5.0/SMI-SVR4) id AA21024; Mon, 10 Feb 97 10:44:17 EST Date: Mon, 10 Feb 97 10:44:17 EST Sender:ietf-request@ietf.org From: "Gaylord K. Miyata" Message-Id: <9702101544.AA21024@techno> To: ietf@CNRI.Reston.VA.US Subject: per minute charges for internet (dialup) service? X-Sun-Charset: US-ASCII Source-Info: From (or Sender) name not authenticated. a friend in the American Bar Assoc. forwarded me the following this morning. I snipped the mail headers. Basically, local phone cos. filed a proposal w/ the FCC to impose per minute charges for internet service. FCC is fielding comments at isp@fcc.gov. Anyone hear about this? - gaylord ----- Begin Included Message ----- > > For your information and whatever action you think appropriate. > > ********************** > > On Fri, 7 Feb 1997 17:21:16 -0700 (MST) Marshall Morrise wrote: > >I received message below from an unknown parth. I don't know if it is > >accurate. But if it is true, it is worth acting on. > >----- > >I am forwarding this message to you to inform you of > >a very important matter currently under review by the > >FCC..... -------- Indeed it appears to be accurate. You might be interested in this article in the NYTimes at http://www.nytimes.com/library/cyber/week/020897fcc.html or in the FCC info at http://www.fcc.gov/isp.html . ----- End Included Message ----- ----- Begin Included Message ----- Just to follow up, this was what was on the FCC's web page. It is an NOI, meaning "Notice of Intent". The FCC is basically seeking comment on whether it should or should not allow the local telephone companies to charge access fees for ISPs. Ruth ------------------------------------------ Internet Access & Information Service Provider NOI The NOI seeks comment on whether the FCC should, in addition to access charge reform, consider actions relating to the implications of information service and Internet access provider usage of the public switched network. In particular, in light of concerns raised over congestion on the public switched network, the Commission seeks comment on how it can most effectively create incentives for the deployment of services and facilities to allow more efficient transport of data traffic to and from end users. The Commission made no specific proposals, but tentatively concluded that providers of information services (including Internet service providers) should not be subject to the interstate access charges that local telephone companies currently assess on long-distance carriers. ----- End Included Message ----- ----- Begin Included Message ----- On Fri, 7 Feb 1997 17:21:16 -0700 (MST) Marshall Morrise wrote: >All, > >I received message below from an unknown parth. I don't know if it is >accurate. But if it is true, it is worth acting on. > >Marshall > >----- >I am forwarding this message to you to inform you of >a very important matter currently under review by the >FCC. Your local telephone company has filed a proposal >with the FCC to impose per minute charges for your >internet service. > >They contend that your usage has or will hinder the >operation of the telephone network. It is my belief >that internet usage will diminish if users were >required to pay additional per minute charges. The >FCC has created an e-mail box for your comments, >responses must be received by February 13, 1997. > >Send your comments to isp@fcc.gov and tell them what >you think. Every phone company is in on this one, and >they are trying to sneak it in just under the wire >for litigation. Let everyone you know hear this one. >Get the e-mail address to everyone you can think of. > > isp@fcc.gov > >**** Please forward this email to all your friends on >the internet so all our voices may be heard! ----- End Included Message -----   Received: from ietf.org by ietf.org id aa26288; 10 Feb 97 12:22 EST Received: from ietf.ietf.org by ietf.org id aa25372; 10 Feb 97 11:53 EST To: IETF-Announce: ; cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: A Common Schema for the Internet White Pages Service to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Feb 1997 11:53:17 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702101153.aa25372@ietf.org> The IESG has received a request from the Integrated Directory Services Working Group to consider "A Common Schema for the Internet White Pages Service" 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@ietf.org or ietf@ietf.org mailing lists by February 24, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from ietf.org by ietf.org id aa06032; 11 Feb 97 10:17 EST Received: from ietf.ietf.org by ietf.org id aa03139; 11 Feb 97 9:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-bennett-00.txt Date: Tue, 11 Feb 1997 09:36:55 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110936.aa03139@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Telnet Remote Serial Port (RSP) Option Author(s) : M. Bennett Filename : draft-rfced-info-bennett-00.txt Pages : 5 Date : 02/10/1997 This document is a submission to the Internet Engineering Task Force (IETF) as an Internet draft standard. 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-bennett-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-bennett-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-bennett-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210114429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-bennett-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-bennett-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210114429.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06067; 11 Feb 97 10:17 EST Received: from ietf.ietf.org by ietf.org id aa03123; 11 Feb 97 9:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: frs-mib@newbridge.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-frnetmib-spvc-00.txt Date: Tue, 11 Feb 1997 09:36:49 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110936.aa03123@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Frame Relay Service MIB Working Group of the IETF. Title : Frame Relay Service Extensions MIB for Switched PVCs Author(s) : B. Coutts Filename : draft-ietf-frnetmib-spvc-00.txt Pages : 13 Date : 02/10/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 Switched Permanent Virtual Circuits (SPVCs) as extensions to RFC 1604 [1]. 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-frnetmib-spvc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-frnetmib-spvc-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-frnetmib-spvc-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210113820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-frnetmib-spvc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-frnetmib-spvc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210113820.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06076; 11 Feb 97 10:17 EST Received: from ietf.ietf.org by ietf.org id aa03075; 11 Feb 97 9:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-sheppard-00.txt Date: Tue, 11 Feb 1997 09:36:37 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110936.aa03075@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Electronic Part Catalog to Business System Interface Author(s) : S. Sheppard, S. Peoples Filename : draft-rfced-info-sheppard-00.txt Pages : 16 Date : 02/10/1997 This Internet-Draft specifies a standard method of transferring part and pick list information between dealer business systems (DBS) and electronics parts catalog (EPC) systems. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rfced-info-sheppard-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-sheppard-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-sheppard-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210111949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-sheppard-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-sheppard-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210111949.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06074; 11 Feb 97 10:18 EST Received: from ietf.ietf.org by ietf.org id aa03107; 11 Feb 97 9:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-ldapv3-dn-01.txt Date: Tue, 11 Feb 1997 09:36:47 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110936.aa03107@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names Author(s) : M. Wahl, S. Kille Filename : draft-ietf-asid-ldapv3-dn-01.txt Pages : 5 Date : 02/10/1997 The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight Directory Access Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-ldapv3-dn-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-dn-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-ldapv3-dn-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210113249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-ldapv3-dn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-ldapv3-dn-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210113249.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06065; 11 Feb 97 10:18 EST Received: from ietf.ietf.org by ietf.org id aa03188; 11 Feb 97 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-calendar@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cih-00.txt Date: Tue, 11 Feb 1997 09:37:02 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110937.aa03188@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 : Calendaring Interoperability over HTTP (CIH) Author(s) : S. Hanna Filename : draft-ietf-calsch-cih-00.txt Pages : 5 Date : 02/10/1997 Calendaring Interoperability over HTTP (CIH) is a technique for exchanging calendaring information between scheduling systems using the Hypertext Transfer Protocol (HTTP). This allows users to schedule meetings with anyone else, no matter what scheduling software they use. This document is a tentative exploration of whether CIH is feasible and what the pros and cons are relative to a brand new protocol like the Calendaring Interoperability Protocol (CIP). The primary benefit of CIH over CIP and motivation for this project is that we avoid implementing a whole new protocol, such as writing and debugging the protocol, convincing vendors to write new code to support it, and then convincing users to deploy 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-calsch-cih-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-cih-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cih-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210152015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cih-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cih-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210152015.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06064; 11 Feb 97 10:18 EST Received: from ietf.ietf.org by ietf.org id aa03155; 11 Feb 97 9:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gahrns-imap-referrals-01.txt Date: Tue, 11 Feb 1997 09:36:57 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110936.aa03155@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP4 Referrals Author(s) : M. Gahrns Filename : draft-gahrns-imap-referrals-01.txt Pages : 7 Date : 02/10/1997 When dealing with large amounts of users, messages and geographically dispersed IMAP4 [RFC-2060] servers, it is often desirable to distribute messages and users amongst different servers within an organization. For example an administrator may choose to store user's personal mailboxes on a local IMAP4 server, while storing shared mailboxes remotely on another server. This type of configuration is common when it is uneconomical to store all data centrally due to limited bandwidth or disk resources. By examining the REFERRALS response code in response to a SELECT command, a client can seamlessly access mailboxes distributed across several IMAP4 servers. Additionally, users may be frequently moved from one IMAP4 server to another because of hardware failures or organizational changes. By examining the REFERRAL response code at connection startup or in response to a LOGIN or AUTHENTICATE command, an IMAP4 client can transparently connect to an alternate IMAP4 server. A referral mechanism can provide efficiencies over the alternative "proxy method", in which the local IMAP4 server contacts the remote server on behalf of the client, and then transfers the data from the remote server to itself, and then on to the client. The referral mechanism's direct client connection to the remote server is often a more efficient use of bandwidth, and does not require the local server to impersonate the client when authenticating to the remote server. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gahrns-imap-referrals-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-referrals-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-gahrns-imap-referrals-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210115827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gahrns-imap-referrals-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-gahrns-imap-referrals-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210115827.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06036; 11 Feb 97 10:18 EST Received: from ietf.ietf.org by ietf.org id aa03039; 11 Feb 97 9:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: http-wg@cuckoo.hpl.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-http-negotiation-00.txt Date: Tue, 11 Feb 1997 09:36:31 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110936.aa03039@ietf.org> --NextPart A New 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 : Transparent Content Negotiation in HTTP Author(s) : K. Holtman, A. Mutz Filename : draft-ietf-http-negotiation-00.txt Pages : 35 Date : 02/10/1997 HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. 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-negotiation-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-negotiation-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-negotiation-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210110943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-negotiation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-http-negotiation-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210110943.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06055; 11 Feb 97 10:17 EST Received: from ietf.ietf.org by ietf.org id aa03205; 11 Feb 97 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-lyon-itp-nodes-01.txt Date: Tue, 11 Feb 1997 09:37:04 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110937.aa03205@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transaction Internet Protocol Author(s) : J. Lyon, K. Evans, J. Klein Filename : draft-lyon-itp-nodes-01.txt Pages : 17 Date : 02/10/1997 In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. 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-lyon-itp-nodes-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-lyon-itp-nodes-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-lyon-itp-nodes-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210173413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lyon-itp-nodes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-lyon-itp-nodes-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210173413.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06029; 11 Feb 97 10:18 EST Received: from ietf.ietf.org by ietf.org id aa03059; 11 Feb 97 9:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: http-wg@cuckoo.hpl.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-http-rvsa-v10-00.txt Date: Tue, 11 Feb 1997 09:36:34 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110936.aa03059@ietf.org> --NextPart A New 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 Remote Variant Selection Algorithm -- RVSA/1.0 Author(s) : K. Holtman, A. Mutz Filename : draft-ietf-http-rvsa-v10-00.txt Pages : 10 Date : 02/10/1997 HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. 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-rvsa-v10-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-rvsa-v10-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-rvsa-v10-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210111335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-rvsa-v10-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-http-rvsa-v10-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210111335.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06068; 11 Feb 97 10:18 EST Received: from ietf.ietf.org by ietf.org id aa03091; 11 Feb 97 9:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-ldap-domains-01.txt Date: Tue, 11 Feb 1997 09:36:45 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702110936.aa03091@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 : An Approach for Using Domains in LDAP Distinguished Names Author(s) : S. Kille, M. Wahl Filename : draft-ietf-asid-ldap-domains-01.txt Pages : 4 Date : 02/10/1997 The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible distinguished names for providing unique identification of entries. distinguished names in currently-deployed X.500 directories have the properties that they are descriptive, hierarchical, and follow common organizational models. However, there is not today a registration mechanism to permit individuals and organizations to obtain distinguished names, regardless of their physical location. This document defines a mechanism by which a name registered with the Internet Domain Name Service [1], for which there are active registration services, can be represented as a distinguished name so that it may be used with the LDAP protocol. This is not intended to have LDAP replace the DNS protocol, but to permit further deployment of LDAP into organizations connected to the Internet. This algorithm automatically assigns a distinguished name to any enterprise which has obtained a domain name for use in the Internet. This distinguished name may be used as a prefix for their names of entries in that enterprise. This document does not define how to represent objects which do not have domain names. Several RFCs, such as [3] and [4], and more recent documents provide additional guidance on representing and structuring information in these entries. Nor does this document define the procedure to locate an enterprises' LDAP directory server, given their domain name. Such as procedure may be defined in future RFCs. 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-ldap-domains-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-domains-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-ldap-domains-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210112737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-ldap-domains-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-ldap-domains-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210112737.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15294; 11 Feb 97 12:17 EST Received: from ietf.ietf.org by ietf.org id aa14655; 11 Feb 97 12:06 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: dns-security@tis.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: Secure Domain Name System Dynamic Update to Proposed Standard Date: Tue, 11 Feb 1997 12:06:09 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702111206.aa14655@ietf.org> The IESG has approved the Internet-Draft "Secure Domain Name System Dynamic Update" as a Proposed Standard. This document is the product of the Domain Name System Security Working Group. The IESG contact person is Jeffrey Schiller. Technical Summary This document describes a protocol that when used in conjunction with Dynamic Update of DNS permits updates to be performed in a secure fashion. It describes two related mechanisms that offer different performance vs. security trade-offs to suit different environments. Working Group Summary The working group came to consensus on this document with little debate required. Protocol Quality This protocol was reviewed for the IESG by Jeffrey I. Schiller, Security AD. It appears to be competent and appropriate for the task at hand.   Received: from ietf.org by ietf.org id aa15493; 11 Feb 97 12:21 EST Received: from ietf.ietf.org by ietf.org id aa15352; 11 Feb 97 12:18 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: namedroppers@internic.net Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: Dynamic Updates in the Domain Name System (DNS UPDATE) to Proposed Standard Date: Tue, 11 Feb 1997 12:18:51 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702111218.aa15352@ietf.org> The IESG has approved the Internet-Draft "Dynamic Updates in the Domain Name System (DNS UPDATE)" as a Proposed Standard. This document is the product of the DNS IXFR, Notification, and Dynamic Update Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. Technical Summary The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File. Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the existence or nonexistence of a RRset, or the existence of a single RR. All prerequisites must be satisfied for update operations to take place. There are no data dependent error conditions defined after the prerequisites have been met. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Frank Kastenholz and Jeffrey Burgan of the IESG.   Received: from ietf.org by ietf.org id aa15719; 11 Feb 97 12:25 EST Received: from ietf.ietf.org by ietf.org id aa15607; 11 Feb 97 12:24 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Document Action: Issues affecting MARS Cluster Size to Informational Date: Tue, 11 Feb 1997 12:24:06 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702111224.aa15607@ietf.org> The IESG has reviewed the Internet-Draft "Issues affecting MARS Cluster Size" and recommends that it be published by the RFC Editor as an Informational RFC. This document is the product of the Internetworking Over NBMA Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan.   Received: from ietf.org by ietf.org id aa05936; 11 Feb 97 19:24 EST Received: from cnri by ietf.org id aa05774; 11 Feb 97 19:14 EST Received: from [130.192.2.16] by CNRI.Reston.VA.US id aa11700; 11 Feb 97 19:14 EST Received: from chiusella.polito.it.polito.it (chiusella.polito.it) by polito.it (PMDF V4.2-15 #3020) id <01IFAT7Q9E1SHSK0U1@polito.it>; Tue, 11 Feb 1997 18:50:33 GMT+1 Received: by chiusella.polito.it.polito.it (4.1/SMI-4.1) id AA12430; Tue, 11 Feb 97 18:50:24 +0100 Date: Tue, 11 Feb 1997 18:50:24 +0100 Sender:ietf-request@ietf.org From: Paolo Prinetto Subject: ETW'97: IEEE European Test Workshop - Remind To: ietf@CNRI.Reston.VA.US Errors-to: Rapalino@cclix1.polito.it Errors-to: Rapalino@cclix1.polito.it Message-id: <9702111750.AA12430@chiusella.polito.it.polito.it> X-Envelope-to: ietf@CNRI.Reston.VA.US Content-transfer-encoding: 7BIT Apparently-To: ietf@CNRI.Reston.VA.US Source-Info: From (or Sender) name not authenticated. Dear colleague, March 1st 1997, the submission deadline for ETW'97: IEEE European Test Workshop is approaching quickly. For your convenience we enclose the call for papers. The ETW'97 internet web page at http://www.polito.it/etw97/ includes updated registration information. We look forward to hearing from you soon. Best regards. Paolo Prinetto ................................................................................. ETW'97 IEEE European Test Workshop Cagliari (Grand Hotel Chia Laguna), Italy May 28 - 30, 1997 The IEEE European Test Workshop is a well-recognized forum for presenting and discussing trends and hot topics in the area of electronic circuit and system testing. The Workshop provides the ideal environment for cross-fertilizing industrial and academic experiences and needs. You are all invited to submit your contributions to ETW'97, which moves from Montpellier to another nice seaside resort in the Mediterranean area. The topics include but are not limited to: - Test Automation - DFT and BIST - ATPG and Fault Simulation - IDDQ Testing - ATE - Application-Driven System Test - Synthesis for Testability - Online Test - Defect Analysis - Mixed-Signal and Analog Testing - Test Quality and Test Economics. The program committee invites original presentations in these areas. Each submission should include a 50-word abstract and a list of keywords, and may be a full paper or an extended summary. Also identify a contact author and include a complete mailing address, phone number, fax number and E-mail address. Submitted materials may be included in an informal workshop compendium of papers. Best contributions will be selected for publication in a special issue of the Journal of Electronic Testing: Theory and Applications (JETTA), published by Kluwer. If you wish to submit a presentation, please observe the following deadlines: * Submission deadline: March 1, 1997 * Notification of acceptance: April 15, 1997 Submit paper proposals to: ETW'97 Secretariat Politecnico di Torino Dip. Automatica e Informatica Corso Duca degli Abruzzi, 24 I-10129 Torino Italy Phone: +39 11 564.7043 Fax: +39 11 564.7099 E-mail: etw97@polito.it For general information, contact: Paolo Prinetto Politecnico di Torino Dip. Automatica e Informatica Corso Duca degli Abruzzi, 24 I-10129 Torino Italy Phone: +39 11 564.7007 Fax: +39 11 564.7099 E-mail: paolo.prinetto@polito.it The ETW'97 is sponsored by the IEEE Computer Society Test Technology Technical Committee, in cooperation with the European group of the Test Technology Technical Committee (ETTTC). Daily flights connect most European airports to Cagliari. A shuttle service will be provided from Cagliari airport to the Grand Hotel Chia Laguna. For further information, please visit the ETW'97 internet web page at http://www.polito.it/etw97/ ------------------------------------------------------------------------ General Chair P. Prinetto Politecnico di Torino (Italy) General Co-Chair T. W. Williams IBM (USA) General Vice Chair J. Figueras University of Catalunya (Spain) Program Chair H. J. Wunderlich University of Siegen (Germany) Program Co-Chair B. Bennetts LogicVision Europe (United Kingdom) Finance Chair M. Sonza Reorda Politecnico di Torino (Italy) Local Arrangements Chair A. Benso Politecnico di Torino (Italy) Publicity Chair C. Landrault LIRMM (France) Program Committee E.J. Aas - Univ. of Trondheim (NL) K. Baker - Philips (NL) S. Barbagallo - Italtel (I) B. Becker - Univ. of Freiburg (D) G. Carlsson - Ericsson (S) M. Croft - Mentor Graphics (UK) B. Courtois - TIMA CMP (F) W. Daehn - SICAN GmbH (D) C. Ellingham - Synopsys (USA) J. Figueras - Univ. of Catalunya (E) H. Fujiwara - NAIST (J) C. Gauthron - Compass (F) S. Griep - Siemens (D) J. Hlavicka - Univ. of Czech (CZ) A. Hlawiczka - Univ. of Gliwice (PL) H. Kerkhoff - Univ. of Twente (NL) G. Krueger - SNI (D) C. Landrault - LIRMM (F) C. Lopez Barrio - Telefonica I+D (E) D. Medina - Italtel (I) H. Manhaeve - KIHWV (B) M. Nicolaidis - TIMA CMP (F) P. Olivo - Univ. di Ferrara (I) A. Paschalis - NCSR (GR) Z. Peng - Univ. of Linkoping (S) P. Prinetto - Politecnico di Torino (I) M. Renovell - LIRMM (F) R. Segers - Philips Semiconductors (NL) J.P. Teixeira - INESC (P) R. Ubar - Univ. of Tallinn (EE) R. Wagner - Bosch (D) T. W. Williams - IBM (USA) V. Yarmolik - Univ. of Minsk (BY) Y. Zorian - LogicVision (USA) .................................................................................   Received: from ietf.org by ietf.org id aa28146; 12 Feb 97 9:57 EST Received: from ietf.ietf.org by ietf.org id aa25836; 12 Feb 97 9:34 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: oncrpc-wg@sunroof.eng.sun.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-oncrpc-rpcsec_gss-02.txt Date: Wed, 12 Feb 1997 09:34:05 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702120934.aa25836@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ONC Remote Procedure Call Working Group of the IETF. Title : RPCSEC_GSS Protocol Specification Author(s) : M. Eisler, A. Chiu, L. Ling Filename : draft-ietf-oncrpc-rpcsec_gss-02.txt Pages : 20 Date : 02/10/1997 This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-oncrpc-rpcsec_gss-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-oncrpc-rpcsec_gss-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970210110329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-oncrpc-rpcsec_gss-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970210110329.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28145; 12 Feb 97 9:57 EST Received: from ietf.ietf.org by ietf.org id aa25904; 12 Feb 97 9:34 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: srv-location@tgv.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-discovery-00.txt Date: Wed, 12 Feb 1997 09:34:23 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702120934.aa25904@ietf.org> --NextPart A New 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 Filename : draft-ietf-svrloc-discovery-00.txt Pages : 3 Date : 02/11/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 located 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-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-discovery-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-discovery-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970211164936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-discovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-discovery-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970211164936.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28140; 12 Feb 97 9:57 EST Received: from ietf.ietf.org by ietf.org id aa25856; 12 Feb 97 9:34 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-syntax-02.txt Date: Wed, 12 Feb 1997 09:34:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702120934.aa25856@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-02.txt Pages : 7 Date : 02/11/1997 Uniform Resource Names (URNs) are intended to serve as persistent 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-syntax-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970211102211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-syntax-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-syntax-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970211102211.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28147; 12 Feb 97 9:57 EST Received: from ietf.ietf.org by ietf.org id aa25887; 12 Feb 97 9:34 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: srv-location@tgv.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-advertising-00.txt Date: Wed, 12 Feb 1997 09:34:20 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702120934.aa25887@ietf.org> --NextPart A New 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-00.txt Pages : 11 Date : 02/11/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-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-advertising-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-advertising-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970211165301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-advertising-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-advertising-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970211165301.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28142; 12 Feb 97 9:57 EST Received: from ietf.ietf.org by ietf.org id aa25867; 12 Feb 97 9:34 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: srv-location@tgv.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-wpyp-00.txt Date: Wed, 12 Feb 1997 09:34:17 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702120934.aa25867@ietf.org> --NextPart A New 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 : Defining White Pages and Yellow Pages Services Author(s) : R. Moats Filename : draft-ietf-svrloc-wpyp-00.txt Pages : 6 Date : 02/11/1997 Service scheme templates for several different "white" and "yellow" pages services are presented. 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-wpyp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-wpyp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-wpyp-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970211165511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-wpyp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-wpyp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970211165511.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09399; 12 Feb 97 12:59 EST Received: from zephyr.isi.edu by ietf.org id aa09144; 12 Feb 97 12:52 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 12 Feb 1997 09:50:01 -0800 Message-Id: <199702121750.AA28882@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2108 on 802.3 Repeater MIB using SMIv2 Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 12 Feb 97 09:50:01 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2108: Title: Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 Author: K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie Date: February 1997 Mailbox: kdegraaf@isd.3com.com, dromasca@madge.com, mcmaster@cisco.com, kzm@cisco.com Pages: 82 Characters: 166336 Updates/Obsoletes: 1516 URL: ftp://ds.internic.net/rfc/rfc2108.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 & 100 Mb/s Management," October 26, 1995. This document is a product of the IEEE 802.3 Hub MIB 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@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970212094534.RFC@ISI.EDU> SEND /rfc/rfc2108.txt --OtherAccess Content-Type: Message/External-body; name="rfc2108.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970212094534.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11007; 12 Feb 97 13:36 EST Received: from ietf.ietf.org by ietf.org id aa10886; 12 Feb 97 13:34 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 12 Feb 1997 13:34:10 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702121334.aa10886@ietf.org> The IESG has received a request to consider "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 12, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from ietf.org by ietf.org id aa24566; 12 Feb 97 17:29 EST Received: from ietf.ietf.org by ietf.org id aa21965; 12 Feb 97 17:02 EST To: IETF-Announce: ; Subject: WG ACTION: TCP Implementation (tcpimpl) Date: Wed, 12 Feb 1997 17:02:02 -0500 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9702121702.aa21965@ietf.org> A new working group has been formed in the Transport Area of the IETF. For additional information, contact the Area Directors or the WG Chair. TCP Implementation (tcpimpl) ---------------------------- Chair(s): Steve Alexander Vern Paxson Transport Area Director(s): Allison Mankin Allyn Romanow Area Advisor Allyson Romanow Mailing lists: General Discussion:tcp-impl@engr.sgi.com To Subscribe: majordomo@engr.sgi.com In Body: "subscribe tcp-impl" in the message body Archive: ftp://ftp.sgi.com/other/tcp-impl/mail.archive Description of Working Group: The objective of this group is to decide how to best address known problems in existing implementations of the current TCP standard(s) and practices. The overall goal is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. It is hoped that both performance and correctness issues can be resolved by making implementors aware of the problems and their solutions. In the long term, it is felt that this will provide a reduction in unnecessary traffic on the network, the rate of connection failures due to protocol errors, and load on network servers due to time spent processing both unsuccessful connections and retransmitted data. This will help to ensure the stability of the global Internet. Examples of detected problems: o TCPs that retransmit all unacknowledged data at a single time. This behavior greatly adds to Internet load, at a time when the network is already under stress. The combination can lead to congestion collapse. o TCPs that misinitialize the congestion window, leading to potentially enormous bursts of traffic when new connections begin. Such burstiness can greatly stress Internet routers. In the BOF, it was generally agreed that problems of this class need to be fixed. Scope: The scope of this group must be carefully defined in order to ensure timely progress. To this end, TCP issues that still remain areas of research are considered out of scope for the WG. For example new improvements in congestion control algorithms are not within the WG scope. The WG will solicit input from the End-To-End research group of the IRTF on questions of whether a TCP implementation issue is considered research. The major objectives of this group will be to : Produce a compilation of known problems and their solutions. This will raise awareness of these issues. Determine if any problems found are the result of ambiguities in the TCP specification. If necessary, produce a document which clarifies the specification. Catalog existing TCP test suites, diagnostic tools, testing organizations, and procedures that can be used by implementors to improve their code, and produce a document enumerating them. Goals and Milestones: Jan 97 Working group formation. Decide on document editors. Apr 97 First Internet-Draft of problems and fixes, and very rough first draft of catalogue of test suites. Apr 97 Define schedule for producing the test suite catalog Jul 97 Issue revised Internet-Draft documents. Sep 97 Cut-off for determining whether clarification document is needed. If necessary, have interim meeting to focus effort on clarification document. Dec 97 Submit Internet-Draft of problems and fixes to IESG for publication as an RFC. Dec 97 Submit Internet-Draft of test catalogue to IESG for publication as an RFC. Mar 98 Submit Internet-Draft clarifying RFCs 793, 1122, and 1323 to IESG for publication as an RFC. Mar 98 CLose WG down.   Received: from ietf.org by ietf.org id aa14085; 13 Feb 97 9:44 EST Received: from ietf.ietf.org by ietf.org id aa12899; 13 Feb 97 9:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mobile-ip@smallworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mobileip-pppconf-00.txt Date: Thu, 13 Feb 1997 09:23:17 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702130923.aa12899@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 Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IPv4 Configuration Option for PPP IPCP Author(s) : J. Solomon, S. Glass Filename : draft-ietf-mobileip-pppconf-00.txt Pages : 14 Date : 02/12/1997 By strict interpretation of Mobile IP [RFC 2002] and PPP [RFC 1661] it is impossible for a mobile node to use anything but a co-located care-of address when using PPP, even if the PPP peer is capable of performing the Foreign Agent functions specified by Mobile IP. This document defines the Mobile IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332] which allows two PPP peers to negotiate the proper use of Mobile IP within the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. 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-mobileip-pppconf-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-pppconf-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-pppconf-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970212171233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-pppconf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-pppconf-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970212171233.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa24915; 13 Feb 97 11:04 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17637; 13 Feb 97 11:04 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Thu, 13 Feb 1997 13:57:33 GMT Message-Id: <199702131357.IAA20026@gza-client1.cam.ov.com> To: cat-ietf@mit.edu Cc: linn@cam.ov.com Subject: CAT Internet-Draft stati? Date: Thu, 13 Feb 1997 08:57:27 -0500 From: John Linn Precedence: bulk Current and/or prospective document editors I would appreciate it if anyone planning to submit new or updated CAT-WG Internet-Drafts in advance of the April IETF meeting could make this known, along with approximate anticipated submission date, for planning purposes. Thanks, regards, ... --jl   Received: from cnri by ietf.org id aa25883; 13 Feb 97 11:29 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa19620; 13 Feb 97 11:29 EST Received: by hosaka (SMI-8.6/SMI-SVR4) id JAA16828; Thu, 13 Feb 1997 09:06:23 -0600 Received: from ietf.org by hosaka (SMI-8.6/SMI-SVR4) id JAA16801; Thu, 13 Feb 1997 09:05:49 -0600 Received: from ietf.ietf.org by ietf.org id aa12850; 13 Feb 97 9:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, ietf.org@hosaka.smallworks.com MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US cc: mobile-ip@hosaka.smallworks.com From: Internet-Drafts@ietf.org Subject: (mobile-ip) I-D ACTION:draft-ietf-mobileip-tunnel-reverse-01.txt Date: Thu, 13 Feb 1997 09:23:10 -0500 Message-ID: <9702130923.aa12850@ietf.org> Sender: owner-mobile-ip@hosaka.smallworks.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Reverse Tunneling for Mobile IP Author(s) : G. Montenegro Filename : draft-ietf-mobileip-tunnel-reverse-01.txt Pages : 16 Date : 02/12/1997 Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign net, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. 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-mobileip-tunnel-reverse-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-tunnel-reverse-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-tunnel-reverse-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970212155312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-tunnel-reverse-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-tunnel-reverse-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970212155312.I-D@ietf.org> --OtherAccess-- --NextPart-- ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from cnri by ietf.org id aa04245; 13 Feb 97 14:55 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07900; 13 Feb 97 14:55 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Thu, 13 Feb 1997 18:05:45 GMT Message-Id: <9702131757.AA06601@us1rmc.bb.dec.com> Date: Thu, 13 Feb 97 12:57:45 EST From: "John Wray, Digital DPE, (508) 486-5210 13-Feb-1997 1207" To: "cat-ietf@mit.edu"@in.enet.dec.com Cc: wray@tuxedo.enet.dec.com Apparently-To: cat-ietf@mit.edu Subject: GSSv2 C-bindings Precedence: bulk I'm working on the next draft of the C-bindings document, and have currently incorporated all the changes from the San Jose meeting except for the following item from John's minutes, which was flagged as requiring further E-mail discussion: #3: Remove gss_str_to_oid(), gss_oid_to_str() and gss_release_oid(). The rationale for removing these routines concerns the definition of gss_release_oid(), which currently has to be able to recognize static OID values returned by GSSAPI and silently ignore attempts to free them. This was considered too much hassle for GSSAPI implementors. Since gss_str_to_oid() is the only way that GSSAPI can create an OID that doesn't have a value known at implementation time, if we remove this convenience routine, then OIDs can all be documented as being static constants (as in GSSv1), and therefore gss_release_oid() would not be needed, and the problem would go away. gss_oid_to_str() would be removed for symmetry, although it doesn't actually cause any problems. The concensus of the meeting was that this option was the best of the 7 we considered, but we felt we needed to allow comments from members of the list who couldn't attend the meeting. If anyone has a strong attachment to these routines, now is the time to say so :-) In addition to the above, there is a similar problem with gss_OID_set objects, but one that I don't think we can simply avoid. Currently, all gss_OID_set objects returned by GSSAPI are dynamic (heap-allocated, with the application responsible for calling gss_release_oid_set() to free them) with the exception of the one returned by gss_indicate_mechs, which the C bindings says the application must treat as read-only. This doesn't work well in GSSAPI implementations that support dynamic registration of new mechanisms. Now, it's possible for a GSSAPI implementation to actually return a pointer to an internally-maintained variable gss_OID_set, so there may be ways to work around this, although there are "interesting" locking issues if a new mechanism is being registered at the same time an application is looking at this OID_set, and if the number of mechanisms registered is larger than whatever space the GSSAPI implementation reserved for this set, then GSSAPI can't simply realloc a larger space, as applications may be holding a pointer to the old set. It also suffers from the same ugliness as the previous situation w.r.t. gss_OIDs in that the application must free OID_sets returned from GSSAPI with this one glaring exception. Do we want to do anything about this? There are two obvious possibilities: i) Change gss_indicate_mechs() to return a dynamic OID_set that the application must free. This is probably the cleanest solution in that it avoids multiple-access problems without complicating either the application or the GSSAPI implementor's jobs. However, it would introduce a memory leak in V1 apps that call this function. This may not be too bad, since I would expect a typical V1 application to call gss_indicate_mechs() at most once, and then use the returned set if mechanism-specific processing is required, so it wouldn't be a very severe leak for most apps. ii) Keep the indicate_mechs() OID_set as a non-freed object, and accept the problems with dynamic registration. This breaks down into two sub-options: iia) Keep the text in gss_release_oid_set that requires GSSAPI implementations to silently ignore attempts to free such sets. iib) Make the application responsible for knowing that gss_indicate_mechs' returned OID_set is special, and that it doesn't need to be freed. My own preference is to go for option (i) - sacrifice strict V1 compatibility (although in practice I doubt this will affect many applications) in exchange for getting a gss_inquire_mechs() that can cleanly support dynamic mechanism registration, as well as both a more uniform application-visible behavior and a simpler GSSAPI implementation. John   Received: from ietf.org by ietf.org id aa10363; 13 Feb 97 15:29 EST Received: from mail1.microsoft.com by ietf.org id aa08412; 13 Feb 97 15:18 EST Received: by mail1.microsoft.com with Internet Mail Service (5.0.1421.13) id <01BC1989.94A8DDC0@mail1.microsoft.com>; Thu, 13 Feb 1997 08:40:35 -0800 Message-ID: Sender:ietf-request@ietf.org From: "Marcel Wingate (Excell Data Corporation)" To: ietf@ietf.org Subject: RE: I-D ACTION:draft-rfced-info-ryckman-00.txt Date: Thu, 13 Feb 1997 08:41:46 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1421.13) Source-Info: From (or Sender) name not authenticated. If we're not able to see the encrytion algorithm code for ourselves, how can we trust that there isn't a back-door built in? It is my understanding that even with an algorithm, its not possible that some one could use it to reverse-engineer an encrypted message, document, etc. In fact, distributing the algorithm for wide professional scrutiny helps to make it stronger! Thank you, Marcel R. Wingate, MCSE Sr. Technical Support Lead Ph: (206) 703-1875 Microsoft Technical Support Group Fax: (206) 936-9158 > > Due to the required security of the data being transmitted, the > encryption > > algorithm used will only be released on a need to know basis to > software > > developers in the Alarm/Security Industry. A non-disclosure > agreement will > > be required. Terms and conditions of the licensing will depend on > the > > intended purpose for use and may require a non-competition agreement > or > > licensing fees. >   Received: from cnri by ietf.org id aa16453; 13 Feb 97 16:50 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa29410; 13 Feb 97 16:50 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Thu, 13 Feb 1997 20:28:11 GMT To: wray@tuxedo.enet.dec.com, cat-ietf@mit.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Re: GSSv2 C-bindings References: <9702131757.AA06601@us1rmc.bb.dec.com> From: Marc Horowitz Date: 13 Feb 1997 15:27:58 -0500 In-Reply-To: "John Wray, Digital DPE,'s message of Thu, 13 Feb 97 12:57:45 EST Message-Id: Lines: 13 X-Mailer: Gnus v5.3/Emacs 19.34 Precedence: bulk "John Wray, Digital DPE, (508) 486-5210 13-Feb-1997 1207" writes: >> My own preference is to go for option (i) - sacrifice strict V1 >> compatibility (although in practice I doubt this will affect many >> applications) in exchange for getting a gss_inquire_mechs() that >> can cleanly support dynamic mechanism registration, as well as both >> a more uniform application-visible behavior and a simpler GSSAPI >> implementation. This is my preference as well. If it is decided that total compatibility with v1 must be kept, I would prefer iib. Marc   Received: from cnri by ietf.org id aa19079; 13 Feb 97 19:44 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11326; 13 Feb 97 19:44 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Thu, 13 Feb 1997 23:24:14 GMT Message-Id: <199702132325.AA13675@sap-ag.de> From: Martin Rex Subject: Re: GSSv2 C-bindings To: John Wray Digital DPE Date: Thu, 13 Feb 1997 18:22:06 -0500 (EST) Cc: cat-ietf@mit.edu In-Reply-To: <9702131757.AA06601@us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Feb 13, 97 12:57:45 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk John Wray, Digital DPE, wrote: > ... which was flagged as requiring further E-mail discussion: > > #3: Remove gss_str_to_oid(), gss_oid_to_str() and gss_release_oid(). I would like to see them removed from the _spec_. For those who weren't in San Jose: Ted Ts'o (MIT) volunteered to supply a gss-api convenience library with these calls if someone really needs them badly. ;-) > > i) Change gss_indicate_mechs() to return a dynamic OID_set that the > application must free. This is probably the cleanest solution in that > it avoids multiple-access problems without complicating either the > application or the GSSAPI implementor's jobs. However, it would > introduce a memory leak in V1 apps that call this function. This may > not be too bad, since I would expect a typical V1 application to call > gss_indicate_mechs() at most once, and then use the returned set if > mechanism-specific processing is required, so it wouldn't be a very > severe leak for most apps. > > ii) Keep the indicate_mechs() OID_set as a non-freed object, and accept the > problems with dynamic registration. This breaks down into two sub-options: > > iia) Keep the text in gss_release_oid_set that requires GSSAPI implementations > to silently ignore attempts to free such sets. > > iib) Make the application responsible for knowing that gss_indicate_mechs' > returned OID_set is special, and that it doesn't need to be freed. How about (i) without explicitly "outlawing" (iia): Change gss_indicate_mechs() to return an OID_set that has to be passed to gss_release_oid_set() by the application. Don't call it dynamic or static, just require that gss_release_oid_set() must deal with it correctly. Why should we make a mechanism non-conforming when it returns a static oid_set that it correctly recognizes in gss_release_oid_set() ? The characteristics "static" "dynamic" and the "free()" activity should better be a local matter (i.e. implementation detail). -Martin   Received: from ietf.org by ietf.org id aa02034; 14 Feb 97 5:31 EST Received: from mersey.hursley.ibm.com by ietf.org id aa01936; 14 Feb 97 5:25 EST Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA54087; Fri, 14 Feb 1997 10:23:21 GMT Date: Fri, 14 Feb 1997 10:23:21 GMT Message-Id: <9702141023.AA54087@hursley.ibm.com> Sender:ietf-request@ietf.org From: "(Brian E Carpenter)" Subject: 1997/98 IAB membership To: ietf@ietf.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1941 Source-Info: From (or Sender) name not authenticated. IETF, I wish to thank Geoff Huston for the work of the Nominating Committee in selecting new IAB members. The four outgoing members are: J Allard Elise Gerich Yakov Rekhter Chris Weider I'd like specifically to thank Elise for her contributions to operational issues the IAB has dealt with, Chris for his contributions towards internationalization, and Yakov for his contributions on IP addressing and routing issues. Thanks are also due to Allison Mankin, who is leaving the the IESG, for being an effective liaison from the IESG to the IAB. The new IAB elects its chair annually upon taking office. The new IAB, effective the evening of April 10, 1997, will be: Nominated by NomCom and approved by ISOC: ========================================= Steve Bellovin * [US] Brian Carpenter * [UK] Jon Crowcroft * [UK] Steve Deering [US] Robert Elz * [AU] Tony Hain [US] Erik Huizer [NL] Cyndi Jung [US] John Klensin * [US] Bob Moskowitz [US] Charlie Perkins [US] Radia Perlman * [US] * term expires in Spring 1998. Others expire in Spring 1999. Others: ======= TBD (IESG liaison) Fred Baker (IETF chair) Jon Postel (IANA/RFC Editor) Abel Weinrib (Executive Director/IRTF Chair) Don Heath (ISOC liaison) For general information about the IAB, please see http://www.iab.org/iab You can send mail to the IAB at iab@isi.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) brian@hursley.ibm.com IBM United Kingdom Laboratories phone: +44 1962 816833 MP 185 fax: +44 1962 818101 Hursley Park Winchester Hampshire SO21 2JN, UK   Received: from ietf.org by ietf.org id aa04394; 14 Feb 97 7:47 EST Received: from cnri by ietf.org id aa04316; 14 Feb 97 7:44 EST Received: from www.ttz.co.at by CNRI.Reston.VA.US id aa03198; 14 Feb 97 7:44 EST Received: from Ulrich ([194.118.46.172]) by www.tirol.com (8.7.5/8.7.3) with SMTP id NAA24808; Fri, 14 Feb 1997 13:39:42 +0100 (MET) Received: by Ulrich Bachmann with Microsoft Mail id <01BC1A7C.9F1A5060@Ulrich Bachmann>; Fri, 14 Feb 1997 13:40:20 +0100 Message-ID: <01BC1A7C.9F1A5060@Ulrich Bachmann> Sender:ietf-request@ietf.org From: "u.bachmann" To: "'ALEPH1@UNDERGROUND.ORG'" , "'firewalls@GreatCircle.COM'" , "'ids@uow.edu.au'" , "'ieft-tls@w3.org'" , "'ietf@cnri.reston.va.us'" , "'lacc@suburbia.net'" To: "'sod@command.com.inter.net'" , "'www-security@ns2.Rutgers.EDU'" Subject: Security & Hackerscene update Date: Fri, 14 Feb 1997 13:38:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Recently new papers have been added to provide you with up-to-date information on Internet Security. URL of the "Security & Hackerscene" site: ----------------------------------------------------------------------------------------------------------- http://www.geocities.com/capecanaveral/3498/security.htm ----------------------------------------------------------------------------------------------------------- Some of the added items are: + TCP Port Stealth Scanning + Crash Course in X Windows Security + X Window System Security + Gettin A Handle On Internet Security + Remote Host Probing plus a new section called "CGI Security Compilation" which covers nearly every aspect of CGI Security. I would be glad to receive your feedback. Markus Huebner ===================================================================== E-Mail: matic@bau2.uibk.ac.at WWW: http://bau2.uibk.ac.at/matic Working as a freelance WEB-programmer and security-consultant.   Received: from cnri by ietf.org id aa08420; 14 Feb 97 11:13 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17689; 14 Feb 97 11:13 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Fri, 14 Feb 1997 14:30:41 GMT From: "Leap, Michael C TR" To: "'cat-ietf@MIT.EDU'" Subject: Unsubscribe Date: Fri, 14 Feb 97 09:38:00 EST Message-Id: <330476FE@trpo1.tr.unisys.com> Encoding: 2 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk unsubscribe cat-ietf   Received: from cnri by ietf.org id aa11436; 14 Feb 97 14:30 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03014; 14 Feb 97 14:30 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Fri, 14 Feb 1997 14:46:59 GMT Message-Id: <9702141435.AA07258@us1rmc.bb.dec.com> Date: Fri, 14 Feb 97 09:35:50 EST From: "John Wray, Digital DPE, (508) 486-5210 14-Feb-1997 0928" To: martin.rex@sap-ag.de Cc: "cat-ietf@mit.edu"@in.enet.dec.com, wray@tuxedo.enet.dec.com Apparently-To: cat-ietf@MIT.EDU, martin.rex@sap-ag.de Subject: Re: GSSv2 C-bindings Precedence: bulk >> >> i) Change gss_indicate_mechs() to return a dynamic OID_set that the >> application must free. This is probably the cleanest solution in that >> it avoids multiple-access problems without complicating either the >> application or the GSSAPI implementor's jobs. However, it would >> introduce a memory leak in V1 apps that call this function. This may >> not be too bad, since I would expect a typical V1 application to call >> gss_indicate_mechs() at most once, and then use the returned set if >> mechanism-specific processing is required, so it wouldn't be a very >> severe leak for most apps. >> >> ii) Keep the indicate_mechs() OID_set as a non-freed object, and accept the >> problems with dynamic registration. This breaks down into two sub-options: >> >> iia) Keep the text in gss_release_oid_set that requires GSSAPI implementations >> to silently ignore attempts to free such sets. >> >> iib) Make the application responsible for knowing that gss_indicate_mechs' >> returned OID_set is special, and that it doesn't need to be freed. > >How about (i) without explicitly "outlawing" (iia): > >Change gss_indicate_mechs() to return an OID_set that has to be passed >to gss_release_oid_set() by the application. Don't call it dynamic >or static, just require that gss_release_oid_set() must deal with it >correctly. Why should we make a mechanism non-conforming when it returns >a static oid_set that it correctly recognizes in gss_release_oid_set() ? > >The characteristics "static" "dynamic" and the "free()" activity should >better be a local matter (i.e. implementation detail). Yes, I like the sound of that. So the documentation for gss_indicate_mechs() should be changed to say that the application is responsible for invoking gss_release_oid_set() on the returned OID-set, but it would be perfectly permissible for an implementation to have gss_indicate_mechs() return a pointer to an internally-maintained constant OID-set if its gss_release_oid_set() can cope with that. That way, an implementation is only forced to incur the overhead of mallocing a fresh oid-set and copying if it supports dynamic mechanism registration (an implementation can, of course, choose to do this even if it doesn't support dynamic registration). John   Received: from ietf.org by ietf.org id aa13062; 14 Feb 97 16:10 EST Received: from box.nl by ietf.org id aa12590; 14 Feb 97 15:53 EST Received: from cs-gj3-a6.hro.nl (cs-gj2-a16.hro.nl [145.24.129.132]) by box.nl (8.7.5/8.6.9) with SMTP id VAA04613 for ; Fri, 14 Feb 1997 21:15:50 +0100 Date: Fri, 14 Feb 1997 21:15:50 +0100 Message-Id: <199702142015.VAA04613@box.nl> X-Sender: unit@box.nl X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: ietf@ietf.org Sender:ietf-request@ietf.org From: michael_roetto Subject: New Ideas for a WWW standard Source-Info: From (or Sender) name not authenticated. Please find below some preliminary suggestions for a new WWW standard. Hypertext version is available at http://www.box.nl/~unit/mike/prop.htm. I welcome all comments. Sincerely, Michael Roetto Proposal for a Language Standard for the World Wide Web (including standards adoption procedures) February 2, 1997 Michael B. Roetto Summary: Now that HTML 3.2 is finally upon us, I would like to put forth this alternative picture of a future web standard. Below is a series of observations and a limited a number of guidlines for possible solutions, including a framework for adopting future standards. The proposals in section 2 are intended as discussion points only, and are in no way= complete. Observations: 1) HTML is regularly used for purposes beyond its intended use 2) Markup is often irrelevant 3) HTML is now the only viable possibility for interactive, graphic layout over distributed networks (i.e. The WWW) 3a) Alternatives exist, but are incomplete. 4) A new standard is badly needed to fill this gap 5) Proposed HTML 3.2 will not meet this need. 5a) Conventional Standards Organizations not dynamic enough to provide timely solutions 5b) A streamlined RFC mechanism is needed 6) Solutions exclusive of HTML must be pursued 7) Standards implementation has been largely corrupted due to hyper-comptetion browser manufacturers 7a) Poor standards implementation hinders the development of quality content, as well mass-market acceptance of the WWW 8) Timely solutions are of high importance (see 5a,b)=20 Specific Proposals: The proposed standard language should: 1) stem from existing, often-used standards 2) be lay-user accessable 2a) have 'relaxed' syntax=20 3) include rigorous interactive,typographic, image, and layout controls 4) Must provide an HTML shell for compatibility and flexibility 5) Consensually agreed upon and adopted in a timely manner 6) Completely and purely adopted by ALL browser developers =A41 Observations =A41.1 HTML is regularly used for purposes beyond its intended use.=20 As a language, HTML was originally intended to indicate the logical structure of a text document, as well a providing facilities for hypertext. The development of HTML did not anticipate the appearance of graphical browsers, or the subsequent mass commercial interest they precipitated. With the arrival of graphical browsers, many Web pages and sites have become more a product of 'design' and less of 'markup'. This is a desirable trend and will encourage mass-market acceptance of the World Wide Web (see =A41.7a= ). =A41.2 Markup is often irrelevant In the large majority of situations traditional text-based markup has been replaced with graphical navigation schemes. This approach is often more attractive, as it offers the Web developer more flexibility, and the user a more intuitive system for accessing content. However, text markup is superior in certain cases: i.e., scientific and academic papers, technical documentation, etc. In these cases HTML provides an adequeate solution. (see =A42.5) =A41.3 HTML is now the only viable possibility for interactive, graphic layout over distributed networks (i.e. The WWW). Even though HTML was never intended as a layout language, is can nevertheless be forced to act as one through a number of indirect, imperfect and unreliable temporary solutions. Because of its accessability for the beginner, HTML is still favored for this task despite other possibilities. =A41.3a Alternatives exist, but are incomplete The major browsers now support either directly or in the form of a plug-in a number of page layout formats such as the Portable Document Format (PDF) or even raw Postscript. Despite their considerable advantages in placing type and graphics, they remain inadequate because of their meager support for hypertext and other interactive functions, when compared with HTML 3.0. =A41.4 A new standard is badly needed to fill this gap. Thus, it is easy to see that, considering the current and desirable trend towards graphical Web interfaces, a standard language that combines graphical support and interactive functionality is badly needed. (see =A42.3= ) =A41.5 Proposed HTML 3.2 will not meet this need. HTML 3.2, as proposed by the World Wide Web Consortium (W3C) will be inadequate, as it merely perpetuates text markup as a concept, largely ignoring needed typographic and image controls. =A41.5a Conventional Standards Organizations not dynamic enough to provide timely solutions Organizations such as the W3C, the American National Standards Institute (ANSI), the International Standards Organization (ISO) and the International Telecommunications Union (ITU), perhaps due to their publicly-supported linkage have become too sluggish to formulate standards in step with the rapid technological development in the computer industry.=20 =A41.5b Alternative standards adoption procedures must be implemented To establish a more dynamic standards adoption procedure, an RFC (Request for Comments) model is suggested. Compared with ISO and ANSI, the Internet Engineering Task Force (IETF) has established a remarkably efficient and democratic method of adopting new standards based around the RFC concept. If streamlined and modernized, this model is dynamic enough to accomodate rapid technological development. (thus stimulating new development) =A41.6 Solutions exclusive of HTML must be pursued As HTML is primarily a vehicle for text markup, and as markup in the large majority of cases is irrelevant, a language standard not based upon HTML must be sought. =A41.7 Standards implementation has been largely corrupted due to hyper-comptetion among browser manufacturers. Since the World Wide Web became a mass-media, mass-market sensation, growth has been enormous both in content and user traffic. Due to this unusually rapid growth, the competition between browser developers has been especially intense. Each developer, in their quest for the 'better browser' has not only added many proprietary additions to HTML, but also implemented HTML in an inconsistent and unpredictable manner. =A41.7a Poor standards implementation hinders the development of quality content, as well mass-market acceptance of the WWW Due to the fact that HTML implementation is inconsistent across different browser platforms, Web developers/designers have inadequate control of how their work is presented to the user. Thus, each developer must either concentrate on specific browser, or design for the 'lowest common denominator'. Both solutions are undesirable as the former would alienate a large percentage of the audience, and the latter prevents the development of creative and high-quality content. Without quality content, the Web will remain popular only within a vertical demographic; never realizing its mass-market potential. =A41.8 Timely solutions are of high importance (see =A41.5a,b) The development of the World Wide Web and its related technologies is extremely rapid, as it is a new form, and its possibilities not fully understood. Thus, a mechanism for adopting new standards and protocols in a timely fashion should be put in place without delay. =A42 Specific Proposals =A42.1 The language should stem from existing, often-used standards In order in minimize disruption in an already chaotic field, the new language should draw on existing standards: traditional programming languages, DTP description languages, and distributed languages such as Java and HTML. Not only should the new standard draw upon these languages, it should to some extent provide compatibility 'shells' for them. (see =A42.= 4) =A42.2 The language should be lay-user accessable The Web 'revolution' was partly aided by the fact that HTML can be learned by anyone in a relatively short time, without any previous knowledge of computer programming. Any new language should continue this trend. =A42.2a The language should have 'relaxed' syntax=20 The new standard should have relaxed and flexible syntax. Identifiers, variables, and strings should remain case-insensitive. Concepts similar to the 'friendly' color tags of HTML should be continued and extended. =A42.3 The language should include rigorous interactive,typographic, image, and layout controls To provide creative, quality content, web designers should have adequate control of image and text. The new standard could provide a number of image and text control without adding significant overhead in the browser. Image controls such as pixel-depth, rotation, and color tables should be available. Text control, while quite complete in HTML 3.0/3.2, should extended to provide most of the controls available in a DTP package. These could include kerning, justification, text flow, line spacing, and letter width. More importantly, the web designer should have pixel-level control of each of these elements. Quarck-style boxes could be one possibility. Imagine this syntax: imagebox: layer1 pos=3D50,50,100,100 content(logo.gif) depth=3D8 rotation=3D45=20 transp=3D80% ; textbox: layer 2 pos=3D75,75,125,125 content(test.txt,test.html) fsize=3D24 rotation=3D180 flow=3Dnone just=3Dful= l lspac=3D2=20 ; In this example upside down text would overlap a semi-transparent image in the upper-left corner of the screen. =A42.4 The language should provide an HTML shell for compatibility and= flexibility To provide compatibility with existing documents, the new standard language should have, among others, a HTML shell, or a way of calling HTML functions., just as the way C++ can call Pascal functions. Naturally, the new browser software must continue to provide a HTML interpreter.=20 =A42.5 The language should be consensually agreed upon and adopted in a= timely manner Considering the IETF's democratic model based on RFC's and working groups, the new language must be agreed upon in a similar manner. Only through including users and content-level developers will a workable standard be reached. Thus, past practice of adopting standards heavily influenced from browser developers is no longer valid. (see =A41.7, 1.7a) =A42.6 The language should be completely and purely adopted by ALL browser developers. Only if web-developers have a consistent set of tools upon which they can rely, will the quality of content on the WWW be increased. :::::::::::::::::::::::::::::::::::: Internet Design Unit http://www.box.nl/~unit/idu Personal Page: http://www.box.nl/~unit/mike ::::::::::::::::::::::::::::::::::::   Received: from ietf.org by ietf.org id aa15287; 14 Feb 97 18:04 EST Received: from m3.sprynet.com by ietf.org id aa14962; 14 Feb 97 17:50 EST Received: from jjones (host-159-49.UB.com [128.203.159.49]) by m3.sprynet.com (8.6.12/8.6.12) with SMTP id OAA03342; Fri, 14 Feb 1997 14:47:57 -0800 Message-ID: <3304EA8B.6ABA@sprynet.com> Date: Fri, 14 Feb 1997 17:43:23 -0500 Sender:ietf-request@ietf.org From: Jeff Jones Reply-To: jdjones@sprynet.com X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: michael_roetto CC: ietf@ietf.org Subject: Re: New Ideas for a WWW standard References: <199702142015.VAA04613@box.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. michael_roetto wrote: > > Please find below some preliminary suggestions for a new WWW standard. > Hypertext version is available at http://www.box.nl/~unit/mike/prop.htm. I > welcome all comments. > > Sincerely, > Michael Roetto Great idea! This same problem was faced in the programming world for Windows, as Pascal, C, and C++ vied for the "mainstream" language. The same was true with xBase and SQL for database programming. In the end, the market chose Visual Basic as the predominant programming language, and C++ for components (DLLs, OCXs, etc). SQL won the DB wars. The point of this is that the market determined the outcome. It would seem that the resolution of this idea would best be served by looking at the market today. ActiveX vs Java applets is but one example of competing technologies. My best suggestion is that a WebBasic standard be created encompassing and compatible with existing tools. For example, I can use VB4 to write my web pages, incorporating ActiveX. I can write Java applets in VB and convert them with Applet Designer. In short, VB4, and now VB5, provides a good starting definition, given its market domination, ease of use, and broad based usability. I would be interested in others opinions, but please spare me the ad hominums about Windows being terrible, or VB not being a language, and other myths. Obviously, any standard would have to be applied across many OSs, just as Sun's Java interpreters are today. Jeff Jones -- ===================================== "He is no fool who gives up what he cannot keep to gain that which he cannot lose." - Jim Elliot ===================================== jdjones@sprynet.com   Received: from ietf.org by ietf.org id aa17165; 14 Feb 97 19:16 EST Received: from bast.livingston.com by ietf.org id aa16766; 14 Feb 97 19:07 EST Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id QAA16701 for ; Fri, 14 Feb 1997 16:07:16 -0800 (PST) Received: (from megazone@localhost) by server.livingston.com (8.7.1/8.6.9) id QAA23231 for ietf@ietf.org; Fri, 14 Feb 1997 16:05:13 -0800 (PST) Message-Id: <199702150005.QAA23231@server.livingston.com> Subject: Re: New Ideas for a WWW standard (fwd) To: ietf@ietf.org Date: Fri, 14 Feb 1997 16:05:12 -0800 (PST) Sender:ietf-request@ietf.org From: MegaZone Precedence: special-delivery Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me. Content-Type: text Source-Info: From (or Sender) name not authenticated. Once upon a time Jeff Jones shaped the electrons to say... >> Hypertext version is available at http://www.box.nl/~unit/mike/prop.htm. I >> welcome all comments. >> Michael Roetto >Great idea! This same problem was faced in the programming world for I think it is a horrible idea. 1. HTML is fine. 2. He seems to have missed the fact that we already have CSS1 - which moots the presentation arguments. 3. We already have XML as a possible nexgen. 4. You'd have to be high to believe NS and M$ would convert to a new system. You *can* rely on HTML 3.2 to work consistently. If you don't use vendor tags you have no problem. And if you think a new system would eliminate vendor specific enhancements, you're nuts. CSS1 gives the control over presentation the proposal seems to be aiming at - MS and NS have committed to supporting the full recomendation. Even NS sees plugins dying as Java replaces them. You have HTML for the structural and minimal presentational markup. CSS1 for the fine control on presentation. And Java Applets for other needs. The *last* thing we need is some new system that tries to replace any or all of these. Right now it is hard enough to get the various vendors to all implement ONE spec properly. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com Snail mail: 4464 Willow Road, Pleasanton, CA 94588   Received: from ietf.org by ietf.org id aa19206; 14 Feb 97 20:41 EST Received: from egoshin.genesyslab.com by ietf.org id aa18643; 14 Feb 97 20:30 EST Received: (from egoshin@localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id RAA08391 for ietf@ietf.org; Fri, 14 Feb 1997 17:31:49 -0800 To: ietf@ietf.org Errors-To: egoshin@genesyslab.com Return-Receipt-To: egoshin@genesyslab.com Message-ID: Sender:ietf-request@ietf.org From: Leonid Yegoshin Date: Fri, 14 Feb 1997 17:31:49 -0800 (PST) Subject: Subscription Lines: 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Source-Info: From (or Sender) name not authenticated. Hi, Please subscribe me to IETF and IETF-Announce mail lists. Thank you, - Leonid Yegoshin, LY22   Received: from cnri by ietf.org id aa20635; 14 Feb 97 21:08 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01970; 14 Feb 97 21:08 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Fri, 14 Feb 1997 23:51:43 GMT Date: Fri, 14 Feb 1997 18:49:05 -0500 Message-Id: <9702142349.AA13313@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Marc Horowitz Cc: wray@tuxedo.enet.dec.com, cat-ietf@mit.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US In-Reply-To: Marc Horowitz's message of 13 Feb 1997 15:27:58 -0500, Subject: Re: GSSv2 C-bindings Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Marc Horowitz Date: 13 Feb 1997 15:27:58 -0500 >> My own preference is to go for option (i) - sacrifice strict V1 >> compatibility (although in practice I doubt this will affect many >> applications) in exchange for getting a gss_inquire_mechs() that >> can cleanly support dynamic mechanism registration, as well as both >> a more uniform application-visible behavior and a simpler GSSAPI >> implementation. This is my preference as well. If it is decided that total compatibility with v1 must be kept, I would prefer iib. I also think that allowing V1 applications to leak memory if they call gss_inquire_mechs() is OK. If there is a real problem ii(b) is probably be the best fallback. - Ted   Received: from cnri by ietf.org id aa21395; 14 Feb 97 21:54 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa04792; 14 Feb 97 21:54 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Fri, 14 Feb 1997 23:55:48 GMT Date: Fri, 14 Feb 1997 18:52:48 -0500 Message-Id: <9702142352.AA13325@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Marc Horowitz Cc: wray@tuxedo.enet.dec.com, cat-ietf@mit.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US In-Reply-To: Marc Horowitz's message of 13 Feb 1997 15:27:58 -0500, Subject: Re: GSSv2 C-bindings Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Marc Horowitz Date: 13 Feb 1997 15:27:58 -0500 >> My own preference is to go for option (i) - sacrifice strict V1 >> compatibility (although in practice I doubt this will affect many >> applications) in exchange for getting a gss_inquire_mechs() that >> can cleanly support dynamic mechanism registration, as well as both >> a more uniform application-visible behavior and a simpler GSSAPI >> implementation. This is my preference as well. If it is decided that total compatibility with v1 must be kept, I would prefer iib. I also think that allowing V1 applications to leak memory if they call gss_inquire_mechs() is OK. If there is a real problem ii(b) is probably be the best fallback. - Ted   Received: from ietf.org by ietf.org id aa29389; 15 Feb 97 0:05 EST Received: from m3.sprynet.com by ietf.org id aa29012; 14 Feb 97 23:55 EST Received: from jeffjones (host-205-152-197-23.atl.bellsouth.net [205.152.197.23]) by m3.sprynet.com (8.6.12/8.6.12) with ESMTP id UAA04996; Fri, 14 Feb 1997 20:51:45 -0800 Message-Id: <199702150451.UAA04996@m3.sprynet.com> Sender:ietf-request@ietf.org From: Jeff Jones To: ietf@ietf.org, MegaZone MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: New Ideas for a WWW standard (fwd) Date: Fri, 14 Feb 1997 23:52:50 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Thanks for the reply. And some excellent points. However, it is not just the technology that matters - there are financial and psychological considerations to make. For example, there is no doubt UNIX is a superior operating system than NT for both workstations and servers. Yet, UNIX is a dying technology and NT reigns supreme in the marketplace. Why? UNIX is the result of committees and concensus. NT is the result of private sector. What UNIX gives over NT is past the point of diminishing returns, and fails to capture the market. Likewise, some great technologies, like you have mentioned, are arguably the best way to go. Unless the market is convinced, it will not happen. While a team of programmers can use HTML 3.2, CGI, Java, and CSS1 on their UNIX system for months to build a web project, I or any good VB programmer can do the same project, with equivalent or better performance in just a few weeks. To the customer looking at the life cycle cost, the VB approach always wins. One must look beyond the technology to the intended result and resources. That is why I simply suggest that standardizing on MS's Basic syntax, or a reasonable facsimile, would provide the goal the original request had in mind. Perhaps selling MS, Sun, and Netscape on CSS1 would be another good idea. Jeff Jones ========================================== "He is no fool who gives up what he cannot keep to gain that which he cannot lose." - Jim Elliott ========================================== jdjones@sprynet.com ---------- > From: MegaZone > To: ietf@ietf.org > Subject: Re: New Ideas for a WWW standard (fwd) > Date: Friday, February 14, 1997 7:05 PM > > Once upon a time Jeff Jones shaped the electrons to say... > >> Hypertext version is available at http://www.box.nl/~unit/mike/prop.htm. I > >> welcome all comments. > >> Michael Roetto > >Great idea! This same problem was faced in the programming world for > > I think it is a horrible idea. > > 1. HTML is fine. > 2. He seems to have missed the fact that we already have CSS1 - which moots > the presentation arguments. > 3. We already have XML as a possible nexgen. > 4. You'd have to be high to believe NS and M$ would convert to a new system. > > You *can* rely on HTML 3.2 to work consistently. If you don't use vendor > tags you have no problem. And if you think a new system would eliminate > vendor specific enhancements, you're nuts. CSS1 gives the control over > presentation the proposal seems to be aiming at - MS and NS have committed > to supporting the full recomendation. > > Even NS sees plugins dying as Java replaces them. You have HTML for the > structural and minimal presentational markup. CSS1 for the fine control > on presentation. And Java Applets for other needs. > > The *last* thing we need is some new system that tries to replace any or > all of these. Right now it is hard enough to get the various vendors to > all implement ONE spec properly. > > -MZ > -- > Livingston Enterprises - Chair, Department of Interstitial Affairs > Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com > For support requests: support@livingston.com > Snail mail: 4464 Willow Road, Pleasanton, CA 94588   Received: from cnri by ietf.org id aa00320; 15 Feb 97 0:41 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06390; 15 Feb 97 0:41 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Sat, 15 Feb 1997 04:23:02 GMT From: Jacques Lebastard Message-Id: <9702140849.AA18688@ronde.frcl.bull.fr> Subject: Re: GSSv2 C-bindings To: John Wray Digital DPE Date: Fri, 14 Feb 1997 09:49:15 +0100 ("MET) Cc: cat-ietf@mit.edu In-Reply-To: <9702131757.AA06601@us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Feb 13, 97 12:57:45 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Precedence: bulk John and CAT members, > #3: Remove gss_str_to_oid(), gss_oid_to_str() and gss_release_oid(). > > The concensus of the meeting was that this option was the best of the 7 we > considered, but we felt we needed to allow comments from members of the list > who couldn't attend the meeting. If anyone has a strong attachment to these > routines, now is the time to say so :-) These convenience routines may be useful when GSS-API Version 2 are used in combination with the AccessControl and delegation extensions as defined in draft-ietf-cat-xgssapi-acc-cntrl-01.txt. The extended routines (used to implement the SESAME Security Mechanism) handle SecurityAttribute OID-typed objects. Though this internet draft defines a given set of security attribute type OIDs, the user may define additional Object Identifiers to identify his own Security Attribute. In such cases, gss_str_to_oid would be quite convenient to get the """ASN.1 BER encoding of the value portion of the normal BER TLV encoding of the gss_OID""". The gss_oid_to_str function may as well be convenient when used in conjunction with gss_inquire_cred/context to indicate to a user the (not well-known) type of a Security Attribute. In my own implementation of gss_release_oid, the routine deallocate storage associated with the gss_OID if it does not refer to a well known ObjectIdentifier ; a user may build a well-known OID (eg. GSS_C_NT_ANONYMOUS) using gss_str_to_oid and this non-static gss_OID will not be freed by gss_release_oid, but I reckon this implementation as a good compromise). Besides, there's a good reason to keep these three V2 specific routines in the C-bindings : they are defined in RFC 2078. > i) Change gss_indicate_mechs() to return a dynamic OID_set that the > application must free. This is probably the cleanest solution in that no objection to this solution. Hope this helps, -- Jacques LEBASTARD mailto:J.Lebastard@frcl.bull.fr BULL SA - ISM AccessMaster http://www-ism.bull.com/ism/ Rue Jean Jaures - A5/146 Tel: +33 (0)1 30 80 77 86 F-78340 Les Clayes sous Bois Fax: +33 (0)1 30 80 77 99   Received: from ietf.org by ietf.org id aa05346; 15 Feb 97 6:51 EST Received: from bast.livingston.com by ietf.org id aa04209; 15 Feb 97 6:18 EST Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id DAA01384 for ; Sat, 15 Feb 1997 03:17:12 -0800 (PST) Received: (from megazone@localhost) by server.livingston.com (8.7.1/8.6.9) id DAA22157 for ietf@ietf.org; Sat, 15 Feb 1997 03:15:08 -0800 (PST) Message-Id: <199702151115.DAA22157@server.livingston.com> Subject: Re: New Ideas for a WWW standard (fwd) To: ietf@ietf.org Date: Sat, 15 Feb 1997 03:15:08 -0800 (PST) Sender:ietf-request@ietf.org From: MegaZone Precedence: special-delivery Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me. Content-Type: text Source-Info: From (or Sender) name not authenticated. Once upon a time Jeff Jones shaped the electrons to say... >operating system than NT for both workstations and servers. Yet, UNIX is a >dying technology and NT reigns supreme in the marketplace. Why? UNIX is I hardly think it is dying. The UNIX base is growing. >convinced, it will not happen. While a team of programmers can use HTML >3.2, CGI, Java, and CSS1 on their UNIX system for months to build a web >project, I or any good VB programmer can do the same project, with >equivalent or better performance in just a few weeks. To the customer I completely disagree with this. First, HTML and CSS1 are cake - anyone should be able to use them with ease. And there are several good tools on the market - such as HoTMetaL PRO. Second, pick a language - let's say Perl - a skilled Perl programmer can create the same application just as fast as a silling VB programmer can do it in VB. And with Perl 5 there are literally hundreds of modules you can plug together like legos - it greatly reduces the coding time. And any full time webmaster is going to write their own Perl library to make life easier - then you just use your ready-made routines. Actually programming page content is a completely warped, completely terrible idea no matter what you use. It adds completely pointless overhead to the process that is not worth it. When you can mark up a file with HTML and Style Sheets, and MOST of the web is NOT dynamic content so this covers it, it doesn't make sense to turn to a more programatic syntax. >looking at the life cycle cost, the VB approach always wins. One must look That is flat out incorrect. It wins SOME of the time, NOTHING wins all of the time. VB doesn't even win most of the time. >beyond the technology to the intended result and resources. That is why I >simply suggest that standardizing on MS's Basic syntax, or a reasonable When you have a hammer, everything looks like a nail. You know VB, so you want to standardize on that. I know other Windows programmers who would say you're high and C++ is the way to go. My personal fave is Perl, followed by C. Someone else will say we're all obviously clueless and Java is the standard to use. >Perhaps selling MS, Sun, and Netscape on CSS1 would be another good idea. As I said, at least MS and NS have already committed to it. MSIE 3.x has a decent level of support, and MSIE 4.0 and NS 4.0 will supposedly support the entire spec. Sun/Java doesn't really enter into it, since applets control their area on their own. Though CSS1 can be used to position it, etc. For the various needs: HTML is for document structure, and some basic layout. CSS1 and following levels will provide increasing levels of fine presentational control. Server Side - define an interface and let people code what they like, THAT is the most efficient way. CGI is in need of an overhaul, FastCGI looks like an effective replacement. Client side - This is a weak spot. A real standardized scripting language would be welcome. To be practical I think that should be JavaScript as that is the one most widely used and more fully developed. If only MS would stop diluting their efforts wit VBScript and JS - and NS would make it an open spec instead of screwing with it at whim. If anything needs to be worked on, it is the client side scripting. Structure is well in hand and the future is bright, same for presentation. CGI and other server issues can be written in the most appropriate language for the task and platform - as I strongly feel it should be. Things are really just starting to congeal with the feature war in the browsers really calming down and MS and NS both publically stating that they will abide by the W3C recomendatins on things like HTML and Style Sheets. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com Snail mail: 4464 Willow Road, Pleasanton, CA 94588   Received: from ietf.org by ietf.org id aa05462; 15 Feb 97 6:51 EST Received: from bast.livingston.com by ietf.org id aa04590; 15 Feb 97 6:33 EST Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id DAA01530 for ; Sat, 15 Feb 1997 03:33:04 -0800 (PST) Received: (from megazone@localhost) by server.livingston.com (8.7.1/8.6.9) id DAA22669 for ietf@ietf.org; Sat, 15 Feb 1997 03:31:01 -0800 (PST) Message-Id: <199702151131.DAA22669@server.livingston.com> Subject: Re: New Ideas for a WWW standard (fwd) To: ietf@ietf.org Date: Sat, 15 Feb 1997 03:31:00 -0800 (PST) Sender:ietf-request@ietf.org From: MegaZone Precedence: special-delivery Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me. Content-Type: text Source-Info: From (or Sender) name not authenticated. Once upon a time michael_roetto shaped the electrons to say... >You seem to think that Web-design is mature medium with a history and It is not mature, but it isn't fledgling either. 5+ years is not overnight - that's how long I've been doing it. >are at the beginning of this new medium we should have an extensible >programming language in place; before we go any further.The central idea of Why? I do not see ANY need for a 'programming language' for web content. A standard client side scripting language would be nice, but aside from that: HTML *is* an extensible structural markup. CSS1 *is* an extensible presentational system. >HTML, markup, is no longer necessary, and wastes a lot of time. Having a I think this is bullshit. MOST of the content people need to put on the web is static. It is *simple* to use HTML and Style Sheets to mark it up and be done with it. Having to use a programming language would be a huge pain in the ass with no reason. >better language is of crucial importance if the Web is to be accepted by the >general public. I don't agree with this at all. First - Having instructed both, most people understand markup faster than they understand programmatical structurs. Second - The average person doesn't care to have a webpage, they use it as another information resource or entertainment venue. Third - There are already several fine tools that make generating a web page as simple as word processing a letter. I don't believe it is worth the effort, in fact, I think trying to change the system at this late a date is completely counter productive. I for one would certainly fight such an effort. But I'm not worried, I don't believe for a minute that NS and MSIE would change to a completely new system. Especially now that NS has a complete server suite based on HTML and related technolgies and MSIE is incorporating the technology right into the OS. You should have tried in 1993, before it would be a tremendous pain to even consider a change. Having read your page I fail to see any reasonable argument in it's favor. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com Snail mail: 4464 Willow Road, Pleasanton, CA 94588   Received: from ietf.org by ietf.org id aa09381; 15 Feb 97 10:56 EST Received: from m3.sprynet.com by ietf.org id aa08022; 15 Feb 97 9:43 EST Received: from jeffjones (host-205-152-197-27.atl.bellsouth.net [205.152.197.27]) by m3.sprynet.com (8.6.12/8.6.12) with ESMTP id GAA19860; Sat, 15 Feb 1997 06:39:46 -0800 Message-Id: <199702151439.GAA19860@m3.sprynet.com> Sender:ietf-request@ietf.org From: Jeff Jones To: ietf@ietf.org, MegaZone MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: New Ideas for a WWW standard (fwd) Date: Sat, 15 Feb 1997 09:40:52 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. > From MegaZone: > > I hardly think it is dying. The UNIX base is growing. As a share of the market in servers and workstations, the facts are otherwise. > >convinced, it will not happen. While a team of programmers can use HTML > >3.2, CGI, Java, and CSS1 on their UNIX system for months to build a web > >project, I or any good VB programmer can do the same project, with > >equivalent or better performance in just a few weeks. To the customer > > I completely disagree with this. I have no problem with you disagreeing. That is what an open forum is about. Unfortunately, I say this based on a past history of successfully doing this in the VB/Win32 world in competition with UNIX programmers and HTML/Java/CGI programmers. I doubt I am the only one capable of doing this. > > First, HTML and CSS1 are cake - anyone should be able to use them with ease. > And there are several good tools on the market - such as HoTMetaL PRO. Yes, there are. Especially the free ones or the shareware ones nobody is honest enough to pay for, like HoTMetaL. I use Frontpage in tandem with VB4. It is not the only solution, but it works for me, and I turn out my projects in less time that others with similar projects. > > Second, pick a language - let's say Perl - a skilled Perl programmer can > create the same application just as fast as a silling VB programmer can > do it in VB. And with Perl 5 there are literally hundreds of modules you > can plug together like legos - it greatly reduces the coding time. And any > full time webmaster is going to write their own Perl library to make life > easier - then you just use your ready-made routines. People should use what they want. My argument was in support of a standard, like HTML has a published standard today. How about a specified project, given to Perl & VB programmers to do, and a contest to judge the results based on quality and time to production? It would certainly generate some interest, given all the nasty-grams I get for even mentioning VB to "REAL" programmers. > > Actually programming page content is a completely warped, completely terrible > idea no matter what you use. It adds completely pointless overhead to > the process that is not worth it. When you can mark up a file with HTML > and Style Sheets, and MOST of the web is NOT dynamic content so this > covers it, it doesn't make sense to turn to a more programatic syntax. If you like HTML, Perl, FastCGI, then you must like some degree of overhead. Java is interpreted code, like VB4. Please keep in mind that I am not recommending VB4 as a substitute for a standard. I am merely pointing out that the success of a future standard is measured by how broadly it is adopted inside and outside of the techie world. The success of VB4, the wide audience for BASIC, and the methodology of how VB has incorporated other languages certainly provides a starting point for that standard. > > >looking at the life cycle cost, the VB approach always wins. One must look > > That is flat out incorrect. It wins SOME of the time, NOTHING wins all of > the time. VB doesn't even win most of the time. Then specify a scenario - perhaps in the contest above. Specify a real world system, with web server, database support, encryption, client side features, etc. Require a life cycle cost analysis in the contest. Then let's see. A lot of creative minds could tackle this with the religious fervor that seems to permeate the UNIX and NT faithful. My real world experience, competing against mini and mainframe systems, is that VB wins. Everytime it is tried. > > >beyond the technology to the intended result and resources. That is why I > >simply suggest that standardizing on MS's Basic syntax, or a reasonable > > When you have a hammer, everything looks like a nail. You know VB, so > you want to standardize on that. I know other Windows programmers who would > say you're high and C++ is the way to go. My personal fave is Perl, followed > by C. Someone else will say we're all obviously clueless and Java is the > standard to use. Actually, I have changed languages several times over the years to allow me to produce the best product I can for my customers. I started with machine code in the late 70's on Barber-Colman systems, then to Fortran IV and 77, then to xBase & Clipper in the DOS world, then to VB in the Windows world. C (and C++) are the ideal, but impractical for development unless you have a huge ROI that pays for it (as in major commercial applications or writing multi-platform operating systems). Hardly a Johnny-one-note in programming. The same holds true for my network design. I started with a slow serial net in the early 80s (Barber Colman), then on to Token Ring and Ethernet, to FDDI, Fast Ethernet, and gigabit Ethernet. I went from applying repeaters on thinnet to hubs and routers, to switches. From 300 baud dial up to ISDN, SMDS, and frame relay. I adopt the technology in any field that best suits the short and long term needs. > > >Perhaps selling MS, Sun, and Netscape on CSS1 would be another good idea. > > As I said, at least MS and NS have already committed to it. MSIE 3.x has > a decent level of support, and MSIE 4.0 and NS 4.0 will supposedly support > the entire spec. Sun/Java doesn't really enter into it, since applets > control their area on their own. Though CSS1 can be used to position it, etc. I wholeheartedly agree. > > For the various needs: > HTML is for document structure, and some basic layout. > > CSS1 and following levels will provide increasing levels of fine > presentational control. > > Server Side - define an interface and let people code what they like, THAT > is the most efficient way. CGI is in need of an overhaul, FastCGI looks > like an effective replacement. > > Client side - This is a weak spot. A real standardized scripting language > would be welcome. To be practical I think that should be JavaScript as that > is the one most widely used and more fully developed. If only MS would stop > diluting their efforts wit VBScript and JS - and NS would make it an open > spec instead of screwing with it at whim. > > If anything needs to be worked on, it is the client side scripting. > > Structure is well in hand and the future is bright, same for presentation. > CGI and other server issues can be written in the most appropriate language > for the task and platform - as I strongly feel it should be. > > Things are really just starting to congeal with the feature war in the > browsers really calming down and MS and NS both publically stating that > they will abide by the W3C recomendatins on things like HTML and Style > Sheets. > > -MZ I agree with this, also. I appreciate how you argue intelligently, and avoid the ad hominums that others have made in reply. I learn something new from each of your postings. Jeff Jones Remote Monitoring System Services Manager UB Networks CSMC Atlanta 888-80UBNET "ALLOPINONS EXPRESSED ARE MY OWN AND NOT NECESSARILY THOSE OF UB NETWORKS"   Received: from ietf.org by ietf.org id aa16017; 15 Feb 97 18:36 EST Received: from [207.211.135.2] by ietf.org id aa14920; 15 Feb 97 17:56 EST Received: from ct1-11.INTERCENTER.NET by hermod.pcinno.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1389.3) id 1HTLLF3Q; Sat, 15 Feb 1997 18:07:04 -0500 Received: by ct1-11.INTERCENTER.NET with Microsoft Mail id <01BC1B69.3A089BD0@ct1-11.INTERCENTER.NET>; Sat, 15 Feb 1997 17:54:01 -0500 Message-ID: <01BC1B69.3A089BD0@ct1-11.INTERCENTER.NET> Sender:ietf-request@ietf.org From: Michael Zappe To: "ietf@ietf.org" Cc: "'rothwell@cybergrafx.com'" Subject: RE: New Ideas for a WWW standard Date: Sat, 15 Feb 1997 17:54:00 -0500 Return-Receipt-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Source-Info: From (or Sender) name not authenticated. The discussion of a new standard for the web I find particularly = interesting. I have found that HTML is a very limited markup language, = and is very difficult to work with in some cases, especially when = creating documents for large sites and trying to provide dynamic = information. CGI is not a very good alternative. Trying to produce = HTML documents from within most structured languages is a great source = of frustrating errors ("Whoops... forgot to escape that quote, again!" = ;-) ). It can also be a difficult proposition to think in design terms = while you're embedding the design of the page inside of the program. =20 MegaZone earlier said that most of the content on the web right now is = static, and that is true, but we are moving towards having more and more = dynamic data present; just think about electronic commerce, where = dynamic data is necessary for any large retail site! Doing this in CGI = is a big pain! =20 Adding a programmatic structure to HTML, but leaving it in a markup = type syntax I find to be a great idea! Even static data could benefit = from such a structure. I was (previous to budget cuts) working on the = electronic textbook project at NC State, and producing a large textbook = in HTML was a tremendous pain. SGML has some great features to make it = easier, but writing a rendering engine for the DTDs for each type of = page to create HTML is a lot of redundant effort. So using what I = learned from this, and also helping to create an electronic commerce = site, I've found (and am currently implementing in the form of a = server-side scripting engine.) that adding programming features but = leaving a markup type syntax is a great solution for this. You also get = a flexibility, ease of use, and functionality superior to that of HTML, = CSS1 and CGI. Using the same markup structure used to define the = content to define the document structure, and including the rendering = procedures inside the definition, is also a great improvement over SGML = DTDs.=20 Until Later, Zapman -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Michael Zappe=20 Chief Programmer and CEO Magnus Software, Inc. Zapman@pcinno.com -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-   Received: from ietf.org by ietf.org id aa26884; 15 Feb 97 23:07 EST Received: from proxy2.ba.best.com by ietf.org id aa21685; 15 Feb 97 22:45 EST Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.5/8.8.3) with ESMTP id TAA01825 for ; Sat, 15 Feb 1997 19:42:28 -0800 (PST) Received: (from boo@localhost) by shellx.best.com (8.8.5/8.8.3) id TAA11637; Sat, 15 Feb 1997 19:42:16 -0800 (PST) Date: Sat, 15 Feb 1997 19:42:16 -0800 (PST) Message-Id: <199702160342.TAA11637@shellx.best.com> To: ietf@ietf.org X-URL: mailto:ietf@ietf.org X-Mailer: Lynx, Version 2.5FM Sender:ietf-request@ietf.org From: Walter Ian Kaye Subject: Re: New Ideas for a WWW standard (fwd) Source-Info: From (or Sender) name not authenticated. I hope this thread does not degenerate into a "my-language-is-better- than-your-language" interchange. I do have some constructive comments to add, though, so here they are... From Jeff Jones: >> From MegaZone: >> >> I hardly think it is dying. The UNIX base is growing. >As a share of the market in servers and workstations, the facts are >otherwise. You are comparing apples and oranges (base vs. market share). As long as SALES are growing, I hardly think "market share" matters. If you go ask Power Computing Corp if "declining Mac market share" means lower sales, they'll look at you like you've got two heads! Their sales have been growing at a delightful pace -- the MacOS market is strong indeed, and new MacOS-compatible manufacturers/licensees are popping up every day. "Market share" is of interest only to MBAs. >> >convinced, it will not happen. While a team of programmers can use HTML >> >3.2, CGI, Java, and CSS1 on their UNIX system for months to build a web >> >project, I or any good VB programmer can do the same project, with >> >equivalent or better performance in just a few weeks. To the customer >> >> I completely disagree with this. >I have no problem with you disagreeing. That is what an open forum is >about. Unfortunately, I say this based on a past history of successfully >doing this in the VB/Win32 world in competition with UNIX programmers and >HTML/Java/CGI programmers. What about in competition with Macintosh programmers? Great RAD tools here! >> Second, pick a language - let's say Perl - a skilled Perl programmer can >> create the same application just as fast as a silling VB programmer can Umm...what's a silling? :-) >> do it in VB. And with Perl 5 there are literally hundreds of modules you >> can plug together like legos - it greatly reduces the coding time. And >> any full time webmaster is going to write their own Perl library to make >> life easier - then you just use your ready-made routines. >People should use what they want. My argument was in support of a >standard, like HTML has a published standard today. How about a specified >project, given to Perl & VB programmers to do, and a contest to judge the >results based on quality and time to production? It would certainly >generate some interest, given all the nasty-grams I get for even mentioning >VB to "REAL" programmers. Include AppleScript and Frontier's UserTalk in that contest -- these are the scripting languages we use under MacOS ('course we've got MacPerl, too...). >> >looking at the life cycle cost, the VB approach always wins. One must >> >look >> That is flat out incorrect. It wins SOME of the time, NOTHING wins all >> of the time. VB doesn't even win most of the time. >Then specify a scenario - perhaps in the contest above. Specify a real >world system, with web server, database support, encryption, client side >features, etc. Require a life cycle cost analysis in the contest. Then >let's see. A lot of creative minds could tackle this with the religious >fervor that seems to permeate the UNIX and NT faithful. My real world >experience, competing against mini and mainframe systems, is that VB wins. >Everytime it is tried. But will it win against AppleScript, FaceSpan, and Frontier? We can do all the things you just listed, on the Mac; and we've got great tools with intuitive human interfaces (one of the Mac's great strengths). BTW, Frontier's language, UserTalk, has a syntax reminiscent of VB's "dot notation", so you might like it! (heck, it may even get a Win32 port...;) -Walter Frontier: FaceSpan: AppleScript: My AS page: Mac Scripting in general: __________________________________________________________________________ Walter Ian Kaye Programmer - Excel, AppleScript, Mountain View, CA ProTERM, FoxPro, HTML http://www.natural-innovations.com/ Musician - Guitarist, Songwriter   Received: from ietf.org by ietf.org id aa03316; 16 Feb 97 7:00 EST Received: from bast.livingston.com by ietf.org id aa03007; 16 Feb 97 6:49 EST Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id DAA19900 for ; Sun, 16 Feb 1997 03:48:03 -0800 (PST) Received: (from megazone@localhost) by server.livingston.com (8.7.1/8.6.9) id DAA05681 for ietf@ietf.org; Sun, 16 Feb 1997 03:45:59 -0800 (PST) Message-Id: <199702161145.DAA05681@server.livingston.com> Subject: Re: New Ideas for a WWW standard (fwd) To: ietf@ietf.org Date: Sun, 16 Feb 1997 03:45:59 -0800 (PST) Sender:ietf-request@ietf.org From: MegaZone Precedence: special-delivery Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me. Content-Type: text Source-Info: From (or Sender) name not authenticated. Once upon a time Jeff Jones shaped the electrons to say... >As a share of the market in servers and workstations, the facts are >otherwise. But the user BASE is expanding. It isn't surprising that it is shrinking in market share - when you're close to being the entire server base, any time a new server has any presence then your share declines. But there is room enough for both. Don't forget OS/2 also has a decent base as a server. Personally I'd use OS/2 before NT, and UNIX before both. But that's my view. >about. Unfortunately, I say this based on a past history of successfully >doing this in the VB/Win32 world in competition with UNIX programmers and >HTML/Java/CGI programmers. I doubt I am the only one capable of doing Are they equally skilled? Were the tasks better suited to VB? It is nigh-impossible to find a task that is equally suited to all approaches. If you're on NT, then VB has a bit of an edge. If you're on UNIX, VB isn't even a player. I operate solely on UNIX, as do the majority of sites today and for the foreseeable future. I also believe in portability, so any serious work I do is likely to be in a language I can move to another platform without rewriting it all. While I don't code my Perl to work on NT - I'd have an easier time of making the needed changes to it then you would of making a VB script work on UNIX. Different goals. >Yes, there are. Especially the free ones or the shareware ones nobody is >honest enough to pay for, like HoTMetaL. I use Frontpage in tandem with I do my work in emacs. I can write HTML of the top of my head in any decent text editor, and nearly always it is valid HTML first try. And if I screw up, it is usually a typo. I check my work with WebLint and an SGML parser. Using an "HTML Editor" slows me down. However, I do not expect everyone to be at my level. And I've designated HoTMetaL PRO as the editor for Livingston for those who don't have the ability to code by hand. I tested several, and after being completely disgusted by a few (PageHell and Netscape Foolsgold) I decided on HoTMetaL over FrontPage - FP still makes too many stupid errors, and it doesn't have the flexibility that HM has. I think FP could be one of the best products, if they'd just fix some of the mistakes it makes - it generates invalid HTML by default in many cases. It can be fixed in most, but it shouldn't be this way. But this is a tangent. >People should use what they want. My argument was in support of a >standard, like HTML has a published standard today. How about a specified HTML is a standard for structure. CSS1 is a standard for presentation. Server side scripting - the standard should be the *interface*. Either something like CGI or an API. CGI is great - but suffers from overhead. FastCGI cuts down greatly on overhead and speeds up response, but I think we could do better. And we still don't have agreement on supporting FastCGI. Trying to standardize on a server side languange would be a tragedy IMHO. As far as APIs go - it would be nice to give MS-API, and NS-API, and the Apache-API, etc -and produce a *standard* API that worked on all of them. That is what really keeps a lot of people from coding low level addon for servers. And producing a standard would really open the market to 3rd party vendors for enchancements. For client side scripting, again we need a standard. JavaScript is in the lead and is much farther along that VB Script. But now we have MS's half-assed and broken attempt at JS support that causes valid JS code to break in MSIE. And we also have NS making changes to it almost constantly. What we need is: 1. Assurance of backwards compatibility. 2. Real version control of the language. 3. And openly documented specification vendors can implement. If NS won't do this with JS, maybe it is appropriate to develop an open standard for a scripting language. Personally I'd take an existing one, like Perl or Python, and start there. JS is very Perl-like already. >results based on quality and time to production? It would certainly >generate some interest, given all the nasty-grams I get for even mentioning >VB to "REAL" programmers. But on which OS? And can you develop a project that isn't favored by one of the approaches? And, of course, you'd want some way to ensure the coders on both sides were equally skilled. >If you like HTML, Perl, FastCGI, then you must like some degree of >overhead. Java is interpreted code, like VB4. Please keep in mind that I That's one of the reasons there is a lot of work going on in respect to the Perl complier. To reduce the overhead of using Perl - the only real penalty with Perl is the recompilation on each instance of the script running. But even this isn't a serious drawback for most applications. It all depends on server load and how much overhead you have to play with. CGI itself is a 'slow' interface, and I agree that it could use improvement. the FastCGI effort is a real start on this. >C (and C++) are the ideal, but impractical for development unless you have >a huge ROI that pays for it (as in major commercial applications or writing Perl is multiplatform and is very simple to code. To me, the portability is what wins over VB. But I regularly work in heterogenous environments, serveral different flavors of UNIX - and sometimes NT is in the mix. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com Snail mail: 4464 Willow Road, Pleasanton, CA 94588   Received: from ietf.org by ietf.org id aa03802; 16 Feb 97 7:12 EST Received: from bast.livingston.com by ietf.org id aa03578; 16 Feb 97 7:09 EST Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id EAA20085 for ; Sun, 16 Feb 1997 04:09:05 -0800 (PST) Received: (from megazone@localhost) by server.livingston.com (8.7.1/8.6.9) id EAA06341 for ietf@ietf.org; Sun, 16 Feb 1997 04:07:01 -0800 (PST) Message-Id: <199702161207.EAA06341@server.livingston.com> Subject: RE: New Ideas for a WWW standard (fwd) To: ietf@ietf.org Date: Sun, 16 Feb 1997 04:07:01 -0800 (PST) Sender:ietf-request@ietf.org From: MegaZone Precedence: special-delivery Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me. Content-Type: text Source-Info: From (or Sender) name not authenticated. Once upon a time Michael Zappe shaped the electrons to say... >interesting. I have found that HTML is a very limited markup language, = In what way? HTML is meant to define the document *structure* not how it is presented. Keep that in mind when you criticise it. As far as defining structure goes, HTML 3.2 is pretty well rounded. With Couger moving to the full RFC 1942 table specification, the encorporation of OBJECT, and the internationalization of HTML, I don't see any real weaknesses. For the presentational side of things, we have Style Sheets - currently CSS1. I used to be highly critical of style sheets, but as they standard evolved the proposal won me over. I still think some people are a bit utopian - style sheets are the answer to everything - but it is a very solid effort. And careful attention was paid to growth, so that 'CSS2', etc will not be like pulling teeth. On the outside we have the W3C's proposal on XML - Extensible Markup Language. A *much* broader application of SGML, allowing for near complete flexibility. Time will tell if this goes anywhere. >information. CGI is not a very good alternative. Trying to produce = >HTML documents from within most structured languages is a great source = >of frustrating errors ("Whoops... forgot to escape that quote, again!" = *shrug* I do this all the time. I done a number of multipage forms that are 100% generated from Perl. It isn't all that hard once you do it a few times. Most of my time is spent redoing things when marketing changes their mind. ;-) >;-) ). It can also be a difficult proposition to think in design terms = >while you're embedding the design of the page inside of the program. =20 Maybe it's me. I've been told I'm weird - I did design and architecture and one some awards as a student, then I got degrees in technicial writing and history - which were really an excuse for me to hack around on the network while I was there. I know AtariBASIC, BASIC, True Basic, C, Perl, some C++, some x86 assembly, and very little Scheme. These days I'm sharpest in Perl. My point is that I don't have a traditional 'design only' or 'computing only' backround. Which seems the norm in most people I know involved in the web. You have the people who do the page design, and the people who write applications and keep the servers running. It doesn't seem that common to have a person fluent in both areas - which is what I do. While I'm writing an application that is going to produce a page, I can see exactly how that page is going to look in HTML. It does come in handy. > MegaZone earlier said that most of the content on the web right now is = >static, and that is true, but we are moving towards having more and more = >dynamic data present; just think about electronic commerce, where = >dynamic data is necessary for any large retail site! Doing this in CGI = >is a big pain! =20 I agree that we are moving to more dynamic content. But I do not believe we will ever have a day when there is more dynamic content then there is static. Even the sites that have stores have many pages of static info for each store, dynamic page. I don't think writing a store is so hard. It is time consuming, but no more so than any other major application programming development project. Last year I coded up, from scratch, the majority of what is needed for an online store for Livingston. At the time I had just resumed programming after a year+ period where I didn't code anything, so it wasn't pretty - but it works. (Then marketing changed their minds and it's been on indefinitely hold ever since.) I took the approach of coding reusable modules and storing all of the content in fixed formats. I was using flat files for development, but it could just as easily be DBM - or call a commercial database for the truly large sites. Many of the forms I've done have lists, variable input fields, etc that use datafiles, a keyed on imput from a previous page, etc. > Adding a programmatic structure to HTML, but leaving it in a markup = >type syntax I find to be a great idea! Even static data could benefit = >from such a structure. I was (previous to budget cuts) working on the = I don't understand this. How would you take a markup language and make it programatic? What would this do? How would this differ from server side CGI? Or programs written for the server'd API? Or ever things like NS's server side JavaScript? >electronic textbook project at NC State, and producing a large textbook = >in HTML was a tremendous pain. SGML has some great features to make it = >easier, but writing a rendering engine for the DTDs for each type of = >page to create HTML is a lot of redundant effort. So using what I = We do our documentation in FrameMaker. We then user WebWorks to publish to HTML. The HTML has many errors (we tested many products, WW was the lesser of many evils) so it runs through some Perl that fixes most of them. A final human check does the rest. We started doign this only a month of so back, and we've already worked most of the kinks out and are close to doing so with the rest. Our goal is to have the system use as little human time as possible, and to hopefully automate the entire process. >a flexibility, ease of use, and functionality superior to that of HTML, = >CSS1 and CGI. Using the same markup structure used to define the = Remember that for it to be usuable online, the end product must be in the form of the basic HTML & CSS building blocks. It doesn't matter what magic happens on the server side to produce this though. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com Snail mail: 4464 Willow Road, Pleasanton, CA 94588   Received: from ietf.org by ietf.org id aa10187; 16 Feb 97 12:35 EST Received: from edu.lahti.fi by ietf.org id aa09765; 16 Feb 97 12:22 EST Received: (qmail 11221 invoked by uid 1067); 16 Feb 1997 17:21:02 -0000 Date: Sun, 16 Feb 1997 19:21:02 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni To: MegaZone cc: ietf@ietf.org To: Undisclosed recipients: ; Subject: Re: New Ideas for a WWW standard (fwd) In-Reply-To: <199702150005.QAA23231@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Fri, 14 Feb 1997, MegaZone wrote: > 3. We already have XML as a possible nexgen. Where can I find XML specs? (I'm not quite the most knowledgeable about hypertext languages, but I'd like to keep up with the progress...) Thanks in advance. > vendor specific enhancements, you're nuts. CSS1 gives the control over > presentation the proposal seems to be aiming at - MS and NS have committed > to supporting the full recomendation. It's true, though, that the NS and MS extensions are much more accessable than the respective CSS1 counterparts - there aren't any WYSIWYG CSS1 generators and, all in all, CSS1 is quite a bit more abstract in its syntax than baseline HTML plus some of the more convenient proprietary extensions. Don't get me wrong, I'm in for standardization. It's just that the usual layman in for the Net revolution probably doesn't think the way we do. > Even NS sees plugins dying as Java replaces them. You have HTML for the > structural and minimal presentational markup. CSS1 for the fine control > on presentation. And Java Applets for other needs. But Java has its problems as well: it requires in depth knowledge of (OO) programming. I we do that but how about the average Net user that just wants fancy functions with minimal work? > The *last* thing we need is some new system that tries to replace any or > all of these. Right now it is hard enough to get the various vendors to > all implement ONE spec properly. Right again. So what we have in our hands is a mess. (As if you didn't know...) Sampo Syreeni (Decoy/dAWN), student,   Received: from ietf.org by ietf.org id aa10412; 16 Feb 97 12:42 EST Received: from edu.lahti.fi by ietf.org id aa10319; 16 Feb 97 12:41 EST Received: (qmail 11258 invoked by uid 1067); 16 Feb 1997 17:41:05 -0000 Date: Sun, 16 Feb 1997 19:41:05 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni To: MegaZone cc: ietf@ietf.org To: Undisclosed recipients: ; Subject: Re: New Ideas for a WWW standard (fwd) In-Reply-To: <199702151115.DAA22157@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Sat, 15 Feb 1997, MegaZone wrote: > Once upon a time Jeff Jones shaped the electrons to say... > >operating system than NT for both workstations and servers. Yet, UNIX is a > >dying technology and NT reigns supreme in the marketplace. Why? UNIX is > > I hardly think it is dying. The UNIX base is growing. Especially since Linux hit the market. You ain't going to get an NT clone for free. > Actually programming page content is a completely warped, completely terrible > idea no matter what you use. It adds completely pointless overhead to > the process that is not worth it. When you can mark up a file with HTML > and Style Sheets, and MOST of the web is NOT dynamic content so this > covers it, it doesn't make sense to turn to a more programatic syntax. But you must admit the users want interactivity. And that's real messy to do with declarative languages such as HTML and CSS1. But I agree, it's really a horrific idea to settle for something as proprietary as VB. Java is a better candidate, but it's a bit heavy and, when not running natively, slow. > That is flat out incorrect. It wins SOME of the time, NOTHING wins all of > the time. VB doesn't even win most of the time. Exactly. VB wins if you need let's say intranet RAD applications where you don't have to worry about interconnectivity or longevity of the data. But as soon as you go global and multiplatform, VB's not going to do you much good. > When you have a hammer, everything looks like a nail. You know VB, so > you want to standardize on that. I know other Windows programmers who would > say you're high and C++ is the way to go. My personal fave is Perl, followed > by C. Someone else will say we're all obviously clueless and Java is the > standard to use. Partially correct. But even you must admit that Java is the one originally designed with these kinds of applications in mind whereas C, C++ and VB are all originally meant for tranditional, procedural programming. (Well, Java is procedural and C-like, but still...). Perl is a convenient scripting language, and thus a valid competitor. So take your pick. But forget C, C++ and VB. > HTML is for document structure, and some basic layout. I think the number of different layout primitives in HTML should be reduced. It would make implementing CSS1 and HTML side by side a bit easier and would emphasize HTML's primary role as a markup language. Sampo Syreeni (Decoy/dAWN), student,   Received: from ietf.org by ietf.org id aa11349; 16 Feb 97 12:56 EST Received: from edu.lahti.fi by ietf.org id aa11058; 16 Feb 97 12:53 EST Received: (qmail 11302 invoked by uid 1067); 16 Feb 1997 17:53:05 -0000 Date: Sun, 16 Feb 1997 19:53:05 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni Reply-To: Sampo Syreeni To: MegaZone cc: ietf@ietf.org To: Undisclosed recipients: ; Subject: Re: New Ideas for a WWW standard (fwd) In-Reply-To: <199702151131.DAA22669@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Sat, 15 Feb 1997, MegaZone wrote: > First - Having instructed both, most people understand markup faster than > they understand programmatical structurs. Agreed. It's the basic difference between procedural and declarative languages - it's much easier to tell what than to come up with how. And there are other benefits as well - one of them being easy automatic generation of declarative constructs. It's quite easy to construct a WYSIWYG web editor but try to do the same with programmatic constructs - not nearly as workable. > I don't believe it is worth the effort, in fact, I think trying to change > the system at this late a date is completely counter productive. I for [snip] > You should have tried in 1993, before it would be a tremendous pain to > even consider a change. But as the graphical (and other multimedia oriented) content of the web is bound to increase and at the same time people crave more intelligent and easy to use services and interactivity, the HTML model doesn't completely fulfil all the needs present. Even when spiced up with CSS1, VRML and whatever. So the model is going to break someday. Wouldn't it be better to try to anticipate that day and try to come up with an alternative (now, I don't yet know about XML or others of its kind, so don't yell...). Sampo Syreeni (Decoy/dAWN), student,   Received: from ietf.org by ietf.org id aa12260; 16 Feb 97 13:12 EST Received: from edu.lahti.fi by ietf.org id aa12071; 16 Feb 97 13:06 EST Received: (qmail 11415 invoked by uid 1067); 16 Feb 1997 18:05:59 -0000 Date: Sun, 16 Feb 1997 20:05:59 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni To: Jeff Jones cc: ietf@ietf.org, MegaZone To: Undisclosed recipients: ; Subject: Re: New Ideas for a WWW standard (fwd) In-Reply-To: <199702151439.GAA19860@m3.sprynet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Sat, 15 Feb 1997, Jeff Jones wrote: > > I hardly think it is dying. The UNIX base is growing. > As a share of the market in servers and workstations, the facts are > otherwise. Ain't that growth, then? And UNIX has certainly been around longer than NT. It's stable and usable and has a huge installed base. It's the de facto server standard and the Net itself developed on UNIX. So UNIX certaily has its charm. > about. Unfortunately, I say this based on a past history of successfully > doing this in the VB/Win32 world in competition with UNIX programmers and > HTML/Java/CGI programmers. I doubt I am the only one capable of doing > this. But try a longer project with some five thousand pages of content and long life cycles. Even if you win in time, effort and outlook, you're caught when scaling up. VB isn't suitable for projects like that. It just wasn't designed for projects of that nature. > > First, HTML and CSS1 are cake - anyone should be able to use them with > ease. > > And there are several good tools on the market - such as HoTMetaL PRO. > Yes, there are. Especially the free ones or the shareware ones nobody is > honest enough to pay for, like HoTMetaL. I use Frontpage in tandem with Indeed. Where is the low-cost VB developer environment readily available to all? > am not recommending VB4 as a substitute for a standard. I am merely > pointing out that the success of a future standard is measured by how > broadly it is adopted inside and outside of the techie world. The success > of VB4, the wide audience for BASIC, and the methodology of how VB has > incorporated other languages certainly provides a starting point for that > standard. VB is no starting point, it's a kludge. Sampo Syreeni (Decoy/dAWN), student,   Received: from ietf.org by ietf.org id aa12367; 16 Feb 97 13:15 EST Received: from edu.lahti.fi by ietf.org id aa12280; 16 Feb 97 13:13 EST Received: (qmail 11479 invoked by uid 1067); 16 Feb 1997 18:12:51 -0000 Date: Sun, 16 Feb 1997 20:12:51 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni To: Michael Zappe cc: "ietf@ietf.org" To: Undisclosed recipients: ; Subject: RE: New Ideas for a WWW standard In-Reply-To: <01BC1B69.3A089BD0@ct1-11.INTERCENTER.NET> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Sat, 15 Feb 1997, Michael Zappe wrote: > Adding a programmatic structure to HTML, but leaving it in a markup > type syntax I find to be a great idea! Even static data could benefit But it messes up the very idea of declarativeness. And when people start using the programmatic constructs for the content (as they certainly will), one very basic and important function of the Net breaks down, namely, searching facilities. It's extremely hard if not impossible to properly index procedural data whereas doing exactly that with declarative data is a breeze. Sampo Syreeni (Decoy/dAWN), student,   Received: from ietf.org by ietf.org id aa13934; 16 Feb 97 13:48 EST Received: from lint.cisco.com by ietf.org id aa13134; 16 Feb 97 13:30 EST Received: from big-dogs.cisco.com ([171.68.53.43]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id KAA08857; Sun, 16 Feb 1997 10:26:15 -0800 (PST) Message-Id: <3.0.32.19970216132612.006cdd44@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 16 Feb 1997 13:26:16 -0500 To: Sampo Syreeni Sender:ietf-request@ietf.org From: Paul Ferguson Subject: Re: New Ideas for a WWW standard (fwd) Cc: Jeff Jones , ietf@ietf.org, MegaZone Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. At 08:05 PM 2/16/97 +0200, Sampo Syreeni wrote: > >Ain't that growth, then? And UNIX has certainly been around longer than >NT. It's stable and usable and has a huge installed base. It's the de >facto server standard and the Net itself developed on UNIX. So UNIX >certaily has its charm. > I'll agree that UNIX 'certainly has it's charm', but trying to establish that UNIX is the de facto server 'standard' is somewhat akin to saying that Jack Daniels is the de facto whiskey standard. You know what analogies can be made about opinions; everyone has one, etc. Your mileage may vary. - paul   Received: from ietf.org by ietf.org id aa17571; 16 Feb 97 16:06 EST Received: from cnri by ietf.org id aa17453; 16 Feb 97 16:02 EST Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa03417; 16 Feb 97 16:02 EST Received: from Ikkoku-Kan.Panda.COM (v92ti@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU (8.7.5/) with SMTP id MAA01329 for ; Sun, 16 Feb 1997 12:59:49 -0800 (PST) Received: from localhost by Ikkoku-Kan.Panda.COM id AA16487; Sun, 16 Feb 97 12:59:45 -0800 Date: Sun, 16 Feb 1997 12:34:31 -0800 (PST) Sender:ietf-request@ietf.org From: Mark Crispin X-Orig-Sender: Mark Crispin Subject: Re: New Ideas for a WWW standard (fwd) To: Internet Engineering Task Force In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Source-Info: From (or Sender) name not authenticated. A dose of reality for both sides, since I use both UNIX and NT extensively. The reports of the imminent, or even short- to mid-term, demise of UNIX are highly exaggerated. Unlike other systems where pundit declarations of gloom and doom proved true, UNIX has some substantial advantages which tend to ensure its long-term survival. The first is multiple vendor support. It is extremely difficult for any UNIX hardware vendor to lock in its customer base (although many have tried); and it is relatively easy to switch hardware vendors. UNIX has brought an end to the bad old days when a PDP-10 could be priced at many times the market value of its horsepower because it was the only machine that could run TOPS-20. Nor does the failure of any particular vendor spell concern for the future of the hardware. The second is economics. There are several variants of UNIX which are available for free or nearly-free, and which run on inexpensive generic hardware. NT, for all its other merits, is priced out of the hobbyist market, and requires a relatively high end machine with fairly specific peripherals. On the other hand, those who dismiss NT out of hand are in for a rude awakening. Strip NT of all the Windows garbage and underneath you'll find an impressive operating system. There are a remarkable number of things that UNIX does wrong and NT does right. None of this is germaine to the issue of whether HTTP or a new language is more suitable for the future of the web. Both NT and UNIX are suitable Web platforms, and will continue to be for some time. You need to think in terms of the needs and requirements of the web, and not about silly "my OS is better than your OS" wars.   Received: from ietf.org by ietf.org id aa17570; 16 Feb 97 16:06 EST Received: from [207.211.135.2] by ietf.org id aa17348; 16 Feb 97 15:57 EST Received: from ct1-07.INTERCENTER.NET by hermod.pcinno.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1389.3) id 1HTLLG13; Sun, 16 Feb 1997 16:08:05 -0500 Received: by ct1-11.INTERCENTER.NET with Microsoft Mail id <01BC1C21.C7EA70A0@ct1-11.INTERCENTER.NET>; Sun, 16 Feb 1997 15:55:07 -0500 Message-ID: <01BC1C21.C7EA70A0@ct1-11.INTERCENTER.NET> Sender:ietf-request@ietf.org From: Michael Zappe To: 'MegaZone' , "'ietf@ietf.org'" Cc: "'rothwell@cybergrafx.com'" Subject: RE: New Ideas for a WWW standard (fwd) Date: Sun, 16 Feb 1997 15:55:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Source-Info: From (or Sender) name not authenticated. -----Original Message----- From: MegaZone [SMTP:megazone@livingston.com] Sent: Sunday, 16 February, 1997 7:07 AM To: ietf@ietf.org Subject: RE: New Ideas for a WWW standard (fwd) Once upon a time Michael Zappe shaped the electrons to say... >interesting. I have found that HTML is a very limited markup language, = =3D In what way? HTML is meant to define the document *structure* not how it is = presented. Keep that in mind when you criticise it. As far as defining structure goes, HTML 3.2 is pretty well rounded. With Couger moving to the full RFC 1942 table specification, the encorporation of OBJECT, and the internationalization of HTML, I don't see any real weaknesses. True. As far as defining things structurally, HTML is a good markup. = It's easy to forget it's original purpose when you are concentrating on = the presentational side of things. :-) For the presentational side of things, we have Style Sheets - currently CSS1. I used to be highly critical of style sheets, but as they = standard evolved the proposal won me over. I still think some people are a bit utopian - style sheets are the answer to everything - but it is a very solid effort. And careful attention was paid to growth, so that 'CSS2', etc will not be like pulling teeth. I must admit, that I hadn't originally paid much attention to CSS1. But = looking at it now, it does help the presentational side of things quite = considerably! (Jeez, I've been out of the loop for a while...) =20 On the outside we have the W3C's proposal on XML - Extensible Markup Language. A *much* broader application of SGML, allowing for near = complete flexibility. Time will tell if this goes anywhere. I was looking at W3C's site and didn't see anything about XML off the = bat. Do you have a URL I can look at? >information. CGI is not a very good alternative. Trying to produce = =3D >HTML documents from within most structured languages is a great source = =3D >of frustrating errors ("Whoops... forgot to escape that quote, again!" = =3D *shrug* I do this all the time. I done a number of multipage forms that are 100% generated from Perl. It isn't all that hard once you do it a few times. =20 I've done quite a considerable amount of CGI programming, and I also = noted a considerable amount of wasted time with it! It's not hard, just = time consuming, and can be difficult to maintain! Most of my time is spent redoing things when marketing changes their=20 mind. ;-) Bingo! And changing a perl script or C++ program can be a pain, = especially because marketing and the designers like to change their = minds every five minutes! ;-) >;-) ). It can also be a difficult proposition to think in design terms = =3D >while you're embedding the design of the page inside of the program. = =3D20 Maybe it's me. I've been told I'm weird - I did design and architecture and one some awards as a student, then I got degrees in technicial = writing and history - which were really an excuse for me to hack around on the network while I was there. I know AtariBASIC, BASIC, True Basic, C, = Perl, some C++, some x86 assembly, and very little Scheme. These days I'm=20 sharpest in Perl. My point is that I don't have a traditional 'design only' or 'computing only' backround. Which seems the norm in most people I know involved in the web. You have the people who do the page design, and the people who write applications and keep the servers running. It doesn't seem that common to have a person fluent in both areas - which is what I do. While I'm writing an application that is going to produce a page, I can see exactly how that page is going to look in HTML. It does come in handy. Well, I'm also quite a mish-mash of things. I almost got a degree in = Religion, before I left the University (in quite a fuss). I know C++ = (My Favorite), Java, SQL, LISP, some perl, and am familiar with a bunch = of other languages (the thing I like most in computer science is = compiler theory ;-) ). I also come from a family full of artists (and = I'm one of them). So I can design the web pages inside the CGI script, = but it is much easier to visualize if you have the document in front of = you in it's rendered structure, rather than searching through print's = and cout's. It's just slightly more error prone. > MegaZone earlier said that most of the content on the web right now = is =3D >static, and that is true, but we are moving towards having more and = more =3D >dynamic data present; just think about electronic commerce, where =3D >dynamic data is necessary for any large retail site! Doing this in CGI = =3D >is a big pain! =3D20 I agree that we are moving to more dynamic content. But I do not = believe we will ever have a day when there is more dynamic content then there is static. Even the sites that have stores have many pages of static info for each store, dynamic page. I don't think writing a store is so hard. It is time consuming, but no more so than any other major application programming development = project. Last year I coded up, from scratch, the majority of what is needed for = an online store for Livingston. At the time I had just resumed programming = after a year+ period where I didn't code anything, so it wasn't pretty - but it works. (Then marketing changed their minds and it's been on indefinitely hold ever since.) I took the approach of coding reusable modules and storing all of the content in fixed formats. I was using flat files for development, but it could just as easily be DBM - or call a commercial database for the truly large sites. Many of the forms I've done have lists, variable input fields, etc that use datafiles, a keyed on imput from a previous page, etc. Oh, I'm not saying it's hard, but with the current tools in use, there = is a lot of unnecessary overhead. That's one of the time consuming = factors. And when marketing comes over and says "Change the site to = look like this!", it's a pain to change all of the CGI scripts. I used = for a site I did a few months ago a SQL database on the backend, with = the same idea of keyed sessions. And it was also built on a modular = structure. But when someone in marketing changed their mind, changing = all of the scripts to fit their new ideal was a pain. (At least now I = see that CSS1 makes presentational changes SO MUCH BETTER! Structural = changes however... ;-) ) > Adding a programmatic structure to HTML, but leaving it in a markup = =3D >type syntax I find to be a great idea! Even static data could benefit = =3D >from such a structure. I was (previous to budget cuts) working on the = =3D I don't understand this. How would you take a markup language and make it programatic? What would this do? Well, the way I'm working on it, it allows you to view the page from a = more document structured view rather than having the document broken up = among various print statements, etc. So it codes for more of a dynamic = structure. Such as:
    <{While TheresMore}>
  • <{FETCH QUERY=3DMyQuery COL=3D"PartName"}> <{/While}>
I also found that being able to create your own tag, much like a SGML = DTD, but including the rendering information in the definition makes = life easier. An example, from the book I was working on, is the = presence of an end of chapter section. So an example syntax (I'm = currently trying to define it..) In the document module (which contains various (sub)site-wide = definitions): <{SECTION EndOfChapter [WhatDoYouKnow+, Projects+]}> <{START}> <{TD COLSPAN=3D2 BGCOLOR=3D"#F80000">
Chapter
<{/TD}> <{/START}> <{END}>
<{/END}> <{SECTION WhatDoYouKnow [Question+]}> <{START}> <{TD BGCOLOR=3D"#FF0000"> What do you know? <{/TD}> <{/START}> <{END}> <{/TD}> <{/END}> =20 <{SECTION Question} NOEND> <{IMG SRC=3D""}> <{/SECTION Question}> ,,,etc... <{/SECTION}> And, in the document itself: What is the capital of Paraguay? Where is the Amazon river located? ...etc... Now this is very SGML-like, but with the programmatic features, it works = well for dynamic structure (Like database driven stuff). For static = pages, SGML->HTML is a great solution, but for dynamic stuff, it can be = a pain. (Is anyone out there looking for something like this also, or am = I wasting my time? ;-)) How would this differ from server side CGI? Or programs written for the server'd API? Or ever things like NS's server side JavaScript? The way I'm implementing it, it is very similar to Fast-CGI. It is like = ServerSide JavaScript, except that it is structured in a more SGMLish = way, and has various optimizations (like cached source) to make it = render documents quite fast. Perhaps I am slightly off beat with the = current discusstion, since it is server-side,,, (And in response to = Sampo, the client would only see the rendered HTML, so it would be = indexable. (I think I misrepresented myself.)) >electronic textbook project at NC State, and producing a large textbook = =3D >in HTML was a tremendous pain. SGML has some great features to make it = =3D >easier, but writing a rendering engine for the DTDs for each type of = =3D >page to create HTML is a lot of redundant effort. So using what I =3D We do our documentation in FrameMaker. We then user WebWorks to publish to HTML. The HTML has many errors (we tested many products, WW was the lesser of many evils) so it runs through some Perl that fixes most of them. A final human check does the rest. (Not to start a holy war, but: Yuck, FrameMaker :-) )=20 We started doign this only a month of so back, and we've already worked most of the kinks out and are close to doing so with the rest. Our goal is to have the system use as little human time as possible, and to = hopefully automate the entire process. >a flexibility, ease of use, and functionality superior to that of HTML, = =3D >CSS1 and CGI. Using the same markup structure used to define the =3D Remember that for it to be usuable online, the end product must be in the form of the basic HTML & CSS building blocks. It doesn't matter = what magic happens on the server side to produce this though. True, and CSS is a tool that I haven't utilized enough it appears! :-) -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 = megazone@livingston.com For support requests: support@livingston.com = =20 Snail mail: 4464 Willow Road, Pleasanton, CA 94588 Until Later, Mike -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Michael Zappe=20 Chief Programmer and CEO Magnus Software, Inc. Zapman@pcinno.com -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-   Received: from ietf.org by ietf.org id aa23804; 16 Feb 97 22:06 EST Received: from cnri by ietf.org id aa23432; 16 Feb 97 21:53 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa25669; 16 Feb 97 21:53 EST Received: from sirius.ctr.columbia.edu by venera.isi.edu (5.65c/5.61+local-26) id ; Sun, 16 Feb 1997 18:50:56 -0800 Received: from sweetpea (sweetpea.ctr.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id VAA15873; Sun, 16 Feb 1997 21:50:55 -0500 (EST) Message-Id: <3307F239.7F45@ctr.columbia.edu> Date: Sun, 16 Feb 1997 21:52:57 -0800 Sender:ietf-request@ietf.org From: Andrew Campbell Reply-To: campbell@ctr.columbia.edu Organization: Ceter for Telecommunications Research, Columbia University X-Mailer: Mozilla 3.01Gold (WinNT; I) Mime-Version: 1.0 To: ietf@isi.edu Cc: TANTAWI@watson.ibm.com, PARRY@watson.ibm.com, campbell@ctr.columbia.edu Subject: HPN'97 Advance Program + Registration Information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. H P N ' 9 7 A D V A N C E P R O G R A M SEVENTH IFIP CONFERENCE ON HIGH PERFORMANCE NETWORKING (HPN'97) White Plains, New York, April 28-May 2, 1997 http://www.ctr.columbia.edu/hpn97 THE PROGRAM AT A GLANCE: Monday April 28, 1997 9:00 - 12:30 Tutorial A: Wireless ATM and Mobile Computing Upkar Varshney, Washburn University, USA 13:30 - 17:00 Tutorial B: Scheduling Algorithms for Integrated Services Networks Hui Zhang, Carnegie Mellon University, USA Tuesday April 29, 1997: 9:00 - 12:30 Tutorial C: The Next Generation Internet Protocol Suite Doug Montgomery, NIST, USA 13:30 - 17:00 Tutorial D: Protocol Support for End-to-End QoS Guarantees across the Internet Raj Yavatkar, Intel, USA Wednesday April 30, 1997: 8:45 - 9:45 Conference Opening and Keynote Session 9:45 - 10:45 Experience with Standards 11:15 - 12:30 Multicast Implementation Issues 12:30 - 13:30 Conference Luncheon 13:30 - 15:00 Experimental Results 15:30 - 17:00 Multimedia Traffic Thursday May 1, 1997: 9:00 - 10:30 Quality of Service 11:00 - 12:30 Fundamental Concepts 12:30 - 13:30 Conference Luncheon 13:30 - 15:00 Architectural Issues 15:30 - 16:45 Bandwidth Allocation 18:00 - 22:00 CONFERENCE BANQUET (Dinner Cruise around NYC) Friday May 2, 1997: 9:00 - 10:30 Invited Presentations: Use of HPNs 11:00 - 12:30 Panel Discussion: Trends and Future of HPNs For details of the full program and registration information, please visit http://www.ctr.columbia.edu/hpn97 -- Andrew T. Campbell http://comet.ctr.columbia.edu/~campbell Wireless Media Systems Project http://comet.ctr.columbia.edu/wireless   Received: from ietf.org by ietf.org id aa06063; 17 Feb 97 5:29 EST Received: from mersey.hursley.ibm.com by ietf.org id aa05669; 17 Feb 97 5:21 EST Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA36526; Mon, 17 Feb 1997 10:19:13 GMT Date: Mon, 17 Feb 1997 10:19:13 GMT Message-Id: <9702171019.AA36526@hursley.ibm.com> Sender:ietf-request@ietf.org From: "(Brian E Carpenter)" Subject: Re: New Ideas for a WWW standard (where?) To: michael_roetto Cc: ietf@ietf.org In-Reply-To: <199702142015.VAA04613@box.nl> from "michael_roetto" at Feb 14, 97 09:15:50 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 105 Source-Info: From (or Sender) name not authenticated. WWW standards at upper layers tend to originate in the WWW Consortium, not the IETF. Brian Carpenter   Received: from ietf.org by ietf.org id aa12758; 17 Feb 97 10:06 EST Received: from ietf.ietf.org by ietf.org id aa10397; 17 Feb 97 9:24 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-teow-fabric-mib-02.txt Date: Mon, 17 Feb 1997 09:24:20 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702170924.aa10397@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard Author(s) : K. Teow Filename : draft-teow-fabric-mib-02.txt Pages : 49 Date : 02/12/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 defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standard defined in [1], [2] and [3]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identicalto the peer SNMPv1 definitions. There is a companion memo [10], that defines the objects for managing the operations of the Node portion of the Fibre Channel Standard (FC). 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-teow-fabric-mib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-teow-fabric-mib-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-teow-fabric-mib-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970213140208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-teow-fabric-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-teow-fabric-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970213140208.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12757; 17 Feb 97 10:06 EST Received: from ietf.ietf.org by ietf.org id aa10414; 17 Feb 97 9:24 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-miller-mftp-spec-02.txt Date: Mon, 17 Feb 1997 09:24:28 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702170924.aa10414@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : StarBurst Multicast File Transfer Protocol (MFTP) Specification Author(s) : K. Miller, K. Robertson, A. Tweedly, M. White Filename : draft-miller-mftp-spec-02.txt Pages : 57 Date : 02/13/1997 The Multicast File Transfer Protocol (MFTP) is a protocol that operates above UDP in the application layer to provide a reliable means for transferring files from a sender to up to thousands (potentially millions with network "aggregators" or relays) of multiple receivers simultaneously over a multicast group in a multicast IP enabled network. The protocol consists of two parts; an administrative protocol to set up and tear down groups and sessions, and a data transfer protocol used to send the actual file reliably and simultaneously to the multiple recipients residing in the group. 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-miller-mftp-spec-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-miller-mftp-spec-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-miller-mftp-spec-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970217090019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-miller-mftp-spec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-miller-mftp-spec-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970217090019.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12755; 17 Feb 97 10:06 EST Received: from ietf.ietf.org by ietf.org id aa10379; 17 Feb 97 9:24 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-atm1ng-03.txt Date: Mon, 17 Feb 1997 09:24:10 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702170924.aa10379@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Definitions of Managed Objects for ATM Management Author(s) : K. Tesink Filename : draft-ietf-atommib-atm1ng-03.txt Pages : 100 Date : 02/12/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 objects used for managing ATM-based interfaces, devices, networks and services. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. 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-atommib-atm1ng-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm1ng-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-atm1ng-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970213154658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atm1ng-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atm1ng-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970213154658.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18831; 17 Feb 97 12:04 EST Received: from black-ice.cc.vt.edu by ietf.org id aa18173; 17 Feb 97 11:46 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA30044 for ; Mon, 17 Feb 1997 11:41:02 -0500 Message-Id: <199702171641.LAA30044@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: ietf@ietf.org Subject: Re: New Ideas for a WWW standard (fwd) In-Reply-To: Your message of "Sat, 15 Feb 1997 03:15:08 PST." <199702151115.DAA22157@server.livingston.com> Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <199702151115.DAA22157@server.livingston.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1104214492P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 17 Feb 1997 11:41:01 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_-1104214492P Content-Type: text/plain; charset=us-ascii One thing that is getting lost in all the "language wars" for VB, Perl, C, C++, Java, Tk/Tcl, and what-have-you, is that there is a *firm* requirement that the language be designed to be implemented in a "secure box" (similar to the Java applet model), where a trojan applet can't do mean and nasty things to you. Anybody who doesn't agree should go read up on what the Chaos Computer Club demonstrated recently regarding ActiveX and Quicken..... -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_-1104214492P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMwiKG9QBOOoptg9JAQEQ7gP+Ix1tmmCmqIhUVPcIqCeR80ihDwSeC4pn DIrKl3y+KCxtd6nQdmpO9MeGpVoPA3DbNqA6ru4TR4nog3XBZT2ymRtga6fChAXz 2hdtgaeS3OZ4sQ+foSk2arHpZhlk2OSKJT2tqCQPz5UI+W/8HRTiFUyg9KzxE/Iy TQ6nYC/aSa8= =FhxM -----END PGP MESSAGE----- --==_Exmh_-1104214492P--   Received: from ietf.org by ietf.org id aa19364; 17 Feb 97 12:18 EST Received: from black-ice.cc.vt.edu by ietf.org id aa19154; 17 Feb 97 12:11 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA25130; Mon, 17 Feb 1997 11:37:48 -0500 Message-Id: <199702171637.LAA25130@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: Sampo Syreeni Cc: ietf@ietf.org Subject: Re: New Ideas for a WWW standard (fwd) In-Reply-To: Your message of "Sun, 16 Feb 1997 19:21:02 +0200." Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1241100520P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 17 Feb 1997 11:37:47 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_1241100520P Content-Type: text/plain; charset=us-ascii (Correcting two minor nits...) On Sun, 16 Feb 1997 19:21:02 +0200, Sampo Syreeni said: > But Java has its problems as well: it requires in depth knowledge of (OO) > programming. I we do that but how about the average Net user that just > wants fancy functions with minimal work? As the desktop publishing industry found out, having 5,000 fonts accessible doesn't make somebody a graphic designer. All it does is create better output in the hands of somebody who understands design, and creates horrible output in the hands of somebody who just wants to do minimal work. The "average Net user" is the kind of person that makes people who have a clue regarding design deplore the creation of . Using "fancy functions with minimal work" is the online equivalent of working in a wood shop with power tools without bothering to learn basic shop safety. On Sun, 16 Feb 1997 20:05:59 +0200, Sampo Syreeni said: > Ain't that growth, then? And UNIX has certainly been around longer than > NT. It's stable and usable and has a huge installed base. It's the de > facto server standard and the Net itself developed on UNIX. So UNIX > certaily has its charm. Umm.. actually, the Net itself *didnt* develop on Unix. It only got *popular* when BSD came with a free networking API (in the form of sockets). The actual development of TCP/IP was in the days of TOPS-20 and Multics (see all the references to "octets" instead of "bytes", specifically because the DEC-10 and -20 had variable-width bytes). But then again, most people think Apple invented the desktop/GUI idea on the Macintosh, overlooking both the Lisa and all the work done at Xerox PARC... ;) -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_1241100520P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMwiJWdQBOOoptg9JAQGoawP/SfuGMlP4Zpj+5/iROd6hYI1ppXAzVwmY Gi1t6prscO2IsFnXa/Q15w0BzLFB/VBV2WYtHmIflFvDPhHRlWA3ITgkMMBUNvPZ TFvZzp2RECXzP4kSt/cQlrWUdMWOUXmZsuexSKBD8HkEWGX9/LF0L6fxD+d2iFg0 oFd+/7mMMv4= =grm4 -----END PGP MESSAGE----- --==_Exmh_1241100520P--   Received: from ietf.org by ietf.org id aa21748; 17 Feb 97 13:39 EST Received: from callandor.cybercash.com by ietf.org id aa21067; 17 Feb 97 13:02 EST Received: by callandor.cybercash.com; id MAA04844; Mon, 17 Feb 1997 12:50:58 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma004819; Mon, 17 Feb 97 12:50:46 -0500 Received: from crockerdec.cybercash.com (loial.cybercash.com) by cybercash.com (4.1/SMI-4.1) id AA10181; Mon, 17 Feb 97 12:55:56 EST Message-Id: <3.0.32.19970217130123.006fbce8@cybercash.com> X-Sender: crocker@cybercash.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Feb 1997 13:01:59 -0500 To: Valdis.Kletnieks@vt.edu Sender:ietf-request@ietf.org From: Steve Crocker Subject: Re: New Ideas for a WWW standard (fwd) Cc: Sampo Syreeni , ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. >But then again, most people think Apple invented the desktop/GUI idea >on the Macintosh, overlooking both the Lisa and all the work done at >Xerox PARC... ;) And essentially all of the ideas that flowed through Parc and the Lisa that you're referring to came from Doug Engelbart's project at SRI before then including the invention of the mouse, structured documents with variable depth display, and "links" which are the forerunner of today's URLs. ---------------------------------- Steve Crocker Main: +1 703 620 4200 CyberCash, Inc. Desk: +1 703 716 5214 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 22091 crocker@cybercash.com   Received: from ietf.org by ietf.org id aa25152; 17 Feb 97 15:05 EST Received: from ietf.ietf.org by ietf.org id aa24687; 17 Feb 97 14:54 EST To: IETF-Announce: ; Subject: San Jose Electronic Proceedings Sender:ietf-announce-request@ietf.org From: IETF Proceedings Date: Mon, 17 Feb 1997 14:54:09 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702171454.aa24687@ietf.org> We have created a Web page to provide "early" access to the unedited version of the San Jose IETF Meeting held in December, 1996. The web page contains pointers to UNedited minutes and presentation slides. Once the hardcopy version of the proceedings has been completed, we will update this page with pointers to the final html meeting minutes. You can reach the new page at: http://www.ietf.org/proceedings/96dec/toc-96dec.html IETF Secretariat   Received: from ietf.org by ietf.org id aa26843; 17 Feb 97 15:40 EST Received: from gatekeeper.eop.gov by ietf.org id aa26732; 17 Feb 97 15:37 EST Received: from pmdf.eop.gov by gatekeeper.eop.gov; (5.65v3.2/1.1.8.2/17Oct95-0424PM) id AA06805; Mon, 17 Feb 1997 15:35:24 -0500 Received: from mr.eop.gov by PMDF.EOP.GOV (PMDF V5.0-4 #6879) id <01IFJ05R6J8G0078YJ@PMDF.EOP.GOV> for ietf@ietf.org; Mon, 17 Feb 1997 15:35:21 -0400 (EDT) Received: with PMDF-MR; Mon, 17 Feb 1997 15:35:19 -0400 (EDT) Mr-Received: by mta EOPMRX; Relayed; Mon, 17 Feb 1997 15:35:19 -0400 Alternate-Recipient: prohibited Disclose-Recipients: prohibited Date: Mon, 17 Feb 1997 15:29:00 -0400 (EDT) Sender:ietf-request@ietf.org From: Thomas_A._Kalil@oa.eop.gov Subject: Next Generation Internet Workshop--Call for White Papers To: ietf@ietf.org Message-Id: <01IFJ05RJXHY0078YJ@mr.eop.gov> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="Boundary (ID pp1tSbXgkryQ7ZTJ/WTb1g)" Ua-Content-Id: MBLINKAA" X400-Mts-Identifier: [;91535171207991/4682561@EOPMRX] Hop-Count: 1 Source-Info: From (or Sender) name not authenticated. --Boundary (ID pp1tSbXgkryQ7ZTJ/WTb1g) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Message Creation Date was at 17-FEB-1997 15:29:00 Apologies if you've already gotten this. - Tom Kalil The White House kalil_t@a1.eop.gov Call for White Papers Workshop on Research Directions for the Next Generation Internet May 13-14, 1997, Vienna, VA On October 10, 1996, President Clinton and Vice President Gore announced a new initiative to develop the Next Generation Internet (NGI). The initiative is a three-year, $300 million investment that will create the foundation for the networks of the 21st century. Specifically, the NGI initiative will: 1) connect 100 or more universities, national laboratories, and research institutions with high-speed networks that are 100 to 1,000 times faster than today's Internet; 2) invest in research and development that will enhance the capabilities of the Internet, such as real-time services; and 3) demonstrate new applications that support important national goals and missions such as scientific research, national security, distance education, environmental monitoring, and health care. The Computing Research Association will convene a two-day meeting of researchers to discuss the research agenda needed to accomplish these goals. The workshop will be held on May 13-14, 1997 at the Sheraton Premiere Hotel at Tyson's Corner, 8661 Leesburg Pike, Vienna, VA. Attendance will be by invitation; some limited support for travel and expenses is available for invitees. The academic, industrial, and government research communities are invited to submit "White Papers." These papers will not be formally presented at the workshop, but will provide grist for the working sessions and will be part of the formal record of the workshop. White Paper topics might include (but will not be limited to) research issues such as security, high-performance routing, performance measurement, caching, multicast, or dependability/reliability. The deadline for submission of White Papers is Thursday, March 27, 1997. Papers not exceeding 1,000 words should be submitted in ASCII text to jean@cra.org. In addition, please provide a cover page with name, title, affiliation, postal and e-mail addresses, and phone and fax numbers. Submissions will be reviewed by a distinguished panel of experts. Those selected to participate will be notified by April 15. The workshop is sponsored by the Federal Large Scale Networking Working Group (LSN) of the National Science and Technology Council's Committee on Computing, Information, and Communications R&D Subcommittee. LSN members include the National Institutes of Health, National Security Agency, Department of Energy, National Aeronautics and Space Administration, Department of Defense, DARPA, National Coordinating Office, National Oceanic and Atmospheric Administration, White House Office of Science and Technology Policy, Federal Networking Council, and National Science Foundation. The NGI Workshop web site, currently under construction, is http://www.cra.org/Policy/NGI. For further information, contact Jean Smith (jean@cra.org) or Rick Weingarten (rick@cra.org). Computing Research Association 1875 Connecticut Avenue NW, Suite 718 Washington, DC 20009 Phone: 202-234-2111 Fax: 202-667-1066 --Boundary (ID pp1tSbXgkryQ7ZTJ/WTb1g) Content-type: TEXT/PLAIN; CHARSET=US-ASCII The following attachments were included with this message: __________________________________________________________________ TYPE : FILE NAME : 021713AS.TXT __________________________________________________________________ --Boundary (ID pp1tSbXgkryQ7ZTJ/WTb1g) MIME-version: 1.0 Content-type: MESSAGE/RFC822 Subject: 021713AS MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII A1-type: DOCUMENT RFC-822-headers: Received: from storm.eop.gov (storm.eop.gov) by PMDF.EOP.GOV (PMDF V5.0-4 #6879) id <01IFIW7UN04W00HTMD@PMDF.EOP.GOV> for kalil_t@a1.eop.gov; Mon, 17 Feb 1997 13:42:30 -0400 (EDT) Received: from cra.org (cra.org) by STORM.EOP.GOV (PMDF V5.0-7 #6879) id <01IFIW7SYOOM000045@STORM.EOP.GOV> for kalil_t@a1.eop.gov; Mon, 17 Feb 1997 13:42:28 -0700 (MST) Received: from [198.180.53.4] (mac2.cra.org [198.180.53.4]) by cra.org (8.8.3/8.8.3) with SMTP id NAA08300 for ; Mon, 17 Feb 1997 13:44:30 -0500 (EST) X-Sender: jean@198.180.53.2 --Boundary (ID pp1tSbXgkryQ7ZTJ/WTb1g)--   Received: from ietf.org by ietf.org id aa00286; 17 Feb 97 16:44 EST Received: from bast.livingston.com by ietf.org id aa29216; 17 Feb 97 16:28 EST Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id NAA23720 for ; Mon, 17 Feb 1997 13:27:48 -0800 (PST) Received: (from megazone@localhost) by server.livingston.com (8.7.1/8.6.9) id NAA08268 for ietf@ietf.org; Mon, 17 Feb 1997 13:25:43 -0800 (PST) Message-Id: <199702172125.NAA08268@server.livingston.com> Subject: Re: New Ideas for a WWW standard (fwd) To: ietf@ietf.org Date: Mon, 17 Feb 1997 13:25:43 -0800 (PST) Sender:ietf-request@ietf.org From: MegaZone Precedence: special-delivery Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me. Content-Type: text Source-Info: From (or Sender) name not authenticated. Small request - please don't CC me when you send to the list. I do read the list. Once upon a time Sampo Syreeni shaped the electrons to say... >Where can I find XML specs? (I'm not quite the most knowledgeable about >It's true, though, that the NS and MS extensions are much more accessable >than the respective CSS1 counterparts - there aren't any WYSIWYG CSS1 >generators and, all in all, CSS1 is quite a bit more abstract in its For now, yes. But, for example, SoftQuad has said they will encorporate CSS1 autoring into HoTMetaL PRO, and I believe MS is doing the same for FrontPage. >But Java has its problems as well: it requires in depth knowledge of (OO) >programming. I we do that but how about the average Net user that just >wants fancy functions with minimal work? There are already pubically available applets that the average user can plugin and use, and there are tools for easy applet creation. I believe MacroMedia already has a decent tool for this on the market. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com Snail mail: 4464 Willow Road, Pleasanton, CA 94588   Received: from cnri by ietf.org id aa08167; 17 Feb 97 22:47 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06396; 17 Feb 97 22:47 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Tue, 18 Feb 1997 02:07:10 GMT Date: Mon, 17 Feb 1997 21:04:04 -0500 Message-Id: <9702180204.AA16259@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: J.Lebastard@frcl.bull.fr Cc: wray@tuxedo.enet.dec.com, cat-ietf@mit.edu In-Reply-To: Jacques Lebastard's message of Fri, 14 Feb 1997 09:49:15 +0100 ("MET), <9702140849.AA18688@ronde.frcl.bull.fr> Subject: Re: GSSv2 C-bindings Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: J.Lebastard@frcl.bull.fr (Jacques Lebastard) Date: Fri, 14 Feb 1997 09:49:15 +0100 ("MET) These convenience routines may be useful when GSS-API Version 2 are used in combination with the AccessControl and delegation extensions as defined in draft-ietf-cat-xgssapi-acc-cntrl-01.txt. I'm sure they may be useful; and indeed, I suspect many people will include such routines in their private libraries. The question is whether or not such convenience routines should be in the GSSAPI specification. (i.e., parse_X509_domain_name() is also useful for many mechanisms; that doesn't mean it should be in the GSSPAI specification.) Besides, there's a good reason to keep these three V2 specific routines in the C-bindings : they are defined in RFC 2078. The proposal is to drop them from the C-bindings, as well as dropping them in a future revision of RFC 2078. - Ted   Received: from ietf.org by ietf.org id aa22708; 18 Feb 97 9:55 EST Received: from ietf.ietf.org by ietf.org id aa20577; 18 Feb 97 9:28 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pfenning-irc-extensions-01.txt Date: Tue, 18 Feb 1997 09:28:16 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702180928.aa20577@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the Internet Relay Chat Protocol (IRCX) Author(s) : K. Cedola, T. Pfenning Filename : draft-pfenning-irc-extensions-01.txt Pages : 28 Date : 02/17/1997 This document describes extensions to the Internet Relay Chat protocol defined in RFC 1459[1]. The added functionality includes optional user authentication for multiple security providers, support for UNICODE[2] characters, multilayer security, and a unified property mechanism. Chat server implementations can optionally support channel or server services with full control over all messages and events. These services communicate with the core server over an extended IRC connection. All changes to the IRC protocol are designed in a way that existing clients will continue to work against servers implementing the extensions. Support for the extended protocol can be queried by clients to take advantage of the added functionality or to conform to the basic protocol as defined in RFC 1459. 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-pfenning-irc-extensions-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-pfenning-irc-extensions-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pfenning-irc-extensions-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970217095116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pfenning-irc-extensions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-pfenning-irc-extensions-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970217095116.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22710; 18 Feb 97 9:55 EST Received: from ietf.ietf.org by ietf.org id aa20624; 18 Feb 97 9:28 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-atm2-08.txt Date: Tue, 18 Feb 1997 09:28:20 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702180928.aa20624@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Definitions of Supplemental Managed Objects for ATM Management Author(s) : F. Ly, M. Noto, A. Smith, K. Tesink Filename : draft-ietf-atommib-atm2-08.txt Pages : 99 Date : 02/17/1997 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in 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-atommib-atm2-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-atm2-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970217100031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atm2-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atm2-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970217100031.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22714; 18 Feb 97 9:55 EST Received: from ietf.ietf.org by ietf.org id aa20623; 18 Feb 97 9:28 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: cat-ietf@mit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-pktapp-00.txt Date: Tue, 18 Feb 1997 09:28:26 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702180928.aa20623@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Public Key Utilizing Tickets for Application Servers (PKTAPP) Author(s) : A. Medvinsky, M. Hur, C. Neuman Filename : draft-ietf-cat-pktapp-00.txt Pages : 4 Date : 02/17/1997 Public key based Kerberos for Distributed Authentication[1], (PKDA) proposed by Sirbu & Chuang, describes PK based authentication that eliminates the use of a centralized key distribution center while retaining the advantages of Kerberos tickets. This draft describes how, without any modification, the PKINIT specification[2] may be used to implement the ideas introduced in PKDA. The benefit is that only a single PK Kerberos extension is needed to address the goals of PKINIT & PKDA. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-pktapp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-pktapp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-pktapp-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970217141109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-pktapp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-pktapp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970217141109.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22706; 18 Feb 97 9:55 EST Received: from ietf.ietf.org by ietf.org id aa20600; 18 Feb 97 9:28 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stevens-advanced-api-01.txt Date: Tue, 18 Feb 1997 09:28:22 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702180928.aa20600@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Advanced Sockets API for IPv6 Author(s) : W. Stevens, M. Thomas Filename : draft-stevens-advanced-api-01.txt Pages : 62 Date : 02/17/1997 Specifications are in progress for changes to the sockets API to support IP version 6 [2]. These changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. But another class of applications exists that will also be run under IPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [2]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too. 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-stevens-advanced-api-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-stevens-advanced-api-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-stevens-advanced-api-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970217105807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stevens-advanced-api-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-stevens-advanced-api-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970217105807.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22690; 18 Feb 97 9:55 EST Received: from ietf.ietf.org by ietf.org id aa20622; 18 Feb 97 9:28 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-moore-mime-cdisp-00.txt Date: Tue, 18 Feb 1997 09:28:28 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702180928.aa20622@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field Author(s) : R. Troost, S. Dorner, K. Moore Filename : draft-moore-mime-cdisp-00.txt Pages : 12 Date : 02/17/1997 This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content-Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). Two values for this header field are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values. This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, and [RFC 822]. The information presented herein supplements but does not replace that found in those documents. This document is a revision to the Experimental protocol defined in RFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the File Transfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values. [[NOTE IN DRAFT:: Comments on this document during the review period should be sent to .]] 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-moore-mime-cdisp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-moore-mime-cdisp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-moore-mime-cdisp-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970217173209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-moore-mime-cdisp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-moore-mime-cdisp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970217173209.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18288; 18 Feb 97 16:01 EST Received: from zephyr.isi.edu by ietf.org id aa17945; 18 Feb 97 15:51 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 18 Feb 1997 12:48:41 -0800 Message-Id: <199702182048.AA11842@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2109 on HTTP State Management Mechanism Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 18 Feb 97 12:48:41 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2109: Title: HTTP State Management Mechanism Author: D. Kristol, L. Montulli Date: February 1997 Mailbox: dmk@bell-labs.com, montulli@netscape.com Pages: 21 Characters: 43649 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2109.txt This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set-Cookie, which carry state information between participating origin servers and user agents. This document is a product of the HyperText Transfer Protocol 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@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970212095025.RFC@ISI.EDU> SEND /rfc/rfc2109.txt --OtherAccess Content-Type: Message/External-body; name="rfc2109.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970212095025.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13870; 19 Feb 97 10:10 EST Received: from ietf.ietf.org by ietf.org id aa11978; 19 Feb 97 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bernstein-owner-hack-01.txt Date: Wed, 19 Feb 1997 09:41:18 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702190941.aa11978@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Owner Hack Author(s) : D. Bernstein Filename : draft-bernstein-owner-hack-01.txt Pages : 2 Date : 02/19/1997 The fundamental problem in managing a large mailing list is matching bounce messages to subscription addresses. Often a bounce message refers to a failing address that does not appear on the mailing list. One of the mailing list subscribers is forwarding messages to that address. Which subscriber? As the list grows, this question becomes more and more difficult to answer. The owner hack completely eliminates this problem _right now_. It automatically and reliably identifies the subscription address relevant to each bounce message. It provides the address in a form that is trivial for automated bounce handlers to parse. It requires support from the local mailer, but it does not require support from any other hosts. 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-bernstein-owner-hack-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bernstein-owner-hack-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bernstein-owner-hack-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219091544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernstein-owner-hack-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernstein-owner-hack-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219091544.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13874; 19 Feb 97 10:10 EST Received: from ietf.ietf.org by ietf.org id aa11946; 19 Feb 97 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: idmr@cs.ucl.ac.uk Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-dvmrp-v3-04.txt, .ps Date: Wed, 19 Feb 1997 09:41:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702190941.aa11946@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : Distance Vector Multicast Routing Protocol Author(s) : T. Pusateri Filename : draft-ietf-idmr-dvmrp-v3-04.txt, .ps Pages : 38 Date : 02/18/1997 DVMRP is an Internet routing protocol that provides an efficient mechanism for connection-less datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP Multicast delivery trees using a technique called Reverse Path Multicasting (RPM) [Deer90]. This document is an update to Version 1 of the protocol specified in RFC 1075 [Wait88]. 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-idmr-dvmrp-v3-04.txt". Or "get draft-ietf-idmr-dvmrp-v3-04.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-dvmrp-v3-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idmr-dvmrp-v3-04.txt". Or "FILE /internet-drafts/draft-ietf-idmr-dvmrp-v3-04.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@ds.internic.net" Content-Type: text/plain Content-ID: <19970218101930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-dvmrp-v3-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-dvmrp-v3-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970218101930.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13868; 19 Feb 97 10:10 EST Received: from ietf.ietf.org by ietf.org id aa11962; 19 Feb 97 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-giudici-web-robots-cntrl-00.txt Date: Wed, 19 Feb 1997 09:41:16 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702190941.aa11962@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Web Robots Control Method for supporting Mobile Agents Author(s) : F. Giudici, A. Sappia Filename : draft-giudici-web-robots-cntrl-00.txt Pages : 7 Date : 02/18/1997 The Web Robots Control Standard [1] is a method for administrators of sites on the World-Wide-Web to give instructions to visiting Web robots. This document describes an extension for supporting Robots based on Mobile Agents, in a way that is independent of the technology used for their actual implementation. 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-giudici-web-robots-cntrl-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-giudici-web-robots-cntrl-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-giudici-web-robots-cntrl-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970218102925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-giudici-web-robots-cntrl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-giudici-web-robots-cntrl-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970218102925.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa15702; 19 Feb 97 10:37 EST Received: from palrel1.hp.com by CNRI.Reston.VA.US id aa16228; 19 Feb 97 10:37 EST Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id HAA12757; Wed, 19 Feb 1997 07:28:35 -0800 (PST) Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.20/15.5+ECS 3.3) id AA239866106; Wed, 19 Feb 1997 07:28:27 -0800 Received: from ietf.org by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA064716105; Wed, 19 Feb 1997 07:28:25 -0800 Received: from ietf.ietf.org by ietf.org id aa11998; 19 Feb 97 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: vgmib@hprnd.rose.hp.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-vgmib-repeater-dev-03.txt Date: Wed, 19 Feb 1997 09:41:20 -0500 Sender: cclark@ietf.org Message-Id: <9702190941.aa11998@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the 100VG-AnyLAN MIB Working Group of the IETF. Title : Definitions of Managed Objects for IEEE 802.12 Repeater Devices Author(s) : J. Flick Filename : draft-ietf-vgmib-repeater-dev-03.txt Pages : 56 Date : 02/19/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 network repeaters based on IEEE 802.12. 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-vgmib-repeater-dev-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-vgmib-repeater-dev-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-vgmib-repeater-dev-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219090904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vgmib-repeater-dev-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vgmib-repeater-dev-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219090904.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa21107; 19 Feb 97 12:20 EST Received: from ietf.ietf.org by ietf.org id aa20732; 19 Feb 97 12:12 EST To: IETF-Announce: ; Subject: IETF MAILING: INTRO: April 7-11, 1997 Date: Wed, 19 Feb 1997 12:12:44 -0500 Sender:ietf-announce-request@ietf.org From: Marcia Beaulieu Message-ID: <9702191212.aa20732@ietf.org> Dear IETFers: Following this message, you will receive three more regarding: REGISTRATION INFORMATION AT-A-GLANCE AGENDA The following information is/will be available via the Web. Agenda At-A-Glance Registration Form Miscellaneous: shipping information directions public transportation WG and BOF Agendas Tao: Guide for New Attendees WWW ----- Click on the link for "meetings" and you will find an entry for the Memphis meeting. The following information is available via the remote directories: Agenda At-A-Glance Registration Form Tao: Guide for New Attendees Travel Directions FTP ----- IETF Information is available by anonymous FTP from several sites. US East Coast Address: ds.internic.net (198.49.45.10) US West Coast Address: ftp.isi.edu (128.9.0.32) Europe Address: nic.nordu.net (192.36.148.17) Pacific Rim Address: munnari.oz.au (128.250.1.21) cd ietf ls *0mtg* NOTE: The payment fee structure has changed since the last meeting. If you pre-register and pre-pay before the registration cut-off date of March 28, 1997 your registration fee is $250.00. If you pre-register but do not pre-pay and plan to pay on-site, your registration fee will be $290.00. Registrations are still accepted on-site and the registration fee for on-sites is $290.00.   Received: from ietf.org by ietf.org id aa21719; 19 Feb 97 12:29 EST Received: from ietf.ietf.org by ietf.org id aa21576; 19 Feb 97 12:27 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ietf-rsvp@ietf.org Subject: IETF MAILING: REGISTRATION INFORMATION: April 7-11, 1997 Date: Wed, 19 Feb 1997 12:27:01 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9702191227.aa21576@ietf.org> New On-line Registration & Payment Procedure A New On-line Registration Procedure is now in effect, along with a New Payment Schedule - Please Take Note! Due to the increased number of attendees at IETF meetings, automating the registration process has become a priority for the Secretariat. In doing so, we have created an On-line Registration Form, accessible via the IETF Web Home Page, making it easy and simple for you to register on-line! Simply fill out the On-line Registration form completely and click on the "Submit" button at the bottom of the page. If you forgot to fill out a certain section, you will immediately receive a reply asking for that information and you may re-submit your form. Please be sure that all information you provide is correct! You will then see an acknowledgement page on your browser listing the information you just provided. If you need to make a change, please contact the IETF Registrar at: ietf-rsvp@ietf.org. Your registration/confirmation number will come to you via e-mail, which you should receive within 24 hours of submitting your registration form. Please be sure to use this number for any future correspondence regarding your registration. The e-mail message will list your options for payment - 1) reply e-mail using PGP, 2) print & fax, 3) print & mail ( additional on-line options are planned for the future). You may choose whichever option is most convenient for you. NOTE: Your payment of US$250 must be RECEIVED by the cut-off date of 28 March 1997 in order for you to qualify for the lower registration fee. If your payment is Not Received by the cut-off date, the fee will increase to US$290 and must be paid on-site. PLEASE BE SURE TO NOTE THIS NEW PAYMENT SCHEDULE! You can view the Memphis Meeting home page at: http://www.ietf.org/meetings/Memphis.html The URL for the on-line registration form is: http://www.ietf.org/meetings/reg_form.html If you are unable to access our Home Page on the Web, or if you have any questions regarding the new registration/payment procedure, please contact the IETF Registrar at: ietf-rsvp@ietf.org.   Received: from ietf.org by ietf.org id aa21832; 19 Feb 97 12:30 EST Received: from ietf.ietf.org by ietf.org id aa21736; 19 Feb 97 12:29 EST To: IETF-Announce: ; Subject: IETF MAILING: AT-A-GLANCE: April 7-11, 1997 Date: Wed, 19 Feb 1997 12:29:28 -0500 Sender:ietf-announce-request@ietf.org From: Marcia Beaulieu Message-ID: <9702191229.aa21736@ietf.org> PLEASE BE SURE TO MAKE YOUR HOTEL RESERVATION, THE CUT-OFF IS WEDNESDAY, MARCH 5, 1997 38th INTERNET ENGINEERING TASK FORCE Mailing Date: February 19, 1997 AT-A-GLANCE DATES: April 7-11, 1997 HOST: Keith Johnson Federal Express Corporation HOTEL/MEETING SITE: The Peabody Memphis 149 Union Avenue Memphis, TN 38103 Phone: 1 (901) 529-4000 or 1 (800) 732-2639 {fax: 1 (901) 529-3646} CI 1600; CO 11:00 325 Rooms reserved until Wednesday, March 5, 1997. US$119.00/single; US$129.00/double (please add 13.25% tax). Specify: 38th IETF Group Cancellations must be made 48 hours prior to the day of arrival in order to avoid being charged the deposit. ADDITIONAL ACCOM: TBD NEWCOMER'S Sunday, April 6, 1997 ORIENTATION: 15:30 - 16:30 The Peabody Memphis Room: Venetian Room PRE-REGISTRATION: Sunday, April 6, 1997 17:00 - 19:00 (reception) The Peabody Memphis Room: Continental Ballroom REGISTRATION: Monday, April 7, 1997 and BREAKS 08:00 - 18:00 Tuesday, April 8 - Thursday, April 10, 1997 08:30 - 18:00 Friday, April 11, 1997 08:30 - 12:00 The Peaboy Memphis Room: Memphis Foyer TERMINAL ROOM: Forest Room REGISTRATION FEE: Your payment of US$250 must be RECEIVED by the cut-off date of 28 March 1997 in order for you to qualify for the lower registration fee. If your payment is Not Received by the cut-off date, the fee will increase to US$290 and must be paid on-site. AIRPORT: Memphis International PARKING: The current charge for parking is $6.00 (self parking) or $9.00 (valet parking) - this is subject to change without notice. SHUTTLE: TBD   Received: from ietf.org by ietf.org id aa21979; 19 Feb 97 12:32 EST Received: from ietf.ietf.org by ietf.org id aa21911; 19 Feb 97 12:32 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: agenda@ietf.org Subject: IETF MAILING: DRAFT AGENDA: April 7-11, 1997 Date: Wed, 19 Feb 1997 12:32:07 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9702191232.aa21911@ietf.org> ****38th IETF: April 7-11, 1997/Memphis, TN**** PLEASE NOTE THE FOLLOWING: 1. NEWCOMER's ORIENTATION: On Sunday, April 6th at 1530 we will be holding an orientation session for Newcomers (Room: Venetian Room) ALL FIRST TIME ATTENDEES ARE ENCOURAGED TO READ RFC 1718 BEFORE ATTENDING THE MEETING. Entitled "The Tao of IETF: A Guide for New Attendees of the Internet Engineering Task Force", this RFC is available by anonymous FTP, although an updated version is available via the WEB. 2. PRE-REGISTRATION and a RECEPTION will be held on Sunday, April 6th from 1700 - 1900 (Room: Continental Ballroom). 3. A Working Group Chairs Workshop will be held during lunch on Monday, April 7th at 1130. Anyone interested in learning about the role of the working group chair is welcome to attend. Location: TBD. 4. The Agenda below is a DRAFT and therefore subject to frequent changes. We do not advise you use it to determine travel arrangements. -------- FYI..... A reminder that the quality of these meetings (and in particular the Working Group technical *working* sessions) is dependent upon the informed, constructive participation of the individual attendees. Please come prepared. Information on the current status and progress of the individual Working Groups can be obtained in several ways: 1. Working Group objectives and notes from previous sessions are available online (send to ietf-info@ietf.org for retrieval instructions). 2. Working Group objectives and notes from previous meetings are also reproduced in the hardcopy Proceedings (to order, send to proceedings@ietf.org). 3. Agendas and reading lists for Working Group meetings will also be posted to the respective Working Group mailing lists. And when submitted to the Secretariat will be made available via the web. IF YOU HAVE QUESTIONS REGARDING THE SCHEDULING OF A PARTICULAR WORKING GROUP, PLEASE CONTACT THE CHAIR OF THAT GROUP DIRECTLY. A LISTING OF WORKING GROUP MAILING LISTS IS AVAILABLE VIA ANONYMOUS FTP, CD IETF, GET "1wg-summary.txt". LOOKING AHEAD.... Information on future IETF meetings is available from the FTP Directories. Look under filename "0mtg-sites.txt". Draft Agenda of the Thirty-Eighth IETF (April 7-11, 1997) As of February 18, 1997 MONDAY, April 7, 1997 0800-0900 IETF Registration and Continental Breakfast 0900-0930 Introductions 0930-1130 Morning Sessions OPS disman Distributed Management WG OPS ngtrans New Generation Transition WG SEC pkix Public-Key Infrastructure (X.509) WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG 1130-1300 Break 1300-1500 Afternoon Sessions I INT pppext Point-to-Point Protocol Extensions WG OPS mboned MBONED Deployment WG SEC aft Authenticated Firewall Traversal WG USV uswg User Services 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II OPS omarea Operations & Management Open Area Meeting RTG idr Inter-Domain Routing WG USV isn Internet School Networking WG 1730-1930 Break 1930-2200 Evening Sessions OPS mboned MBONED Deployment WG USV isnII Internet School Networking-Educators BOF TUESDAY, April 8, 1997 0830-0900 Continental Breakfast 0900-1130 Morning Sessions GEN poisson Process for Organization of Internet Standards Ong WG INT ion Internetworking Over NBMA WG OPS rmonmib Remote Network Monitoring WG SEC pkix Public-Key Infrastructure (X.509) WG 1130-1300 Break 1300-1500 Afternoon Sessions I INT ion Internetworking Over NBMA WG OPS rtfm Realtime Traffic Flow Measurement WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC cat Common Authentication Technology WG USV harts Humanities and Arts WG 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II OPS disman Distributed Management WG OPS grip G and R for Security Incident Processing WG RTG idmr Inter-Domain Multicast Routing WG SEC spki Simple Public Key Infrastructure WG WEDNESDAY, April 9, 1997 0830-0900 Continental Breakfast 0900-1000 Morning Sessions I INT pktway PacketWay WG OPS stdguide Guide for Internet Standards Writers WG USV run Responsible Use of the Network WG 1015-1115 Morning Sessions II INT pktway PacketWay WG OPS rmonmib Remote Network Monitoring WG 1115-1300 Break 1300-1400 Afternoon Sessions I INT pppext Point-to-Point Protocol Extensions WG OPS pier Procedures for Internet/Enterprise Renumbering WG OPS ptopomib Physical Topology MIB WG 1415-1515 Afternoon Sessions II OPS ptopomib Physical Topology MIB WG 1515-1545 Break (Refreshments provided) 1545-1645 Afternoon Sessions III INT dhc Dynamic Host Configuration WG OPS roamops Roaming Operations WG USV ssh Site Security Handbook WG 1700-1800 Afternoon Sessions IV INT dhc Dynamic Host Configuration WG OPS roamops Roaming Operations WG USV ssh Site Security Handbook WG 1800-2000 Break 2000-2100 Evening Sessions I GEN iab Internet Architecture Board INT dhc Dynamic Host Configuration WG 2100-2200 Evening Sessions II GEN iab Internet Architecture Board INT dhc Dynamic Host Configuration WG 2230 Late Night Session PGP Key Signing Party THURSDAY, April 10. 1997 0830-0900 Continental Breakfast 0900-1130 Morning Sessions INT atommib AToM MIB WG OPS roamops Roaming Operations WG RTG idmr Inter-Domain Multicast Routing WG 1130-1300 Break 1300-1500 Afternoon Sessions I INT ipngwg IPNG WG 1500-1530 Break (Refreshments provided) 1530-1630 Presentations 1630-1800 Open Plenary and IESG FRIDAY, April 11, 1997 0830-0900 Continental Breakfast 0900-1130 Morning Sessions INT ipngwg IPNG WG OPS bmwg Benchmarking Methodology WG Key to Abbreviations APP Applications Harald Alvestrand/UNINETT and Keith Moore/UTK GEN General Interest Fred Baker/cisco Systems INT Internet Frank Kastenholz/FTP Software and Jeffrey Burgan/Bay Networks OPS Operational Requirements Scott Bradner/Harvard and Michael O'Dell/UUNET Technologies Deirdre Kostick/AT&T RTG Routing Joel Halpern/Newbridge Networks SEC Security Jeff Schiller/MIT TSV Transport Allison Mankin/ISI Allyn Romanow/Sun Microsystems USV User Services Joyce K. Reynolds/ISI   Received: from ietf.org by ietf.org id aa23201; 19 Feb 97 12:46 EST Received: from ietf.ietf.org by ietf.org id aa22512; 19 Feb 97 12:39 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ietf-rsvp@ietf.org Subject: IETF MAILING: LIST OF REGISTERED ATTENDEES: April 7-11, 1997 Date: Wed, 19 Feb 1997 12:39:52 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9702191239.aa22512@ietf.org> THIS IS A LIST AS OF FEBRUARY 19, 1997 AT 9:00AM ET "Adams","Robert","Cisco Systems" "Aprille","Thomas","Lucent Technologies - Bell Labs" "Atkinson","Randall","@Home Networks" "Bailey","Chase","Cisco Systems" "Baker","Fred","Cisco Systems" "Balenson","David","Trusted Information Systems Inc." "Beaulieu","Marcia","Corporation for National Research Initiatives" "Binder","Dick","CNRI" "Blanchet","Marc","Viagenie inc." "Bono","Anthony ","Telford Tools Inc." "Boroumand","Javad","USC/ISI" "Boudreaux","John","Daleen Technologies Inc." "Brabson","Roy","IBM Corporation" "Braden","Bob","USC/ISI" "Cansever","Derya","GTE Laboratories Inc." "Casner","Stephen","Precept Software Inc." "Cheng","Zorro","HK Supernet" "Christy","Greg","Juniper Networks Inc." "Civanlar","Reha","AT&T Labs - Research" "Corson","M Scott","University of Maryland" "Crawford","Matt","Fermilab" "Crowcroft","Jon","ucl" "Daniel","Ron","Los Alamos National Laboratory" "Davis","Terry ","Boeing Information & Support Services" "Dawkins","Spencer","Nortel" "De Winter","Jack","Wildbear Consulting Inc." "Deering","Steve","Cisco Systems" "Dia","Jay","BBN" "Dinha","Francis","NewCom Technologies Inc." "Donelan","Sean","Data Research Associates" "Doria","Avri","GDC" "Droms","Ralph","Bucknell University" "Droz","Patrick","IBM Research Division" "Droz","Patrick","IBM Research Division" "Dunn","Jeffrey","Hewlett-Packard Company" "Dunstan","Adam","Bay Networks" "Dusseault","Lisa","Microsoft" "Earhart","Rob","Carnegie Mellon University" "Eastlake 3rd","Donald","CyberCash Inc." "Ellerbee","Jeff","ichat" "Ellesson","Edward","IBM" "Eppenberger","Urs","SWITCH" "Esposito","Antonio","Telecom Italia DRE/TA" "Faltstrom","Patrik","Swipnet" "Farinacci","Dino","cisco Systems" "Ferguson","Paul","cisco Systems Inc." "Fink","Robert","Berkeley Lab (LBNL)" "Flanigan Jr.","William","DoD/DISA/Center for Standards" "Fletcher","Chris","RIPE NCC" "Fox","Barbara","Microsoft Corporation" "Fraser","Barbara","Software Engineering Institute" "Fredette","Andre","Bay Networks" "Fujii","Noboru","Sony Corporation" "Gallagher","Maria","LSI Logic" "Garrett","Mark","Bellcore" "Gettys","James","Digital Equipment Corporation" "Glass","Steven","ftp Software" "Goland","Yaron","Microsoft" "Goller","Sean","Carnegie Mellon University" "Gray","Eric","Lucent Technologies" "Gudmundsson","Olafur","Trusted Information Systems Inc." "Guttman","Erik","Sun Microsystems" "Halpern","Joel","Newbridge Networks Inc." "Hambridge","Sally","Intel Corp" "Handley","Mark","USC/ISI" "Hanna","Donal","Netskills" "Hanna","Stephen","ON Technology Corporation" "Harrington","David","Cabletron Systems Inc" "Hedberg","Roland","SUNET" "Herzog","Shai","IBM T.J. Watson" "Hinden","Robert","Ipsilon Networks Inc." "Hoffman","Paul","Internet Mail Consortium" "Holmstead","Stephen","Hewlett Packard" "Holtzman","David","Network Solutions Inc." "Hopkins","Gerald","Bell Atlantic" "Horowitz","Marc","Cygnus Solutions" "Huber","Kathy","BBN" "Huizer","Erik","SURFnet ExpertiseCentrum bv" "Huss","Claude","Matsushita Electric Works R&D Labs Inc." "Hussain","Farooq","MCI" "Izumiyama","Hidetaka","Japan Satellite Systems Inc." "Jackowski","Steven","NetManage Inc." "Kadansky","Miriam","Sun Microsystems" "Karn","Phil","Qualcomm" "Kemp","David","National Security Agency" "Keromytis","Angelos","University of Pennsylvania" "Kim","Dorian","CICNet" "Kim","Yong-Woon","ETRI" "Kirchhoff","Julie","Corporation for National Research Initiatives" "Klein","Joseph","Titania Corporation" "Koch","Harald","Secure Computing" "Kohn","Daniel","Teledesic" "Komiya","Masakatsu","Japan Satellite Systems Inc." "Kompella","Vach","IBM Corp." "Koskelainen","Petri","Nokia Research Center" "Kossakowski","Klaus","DFN-CERT" "Kosters","Mark","Network Solutions Inc." "Kostick","Deirdre","AT&T" "Krawczyk","John","Bay Networks" "Kristol","David","Bell+Labs +Lucent+Technologies" "Kurakami","Hiroshi","NTT Multimedia Network Labs." "Lang","Ruth","SRI International" "Lanphier","Robert","Progressive Networks" "Lazear","Walter","MITRE Corp" "Leech","Marcus","Nortel Technology" "Loa","Loa","Ericcson Tekecom AB" "Luciani","James","Bay Networks Inc." "Magnell","Steven","Dialogic Corporation" "Malamud","Carl","MIT Media Lab" "Malis","Andrew","Cascade Communications Corp." "Malkin","Gary","Bay Networks" "Mamakos","Louis","UUNET Technologies" "Mankin","Allison","USC/ISI" "Mannie","Eric","Brussels University" "Manning","Bill","USC/ISI" "Martillo","Joachim","Telford Tools Inc." "Martin","Cynthia","DISA" "Masinter","Larry","Xerox Corporation" "Massarani","Leo","IBM" "Maufer","Thomas","3Com Corporation" "McBurnett","Neal","Bell Labs" "McCauley","Bill","GeoNet Communications Inc." "McDonald","Daniel","Sun Microsystems Inc." "McIntyre","Daniel ","Boeing Information & Support Services" "Mealling","Michael","Network Solutions Inc." "Mercer","David","Nortel Technology" "Metzger","Perry","Piermont Information Systems Inc." "Meyer","David","University of Oregon" "Monfort","Martial","Electicite et gaz de France" "Monsour","Bob","Hi/fn Inc." "Moore","Robert","IBM" "Mundy","Russ","Trusted Information Systems Inc." "Murai","Jun","Keio University" "Murphy","John ","AT&T" "Murphy","Sandra","Trusted Information Systems Inc." "Mutz","Andrew","Hewlett-Packard Company" "Napjus","Erikas","Carnegie Mellon University" "Narayana","Raj","Cable & Wireless" "Narten","Thomas","IBM Corporation" "Newell","Tom","Network Solutions Inc./InterNIC" "Ng","Forrest","HK Supernet" "Nguyen","Liem","NetEdge Systems Inc." "Nicolls","Weston","National Security Agency" "Northlich","William","Onlive! Technologies" "Ollikainen","Ari","Sprint Advanced Technology Laboratories" "Parker","Brad","American Internet Corp" "Partan","Andrew","WNA" "Pereira","Roy","TimeStep Corporation" "Petke","Rich","CompuServe Inc." "Poepping","Mark","Carnegie Mellon University" "Polinsky","Steven ","Goldman Sachs & Co." "Resnick","Pete","QUALCOMM Incorporated" "Rex","Martin","SAP AG" "Reynolds","Joyce","Information Sciences Institute" "Rogerson","Duncan","University of London/JANET" "Romascanu","Dan","Madge Networks Ltd." "Rose","Marshall","First Virtual Holdings Incorporated" "Rosselli","Michael","AssureNet Pathways" "Ruth","Gregory","GTE Laboratories Inc." "Saito","Takeshi ","Toshiba" "Sanchez","Luis","BBN Corporation" "Sarmiento","Ramiro","Sun Microsystems Inc." "Scholl","Reinhard","Siemens AG" "Shepard","Timothy","BBN Systems & Technologies" "Shimazu","Yoshihiro","Internet Initiative Japan Inc." "Showalter","Timothy","Carnegie Mellon University" "Siebel","Christian","DTAG" "Singh","Jasdip","Network Solutions Inc." "Smith","Bruce","Gigalabs" "Smith","Kenneth","Nortel" "Solensky","Frank","FTP Software" "Solomon","Jim","Motorola" "Sommerfeld","Bill","Hewlett Packard" "Stefferud","Einar","Network Management Associates Inc." "Stewart","Bob","cisco Systems" "Stewart III","John","USC/ISI" "Stockman","Bernhard","Telia AB" "Sundell","Kenneth","Ericsson Infocom" "Suzuki","Muneyoshi","NTT Multimedia Networks Labs." "Suzuki","Shigeya","Foretune Co. Ltd." "Taylor","Peter","Mailbase University of Newcastle" "Teraoka","Fumio","Sony Computer Science Lab. Inc." "Thomas","Matt","Digital Equipment Corp" "Thomas","Stephen","AT&T Tridom" "Topolcic","Claudio","BBN Corp" "Tow","Agnes","AT&T" "Townsley","W.","IBM" "Traina","Paul","Juniper Networks" "Troll","Ryan","Carnegie Mellon University" "Ts'o","Theodore","MIT" "Tsukada","Koji","Hitachi Ltd." "Veach","Ross","CICNet" "Vozza","Vincenzo","Telecom Italia DRE/TA" "Wall","Matt","Carnegie Mellon University" "Wallack","Todd","Network World" "Watt","James","Newbridge Networks Corporation" "Weiler","Sam","Carnegie Mellon University" "Welch","Arun","CompuServe" "West","Jim ","CIENA" "White","Dan","Bay Networks" "Wijnen","Bert","IBM" "Williamson","Scott","Network Solutions Inc." "Wong","Walter","Carnegie Mellon Unviersity" "Wood","David","NATO C3 Agency" "Wrege","Dallas","IBM" "Yaguchi","Tomokazu ","Telecomet Inc " "Zilles","Stephen","Adobe System Inc." "Zorn","Glen","Microsoft Corporation"   Received: from cnri by ietf.org id aa25223; 19 Feb 97 13:21 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23048; 19 Feb 97 13:21 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Wed, 19 Feb 1997 15:57:30 GMT Message-Id: <9702191557.AA18008@MIT.EDU> Date: Wed, 19 Feb 1997 10:56:08 EST From: pfh@uk.ibm.com To: cat-ietf@mit.edu X-Sender-Info: Paul Ford-Hutchinson Classification: -- NONE -- Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ftp extensions Precedence: bulk *** Resending note of 19/02/97 15:41 > OOOPS - typo on the PROT parm (a rather important one at that !!) -Is it reasonable, within the spirit of the document, to state the following. "An FTP control connection, initiated on the TLS protected ftp well known port can be assumed to be in a similar state as if the client had connected to the standard ftp port and issued (successfully) AUTH TLS PBSZ 0 PROT P" I really need to be able to say this to allow a migration path from the existing (?) ftp/ssl implementations which simply define a new port and then assume that all data connections will be protected. Paul   Received: from cnri by ietf.org id aa27806; 19 Feb 97 13:51 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23830; 19 Feb 97 13:51 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Wed, 19 Feb 1997 15:48:14 GMT Message-Id: <9702191548.AA18509@MIT.EDU> Date: Wed, 19 Feb 1997 10:46:34 EST From: pfh@uk.ibm.com To: cat-ietf@mit.edu X-Sender-Info: Paul Ford-Hutchinson Classification: -- NONE -- Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ftp extensions Precedence: bulk Sorry if I am going over old territory here, but I am in the process of re-writing a draft describing how to mash ftp, tls and cat together, which has prompted some issues with draft-ietf-cat-ftpsec-09 - The AUTH command to negotiate a security mechanism covers the control port. In the case of TLS, this will be all that is required for the control connection, the commands ADAT, MIC, CCC and ENC are not necessary. My questions are really about the data connection. It appears desirable to use the PROT command to define whether a particular data connection requires protection or not, however, in the context of TLS, the PBSZ is not required. I understand that it makes sense to insist on a PBSZ, not have a default etc... etc..., however, for TLS (which appears to the FTP application as a streaming encryption mechanism), PBSZ has no meaning. So my question is ... can you either a) - remove the requirement to issue a PBSZ b) - allow a value on PBSZ of, say 0, to mean 'a streaming mechanism requiring no application layer buffering and not requiring the block length 4 chars at the start of each block'. (I prefer b)) -I presume that the PROT command protects all data channels until the next PROT command (or QUIT. or AUTH if you wanna be picky) -Is it reasonable, within the spirit of the document, to state the following. "An FTP control connection, initiated on the TLS protected ftp well known port can be assumed to be in a similar state as if the client had connected to the standard ftp port and issued (successfully) AUTH TLS PBSZ 0 PROT C" I really need to be able to say this to allow a migration path from the existing (?) ftp/ssl implementations which simply define a new port and then assume that all data connections will be protected. Thanks for your time, Paul -.--.---.----.-----.----.---.--.--.---.----.-----.----.---.--.- Paul Ford-Hutchinson FORDHUP @ NHBVM9 (GBIBMLLL @ IBMMAIL) IGN EDI Products Development and Support. (pfh@uk.ibm.com) Warwick (OSU-1) +44 (0)1926 464836 : tie (7)66 4836   Received: from ietf.org by ietf.org id aa03270; 19 Feb 97 15:27 EST Received: from ietf.ietf.org by ietf.org id aa02955; 19 Feb 97 15:20 EST To: IETF-Announce: ; Subject: Internet-Draft CUTOFF Date Date: Wed, 19 Feb 1997 15:20:56 -0500 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9702191520.aa02955@ietf.org> The cut-off for Internet-Draft submissions prior to the Memphis IETF meeting is Wednesday, March 26, 1997 at 5pm ET. Internet-Drafts received after this time will not be announced nor made available in the Internet-drafts Directories. We will begin processing Internet-Draft submissions the week following the IETF meeting. Thank you for your understanding and cooperation. Please do not hesitate to contact me if you have any questions or concerns. Kind Regards, Cynthia Clark Internet-Drafts Administrator   Received: from ietf.org by ietf.org id aa05942; 19 Feb 97 16:14 EST Received: from cnri by ietf.org id aa05609; 19 Feb 97 16:09 EST Received: from actcom.co.il by CNRI.Reston.VA.US id aa27892; 19 Feb 97 16:09 EST Received: from localhost by actcom.co.il with SMTP (8.8.4/actcom-0.1) id XAA26285; Wed, 19 Feb 1997 23:06:04 +0200 (EET) (rfc931-sender: hayam@localhost) Date: Wed, 19 Feb 1997 23:06:02 +0200 (EET) Sender:ietf-request@ietf.org From: Avraham Hayam To: "u.bachmann" cc: "'ALEPH1@UNDERGROUND.ORG'" , "'firewalls@GreatCircle.COM'" , "'ids@uow.edu.au'" , "'ieft-tls@w3.org'" , "'ietf@cnri.reston.va.us'" , "'lacc@suburbia.net'" , "'sod@command.com.inter.net'" , "'www-security@ns2.Rutgers.EDU'" Subject: Re: Security & Hackerscene update In-Reply-To: <01BC1A7C.9F1A5060@Ulrich Bachmann> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Hi, Most interesting and of help. Thank you Avraham Hayam   Received: from ietf.org by ietf.org id aa22611; 20 Feb 97 0:13 EST Received: from relay-7.mail.demon.net by ietf.org id aa22462; 20 Feb 97 0:07 EST Received: from eidos.demon.co.uk ([158.152.55.149]) by relay-6.mail.demon.net id aa629433; 20 Feb 97 5:04 GMT Received: from leigh.eidos.co.uk by leigh.eidos.co.uk (NTMail 3.02.10) with ESMTP id ma015118 for ; Thu, 20 Feb 1997 04:03:52 +0000 Sender:ietf-request@ietf.org From: "PostMaster@eidos.co.uk" To: "ietf@ietf.org" Subject: Failed mail: exceeded hop count Date: Thu, 20 Feb 1997 04:03:52 +0000 Return-Path: <> Message-Id: <04035255107535@eidos.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="==04035255107536==" Source-Info: From (or Sender) name not authenticated. This is a MIME-encapsulated message --==04035255107536== Content-Type: text/plain; charset=us-ascii This mail message has exceeded the maximum number of hops. The requested destination was: general@techsupport.eidos.co.uk The text of the message follows: --==04035255107536== Content-Type: message/rfc822 Received: from relay-6.mail.demon.net by mailstore for general@techsupport.eidos.co.uk id 856411535:6:16436:1; Thu, 20 Feb 97 04:05:35 GMT Received: from eidos.demon.co.uk ([158.152.55.149]) by relay-6.mail.demon.net id aa616238; 20 Feb 97 4:04 GMT Received: from leigh.eidos.co.uk by leigh.eidos.co.uk (NTMail 3.02.10) with ESMTP id ka015116 for ; Thu, 20 Feb 1997 03:05:05 +0000 Received: from relay-6.mail.demon.net by mailstore for general@techsupport.eidos.co.uk id 856407937:6:03250:1; Thu, 20 Feb 97 03:05:37 GMT Received: from eidos.demon.co.uk ([158.152.55.149]) by relay-6.mail.demon.net id aa602990; 20 Feb 97 3:04 GMT Received: from leigh.eidos.co.uk by leigh.eidos.co.uk (NTMail 3.02.10) with ESMTP id fa015111 for ; Thu, 20 Feb 1997 02:04:17 +0000 Received: from relay-5.mail.demon.net by mailstore for general@techsupport.eidos.co.uk id 856404286:5:02615:2; Thu, 20 Feb 97 02:04:46 GMT Received: from eidos.demon.co.uk ([158.152.55.149]) by relay-5.mail.demon.net id aa502576; 20 Feb 97 2:04 GMT Received: from leigh.eidos.co.uk by leigh.eidos.co.uk (NTMail 3.02.10) with ESMTP id za015105 for ; Thu, 20 Feb 1997 01:03:52 +0000 Received: from relay-5.mail.demon.net by mailstore for general@techsupport.eidos.co.uk id 856400680:5:12216:0; Thu, 20 Feb 97 01:04:40 GMT Received: from eidos.demon.co.uk ([158.152.55.149]) by relay-5.mail.demon.net id aa512179; 20 Feb 97 1:04 GMT Received: from leigh.eidos.co.uk by leigh.eidos.co.uk (NTMail 3.02.10) with ESMTP id wa015102 for ; Thu, 20 Feb 1997 00:03:35 +0000 Received: from relay-5.mail.demon.net by mailstore for general@techsupport.eidos.co.uk id 856397083:5:19177:3; Thu, 20 Feb 97 00:04:43 GMT Received: from eidos.demon.co.uk ([158.152.55.149]) by relay-5.mail.demon.net id aa519137; 20 Feb 97 0:04 GMT Received: from leigh.eidos.co.uk by leigh.eidos.co.uk (NTMail 3.02.10) with ESMTP id qa015096 for ; Wed, 19 Feb 1997 23:03:39 +0000 Received: from relay-10.mail.demon.net by mailstore for general@techsupport.eidos.co.uk id 856393524:10:09398:5; Wed, 19 Feb 97 23:05:24 GMT Received: from eidos.demon.co.uk ([158.152.55.149]) by relay-11.mail.demon.net id aa1101041; 19 Feb 97 23:05 GMT Received: from leigh.eidos.co.uk by leigh.eidos.co.uk (NTMail 3.02.10) with ESMTP id na015093 for ; Wed, 19 Feb 1997 22:23:58 +0000 Received: from relay-10.mail.demon.net by mailstore for general@techsupport.eidos.co.uk id 856391084:10:23046:3; Wed, 19 Feb 97 22:24:44 GMT Received: from alpha1.superonline.com ([194.242.73.12]) by relay-10.mail.demon.net id aa1022663; 19 Feb 97 22:23 GMT Received: from bulent-uludag ([194.242.78.61]) by alpha1.superonline.com (Netscape Mail Server v2.0) with ESMTP id AAA19802 for ; Thu, 20 Feb 1997 00:21:51 +0300 From: "IETF" To: Subject: Tomb Raider Lovers... Date: Wed, 19 Feb 1997 00:18:04 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-9 Content-Transfer-Encoding: 7bit Message-ID: <856391027.1022663.0@alpha1.superonline.com> We love Tomb Raider! It's a great game... In Turkey, the Diamond cards are very popular, especially the late one, the Diamond 3D 2000 is highly sold.. Why not make a patch for it like you did for the Matrox Mistique? I mean not a patch for especially the Diamond 3D 2000, but a patch for S3 VIRGE chipset would satisfy us - all Tomb Raider lovers.. And I think it could effect your sales... Please think of it.. Thank you.. Bulent ULUDAG --==04035255107536==--   Received: from ietf.org by ietf.org id aa26571; 20 Feb 97 4:27 EST Received: from strowger.pass.theplanet.net by ietf.org id aa26423; 20 Feb 97 4:21 EST Received: from office(really [194.152.71.165]) by strowger.pass.theplanet.net via sendmail with smtp id for ; Thu, 20 Feb 97 09:19:22 +0000 (GMT) (/\##/\ Smail3.1.30.16 #30.4 built 29-jan-96) Message-ID: <330C169D.4F85@pop.prestel.co.uk> Date: Thu, 20 Feb 1997 09:17:17 +0000 Sender:ietf-request@ietf.org From: Clive Loseby Reply-To: prs93dw2@pop.prestel.co.uk Organization: Rather Good Productions Ltd X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: "IETF Cubase-users@mcc.ac.uk" Subject: Re: Can't take all... ---> It's handled... References: <199702191121.LAA24260@hades.mcc.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. I bundled all his e-mails up and sent it back with a 'No thank you' message. The file was too big and was returned by the server. The attachments were visible and consisted of a least two disgusting hard-core pornographic pictures. I hope this man is dealt with. There are Cubase Users under the age of 16 - sending them unsolicited pictures of this nature is surely an offence. Clive Loseby   Received: from ietf.org by ietf.org id aa03006; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01526; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-naptr-02.txt Date: Thu, 20 Feb 1997 09:35:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01526@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 : Resolution of Uniform Resource Identifiers using the Domain Name System Author(s) : R. Daniel, M. Mealling Filename : draft-ietf-urn-naptr-02.txt Pages : 14 Date : 02/19/1997 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. 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-naptr-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-naptr-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219104118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-naptr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-naptr-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219104118.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa02996; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01604; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-guaranteed-svc-07.txt Date: Thu, 20 Feb 1997 09:35:23 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01604@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 Services Working Group of the IETF. Title : Specification of Guaranteed Quality of Service Author(s) : S. Shenker, C. Partridge, R. Guerin Filename : draft-ietf-intserv-guaranteed-svc-07.txt Pages : 21 Date : 02/19/1997 This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. This specification follows the service specification template described in [1]. 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-intserv-guaranteed-svc-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-guaranteed-svc-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-guaranteed-svc-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219150551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-guaranteed-svc-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-guaranteed-svc-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219150551.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03011; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01494; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-mansigian-00.txt Date: Thu, 20 Feb 1997 09:35:08 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01494@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Clearing the Traffic Jam at Internet Servers A Network Layer View Of Network Traffic Consolidation Author(s) : J. Mansigian Filename : draft-rfced-info-mansigian-00.txt Pages : 8 Date : 02/19/1997 The cause of the typical glacial response from popular Internet World Wide Web servers is seldom lack of network bandwidth or any deficits in the client's equipment. The reasons for the abysmal performance are the subject server is spending an inordinate amount of time managing two problems; an unnecessarily large number of TCP connections and masses of redundant data that are received and transmitted without optimization. This work addresses both problems. 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-mansigian-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-mansigian-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-mansigian-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219102925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-mansigian-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-mansigian-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219102925.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03008; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01478; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mboned@ns.uoregon.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mboned-limit-rate-guide-00.txt Date: Thu, 20 Feb 1997 09:35:05 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01478@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : Guidelines for Rate Limits on the MBONE Author(s) : D. Junkins Filename : draft-ietf-mboned-limit-rate-guide-00.txt Pages : 3 Date : 02/19/1997 Much confusion and misunderstanding exists in the Internet community on the use of rate limits on the Multicast Backbone (MBONE). This document dispels some of the misunderstandings of rate limits and describes the best current practices for when to implement rate limits on MBONE links. It is a product of the Multicast Deployment Working Group in the Operational Requirements area of the Internet Engineering Task Force. Submit comments to or the author. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mboned-limit-rate-guide-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-limit-rate-guide-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mboned-limit-rate-guide-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219095142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mboned-limit-rate-guide-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mboned-limit-rate-guide-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219095142.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03009; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01623; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-radius@livingston.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radius-eap-00.txt Date: Thu, 20 Feb 1997 09:35:25 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01623@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : Extensible Authentication Protocol Support in RADIUS Author(s) : P. Calhoun, A. Rubens, B. Aboba Filename : draft-ietf-radius-eap-00.txt Pages : 12 Date : 02/19/1997 The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This document describes how the EAP-Message and Signature attributes may be used for providing EAP support within RADIUS. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-eap-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-radius-eap-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-radius-eap-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219151428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-eap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-eap-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219151428.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03007; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01510; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-amsden-00.txt Date: Thu, 20 Feb 1997 09:35:10 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01510@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Light-weight Flow Admission Protocol Specification Version 1.0 Author(s) : P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons Filename : draft-rfced-info-amsden-00.txt Pages : 19 Date : 02/19/1997 Light-weight Flow Admission Protocol, LFAP, allows an external Flow Admission Service (FAS) to manage flow admission at the switch, allowing flexible Flow Admission Services to be deployed by a vendor or customer without changes to, or undue burden on, the switch. Specifically, this document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. Using LFAP, a Flow Admission Service can: allow or disallow flows, define the parameters under which a given flow is to operate (operating policy) or, redirect the flow to an alternate destination. The FAS may also maintain details of current or historical flows for billing, capacity planning and other purposes. 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-amsden-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-amsden-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-amsden-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219103428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-amsden-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-amsden-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219103428.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03002; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01564; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-http-conv-01.txt Date: Thu, 20 Feb 1997 09:35:17 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01564@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 : A Trivial Convention for using HTTP in URN Resolution Author(s) : R. Daniel Filename : draft-ietf-urn-http-conv-01.txt Pages : 6 Date : 02/19/1997 The Uniform Resource Names Working Group (URN-WG) was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrieve the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal specifies how a client may find a "resolver" for a URN. A resolver is a database that can provide information about the resource identified by a URN, such as the resource's location, a bibliographic description, or even the resource itself. The protocol used for the client to communicate with the resolver is not specified in the NAPTR proposal. Instead, the NAPTR resource record provides a field that indicates the "resolution protocol" and "resolution service requests" offered by the resolver. This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. The primary goal of THTTP is to be simple to implement so that existing HTTP servers may easily add support for URN resolution. We expect that the databases used by early resolvers will be useful when more sophisticated esolution protocols are developed later. 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-http-conv-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-http-conv-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219105545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-http-conv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-http-conv-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219105545.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03010; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01565; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: madman@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-madman-dsa-mib-1-02.txt Date: Thu, 20 Feb 1997 09:35:19 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01565@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mail and Directory Management Working Group of the IETF. Title : LDAP/CLDAP/X.500 Directory Services Monitoring MIB Author(s) : G. Mansfield, S. Kille Filename : draft-ietf-madman-dsa-mib-1-02.txt Pages : 21 Date : 02/19/1997 This document defines a portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory Services. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring Directory Servers (DS)s. 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-madman-dsa-mib-1-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-madman-dsa-mib-1-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-madman-dsa-mib-1-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219110629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-madman-dsa-mib-1-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-madman-dsa-mib-1-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219110629.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa02995; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01592; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ppp@merit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-bacp-06.txt Date: Thu, 20 Feb 1997 09:35:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01592@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) Author(s) : C. Richards, K. Smith Filename : draft-ietf-pppext-bacp-06.txt Pages : 22 Date : 02/19/1997 This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol [2]. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co-ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-bacp-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-bacp-06.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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-bacp-06.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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219140614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bacp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bacp-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219140614.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa02997; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01543; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-armitage-ion-venus-01.txt Date: Thu, 20 Feb 1997 09:35:15 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01543@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : VENUS - Very Extensive Non-Unicast Service Author(s) : G. Armitage Filename : draft-armitage-ion-venus-01.txt Pages : 12 Date : 02/19/1997 The MARS model is our current solution to IP multicasting over ATM, establishing and managing the use of ATM pt-mpt SVCs for intra-LIS IP multicast packet forwarding. Inter-LIS multicast forwarding is achieved using Mrouters, in a similar manner to which the `Classical IP over ATM' model uses Routers to inter-connect LISes for unicast traffic. The development of unicast IP shortcut mechanisms (e.g. NHRP) has led some people to request the development of a Multicast equivalent. This document describes a hypothetical solution, dubbed `Very Extensive NonUnicast Service' (VENUS), shows how complex such a service would be, and asserts that analogies with unicast shortcut mechanisms are not entirely appropriate. It is also noted that VENUS ultimately has the look and feel of a single, large cluster using a distributed MARS. This document is being issued to help focus ION efforts. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-armitage-ion-venus-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-armitage-ion-venus-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-armitage-ion-venus-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970219105413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-armitage-ion-venus-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-armitage-ion-venus-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219105413.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13970; 20 Feb 97 12:35 EST Received: from strowger.pass.theplanet.net by ietf.org id aa13587; 20 Feb 97 12:31 EST Received: from office(really [194.152.71.33]) by strowger.pass.theplanet.net via sendmail with smtp id for ; Thu, 20 Feb 97 15:03:29 +0000 (GMT) (/\##/\ Smail3.1.30.16 #30.4 built 29-jan-96) Message-ID: <330C6742.3D4B@pop.prestel.co.uk> Date: Thu, 20 Feb 1997 15:01:22 +0000 Sender:ietf-request@ietf.org From: Clive Loseby Reply-To: prs93dw2@pop.prestel.co.uk Organization: Rather Good Productions Ltd X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ietf@ietf.org Subject: Complaint about spammer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Sorry, I appear to got my wires/addresses crossed when I sent my previous mail. Apologies for any confusion. Clive Loseby   Received: from ietf.org by ietf.org id aa18118; 20 Feb 97 13:15 EST Received: from ietf.ietf.org by ietf.org id aa18052; 20 Feb 97 13:13 EST To: ietf@ietf.org Subject: Embedded Web Technology Workshop Sender:ietf-request@ietf.org From: "Burton H. Lee" Date: Thu, 20 Feb 1997 13:13:31 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702201313.aa18052@ietf.org> Source-Info: From (or Sender) name not authenticated. Call for Papers and Participation Workshop on Embedded Web/Internet Technologies April 7, 1997 Santa Clara, CA 6th International World Wide Web Conference Sponsored by Stanford University The Call for Papers (CFP) is available at: http://diagnostics.stanford.edu/www6/EWTWorkshopCFP.html This workshop is open to all members of the public. Please see the CFP for Paper Submission and Registration details. Thank you. -- Burton H. Lee blee@cdr.stanford.edu   Received: from ietf.org by ietf.org id aa20310; 20 Feb 97 13:55 EST Received: from zephyr.isi.edu by ietf.org id aa20108; 20 Feb 97 13:50 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 20 Feb 1997 10:48:15 -0800 Message-Id: <199702201848.AA24055@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2102 on Nimrod Multicast Support Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 20 Feb 97 10:48:15 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2102: Title: Multicast Support for Nimrod : Challenges and Solution Approaches Author: R. Ramanathan Date: February 1997 Mailbox: ramanath@bbn.com Pages: 23 Characters: 50962 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2102.txt Nimrod does not specify a particular solution for multicasting. Rather, Nimrod may use any of a number of emerging multicast techniques. This document identifies the requirements that Nimrod has of a solution for multicast support. This document is a product of the New Internet Routing and Addressing Working Group of the IETF. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970220104311.RFC@ISI.EDU> SEND /rfc/rfc2102.txt --OtherAccess Content-Type: Message/External-body; name="rfc2102.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970220104311.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04286; 21 Feb 97 10:10 EST Received: from ietf.ietf.org by ietf.org id aa02933; 21 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-mixer@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kille-mixer-rfc1327bis-04.txt Date: Fri, 21 Feb 1997 09:43:19 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702210943.aa02933@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME - X.400 Gateway Working Group of the IETF. Title : MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME Author(s) : S. Kille Filename : draft-kille-mixer-rfc1327bis-04.txt Pages : 172 Date : 02/20/1997 This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. Any reference to the 1984 Recommendations will be explicit. Any mappings relating to elements which are in the 1992 version and not in the 1988 version will be noted explicitly. X.400 defines an Interpersonal Messaging System (IPMS), making use of a store and forward Message Transfer System. This document relates to the IPMS, and not to wider application of X.400, such as EDI as defined in X.435. 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-kille-mixer-rfc1327bis-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kille-mixer-rfc1327bis-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kille-mixer-rfc1327bis-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970220162752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kille-mixer-rfc1327bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-kille-mixer-rfc1327bis-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970220162752.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04288; 21 Feb 97 10:10 EST Received: from ietf.ietf.org by ietf.org id aa02949; 21 Feb 97 9:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-martel-bootp-mixedlinklayers-00.txt Date: Fri, 21 Feb 1997 09:43:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702210943.aa02949@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BOOTP and DHCP on Mixed Media Link-Layer Networks Author(s) : S. Martel, W. Wimer Filename : draft-martel-bootp-mixedlinklayers-00.txt Pages : 8 Date : 02/20/1997 RFCs 951 [1], 1541 [2], and 1542 [3] describe the interactions of BOOTP [1] and DHCP [2] client, server, and relay agents. However, further experience with these protocols has revealed the existence of an interoperability issue. The issue occurs when a given IP subnet is constructed over one link-layer network inter-connected by translational bridges to other dissimilar link-layer networks. The following information attempts to address this problem. It is impossible for a BOOTP or DHCP client, server, or relay agent to know in advance whether or not it will be operating in a mixed media link-layer network environment. Given this fact, all BOOTP and DHCP client, server, and relay agents SHOULD adopt the recommendations defined in this memo. 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-martel-bootp-mixedlinklayers-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-martel-bootp-mixedlinklayers-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-martel-bootp-mixedlinklayers-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970220171429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-martel-bootp-mixedlinklayers-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-martel-bootp-mixedlinklayers-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970220171429.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa15852; 21 Feb 97 13:30 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa19153; 21 Feb 97 13:30 EST Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id MAA03964 for uri-out; Fri, 21 Feb 1997 12:40:26 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA03937; Fri, 21 Feb 1997 12:39:47 -0500 (EST) Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04329 (mail destined for urn-ietf@services.bunyip.com); Fri, 21 Feb 97 12:39:46 -0500 Received: from beach.w3.org by MINTAKA.LCS.MIT.EDU id aa04054; 21 Feb 97 12:21 EST Message-Id: <330DD97C.D6F7D91@w3.org> Date: Fri, 21 Feb 1997 11:21:00 -0600 From: Dan Connolly Organization: World Wide Web Consortium X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.18 i586) Mime-Version: 1.0 To: touch@isi.edu Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: URI-protocol mapping (was Re: How to add new "protocols" ?) References: <199702211554.AA05345@ash.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk touch@ISI.EDU wrote: > > > OK, I'll bite: how is it that "location-dependent" vs. > > "location-independent" is a technical distinction? > It's very technical. The host requirements RFC specifies locations > as either fully-qualified DNS names or IP addresses. And that's what > you have here. I.e., you have as much of a location as the internet > allows. Ah! I wan't aware of that. I really appreciate you pointing that out. OK, I'm happy with 'location-independent' as a technical term if 'location' is defined as 'FQDN or IP address'. I inferred the more geographic connotations. I want that in the specs though. If I didn't know it, I'm sure lots of other folks didn't know it. A quick scan of the URN requirements/framework draft[1] and the URN requirements RFC[2] doesn't show a similar definition of 'location'. And there's no reference to the host requirements RFC. Hang on... I went to add it to my glossary of web architecture terms[3], but a brief scan of the host requirements RFC[4] shows: |the DNS provides globally-unique, | location-independent names. If a FQDNs are locations, how does DNS provide location-independent names? In fact, I don't see this definition of location that you refer to at all in the host requirements RFC[4]. Could you elaborate? [1] ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-req-frame-00.txt [2] http://ds.internic.net/rfc/rfc1737.txt [3] http://www.w3.org/pub/WWW/Architecture/Terms [4] ftp://ftp.math.utah.edu/pub/rfc/rfc1123.txt   Received: from cnri by ietf.org id aa22339; 21 Feb 97 17:46 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25880; 21 Feb 97 17:46 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Fri, 21 Feb 1997 20:33:34 GMT Mime-Version: 1.0 Date: Fri, 21 Feb 1997 15:35:16 -0500 Message-Id: <30E03C70.1953@securid.com> From: Riaz Zolfonoon Subject: a few questions on SPKM (RFC2025) To: cat-ietf@mit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Precedence: bulk I'm new to this list so my appologies if these questions have been asked already. 1) What is the current status of RFC 2025? 2) Are there any reference and/or public domain implementations of this RFC available? If so, could someone provide a pointer? regards, Riaz ================================================================ Riaz Zolfonoon email:rzolfonoon@securid.com Security Dynamics Inc. http://www.securid.com 20 Crosby Drive phone:(617) 687-7636 Bedford MA 01730   Received: from ietf.org by ietf.org id aa17046; 22 Feb 97 14:25 EST Received: from [206.103.249.22] by ietf.org id aa16729; 22 Feb 97 14:14 EST Received: from woody.aiinet.com (woody.aiinet.com [206.103.249.30]) by aisun.aiinet.com (8.7.3/8.7.3) with SMTP id OAA18780 for ; Sat, 22 Feb 1997 14:12:47 -0500 (EST) Received: by woody.aiinet.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC20C9.2287C610@woody.aiinet.com>; Sat, 22 Feb 1997 14:03:09 -0500 Message-ID: Sender:ietf-request@ietf.org From: "Bond, Andrew" To: "'ietf@ietf.org'" Subject: RE: I-D ACTION:draft-kille-mixer-rfc1327bis-04.txt Date: Sat, 22 Feb 1997 14:03:08 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 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 ietf.org list: >andrewb@aiinet.com   Received: from ietf.org by ietf.org id aa19208; 22 Feb 97 16:46 EST Received: from edu.lahti.fi by ietf.org id aa19136; 22 Feb 97 16:43 EST Received: (qmail 5768 invoked by uid 1067); 22 Feb 1997 21:43:40 -0000 Date: Sat, 22 Feb 1997 23:43:40 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni To: Valdis.Kletnieks@vt.edu cc: ietf@ietf.org Subject: Re: New Ideas for a WWW standard (fwd) In-Reply-To: <199702171637.LAA25130@black-ice.cc.vt.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Mon, 17 Feb 1997 Valdis.Kletnieks@vt.edu wrote: > Using "fancy functions with minimal work" is the online equivalent of > working in a wood shop with power tools without bothering to learn > basic shop safety. Very much agreed. And I certainly don't like the idea of people stuffing all kinds of unappropriate extensions into otherwise clean languages such as HTML. But nevertheless one of the things that people expect from this technology is usability. And it's true that it's much harder to learn to do Java badly than to do HTML pretty well. Programming in conventional languages is harder even for professionals. And that brings up costs. And as I said earlier, using procedural languages to create content does real harm to searching and autoindexing functions... > Umm.. actually, the Net itself *didnt* develop on Unix. It only got > *popular* when BSD came with a free networking API (in the form of sockets). Indeed. But many of the Net's current functions have developed a lot over the years and most of the development has been on UNIX. Like the sockets and all... But I stand corrected. My sense of early Net history is a bit weak... Sampo Syreeni (Decoy/dAWN), student,   Received: from ietf.org by ietf.org id aa20811; 22 Feb 97 17:57 EST Received: from edu.lahti.fi by ietf.org id aa20737; 22 Feb 97 17:55 EST Received: (qmail 5925 invoked by uid 1067); 22 Feb 1997 22:55:47 -0000 Date: Sun, 23 Feb 1997 00:55:47 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni To: IETF list Subject: Re: New Ideas for a WWW standard (fwd) In-Reply-To: <199702172125.NAA08268@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Mon, 17 Feb 1997, MegaZone wrote: > >But Java has its problems as well: it requires in depth knowledge of (OO) > >programming. I we do that but how about the average Net user that just > >wants fancy functions with minimal work? > > There are already pubically available applets that the average user can > plugin and use, and there are tools for easy applet creation. I believe > MacroMedia already has a decent tool for this on the market. But it's still a procedural language and thus has its problems when used for content creation. It's very good, though, that we'll soon be able to do real RAD with Java. The critical mass seems to be forming out there... Sampo Syreeni (Decoy/dAWN), student,   Received: from ietf.org by ietf.org id aa08450; 23 Feb 97 8:15 EST Received: from cnri by ietf.org id aa08334; 23 Feb 97 8:10 EST Received: from [208.1.117.133] by CNRI.Reston.VA.US id aa08149; 23 Feb 97 8:10 EST Received: from postoffice.world.att.net (228.los-angeles-001.ca.dial-access.att.net [207.147.200.228]) by georgia.sallynet.com (8.7.3/8.7.3) with SMTP id FAA10781 for ; Sun, 23 Feb 1997 05:08:17 -0800 (PST) Date: Sun, 23 Feb 1997 05:08:17 -0800 (PST) Sender:ietf-request@ietf.org From: "voccnet.com" Message-Id: <199702231308.FAA10781@georgia.sallynet.com> To: ietf@CNRI.Reston.VA.US Subject: The Virtual Office Source-Info: From (or Sender) name not authenticated. Virtual Office Communications Company is proud to announce the new technology of having one 800/888 number that is your: home, office, fax, voice-mail, E-mail, pager, # etc..To learn more visit: http://www.vocc.com To be removed from our mailing list, please reply with remove in the subject. All others will remain on the mailing list. Cordially, Vocc   Received: from ietf.org by ietf.org id aa27733; 23 Feb 97 23:28 EST Received: from cnri by ietf.org id aa27557; 23 Feb 97 23:16 EST Received: from comsun.comm.utoronto.ca by CNRI.Reston.VA.US id aa00390; 23 Feb 97 23:16 EST Received: by comsun.comm.toronto.edu id <33618>; Sun, 23 Feb 1997 23:14:08 -0500 Sender:ietf-request@ietf.org From: Irene Katzela To: cnom@maestro.bellcore.com, comsoc-chapter@ieee.org, comsoc-itii@ieee.com, dbworld@cs.wisc.edu, ieeetcpc@ccvm.sunysb.edu, ietf@CNRI.Reston.VA.US, itc@focus.gmd.de, modern-heuristics@uk.ac.mailbase.ucdavis.edu, tccc@ieee.org Content-Length: 3773 Message-Id: <97Feb23.231408est.33618@comsun.comm.toronto.edu> Date: Sun, 23 Feb 1997 23:13:54 -0500 Source-Info: From (or Sender) name not authenticated. *********************************************************************** 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@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@comm.utoronto.ca, or the editors of MC2R at editors@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@comm.utoronto.edu email: bahl@samson.enet.dec.com ASSOCIATE EDITOR ASSOCIATE EDITOR Charles Perkins (IBM) Jason Redi (BCN) ****************************************************************************   Received: from ietf.org by ietf.org id aa02385; 24 Feb 97 4:09 EST Received: from dns.doruk.net.tr by ietf.org id aa02254; 24 Feb 97 4:08 EST Sender:ietf-request@ietf.org From: Doruk-BBS Forum Servisi To: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Date: Mon, 24 Feb 97 11:05:05 TSI Subject: "oyun-f" grup uyeligine kabulunuz Message-ID: <9702241105.aa12538@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Sayin "IETF", "oyun-f" forum grubuna hos geldiniz, gruba gonderilen butun mektuplar size, sizin gruba gonderdiginiz mektuplar diger grup uyelerine iletilecektir. Gruba gonderilen mektuplarin kopyasi, grubun konusu ile ilgili dosyalar ve programlar grup kutuphanesinde saklanmaktadir. Forum servisinden "Forum Dosya Indeksini" alip, dosya alma servisini kullanarak forum kutuphanesine erisebilirsiniz. Gruptan ayrilmak icin forum servisinde Ayril secenegine "oyun-f" grup adini girmeniz yeterli olacaktir. Doruk-BBS Forum Servisi   Received: from ietf.org by ietf.org id aa02383; 24 Feb 97 4:09 EST Received: from dns.doruk.net.tr by ietf.org id aa02210; 24 Feb 97 4:07 EST Errors-To: forum-error@doruk.com.tr Reply-To: forum-error@doruk.com.tr Sender:ietf-request@ietf.org From: Doruk-BBS Forum Servisi To: ietf@ietf.org Date: Mon, 24 Feb 97 13:03:00 TSI Subject: Re: Mektubunuza cevap Message-ID: <9702241103.aa12345@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. >---------- : Taninmayan komut... "Yardim" komutunu deneyin. >From: forum@doruk.com.tr : Taninmayan komut... "Yardim" komutunu deneyin. >To: sonic : Taninmayan komut... "Yardim" komutunu deneyin. >Subject: DorukNet pc-muzik-f forumu : Taninmayan komut... "Yardim" komutunu deneyin. >Date: 22 *ubat 1997, Cumartesi 17:51 : Taninmayan komut... "Yardim" komutunu deneyin. >basvur pc-muzik-f : "pc-muzik-f" grubuna eklendiniz. ---------------------- Doruk-BBS Forum Servisi ----------------------   Received: from ietf.org by ietf.org id aa02387; 24 Feb 97 4:09 EST Received: from dns.doruk.net.tr by ietf.org id aa02170; 24 Feb 97 4:06 EST Sender:ietf-request@ietf.org From: Doruk-BBS Forum Servisi To: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Date: Mon, 24 Feb 97 11:02:50 TSI Subject: "pc-muzik-f" grup uyeligine kabulunuz Message-ID: <9702241103.aa12342@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Sayin "IETF", "pc-muzik-f" forum grubuna hos geldiniz, gruba gonderilen butun mektuplar size, sizin gruba gonderdiginiz mektuplar diger grup uyelerine iletilecektir. Gruba gonderilen mektuplarin kopyasi, grubun konusu ile ilgili dosyalar ve programlar grup kutuphanesinde saklanmaktadir. Forum servisinden "Forum Dosya Indeksini" alip, dosya alma servisini kullanarak forum kutuphanesine erisebilirsiniz. Gruptan ayrilmak icin forum servisinde Ayril secenegine "pc-muzik-f" grup adini girmeniz yeterli olacaktir. Doruk-BBS Forum Servisi   Received: from ietf.org by ietf.org id aa02386; 24 Feb 97 4:09 EST Received: from dns.doruk.net.tr by ietf.org id ab02254; 24 Feb 97 4:08 EST Errors-To: forum-error@doruk.com.tr Reply-To: forum-error@doruk.com.tr Sender:ietf-request@ietf.org From: Doruk-BBS Forum Servisi To: ietf@ietf.org Date: Mon, 24 Feb 97 13:05:07 TSI Subject: Re: Mektubunuza cevap Message-ID: <9702241105.aa12540@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. >---------- : Taninmayan komut... "Yardim" komutunu deneyin. >From: forum@doruk.com.tr : Taninmayan komut... "Yardim" komutunu deneyin. >To: sonic : Taninmayan komut... "Yardim" komutunu deneyin. >Subject: DorukNet oyun-f forumu : Taninmayan komut... "Yardim" komutunu deneyin. >Date: 22 *ubat 1997, Cumartesi 17:51 : Taninmayan komut... "Yardim" komutunu deneyin. >basvur oyun-f : "oyun-f" grubuna eklendiniz. ---------------------- Doruk-BBS Forum Servisi ----------------------   Received: from ietf.org by ietf.org id aa02543; 24 Feb 97 4:10 EST Received: from dns.doruk.net.tr by ietf.org id aa02435; 24 Feb 97 4:10 EST Sender:ietf-request@ietf.org From: Doruk-BBS Forum Servisi To: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Date: Mon, 24 Feb 97 11:05:19 TSI Subject: "windows-f" grup uyeligine kabulunuz Message-ID: <9702241105.aa12545@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Sayin "IETF", "windows-f" forum grubuna hos geldiniz, gruba gonderilen butun mektuplar size, sizin gruba gonderdiginiz mektuplar diger grup uyelerine iletilecektir. Gruba gonderilen mektuplarin kopyasi, grubun konusu ile ilgili dosyalar ve programlar grup kutuphanesinde saklanmaktadir. Forum servisinden "Forum Dosya Indeksini" alip, dosya alma servisini kullanarak forum kutuphanesine erisebilirsiniz. Gruptan ayrilmak icin forum servisinde Ayril secenegine "windows-f" grup adini girmeniz yeterli olacaktir. Doruk-BBS Forum Servisi   Received: from ietf.org by ietf.org id aa02565; 24 Feb 97 4:11 EST Received: from dns.doruk.net.tr by ietf.org id ab02435; 24 Feb 97 4:10 EST Errors-To: forum-error@doruk.com.tr Reply-To: forum-error@doruk.com.tr Sender:ietf-request@ietf.org From: Doruk-BBS Forum Servisi To: ietf@ietf.org Date: Mon, 24 Feb 97 13:05:29 TSI Subject: Re: Mektubunuza cevap Message-ID: <9702241105.aa12550@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. >---------- : Taninmayan komut... "Yardim" komutunu deneyin. >From: forum@doruk.com.tr : Taninmayan komut... "Yardim" komutunu deneyin. >To: sonic : Taninmayan komut... "Yardim" komutunu deneyin. >Subject: DorukNet windows-f forumu : Taninmayan komut... "Yardim" komutunu deneyin. >Date: 22 *ubat 1997, Cumartesi 17:51 : Taninmayan komut... "Yardim" komutunu deneyin. >basvur windows-f : "windows-f" grubuna eklendiniz. ---------------------- Doruk-BBS Forum Servisi ----------------------   Received: from ietf.org by ietf.org id aa12362; 24 Feb 97 9:36 EST Received: from [206.103.249.22] by ietf.org id aa12197; 24 Feb 97 9:30 EST Received: from woody.aiinet.com (woody.aiinet.com [206.103.249.30]) by aisun.aiinet.com (8.7.3/8.7.3) with SMTP id JAA20694 for ; Mon, 24 Feb 1997 09:28:11 -0500 (EST) Received: by woody.aiinet.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC2233.B24BF490@woody.aiinet.com>; Mon, 24 Feb 1997 09:18:28 -0500 Message-ID: Sender:ietf-request@ietf.org From: "Bond, Andrew" To: "'ietf@ietf.org'" Subject: remove Date: Mon, 24 Feb 1997 09:18:28 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 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 list AndrewB   Received: from ietf.org by ietf.org id aa13971; 24 Feb 97 10:03 EST Received: from ietf.ietf.org by ietf.org id aa12931; 24 Feb 97 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stager-pdc-netapp-backup-01.txt Date: Mon, 24 Feb 1997 09:51:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702240951.aa12931@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Data Management Protocol Author(s) : R. Stager, D. Hitz Filename : draft-stager-pdc-netapp-backup-01.txt Pages : 76 Date : 02/20/1997 The Network Data Management Protocol (NDMP) addresses the user's need for centralized control of enterprise-wide network data management while minimizing network traffic. The design objective of the protocol is to make every network attached storage device "backup ready", enabling true plug-and-play backup operation. The user will not be required to install any additional software on an NDMP-compliant network storage device. With the NDMP approach, each network-attached file server ships with a "universal agent," which can be used by any NDMP-compliant backup administration application. For IS departments and system administrators, NDMP will ensure interoperability between different file servers and backup solutions, significantly simplifying the data management process. This same universal agent architecture is also for network-attached backup devices, such as a tape libraries. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stager-pdc-netapp-backup-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-stager-pdc-netapp-backup-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-stager-pdc-netapp-backup-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970221101910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stager-pdc-netapp-backup-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-stager-pdc-netapp-backup-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221101910.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13989; 24 Feb 97 10:03 EST Received: from ietf.ietf.org by ietf.org id aa12915; 24 Feb 97 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-farinacci-intralis-multicast-00.txt Date: Mon, 24 Feb 1997 09:51:09 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702240951.aa12915@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Intra-LIS IP multicast among routers over ATM Author(s) : D. Farinacci, D. Meyer, Y. Rekhter Filename : draft-farinacci-intralis-multicast-00.txt Pages : 4 Date : 02/21/1997 This document describes how intra-LIS IP multicast could be supported among routers over ATM without using the Multicast Address Resolution Server (MARS), by using just the existing IP multicast protocols (IGMP, PIM). 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-farinacci-intralis-multicast-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-farinacci-intralis-multicast-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-farinacci-intralis-multicast-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970221100741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-farinacci-intralis-multicast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-farinacci-intralis-multicast-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221100741.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13990; 24 Feb 97 10:03 EST Received: from ietf.ietf.org by ietf.org id aa13026; 24 Feb 97 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-07.txt, .ps Date: Mon, 24 Feb 1997 09:51:32 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702240951.aa13026@ietf.org> --NextPart A Revised 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 : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-07.txt, .ps Pages : 79 Date : 02/20/1997 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet 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-ietf-ipsec-isakmp-07.txt". Or "get draft-ietf-ipsec-isakmp-07.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-07.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-07.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@ds.internic.net" Content-Type: text/plain Content-ID: <19970221180031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221180031.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13991; 24 Feb 97 10:03 EST Received: from ietf.ietf.org by ietf.org id aa13010; 24 Feb 97 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-mixer@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mixer-directory-00.txt Date: Mon, 24 Feb 1997 09:51:30 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702240951.aa13010@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME - X.400 Gateway Working Group of the IETF. Title : Use of an X.500/LDAP directory to support MIXER address mapping Author(s) : S. Kille Filename : draft-ietf-mixer-directory-00.txt Pages : 9 Date : 02/21/1997 This document defines how to use an X.500 or LDAP directory to support the mapping between X.400 OR Addresses and mailboxes defined in MIXER (RFC 1327bis) [5]. This draft document will be submitted to the RFC editor as a protocol standard. Distribution of this memo is unlimited. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mixer-directory-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mixer-directory-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mixer-directory-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970221111723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mixer-directory-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mixer-directory-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221111723.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13973; 24 Feb 97 10:03 EST Received: from ietf.ietf.org by ietf.org id aa12976; 24 Feb 97 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-issll-is802-framework-00.txt Date: Mon, 24 Feb 1997 09:51:24 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702240951.aa12976@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies Author(s) : A. Ghanwani, W. Pace, V. Srinivasan Filename : draft-ietf-issll-is802-framework-00.txt Pages : 15 Date : 02/20/1997 Traditionally, LAN technologies such as ethernet and token ring have been required to handle best effort services only. No standard mechanism exists for providing bandwidth or delay guarantees on these media. It is therefore not possible to provide guaranteed quality of service as will be required by emerging and future multimedia applications. The anticipated demand for real-time applications on the Internet has led to the development of RSVP, a signaling mechanism for performing resource reservation in the Internet. Concurrently, the Integrated Services working group within the IETF has been working on the definition of service classes called "Integrated Services" which are expected to make use of RSVP. Applications will use these service classes in order to obtain the desired quality of service from the network. LAN technologies such as token ring and ethernet typically constitute the last hop in Internet connections. There is therefore a need to enhance these technologies so that they are able to support the Integrated Services. In order to enable such services, it is necessary to provide a resource management functions. This memo describes a framework for providing the necessary functionality on shared and switched LAN technologies. 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-issll-is802-framework-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-issll-is802-framework-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-issll-is802-framework-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970221105439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-issll-is802-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-issll-is802-framework-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221105439.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13980; 24 Feb 97 10:03 EST Received: from ietf.ietf.org by ietf.org id aa12947; 24 Feb 97 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ppp@merit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eaprsa-04.txt Date: Mon, 24 Feb 1997 09:51:19 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702240951.aa12947@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP EAP RSA Public Key Authentication Protocol Author(s) : W. Whelan Filename : draft-ietf-pppext-eaprsa-04.txt Pages : 14 Date : 02/20/1997 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication its peer before allowing Network Layer protocols to transmit over the link. PPP Extensible Authentication Protocol (EAP) [2] provides for a number of authentication mechanisms. One of these is RSA Public Key Authentication. This document defines RSA Public Key Authentication Protocol within PPP EAP. 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-pppext-eaprsa-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eaprsa-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eaprsa-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970221102616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eaprsa-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eaprsa-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221102616.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14838; 24 Feb 97 10:15 EST Received: from ietf.ietf.org by ietf.org id aa12963; 24 Feb 97 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: namedroppers@internic.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsind-ncache-02.txt Date: Mon, 24 Feb 1997 09:51:22 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702240951.aa12963@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. Title : Negative Caching of DNS Queries (DNS NCACHE) Author(s) : M. Andrews Filename : draft-ietf-dnsind-ncache-02.txt Pages : 8 Date : 02/21/1997 When [RFC1034] was written there were no DNS servers that implemented negative caching [RFC1034 Section 4.3.4]. This document replaces [RFC1034 Section 4.3.4] in the light of experience. Negative caching was a optional part of the DNS specification and deals with the caching of the non-existence of a RRset or domain name. Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all servers implemented negative caching. With this in mind negative caching should no longer be seen as a optional part of a DNS 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-ietf-dnsind-ncache-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-ncache-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnsind-ncache-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970221103652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-ncache-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsind-ncache-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221103652.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa27657; 24 Feb 97 12:39 EST Received: from zephyr.isi.edu by ietf.org id aa27373; 24 Feb 97 12:34 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 24 Feb 1997 09:31:53 -0800 Message-Id: <199702241731.AA06930@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2076 on Internet Message Headers Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 24 Feb 97 09:31:52 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2076: Title: Common Internet Message Headers Author: J. Palme Date: February 1997 Mailbox: jpalme@dsv.su.se Pages: 27 Characters: 47639 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2076.txt This memo contains a table of commonly occurring headers in headings of e-mail messages. This document is a product of the Mail Extensions Working Group of the IETF. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970224092804.RFC@ISI.EDU> SEND /rfc/rfc2076.txt --OtherAccess Content-Type: Message/External-body; name="rfc2076.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970224092804.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28001; 24 Feb 97 12:46 EST Received: from zephyr.isi.edu by ietf.org id aa27866; 24 Feb 97 12:44 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 24 Feb 1997 09:41:37 -0800 Message-Id: <199702241741.AA07495@zephyr.isi.edu> To: IETF-Announce: ; Subject: STD 1, RFC 2000 on Internet Standards Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 24 Feb 97 09:41:37 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. STD 1: RFC 2000: Title: INTERNET OFFICIAL PROTOCOL STANDARDS Author: J. Postel, Editor Date: February 1997 Mailbox: postel@isi.edu Pages: 56 Characters: 121298 Updates/Obsoletes: 1920, 1880, 1800, 1780, 1720, 1610, 1600, 1540, 1500, 1410, 1360, 1280, 1250, 1200, 1140, 1130, 1100, 1083 URL: ftp://ds.internic.net/rfc/rfc2000.txt This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. 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@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970224093656.RFC@ISI.EDU> SEND /rfc/rfc2000.txt --OtherAccess Content-Type: Message/External-body; name="rfc2000.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970224093656.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10125; 24 Feb 97 17:25 EST Received: from aleve.media.mit.edu by ietf.org id aa09818; 24 Feb 97 17:19 EST Received: from ml.media.mit.edu (ml.media.mit.edu [18.85.13.107]) by media.mit.edu (8.7.5/ML961206) with SMTP id RAA25622 for ; Mon, 24 Feb 1997 17:16:07 -0500 (EST) Received: from bad-taste.media.mit.edu by ml.media.mit.edu; (5.65v3.2/1.1.8.2/12Apr96-0443PM) id AA22614; Mon, 24 Feb 1997 17:16:06 -0500 Date: Mon, 24 Feb 1997 17:16:02 -0500 (EST) Sender:ietf-request@ietf.org From: Roger WOJA Kermode To: ietf@ietf.org Subject: 38th IETF Meeting...Hotel Gripe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. I just rang the Peabody Memphis hotel in an attempt to make a booking and was informed that all the rooms allocated to the conference were already booked (not a huge surpirse). When I asked if I might be put on a waiting list for any rooms that might be cancelled I was informed rather curtly that if a room from the IETF block was cancelled it would be available at the *regular* rate, i.e. the IETF rate would no longer reply. Is this standard practice? I would have assumed that given the nature of the IETF corwad, that more than a few people that pre-book and then subsequently cancel would not be insignificant, thus leading to their `replacements' paying extra.... Roger (who will be staying across the road at the Holiday Inn) Roger Kermode Research Assistant woja@media.mit.edu tel : +1 617 253 0341 Entertainment & Information Systems Group fax : +1 617 258 6264 MIT Media Lab, 20 Ames St, RmE15-354, Cambridge, MA 02139 USA   Received: from ietf.org by ietf.org id aa11473; 24 Feb 97 17:49 EST Received: from fnal.fnal.gov by ietf.org id aa11342; 24 Feb 97 17:47 EST Received: from gungnir.fnal.gov ("port 34597"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IFSUM2FY6W001PLO@FNAL.FNAL.GOV> for ietf@ietf.org; Mon, 24 Feb 1997 16:44:37 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA18329; Mon, 24 Feb 1997 16:44:37 -0600 Date: Mon, 24 Feb 1997 16:44:37 -0600 Sender:ietf-request@ietf.org From: Matt Crawford Subject: Re: 38th IETF Meeting...Hotel Gripe In-reply-to: "24 Feb 1997 17:16:02 EST." <"Pine.OSF.3.91.970224170648.23609H-100000"@bad-taste.media.mit.edu> X-Orig-Sender: crawdad@gungnir.fnal.gov To: ietf@ietf.org Message-id: <199702242244.QAA18329@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ To: ietf@ietf.org Subject: Re: 38th IETF Meeting...Hotel Gripe In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. If the Peabody is booked i assume there is going to be posted some alternative hotels people can stay at Mark Needleman University of California On Mon, 24 Feb 1997, Roger WOJA Kermode wrote: > Date: Mon, 24 Feb 1997 17:16:02 -0500 (EST) > From: Roger WOJA Kermode > To: ietf@ietf.org > Subject: 38th IETF Meeting...Hotel Gripe > > > I just rang the Peabody Memphis hotel in an attempt to make a booking > and was informed that all the rooms allocated to the conference were > already booked (not a huge surpirse). > > When I asked if I might be put on a waiting list for any rooms that might > be cancelled I was informed rather curtly that if a room from the IETF > block was cancelled it would be available at the *regular* rate, > i.e. the IETF rate would no longer reply. > > Is this standard practice? I would have assumed that given the nature > of the IETF corwad, that more than a few people that pre-book and then > subsequently cancel would not be insignificant, thus leading to their > `replacements' paying extra.... > > Roger (who will be staying across the road at the Holiday Inn) > > > > Roger Kermode Research Assistant > woja@media.mit.edu tel : +1 617 253 0341 > Entertainment & Information Systems Group fax : +1 617 258 6264 > MIT Media Lab, 20 Ames St, RmE15-354, Cambridge, MA 02139 USA > >   Received: from ietf.org by ietf.org id aa12332; 24 Feb 97 18:01 EST Received: from dns.doruk.net.tr by ietf.org id aa12197; 24 Feb 97 17:59 EST Received: by bbs.doruk.com.tr id aa00181; 25 Feb 97 0:54 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: "D.GEYRAN" X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: Re[2]: W95 ten sikayete devam Date: Tue, 25 Feb 97 00:34:43 Resent-Date: Tue, 25 Feb 97 00:45:28 TSI Xorg-Content: text/plain; charset="dbbs-win" Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250054.aa00181@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. >>ihtimal.. Kulluk etmek gibi bisey bu... Bill onumuze ne koysa razi oluyoruz. >> >>Sevgilerimle, >>A.Eren OZENLI >> >>>Hades >>>hades@ibm.net >>>olgunv@doruk.com.tr >>>http://www.geocities.com/SunsetStrip/Alley/1870 >>>---------------------------------------------------------------------------- >>>Hiroshima 45, Chernobil 86, Windoze 95 >>>---------------------------------------------------------------------------- >Yaaa. Milyonlarca insan "baska alternatif var midir?", "M$ urunleri gercekten >isimi gorur mu?" falan gibi mantikli sorulari sormadan Bill onlerine ne >koyarsa razi oluyorlar. Para Bill'de tabii. >Kongar (kiskanc adam) El insaf yani.!...Artik dayanamayip cevap yazmak istiyorum.! Sayin forumcular W95 ten baskada OS ler var neden onlari kullanmiyorsunuzda onunuze konana kendinizi mecbur hissediyorsunuz. Bunca sesiz kullanici var benim bildiklerimin kabaca yaridan cok fazlasi sikayetci degiller. Bir yildir kullaniyorum onemli bir sorun cikmadi. Begenmesem hemen baska sisteme gecerdim. Onume ne konsa razi olmazdim. Tum dunyada kullanici sayisi cok fazla. Yani Amerika, Avrupa, Japonya ki tuketici haklarinin cok iyi korundugu ve yanlis reklamin siddetle hem hukuki hemde kamuoyu nezdinde cezalandirildigi ve derhal itibar kaybettigi bilincli tuketici pazarlari bunlar. Yuzlerce dergi enine boyuna programlari didik didik inceliyor binlerce okuruna aktariyor. Buralarda PC kullanacak kapasitedeki bir suru insan W95-Warp-Merlin-Mac vs pazarda gorup deniyor ve hernasilsa toplu bir ahmaklikla cok sayida insan digerleri yanindaki dezavantajlarina ragmen W95 tercih ediyor. Ama siz faka basmiyor W95 sadece bir pazarlama basarisi oldugunu hemen farkediyorsunuz ve fakat yinede kullanmaya devam ediyorsunuz. Hirosima/W95, Hitler/Bill benzetmeleri bir iki duyunca bu yaratici zeka urunu espriler cok hos oluyor ama ayni seyler durmadan tekrarlayinca artik gulemiyorum. Birde sunu anlayamiyorum: makinama bilmem ne taktim.... 6 kere restart yaptim tanimadi 7 cisinde tanidi ne aptal program... Yahu bu insanmiki jetonu gec dussun? 6 kere yapilan her ne ise 7 cisinde degistirilmiski makina tanima islemini gerceklestirmis. Hic tasarim hatasi olamayan kullanici hatalarinida gideren programlar yapilacak elbette. Buna inaniyorum W2.0 dan baslayip W95e gelinen surec bunu gosteriyor. Yine inaniyorumki ayni kategorideki sozkonusu isletim sistemleri esasen hemen hemen ayni performansi gosteriyor. Kisisel olarak MS tercih ettim cunku software firmalari icinde finansman gucu enyuksek olani. Piyasada soz sahibi olacagi kacinilmaz. Yan sanayi destegide onun ruzgarina kapilmis gidiyor. O halde MS ve windows kulturune nekadar cabuk alisirsam mevcut ve ileride piyasalara cikacak programlara ortak ozellikleri nedeniyle daha hizli adapte olabilirim diye dusunuyorum zira ben artik her yil yenibir program ogrenmekten biktim. Wordstar-Wordperfect-Lotus123 zinciri yerine Word2-Word7-Excel zincirini takip etmek benim icin cok daha az caba gerektiriyor. Tekellesmenin onlenmesi ve rekabet acisindan diger firmlarinda pazar paylarini korumalari gerekiyor elbette iste o yuzden bi zahmet W95 i birakip bu sistemlere gecinde hem siz kurtulun hemde piyasa dengeleri kurulsun. Sevgiler D.Geyran Not: Cevap yazmak icin Sn Kongar'in mail i tesadufen denk gelmistir. Elestrimin kisisel olmadigi acik ancak yinede her ihtimale karsi hosgorusune sigindigimi belirtmek istiyorum.   Received: from ietf.org by ietf.org id aa13932; 24 Feb 97 18:33 EST Received: from dns.doruk.net.tr by ietf.org id aa13739; 24 Feb 97 18:31 EST Received: by bbs.doruk.com.tr id ab00986; 25 Feb 97 1:25 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Imran Geriskovan X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: UNIXNT-L: NC's and UNIX and NT.... Date: Fri, 21 Feb 97 01:09:54 Resent-Date: Tue, 25 Feb 97 01:18:31 TSI Comment: Originally-from : flatech@magicnet.net (Florida Tech) Comment: Originally-to : Multiple recipients of list UNIXNT-L Xorg-Content: text/plain; charset="dbbs-dos" Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250125.ab00986@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. ------------------------- Orjinal Mesaj -------------------------- The following was emailed to Bob Lewis, referring to his recent article in INFOWORLD, February 17, 1997, pg. 58. "If client/server seems pricey, try creating GUI screens for a mainframe". Hello Bob, I try to read your articles (or at least scan them) as regularly as possible in InfoWorld. This week's article was good. I have a UNIX/C/C++ Program going on here at Florida Institute of Technology (Florida Tech), Orlando Branch, and I love to talk about the concept of NC's. First of all, I do believe the mainframe was the first NC. Then came UNIX. For over 25 years, UNIX has been providing an ideal 32-bit NC on more platforms than any other operating system in existance. You can tap into a UNIX machine as a user, or even a superuser, do anything you want, set off print jobs, compile programs, change system behavior, and access applications from almost any computer with a modem and communication package (like the ones built-in to Windows 3.1 and Win 95). You don't need PC Anywhere or anything like that to do it, your remote computer IS your host computer. Built-in, off the shelf, ready to rock 'n roll. TCP/IP? I believe UNIX came up with that one, Microsoft. Now, there is one issue to contend with, that concept of snappy GUI's. Well, you do need a little training (like ours, hint hint) to get the knack of UNIX. It isn't something a secretarial applicant can handle with ease, but isn't the flexibility worth it? And by the way, the UNIX people get to command a little higher salary for their "out of the ordinary" skills. Our grads do exceptionally well. And of course, there are lot's of snazzy x-windows interfaces out there to play around with. And by the way, mix and match as you please.... A GUI here, a $200 text terminal there, an old PC over there, etc. Try THAT with NT. I know of a local company that produces large stainless steal tubing for petroleum refineries. He has a unix box and brings old bang-em-up terminals out to the production floor to get delivery and ordering information to the manufacturing personnel. Citrix Winframe - Yes, that is one option, and it is pretty cool too. We were looking into possibly using it to network our office. Yes, yes, yes, I did fire up a working session of WIN NT on an old 386 DOS only machine over a 14.4kb modem. But it did lag a bit. You are talking about the equivalent of a 28.8 kb connection, even within the LAN. But for people that only know Windows, I guess it is the cat's meow. Did I mention that even for our little network we needed a 256 meg 200 mhz pentium server? Quite a mammoth server. NT sure isn't as frugal with resources as UNIX. We have 2 90 mhz Pentium machines with 32 megs ram each running our classroom on SCO UNIX Openserver 5, with 24 text-based terminals. We also have 2 16meg 486-66's hooked up to our little network. You can telnet back and forth to any of them, and any of them can run the entire classroom without a hiccup. Even when the class is compiling C code, it barely even slows down. And I'm sure you are aware of UNIX's own entries into the "NC" market, with even "more NC" NC's than ever. One example is SCO's "Tarantula" product. They will by coming out with a 64-bit UNIX by the end of the year. I hate all those Microsoft vs. UNIX studies where they ask "how many PC's have this OS installed? And of course, if the NT network is 15 people, their answer is 15. On the UNIX side, their network may be 100, but only one PC, and 100 users. MS - 15, UNIX - 1. That question is loaded..... Well, continue the good work. I look forward to your articles in upcoming issues. You can find out more about our program at http://www.magicnet.net/~frosty/flatech.html. Sincerely, Michael Dotson Program Manager Florida Tech UNIX/C/C++ Program Florida Tech Orlando Graduate Center 3165 McCrory Place Suite 161 Orlando, Florida 32803 (407)895-7007 (voice) (407)894-8583 (fax) http://www.magicnet.net/~frosty/flatech.html ---------------------------------------------------------------- UNIXNT-L Unix & NT List. For a list of commands send the message: INFO COMMANDS to LISTSERVER@switchsoft.com   Received: from ietf.org by ietf.org id aa14194; 24 Feb 97 18:37 EST Received: from dns.doruk.net.tr by ietf.org id aa13998; 24 Feb 97 18:35 EST Received: by bbs.doruk.com.tr id ab01127; 25 Feb 97 1:31 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Tim McDowell X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: AUTOMATIC REPLY Date: Mon, 24 Feb 1997 16:20:30 -0700 (MST) Resent-Date: Tue, 25 Feb 97 01:23:03 TSI Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250131.ab01127@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. The user mcdowelt no longer has an active account on rintintin. The mail you sent will be received by mcdowelt in the event that the account is re-activated. Another means of communication is advised. Important requests for more information on the mcdowelt account can be sent to postmaster@rintintin.   Received: from ietf.org by ietf.org id aa16752; 24 Feb 97 19:13 EST Received: from dns.doruk.net.tr by ietf.org id aa16687; 24 Feb 97 19:11 EST Received: by bbs.doruk.com.tr id aa01878; 25 Feb 97 2:07 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: George Eddy X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: UNIXNT-L: NC's and UNIX and NT.... Date: Mon, 24 Feb 97 15:59:03 PST Resent-Date: Tue, 25 Feb 97 02:02:05 TSI In-Reply-To: <9702250125.ab00986@bbs.doruk.com.tr> Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250207.aa01878@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. please do not send this stuff to ietf@ieft.org or whatever mail-list you've fwd'd it to. i am soooooo sick of unix vs. whatever discussions and do not want to be bothered with it. eddy@isi.edu According to: Imran Geriskovan > > ------------------------- Orjinal Mesaj -------------------------- > The following was emailed to Bob Lewis, referring to his recent article in > INFOWORLD, February 17, 1997, pg. 58. "If client/server seems pricey, try > creating GUI screens for a mainframe". > > > Hello Bob, > > I try to read your articles (or at least scan them) as regularly as possible > in InfoWorld. This week's article was good. I have a UNIX/C/C++ Program > going on here at Florida Institute of Technology (Florida Tech), Orlando > Branch, and I love to talk about the concept of NC's. > > First of all, I do believe the mainframe was the first NC. Then came UNIX. > For over 25 years, UNIX has been providing an ideal 32-bit NC on more > platforms than any other operating system in existance. You can tap into a > UNIX machine as a user, or even a superuser, do anything you want, set off > print jobs, compile programs, change system behavior, and access > applications from almost any computer with a modem and communication package > (like the ones built-in to Windows 3.1 and Win 95). You don't need PC > Anywhere or anything like that to do it, your remote computer IS your host > computer. > > Built-in, off the shelf, ready to rock 'n roll. > > TCP/IP? I believe UNIX came up with that one, Microsoft. > > Now, there is one issue to contend with, that concept of snappy GUI's. > Well, you do need a little training (like ours, hint hint) to get the knack > of UNIX. It isn't something a secretarial applicant can handle with ease, > but isn't the flexibility worth it? And by the way, the UNIX people get to > command a little higher salary for their "out of the ordinary" skills. Our > grads do exceptionally well. > > And of course, there are lot's of snazzy x-windows interfaces out there to > play around with. And by the way, mix and match as you please.... A GUI > here, a $200 text terminal there, an old PC over there, etc. Try THAT with > NT. I know of a local company that produces large stainless steal tubing for > petroleum refineries. He has a unix box and brings old bang-em-up terminals > out to the production floor to get delivery and ordering information to the > manufacturing personnel. > > Citrix Winframe - Yes, that is one option, and it is pretty cool too. We > were looking into possibly using it to network our office. Yes, yes, yes, I > did fire up a working session of WIN NT on an old 386 DOS only machine over > a 14.4kb modem. But it did lag a bit. You are talking about the equivalent > of a 28.8 kb connection, even within the LAN. But for people that only know > Windows, I guess it is the cat's meow. > > Did I mention that even for our little network we needed a 256 meg 200 mhz > pentium server? Quite a mammoth server. NT sure isn't as frugal with > resources as UNIX. > > We have 2 90 mhz Pentium machines with 32 megs ram each running our > classroom on SCO UNIX Openserver 5, with 24 text-based terminals. We also > have 2 16meg 486-66's hooked up to our little network. You can telnet back > and forth to any of them, and any of them can run the entire classroom > without a hiccup. Even when the class is compiling C code, it barely even > slows down. > > And I'm sure you are aware of UNIX's own entries into the "NC" market, with > even "more NC" NC's than ever. One example is SCO's "Tarantula" product. > They will by coming out with a 64-bit UNIX by the end of the year. > > I hate all those Microsoft vs. UNIX studies where they ask "how many PC's > have this OS installed? And of course, if the NT network is 15 people, > their answer is 15. On the UNIX side, their network may be 100, but only > one PC, and 100 users. MS - 15, UNIX - 1. That question is loaded..... > > Well, continue the good work. I look forward to your articles in upcoming > issues. You can find out more about our program at > http://www.magicnet.net/~frosty/flatech.html. > > Sincerely, > > > Michael Dotson > Program Manager > Florida Tech UNIX/C/C++ Program > > Florida Tech > Orlando Graduate Center > 3165 McCrory Place > Suite 161 > Orlando, Florida 32803 > > (407)895-7007 (voice) > (407)894-8583 (fax) > > http://www.magicnet.net/~frosty/flatech.html > > ---------------------------------------------------------------- > UNIXNT-L Unix & NT List. For a list of commands send > the message: INFO COMMANDS to LISTSERVER@switchsoft.com >   Received: from ietf.org by ietf.org id aa16945; 24 Feb 97 19:18 EST Received: from dns.doruk.net.tr by ietf.org id aa16856; 24 Feb 97 19:17 EST Received: by bbs.doruk.com.tr id ac02033; 25 Feb 97 2:13 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: oyun-f@doruk.com.tr Sender:ietf-request@ietf.org From: Osman Yozgatlioglu X-Mailer: Doruk-BBS Forum Servisi To: oyun-f forum grubu uyeleri Subject: Re: Red Alert Date: Tue, 25 Feb 97 01:19:53 Resent-Date: Tue, 25 Feb 97 02:08:06 TSI In-Reply-To: EvolveR Xorg-Content: text/plain; charset="dbbs-dos" Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250213.ac02033@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. >Selam, >Size E-Mail adresi olmayan bir arkadasimin sorununu aktarmak istiyorum: > >Red Alert'in CD'sindeki install programini calistirdiktan sonra, ve belli >dosyalari hard diske yuklenmeden once bir hata mesaji veriliyor... >Hard disk'te 8 MB'lik bos yer olmadigini belirtiyor, oysa bilgisayarinda 25 MB >bos yer var. Neden sorun cikarabilecegini bilen bir uye varsa lutfen cevap >gondersin... > >Simdiden tesekkur ediyormus... (Ben de) > >EvolveR Harddiskindeki bos alani optimize etsin veya 50 MB bos alan acsin. Aciklama isteme, her programin hataya ihtiyaci vardir. :) _Osman_   Received: from ietf.org by ietf.org id aa16944; 24 Feb 97 19:18 EST Received: from dns.doruk.net.tr by ietf.org id aa16856; 24 Feb 97 19:17 EST Received: by bbs.doruk.com.tr id aa02033; 25 Feb 97 2:13 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: "Douglas R. Sheppard" X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: UNIXNT-L: NC's and UNIX and NT.... Date: Mon, 24 Feb 1997 15:55:57 -0800 Resent-Date: Tue, 25 Feb 97 02:05:05 TSI Xorg-Content: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250213.aa02033@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Here here! I also want to remind people that Microsoft is NOT the Internet. It pains me to hear how many people seem to think Microsoft created the Internet, or that they even had ANYTHING to do with making it what it is. In fact, doesn't anyone remember the statements Gates made about how the Internet wasn't anything worth Microsoft looking at just a few years ago? Just that hypocritical statement itself should be enough to never associate the two! -doug Imran Geriskovan wrote: > > ------------------------- Orjinal Mesaj -------------------------- > The following was emailed to Bob Lewis, referring to his recent article in > INFOWORLD, February 17, 1997, pg. 58. "If client/server seems pricey, try > creating GUI screens for a mainframe". > > Hello Bob, > > I try to read your articles (or at least scan them) as regularly as possible > in InfoWorld. This week's article was good. I have a UNIX/C/C++ Program > going on here at Florida Institute of Technology (Florida Tech), Orlando > Branch, and I love to talk about the concept of NC's. > > First of all, I do believe the mainframe was the first NC. Then came UNIX. > For over 25 years, UNIX has been providing an ideal 32-bit NC on more > platforms than any other operating system in existance. You can tap into a > UNIX machine as a user, or even a superuser, do anything you want, set off > print jobs, compile programs, change system behavior, and access > applications from almost any computer with a modem and communication package > (like the ones built-in to Windows 3.1 and Win 95). You don't need PC > Anywhere or anything like that to do it, your remote computer IS your host > computer. > > Built-in, off the shelf, ready to rock 'n roll. > > TCP/IP? I believe UNIX came up with that one, Microsoft. > > Now, there is one issue to contend with, that concept of snappy GUI's. > Well, you do need a little training (like ours, hint hint) to get the knack > of UNIX. It isn't something a secretarial applicant can handle with ease, > but isn't the flexibility worth it? And by the way, the UNIX people get to > command a little higher salary for their "out of the ordinary" skills. Our > grads do exceptionally well. > > And of course, there are lot's of snazzy x-windows interfaces out there to > play around with. And by the way, mix and match as you please.... A GUI > here, a $200 text terminal there, an old PC over there, etc. Try THAT with > NT. I know of a local company that produces large stainless steal tubing for > petroleum refineries. He has a unix box and brings old bang-em-up terminals > out to the production floor to get delivery and ordering information to the > manufacturing personnel. > > Citrix Winframe - Yes, that is one option, and it is pretty cool too. We > were looking into possibly using it to network our office. Yes, yes, yes, I > did fire up a working session of WIN NT on an old 386 DOS only machine over > a 14.4kb modem. But it did lag a bit. You are talking about the equivalent > of a 28.8 kb connection, even within the LAN. But for people that only know > Windows, I guess it is the cat's meow. > > Did I mention that even for our little network we needed a 256 meg 200 mhz > pentium server? Quite a mammoth server. NT sure isn't as frugal with > resources as UNIX. > > We have 2 90 mhz Pentium machines with 32 megs ram each running our > classroom on SCO UNIX Openserver 5, with 24 text-based terminals. We also > have 2 16meg 486-66's hooked up to our little network. You can telnet back > and forth to any of them, and any of them can run the entire classroom > without a hiccup. Even when the class is compiling C code, it barely even > slows down. > > And I'm sure you are aware of UNIX's own entries into the "NC" market, with > even "more NC" NC's than ever. One example is SCO's "Tarantula" product. > They will by coming out with a 64-bit UNIX by the end of the year. > > I hate all those Microsoft vs. UNIX studies where they ask "how many PC's > have this OS installed? And of course, if the NT network is 15 people, > their answer is 15. On the UNIX side, their network may be 100, but only > one PC, and 100 users. MS - 15, UNIX - 1. That question is loaded..... > > Well, continue the good work. I look forward to your articles in upcoming > issues. You can find out more about our program at > http://www.magicnet.net/~frosty/flatech.html > > Sincerely, > > Michael Dotson > Program Manager > Florida Tech UNIX/C/C++ Program > > Florida Tech > Orlando Graduate Center > 3165 McCrory Place > Suite 161 > Orlando, Florida 32803 > > (407)895-7007 (voice) > (407)894-8583 (fax) > > http://www.magicnet.net/~frosty/flatech.html > > ---------------------------------------------------------------- > UNIXNT-L Unix & NT List. For a list of commands send > the message: INFO COMMANDS to LISTSERVER@switchsoft.com   Received: from ietf.org by ietf.org id aa18891; 24 Feb 97 19:38 EST Received: from dns.doruk.net.tr by ietf.org id aa18375; 24 Feb 97 19:36 EST Received: by bbs.doruk.com.tr id ab02517; 25 Feb 97 2:32 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Dark Paladin X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: Re[2]: W95 ten sikayete devam Date: Tue, 25 Feb 97 02:15:31 Resent-Date: Tue, 25 Feb 97 02:26:08 TSI In-Reply-To: D.GEYRAN Xorg-Content: text/plain; charset="dbbs-dos" Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250232.ab02517@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. > >Tum dunyada kullanici sayisi cok fazla. Yani Amerika, Avrupa, Japonya ki tuketici haklarinin cok iyi korundugu ve >yanlis reklamin siddetle hem hukuki hemde kamuoyu nezdinde cezalandirildigi ve derhal itibar kaybettigi bilincli >tuketici pazarlari bunlar. Yuzlerce dergi enine boyuna programlari didik didik inceliyor binlerce okuruna aktariyor. Yuzlerce derginin programlari enine-boyuna inceledigine emin misiniz? Dergilerin incelemelerini ne kadar dikkate alabiliriz? Hey ay MS'den 7-8 tam sayfa reklam alan bir dergi bir MS urununu tarafsiz olarak degerlendirebilir mi? MS'in dev bir kurulus oldugunu kendiniz soyluyorsunuz. Hangi dergi bu kurulusu karsisina almaya cesaret edebilir? >Buralarda PC kullanacak kapasitedeki bir suru insan W95-Warp-Merlin-Mac vs pazarda gorup deniyor ve >hernasilsa toplu bir ahmaklikla cok sayida insan digerleri yanindaki dezavantajlarina ragmen W95 tercih ediyor. >Ama siz faka basmiyor W95 sadece bir pazarlama basarisi oldugunu hemen farkediyorsunuz ve fakat yinede >kullanmaya devam ediyorsunuz. > Kullanmaya devam ediyoruz, cunku baska alternatif yok. Hemen, "warp, merlin" falan demeyin, onlar alternatif degil. Kullanmam gereken bazi yazilimlar var ve bunlar sadece Win95 ustunde calisiyor. Bu nedenle, rezil hatalar icermesine ragmen Win95 kullaniyorum. Ama sistemime baska hic bir MS programini da yuklememeye dikkat ediyorum. MS kalitesiz programlar uretiyor. MS hatalar iceren programlar uretiyor. MS programlari gereginden fazla RAM ve islemci tuketiyorlar. MS Big Brother olmaya calisiyor. Bunlari soyleyen sadece ben degilim. Hem aglarim hem giderim hesabi, MS programlari ve bunlarin hatalari ile yasamayi ogreniyorum. Ama P133 ve 32Mb RAM'da bile yavas calisan bu isletim sistemini yapanlara da sik sik kufur etmekten geri kalmiyorum. Buna da hakkim var. > >Tekellesmenin onlenmesi ve rekabet acisindan diger firmlarinda pazar paylarini korumalari gerekiyor elbette iste o >yuzden bi zahmet W95 i birakip bu sistemlere gecinde hem siz kurtulun hemde piyasa dengeleri kurulsun. > Hem siz kurtulun hem biz kurtulalim demek istediniz sanirim.. Dark   Received: from ietf.org by ietf.org id aa19339; 24 Feb 97 19:44 EST Received: from dns.doruk.net.tr by ietf.org id aa19247; 24 Feb 97 19:43 EST Received: by bbs.doruk.com.tr id aa02764; 25 Feb 97 2:38 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: oyun-f@doruk.com.tr Sender:ietf-request@ietf.org From: Reto Lichtensteiger X-Mailer: Doruk-BBS Forum Servisi To: oyun-f forum grubu uyeleri Subject: Re: Red Alert (fwd) Date: Mon, 24 Feb 1997 19:32:43 -0500 (EST) Resent-Date: Tue, 25 Feb 97 02:33:38 TSI Xorg-Content: text/plain; charset=US-ASCII Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250238.aa02764@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Osman Yozgatlioglu wrote: <> From ietf-request@ietf.org Mon Feb 24 19:27:29 1997 <> Resent-From: ietf-request@ietf.org <> Resent-Message-Id: <9702250027.AA26508@ns1.meitca.com> <> X-Orig-Sender: Doruk-BBS Forum Servisi <> Errors-To: forum-error@doruk.com.tr <> Reply-To: oyun-f@doruk.com.tr <> Sender: ietf-request@ietf.org <> From: Osman Yozgatlioglu <> X-Mailer: Doruk-BBS Forum Servisi <> To: oyun-f forum grubu uyeleri <> Subject: Re: Red Alert <> Date: Tue, 25 Feb 97 01:19:53 <> Resent-Date: Tue, 25 Feb 97 02:08:06 TSI <> In-Reply-To: EvolveR <> Xorg-Content: text/plain; charset="dbbs-dos" <> Content-Type: text/plain; charset="us-ascii" <> Message-Id: <9702250213.ac02033@bbs.doruk.com.tr> <> Source-Info: From (or Sender) name not authenticated. As you can see from these headers, you are holding this conversation on the IETF mailing list. While your words certainly may have to do with Internet design issues, regretfully, most of the folks on the list don't speak Turkish, hence can't participate ... Thanks! Reto L. -- R A Lichtensteiger rali@meitca.com -or- rali@world.std.com http://www.meitca.com/ITA/People/rali "Yes, you're doing things right, but are you doing the right things?" "Nope. I'm just doing something dumb fast."   Received: from ietf.org by ietf.org id aa19650; 24 Feb 97 19:51 EST Received: from dns.doruk.net.tr by ietf.org id aa19589; 24 Feb 97 19:49 EST Received: by bbs.doruk.com.tr id aa02840; 25 Feb 97 2:44 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: oyun-f@doruk.com.tr Sender:ietf-request@ietf.org From: Tim McDowell X-Mailer: Doruk-BBS Forum Servisi To: oyun-f forum grubu uyeleri Subject: AUTOMATIC REPLY Date: Mon, 24 Feb 1997 17:33:52 -0700 (MST) Resent-Date: Tue, 25 Feb 97 02:35:09 TSI Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250244.aa02840@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. The user mcdowelt no longer has an active account on rintintin. The mail you sent will be received by mcdowelt in the event that the account is re-activated. Another means of communication is advised. Important requests for more information on the mcdowelt account can be sent to postmaster@rintintin.   Received: from ietf.org by ietf.org id aa20732; 24 Feb 97 20:06 EST Received: from dns.doruk.net.tr by ietf.org id aa20660; 24 Feb 97 20:05 EST Received: by bbs.doruk.com.tr id aa03125; 25 Feb 97 3:02 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: oyun-f@doruk.com.tr Sender:ietf-request@ietf.org From: "Robert W. Hall" X-Mailer: Doruk-BBS Forum Servisi To: oyun-f forum grubu uyeleri Subject: Re: Red Alert Date: Mon, 24 Feb 1997 19:55:46 -0500 (EST) Resent-Date: Tue, 25 Feb 97 02:57:39 TSI In-Reply-To: <9702250213.ac02033@bbs.doruk.com.tr> Xorg-Content: TEXT/PLAIN; charset=US-ASCII Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250302.aa03125@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Hello, Why is this being sent to the ietf-mailing list? Rob On Tue, 25 Feb 1997, Osman Yozgatlioglu wrote: > >Selam, > >Size E-Mail adresi olmayan bir arkadasimin sorununu aktarmak istiyorum: > > > >Red Alert'in CD'sindeki install programini calistirdiktan sonra, ve belli > >dosyalari hard diske yuklenmeden once bir hata mesaji veriliyor... > >Hard disk'te 8 MB'lik bos yer olmadigini belirtiyor, oysa bilgisayarinda 25 > MB > >bos yer var. Neden sorun cikarabilecegini bilen bir uye varsa lutfen cevap > >gondersin... > > > >Simdiden tesekkur ediyormus... (Ben de) > > > >EvolveR > > Harddiskindeki bos alani optimize etsin veya 50 MB bos alan acsin. Aciklama > isteme, her programin hataya ihtiyaci vardir. :) > > _Osman_ >   Received: from ietf.org by ietf.org id aa23112; 24 Feb 97 20:46 EST Received: from tipper.oit.unc.edu by ietf.org id aa23022; 24 Feb 97 20:44 EST Received: from tipper.oit.unc.edu (tipper.oit.unc.edu [152.2.22.85]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id UAA02052; Mon, 24 Feb 1997 20:42:04 -0500 Date: Mon, 24 Feb 1997 20:42:04 -0500 (EST) Sender:ietf-request@ietf.org From: Simon Spero To: Roger WOJA Kermode cc: ietf@ietf.org Subject: Re: 38th IETF Meeting...Hotel Gripe In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Mon, 24 Feb 1997, Roger WOJA Kermode wrote: > > Roger (who will be staying across the road at the Holiday Inn) If you make a big donation to the Democratic party, you may be able to spend the night at Graceland... I wouldn't worry too much; the IETF block rate is often not that great; at Houston I got a room at the conference hotel about 20 dollars less just showing up - and I even had hot water. ----- Now available - The Freddy Hayek Kayak Paddle Your Own Canoe! Be Rowed To Surfdom! From The Taco Institute for Dyslexic Libertarians   Received: from ietf.org by ietf.org id aa23472; 24 Feb 97 20:54 EST Received: from dns.doruk.net.tr by ietf.org id aa23395; 24 Feb 97 20:53 EST Received: by bbs.doruk.com.tr id aa03810; 25 Feb 97 3:50 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: oyun-f@doruk.com.tr Sender:ietf-request@ietf.org From: Serpil Bayraktar X-Mailer: Doruk-BBS Forum Servisi To: oyun-f forum grubu uyeleri Subject: "Robert W. Hall": Re: Red Alert Date: Mon, 24 Feb 1997 20:42:42 -0500 Resent-Date: Tue, 25 Feb 97 03:44:10 TSI Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250350.aa03810@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Arkadaslar, herhalde mailing listlerde bir karisiklik oldu. IETF mailing list Internet'i ilgilendiren konular icin kullanilan ve *ingilizce* yazismanin oldugu bir list. Lutfen IETF'i genel listenizden cikarin. Tesekkurler, Serpil Bayraktar ------- Forwarded Message Return-Path: ietf-request@ietf.org Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by anatolia.ans.net (8.7.5/8.7.3) with SMTP id UAA13556 for ; Mon, 24 Feb 1997 20:32:13 -0500 (EST) Received: by interlock.ans.net id AA26420 (InterLock SMTP Gateway 3.0 for sbb@ans.net); Mon, 24 Feb 1997 20:32:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 24 Feb 1997 20:32:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 24 Feb 1997 20:32:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 24 Feb 1997 20:32:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 24 Feb 1997 20:32:12 -0500 Resent-From: ietf-request@ietf.org Resent-Message-Id: <199702250132.UAA166980@bugsy.aa.ans.net> X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: oyun-f@doruk.com.tr Sender: ietf-request@ietf.org From: "Robert W. Hall" X-Mailer: Doruk-BBS Forum Servisi To: oyun-f forum grubu uyeleri Subject: Re: Red Alert Date: Mon, 24 Feb 1997 19:55:46 -0500 (EST) Resent-Date: Tue, 25 Feb 97 02:57:39 TSI In-Reply-To: <9702250213.ac02033@bbs.doruk.com.tr> Xorg-Content: TEXT/PLAIN; charset=US-ASCII Message-Id: <9702250302.aa03125@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Content-Type: text/plain; charset="us-ascii" Content-Length: 739 Hello, Why is this being sent to the ietf-mailing list? Rob On Tue, 25 Feb 1997, Osman Yozgatlioglu wrote: > >Selam, > >Size E-Mail adresi olmayan bir arkadasimin sorununu aktarmak istiyorum: > > > >Red Alert'in CD'sindeki install programini calistirdiktan sonra, ve belli > >dosyalari hard diske yuklenmeden once bir hata mesaji veriliyor... > >Hard disk'te 8 MB'lik bos yer olmadigini belirtiyor, oysa bilgisayarinda 25 > MB > >bos yer var. Neden sorun cikarabilecegini bilen bir uye varsa lutfen cevap > >gondersin... > > > >Simdiden tesekkur ediyormus... (Ben de) > > > >EvolveR > > Harddiskindeki bos alani optimize etsin veya 50 MB bos alan acsin. Aciklama > isteme, her programin hataya ihtiyaci vardir. :) > > _Osman_ > ------- End of Forwarded Message   Received: from ietf.org by ietf.org id aa28725; 24 Feb 97 22:53 EST Received: from netgw.npix.com by ietf.org id aa28614; 24 Feb 97 22:49 EST Received: from smtp by npix (5.0/SMI-SVR4) id AA02135; Mon, 24 Feb 1997 19:41:02 +0800 Received: from cc:Mail by smtp id AA856843020 Mon, 24 Feb 97 19:57:00 PST Date: Mon, 24 Feb 97 19:57:00 PST Sender:ietf-request@ietf.org From: "Jiang, Frank" Message-Id: <9701248568.AA856843020@smtp> To: woja@media.mit.edu, Simon Spero Cc: ietf@ietf.org Subject: Re[2]: 38th IETF Meeting...Hotel Gripe content-length: 714 Source-Info: From (or Sender) name not authenticated. I must miss something. Where is the 38th IETF meeting going to be taken place? Thanks, /Frank On Mon, 24 Feb 1997, Roger WOJA Kermode wrote: > > Roger (who will be staying across the road at the Holiday Inn) If you make a big donation to the Democratic party, you may be able to spend the night at Graceland... I wouldn't worry too much; the IETF block rate is often not that great; at Houston I got a room at the conference hotel about 20 dollars less just showing up - and I even had hot water. ----- Now available - The Freddy Hayek Kayak Paddle Your Own Canoe! Be Rowed To Surfdom! From The Taco Institute for Dyslexic Libertarians   Received: from ietf.org by ietf.org id aa11621; 25 Feb 97 2:19 EST Received: from dns.doruk.net.tr by ietf.org id aa11324; 25 Feb 97 2:12 EST Received: by bbs.doruk.com.tr id aa06935; 25 Feb 97 9:09 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Hakki Alacakaptan X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: Re[2]: W95 ten sikayete devam Date: Tue, 25 Feb 97 08:44:04 Resent-Date: Tue, 25 Feb 97 09:00:47 TSI In-Reply-To: D.GEYRAN Xorg-Content: text/plain; charset="dbbs-dos" Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250909.aa06935@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. >Tum dunyada kullanici sayisi cok fazla. Yani Amerika, Avrupa, Japonya ki tuketici haklarinin cok iyi korundugu ve >yanlis reklamin siddetle hem hukuki hemde kamuoyu nezdinde cezalandirildigi Iyi ki hatirlattiniz. "4Mb RAM'la calisacak, icinde DOS yok" diye reklam yaptigi icin Mikisoft'a kac milyar ceza kesmislerdi? ve derhal itibar kaybettigi bilincli >tuketici pazarlari bunlar. Yuzlerce dergi enine boyuna programlari didik didik inceliyor binlerce okuruna aktariyor. Soyle duzeltelim: Binlerce konuyla ilgili-ilgisiz medya organi Windows 95 balonunu ucurmak icin birbiriyle yaristi. >Buralarda PC kullanacak kapasitedeki bir suru insan W95-Warp-Merlin-Mac vs pazarda gorup deniyor ve >hernasilsa toplu bir ahmaklikla cok sayida insan digerleri yanindaki dezavantajlarina ragmen W95 tercih ediyor. Gene bir duzeltme: Karsilastirma yapacak seviyede olan kullanicilar Win 95'in aksak yanlarini acikca goruyor ve bu forum gibi yerlerde bildiriyorlar. Reklamlari izlemekle yetinenlerse aldiklari urunun kotu oldugunu duymak istemiyorlar. >Ama siz faka basmiyor W95 sadece bir pazarlama basarisi oldugunu hemen farkediyorsunuz ve fakat yinede >kullanmaya devam ediyorsunuz. > Gates imparatorlugunun kurdugu ve yasalarin nedense bir turlu engel olamadigi tekelci yazilim-donanim destegi Win 95'i karsi konulmaz yapiyor. Diger alternatifler Linux gibi kurulumu bedava bile olsa sonradan daha pahaliya patliyor. (...) > >Hic tasarim hatasi olamayan kullanici hatalarinida gideren programlar yapilacak elbette. Buna inaniyorum W2.0 dan >baslayip W95e gelinen surec bunu gosteriyor. > Inanclariniza saygiliyim ama bugunku rekabet kosullarinda PC yazilimlarinin giderek kalitesizlestigi bilinen bir gercek. Beta testleri artik musteriye yaptiriliyor ya da tamamlattiriliyor, sonra da "service pack" adi altinda bugfix'ler kurmaya mecbur ediliyor. >Yine inaniyorumki ayni kategorideki sozkonusu isletim sistemleri esasen hemen hemen ayni performansi gosteriyor. Siz inanmaya devam edin; sakin konuyu fazla arastirmayin yoksa derin soka girebilirsiniz ;-) >Kisisel olarak MS tercih ettim cunku software firmalari icinde finansman gucu enyuksek olani. Piyasada soz sahibi >olacagi kacinilmaz. Yan sanayi destegide onun ruzgarina kapilmis gidiyor. O Gucluden yana olmak buna derler. Mikisoft'un vasat urunler cikarmasi, faullu oynamasi, profesyonellerce begenilmemesi, aldatici vaadlerde bulunmasi ve hatta yalan soylemesi, bir bilgisayar-network-medya tekeli kurma pesinde olmasi onemli degil. Parasi var ya, onemli olan bu. halde MS ve windows kulturune >nekadar cabuk alisirsam mevcut ve ileride piyasalara cikacak programlara ortak ozellikleri nedeniyle daha hizli >adapte olabilirim diye dusunuyorum zira ben artik her yil yenibir program ogrenmekten biktim. >Wordstar-Wordperfect-Lotus123 zinciri yerine Word2-Word7-Excel zincirini takip etmek benim icin cok daha az >caba gerektiriyor. Elmayla patlicani karsilastirmayin. Word7-Excel'in karsiligi Lotus Smartsuite ya da Corel Wordperfect Suite'tir. Lotus'un kelime islemcisiyse daima Word'dan ustun olmustur. > >Tekellesmenin onlenmesi ve rekabet acisindan diger firmlarinda pazar paylarini korumalari gerekiyor elbette iste o >yuzden bi zahmet W95 i birakip bu sistemlere gecinde hem siz kurtulun hemde piyasa dengeleri kurulsun. Ha yani yeni bir pazar olusturmanin cefasini biz cekelim ki sizin gibi saglamci arkadaslara yol acilsin oyle mi? > >Sevgiler >D.Geyran > (...)   Received: from ietf.org by ietf.org id aa13229; 25 Feb 97 2:51 EST Received: from dns.doruk.net.tr by ietf.org id aa13173; 25 Feb 97 2:49 EST Received: by bbs.doruk.com.tr id aa07651; 25 Feb 97 9:45 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: peter.gleissl@oen.siemens.de X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: remove Date: 25 FEB 97 08:33:23 MEZ Resent-Date: Tue, 25 Feb 97 09:35:18 TSI Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250945.aa07651@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. remove delete ################################################################### Please remove me from your e-mail reflector. I have never subscribed to your list and I#m not interested in your discussion. Dr. Peter Gleissl Siemens AG Public Telecommunications Strategic Product Planning Tel.: +49-89-722-24220 Fax: +49-89-722-41973 e-mail: peter.gleissl@oen.siemens.de ------------- Original Text From C=DE/A=SMTP/DDA=ID/windows-f(a)doruk.com.tr, on 25.02.1997 02:02: >>Tum dunyada kullanici sayisi cok fazla. Yani Amerika, Avrupa, Japonya ki tuketici haklarinin cok iyi korundugu ve >yanlis reklamin siddetle hem hukuki hemde kamuoyu nezdinde cezalandirildigi ve derhal itibar kaybettigi bilincli >tuketici pazarlari bunlar. Yuzlerce dergi enine boyuna programlari didik didik inceliyor binlerce okuruna aktariyor. Yuzlerce derginin programlari enine-boyuna inceledigine emin misiniz? Dergilerin incelemelerini ne kadar dikkate alabiliriz? Hey ay MS'den 7-8 tam sayfa reklam alan bir dergi bir MS urununu tarafsiz olarak degerlendirebilir mi? MS'in dev bir kurulus oldugunu kendiniz soyluyorsunuz. Hangi dergi bu kurulusu karsisina almaya cesaret edebilir? >Buralarda PC kullanacak kapasitedeki bir suru insan W95-Warp-Merlin-Mac vs pazarda gorup deniyor ve >hernasilsa toplu bir ahmaklikla cok sayida insan digerleri yanindaki dezavantajlarina ragmen W95 tercih ediyor. >Ama siz faka basmiyor W95 sadece bir pazarlama basarisi oldugunu hemen farkediyorsunuz ve fakat yinede >kullanmaya devam ediyorsunuz. > Kullanmaya devam ediyoruz, cunku baska alternatif yok. Hemen, "warp, merlin" falan demeyin, onlar alternatif degil. Kullanmam gereken bazi yazilimlar var ve bunlar sadece Win95 ustunde calisiyor. Bu nedenle, rezil hatalar icermesine ragmen Win95 kullaniyorum. Ama sistemime baska hic bir MS programini da yuklememeye dikkat ediyorum. MS kalitesiz programlar uretiyor. MS hatalar iceren programlar uretiyor. MS programlari gereginden fazla RAM ve islemci tuketiyorlar. MS Big Brother olmaya calisiyor. Bunlari soyleyen sadece ben degilim. Hem aglarim hem giderim hesabi, MS programlari ve bunlarin hatalari ile yasamayi ogreniyorum. Ama P133 ve 32Mb RAM'da bile yavas calisan bu isletim sistemini yapanlara da sik sik kufur etmekten geri kalmiyorum. Buna da hakkim var. > >Tekellesmenin onlenmesi ve rekabet acisindan diger firmlarinda pazar paylarini korumalari gerekiyor elbette iste o >yuzden bi zahmet W95 i birakip bu sistemlere gecinde hem siz kurtulun hemde piyasa dengeleri kurulsun. > Hem siz kurtulun hem biz kurtulalim demek istediniz sanirim.. Dark   Received: from ietf.org by ietf.org id aa13590; 25 Feb 97 2:56 EST Received: from dns.doruk.net.tr by ietf.org id aa13535; 25 Feb 97 2:54 EST Received: by bbs.doruk.com.tr id aa07868; 25 Feb 97 9:51 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Goktug Beser X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: W95 CONFIG.SYS Date: Mon, 24 Feb 1997 10:19:11 +0200 Resent-Date: Tue, 25 Feb 97 09:44:19 TSI Xorg-Content: text/plain; charset=Default Content-Type: text/plain; charset="us-ascii" Message-ID: <9702250951.aa07868@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Bilgisayari kapatirken cikan "bilgisayarinizi kapatabilirsiniz " hangi isimli dosyada acaba? Edit etmek istiyorum da! Goktug > >>Valla bildigim kadariyla 320x200 BMP olarak kaydettigin resmi ROOT'a > >>"logo.sys" olarak atiyosun ve oluyor. Hatta shut down olayinda cikan > >yazilarda > >>bi zahmet aciklarmi? > >>Lord Spike!!!x > >> > > > >Dedigin dogru ama 320x400 cozunurlukte olacak grafikler. En fazla da 256 renk > >icerebilirler. > > > >Dark > > Sagol. Peki su cycle olayina bi cozum bilen yokmu? Hani Windows95 yazarken > alttan mavi renkler geciyor ya! > Lord Spike!!!x   Received: from ietf.org by ietf.org id aa15626; 25 Feb 97 3:27 EST Received: from dns.doruk.net.tr by ietf.org id aa15470; 25 Feb 97 3:25 EST Received: by bbs.doruk.com.tr id ab08692; 25 Feb 97 10:22 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: kongark X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: Re[2]: W95 ten sikayete devam Date: Tue, 25 Feb 97 10:06:18 Resent-Date: Tue, 25 Feb 97 10:17:21 TSI Xorg-Content: text/plain; charset="dbbs-dos" Content-Type: text/plain; charset="us-ascii" Message-ID: <9702251022.ab08692@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. El insaf yani.!...Artik dayanamayip cevap yazmak istiyorum.! Sayin forumcular W95 ten baska da OS ler var neden onlari kullanmiyorsunuz da > Kongar: Kullaniyoruz. :-) onunuze konana kendinizi mecbur hissediyorsunuz. Bunca sesiz kullanici var benim bildiklerimin kabaca yaridan cok fazlasi sikayetci degiller. > Kongar: 95 ilginc bir isletim sistemidir. Kullanma yogunluguna ve yapilan islerin farkliligina gore hatalar uretir. Bir yildir kullaniyorum onemli bir sorun cikmadi. Begenmesem hemen baska sisteme gecerdim. Onume ne konsa razi olmazdim. > Kongar: Cok sevindim. Tum dunyada kullanici sayisi cok fazla. > Kongar: Dogrudur. W95 gelmis gecmis en yaygin isletim sistemi. Yani Amerika, Avrupa, Japonya ki tuketici haklarinin cok iyi korundugu ve yanlis reklamin siddetle hem hukuki hemde kamuoyu nezdinde cezalandirildigi ve derhal itibar kaybettigi bilincli tuketici pazarlari bunlar. > Kongar: Tuketici dunyanin hemen heryerinde benzeri karakteristikler gosterir. Sizin de yazmis oldugunuz gibi korunmaya muhtac bir varliktir O. Yuzlerce dergi enine boyuna programlari didik didik inceliyor binlerce okuruna aktariyor. Buralarda PC kullanacak kapasitedeki bir suru insan W95-Warp-Merlin-Mac vs pazarda gorup deniyor ve hernasilsa toplu bir ahmaklikla cok sayida insan digerleri yanindaki dezavantajlarina ragmen W95 > Kongar: Ahmaklik ya da benzeri sifatlari daha once bu forumda kullanmamis olugumu hatirlatirim :-( Lutfen size ait sifatlari bana atfetmeyiniz. tercih ediyor. Ama siz faka basmiyor W95 sadece bir pazarlama basarisi oldugunu hemen farkediyorsunuz ve fakat yine de kullanmaya devam ediyorsunuz. > Kongar: W95'i kullanmaya devam etmiyorum. Linux 2.0.29 kullaniyorum. W95'in ciddi bir pazarlama basarisi oldugu gorusumu surduruyorum. Ayrica; 1987 yilinda Lotus 123 kullanarak yaptigim islemler, x1000 gucunde CPU'su olan simdiki bilgisayarimda W95 ve Excel altinda daha uzun surede sonuc veriyor. Bu da beni uzuyor. >Hirosima/W95, Hitler/Bill benzetmeleri bir iki duyunca bu yaratici zeka urunu espriler cok hos oluyor ama ayni seyler durmadan tekrarlayinca artik gulemiyorum. > Kongar: Bende. Kendi adima genellikle sakalari her farkli ortamda sadece bir defa yapmaya calisirim. Ancak bazi arkadaslarin kullandigi imzalar bu tur sureklilikleri de iceriyor. Ne yapabilirim ? :-< Birde sunu anlayamiyorum: makinama bilmem ne taktim....6 kere restart yaptim tanimadi 7 cisinde tanidi ne aptal program... Yahu bu insanmi ki jetonu gec dussun? 6 kere yapilan her ne ise 7 cisinde degistirilmiski makina tanima islemini gerceklestirmis. > Kongar: Son derece dogru bir gozlem. Hic tasarim hatasi olamayan kullanici hatalarini da gideren programlar yapilacak elbette. Buna inaniyorum W2.0 dan baslayip W95e gelinen surec bunu gosteriyor. > Kongar: Bence de genel surec iyilesme egilimi gosteriyor. Ancak ben bu egilimi Windows (TM) uygulamalarinda gormekte gucluk cekiyorum. Hatirlatirim W95, 15 yildir halihazirda varolan MacOs isletim sistemini ancak simdi kopya edebilmeye basladi. Yine inaniyorum ki ayni kategorideki sozkonusu isletim sistemleri esasen hemen hemen ayni performansi gosteriyor. > Kongar: Bu bir inanc degil hesap meselesi. Ben olctum, begenmedim. Kisisel olarak MS tercih ettim cunku software firmalari icinde finansman gucu en yuksek olani. > Kongar: Ben kendi program tercihlerimi program kalitesine gore yapmaya calisirim. Uretici firmanin finansman gucu beni cok da fazla ilgilendirmez. Piyasada soz sahibi olacagi kacinilmaz. Yan sanayi destegi de onun ruzgarina kapilmis gidiyor. > Kongar: Oldu zaten. :-) O halde MS ve windows kulturune nekadar cabuk alisirsam mevcut ve ileride piyasalara cikacak programlara ortak ozellikleri nedeniyle daha hizli adapte olabilirim diye dusunuyorum zira ben artik her yil yeni bir program ogrenmekten biktim. > Kongar: Neden her yil yeni bir program kullaniyorsunuz? Yaptiginiz isin yapisi degismedigi surece kullandiginiz programlarin da ayni kalmasi beklenir. Yoksa siz gerekmedigi halde surekli daha yeniyi arayan gruba mi dahilsiniz? Wordstar-Wordperfect-Lotus123 zinciri yerine Word2-Word7-Excel zincirini takip etmek benim icin cok daha az caba gerektiriyor. > Kongar: Benim icin de. Zincirleri cok da fazla takip etmemek cok daha az caba gerektirir. Tekellesmenin onlenmesi ve rekabet acisindan diger firmlarinda pazar paylarini korumalari gerekiyor elbette iste o yuzden bi zahmet W95 i birakip bu sistemlere gecin de hem siz kurtulun hemde piyasa dengeleri kurulsun. > Kongar: Sahsen freeware (yani sebil) bir isletim sistemi kullandigim icin yukaridaki onerinize ne yazik ki uyamayacagim. Pazarin dengeleri konsunda yapmaya calistigim tek sey Micro$oft urunlerini kullanmamak. Sevgiler D.Geyran Not: Cevap yazmak icin Sn Kongar'in mail i tesadufen denk gelmistir. Elestrimin kisisel olmadigi acik ancak yinede her ihtimale karsi hosgorusune sigindigimi belirtmek istiyorum. > Kongar: Sevgili Geyran, forumlar keyifle tartismak icindir. Siz de ben de burada yazilmis olanlarin birbirimizin fikirlerini cok da etkilemeyecegini biliyoruz. Ancak yeni insanlarla tanismanin keyfi hic bir seyde yok. :-) Cok Sevgiler, Kongar   Received: from ietf.org by ietf.org id aa16049; 25 Feb 97 3:33 EST Received: from dns.doruk.net.tr by ietf.org id aa15927; 25 Feb 97 3:32 EST Received: by bbs.doruk.com.tr id ab08920; 25 Feb 97 10:28 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Imran Geriskovan X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: Re[2]: W95 ten sikayete devam Date: Fri, 21 Feb 97 03:02:23 Resent-Date: Tue, 25 Feb 97 10:23:22 TSI Xorg-Content: text/plain; charset="dbbs-dos" Content-Type: text/plain; charset="us-ascii" Message-ID: <9702251028.ab08920@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. >El insaf yani.!...Artik dayanamayip cevap yazmak istiyorum.! >Sayin forumcular W95 ten baskada OS ler var neden onlari kullanmiyorsunuzda >onunuze konana kendinizi mecbur >hissediyorsunuz. Bunca sesiz kullanici var benim bildiklerimin kabaca yaridan >cok fazlasi sikayetci degiller. Bir >yildir kullaniyorum onemli bir sorun cikmadi. Begenmesem hemen baska sisteme >gecerdim. Onume ne konsa razi >olmazdim. Bakiniz, 1) Urunler ile ilgili forumlar genellikler herhangibir urunun "Ne kadar muthis" oldugunun yazilmasi icin degil o urunler hakkinda kritik yapmak icin kurulur. Bu tip forumlarda bir problem duyurulur ve mumkunse birlikte cozum aranir. Eger bulunamiyorsa "Bulunamadigi" tescil edilir. Tipki W95 in bircok problemi gibi. Alin size 2 kucuk! problem daha: * Herhangibir network drive a erisim hakkiniz yokmu? Hic dert etmeyin. DOS prompta dusun, istediginiz yerde at oynatin. * Atlas Net teki bir SysOp ile gorusurken bana soyle dedi: "Microsoft Network Client yuklu iken sakin ola Dial-Up baglanti yapmayin. Disaridan makinaniza girmeleri cok kolaydir." Ben "Ama file sharing kapaliyken nasil olur?" deyince SysOp "Isteseniz simdi yapayim" dedi. :) Isterseniz dahada yazabilirim. Hadi buglardan, hatalardan vazgectim bunlar resmen guvenliginizi tehdit edebilecek unsurlar. Sizin kafanizdaki "Muhtesem Bill" veya "Buyuk M$ Imparatorlugu" imajlarini biraz zedeliyor ama kusura bakmayin. Gercekler acidir. Aslinda siz isinize yarayacak olan bilgileri tepmeye dunden hazirsiniz. Bari sesinizi cikarmayinda digerleri kullansin bunlari. 2) Bize baska islerim sistemleri tavsiye etmissiniz. Eksik olmayin. Zaten digerlerinide kullaniyoruz. Ve kullandikca "W95" in ne kadar muthis! oldugunu daha iyi anliyoruz. 3) Hazir bize isletim sistemleri hakkinda tavsiyede bulunmusken bende size bazi tavsiyelerde bulunayim: (Yukaridaki yazinizdan bir miktar alip degistirdim. Umarim kizmazsiniz) "Forumu begenmesem hemen baska foruma gecerdim. Ne posta yazilsa razi olmazdim." >Ama siz faka basmiyor W95 sadece bir pazarlama basarisi oldugunu hemen >farkediyorsunuz ve fakat yinede >kullanmaya devam ediyorsunuz. 4) "W95 i begenmemem" ve "kullanmaya devam etmem" arasinda oyle acaip! bir paradox goremiyorum. Kullanma sebeplerimide aciklamak durumunda da degilim. >olacagi kacinilmaz. Yan sanayi destegide onun ruzgarina kapilmis gidiyor. O >halde MS ve windows kulturune >nekadar cabuk alisirsam mevcut ve ileride piyasalara cikacak programlara >ortak ozellikleri nedeniyle daha hizli >adapte olabilirim diye dusunuyorum zira ben artik her yil yenibir program >ogrenmekten biktim. 5) Galiba "Program ezberlemekten biktim" demek istediniz. 6) Anladigim kadar ile sade bir kullanicisiniz. Kimse sadece kullanici oldugu icin ayiplanmaz. Ama burada sadece "sade kullanici" muhabbeti beklemeniz hatadir. Bir miktar sikayet ile karisikda olasa teknik konular uzerinde tartisma olacaktir. Bunlardan rahatsiz oldugunuzu belirtmek yerine birseyler kapmaya calismaniz daha hayirlidir. Imran   Received: from ietf.org by ietf.org id aa16696; 25 Feb 97 3:38 EST Received: from dns.doruk.net.tr by ietf.org id aa16622; 25 Feb 97 3:36 EST Received: by bbs.doruk.com.tr id aa09114; 25 Feb 97 10:34 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Bengt Gorden X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Stop this imideatley......... Date: Tue, 25 Feb 1997 09:24:59 +0100 Resent-Date: Tue, 25 Feb 97 10:27:53 TSI Xorg-Content: text/plain; charset="us-ascii" Content-Type: text/plain; charset="us-ascii" Message-ID: <9702251034.aa09114@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. You seems to have the wrong config for this mail-list. Please reconfigure. Here is the headers to one of the letters to us on ietf@ietf.org Resent-From: ietf-request@ietf.org Resent-Message-Id: <199702250819.IAA17445@sunic.sunet.se> X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender: ietf-request@ietf.org From: Goktug Beser To: windows-f forum grubu uyeleri Subject: Re: W95 CONFIG.SYS Date: Mon, 24 Feb 1997 10:19:11 +0200 Resent-Date: Tue, 25 Feb 97 09:44:19 TSI Xorg-Content: text/plain; charset=Default Source-Info: From (or Sender) name not authenticated. /Bengan   Received: from ietf.org by ietf.org id aa17849; 25 Feb 97 3:50 EST Received: from AIC.NET by ietf.org id aa17583; 25 Feb 97 3:48 EST Received: by aic.net for at Tue, 25 Feb 1997 11:45:40 +0300 (GMT) Message-Id: <199702250845.LAA11536@aic.net> Subject: "Robert W. Hall": Re: Red Alert (fwd) To: postmaster@ietf.org, ietf@ietf.org Date: Tue, 25 Feb 1997 11:45:40 +0300 (GMT) Sender:ietf-request@ietf.org From: Edgar Danielian Content-Type: text Source-Info: From (or Sender) name not authenticated. Postmaster@ietf.org, why don't you allow access to ietf@ietf.org only for subscribers? It seems these 'European turks' doesn't even understand English.... Edgar Forwarded message: > From ietf-request@ietf.org Tue Feb 25 04:56:07 1997 > Resent-From: ietf-request@ietf.org > Resent-Message-Id: <199702250155.EAA10543@aic.net> > X-Orig-Sender: Doruk-BBS Forum Servisi > Errors-To: forum-error@doruk.com.tr > Reply-To: oyun-f@doruk.com.tr > Sender: ietf-request@ietf.org > From: Serpil Bayraktar > X-Mailer: Doruk-BBS Forum Servisi > To: oyun-f forum grubu uyeleri > Subject: "Robert W. Hall": Re: Red Alert > Date: Mon, 24 Feb 1997 20:42:42 -0500 > Resent-Date: Tue, 25 Feb 97 03:44:10 TSI > Content-Type: text/plain; charset="us-ascii" > Message-ID: <9702250350.aa03810@bbs.doruk.com.tr> > Source-Info: From (or Sender) name not authenticated. > > > Arkadaslar, herhalde mailing listlerde bir karisiklik oldu. IETF > mailing list Internet'i ilgilendiren konular icin kullanilan ve > *ingilizce* yazismanin oldugu bir list. Lutfen IETF'i genel listenizden > cikarin. > > Tesekkurler, > Serpil Bayraktar   Received: from ietf.org by ietf.org id aa19547; 25 Feb 97 4:15 EST Received: from dns.doruk.net.tr by ietf.org id ab19388; 25 Feb 97 4:13 EST Received: by bbs.doruk.com.tr id ab10551; 25 Feb 97 11:10 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Denis Trcek X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: remove Date: Tue, 25 Feb 1997 10:02:38 +0100 Resent-Date: Tue, 25 Feb 97 11:02:25 TSI Content-Type: text/plain; charset="us-ascii" Message-ID: <9702251110.ab10551@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. unsubscribe denis.trcek@ijs.si remove denis.trcek@ijs.si   Received: from ietf.org by ietf.org id aa19548; 25 Feb 97 4:15 EST Received: from dns.doruk.net.tr by ietf.org id aa19388; 25 Feb 97 4:13 EST Received: by bbs.doruk.com.tr id aa10551; 25 Feb 97 11:10 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Guenther Schreiner X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Please stop - you flood the world !!! Date: Tue, 25 Feb 1997 09:58:46 +0100 Resent-Date: Tue, 25 Feb 97 11:00:55 TSI Content-Type: text/plain; charset="us-ascii" Message-ID: <9702251110.aa10551@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. I don't know what's the list about. Please remove the ietf@org receipient - this one is an english world-wide mailing list for Internet concerns. Regards, Guenther -- Guenther Schreiner | University of Karlsruhe, Germany Fakultaet fuer Informatik (CSD) ---+--- Am Fasanengarten 5 | Phone: (+49) 721 608-3980 or 4321 76128 Karlsruhe | FAX: (+49) 721 9663550 | INTERNET: guenther@ira.uka.de X.400: G=Guenther/S=Schreiner/OU=Informatik/PRMD=UNI-KARLSRUHE/ADMD=D400/C=DE/; --   Received: from ietf.org by ietf.org id aa24692; 25 Feb 97 5:24 EST Received: from wf10.wfa.digital.ie by ietf.org id aa24593; 25 Feb 97 5:21 EST Received: by gateway.wfa.digital.ie; (8.7.3/1.3/10May95) id LAA06574; Tue, 25 Feb 1997 11:26:07 GMT Sender:ietf-request@ietf.org From: Dermot Tynan Message-Id: <9702251019.AA11851@karpov.wfa.digital.ie> Subject: Re: "Robert W. Hall": Re: Red Alert (fwd) To: Edgar Danielian Date: Tue, 25 Feb 1997 10:19:32 +0000 (GMT) Cc: postmaster@ietf.org, ietf@ietf.org In-Reply-To: <199702250845.LAA11536@aic.net> from "Edgar Danielian" at Feb 25, 97 11:45:40 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Edgar Danielian wrote: > > why don't you allow access to ietf@ietf.org only for subscribers? > It seems these 'European turks' doesn't even understand English.... Before we get too excited, it would appear that some cowboy (or cowgirl) somewhere has faked a "subscribe" message to this Turkish mailing list, on behalf of the IETF mailing list. If they don't take us off fairly soon, I'll see if I can fake an "unsubscribe". - Der -- Dermot Tynan +353 91 754608 dtynan@wfa.digital.ie DTN: 822-4608 AltaVista Internet Software, Galway, Ireland   Received: from ietf.org by ietf.org id aa02808; 25 Feb 97 8:11 EST Received: from dns.doruk.net.tr by ietf.org id aa02554; 25 Feb 97 8:08 EST Received: by bbs.doruk.com.tr id aa14474; 25 Feb 97 15:04 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Ken Hays X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: remove Date: Tue, 25 Feb 1997 07:34:15 -0500 Resent-Date: Tue, 25 Feb 97 14:58:06 TSI In-Reply-To: <9702251110.ab10551@bbs.doruk.com.tr> Content-Type: text/plain; charset="us-ascii" Message-ID: <9702251504.aa14474@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. Realize you may know better, but a message got to me [just a list member, not the maintainer] that has to do with administrivia on a list, so a gentle reminder is in order. In general, to do ANY administrative thing on ANY internet mailing list one sends mail to the list name with -REQUEST appended. For example, the administrivia address for is . Yes,-REQUEST can be lowercase also, as in . Of course, the advice above is predicated on your being interested in the master list. However, if you are trying to unsubscribe and are getting your copy from a secondary exploder, you need to send a message to the exploder administrivia address. You may want/need to to look at the headers for of a typical mail message from the list to determine whether you are on the master list or an exploder. Or, asking your postmaster to look at the headers for you would work too. In addition, for a lot of lists you should not plan on having the list administrator reading the list. Be PATIENT, the humans that do mailing list maintenance often do that as an ancillary task and sometimes have to do their "real" jobs and the list maintenance takes a lesser priority. Later, Ken --------------- Prompting Message Follows --------------- From daemon Tue Feb 25 04:35:25 1997 Received: from ietf.org (ietf.org [132.151.1.19]) by mailer.scri.fsu.edu (8.8.5/8.7.5) with SMTP id EAA10574 for ; Tue, 25 Feb 1997 04:35:23 -0500 (EST) Resent-From: ietf-request@ietf.org Resent-Message-Id: <199702250935.EAA10574@mailer.scri.fsu.edu> Received: from ietf.org by ietf.org id aa19494; 25 Feb 97 4:14 EST Received: from dns.doruk.net.tr by ietf.org id ab19388; 25 Feb 97 4:13 EST Received: by bbs.doruk.com.tr id ab10551; 25 Feb 97 11:10 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr X-Mailer: Doruk-BBS Forum Servisi Resent-Date: Tue, 25 Feb 97 11:02:25 TSI Content-Type: text/plain; charset="us-ascii" Message-ID: <9702251110.ab10551@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. From: Denis Trcek Sender: ietf-request@ietf.org To: windows-f forum grubu uyeleri Subject: remove Date: Tue, 25 Feb 1997 10:02:38 +0100 unsubscribe denis.trcek@ijs.si remove denis.trcek@ijs.si   Received: from ietf.org by ietf.org id aa05132; 25 Feb 97 8:46 EST Received: from dns.doruk.net.tr by ietf.org id aa05001; 25 Feb 97 8:44 EST Received: by bbs.doruk.com.tr id aa15340; 25 Feb 97 15:41 TSI X-Orig-Sender: Doruk-BBS Forum Servisi Errors-To: forum-error@doruk.com.tr Reply-To: windows-f@doruk.com.tr Sender:ietf-request@ietf.org From: Bill Manning X-Mailer: Doruk-BBS Forum Servisi To: windows-f forum grubu uyeleri Subject: Re: W95 CONFIG.SYS Date: Tue, 25 Feb 1997 05:32:03 -0800 (PST) Resent-Date: Tue, 25 Feb 97 15:32:37 TSI In-Reply-To: <9702250951.aa07868@bbs.doruk.com.tr> from "Goktug Beser" at Feb 24, 97 10:19:11 am Xorg-Content: text/plain; charset=US-ASCII Content-Type: text/plain; charset="us-ascii" Message-ID: <9702251541.aa15340@bbs.doruk.com.tr> Source-Info: From (or Sender) name not authenticated. > > Bilgisayari kapatirken cikan "bilgisayarinizi kapatabilirsiniz " hangi > isimli dosyada acaba? Edit etmek istiyorum da! > > Goktug > > > >>Valla bildigim kadariyla 320x200 BMP olarak kaydettigin resmi ROOT'a > > >>"logo.sys" olarak atiyosun ve oluyor. Hatta shut down olayinda cikan > > >yazilarda > > >>bi zahmet aciklarmi? > > >>Lord Spike!!!x > > >> > > > > > >Dedigin dogru ama 320x400 cozunurlukte olacak grafikler. En fazla da 256 > renk > > >icerebilirler. > > > > > >Dark > > > > Sagol. Peki su cycle olayina bi cozum bilen yokmu? Hani Windows95 > yazarken > > alttan mavi renkler geciyor ya! > > Lord Spike!!!x > -- --bill   Received: from ietf.org by ietf.org id aa08924; 25 Feb 97 9:41 EST Received: from ietf.ietf.org by ietf.org id aa08411; 25 Feb 97 9:31 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipng@sunroof.eng.sun.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-gseaddr-00.txt Date: Tue, 25 Feb 1997 09:31:48 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702250931.aa08411@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : GSE - An Alternate Addressing Architecture for IPv6 Author(s) : M. O'Dell Filename : draft-ietf-ipngwg-gseaddr-00.txt Pages : 20 Date : 02/24/1997 This document presents an alternative addressing architecture for IPv6 which controls global routing growth by very aggressive topological aggregation. It includes support for scalable multi-homing as a distinguished service. It provides for future independent evolution of routing and forwarding models with essentially no impact on end systems. Finally, it frees sites and service resellers from the tyranny of CIDR-based aggregation by providing transparent re-homing of both. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-gseaddr-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-gseaddr-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-gseaddr-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970224104130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-gseaddr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-gseaddr-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970224104130.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08923; 25 Feb 97 9:41 EST Received: from ietf.ietf.org by ietf.org id aa08454; 25 Feb 97 9:31 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mboned@ns.uoregon.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mboned-pmbr-spec-00.txt, .ps Date: Tue, 25 Feb 1997 09:31:53 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702250931.aa08454@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : PIM Multicast Border Router (PMBR) specification for connecting PIM-SM domains to a DVMRP Backbone Author(s) : D. Estrin, A. Helmy, D. Thaler Filename : draft-ietf-mboned-pmbr-spec-00.txt, .ps Pages : 8 Date : 02/24/1997 This document specifies the behavior of PIM-SM Multicast Border Routers (PMBRs) that connect PIM-SM to DVMRP networks. We assume that the reader is familiar with the PIM-SM protocol specification.[Estrin96] Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mboned-pmbr-spec-00.txt". Or "get draft-ietf-mboned-pmbr-spec-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-pmbr-spec-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mboned-pmbr-spec-00.txt". Or "FILE /internet-drafts/draft-ietf-mboned-pmbr-spec-00.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@ds.internic.net" Content-Type: text/plain Content-ID: <19970224172020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mboned-pmbr-spec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mboned-pmbr-spec-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970224172020.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16684; 25 Feb 97 11:06 EST Received: from uhura.ijs.si by ietf.org id aa15818; 25 Feb 97 11:01 EST Received: from cathy.ijs.si by uhura.ijs.si with SMTP using DNS (PP) id <29317-0@uhura.ijs.si>; Tue, 25 Feb 1997 16:58:50 +0100 Received: from e6pc23.ijs.si by CATHY.IJS.SI (PMDF V4.3-10 #8779) id <01IFU9DXLZJK003TPJ@CATHY.IJS.SI>; Tue, 25 Feb 1997 16:58:45 +0001 Received: by e6pc23.ijs.si with Microsoft Mail id <01BC233D.6E56C9D0@e6pc23.ijs.si>; Tue, 25 Feb 1997 17:00:41 +0100 Date: Tue, 25 Feb 1997 17:00:38 +0100 Sender:ietf-request@ietf.org From: Denis Trcek Subject: Turkish mailing list To: "'ietf@ietf.org'" Message-id: <01BC233D.6E56C9D0@e6pc23.ijs.si> MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Source-Info: From (or Sender) name not authenticated. I' d like to apologise for inconvinience to everybody that has received my "unsubscribe" mail. Actually, I was getting bombed with messages from one turkish mailing list that *I have never subscribed to* and just wanted to get off that list. I made a reply and now I see I was likely getting these messages via IETF mailing list. So I guess I am not the only one with this problem... Denis Trcek IJS, Ljubljana, SI   Received: from ietf.org by ietf.org id aa19443; 25 Feb 97 12:10 EST Received: from catapult.routerware.com by ietf.org id aa19282; 25 Feb 97 12:06 EST Received: by catapult.RouterWare.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC22FA.CF065B80@catapult.RouterWare.com>; Tue, 25 Feb 1997 09:03:47 -0800 Message-ID: Sender:ietf-request@ietf.org From: Brian Collis To: "'ietf@ietf.org'" Subject: Remove Date: Tue, 25 Feb 1997 09:03:45 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. unsubscribe: bcollis@routerware.com Remove bcollis@routerware.com   Received: from ietf.org by ietf.org id aa24087; 25 Feb 97 14:15 EST Received: from gateway.gtech.com by ietf.org id aa23830; 25 Feb 97 14:07 EST Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <46203>; Tue, 25 Feb 1997 13:09:17 -0500 Received: from ccgate by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-X) via SMTP; id AA1686810951; Tue, 25 Feb 1997 13:09:11 -0500 Received: from ccMail by ccgate.gtech.com (ccMail Link to SMTP R6.0) id AA856894164; Tue, 25 Feb 97 13:13:53 -0500 Message-Id: <9702258568.AA856894164@ccgate.gtech.com> X-Mailer: ccMail Link to SMTP R6.0 Date: Tue, 25 Feb 97 13:09:08 -0500 Sender:ietf-request@ietf.org From: postmaster To: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: cc:Mail Link to SMTP Undeliverable Message Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Source-Info: From (or Sender) name not authenticated. --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: Unable to access cc:Mail Post office. Please retry later. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from ops.soft.gtech.com by ccgate.gtech.com (ccMail Link to SMTP R6.0) ; Tue, 25 Feb 97 08:09:06 -0500 Return-Path: Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-X) via SMTP; id AA1182058200; Tue, 25 Feb 1997 08:04:24 -0500 Received: from probity.mcc.ac.uk ([130.88.200.94]) by gateway.gtech.com with SMTP id <46087>; Tue, 25 Feb 1997 08:04:21 -0500 Received: from hades.mcc.ac.uk [130.88.202.93] by probity.mcc.ac.uk with esmtp (Exim 1.59 #1) id 0vzMGX-0001gQ-00; Tue, 25 Feb 1997 12:45:53 +0000 Received: (from majordomo@localhost) by hades.mcc.ac.uk (8.8.5/8.7.3) id MAA17666; Tue, 25 Feb 1997 12:45:14 GMT Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hades.mcc.ac.uk (8.8.5/8.7.3) with SMTP id MAA17648 for ; Tue, 25 Feb 1997 12:44:54 GMT Received: from alpha1.superonline.com [194.242.73.12] by probity.mcc.ac.uk with smtp (Exim 1.59 #1) id 0vzMFY-0001f3-00; Tue, 25 Feb 1997 12:44:53 +0000 Received: from bulent-uludag ([194.242.76.74]) by alpha1.superonline.com (Netscape Mail Server v2.0) with ESMTP id AAA412 for ; Tue, 25 Feb 1997 14:44:16 +0300 From: "IETF" To: "cubase-users" Subject: Where can I find... Date: Sat, 24 Feb 1996 14:39:09 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-cubase-users@mcc.ac.uk Precedence: bulk Is there any source on the web about tonemaistering? I want to learn some basics and general tips about recording and mixing (especially EQing).. Thank you. SoniC --simple boundary--   Received: from cnri by ietf.org id aa24526; 25 Feb 97 14:21 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa18776; 25 Feb 97 14:21 EST Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id NAA05966 for uri-out; Tue, 25 Feb 1997 13:31:13 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id NAA05948; Tue, 25 Feb 1997 13:30:58 -0500 (EST) From: touch@isi.edu Received: from zephyr.isi.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29768 (mail destined for urn-ietf@services.bunyip.com); Tue, 25 Feb 97 13:30:56 -0500 Received: from ash.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 25 Feb 1997 10:30:54 -0800 Date: Tue, 25 Feb 1997 10:30:49 -0800 Posted-Date: Tue, 25 Feb 1997 10:30:49 -0800 Message-Id: <199702251830.AA12562@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Tue, 25 Feb 1997 10:30:49 -0800 To: touch@isi.edu, connolly@w3.org Subject: Re: URI-protocol mapping (was Re: How to add new "protocols" ?) Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, uri@bunyip.com, urn-ietf@bunyip.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-uri@bunyip.com Precedence: bulk > From connolly%w3.org@beach.w3.org Fri Feb 21 09:39:57 1997 > > touch@ISI.EDU wrote: > > > > > OK, I'll bite: how is it that "location-dependent" vs. > > > "location-independent" is a technical distinction? > > > It's very technical. The host requirements RFC specifies locations > > as either fully-qualified DNS names or IP addresses. And that's what > > you have here. I.e., you have as much of a location as the internet > > allows. > > Ah! I wan't aware of that. I really appreciate you pointing > that out. > > OK, I'm happy with 'location-independent' as a technical > term if 'location' is defined as 'FQDN or IP > address'. I inferred the more geographic connotations. > A quick scan of the URN requirements/framework draft[1] > and the URN requirements RFC[2] doesn't > show a similar definition of 'location'. And there's > no reference to the host requirements RFC. That is a clear inconsistency. Given that HTTP/1.1 does ref it. > Hang on... I went to add it to my glossary of web > architecture terms[3], but a brief scan of the > host requirements RFC[4] shows: > > |the DNS provides globally-unique, > | location-independent names. > > If a FQDNs are locations, how does DNS provide > location-independent names? We're confusing the term location here, as is probably obvious. The DNS provides globally-unique, (geographically) location-independent names. FQDNs are locations, just not geographic ones. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/   Received: from ietf.org by ietf.org id aa01063; 25 Feb 97 17:27 EST Received: from ietf.ietf.org by ietf.org id aa00650; 25 Feb 97 17:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: confctrl@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mmusic-rtsp-01.txt, .ps Date: Tue, 25 Feb 1997 17:16:01 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702251716.aa00650@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne, A. Rao, R. Lanphier Filename : draft-ietf-mmusic-rtsp-01.txt, .ps Pages : 61 Date : 02/24/1997 The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and delivery mechanisms based upon RTP (RFC 1889). 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-mmusic-rtsp-01.txt". Or "get draft-ietf-mmusic-rtsp-01.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rtsp-01.txt". Or "FILE /internet-drafts/draft-ietf-mmusic-rtsp-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970225121758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970225121758.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03293; 25 Feb 97 18:12 EST Received: from ietf.ietf.org by ietf.org id aa02922; 25 Feb 97 18:08 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) to Proposed Standard Date: Tue, 25 Feb 1997 18:08:31 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702251808.aa02922@ietf.org> The IESG has approved the Internet-Draft "The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. Technical Summary This document defines a protocol used to dynamically allocate bandwidth on PPP links which are using the PPP Multilink Protocol. The protocol includes mechanisms for adding links to and deleting links from the multilink bundle. Working Group Summary This protocol was developed in the PPPEXT working group. Development was without rancor. Protocol Quality The protocol has been reviewed by Frank Kastenholz and Jeff Burgan.   Received: from ietf.org by ietf.org id aa03484; 25 Feb 97 18:14 EST Received: from ietf.ietf.org by ietf.org id aa03352; 25 Feb 97 18:12 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Sender:ietf-announce-request@ietf.org From: The IESG Subject: Document Action: Microsoft Point-To-Point Compression (MPPC) Protocol to Informational Date: Tue, 25 Feb 1997 18:12:52 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702251812.aa03352@ietf.org> The IESG has reviewed the Internet-Draft "Microsoft Point-To-Point Compression (MPPC) Protocol" and recommends that it be published by the RFC Editor as an Informational RFC. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan.   Received: from ietf.org by ietf.org id aa03630; 25 Feb 97 18:16 EST Received: from ietf.ietf.org by ietf.org id aa03535; 25 Feb 97 18:15 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rtfm@auckland.ac.nz Sender:ietf-announce-request@ietf.org From: The IESG Subject: Document Action: Traffic Flow Measurement: Experiences with NeTraMet to Informational Date: Tue, 25 Feb 1997 18:15:04 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702251815.aa03535@ietf.org> The IESG has reviewed the Internet-Draft "Traffic Flow Measurement: Experiences with NeTraMet" and recommends that it be published by the RFC Editor as an Informational RFC. This document is the product of the Realtime Traffic Flow Measurement Working Group. The IESG contact persons are Scott Bradner and Michael O'Dell.   Received: from ietf.org by ietf.org id aa04000; 25 Feb 97 18:20 EST Received: from ietf.ietf.org by ietf.org id aa03751; 25 Feb 97 18:18 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: The IESG Subject: Document Action: Managing the X.500 Root Naming Context to Experimental Date: Tue, 25 Feb 1997 18:18:08 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702251818.aa03751@ietf.org> The IESG has reviewed the Internet-Draft "Managing the X.500 Root Naming Context" and recommends that it be published by the RFC Editor as an Experimental RFC. This document is the product of the Integrated Directory Services Working Group. The IESG contact persons are Keith Moore and Harald Alvestrand.   Received: from ietf.org by ietf.org id aa04476; 25 Feb 97 18:25 EST Received: from ietf.ietf.org by ietf.org id aa04068; 25 Feb 97 18:21 EST To: IETF-Announce: ; cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: Use of DNS Aliases for Network Services to BCP Reply-to: iesg@ietf.org Date: Tue, 25 Feb 1997 18:21:37 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702251821.aa04068@ietf.org> The IESG has received a request from the Integrated Directory Services Working Group to consider "Use of DNS Aliases for Network Services" for the status of BCP. 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@ietf.org or ietf@ietf.org mailing lists by March 11, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from ietf.org by ietf.org id aa05653; 25 Feb 97 18:37 EST Received: from hail.ncr.disa.mil by ietf.org id aa05390; 25 Feb 97 18:35 EST Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id SAA00197; Tue, 25 Feb 1997 18:14:39 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA856922921; Tue, 25 Feb 97 17:39:20 EST Date: Tue, 25 Feb 97 17:39:20 EST Sender:ietf-request@ietf.org From: Bill Flanigan Message-Id: <9701258569.AA856922921@ncr.disa.mil> To: ietf@ietf.org, Roger WOJA Kermode Cc: flanigab@ncr.disa.mil Subject: Re: 38th IETF Meeting...Hotel Gripe Source-Info: From (or Sender) name not authenticated. Hello Roger, Maybe you're lucky--well, sort of. The IETF group-rate at the Peabody is simply outrageous! The rate at the Holiday Inn is no bargain either. After all, this is Memphis TN (not Memphis, Egypt or Mars) where the going rates for hotels/motor inns/motels is in the $50-60 range--AAA, e.g., lists about 25 (with three-diamond ratings) in that price range including a number within brisk-walking distance of the Peabody. BTW, the IETF group-rates at the San Jose Fairmont Hotel and those nearby were often more than the going AAA rates. Naturally, this can't help, but make me a bit curious about who (if anyone) is seriously negotiating these rates, and what criteria (if any) are being used? IETF attendance is now so large that advance-booking guarantees to completely fill many hotels in an area (even a year in advance) is virtually riskless. This should put the IETF hotel-booking folks firmly in the driver's seat as far as getting the lowest possible room rate in the meeting hotel and others in the area. I wonder what's really going on here? Can't wait to find out the group rates for the Munich Sheraton Hotel! Would you believe 135DM?! Bill Flanigan (who will be commuting, and not by choice) ______________________________ Reply Separator _________________________________ Subject: 38th IETF Meeting...Hotel Gripe Author: Roger WOJA Kermode at smtp Date: 2/24/97 6:41 PM I just rang the Peabody Memphis hotel in an attempt to make a booking and was informed that all the rooms allocated to the conference were already booked (not a huge surpirse). When I asked if I might be put on a waiting list for any rooms that might be cancelled I was informed rather curtly that if a room from the IETF block was cancelled it would be available at the *regular* rate, i.e. the IETF rate would no longer reply. Is this standard practice? I would have assumed that given the nature of the IETF corwad, that more than a few people that pre-book and then subsequently cancel would not be insignificant, thus leading to their `replacements' paying extra.... Roger (who will be staying across the road at the Holiday Inn) Roger Kermode Research Assistant woja@media.mit.edu tel : +1 617 253 0341 Entertainment & Information Systems Group fax : +1 617 258 6264 MIT Media Lab, 20 Ames St, RmE15-354, Cambridge, MA 02139 USA   Received: from ietf.org by ietf.org id aa12664; 25 Feb 97 20:03 EST Received: from cbgw3.lucent.com by ietf.org id aa12478; 25 Feb 97 20:01 EST Received: from drmail.dr.lucent.com by cbig3.firewall.lucent.com (SMI-8.6/EMS-L sol2) id TAA06032; Tue, 25 Feb 1997 19:50:09 -0500 Received: by drmail.dr.lucent.com (4.1/EMS-L SunOS) id AA04714 for ietf@ietf.org; Tue, 25 Feb 97 17:58:52 MST Received: from lever.dr.lucent.com by drmail.dr.lucent.com (4.1/EMS-L SunOS) id AA04656 for ietf@ietf.org; Tue, 25 Feb 97 17:58:42 MST Received: by lever.dr.lucent.com (4.1/EMS-L SunOS) id AA13799; Tue, 25 Feb 97 16:58:42 PST Date: Tue, 25 Feb 97 16:58:42 PST Message-Id: <9702260058.AA13799@lever.dr.lucent.com> Sender:ietf-request@ietf.org From: Neal McBurnett To: ietf@ietf.org Subject: ids-dnsnames-02.txt: add list.domain.name for mail lists Reply-To: Neal McBurnett Cc: m.t.hamilton@lut.ac.uk, wright@lbl.gov Comments: Hyperbole mail buttons accepted, v04.01. Source-Info: From (or Sender) name not authenticated. I think draft-ietf-ids-dnsnames-02.txt is very helpful - thanks. I think one more common name should be added for machines which are dedicated to serving mail lists (e.g. via majordomo or listserv). The machines are frequently distinct from the "mail" machine for a given organization because the operational characteristics and requirements can be very different. I propose the alias "list" for the "mail list" service. It is the most common generic name in the lists I subscribe to. Are there common alternatives? And here is a typo: > point to the DNS server. In fact, the most prevalent use of NS to > name DNS servers. For this reason, we suggest the use of PH as the s/use of NS to/use of NS is to/ and furthermore, for consistancy: s/NS/"ns"/ Cheers, Neal McBurnett 503-331-5795 Portland/Denver Bell Labs Innovations for Lucent Technologies http://bcn.boulder.co.us/~neal/ (with PGP key)   Received: from ietf.org by ietf.org id aa14686; 25 Feb 97 20:27 EST Received: from nausicaa.mew.com by ietf.org id aa14519; 25 Feb 97 20:25 EST Received: from yupa.ca.mew.com (yupa.ca.mew.com [158.118.11.11]) by nausicaa.mew.com (8.6.11+2.5Wb2/3.4W-Claude-NAUSICAA-961123) with ESMTP id RAA11032; Tue, 25 Feb 1997 17:20:41 -0800 Received: from kiki.ca.mew.com (kiki.ca.mew.com [158.118.11.12]) by yupa.ca.mew.com (8.6.11+2.5Wb2/3.4W-YUPA-950728) with SMTP id RAA12466; Tue, 25 Feb 1997 17:22:38 -0800 Sender:ietf-request@ietf.org From: Claude Huss Message-Id: <199702260122.RAA12466@yupa.ca.mew.com> Subject: Re: 38th IETF Meeting...Hotel Gripe To: Bill Flanigan Date: Tue, 25 Feb 1997 17:21:28 -0800 (PST) Cc: ietf@ietf.org, woja@media.mit.edu, flanigab@ncr.disa.mil In-Reply-To: <9701258569.AA856922921@ncr.disa.mil> from "Bill Flanigan" at Feb 25, 97 05:39:20 pm X-Disclaimer: Opinions expressed here are strictly my own Organization: Matsushita Electric Works, Ltd. X-Mailer: ELM [2.4 PL23.Japanese] (Claude Huss) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3153 Source-Info: From (or Sender) name not authenticated. I got a room at Radison Hotel (185 Union Ave), EXACTLY in front of the Peabody for 83 dollars/night (Corporate rate). For what I could check on the web, Radison is not that bad. Check: http://www.travelbase.com/cgi-bin/search_properties.cgi?state=TN&city=Memphis&typeid=2&firstrow=76&featured= and http://www.memphisguide.com/ (Select Hotels) -- Claude Huss From Bill Flanigan: > > Hello Roger, > > Maybe you're lucky--well, sort of. > > The IETF group-rate at the Peabody is simply outrageous! The rate > at the Holiday Inn is no bargain either. > > After all, this is Memphis TN (not Memphis, Egypt or Mars) where > the going rates for hotels/motor inns/motels is in the $50-60 > range--AAA, e.g., lists about 25 (with three-diamond ratings) in that > price range including a number within brisk-walking distance of the > Peabody. > > BTW, the IETF group-rates at the San Jose Fairmont Hotel and those > nearby were often more than the going AAA rates. > > Naturally, this can't help, but make me a bit curious about who (if > anyone) is seriously negotiating these rates, and what criteria (if > any) are being used? > > IETF attendance is now so large that advance-booking guarantees to > completely fill many hotels in an area (even a year in advance) is > virtually riskless. This should put the IETF hotel-booking folks > firmly in the driver's seat as far as getting the lowest possible room > rate in the meeting hotel and others in the area. > > I wonder what's really going on here? > > Can't wait to find out the group rates for the Munich Sheraton > Hotel! Would you believe 135DM?! > > > Bill Flanigan (who will be commuting, and not by choice) > > > ______________________________ Reply Separator _________________________________ > Subject: 38th IETF Meeting...Hotel Gripe > Author: Roger WOJA Kermode at smtp > Date: 2/24/97 6:41 PM > > > > I just rang the Peabody Memphis hotel in an attempt to make a booking > and was informed that all the rooms allocated to the conference were > already booked (not a huge surpirse). > > When I asked if I might be put on a waiting list for any rooms that might > be cancelled I was informed rather curtly that if a room from the IETF > block was cancelled it would be available at the *regular* rate, > i.e. the IETF rate would no longer reply. > > Is this standard practice? I would have assumed that given the nature > of the IETF corwad, that more than a few people that pre-book and then > subsequently cancel would not be insignificant, thus leading to their > `replacements' paying extra.... > > Roger (who will be staying across the road at the Holiday Inn) > > > > Roger Kermode Research Assistant > woja@media.mit.edu tel : +1 617 253 0341 > Entertainment & Information Systems Group fax : +1 617 258 6264 > MIT Media Lab, 20 Ames St, RmE15-354, Cambridge, MA 02139 USA > > >   Received: from ietf.org by ietf.org id aa02570; 26 Feb 97 2:50 EST Received: from cnri by ietf.org id aa02262; 26 Feb 97 2:41 EST Received: from sunhegering7.nm.informatik.uni-muenchen.de by CNRI.Reston.VA.US id aa03801; 26 Feb 97 2:41 EST Received: from hpheger9.nm.informatik.uni-muenchen.de (hpheger9.nm.informatik.uni-muenchen.de [129.187.214.29]) by sunhegering7.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) with ESMTP id IAA09983; Wed, 26 Feb 1997 08:34:48 +0100 (MET) Received: from localhost (neumair@localhost) by hpheger9.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) with SMTP id IAA18455; Wed, 26 Feb 1997 08:34:40 +0100 (MET) Date: Wed, 26 Feb 1997 08:34:40 +0100 (MET) Sender:ietf-request@ietf.org From: Bernhard Neumair To: dbworld@cs.wisc.edu, dec_wireless@samson.zko.dec.com, dini@crim.ca, end2end-interest@venera.isi.edu, enternet@bbn.com, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@CNRI.Reston.VA.US, ifip-6-1@labs-n.bbn.com, ifip-nm@bbn.com, isadsoc@fokus.gmd.de, itc@fokus.gmd.de Subject: CALL FOR PAPERS: JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. **************************************************** *** Please note the new deadline for submissions *** **************************************************** [Apologies if you receive multiple copies of this.] ------------------------------------------------------------------ ********************* * Deadline Extended * ********************* CALL FOR PAPERS JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT Special Issue on Managing Mobility and Mobile Computing Systems Guest Editors: Bernhard Neumair (University of Munich) Rene Wies (TTI TECTRAN GmbH) During the recent years Mobile Computing has become a very important trend in the usage of computing systems. The advantages of mobility and the increasing availability of adequate hardware and software have promoted the development and deployment of wireless LANs. Furthermore, with greater distances being bridged by corporate networks, and with world-wide network access, mobile computing systems can be increasingly used almost anywhere and any time without a restriction on the available services (e.g., mail, WWW, etc.). Managing these mobile systems, the related services, data, and networks as well as managing the mobility aspects of users (e.g., location of home directories, applications, etc.), however, are still unsolved problems. This special issue is intended to address these issues and to provide hints for future directions. The focus of this special issue will be on, but is not limited to, the following topics: o Applicability of existing management concepts, tools, platforms, architectures, etc. to mobile computing o New concepts, tools, and protocols needed for the management of mobility and mobile computing systems o Aspects of dynamic management domains and management policies incorporating mobile computing systems o Management requirements imposed by new services and applications, and new techniques supporting mobility (e.g., replicating file systems, caching strategies) o Management requirements imposed by new technologies and standards (Wireless LANs, HIPERLAN, IEEE P802.11, Mobile IP, etc.) o Change and configuration management for mobile systems (dynamic configuration, downloading and customizing configurations), and integration aspects o Security and accounting aspects for mobile systems o Managing and integrating PDAs Instructions to Authors: Please submit four copies of your manuscript, not exceeding 20 double-spaced type-written pages, to one of the Guest Editors (postscript files by e-mail are also welcome). Please prepare manuscripts according to the Instructions to Contributors which can be found in any copy of the Journal. An electronic copy of this can be obtained by visiting JNSM www page at URL http://www.cstp.umkc.edu/jnsm/. Please include the authors' names, addresses, telephone and fax numbers, and e-mail addresses. Guest Editors: Dr. Bernhard Neumair Department of Computer Science University of Munich Oettingenstrasse 67, D-80538 Munich, Germany Phone: +49-89-2178-2171 Fax: +49-89-2178-2262 E-Mail: neumair@informatik.uni-muenchen.de Dr. Rene Wies TTI TECTRAN GmbH P.O. Box 251 D-82026 Gruenwald/Munich, Germany Phone: +49-89-641-97040 Fax: +49-89-641-4299 E-Mail: r.wies@ieee.org Schedule: Manuscript due: March 30, 1997 Notification of Acceptance: July 30, 1997 Revised Manuscript due: September 30, 1997 Publication Date: First Quarter 1998   Received: from ietf.org by ietf.org id aa05749; 26 Feb 97 4:48 EST Received: from cnri by ietf.org id aa05641; 26 Feb 97 4:44 EST Received: from emout14.mx.aol.com by CNRI.Reston.VA.US id aa05651; 26 Feb 97 4:44 EST Received: (from root@localhost) by emout14.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id EAA19649; Wed, 26 Feb 1997 04:41:18 -0500 (EST) Date: Wed, 26 Feb 1997 04:41:18 -0500 (EST) Sender:ietf-request@ietf.org From: GlobalIS@aol.com Message-ID: <970226044115_-1172476214@emout14.mail.aol.com> To: DOSLYNX-DEV@raven.cc.ukans.edu, HPV@sonoma.edu, IETF@CNRI.Reston.VA.US, POWDERWORKS@cs.colorado.edu Subject: NEW COMPUTER VIRUS ALERT!!!! Source-Info: From (or Sender) name not authenticated. WARNING!!!!!!! There are several new and highly dangerous internet-spread viruses that could cause hundreds, even thousands of dollars' worth of damage to your hardware and/or software. GIS (Global Information Services) has compiled all the latest data on these newest viruses, as well as the older ones. Learn how to protect yourself!!! For more information, reply with the word "information".   Received: from ietf.org by ietf.org id aa11187; 26 Feb 97 8:27 EST Received: from mersey.hursley.ibm.com by ietf.org id aa11059; 26 Feb 97 8:23 EST Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA64734; Wed, 26 Feb 1997 13:21:19 GMT Date: Wed, 26 Feb 1997 13:21:19 GMT Message-Id: <9702261321.AA64734@hursley.ibm.com> Sender:ietf-request@ietf.org From: "(Brian E Carpenter)" Subject: don't shoot the messenger To: ietf@ietf.org Reply-To: ietf@ietf.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 895 Source-Info: From (or Sender) name not authenticated. I hesitate to do this but for those of you that don't receive the ISOC electronic newsletter, the following snip may be of interest. "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS Cyber Promotions, Inc., best known for having been kicked off of as many as 20 different Internet Service Providers for sending unsolicited e- mail, has announced that it will become an Internet Service Provider itself. CPI plans to charge its customers $50 per month, enabling them to send unsolicited mass mailings -- referred to as spams -- as long as they allow users to remove themselves from such lists and comply with local, state, and federal laws. When asked why the company had not thought of this solution earlier, CPI president Sanford Wallace said that his company had been too busy with lawsuits. (Cowles/SIMBA Media Daily 20 Feb 1997)" Don't shoot the messenger :-) Brian Carpenter   Received: from ietf.org by ietf.org id aa11740; 26 Feb 97 8:35 EST Received: from AIC.NET by ietf.org id aa11555; 26 Feb 97 8:34 EST Received: by aic.net for ietf@ietf.org at Wed, 26 Feb 1997 16:31:40 +0300 (GMT) Message-Id: <199702261331.QAA17592@aic.net> Subject: Re: don't shoot the messenger To: ietf@ietf.org Date: Wed, 26 Feb 1997 16:31:39 +0300 (GMT) In-Reply-To: <9702261321.AA64734@hursley.ibm.com> from "ietf-request@ietf.org" at Feb 26, 97 01:21:19 pm Sender:ietf-request@ietf.org From: Edgar Danielian Content-Type: text Source-Info: From (or Sender) name not authenticated. > "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS > Cyber Promotions, Inc., best known for having been kicked off of as many > as 20 different Internet Service Providers for sending unsolicited e- > mail, has announced that it will become an Internet Service Provider > itself. CPI plans to charge its customers $50 per month, enabling them > to send unsolicited mass mailings -- referred to as spams -- as long as > they allow users to remove themselves from such lists and comply with > local, state, and federal laws. When asked why the company had not > thought of this solution earlier, CPI president Sanford Wallace said > that his company had been too busy with lawsuits. > (Cowles/SIMBA Media Daily 20 Feb 1997)" I'm sure they will be much more busy after becoming ISP... IMHO, -edd   Received: from ietf.org by ietf.org id aa12514; 26 Feb 97 8:50 EST Received: from popper.pbi.net by ietf.org id aa12392; 26 Feb 97 8:48 EST Received: from hobbes.eng.pbi.net by popper.PBI.net (4.1/PBI-12/1/95) id AA14244; Wed, 26 Feb 97 05:46:11 PST Date: Wed, 26 Feb 1997 05:46:11 -0800 (PST) Sender:ietf-request@ietf.org From: Christopher Nielsen X-Sender: cnielsen@hobbes.eng.pbi.net To: ietf@ietf.org Subject: Re: don't shoot the messenger In-Reply-To: <9702261321.AA64734@hursley.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Wed, 26 Feb 1997, (Brian E Carpenter) wrote: > "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS > Cyber Promotions, Inc., best known for having been kicked off of as many > as 20 different Internet Service Providers for sending unsolicited e- > mail, has announced that it will become an Internet Service Provider > itself. CPI plans to charge its customers $50 per month, enabling them > to send unsolicited mass mailings -- referred to as spams -- as long as > they allow users to remove themselves from such lists and comply with > local, state, and federal laws. When asked why the company had not > thought of this solution earlier, CPI president Sanford Wallace said > that his company had been too busy with lawsuits. > (Cowles/SIMBA Media Daily 20 Feb 1997)" Would it be legally feasible to deny peering agreements or upstream service to someone like this? They have to either get their upstream service from -someone- or have a peering agreement. I'd be interested to see who it is or if they can manage to get a peering agreement with anyone. On another note, those who attended the most recent NANOG meeting probably heard Paul Vixie's solution to spammers: blackhole routes. -- Christopher Nielsen Pacific Bell Internet Services Senior Systems Administrator and San Francisco, CA Security Officer cnielsen@pbi.net #include   Received: from ietf.org by ietf.org id aa13854; 26 Feb 97 9:08 EST Received: from cs.columbia.edu by ietf.org id aa13748; 26 Feb 97 9:06 EST Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA15033; Wed, 26 Feb 1997 09:04:02 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA11225; Wed, 26 Feb 1997 09:04:01 -0500 (EST) X-Orig-Sender: hgs@cs.columbia.edu Message-ID: <331442D1.10E1@cs.columbia.edu> Date: Wed, 26 Feb 1997 09:04:01 -0500 Sender:ietf-request@ietf.org From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Christopher Nielsen CC: ietf@ietf.org Subject: Re: don't shoot the messenger References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Christopher Nielsen wrote: > > On Wed, 26 Feb 1997, (Brian E Carpenter) wrote: > > > "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS > > Cyber Promotions, Inc., best known for having been kicked off of as many > > as 20 different Internet Service Providers for sending unsolicited e- > > mail, has announced that it will become an Internet Service Provider > > itself. CPI plans to charge its customers $50 per month, enabling them > > to send unsolicited mass mailings -- referred to as spams -- as long as > > they allow users to remove themselves from such lists and comply with > > local, state, and federal laws. When asked why the company had not > > thought of this solution earlier, CPI president Sanford Wallace said > > that his company had been too busy with lawsuits. > > (Cowles/SIMBA Media Daily 20 Feb 1997)" > > Would it be legally feasible to deny peering agreements or upstream > service to someone like this? They have to either get their upstream > service from -someone- or have a peering agreement. I'd be interested to > see who it is or if they can manage to get a peering agreement with > anyone. > > On another note, those who attended the most recent NANOG meeting probably > heard Paul Vixie's solution to spammers: blackhole routes. I'd say: get all the spammers to sign up with one spam-only provider, find out what IP range they got and add a capability to sendmail to block that range. Unlike, say, netcom, you don't have to worry about blocking the mail of innocent bystanders. > > -- > Christopher Nielsen Pacific Bell Internet Services > Senior Systems Administrator and San Francisco, CA > Security Officer > cnielsen@pbi.net #include -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs   Received: from ietf.org by ietf.org id aa15002; 26 Feb 97 9:23 EST Received: from ietf.ietf.org by ietf.org id aa14422; 26 Feb 97 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: tcplw@bsdi.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-tcplw-high-performance-00.txt Date: Wed, 26 Feb 1997 09:19:06 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702260919.aa14422@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Large Windows Working Group of the IETF. Title : TCP Extensions for High Performance Author(s) : V. Jacobson, R. Braden, D. Borman Filename : draft-ietf-tcplw-high-performance-00.txt Pages : 41 Date : 02/25/1997 This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC-1323, a Proposed Standard, with small clarifications and corrections. 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-tcplw-high-performance-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-tcplw-high-performance-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-tcplw-high-performance-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970226091302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcplw-high-performance-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcplw-high-performance-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970226091302.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14999; 26 Feb 97 9:23 EST Received: from ietf.ietf.org by ietf.org id aa14368; 26 Feb 97 9:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pam-html-fine-trans-00.txt Date: Wed, 26 Feb 1997 09:18:54 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702260918.aa14368@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fine-Grained Transclusion in the Hypertext Markup Language Author(s) : A. Pam Filename : draft-pam-html-fine-trans-00.txt Pages : 3 Date : 02/25/1997 The word "hypertext" was coined by Theodor Holm Nelson in his paper "A File Structure for the Complex, the Changing and the Indeterminate", presented at the ACM 20th national conference in 1965. One of the key concepts in Nelson's vision of hypertext is "transclusion" or virtual inclusion, which permits composite documents to be constructed by reference to the original components rather than by copying. The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. HTML currently permits the transclusion of various content types using tags which accept a "SRC" attribute, such as the , and tags, but does not provide a mechanism for transcluding textual content. This document proposes markup for text transclusions in HTML and explains its usage. 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-pam-html-fine-trans-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-pam-html-fine-trans-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pam-html-fine-trans-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970225113525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pam-html-fine-trans-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pam-html-fine-trans-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970225113525.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15004; 26 Feb 97 9:24 EST Received: from ietf.ietf.org by ietf.org id aa14331; 26 Feb 97 9:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-03.txt Date: Wed, 26 Feb 1997 09:18:45 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702260918.aa14331@ietf.org> --NextPart Note: This revision includes changes as a result of WG Last Call A Revised 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 resolution of ISAKMP with Oakley Author(s) : D. Harkins, D. Carrel Filename : draft-ietf-ipsec-isakmp-oakley-03.txt Pages : 32 Date : 02/25/1997 [MSST96] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). This document describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. 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-isakmp-oakley-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970225104523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970225104523.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16504; 26 Feb 97 9:40 EST Received: from ietf.ietf.org by ietf.org id aa14443; 26 Feb 97 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: roamops@tdmx.rutgers.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-roamops-dnsrr-00.txt Date: Wed, 26 Feb 1997 09:19:09 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702260919.aa14443@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Roaming Operations Working Group of the IETF. Title : The Roaming Relationship (RR) Record in the DNS Author(s) : B. Aboba Filename : draft-ietf-roamops-dnsrr-00.txt Pages : 15 Date : 02/25/1997 This document describes the use of the Roaming Relationship (RR) record in the DNS for the description of inter-domain business relationships, as required for enabling of roaming. In the absence of DNS security, RR records may be used for determining the existence of a business relationship between the local ISP and the user's home domain, as well as the location of an appropriate settlement agent. However, since the RR records are not secured, other methods (such as hierarchical authentication routing) must be used in order to validate the business relationship path. When DNS security is implemented, the business relationship path is authenticated via digital signatures, and as a result, additional services may be provided, such as non-repudiation of proxied authentications and signed receipts for accounting record transfers. 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-roamops-dnsrr-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-roamops-dnsrr-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970225140606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-roamops-dnsrr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-roamops-dnsrr-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970225140606.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16865; 26 Feb 97 9:44 EST Received: from bells.cs.ucl.ac.uk by ietf.org id aa16595; 26 Feb 97 9:42 EST Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Feb 1997 14:39:47 +0000 To: Henning Schulzrinne cc: Christopher Nielsen , ietf@ietf.org Subject: Re: don't shoot the messenger In-reply-to: Your message of "Wed, 26 Feb 1997 09:04:01 EST." <331442D1.10E1@cs.columbia.edu> Date: Wed, 26 Feb 1997 14:39:45 +0000 Message-ID: <2235.856967985@cs.ucl.ac.uk> Sender:ietf-request@ietf.org From: Jon Crowcroft Source-Info: From (or Sender) name not authenticated. >> On another note, those who attended the most recent NANOG meeting probably >> heard Paul Vixie's solution to spammers: blackhole routes. >I'd say: get all the spammers to sign up with one spam-only provider, >find out what IP range they got and add a capability to sendmail to >block that range. Unlike, say, netcom, you don't have to worry about >blocking the mail of innocent bystanders. why block them? mark their traffic as low precedence, AND bill them for it jon   Received: from ietf.org by ietf.org id aa23096; 26 Feb 97 11:18 EST Received: from core.IConNet.NET by ietf.org id aa22826; 26 Feb 97 11:14 EST Received: from localhost (brisco@localhost) by fs.IConNet.NET (8.8.5/8.8.5) with SMTP id LAA18133; Wed, 26 Feb 1997 11:12:10 -0500 (EST) Date: Wed, 26 Feb 1997 11:12:10 -0500 (EST) Sender:ietf-request@ietf.org From: "T.P.Brisco" To: Bill Flanigan cc: ietf@ietf.org, Roger WOJA Kermode Subject: Re: 38th IETF Meeting...Hotel Gripe In-Reply-To: <9701258569.AA856922921@ncr.disa.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Can someone post a handful of nearby hotels? The lady at registration wasn't much help .... Tom On Tue, 25 Feb 1997, Bill Flanigan wrote: > Hello Roger, > > Maybe you're lucky--well, sort of. > > After all, this is Memphis TN (not Memphis, Egypt or Mars) where > the going rates for hotels/motor inns/motels is in the $50-60 > range--AAA, e.g., lists about 25 (with three-diamond ratings) in that > price range including a number within brisk-walking distance of the > Peabody.   Received: from ietf.org by ietf.org id aa23640; 26 Feb 97 11:28 EST Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa23547; 26 Feb 97 11:26 EST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA16885; Wed, 26 Feb 97 11:23:35 EST Received: by dcl.MIT.EDU (5.x/4.7) id AA16627; Wed, 26 Feb 1997 11:23:25 -0500 Date: Wed, 26 Feb 1997 11:23:25 -0500 Message-Id: <9702261623.AA16627@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: "Theodore Y. Ts'o" To: Henning Schulzrinne Cc: Christopher Nielsen , ietf@ietf.org In-Reply-To: Henning Schulzrinne's message of Wed, 26 Feb 1997 09:04:01 -0500, <331442D1.10E1@cs.columbia.edu> Subject: Re: don't shoot the messenger Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. Date: Wed, 26 Feb 1997 09:04:01 -0500 From: Henning Schulzrinne I'd say: get all the spammers to sign up with one spam-only provider, find out what IP range they got and add a capability to sendmail to block that range. Unlike, say, netcom, you don't have to worry about blocking the mail of innocent bystanders. MIT has already put that feature (an access list for incoming IP addresses/subnets) in our sendmail hubs..... - Ted   Received: from ietf.org by ietf.org id aa23855; 26 Feb 97 11:29 EST Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa23665; 26 Feb 97 11:28 EST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA17616; Wed, 26 Feb 97 11:26:09 EST Received: by dcl.MIT.EDU (5.x/4.7) id AA16632; Wed, 26 Feb 1997 11:26:07 -0500 Date: Wed, 26 Feb 1997 11:26:07 -0500 Message-Id: <9702261626.AA16632@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: "Theodore Y. Ts'o" To: Bill Flanigan Cc: ietf@ietf.org, Roger WOJA Kermode , flanigab@ncr.disa.mil In-Reply-To: Bill Flanigan's message of Tue, 25 Feb 97 17:39:20 EST, <9701258569.AA856922921@ncr.disa.mil> Subject: Re: 38th IETF Meeting...Hotel Gripe Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. Date: Tue, 25 Feb 97 17:39:20 EST From: Bill Flanigan Naturally, this can't help, but make me a bit curious about who (if anyone) is seriously negotiating these rates, and what criteria (if any) are being used? IETF attendance is now so large that advance-booking guarantees to completely fill many hotels in an area (even a year in advance) is virtually riskless. This should put the IETF hotel-booking folks firmly in the driver's seat as far as getting the lowest possible room rate in the meeting hotel and others in the area. Actually, we have a similar problem to USENIX. The number of meeting and breakout rooms that we need is extremely small compared to the number of attendees we have (read: number of paying hotel rooms). Thus, the number of sites where we can meet are quite limited. This does make me wonder why there were so few rooms reserved at the IETF block rate, though. Unless the hotel was hoping that enough other people would pay the full rate after the IETF block was exhausted, instead of staying at the $50-$60 motel that's 1/4 mile away.... - Ted   Received: from ietf.org by ietf.org id aa24269; 26 Feb 97 11:35 EST Received: from black-ice.cc.vt.edu by ietf.org id aa24126; 26 Feb 97 11:34 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA32304; Wed, 26 Feb 1997 11:31:59 -0500 Message-Id: <199702261631.LAA32304@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: Neal McBurnett Cc: ietf@ietf.org, m.t.hamilton@lut.ac.uk, wright@lbl.gov Subject: Re: ids-dnsnames-02.txt: add list.domain.name for mail lists In-Reply-To: Your message of "Tue, 25 Feb 1997 16:58:42 PST." <9702260058.AA13799@lever.dr.lucent.com> Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <9702260058.AA13799@lever.dr.lucent.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_383835428P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 26 Feb 1997 11:31:58 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_383835428P Content-Type: text/plain; charset=us-ascii On Tue, 25 Feb 1997 16:58:42 PST, Neal McBurnett said: > The machines are frequently distinct from the "mail" machine > for a given organization because the operational characteristics > and requirements can be very different. > > I propose the alias "list" for the "mail list" service. > It is the most common generic name in the lists I subscribe to. > Are there common alternatives? Well.. actually, I suspect that in most cases, the machine name is either listserv.domain.xyz (for people running LSoft's software), or majordomo.domain.xyz, or listproc.domain.xyz (for those running the CREN list processor). I can't remember seeing a machine called list.domain.xyz, and I've been doing Listserv stuff since 1984 or so. Are you sure that your "the lists I subscribe to" isn't biased in some way (for instance, many of your lists are hosted in one domain, so that domain's preferences impact the names you see)? The command languages for these 3 products are sufficiently different that bundling them all under the same 'list' is probably a bad idea. -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_383835428P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMxRlfNQBOOoptg9JAQHCUwP/W7VtJ0FGgeZ3P/U0Ei7Dx7/KgWZ0sFb+ 1HMGcZa8UASOZJ6o3NegsAoFHkkJi5rqW574UpN9rJS7476s0wSSMeJg5M+MZYb7 z9/XlB5oMb8UIEEyqMkTaOYSJJBP10ztRsRo42SjGQgTXV3NLrPNo3pPoLnntCiE YM8CSrLt7aA= =SbSb -----END PGP MESSAGE----- --==_Exmh_383835428P--   Received: from ietf.org by ietf.org id aa25391; 26 Feb 97 11:50 EST Received: from mailgate22-hme0.a001.sprintmail.com by ietf.org id aa25289; 26 Feb 97 11:47 EST Received: by mailgate22 (SMI-8.6/SMI-SVR4) id IAA26897; Wed, 26 Feb 1997 08:45:19 -0800 Message-Id: <199702261645.IAA26897@mailgate22> Received: from sdn-ts-020mdrelrp13.dialsprint.net(206.133.13.48) by mailfep2-hme1 via smap (KC5.24) id Q_10.1.1.6/Q_27061_1_3314689a; Wed Feb 26 08:45:14 1997 Sender:ietf-request@ietf.org From: "Mark A. Mooney" To: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Remove Date: Wed, 26 Feb 1997 11:44:03 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1160 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Remove markmooney@sprintmail.com unsubscribe markmooney@sprintmail.com   Received: from ietf.org by ietf.org id aa27448; 26 Feb 97 12:21 EST Received: from buster.lbl.gov by ietf.org id aa27311; 26 Feb 97 12:18 EST Received: from [128.3.9.20] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 26 Feb 1997 09:15:28 -0800 X-Sender: wright@cnrmail.lbl.gov Message-Id: In-Reply-To: <199702261631.LAA32304@black-ice.cc.vt.edu> References: Your message of "Tue, 25 Feb 1997 16:58:42 PST." <9702260058.AA13799@lever.dr.lucent.com> <9702260058.AA13799@lever.dr.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Feb 1997 09:15:26 -0800 To: Valdis.Kletnieks@vt.edu, Neal McBurnett Sender:ietf-request@ietf.org From: Russ Wright Subject: Re: ids-dnsnames-02.txt: add list.domain.name for mail lists Cc: ietf@ietf.org, ids@merit.edu Source-Info: From (or Sender) name not authenticated. Thanks for the comments. If anyone else has suggestions perhaps we should discuss on the ids@merit.edu list rather than the general ietf list. To address this particular comment- I think Valdis is correct about avoiding one alias. Having said that it was made pretty clear to me that the IESG folks who reviewed this document don't want a long list of aliases in the document. Russ At 8:31 AM -0800 2/26/97, Valdis.Kletnieks@vt.edu wrote: >On Tue, 25 Feb 1997 16:58:42 PST, Neal McBurnett said: >> The machines are frequently distinct from the "mail" machine >> for a given organization because the operational characteristics >> and requirements can be very different. >> >> I propose the alias "list" for the "mail list" service. >> It is the most common generic name in the lists I subscribe to. >> Are there common alternatives? > >Well.. actually, I suspect that in most cases, the machine name is >either listserv.domain.xyz (for people running LSoft's software), >or majordomo.domain.xyz, or listproc.domain.xyz (for those running >the CREN list processor). I can't remember seeing a machine called >list.domain.xyz, and I've been doing Listserv stuff since 1984 or so. >Are you sure that your "the lists I subscribe to" isn't biased in some >way (for instance, many of your lists are hosted in one domain, so >that domain's preferences impact the names you see)? > >The command languages for these 3 products are sufficiently different >that bundling them all under the same 'list' is probably a bad idea. > > >-- > Valdis Kletnieks > Computer Systems Engineer > Virginia Tech   Received: from ietf.org by ietf.org id aa28200; 26 Feb 97 12:33 EST Received: from mail1.microsoft.com by ietf.org id aa28079; 26 Feb 97 12:30 EST Received: by mail1.microsoft.com with Internet Mail Service (5.0.1457.3) id ; Wed, 26 Feb 1997 09:27:27 -0800 Message-ID: <503A2A3C2932CF118D8800805FD44E1802BBD755@RED-68-MSG> Sender:ietf-request@ietf.org From: Eric Fleischman To: "'ietf@ietf.org'" Subject: RE: don't shoot the messenger Date: Wed, 26 Feb 1997 09:22:13 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Source-Info: From (or Sender) name not authenticated. I see that you have now completed your move. I have signed up for the next IETF. I am looking forward to seeing you. -----Original Message----- From: (Brian E Carpenter) [SMTP:brian@hursley.ibm.com] Sent: Wednesday, February 26, 1997 5:21 AM To: ietf@ietf.org Subject: don't shoot the messenger I hesitate to do this but for those of you that don't receive the ISOC electronic newsletter, the following snip may be of interest. "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS Cyber Promotions, Inc., best known for having been kicked off of as many as 20 different Internet Service Providers for sending unsolicited e- mail, has announced that it will become an Internet Service Provider itself. CPI plans to charge its customers $50 per month, enabling them to send unsolicited mass mailings -- referred to as spams -- as long as they allow users to remove themselves from such lists and comply with local, state, and federal laws. When asked why the company had not thought of this solution earlier, CPI president Sanford Wallace said that his company had been too busy with lawsuits. (Cowles/SIMBA Media Daily 20 Feb 1997)" Don't shoot the messenger :-) Brian Carpenter   Received: from ietf.org by ietf.org id aa29219; 26 Feb 97 12:48 EST Received: from hp.rz.uni-potsdam.de by ietf.org id aa29080; 26 Feb 97 12:45 EST Received: from rz.uni-potsdam.de (persius.rz.uni-potsdam.de) by hp.rz.uni-potsdam.de with ESMTP (1.37.109.10G/16.2) id AA240398742; Wed, 26 Feb 1997 18:39:02 +0100 Received: from jhartman.rz.uni-potsdam.de by rz.uni-potsdam.de (SMI-8.6/SMI-SVR4) id SAA17892; Wed, 26 Feb 1997 18:39:50 +0100 Message-Id: <330B51C9.66BD@pobox.com> Date: Wed, 19 Feb 1997 20:17:29 +0100 Sender:ietf-request@ietf.org From: Joerg Hartmann Reply-To: ecology@pobox.com Organization: Oekologie & Innovationen X-Sender: Joerg Hartmann (Unverified) X-Mailer: Mozilla 4.0b1 (Win95; I) Mime-Version: 1.0 To: ietf@ietf.org Subject: Re: New Ideas for a WWW standard (fwd) X-Priority: Normal References: <199702172128.NAA08323@server.livingston.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Source-Info: From (or Sender) name not authenticated. Would you please stop this talk about plattforms, prefered proprietary scripting/macro languages and so on?!!! This all does _not_ belong to IETF. -- Ecology & Innovations, mailto:ecology@pobox.com, http://pobox.com/~ecology/ Hebbelstrasse 9, D-14469 Potsdam, Germany Phone: +49-(0)331-27092-15 P.O. Box 600844, D-14408 Potsdam Fax/3: +49-(0)331-27092-17 CEO + MD IT/OS Mr. Joerg Hartmann, mailto:joerg.hartmann@pobox.com, http://pobox.com/~ecology/joerg.hartmann/   Received: from cnri by ietf.org id aa29636; 26 Feb 97 12:52 EST Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa17517; 26 Feb 97 12:52 EST Received: (from daemon@localhost) by external.BSDI.COM (8.8.5/8.8.2) id KAA29876 for telnet-ietf-list@bsdi.com; Wed, 26 Feb 1997 10:43:58 -0700 (MST) Received: from deis38.deis.unibo.it. (deis38.deis.unibo.it [137.204.57.38]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id KAA29851 for ; Wed, 26 Feb 1997 10:43:32 -0700 (MST) Received: by deis38.deis.unibo.it. (SMI-8.6/SMI-SVR4) id SAA06207; Wed, 26 Feb 1997 18:44:53 +0100 Date: Wed, 26 Feb 1997 18:44:53 +0100 From: Sebastien Boving Message-Id: <199702261744.SAA06207@deis38.deis.unibo.it.> To: telnet-ietf@bsdi.com Subject: long suboptions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: A0qSjvhHqFUikI85BtsM9g== Hi, I'm new on this list, and haven't seen any traffic since i'm following it. I hope i'm not the onlyone out here. I'm expanding the Oct 23, 1995 telnet source to make it work with SESAME authentication (encryption will follow). SESAME uses a GSS-API, for authentication the client sends a firts encrypted token, the server checks this and sends his own authentication information back. The problem is, the token leaves (as far as i can see with the debugging options) the client ok, but the server always refuses the security token, even if it shouldn't. The problem is that the token delivered to sesame_is() (called on receipt of a IS) is much smaller than the actually sent token by the client. The server also makes this clear by stating: td: recv suboption (terminated by TERMINAL TYPE 55, not IAC SE!) AUTHENTICATION IS SESAME CLIENT|MUTUAL AUTH 96 130 (...) Actually, the clients asks net_write to send a token of about 1500 bytes to the server. The server receives this, but at about the 510th (512th?) byte an IAC is inserted (at what point?), so it thinks the suboption is badly terminated! Still this IAC doesn't appear in str_data when the client is sending it! What is going wrong? Why is this byte inserted in the stream? TIA, and sorry if this is a stupid question... Sebastien Boving. (just another student)   Received: from ietf.org by ietf.org id aa00473; 26 Feb 97 13:08 EST Received: from iggy.iwsc.com by ietf.org id aa00335; 26 Feb 97 13:06 EST Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19]) by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP id AAA214; Wed, 26 Feb 1997 10:08:50 -0800 Message-ID: <3314797F.36C@metacomm.com> Date: Wed, 26 Feb 1997 09:57:19 -0800 Sender:ietf-request@ietf.org From: Branislav Meandzija Reply-To: bran@metacomm.com Organization: Meta Communications, Inc. X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: "Theodore Y. Ts'o" CC: Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org Subject: Re: don't shoot the messenger References: <9702261623.AA16627@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Theodore Y. Ts'o wrote: > > Date: Wed, 26 Feb 1997 09:04:01 -0500 > From: Henning Schulzrinne > > I'd say: get all the spammers to sign up with one spam-only provider, > find out what IP range they got and add a capability to sendmail to > block that range. Unlike, say, netcom, you don't have to worry about > blocking the mail of innocent bystanders. > > MIT has already put that feature (an access list for incoming IP > addresses/subnets) in our sendmail hubs..... > > - Ted To me this looks too much like censorship. I'll rather be my own censor. Branislav   Received: from ietf.org by ietf.org id aa01737; 26 Feb 97 13:26 EST Received: from aleve.media.mit.edu by ietf.org id aa01438; 26 Feb 97 13:24 EST Received: from ml.media.mit.edu (ml.media.mit.edu [18.85.13.107]) by media.mit.edu (8.7.5/ML961206) with SMTP id NAA31223 for ; Wed, 26 Feb 1997 13:21:42 -0500 (EST) Received: from bad-taste.media.mit.edu by ml.media.mit.edu; (5.65v3.2/1.1.8.2/12Apr96-0443PM) id AA08312; Wed, 26 Feb 1997 13:21:42 -0500 Date: Wed, 26 Feb 1997 13:21:37 -0500 (EST) Sender:ietf-request@ietf.org From: Roger WOJA Kermode To: ietf@ietf.org Subject: Re: 38th IETF Meeting...Hotel Gripe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. try these on your web browser...... ftp://ftp.ietf.org/ietf/0mtg-at-a-glance-97apr.txt http://www.fodors.com/ir.cgi?dest=Memphis@35&2=name you can find out where the hotels are relative to the meeting site using.... http://www.city.net/countries/united_states/tennessee/memphis/maps/ woja Roger Kermode Research Assistant woja@media.mit.edu tel : +1 617 253 0341 Entertainment & Information Systems Group fax : +1 617 258 6264 MIT Media Lab, 20 Ames St, RmE15-354, Cambridge, MA 02139 USA On Wed, 26 Feb 1997, T.P.Brisco wrote: > > > Can someone post a handful of nearby hotels? The lady > at registration wasn't much help .... > > Tom > > On Tue, 25 Feb 1997, Bill Flanigan wrote: > > Hello Roger, > > > > Maybe you're lucky--well, sort of. > > > > After all, this is Memphis TN (not Memphis, Egypt or Mars) where > > the going rates for hotels/motor inns/motels is in the $50-60 > > range--AAA, e.g., lists about 25 (with three-diamond ratings) in that > > price range including a number within brisk-walking distance of the > > Peabody. > > >   Received: from cnri by ietf.org id aa02882; 26 Feb 97 13:46 EST Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa19180; 26 Feb 97 13:46 EST Received: (from daemon@localhost) by external.BSDI.COM (8.8.5/8.8.2) id LAA03771 for telnet-ietf-list@bsdi.com; Wed, 26 Feb 1997 11:41:21 -0700 (MST) Received: from forge.BSDI.COM (dab@forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.8.5/8.8.2) with ESMTP id LAA03755; Wed, 26 Feb 1997 11:40:44 -0700 (MST) Received: (from dab@localhost) by forge.BSDI.COM (8.8.2/8.7.3) id LAA05265; Wed, 26 Feb 1997 11:40:43 -0700 (MST) Date: Wed, 26 Feb 1997 11:40:43 -0700 (MST) From: David Borman Message-Id: <199702261840.LAA05265@forge.BSDI.COM> To: seb@deis38.deis.unibo.it, telnet-ietf@bsdi.com Subject: Re: long suboptions Sebastien, > The problem is, the token leaves (as far as i can see with the debugging > options) the client ok, but the server always refuses the security token, > even if it shouldn't. The problem is that the token delivered to sesame_is() > (called on receipt of a IS) is much smaller than the actually sent token by > the client. > > The server also makes this clear by stating: > td: recv suboption (terminated by TERMINAL TYPE 55, not IAC SE!) AUTHENTICATION > IS SESAME CLIENT|MUTUAL AUTH 96 130 (...) > > Actually, the clients asks net_write to send a token of about 1500 bytes to > the server. The server receives this, but at about the 510th (512th?) byte > an IAC is inserted (at what point?), so it thinks the suboption is badly > terminated! > Still this IAC doesn't appear in str_data when the client is sending it! The telnet server accumulates the suboption into a static circular buffer, which is 512 bytes long. You say you are sending a token of 1500 bytes, so it is going to wrap that buffer almost 3 times... In telnetd/state.c: unsigned char subbuffer[512], *subpointer= subbuffer, *subend= subbuffer; For the quick fix, make the buffer bigger. -David Borman, dab@bsdi.com   Received: from ietf.org by ietf.org id aa04661; 26 Feb 97 14:07 EST Received: from cnri by ietf.org id aa04582; 26 Feb 97 14:06 EST Received: from po2.glue.umd.edu by CNRI.Reston.VA.US id aa19687; 26 Feb 97 14:06 EST Received: from z.glue.umd.edu (tle@z.glue.umd.edu [128.8.10.71]) by po2.glue.umd.edu (8.8.5/8.8.5) with ESMTP id NAA02927; Wed, 26 Feb 1997 13:55:53 -0500 (EST) Received: from localhost (tle@localhost) by z.glue.umd.edu (8.8.5/8.7.3) with SMTP id NAA17128; Wed, 26 Feb 1997 13:55:44 -0500 (EST) X-Authentication-Warning: z.glue.umd.edu: tle owned process doing -bs Date: Wed, 26 Feb 1997 13:55:43 -0500 (EST) Sender:ietf-request@ietf.org From: Thao Le X-Sender: tle@z.glue.umd.edu To: tccc@ieee.org cc: vacets-tech@vacets.org Subject: Call for Papers - Deadline for Submitting Abstracts/Summaries Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Dear friends The deadline for submitting abstracts/summaries for VTIC '97 will be the end of this week (March 31, 1997). We would like to invite you to submit your own summaries and urge your colleagues to do so. We look forward to hearing from you and meeting you at VTIC '97. Best regards, Thao Le ----------------------------- Vietnamese Association for Computing, Engineering Technology and Science (VACETS) http://www.saigon.com/~vacets vacets-adcom@vacets.org CALL FOR PAPERS 1997 VACETS Technical International Conference (VTIC-97) vtic-tech@vacets.org San Jose State University, San Jose, California July 17 - 19, 1997 The second VACETS Technical International Conference will be held on July 17 and 19, 1997 at San Jose State University, San Jose, California. The theme of this year conference is "Key Technologies for the Year 2000". We will focus on advances in 1997 pacing technologies that we believe will become key technologies in the year 2000. Instructions to Authors: Prospective authors are invited to submit research and overview papers in all engineering and computer, physical, medical and social sciences disciplines for presentation and/or posting during the conference. Original papers are solicited in, but are not limited to, the following areas: =========================================== (1) Biomedical and Bio-Chemistry Technology (2) Robotics and Controls Technology (3) Telecommunications Technology (4) Computer Systems and Applications (5) IC Design Technology (6) Biometric Systems (7) Energy and Environmental Technology (8) Speech, Signal, Video, Image Processing Applications (9) Material and Manufacturing Technologies (10) Other Sciences, Engineering and Technologies ============================================ Students are encouraged to submit their papers. Accepted papers will be printed in the conference proceedings under Student Paper Session. There will be three student paper awards to be presented at the conference. Since the format of the conference allows a number of special topics sessions or workshops to be held, proposals from participants willing to organize special sessions on relevant topics are also welcomed. The organizers will be responsible for inviting speakers to their special sessions. Schedule - Submission of proposal for special sessions must be received by December 15, 1996. - Submission of one page summary must be received by March 1, 1997. - Notification of acceptance by April 1, 1997. - Final manuscripts (photoready papers) are due on May 15, 1997. Summary Submission Submission of one page text summary by e-mail to vtic-tech@vacets.org is requested. Small black and white illustrations, in pcx format (MS Windows Paintbrush readable) can also be included in the file, provided it has been pkzipped and uuencoded. An alternative is to send two copies of the summary, with illustrations (but not the original illustrations themselves) to the Technical Program Chair: Dr. Tran Thong Micro Systems Engineering, Inc. 6024 SW Jean Rd Lake Oswego, OR 97035 Fax: 503 635-9610 1. The official language of the conference is English (both paper and presentation). Vietnamese language submission is encouraged but an English summary must be included. 2. Please indicate your preferences: oral or poster presentation. 3. The summary should include the name, address (both e-mail and postal) and phone/fax number of the author(s). 4. Also, to simplify the review process, please indicate the primary technical area covered by the paper, PLEASE INCLUDE THIS INFORMATION IN THE SUBJECT LINE OF YOUR E-MAIL, for example: "VTIC-97 paper in Robotics" All questions regarding the format of the paper or the acceptance status should be directed to the Technical Program Chair. Dr. Tran Thong Fax: 503 635-9610 E-Mail: trant@teleport.com Technical Paper Format Papers submitted will be reviewed by the Conference Proceedings editorial staff for publication suitability. Editorial changes may be made to meet technical proceedings publication standards. 1. Paper should be printed on both sides of 8.5 X 11 in (21.6 X 27.9 cm) white sheets. 2. Begin with the title of the paper, name(s) of author(s), e-mail address (if available), complete return address, telephone and fax number. 3. A 10 to 15 lines abstract in "italic" 4. Use Word Processor: Microsoft Word 6.0 (or earlier readable version or Word Perfect). Font: Arial 10. An alternative is to submit an Adobe Acrobat pdf file. 5. Leave 1 in (2..54 cm) margin for each side, top and bottom of the page. 6. Make one or two-column per page. 7. The paper length is limited to 8 pages. Indicate page number in blue pencil. 8. Submit a 3.5" diskette in MS Word format for text, graphs, tables, formulas, etc., and two hardcopies of the papers. 9. Mail the paper and diskette to the Technical Program Vice-Chair: Dr. Thuy Trong Le Supercomputer Group Fujitsu America, Inc. 3055 Orchard Drive San Jose, CA 95134-2022 USA email: thuy@fujitsu.com   Received: from cnri by ietf.org id aa04696; 26 Feb 97 14:07 EST Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa19732; 26 Feb 97 14:07 EST Received: (from daemon@localhost) by external.BSDI.COM (8.8.5/8.8.2) id MAA05271 for telnet-ietf-list@bsdi.com; Wed, 26 Feb 1997 12:02:36 -0700 (MST) Received: from deis38.deis.unibo.it. (deis38.deis.unibo.it [137.204.57.38]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id MAA05267; Wed, 26 Feb 1997 12:02:32 -0700 (MST) Received: by deis38.deis.unibo.it. (SMI-8.6/SMI-SVR4) id UAA06368; Wed, 26 Feb 1997 20:05:16 +0100 Date: Wed, 26 Feb 1997 20:05:16 +0100 From: Sebastien Boving Message-Id: <199702261905.UAA06368@deis38.deis.unibo.it.> To: dab@bsdi.com, telnet-ietf@bsdi.com Subject: Re: long suboptions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: 95ebp5TFIaWEIHBEP8IzsA== > The telnet server accumulates the suboption into a static circular buffer, > which is 512 bytes long. You say you are sending a token of 1500 bytes, so > it is going to wrap that buffer almost 3 times... In telnetd/state.c: > > unsigned char subbuffer[512], *subpointer= subbuffer, *subend= subbuffer; > > For the quick fix, make the buffer bigger. > > -David Borman, dab@bsdi.com > That was the problem, it now works! Thanks, Sebastien.   Received: from ietf.org by ietf.org id aa06465; 26 Feb 97 14:33 EST Received: from ietf.ietf.org by ietf.org id aa06055; 26 Feb 97 14:27 EST To: IETF-Announce: ; Subject: WG ACTION: The Internet and the millenium problem (2000) Date: Wed, 26 Feb 1997 14:27:50 -0500 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9702261427.aa06055@ietf.org> A new working group has been formed in the Operational Requirements Area of the IETF. For additional information, contact the Area Directors or the WG Chair. The Internet and the millenium problem (2000) --------------------------------------------- Chair(s): Erik Huizer Operational Requirements Area Director(s): Scott Bradner Michael O'Dell Deirdre Kostick Area Advisor Scott Bradner Mailing lists: General Discussion:2000@nic.surfnet.nl To Subscribe: listserv@nic.surfnet.nl In Body: subscribe 2000 in body Archive: Description of Working Group: The Millenium problem According to the trade press billions of dollars will be spend the upcoming three years on the year 2000 problem, also called the millenium problem (though the third millenium will only start in 2001). This problem consists of the fact that many software packages and some protocols use a two digit field for the year in a date field. Most of the problems seem to be in administrative and financial programs, some of which have been written in archaic languages like Cobol. A lot of organizations are now starting to make an inventory of which software and tools they use will suffer from the millenium problem. ....and the Internet With the increasing popularity of the Internet, more and more organizations start to use the Internet as a serious business tool. This means that most organizations will want to analyse the millenium problems due to the use of Internet protocols and popular Internet software. In the trade press the first articles suggest that the Internet will collapse at midnight the 31st of december 1999. To counter these suggestions (that are obviously wrong) and to avoid that all over the Internet people will redo the same inventory over and over again the WG is to make an inventory of all important Internet protocols and their most popular implementations with respect to the millenium problem. Only software and protocols directly related to the Internet will be considered. The inventory will be published as an informational RFC. The RFC will contain: o Description of the year 2000 problems and when they will occur o Summary of possible solutions and timelines for those solutions o Inventory of the year 2000 problem in the most popular Internet protocols and their most popular implementations o Suggested solutions to the problems noted in the inventory o A disclaimer that the RFC does not pretend to be complete and that the proposed solutions should be tested before being relied upon (this for the US readers). The WG will only meet once (in Memphis, April 1997), most of the work will be done via the mailinglist. Goals and Milestones: Feb 97 Begin collecting inventory. Sep 97 Submit Internet-Draft to IESG for publication as an Informational RFC.   Received: from ietf.org by ietf.org id aa06462; 26 Feb 97 14:33 EST Received: from ietf.ietf.org by ietf.org id aa06045; 26 Feb 97 14:27 EST To: IETF-Announce: ; Subject: WG ACTION: Secure Shell (secsh) Date: Wed, 26 Feb 1997 14:27:48 -0500 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9702261427.aa06045@ietf.org> A new working group has been formed in the Security Area of the IETF. For additional information, contact the Area Directors or the WG Chair. Secure Shell (secsh) -------------------- Chair(s): Perry Metzger Security Area Director(s): Jeffrey Schiller Mailing lists: General Discussion:ietf-ssh@clinet.fi To Subscribe: majordomo@clinet.fi In Body: subscribe ietf-ssh@clinet.fi in body Archive: Description of Working Group: The goal of the working group is to update and standardize the popular SSH protocol. SSH provides support for secure remote login, secure file transfer, and secure TCP/IP and X11 forwardings. It can automatically encrypt, authenticate, and compress transmitted data. The working group will attempt to assure that the SSH protocol o provides strong security against cryptanalysis and protocol attacks, o can work reasonably well without a global key management or certificate infrastructure, o can utilize existing certificate infrastructures (e.g., DNSSEC, SPKI, X.509) when available, o can be made easy to deploy and take into use, o requires minimum or no manual interaction from users, o is reasonably clean and simple to implement. The resulting protocol will operate over TCP/IP or other reliable but insecure transport. It is intended to be implemented at the application level. Goals and Milestones: Feb 97 Submit Internet-Draft on SSH-2.0 protocol Apr 97 Decide on Transport Layer protocol at Memphis IETF. Aug 97 Finalize upper level protocols at Munich IETF. Sep 97 Submit Internet-Drafts to IESG to consider for publication as RFCs. Dec 97 Meet at DC IETF meeting.   Received: from ietf.org by ietf.org id aa08275; 26 Feb 97 15:06 EST Received: from box.nl by ietf.org id aa08191; 26 Feb 97 15:04 EST Received: from cs-gj3-a7.hro.nl (cs-gj3-a7.hro.nl [145.24.129.139]) by box.nl (8.7.5/8.6.9) with SMTP id VAA15386; Wed, 26 Feb 1997 21:01:28 +0100 Date: Wed, 26 Feb 1997 21:01:28 +0100 Message-Id: <199702262001.VAA15386@box.nl> X-Sender: unit@box.nl X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ecology@pobox.com Sender:ietf-request@ietf.org From: michael_roetto Subject: Re: New Ideas for a WWW standard (fwd) Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 20:17 19-02-97 +0100, you wrote: >Would you please stop this talk about plattforms, prefered proprietary >scripting/macro languages and so on?!!! This all does _not_ belong to >IETF. > I realize that the topic does not per se belong to the IETF list. But if you had read the document referenced you would have discovered the reasons I posted to the IETF. Further, judging from the discussion that ensued, it seems that the topic struck the interest of many who subsribe to the list. Please see the original document as well as the comments at: http://www.box.nl/~unit/mike/prop.htm -michael_roetto > > :::::::::::::::::::::::::::::::::::: Internet Design Unit http://www.box.nl/~unit/idu Personal Page: http://www.box.nl/~unit/mike ::::::::::::::::::::::::::::::::::::   Received: from ietf.org by ietf.org id aa13226; 26 Feb 97 16:04 EST Received: from ietf.ietf.org by ietf.org id aa12642; 26 Feb 97 15:59 EST To: IETF-Announce: ; cc: cat-ietf@mit.edu Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: FTP Security Extensions to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 26 Feb 1997 15:59:25 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702261559.aa12642@ietf.org> The IESG has received a request from the Common Authentication Technology Working Group to consider "FTP Security Extensions" 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@ietf.org or ietf@ietf.org mailing lists by March 12, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from ietf.org by ietf.org id aa14782; 26 Feb 97 16:24 EST Received: from ietf.ietf.org by ietf.org id aa14605; 26 Feb 97 16:20 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: IMAP4 Referrals to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 26 Feb 1997 16:20:43 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702261620.aa14605@ietf.org> The IESG has received a request to consider IMAP4 Referrals as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 26, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from cnri by ietf.org id aa20552; 26 Feb 97 17:47 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27668; 26 Feb 97 17:47 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Wed, 26 Feb 1997 20:57:51 GMT Message-Id: <199702262057.PAA17090@gza-client1.cam.ov.com> X-Mailer: exmh version 1.6.9 8/22/96 To: cat-ietf@mit.edu Cc: linn@cam.ov.com Subject: Memphis agenda and discussion solicitation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Feb 1997 15:57:45 -0500 From: John Linn Precedence: bulk CAT-WG members: The level of discussion on the list has been relatively quiet lately, and we have one meeting slot assigned for the Memphis IETF. I'd like to invite all members to initiate and pursue discussions of WG-related topics, and would like at this time to solicit requests for agenda time in order that the slot may be used most effectively towards closure and advancement of active and pending documents. Thanks, regards, ... --jl   Received: from cnri by ietf.org id aa06457; 27 Feb 97 2:37 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03844; 27 Feb 97 2:37 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Thu, 27 Feb 1997 06:00:50 GMT Message-Id: <199702270600.BAB20132@ig.cs.utk.edu> To: ftp-wg@hops.ag.utk.edu Cc: cat-ietf@mit.edu Subject: [fwd] Last Call: FTP Security Extensions to Proposed Standard Date: Thu, 27 Feb 1997 01:00:38 -0500 From: Keith Moore Precedence: bulk FTP extensions WG people: The CAT WG has developed a proposal for security extensions for FTP, and asked IESG that it be considered for Proposed Standard. In accordance with the FTPEXT WG charter, which directs it to review and make recommendations on proposed security extensions to FTP, I hereby request that the FTPEXT review this document and make appropriate recommendations. Individuals may of course submit their own comments independent of the working group. Note: while the FTPEXT group may of course discuss this proposal on its mailing list, any recommendations (from either the working group or individuals) on this proposal should be sent to ietf@ietf.org or iesg@ietf.org before March 12. Keith Moore co-Director, Applications Area IESG ------- Forwarded Message To: IETF-Announce:; cc: cat-ietf@mit.edu Sender: ietf-announce-request@ietf.org From: The IESG Subject: Last Call: FTP Security Extensions to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 26 Feb 1997 15:59:25 -0500 Message-ID: <9702261559.aa12642@ietf.org> The IESG has received a request from the Common Authentication Technology Working Group to consider "FTP Security Extensions" 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@ietf.org or ietf@ietf.org mailing lists by March 12, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/ ------- End of Forwarded Message   Received: from ietf.org by ietf.org id aa09157; 27 Feb 97 5:36 EST Received: from ibmmail.com by ietf.org id aa08867; 27 Feb 97 5:26 EST Received: from uk.ibm.com by ibmmail.COM (IBM VM SMTP V2R3) with BSMTP id 3826; Thu, 27 Feb 97 05:23:56 EST Date: Thu, 27 Feb 1997 05:23:58 EST Sender:ietf-request@ietf.org From: pfh@uk.ibm.com To: cat-ietf@mit.edu, ftp-wg@hops.ag.utk.edu, ietf@ietf.org X-Sender-Info: Paul Ford-Hutchinson Classification: -- NONE -- MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: draft-ietf-cat-ftpsec-09.txt Message-ID: <9702270526.aa08867@ietf.org> Source-Info: From (or Sender) name not authenticated. Two comments - The length of time that PROT is valid for is not specified - is it per data connection; is it cleared with a new AUTH/USER/ ... ... (I guess the latter, but I don't think it can be an implementation decision) - Can PBSZ 0 please define a 'streaming' encryption mechanism (like TLS (SSL)). This allows us to use this draft to negotiate TLS (with AUTH and PROT) but then all the stuff about encapsulating the data channel isn't relevant, as that is done for you by TLS. So, if 'PBSZ 0' meant - O.K. then you can send a PROT, and the data stream will be encrypted for you (the ftp application) lower down, so it will appear to you as a 'normal' unencapsulated data connection. Cheers, Paul -.--.---.----.-----.----.---.--.--.---.----.-----.----.---.--.- Paul Ford-Hutchinson FORDHUP @ NHBVM9 (GBIBMLLL @ IBMMAIL) IGN EDI Products Development and Support. (pfh@uk.ibm.com) Warwick (OSU-1) +44 (0)1926 464836 : tie (7)66 4836   Received: from cnri by ietf.org id aa10884; 27 Feb 97 6:48 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07725; 27 Feb 97 6:48 EST Received: by pad-thai.cam.ov.com (8.8.5/) id ; Thu, 27 Feb 1997 10:24:54 GMT Message-Id: <9702271024.AA08280@MIT.EDU> Date: Thu, 27 Feb 1997 05:24:44 EST From: pfh@uk.ibm.com To: cat-ietf@mit.edu, ftp-wg@hops.ag.utk.edu, ietf@ietf.org X-Sender-Info: Paul Ford-Hutchinson Classification: -- NONE -- Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: draft-ietf-cat-ftpsec-09.txt Precedence: bulk Two comments - The length of time that PROT is valid for is not specified - is it per data connection; is it cleared with a new AUTH/USER/ ... ... (I guess the latter, but I don't think it can be an implementation decision) - Can PBSZ 0 please define a 'streaming' encryption mechanism (like TLS (SSL)). This allows us to use this draft to negotiate TLS (with AUTH and PROT) but then all the stuff about encapsulating the data channel isn't relevant, as that is done for you by TLS. So, if 'PBSZ 0' meant - O.K. then you can send a PROT, and the data stream will be encrypted for you (the ftp application) lower down, so it will appear to you as a 'normal' unencapsulated data connection. Cheers, Paul -.--.---.----.-----.----.---.--.--.---.----.-----.----.---.--.- Paul Ford-Hutchinson FORDHUP @ NHBVM9 (GBIBMLLL @ IBMMAIL) IGN EDI Products Development and Support. (pfh@uk.ibm.com) Warwick (OSU-1) +44 (0)1926 464836 : tie (7)66 4836   Received: from ietf.org by ietf.org id aa13732; 27 Feb 97 9:06 EST Received: from unlinfo.unl.edu by ietf.org id aa13568; 27 Feb 97 9:02 EST Received: from unlinfo2.unl.edu by unlinfo.unl.edu (4.1/SMI-4.1) id AA02935; Thu, 27 Feb 97 07:59:42 CST Received: by unlinfo2.unl.edu (4.1/SMI-4.1) id AA00614; Thu, 27 Feb 97 07:59:38 CST Date: Thu, 27 Feb 1997 07:59:37 -0600 (CST) Sender:ietf-request@ietf.org From: thomas keller Subject: Re: don't shoot the messenger To: Branislav Meandzija Cc: "Theodore Y. Ts'o" , Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org In-Reply-To: <3314797F.36C@metacomm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Wed, 26 Feb 1997, Branislav Meandzija wrote: > Theodore Y. Ts'o wrote: > > Date: Wed, 26 Feb 1997 09:04:01 -0500 > > From: Henning Schulzrinne > > I'd say: get all the spammers to sign up with one spam-only provider, > > find out what IP range they got and add a capability to sendmail to > > block that range. Unlike, say, netcom, you don't have to worry about > > blocking the mail of innocent bystanders. >>> MIT has already put that feature (an access list for incoming IP >>> addresses/subnets) in our sendmail hubs..... >>>> To me this looks too much like censorship. I'll rather be my own >>>> censor. Censorship? Hardly. Spamming of this nature imposes a large and expensive load on the hosts of every system on the spam list. Why do you think that those who are paying the costs should subsidize this unsavory and unethical practice?   Received: from ietf.org by ietf.org id aa14818; 27 Feb 97 9:32 EST Received: from hail.ncr.disa.mil by ietf.org id aa14751; 27 Feb 97 9:30 EST Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id JAA07136; Thu, 27 Feb 1997 09:26:24 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA857064429; Thu, 27 Feb 97 09:25:31 EST Date: Thu, 27 Feb 97 09:25:31 EST Sender:ietf-request@ietf.org From: Bill Flanigan Message-Id: <9701278570.AA857064429@ncr.disa.mil> To: "T.P.Brisco" Cc: ietf@ietf.org, woja@media.mit.edu, flanigab@ncr.disa.mil Subject: Re[2]: 38th IETF Meeting...Hotel Gripe Source-Info: From (or Sender) name not authenticated. Hello Tom, 1. Recommend you get the AAA Tour Book for Tennessee--it list and rates about forty in "Greater "Memphis." 2. List for downtown (all have 901 area code): a. Best Western (two diamonds) 948-9005; b. Comfort Inn (three) 526-0583; c. Days Inn (two) 527-4100; d. Holiday Inn (three) 527-7300; e. Another Holiday Inn (three) 525-5491; and f. Radison (three) 528-1800. 3. Rack rates for the above range from $50 to $109 before AAA (or other) discounts. Bill Flanigan ______________________________ Reply Separator _________________________________ Subject: Re: 38th IETF Meeting...Hotel Gripe Author: "T.P.Brisco" at smtp Date: 2/26/97 11:11 AM Can someone post a handful of nearby hotels? The lady at registration wasn't much help .... Tom On Tue, 25 Feb 1997, Bill Flanigan wrote: > Hello Roger, > > Maybe you're lucky--well, sort of. > > After all, this is Memphis TN (not Memphis, Egypt or Mars) where > the going rates for hotels/motor inns/motels is in the $50-60 > range--AAA, e.g., lists about 25 (with three-diamond ratings) in that > price range including a number within brisk-walking distance of the > Peabody.   Received: from ietf.org by ietf.org id aa15364; 27 Feb 97 9:42 EST Received: from hail.ncr.disa.mil by ietf.org id aa15280; 27 Feb 97 9:40 EST Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id JAA07432; Thu, 27 Feb 1997 09:36:39 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA857065038; Thu, 27 Feb 97 09:35:49 EST Date: Thu, 27 Feb 97 09:35:49 EST Sender:ietf-request@ietf.org From: Bill Flanigan Message-Id: <9701278570.AA857065038@ncr.disa.mil> To: "Theodore Y. Ts'o" Cc: ietf@ietf.org, woja@media.mit.edu, flanigab@ncr.disa.mil Subject: Re[2]: 38th IETF Meeting...Hotel Gripe Source-Info: From (or Sender) name not authenticated. Hello Ted, Here a few other things you might want to ponder: 1. When I've negotiated with "four star" downtown hotels (BTW, my team always includes a lawyer), the issue usually boils down to how many room will I guarantee for how many night at a specific rate to get the number of meeting rooms I need FOR FREE. 2. Let's assume that 2,000 IETFers pay to attend (and show up) at an average of $270 a head. This yields $540K. Let's also assume that the cost of the food and beverages is $5.00 per day per person for 4.5 days plus $20.00 per person for the cash-bar reception. This totals $85K. Net profit, therefore, is $540K less $85K or $455K. This represents a "surplus fee" of $228 paid by each attendee. Any idea where this money ends up? I have some. 3. Let's further assume that the lowest below-the-rack-rate that the Peaboy will go for (which I doubt is really the case) to make their profit target is ($119 +129)/2 + $119, or $124. If attendees pay a registration fee of $270 less $228 or $42, this allows them to effectively stay at the Peaboy for five nights at $74 per night ($124 less $228/5). Now the Peabody's rates suddenly become not so outrageous. Best regards, Bill Flanigan ______________________________ Reply Separator _________________________________ Subject: Re: 38th IETF Meeting...Hotel Gripe Author: "Theodore Y. Ts'o" at smtp Date: 2/26/97 11:26 AM Date: Tue, 25 Feb 97 17:39:20 EST From: Bill Flanigan Naturally, this can't help, but make me a bit curious about who (if anyone) is seriously negotiating these rates, and what criteria (if any) are being used? IETF attendance is now so large that advance-booking guarantees to completely fill many hotels in an area (even a year in advance) is virtually riskless. This should put the IETF hotel-booking folks firmly in the driver's seat as far as getting the lowest possible room rate in the meeting hotel and others in the area. Actually, we have a similar problem to USENIX. The number of meeting and breakout rooms that we need is extremely small compared to the number of attendees we have (read: number of paying hotel rooms). Thus, the number of sites where we can meet are quite limited. This does make me wonder why there were so few rooms reserved at the IETF block rate, though. Unless the hotel was hoping that enough other people would pay the full rate after the IETF block was exhausted, instead of staying at the $50-$60 motel that's 1/4 mile away.... - Ted   Received: from ietf.org by ietf.org id aa16542; 27 Feb 97 9:59 EST Received: from www.atr.net by ietf.org id aa16349; 27 Feb 97 9:57 EST Received: from www.atr.net (www.atr.net [206.232.44.253]) by warp.atr.net (NTMail 3.02.10) with ESMTP id wa000230 for ; Thu, 27 Feb 1997 12:00:20 +0000 Message-ID: <3315BDA4.6789@atr.net> Date: Thu, 27 Feb 1997 12:00:20 -0500 Sender:ietf-request@ietf.org From: Turner W Rentz III Reply-To: treyr@atr.net Organization: Advance Technology and research, Inc. X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: ietf@ietf.org Subject: A legal argument against SPAM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Info: Evaluation version at warp.atr.net Source-Info: From (or Sender) name not authenticated. My math teacher once told me "you've got to learn to talk like a lawyer." Here's an armchair law student's proof that spamming is against the law in the State of Oregon. 1. Unsolicited (marketing) telephone calls are against the law. 2. The wording of the law refers to these calls as 'communication by telephony' 3. Email accessed by modem is 'communication by telephony'. Therefore, unsolicited (marketing) email received over a modem is against the law. Spam is unsolicited email sent over a modem. Therefore, Spam is against the law. Q.E.D. A precedent can be set in this state, with others to follow. Telemarketing is not against the law everywhere, unfortunately :(   Received: from ietf.org by ietf.org id aa16966; 27 Feb 97 10:05 EST Received: from ietf.ietf.org by ietf.org id aa16205; 27 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-klyne-addressing-00.txt Date: Thu, 27 Feb 1997 09:56:00 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702270956.aa16205@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : E-mail addressing: the worst of all worlds? Author(s) : G. Klyne Filename : draft-klyne-addressing-00.txt Pages : 5 Date : 02/26/1997 This memo is a critique of Internet e-mail addressing, with particular reference to its suitability for use in a general purpose interpersonal communication medium as opposed to its present use largely within a restricted community. The critique focusses on the differences between e-mail addresses and other forms of addressing with which very many lay people are intimately familiar. This memo does not offer any solutions to the issues raised; rather it is hoped to provoke some debate on the matter. The author would be particularly interested in views from those whose natural language does not use the Roman (western) alphabet. 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-klyne-addressing-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-klyne-addressing-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-klyne-addressing-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970226093439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-klyne-addressing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-klyne-addressing-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970226093439.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16970; 27 Feb 97 10:05 EST Received: from ietf.ietf.org by ietf.org id aa16238; 27 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kwan-proxy-client-conf-00.txt Date: Thu, 27 Feb 1997 09:56:09 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702270956.aa16238@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Option for Proxy Client Configuration File Author(s) : S. Kwan Filename : draft-kwan-proxy-client-conf-00.txt Pages : 3 Date : 02/26/1997 Application-level gateways are used on networks to provide controlled access to the Internet. Clients in those networks must be configured with the name or address of available proxy servers, the list of local domain names, and other proxy client configuration information before they can access the Internet. The defacto method of proxy client configuration is the download of a script or configuration file named by a URL. This document describes a DHCP option in which to transmit this URL to a proxy client. 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-kwan-proxy-client-conf-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kwan-proxy-client-conf-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kwan-proxy-client-conf-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970226102558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kwan-proxy-client-conf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kwan-proxy-client-conf-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970226102558.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16974; 27 Feb 97 10:05 EST Received: from ietf.ietf.org by ietf.org id aa16279; 27 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rmonmib@cisco.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmonmib-hcrmon-00.txt Date: Thu, 27 Feb 1997 09:56:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702270956.aa16279@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Network Monitoring Working Group of the IETF. Title : Remote Network Monitoring Management Information Base for High Capacity and Switched Networks Author(s) : S. Waldbusser Filename : draft-ietf-rmonmib-hcrmon-00.txt Pages : 43 Date : 02/26/1997 This memo defines an experimental 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 remote network monitoring devices. 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-rmonmib-hcrmon-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rmonmib-hcrmon-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rmonmib-hcrmon-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970226174200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmonmib-hcrmon-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmonmib-hcrmon-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970226174200.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16969; 27 Feb 97 10:05 EST Received: from ietf.ietf.org by ietf.org id aa16254; 27 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-durand-gse+-00.txt Date: Thu, 27 Feb 1997 09:56:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702270956.aa16254@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GSE+ - An Alternate Addressing Architecture to GSE Author(s) : A. Durand Filename : draft-durand-gse+-00.txt Pages : 3 Date : 02/26/1997 This document present an alternative addressing architecture to the GSE proposal (draft-ipng-gseaddr-00.txt) of Mike O'Dell. The basic change is the introduction of a site identifier in the ESD. 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-durand-gse+-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-durand-gse+-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-durand-gse+-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970226105118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-durand-gse+-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-durand-gse+-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970226105118.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16971; 27 Feb 97 10:05 EST Received: from ietf.ietf.org by ietf.org id aa16222; 27 Feb 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-slein-www-dist-author-00.txt Date: Thu, 27 Feb 1997 09:56:04 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702270956.aa16222@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Distributed Authoring and Versioning on the World Wide Web Author(s) : J. Slein, F. Vitali, J. Whitehead, D. Durand Filename : draft-slein-www-dist-author-00.txt Pages : 17 Date : 02/26/1997 Current World Wide Web (WWW or Web) standards provide simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of the WWW have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve relationship management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. 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-slein-www-dist-author-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-slein-www-dist-author-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@ds.internic.net. In the body type: "FILE /internet-drafts/draft-slein-www-dist-author-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@ds.internic.net" Content-Type: text/plain Content-ID: <19970226104148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-slein-www-dist-author-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-slein-www-dist-author-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970226104148.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa25510; 27 Feb 97 11:21 EST Received: from mailhost.worldnet.att.net by ietf.org id aa25194; 27 Feb 97 11:17 EST Received: from LOCALNAME ([207.146.160.192]) by mtigwc02.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA2962 for ; Thu, 27 Feb 1997 16:14:43 +0000 X-Sender: PJJ.PC@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org Sender:ietf-request@ietf.org From: PJJ.PC@worldnet.att.net Subject: Remove us from the mailing list Date: Thu, 27 Feb 1997 16:14:43 +0000 Message-ID: <19970227161441.AAA2962@LOCALNAME> Source-Info: From (or Sender) name not authenticated. To whom it may concern, We are a law firm in Chicago. Somehow you have managed to get us on a mailing list for some organization we do not belong to. We are now receiving at least 20 messages a day with information nobody has any use for. Please remove us form this list as soon as you receive this message. If this is not the correct adress for which I can talk to about removing us form the list can you please refer me to it. Thank You Ms. SMH for PJJ.PC   Received: from ietf.org by ietf.org id aa00532; 27 Feb 97 12:55 EST Received: from icicle.winternet.com by ietf.org id aa00404; 27 Feb 97 12:51 EST Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id LAA19787 for ; Thu, 27 Feb 1997 11:49:17 -0600 (CST) Posted-Date: Thu, 27 Feb 1997 11:49:17 -0600 (CST) Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta) id xma019770; Thu, 27 Feb 97 11:48:59 -0600 Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id da000081 for ; Thu, 27 Feb 1997 11:57:22 +0000 Received: by localhost with Microsoft Mail id <01BC24A5.634B6320@localhost>; Thu, 27 Feb 1997 11:57:21 -0600 Message-ID: <01BC24A5.634B6320@localhost> Sender:ietf-request@ietf.org From: Jon Davis To: "ietf@ietf.org" Date: Thu, 27 Feb 1997 11:16:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Info: Evaluation version at www.interact-net.com Source-Info: From (or Sender) name not authenticated. Someone please remove me from this list Thanks   Received: from ietf.org by ietf.org id aa00879; 27 Feb 97 13:02 EST Received: from black-ice.gateway.com by ietf.org id aa00714; 27 Feb 97 13:00 EST Received: from localhost (abc@localhost) by station1.firehouse.net (8.8.4/Not quite) with SMTP id MAA01163 for ; Thu, 27 Feb 1997 12:57:31 -0500 (EST) Date: Thu, 27 Feb 1997 12:57:30 -0500 (EST) Sender:ietf-request@ietf.org From: Alan Clegg To: ietf@ietf.org Subject: Revelation caused by [Re: Remove us from the mailing list] In-Reply-To: <19970227161441.AAA2962@LOCALNAME> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Thu, 27 Feb 1997 PJJ.PC@worldnet.att.net wrote: > We are now >receiving at least 20 messages a day with information nobody has any use >for. Oddly enough, this boils right down to the problem at the heart of the Internet these days, does it not? -abc | The Internet is not for sissies. [paul@vix.com] | Alan Clegg |   Received: from ietf.org by ietf.org id aa00882; 27 Feb 97 13:02 EST Received: from iggy.iwsc.com by ietf.org id aa00760; 27 Feb 97 13:00 EST Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19]) by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP id AAA252; Thu, 27 Feb 1997 10:03:03 -0800 Message-ID: <3315C996.1186@metacomm.com> Date: Thu, 27 Feb 1997 09:51:18 -0800 Sender:ietf-request@ietf.org From: Branislav Meandzija Reply-To: bran@metacomm.com Organization: Meta Communications, Inc. X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: thomas keller CC: "Theodore Y. Ts'o" , Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org Subject: Re: don't shoot the messenger References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. thomas keller wrote: > > On Wed, 26 Feb 1997, Branislav Meandzija wrote: > > Theodore Y. Ts'o wrote: > > > Date: Wed, 26 Feb 1997 09:04:01 -0500 > > > From: Henning Schulzrinne > > > I'd say: get all the spammers to sign up with one spam-only provider, > > > find out what IP range they got and add a capability to sendmail to > > > block that range. Unlike, say, netcom, you don't have to worry about > > > blocking the mail of innocent bystanders. > >>> MIT has already put that feature (an access list for incoming IP > >>> addresses/subnets) in our sendmail hubs..... > >>>> To me this looks too much like censorship. I'll rather be my own > >>>> censor. > > Censorship? Hardly. Spamming of this nature imposes a large and > expensive load on the hosts of every system on the spam list. Why do you > think that those who are paying the costs should subsidize this unsavory > and unethical practice? They shouldn't but neither should anybody without the recipient's explicit permission cut the recipient off from a part of the wild, wild, west. For example, do all the people at MIT know that Theodore Y. is cutting them off from whoever the suspected (remember, in dubio pro rei, I belive) spammers are. Branislav   Received: from ietf.org by ietf.org id aa07617; 27 Feb 97 15:29 EST Received: from apprentice.qualcomm.com by ietf.org id aa07471; 27 Feb 97 15:24 EST Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA25654; Thu, 27 Feb 1997 12:22:32 -0800 (PST) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <3315BDA4.6789@atr.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Eudora [Macintosh version 3.1b23-3.97] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Thu, 27 Feb 1997 12:15:04 -0800 To: treyr@atr.net Sender:ietf-request@ietf.org From: "John W. Noerenberg" Subject: Re: A legal argument against SPAM Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 12:00 PM -0500 2/27/97, Turner W Rentz III wrote: >My math teacher once told me >"you've got to learn to talk like a lawyer." > > >Here's an armchair law student's proof that >spamming is against the law in the State of >Oregon. > So somebody in Oregon want to haul Cyber Promotions into court to see if this stands up? john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- She discovered, as many a living being had discovered, that rational decisions are far more easily made than carried out. -- Orson Scott Card, Speaker for the Dead, 1986 --------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa08347; 27 Feb 97 15:48 EST Received: from callandor.cybercash.com by ietf.org id aa08262; 27 Feb 97 15:46 EST Received: by callandor.cybercash.com; id PAA11988; Thu, 27 Feb 1997 15:34:18 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma011963; Thu, 27 Feb 97 15:33:52 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA14572; Thu, 27 Feb 97 15:39:37 EST Date: Thu, 27 Feb 1997 15:39:36 -0500 (EST) Sender:ietf-request@ietf.org From: "Donald E. Eastlake 3rd" To: ietf@ietf.org Subject: Re: Remove us from the mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Hi, Forging people's names on subscriptions to mailing lists is becoming a daily occurance. Spamming is becoming an hourly occurance. The IETF list needs stronger control than it apparently has. For example: at a minimum, only allow posting from people on the list (or on a separate list you maintain so people who post from multiple addresses don't have too much inconvenience) and no one should be added to the list unless at least an email loop confirmation occurs where you send mail asking for a confirmation of the subscritpion request and get back a postitive response from the subscription address. I'm not saying such measures will eliminate all problems, but I think they will help a lot. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html ---------- Forwarded message ---------- Date: Thu, 27 Feb 1997 16:14:43 +0000 From: PJJ.PC@worldnet.att.net To: ietf@ietf.org Subject: Remove us from the mailing list To whom it may concern, We are a law firm in Chicago. Somehow you have managed to get us on a mailing list for some organization we do not belong to. We are now receiving at least 20 messages a day with information nobody has any use for. Please remove us form this list as soon as you receive this message. If this is not the correct adress for which I can talk to about removing us form the list can you please refer me to it. Thank You Ms. SMH for PJJ.PC   Received: from ietf.org by ietf.org id aa08970; 27 Feb 97 15:58 EST Received: from lynx.europe.shiva.com by ietf.org id aa08693; 27 Feb 97 15:56 EST Received: from chryses.europe.shiva.com (chryses.europe.shiva.com [89.0.0.223]) by lynx.europe.shiva.com (8.8.5/8.8.5) with ESMTP id UAA13709; Thu, 27 Feb 1997 20:53:38 GMT Received: from black.europe.shiva.com (black.europe.shiva.com [134.191.8.140]) by chryses.europe.shiva.com (8.8.5/8.8.5) with SMTP id UAA09014; Thu, 27 Feb 1997 20:53:37 GMT Received: from localhost by black.europe.shiva.com (SMI-8.6/SMI-SVR4) id UAA11465; Thu, 27 Feb 1997 20:53:37 GMT Date: Thu, 27 Feb 1997 20:53:36 +0000 (GMT) Sender:ietf-request@ietf.org From: Malcolm Campbell To: "John W. Noerenberg" cc: treyr@atr.net, ietf@ietf.org Subject: Re: A legal argument against SPAM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Thu, 27 Feb 1997, John W. Noerenberg wrote: > So somebody in Oregon want to haul Cyber Promotions into court to see if > this stands up? I havent a clue about US law, being neither American, nor a lawyer - but someone sent me this as a suggested reply to junk mailers... ---- Under USC 47 Sec.227(b)(1)(C): "It shall be unlawful for any person within the United States to use any telephone facsimile machine, computer, or other device to send an unsolicited advertisement to a telephone facsimile machine" where a "telephone facsimile machine" is defined in Sec.227(a)(2)(B) as: "equipment which has the capacity to transcribe text or images (or both) from an electronic signal received over a regular telephone line onto paper." Note that under this definition, my e-mail account, modem, computer and printer constitute a fax machine. Under Sec.227(b)(3)(B): "A person or entity may, if otherwise permitted by the laws or rules of court of a State, bring in an appropriate court of that State - (A) an action based on a violation of this subsection or the regulations prescribed under this subsection to enjoin such violation, (B) an action to recover for actual monetary loss from such a violation, or to receive $500 in damages for each such violation, whichever is greater, or (C) both such actions. If the court finds that the defendant willfully or knowingly violated this subsection or the regulations prescribed under this subsection, the court may, in its discretion, increase the amount of the award to an amount equal to not more than 3 times the amount available under subparagraph (B) of this paragraph."   Received: from ietf.org by ietf.org id aa08969; 27 Feb 97 15:58 EST Received: from apprentice.qualcomm.com by ietf.org id aa08748; 27 Feb 97 15:56 EST Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA29998; Thu, 27 Feb 1997 12:53:45 -0800 (PST) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: References: <3314797F.36C@metacomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 3.1b23-3.97] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Thu, 27 Feb 1997 12:32:54 -0800 To: thomas keller Sender:ietf-request@ietf.org From: "John W. Noerenberg" Subject: Re: don't shoot the messenger Cc: Branislav Meandzija , "Theodore Y. Ts'o" , Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 7:59 AM -0600 2/27/97, thomas keller wrote: >On Wed, 26 Feb 1997, Branislav Meandzija wrote: >> Theodore Y. Ts'o wrote: >> > Date: Wed, 26 Feb 1997 09:04:01 -0500 >>>> MIT has already put that feature (an access list for incoming IP >>>> addresses/subnets) in our sendmail hubs..... >>>>> To me this looks too much like censorship. I'll rather be my own >>>>> censor. > > Censorship? Hardly. Spamming of this nature imposes a large and >expensive load on the hosts of every system on the spam list. Why do you >think that those who are paying the costs should subsidize this unsavory >and unethical practice? But, Tom, by what rule can you say this is unsavory and unethical? Where is the privileged position that enables you (or anyone else) to impose the judgement this is morally unjustified? I find the idea of a suit intriguing, because a judgement against Cyber Promotions would say their practice is socially unacceptable. But that's different than imposing a moral choice. Personally, I agree with Branislav. But... We don't do morals, and we don't do social conventions. We do technology here. What is the proof that spamming necessarily imposes a large and expensive load on the hosts involved? john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- She discovered, as many a living being had discovered, that rational decisions are far more easily made than carried out. -- Orson Scott Card, Speaker for the Dead, 1986 --------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa10550; 27 Feb 97 16:24 EST Received: from black-ice.cc.vt.edu by ietf.org id aa10320; 27 Feb 97 16:22 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id QAA29514; Thu, 27 Feb 1997 16:19:30 -0500 Message-Id: <199702272119.QAA29514@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: Malcolm Campbell Cc: "John W. Noerenberg" , treyr@atr.net, ietf@ietf.org Subject: Re: A legal argument against SPAM In-Reply-To: Your message of "Thu, 27 Feb 1997 20:53:36 GMT." Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-353772832P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 27 Feb 1997 16:19:29 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_-353772832P Content-Type: text/plain; charset=us-ascii On Thu, 27 Feb 1997 20:53:36 GMT, Malcolm Campbell said: > Note that under this definition, my e-mail account, modem, computer > and printer constitute a fax machine. Umm.. don't go there. Really. You're opening a can of worms. If you try to chase this on the grounds that e-mail is Fax, then you're going to have to *also* deal with some of the fax-specific things - isn't there a requirement that the originating site/phone number appear at the top/bottom of each page of the fax, etc? A better bet is to just live with the situation, and lobby your local Congresscreature (or equivalent for those outside the US) to get legislation passed that actually matches the technology, and the problems involved. This is far from easy to get right - in fact, the *Department of Justice* filed a brief *opposing* the original Exon amendment, because the way it re-defined electronic communication, it *removed* all enforcement ability of *current* legislation. -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_-353772832P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMxX6XtQBOOoptg9JAQF/+gP/eUFRHOpEwdvc2tHA5xyFw5hoF+R+97Pm djLcZwWqV1zIaRR5KFUW49ZJLrKwPGVR/D3qV5Ri4kG94pB0/L7dll1FEuymI2kJ l4fw/UllWFAdF+kE0vk+dNAkobp0K97442RpzZYeizjNxKODnNZc1hniFyBZPZEP 9q6HWFJd0Bk= =wZiw -----END PGP MESSAGE----- --==_Exmh_-353772832P--   Received: from ietf.org by ietf.org id aa10909; 27 Feb 97 16:31 EST Received: from gateway-gw.pictel.com by ietf.org id aa10792; 27 Feb 97 16:28 EST Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA06202; Thu, 27 Feb 97 16:25:55 EST Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA17810; Thu, 27 Feb 97 16:25:54 EST Received: by smtpnotes.pictel.com (4.1/SMI-4.1) id AA16551; Thu, 27 Feb 97 16:25:52 EST Message-Id: <9702272125.AA16551@smtpnotes.pictel.com> Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id F8869DB2EFDC46EC8525644B007564BC; Thu, 27 Feb 97 21:25:52 To: ietf Sender:ietf-request@ietf.org From: Bradley Stevenson/Engineering/PicTel Date: 27 Feb 97 16:22:49 EDT Subject: remove Mime-Version: 1.0 Content-Type: Text/Plain Source-Info: From (or Sender) name not authenticated. remove unsubscribe take me off this list   Received: from ietf.org by ietf.org id aa14707; 27 Feb 97 17:18 EST Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa14567; 27 Feb 97 17:16 EST Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA05432; Thu, 27 Feb 97 17:12:49 EST Received: by dcl.MIT.EDU (5.x/4.7) id AA18017; Thu, 27 Feb 1997 17:12:43 -0500 Date: Thu, 27 Feb 1997 17:12:43 -0500 Message-Id: <9702272212.AA18017@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: "Theodore Y. Ts'o" To: "John W. Noerenberg" Cc: thomas keller , Branislav Meandzija , "Theodore Y. Ts'o" , Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org In-Reply-To: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54 -0800, Subject: Re: don't shoot the messenger Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. Date: Thu, 27 Feb 1997 12:32:54 -0800 From: "John W. Noerenberg" What is the proof that spamming necessarily imposes a large and expensive load on the hosts involved? That's been our experience at MIT. We get the gamut between people sending SPAM to our users, which cause them to complain to postmaster, to people using MIT.EDU has a large-sclae SPAM reflector, to people sending e-mail bombs through MIT.EDU. Throughout all of this do not underestimate the amount of time it takes to handle user complaints which get sent to postmaster. It's those reasons in particular why we ultimately ended up implementing IP-level blocking. One can debate whether or not users actually want to receive the spam, but if the spam is endangering their ability to get fast reliable mail access, blocking it so that they can get their normal mail does seem to be what our users want. - Ted   Received: from ietf.org by ietf.org id aa15270; 27 Feb 97 17:24 EST Received: from [151.145.250.198] by ietf.org id aa15164; 27 Feb 97 17:22 EST Received: (from smap@localhost) by eagle.anheuser-busch.com (8.7.5/8.6.12) id QAA14882 for ; Thu, 27 Feb 1997 16:11:27 -0600 (CST) Received: from stlabcexg001.anheuser-busch.com(151.145.101.151) by eagle.anheuser-busch.com via smap (V1.3) id sma014876; Thu Feb 27 16:11:00 1997 Received: by stlabcexg001.anheuser-busch.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC24C9.EC2A8FD0@stlabcexg001.anheuser-busch.com>; Thu, 27 Feb 1997 16:18:52 -0600 Message-ID: Sender:ietf-request@ietf.org From: "Rabb, Daniel" To: "'ietf@ietf.org'" Subject: Do you want off this Mailing List ? (From www.ietf.org) Date: Thu, 27 Feb 1997 16:18:47 -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. To join the announcement list, send a request to: ietf-announce-request@ietf.org and enter the word subscribe in the Subject line of the message. The IETF discussion list is open, and therefore has a wide range of topics. However, be advised that employment opportunities and advertising fall well outside the range of acceptable topics. To join the IETF general discussion list, send a request to: ietf-request@ietf.org and enter the word subscribe in the Subject line of the message. An archive of mail sent to the IETF lists is available via anonymous FTP from the directory /ietf-mail-archive/ietf on ietf.org. To join most other Internet mailing lists, send a request to the associated ``-request'' address (e.g., to join the list@listhost list, send a message to list-request@listhost). Never send a subscription message to the list itself. General inquiries about the IETF should be sent to ietf-info@ietf.org . ------------- In other words.. to unsubscribe yourself from this list please send a message to ietf-request@ietf.org and enter the word unsubscribe in the Subject line of the message. PLEASE do not send requests to unsubsribe from this list, to the list itself. Thank you, Dan Rabb Communications and Network Services 314/865-9149 Daniel.Rabb@Anheuser-Busch.com   Received: from ietf.org by ietf.org id aa16073; 27 Feb 97 17:37 EST Received: from audio.ecn.purdue.edu by ietf.org id aa15861; 27 Feb 97 17:34 EST Received: from audio.ecn.purdue.edu (ali@localhost) by audio.ecn.purdue.edu (8.6.12/3.8davy) for delivery to "ietf@ietf.org" id RAA20885; Thu, 27 Feb 1997 17:32:02 -0500 Message-Id: <199702272232.RAA20885@audio.ecn.purdue.edu> Date: Thu, 27 Feb 1997 17:32:02 -0500 Sender:ietf-request@ietf.org From: Zafar Ali To: ietf@ietf.org Subject: remove Source-Info: From (or Sender) name not authenticated. remove unsubscribe   Received: from ietf.org by ietf.org id aa17967; 27 Feb 97 17:59 EST Received: from apprentice.qualcomm.com by ietf.org id aa17828; 27 Feb 97 17:57 EST Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA19783; Thu, 27 Feb 1997 14:51:59 -0800 (PST) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 3.1b23-3.97] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Thu, 27 Feb 1997 14:28:09 -0800 To: "Donald E. Eastlake 3rd" Sender:ietf-request@ietf.org From: "John W. Noerenberg" Subject: Re: Remove us from the mailing list Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote: > >The IETF list needs stronger control than it apparently has. For example: >at a minimum, only allow posting from people on the list (or on a separate >list you maintain so people who post from multiple addresses don't have too >much inconvenience) Just because a list is public and membership unrestricted, why should that imply posters cannot be anonymous? >and no one should be added to the list unless at least an >email loop confirmation occurs where you send mail asking for a confirmation >of the subscritpion request and get back a postitive response from the >subscription address. What policy would your propose for subscriber addresses that are themselves public lists with unrestricted membership? john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- She discovered, as many a living being had discovered, that rational decisions are far more easily made than carried out. -- Orson Scott Card, Speaker for the Dead, 1986 --------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa19686; 27 Feb 97 18:20 EST Received: from also.media.org by ietf.org id aa19609; 27 Feb 97 18:18 EST Received: (from carl@localhost) by also.media.org (8.8.5/8.8.4/961211bjb) id SAA24523; Thu, 27 Feb 1997 18:16:01 -0500 (EST) Sender:ietf-request@ietf.org From: "Carl Malamud [IMS]" Message-Id: <199702272316.SAA24523@also.media.org> Subject: Re: don't shoot the messenger To: "Theodore Y. Ts'o" Date: Thu, 27 Feb 1997 18:16:01 -0500 (EST) Cc: jwn2@qualcomm.com, tkeller@unlinfo2.unl.edu, bran@metacomm.com, tytso@mit.edu, schulzrinne@cs.columbia.edu, cnielsen@pbi.net, ietf@ietf.org In-Reply-To: <9702272212.AA18017@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Feb 27, 97 05:12:43 pm Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. I agree with Ted ... there is a very strong and very real cost to spamming and mailbombing. When Santa was mailbombed at north.pole.org, we had three people working for a a week doing nothing but handle the situation. Likewise with spamming, a problem we had with tpc.int where people decided they had to fax 500 copies of a notice to 500 members of congress. IP level blocking was the only serious way to handle these problems. DNS blocks in sendmail or inetd were partially effective, but we found folks that spend their time damaging the world also tend not to have very effective network implementations (e.g., their dns tables are inevitably screwed up). We weren't an ISP, merely a content provider, and I can tell you we felt the costs in no uncertain terms. Carl According to Theodore Y. Ts'o: > > Date: Thu, 27 Feb 1997 12:32:54 -0800 > From: "John W. Noerenberg" > > What is the proof that spamming necessarily imposes a large and expensive > load on the hosts involved? > > That's been our experience at MIT. We get the gamut between people > sending SPAM to our users, which cause them to complain to postmaster, > to people using MIT.EDU has a large-sclae SPAM reflector, to people > sending e-mail bombs through MIT.EDU. Throughout all of this do not > underestimate the amount of time it takes to handle user complaints > which get sent to postmaster. > > It's those reasons in particular why we ultimately ended up implementing > IP-level blocking. One can debate whether or not users actually want to > receive the spam, but if the spam is endangering their ability to get > fast reliable mail access, blocking it so that they can get their normal > mail does seem to be what our users want. > > - Ted >   Received: from ietf.org by ietf.org id aa19807; 27 Feb 97 18:21 EST Received: from callandor.cybercash.com by ietf.org id aa19716; 27 Feb 97 18:20 EST Received: by callandor.cybercash.com; id SAA20549; Thu, 27 Feb 1997 18:09:09 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma020541; Thu, 27 Feb 97 18:08:57 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA18833; Thu, 27 Feb 97 18:14:42 EST Date: Thu, 27 Feb 1997 18:14:41 -0500 (EST) Sender:ietf-request@ietf.org From: "Donald E. Eastlake 3rd" To: ietf@ietf.org Subject: Re: Remove us from the mailing list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Thu, 27 Feb 1997, John W. Noerenberg wrote: > Date: Thu, 27 Feb 1997 14:28:09 -0800 > From: John W. Noerenberg > > At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote: > > > >The IETF list needs stronger control than it apparently has. For example: > >at a minimum, only allow posting from people on the list (or on a separate > >list you maintain so people who post from multiple addresses don't have too > >much inconvenience) > > Just because a list is public and membership unrestricted, why should that > imply posters cannot be anonymous? And where did I say they couldn't be? I just indicated that they should have to go through an explicit email loop subscription cycle. As commonly happens, the abusers make life a bit more difficult for everyone else. > >and no one should be added to the list unless at least an > >email loop confirmation occurs where you send mail asking for a confirmation > >of the subscritpion request and get back a postitive response from the > >subscription address. > > What policy would your propose for subscriber addresses that are themselves > public lists with unrestricted membership? Such subscriptions have always been problematic due to bounces from sublist entries going back to the main list maintainer who knows nothing about them. I believe there are some early RFCs on this. The existence of any lists on the general Internet with no restirction or confirmation on subscriptions is an open inviation to abuse, abuse which is occuring with increasing frequency. There are a variety of possible solutions or partial solutions to the email abuse problems we are seeing. Doing nothing is not one of these. > john noerenberg > jwn2@qualcomm.com > -------------------------------------------------------------------- Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html   Received: from ietf.org by ietf.org id aa20198; 27 Feb 97 18:26 EST Received: from singapura.singnet.com.sg by ietf.org id aa19961; 27 Feb 97 18:25 EST Received: from localhost (mathias@localhost) by singapura.singnet.com.sg (8.8.5/8.7.2) with SMTP id HAA19275; Fri, 28 Feb 1997 07:22:23 +0800 (SST) Date: Fri, 28 Feb 1997 07:22:20 +0800 (SST) Sender:ietf-request@ietf.org From: Mathias Koerber X-Sender: mathias@singapura.singnet.com.sg Reply-To: mathias@staff.singnet.com.sg To: Zafar Ali cc: ietf@ietf.org Subject: Re: remove In-Reply-To: <199702272232.RAA20885@audio.ecn.purdue.edu> Message-ID: X-Disclaimer: I don't speak for anyone except for myself (and to myself sometimes) Organization: SingNet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Thu, 27 Feb 1997, Zafar Ali wrote: | Date: Thu, 27 Feb 1997 17:32:02 -0500 | From: Zafar Ali | To: ietf@ietf.org | Subject: remove | | remove | unsubscribe | Pls send requests like this to: ietf-REQUEST@ietf.org NOT the list itself. Thx Mathias Koerber | Tel: +65 / 471 9820 | mathias@staff.singnet.com.sg SingNet NOC | Fax: +65 / 475 3273 | mathias@koerber.org Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias@singnet.com.sg 2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65 S'pore 148943 | Disclaimer: I speak only for myself * Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *   Received: from ietf.org by ietf.org id aa22248; 27 Feb 97 18:56 EST Received: from apprentice.qualcomm.com by ietf.org id aa22141; 27 Feb 97 18:55 EST Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id PAA00671; Thu, 27 Feb 1997 15:51:59 -0800 (PST) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <9702272212.AA18017@dcl.MIT.EDU> References: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54 -0800, Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 3.1b23-3.97] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Thu, 27 Feb 1997 15:36:54 -0800 To: "Theodore Y. Ts'o" Sender:ietf-request@ietf.org From: "John W. Noerenberg" Subject: Re: don't shoot the messenger Cc: thomas keller , Branislav Meandzija , "Theodore Y. Ts'o" , Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 5:12 PM -0500 2/27/97, Theodore Y. Ts'o wrote: > Date: Thu, 27 Feb 1997 12:32:54 -0800 > From: "John W. Noerenberg" > > What is the proof that spamming necessarily imposes a large and expensive > load on the hosts involved? > >That's been our experience at MIT. We get the gamut between people >sending SPAM to our users, which cause them to complain to postmaster, >to people using MIT.EDU has a large-sclae SPAM reflector, to people >sending e-mail bombs through MIT.EDU. Throughout all of this do not >underestimate the amount of time it takes to handle user complaints >which get sent to postmaster. That's practical experience and very valuable. Is there some conclusion that can be drawn from the organization of store-and-forward nets that says dropping a large bolus of spam in the net necessarily causes congestion (or maybe indigestion is better here)? All the effects you cite are the result of network congestion. IETF should be seeking a methodological explanation for why spam is bad, or determine that none can be found presently. (This is an invitation for anyone working on this problem to publicize themselves.) Btw, don't anybody for one minute think I actually like those cretin spammers. john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- She discovered, as many a living being had discovered, that rational decisions are far more easily made than carried out. -- Orson Scott Card, Speaker for the Dead, 1986 --------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa26201; 27 Feb 97 19:32 EST Received: from icicle.winternet.com by ietf.org id aa26048; 27 Feb 97 19:30 EST Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id SAA08458 for ; Thu, 27 Feb 1997 18:27:56 -0600 (CST) Posted-Date: Thu, 27 Feb 1997 18:27:56 -0600 (CST) Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta) id xma008425; Thu, 27 Feb 97 18:27:31 -0600 Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id pa000093 for ; Thu, 27 Feb 1997 18:35:52 +0000 Received: by mackie.winternet.com with Microsoft Mail id <01BC24DD.0E199060@mackie.winternet.com>; Thu, 27 Feb 1997 18:35:50 -0600 Message-ID: <01BC24DD.0E199060@mackie.winternet.com> Sender:ietf-request@ietf.org From: Jon Davis To: "ietf@ietf.org" Subject: "REMOVE" function Date: Thu, 27 Feb 1997 18:35:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Info: Evaluation version at www.interact-net.com Source-Info: From (or Sender) name not authenticated. I'm quite surprised that an internet technology based mailing list = requires you to send "remove" requests to a separate e-mail address. = I'm just a loser internet junkie with Windows NT and "NT Mail" and I'm = spoiled on its ability to handle both actual messages and commands-if it = understands the body as a command, it will perform it. If it looks like = a command (1 or 2 words or whatever) but doesn't understand it, it = ignores it. If it's a long message, it broadcasts it. Considering there's about 1500 members on this list, it's a sad shame = that "remove" in the body won't work. =20 Perhaps we should be the first to develop an artificially intelligent = listserv server that can understand text like, "Please remove me from = this list." It would then send a confirmation request to the sender to = make sure removal is what he/she wants, or to broadcast it. Whatever. The listserv server being used now is obviously archaic. Jon Davis NewBreed Communications   Received: from ietf.org by ietf.org id aa26202; 27 Feb 97 19:32 EST Received: from cnri by ietf.org id aa26086; 27 Feb 97 19:30 EST Received: from Turing.Stanford.EDU by CNRI.Reston.VA.US id aa27107; 27 Feb 97 19:30 EST Received: from localhost (ole@localhost) by Turing.Stanford.EDU (8.8.5/8.8.3) with SMTP id QAA09678; Thu, 27 Feb 1997 16:26:45 -0800 (PST) X-Authentication-Warning: Turing.Stanford.EDU: ole owned process doing -bs Date: Thu, 27 Feb 1997 16:26:44 -0800 (PST) Sender:ietf-request@ietf.org From: "Ole J. Jacobsen" X-Sender: ole@Turing.Stanford.EDU To: ole@csli.stanford.edu Subject: BOFs at Interop Las Vegas Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. If you are interested in running a BOF at the next NetWorld+Interop in May in Las Vegas, send a message to ldraper@interop.com for more info. Ole ----------------------------------------------------------------- Ole J. Jacobsen, Senior Technical Advisor, Interop Company, Fax: Please don't, use e-mail instead. E-mail: ole@csli.stanford.edu, ole@world.std.com, ole@interop.com -----------------------------------------------------------------   Received: from ietf.org by ietf.org id aa26424; 27 Feb 97 19:35 EST Received: from iggy.iwsc.com by ietf.org id aa26323; 27 Feb 97 19:34 EST Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19]) by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP id AAA254; Thu, 27 Feb 1997 16:36:38 -0800 Message-ID: <331625D2.2160@metacomm.com> Date: Thu, 27 Feb 1997 16:24:50 -0800 Sender:ietf-request@ietf.org From: Branislav Meandzija Reply-To: bran@metacomm.com Organization: Meta Communications, Inc. X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: "John W. Noerenberg" CC: "Theodore Y. Ts'o" , thomas keller , Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org Subject: Re: don't shoot the messenger References: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54 -0800, Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. John W. Noerenberg wrote: > > At 5:12 PM -0500 2/27/97, Theodore Y. Ts'o wrote: > > Date: Thu, 27 Feb 1997 12:32:54 -0800 > > From: "John W. Noerenberg" > > > > What is the proof that spamming necessarily imposes a large and expensive > > load on the hosts involved? > > > >That's been our experience at MIT. We get the gamut between people > >sending SPAM to our users, which cause them to complain to postmaster, > >to people using MIT.EDU has a large-sclae SPAM reflector, to people > >sending e-mail bombs through MIT.EDU. Throughout all of this do not > >underestimate the amount of time it takes to handle user complaints > >which get sent to postmaster. > > That's practical experience and very valuable. Is there some conclusion > that can be drawn from the organization of store-and-forward nets that says > dropping a large bolus of spam in the net necessarily causes congestion (or > maybe indigestion is better here)? All the effects you cite are the result > of network congestion. IETF should be seeking a methodological explanation > for why spam is bad, or determine that none can be found presently. (This > is an invitation for anyone working on this problem to publicize > themselves.) > > Btw, don't anybody for one minute think I actually like those cretin spammers. > > john noerenberg > jwn2@qualcomm.com > -------------------------------------------------------------------- > She discovered, as many a living being had discovered, that > rational decisions are far more easily made than carried out. > -- Orson Scott Card, Speaker for the Dead, 1986 > -------------------------------------------------------------------- Perhaps what is needed is a mechanism for users to register with their network operators what classes of e-mail (as defined by the network operator or the IETF) they wish to receive. Those classes could allow the selection of the type of e-mail reflectors they wish to be under. That would solve many of the problems listed above while avoiding censorship. Branislav   Received: from ietf.org by ietf.org id aa28819; 27 Feb 97 20:05 EST Received: from mercury.Sun.COM by ietf.org id aa28576; 27 Feb 97 20:03 EST Received: from Holland.Sun.COM ([129.159.201.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA12801 for ; Thu, 27 Feb 1997 16:58:08 -0800 Received: from albano by Holland.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk200) id CAA21109; Fri, 28 Feb 1997 02:01:25 +0100 Received: from glorantha.Holland.Sun.COM by albano (SMI-8.6/SMI-SVR4-se.fkk201) id CAA28375; Fri, 28 Feb 1997 02:01:24 +0100 Received: by glorantha.Holland.Sun.COM (SMI-8.6/SMI-SVR4) id BAA08401; Fri, 28 Feb 1997 01:58:51 +0100 Message-Id: <199702280058.BAA08401@glorantha.Holland.Sun.COM> Subject: re: ietf mailing list policy To: ietf@ietf.org Date: Fri, 28 Feb 1997 01:58:51 +0100 (MET) Precedence: junk In-Reply-To: from "Donald E. Eastlake 3rd" at Feb 27, 97 03:39:36 pm Sender:ietf-request@ietf.org From: Henk.Langeveld@holland.sun.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Source-Info: From (or Sender) name not authenticated. Donald E. Eastlake suggests stronger control on the ietf list, and making it a closed "subscribers only" list. Consider bouncing all messages that do not have "Cc:/To: ietf@ietf.org" in the headers -- this would at least catch any occurrance of the ietf being subscribed to another list. Of course it would be naive to expect this to stop any deliberate spammers, but it will take out many of the obvious mistakes. Also, it should be a requirement for a mailing list to frequently post [a pointer to] the subscription guidelines -with a Reply-To: *-request@.... -- Henk Langeveld   Received: from ietf.org by ietf.org id aa02199; 27 Feb 97 20:50 EST Received: from ns.jck.com by ietf.org id aa02026; 27 Feb 97 20:47 EST Received: from tp.jck.com ("port 2935"@tp.jck.com) by a4.jck.com (PMDF V5.1-7 #16053) with SMTP id <0E6AI64V100LYR@a4.jck.com> for ietf@ietf.org; Thu, 27 Feb 1997 20:44:28 -0500 (EST) Date: Thu, 27 Feb 1997 20:19:49 -0500 Sender:ietf-request@ietf.org From: John C Klensin Subject: Re: don't shoot the messenger In-reply-to: <331625D2.2160@metacomm.com> X-Sender: klensin@alpha1.reston.mci.net To: bran@metacomm.com Cc: "John W. Noerenberg" , "Theodore Y. Ts'o" , thomas keller , Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org Message-id: <3.0.1.16.19970227201949.0aa768c0@alpha1.reston.mci.net> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0.1 (16) Content-type: text/plain; charset="us-ascii" References: Source-Info: From (or Sender) name not authenticated. At 16:24 97.02.27 -0800, Branislav Meandzija wrote: >Perhaps what is needed is a mechanism for users to register with their >network operators what classes of e-mail (as defined by the network >operator or the IETF) they wish to receive. Those classes could allow >the selection of the type of e-mail reflectors they wish to be under. >That would solve many of the problems listed above while avoiding >censorship. As long as you think the bulk mailers would observe the lists or correctly-label material being send out. In a world in which some of them have been accused of using "remove" replies to build new lists of people who are "guaranteed" to read and respond to email, this is not an obviously-safe assumption. john   Received: from ietf.org by ietf.org id aa03662; 27 Feb 97 21:08 EST Received: from iggy.iwsc.com by ietf.org id aa03440; 27 Feb 97 21:06 EST Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19]) by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP id AAA245; Thu, 27 Feb 1997 18:08:42 -0800 Message-ID: <33163B65.5B73@metacomm.com> Date: Thu, 27 Feb 1997 17:56:53 -0800 Sender:ietf-request@ietf.org From: Branislav Meandzija Reply-To: bran@metacomm.com Organization: Meta Communications, Inc. X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: John C Klensin CC: "John W. Noerenberg" , "Theodore Y. Ts'o" , thomas keller , Henning Schulzrinne , Christopher Nielsen , ietf@ietf.org Subject: Re: don't shoot the messenger References: <3.0.1.16.19970227201949.0aa768c0@alpha1.reston.mci.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. John C Klensin wrote: > > At 16:24 97.02.27 -0800, Branislav Meandzija wrote: > >Perhaps what is needed is a mechanism for users to register with their > >network operators what classes of e-mail (as defined by the network > >operator or the IETF) they wish to receive. Those classes could allow > >the selection of the type of e-mail reflectors they wish to be under. > >That would solve many of the problems listed above while avoiding > >censorship. > > As long as you think the bulk mailers would observe the lists or > correctly-label material being send out. In a world in which some of them > have been accused of using "remove" replies to build new lists of people > who are "guaranteed" to read and respond to email, this is not an > obviously-safe assumption. > > john That is not what I ment. In essence, you can do the same as now but add variations defining classes of defenses and allow those to be user selectable. Branislav   Received: from ietf.org by ietf.org id aa12884; 27 Feb 97 22:43 EST Received: from IG.CS.UTK.EDU by ietf.org id aa12497; 27 Feb 97 22:38 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id WAA24473; Thu, 27 Feb 1997 22:34:54 -0500 (EST) Message-Id: <199702280334.WAA24473@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Jon Davis cc: "ietf@ietf.org" , moore@cs.utk.edu Subject: Re: "REMOVE" function In-reply-to: Your message of "Thu, 27 Feb 1997 18:35:19 CST." <01BC24DD.0E199060@mackie.winternet.com> Date: Thu, 27 Feb 1997 22:34:54 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > I'm quite surprised that an internet technology based mailing list > requires you to send "remove" requests to a separate e-mail address. Even for lists that try to filter subscribe/unsubscribe requests from the list traffic (mine do), having separate addresses for list traffic and requests helps decrease the incidence of mis-handled mail. I've seen a lot of lists that were too "smart" - e.g. + incorrectly guessing that an ordinary message contained commands, attempting to process such commands, and sending replies back to the sender rather than forwarding the message to the list. + incorrectly guessing that a message sent to the list was the result of a mail loop and and silently dropping the message. + gratuitously deleting message headers that the list robot doesn't recognize + refusing to forward the message because the list robot has a conflicting notion of how to use the Precedence field, than the sender did. (the right answer: don't use it at al) + refusing to accept mail from moore@cs.utk.edu just because I happen to be subscribed as moore+folder@cs.utk.edu + gratuitously adding a reply-to field on all list traffic, effectively preventing replies to all recipients of the subject message + gratuitously replacing the sender-specified reply-to field with the list's reply-to field, thereby preventing someone from including third parties in a conversation with the list. + deliberately setting the SMTP MAIL FROM address (on messages redistributed to list members) to the address of the mailing list, (rather than the address of the list maintainer as per RFC 1123), then trying to distinguish nondelivery report messages from normal list traffic. Thus not only are some legitimate messages treated as nondelivery reports, some bounced messages aren't recognized and cause mail loops. + gratuitously munging the subject field to add the name of the list (thus making it harder to read the real subject of the message in a one-line-per-message summary of messages from that list) Which is not to say that I disagree with you -- it's a good idea to try to filter out things that are obviously subscribe/unsubscribe requests (say, the ones that fit majordomo or listserv syntax). And for all I know, this is already being done. But since this matching is necessarily based on heuristics, it's probably better to minimize the number of improperly blocked messages, even if that means that a few requests slip through to the list. But I have a lot more tolerance for the occasional subscribe/unsubscribe message sent to a list, than I have for any of the practices listed above. Keith   Received: from ietf.org by ietf.org id aa22267; 27 Feb 97 23:35 EST Received: from icicle.winternet.com by ietf.org id aa22166; 27 Feb 97 23:34 EST Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id WAA05632 for ; Thu, 27 Feb 1997 22:31:32 -0600 (CST) Posted-Date: Thu, 27 Feb 1997 22:31:32 -0600 (CST) Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta) id xma005618; Thu, 27 Feb 97 22:31:22 -0600 Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id sa000096 for ; Thu, 27 Feb 1997 22:39:52 +0000 Received: by localhost with Microsoft Mail id <01BC24FF.24E21CF0@localhost>; Thu, 27 Feb 1997 22:39:51 -0600 Message-ID: <01BC24FF.24E21CF0@localhost> Sender:ietf-request@ietf.org From: Jon Davis To: "ietf@ietf.org" Cc: "ietf@ietf.org" Subject: RE: "REMOVE" function Date: Thu, 27 Feb 1997 22:39:36 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Info: Evaluation version at www.interact-net.com Source-Info: From (or Sender) name not authenticated. Point taken, noted, proven, and known all along. You couldn't be more = right. However, in some cases-let's use mine as an example-all of a = sudden less than 24 hours ago I came home to find my e-mail box flooded = with e-mail. None of it was directed to me. I looked at all the e-mail = and didn't find a single e-mail explaining "WELCOME TO WHATEVER THE HELL = MAILING LIST THIS IS, AND ***THIS*** IS HOW TO REMOVE YOURSELF. = (Apparently, I had subscribed to the list a couple MONTHS ago, and = someone-rather than something-finally managed to get me signed up. I = never received a welcome e-mail that included explanation on removal = procedures.) =20 I was stumped. I had no way of knowing how to remove myself. So, I did = what I had to do-I e-mailed the list, asking for removal. Now I was = getting TWICE the e-mail, telling me not to post to the list, which I = had no clue I was subscribed to, and so frankly I really didn't care if = everyone got copies of my "removal" e-mail. One of those e-mails, = however, was a note from someone telling me that I'd been removed from = the list, but I'd still be getting occasional updates. Fine. WHY AM I = STILL ON THIS LIST? So, you see, something is wrong, something is terribly wrong, and I am = observing that there are at least two different gentlemen on this planet = on this list who are in my shoes right now. Now tell me, all you people who e-mailed me not to waste your e-mail = bandwidth with my complaints, now tell me that it wasn't worth it / = wasn't important enough to speak up on it. Jon Davis -----Original Message----- From: Keith Moore [SMTP:moore@cs.utk.edu] Sent: Thursday, February 27, 1997 9:35 PM To: Jon Davis Cc: ietf@ietf.org; moore@cs.utk.edu Subject: Re: "REMOVE" function=20 > I'm quite surprised that an internet technology based mailing list > requires you to send "remove" requests to a separate e-mail address.=20 Even for lists that try to filter subscribe/unsubscribe requests from the list traffic (mine do), having separate addresses for list traffic and requests helps decrease the incidence of mis-handled mail. =20 I've seen a lot of lists that were too "smart" - e.g.=20 + incorrectly guessing that an ordinary message contained commands, attempting to process such commands, and sending replies back to the sender rather than forwarding the message to the list.=20 + incorrectly guessing that a message sent to the list was the result of a mail loop and and silently dropping the message. + gratuitously deleting message headers that the list robot doesn't=20 recognize + refusing to forward the message because the list robot has a=20 conflicting notion of how to use the Precedence field, than the sender did. (the right answer: don't use it at al) + refusing to accept mail from moore@cs.utk.edu just because I happen to be subscribed as moore+folder@cs.utk.edu + gratuitously adding a reply-to field on all list traffic, effectively preventing replies to all recipients of the subject message + gratuitously replacing the sender-specified reply-to field with the list's reply-to field, thereby preventing someone from including=20 third parties in a conversation with the list. + deliberately setting the SMTP MAIL FROM address (on messages = redistributed to list members) to the address of the mailing list, (rather than the=20 address of the list maintainer as per RFC 1123), then trying to=20 distinguish nondelivery report messages from normal list traffic. Thus not only are some legitimate messages treated as nondelivery=20 reports, some bounced messages aren't recognized and cause mail loops. + gratuitously munging the subject field to add the name of the list (thus making it harder to read the real subject of the message in a one-line-per-message summary of messages from that list) Which is not to say that I disagree with you -- it's a good idea to try to filter out things that are obviously subscribe/unsubscribe = requests=20 (say, the ones that fit majordomo or listserv syntax). And for all I know, this is already being done. But since this matching is = necessarily based on heuristics, it's probably better to minimize the number of=20 improperly blocked messages, even if that means that a few requests slip through to the list. But I have a lot more tolerance for the occasional subscribe/unsubscribe = message sent to a list, than I have for any of the practices listed = above. Keith   Received: from ietf.org by ietf.org id aa22862; 27 Feb 97 23:41 EST Received: from icicle.winternet.com by ietf.org id aa22763; 27 Feb 97 23:40 EST Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id WAA06265 for ; Thu, 27 Feb 1997 22:37:36 -0600 (CST) Posted-Date: Thu, 27 Feb 1997 22:37:36 -0600 (CST) Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta) id xma006227; Thu, 27 Feb 97 22:37:14 -0600 Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id ta000097 for ; Thu, 27 Feb 1997 22:45:39 +0000 Received: by localhost with Microsoft Mail id <01BC24FF.F33A35B0@localhost>; Thu, 27 Feb 1997 22:45:37 -0600 Message-ID: <01BC24FF.F33A35B0@localhost> Sender:ietf-request@ietf.org From: Jon Davis To: "'ietf@ietf.org'" Subject: RE: "REMOVE" function Date: Thu, 27 Feb 1997 22:45:27 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Info: Evaluation version at www.interact-net.com Source-Info: From (or Sender) name not authenticated. Ahem... sorry, everybody. Temper control. Long day. Forgive me, it's = a neat list that I'd be happy to get involved in, but it kind of hit me = by surprise without warning and I wasn't prepared for all this e-mail. -----Original Message----- From: Jon Davis=20 Sent: Thursday, February 27, 1997 10:40 PM To: ietf@ietf.org Cc: ietf@ietf.org Subject: RE: "REMOVE" function=20 Point taken, noted, proven, and known all along. You couldn't be more = right. However, in some cases-let's use mine as an example-all of a = sudden less than 24 hours ago I came home to find my e-mail box flooded = with e-mail. None of it was directed to me. I looked at all the e-mail = and didn't find a single e-mail explaining "WELCOME TO WHATEVER THE HELL = MAILING LIST THIS IS, AND ***THIS*** IS HOW TO REMOVE YOURSELF. = (Apparently, I had subscribed to the list a couple MONTHS ago, and = someone-rather than something-finally managed to get me signed up. I = never received a welcome e-mail that included explanation on removal = procedures.) =20 I was stumped. I had no way of knowing how to remove myself. So, I did = what I had to do-I e-mailed the list, asking for removal. Now I was = getting TWICE the e-mail, telling me not to post to the list, which I = had no clue I was subscribed to, and so frankly I really didn't care if = everyone got copies of my "removal" e-mail. One of those e-mails, = however, was a note from someone telling me that I'd been removed from = the list, but I'd still be getting occasional updates. Fine. WHY AM I = STILL ON THIS LIST? So, you see, something is wrong, something is terribly wrong, and I am = observing that there are at least two different gentlemen on this planet = on this list who are in my shoes right now. Now tell me, all you people who e-mailed me not to waste your e-mail = bandwidth with my complaints, now tell me that it wasn't worth it / = wasn't important enough to speak up on it. Jon Davis -----Original Message----- From: Keith Moore [SMTP:moore@cs.utk.edu] Sent: Thursday, February 27, 1997 9:35 PM To: Jon Davis Cc: ietf@ietf.org; moore@cs.utk.edu Subject: Re: "REMOVE" function=20 > I'm quite surprised that an internet technology based mailing list > requires you to send "remove" requests to a separate e-mail address.=20 Even for lists that try to filter subscribe/unsubscribe requests from the list traffic (mine do), having separate addresses for list traffic and requests helps decrease the incidence of mis-handled mail. =20 I've seen a lot of lists that were too "smart" - e.g.=20 + incorrectly guessing that an ordinary message contained commands, attempting to process such commands, and sending replies back to the sender rather than forwarding the message to the list.=20 + incorrectly guessing that a message sent to the list was the result of a mail loop and and silently dropping the message. + gratuitously deleting message headers that the list robot doesn't=20 recognize + refusing to forward the message because the list robot has a=20 conflicting notion of how to use the Precedence field, than the sender did. (the right answer: don't use it at al) + refusing to accept mail from moore@cs.utk.edu just because I happen to be subscribed as moore+folder@cs.utk.edu + gratuitously adding a reply-to field on all list traffic, effectively preventing replies to all recipients of the subject message + gratuitously replacing the sender-specified reply-to field with the list's reply-to field, thereby preventing someone from including=20 third parties in a conversation with the list. + deliberately setting the SMTP MAIL FROM address (on messages = redistributed to list members) to the address of the mailing list, (rather than the=20 address of the list maintainer as per RFC 1123), then trying to=20 distinguish nondelivery report messages from normal list traffic. Thus not only are some legitimate messages treated as nondelivery=20 reports, some bounced messages aren't recognized and cause mail loops. + gratuitously munging the subject field to add the name of the list (thus making it harder to read the real subject of the message in a one-line-per-message summary of messages from that list) Which is not to say that I disagree with you -- it's a good idea to try to filter out things that are obviously subscribe/unsubscribe = requests=20 (say, the ones that fit majordomo or listserv syntax). And for all I know, this is already being done. But since this matching is = necessarily based on heuristics, it's probably better to minimize the number of=20 improperly blocked messages, even if that means that a few requests slip through to the list. But I have a lot more tolerance for the occasional subscribe/unsubscribe = message sent to a list, than I have for any of the practices listed = above. Keith   Received: from ietf.org by ietf.org id aa12969; 28 Feb 97 4:51 EST Received: from ecrc.de by ietf.org id aa12587; 28 Feb 97 4:46 EST Received: from primergy.atlantikgmbh.de (primergy.atlantikgmbh.de [194.221.55.201]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with SMTP id KAA01094 for ; Fri, 28 Feb 1997 10:43:38 +0100 (MET) Received: by primergy.atlantikgmbh.de with Microsoft Exchange (IMC 4.0.837.3) id <01BC2564.641B7690@primergy.atlantikgmbh.de>; Fri, 28 Feb 1997 10:44:36 +0100 Message-ID: Sender:ietf-request@ietf.org From: J}rgen Wegner To: "'ietf@ietf.org'" Subject: membership Date: Fri, 28 Feb 1997 10:44:34 +0100 Return-Receipt-To: X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 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 list J.Wegner jwegner@atlantikgmbh.de   Received: from ietf.org by ietf.org id aa26789; 28 Feb 97 8:06 EST Received: from relay.hq.tis.com by ietf.org id aa25880; 28 Feb 97 7:55 EST Received: by relay.hq.tis.com; id HAA09254; Fri, 28 Feb 1997 07:51:31 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2) id xma009243; Fri, 28 Feb 97 07:51:23 -0500 Received: from [10.33.112.20] (flapdoodle.hq.tis.com [10.33.112.20]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id HAA12983; Fri, 28 Feb 1997 07:49:00 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Feb 1997 07:35:52 -0500 To: "Donald E. Eastlake 3rd" Sender:ietf-request@ietf.org From: Edward Lewis Subject: Forging subscriptions - was Re: Remove us from the mailing list Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote: >Forging people's names on subscriptions to mailing lists is becoming a daily >occurance.... Just a thought, not to start a deep technical thread on the general list. Without being able to authenicate the subscription requestor (at this time), could a tape-and-glue fix be as simple as: when a request for subscription is received, a confirmation is requested (i.e., in a mail message to the subscribing address), and until a returned confirmation is received, the subscription is not made? I've heard that this approach is being used with at least one (non-IETF) mail list. A forger would have to be in the path of the forged address to see the confirmation message. To prevent predicatability of the confirmation a somewhat random phrase could be used in the confirmation request and reply. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com   Received: from ietf.org by ietf.org id aa29299; 28 Feb 97 8:33 EST Received: from ietf.ietf.org by ietf.org id aa29163; 28 Feb 97 8:30 EST To: ietf@ietf.org Subject: Re: "REMOVE" function Sender:ietf-request@ietf.org From: Dale R Worley Date: Fri, 28 Feb 1997 08:30:22 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702280830.aa29163@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <01BC24FF.24E21CF0@localhost> jon@interact-net.com (Jon Davis) writes: I was stumped. I had no way of knowing how to remove myself. Append "-request" to the name of the list and send a request for removal from that list, per Internet standards of about twenty years' duration. (Yes, if you're only used to Microsoft products, you won't know that, because Microsoft does everything differently. But you're in the Real World now, and have to learn how the Real World does things.) (This isn't a flame, it's just to point out that there are ways to know what you needed to know.) Dale   Received: from ietf.org by ietf.org id aa29620; 28 Feb 97 8:34 EST Received: from ietf.ietf.org by ietf.org id aa29500; 28 Feb 97 8:33 EST To: ietf@ietf.org Subject: RFC 1990 Sender:ietf-request@ietf.org From: Jon Davis Date: Fri, 28 Feb 1997 08:33:39 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9702280833.aa29500@ietf.org> Source-Info: From (or Sender) name not authenticated. Does anyone know where I can get an overview of RFC 1990 written in PLAIN ENGLISH? I realize it's a technical outline and should only expect it to be written in technical terms, but I was just wondering if anyone bothered to try to rephrase the article in a clearer presentation than at http://www.neda.com/rfc/rfc1990.txt Thanks, Jon Davis   Received: from ietf.org by ietf.org id aa04887; 28 Feb 97 9:23 EST Received: from noc.msc.edu by ietf.org id aa04486; 28 Feb 97 9:19 EST Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA22968; Fri, 28 Feb 97 08:16:29 -0600 Sender:ietf-request@ietf.org From: Tim Salo Received: (salo@localhost) by uh.msc.edu (8.7.1/8.6.6) id IAA01066 for ietf@ietf.org; Fri, 28 Feb 1997 08:16:29 -0600 (CST) Date: Fri, 28 Feb 1997 08:16:29 -0600 (CST) Message-Id: <199702281416.IAA01066@uh.msc.edu> To: ietf@ietf.org Subject: Re: "REMOVE" function Source-Info: From (or Sender) name not authenticated. > Subject: Re: "REMOVE" function > From: Dale R Worley > Date: Fri, 28 Feb 1997 08:30:22 -0500 > > In article <01BC24FF.24E21CF0@localhost> jon@interact-net.com (Jon Davis) > writes: > I was stumped. I had no way of knowing how to remove myself. > > Append "-request" to the name of the list and send a request for > removal from that list, per Internet standards of about twenty years' > duration. Per one of a number of inconsistent "standards." "The nice thing about standards is that there are so many to choose from" > (Yes, if you're only used to Microsoft products, you won't know that, > because Microsoft does everything differently. But you're in the Real > World now, and have to learn how the Real World does things.) > > (This isn't a flame, it's just to point out that there are ways to > know what you needed to know.) I suppose this _is_ intended as a flame, (of the lack of a _single_ standard in this area, not of you personally). -tjs   Received: from ietf.org by ietf.org id aa10671; 28 Feb 97 10:31 EST Received: from jekyll.piermont.com by ietf.org id aa10273; 28 Feb 97 10:26 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id KAA11728; Fri, 28 Feb 1997 10:22:18 -0500 (EST) Message-Id: <199702281522.KAA11728@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Jon Davis cc: ietf@ietf.org Subject: Re: RFC 1990 In-reply-to: Your message of "Fri, 28 Feb 1997 08:33:39 EST." <9702280833.aa29500@ietf.org> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 28 Feb 1997 10:22:17 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Jon Davis writes: > Does anyone know where I can get an overview of RFC 1990 written in PLAIN > ENGLISH? I realize it's a technical outline and should only expect it to > be written in technical terms, but I was just wondering if anyone bothered > to try to rephrase the article in a clearer presentation than at > http://www.neda.com/rfc/rfc1990.txt It seems pretty reasonable to read to me. If you are having trouble with it, maybe you should hire a consultant to help you doing your implementation. Perry   Received: from ietf.org by ietf.org id aa19960; 28 Feb 97 12:19 EST Received: from edu.lahti.fi by ietf.org id aa19506; 28 Feb 97 12:13 EST Received: (qmail 3585 invoked by uid 1067); 28 Feb 1997 17:14:13 -0000 Date: Fri, 28 Feb 1997 19:14:13 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni To: Edward Lewis cc: "Donald E. Eastlake 3rd" , ietf@ietf.org Subject: Re: Forging subscriptions - was Re: Remove us from the mailing list In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Fri, 28 Feb 1997, Edward Lewis wrote: > >Forging people's names on subscriptions to mailing lists is becoming a daily > >occurance.... > > Without being able to authenicate the subscription requestor (at this > time), could a tape-and-glue fix be as simple as: when a request for > subscription is received, a confirmation is requested (i.e., in a mail > message to the subscribing address), and until a returned confirmation is > received, the subscription is not made? A good idea. Only one problem needs to be fixed: the list should note pending confirmations and refuse to send more of them even if more subscriptions are received. Otherwise it would be easy to flood someone with confirmations. Of course, the confirmations would have to time out... Sampo Syreeni (Decoy/dAWN), student,   Received: from ietf.org by ietf.org id aa22983; 28 Feb 97 12:55 EST Received: from greatkhan.netmeg.net by ietf.org id aa22783; 28 Feb 97 12:51 EST Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1) id m0w0WPk-0001V4C; Fri, 28 Feb 97 12:48 EST Message-Id: Date: Fri, 28 Feb 97 12:48 EST Sender:ietf-request@ietf.org From: Matt Magri To: ietf@ietf.org Subject: Re: Remove us from the mailing list In-Reply-To: Source-Info: From (or Sender) name not authenticated. Donald E. Eastlake 3rd (dee@cybercash.com) wrote: > Forging people's names on subscriptions to mailing lists is becoming a daily > occurance. Spamming is becoming an hourly occurance. [ ... ] > much inconvenience) and no one should be added to the list unless at least an > email loop confirmation occurs where you send mail asking for a confirmation > of the subscritpion request and get back a postitive response from the > subscription address. There's no harm in setting something like that up. I've seen it used on other lists so it shouldn't require reinventing the wheel. Another thing to consider is poking the list software to add a line or two to the bottom of each post: ====================== IETF Mailing List ========================== To unsubscribe, e-mail ietf-request@ietf.org, subject "unsubscribe" I hate to cruft up each post with extra administrivia, but it's a pretty good fallback if someone gets on against their will. By making "IETF Mailing List" and "ietf-request" variables, they could use the same fix for all of their lists. Matt   Received: from ietf.org by ietf.org id aa24799; 28 Feb 97 13:15 EST Received: from greatkhan.netmeg.net by ietf.org id aa24479; 28 Feb 97 13:12 EST Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1) id m0w0Wk8-0001V4C; Fri, 28 Feb 97 13:09 EST Message-Id: Date: Fri, 28 Feb 97 13:09 EST Sender:ietf-request@ietf.org From: Matt Magri To: ietf@ietf.org Subject: Re: "REMOVE" function In-Reply-To: <199702281416.IAA01066@uh.msc.edu> Source-Info: From (or Sender) name not authenticated. Tim Salo (salo@msc.edu) wrote: > Dale R Worley (worley@world.std.com) wrote: > > In article <01BC24FF.24E21CF0@localhost> jon@interact-net.com (Jon Davis) > > writes: > > I was stumped. I had no way of knowing how to remove myself. > > > > Append "-request" to the name of the list and send a request for > > removal from that list, per Internet standards of about twenty years' > > duration. > > Per one of a number of inconsistent "standards." > > "The nice thing about standards is that there are so many > to choose from" Whatever. Lest it get lost in the noise, however, Dave was presenting information which is very valuable to someone new to the net. Inconsistent standards notwithstanding, it's *always* a good idea to try the -request trick before actually posting to the list address. Even if you don't get the command right you'll usually get something back either telling what the commands are or how you can find out what they are. And, until you can get off a list, you should be able to filter the unwanted mail out of your regular mailbox. Unix folks can check out the Mail Filtering FAQ (it's available in a number of places, including our mirror at http://www.netmeg.net/faq/internet/mail/filtering-faq/)... I'm sure there must be similar software for Windows platforms, etc. Matt   Received: from ietf.org by ietf.org id aa03364; 28 Feb 97 14:56 EST Received: from icicle.winternet.com by ietf.org id aa02877; 28 Feb 97 14:49 EST Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id NAA22053 for ; Fri, 28 Feb 1997 13:46:36 -0600 (CST) Posted-Date: Fri, 28 Feb 1997 13:46:36 -0600 (CST) Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta) id xma022034; Fri, 28 Feb 97 13:46:27 -0600 Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id da000107 for ; Fri, 28 Feb 1997 13:54:51 +0000 Received: by localhost with Microsoft Mail id <01BC257E.F7109F60@localhost>; Fri, 28 Feb 1997 13:54:50 -0600 Message-ID: <01BC257E.F7109F60@localhost> Sender:ietf-request@ietf.org From: Jon Davis To: "ietf@ietf.org" Subject: Re: RFC 1990 Date: Fri, 28 Feb 1997 13:50:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Info: Evaluation version at www.interact-net.com Source-Info: From (or Sender) name not authenticated. By the way, I do stand corrected. RFC 1990 is well-written, and I apologize, I must not have taken a very good look at it. Jon Davis   Received: from ietf.org by ietf.org id aa10964; 28 Feb 97 16:37 EST Received: from IG.CS.UTK.EDU by ietf.org id aa10550; 28 Feb 97 16:31 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA28082; Fri, 28 Feb 1997 16:29:03 -0500 (EST) Message-Id: <199702282129.QAA28082@ig.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Matt Magri cc: ietf@ietf.org, moore@cs.utk.edu Subject: Re: Remove us from the mailing list In-reply-to: Your message of "Fri, 28 Feb 1997 12:48:00 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Feb 1997 16:29:03 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > Another thing to consider is poking the list software to add a line or > two to the bottom of each post: > > ====================== IETF Mailing List ========================== > To unsubscribe, e-mail ietf-request@ietf.org, subject "unsubscribe" > Appending something to a message is not a good idea, especially with MIME mail...it amounts to corruption of the message. For what it's worth, an informal group is working on a draft for adding such information to the message header, in the form of mailto: URLs. So if your UA recognizes embedded URLs, you can simply click on the URL in the List-Unsubscribe header field to unsubscribe. Presumably, more UAs will be taught about this feature if it's standardized. I'm trying to get them to request a BOF for the Memphis IETF. Meanwhile, interested parties can subscribe to their list by clicking on the following URL :) (assuming your UA supports not only URLs but the newly-invented-but-not-yet-standardized extended mailto syntax) mailto:list-header@arpp.carleton.ca?Subject=subscribe%20list-header (Be forewarned: the list software they're using exhibits many of the kinds of brain-damage I mentioned in my recent flame...note for example the lack of a seperate -REQUEST address for requests...but they say some of the problems are being fixed.) -Keith   Received: from ietf.org by ietf.org id aa14345; 28 Feb 97 17:20 EST Received: from apprentice.qualcomm.com by ietf.org id aa14201; 28 Feb 97 17:17 EST Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA01205; Fri, 28 Feb 1997 14:10:48 -0800 (PST) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Eudora [Macintosh version 3.1b23-3.97] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Fri, 28 Feb 1997 14:01:22 -0800 To: "Donald E. Eastlake 3rd" Sender:ietf-request@ietf.org From: "John W. Noerenberg" Subject: Re: Remove us from the mailing list Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 6:14 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote: >On Thu, 27 Feb 1997, John W. Noerenberg wrote: > >> Date: Thu, 27 Feb 1997 14:28:09 -0800 >> From: John W. Noerenberg >> >> At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote: >> > >> >The IETF list needs stronger control than it apparently has. For exampl= e: >> >at a minimum, only allow posting from people on the list (or on a separa= te >> >list you maintain so people who post from multiple addresses don't have = too >> >much inconvenience) >> >> Just because a list is public and membership unrestricted, why should tha= t >> imply posters cannot be anonymous? > >And where did I say they couldn't be? I just indicated that they should ha= ve >to go through an explicit email loop subscription cycle. As commonly >happens, the abusers make life a bit more difficult for everyone else. You didn't, and I know, Donald, that you would not seek to prevent anonymity. But the consequence is unavoidable. Whatever identity is chosen is recorded and becomes a property of the list -- and publicly known. One could argue this identity is itself anonymous, but that is an infinite regress. At best, one could say this identity is a pseudonym. That's not the same as anonymity. If one is truly interested in preserving one's anonymity, it is necessary to minimize the amount of information about your identity that is revealed. Which means not giving any identity. If our goal is to permit the free, unrestricted dissemination of information, the requirement that information include some identity is inconsistent. After all, an identity on the net is only some set of information. You can't condition one set on a second and call the first unrestricted. > >The existence of any lists on the general Internet with no restirction or >confirmation on subscriptions is an open inviation to abuse, abuse which is >occuring with increasing frequency. There are a variety of possible >solutions or partial solutions to the email abuse problems we are >seeing. Doing nothing is not one of these. > I quite agree. best, john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- She discovered, as many a living being had discovered, that rational decisions are far more easily made than carried out. -- Orson Scott Card, Speaker for the Dead, 1986 --------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa16094; 28 Feb 97 17:40 EST Received: from greatkhan.netmeg.net by ietf.org id aa15822; 28 Feb 97 17:36 EST Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1) id m0w0ars-0001V4C; Fri, 28 Feb 97 17:33 EST Message-Id: Date: Fri, 28 Feb 97 17:33 EST Sender:ietf-request@ietf.org From: Matt Magri To: ietf@ietf.org Subject: Re: Remove us from the mailing list In-Reply-To: <199702282129.QAA28082@ig.cs.utk.edu> Source-Info: From (or Sender) name not authenticated. > > Another thing to consider is poking the list software to add a line or > > two to the bottom of each post: > > > > ====================== IETF Mailing List ========================== > > To unsubscribe, e-mail ietf-request@ietf.org, subject "unsubscribe" > > Appending something to a message is not a good idea, especially with > MIME mail...it amounts to corruption of the message. Hm, one might argue that someone posting MIME messages to a general mailing list should expect to have problems. At any rate, the insertion could be more sophisticated if there was some desire to make it friendly to MIME attachments. > For what it's worth, an informal group is working on a draft for > adding such information to the message header, in the form of mailto: > URLs. So if your UA recognizes embedded URLs, you can simply click on > the URL in the List-Unsubscribe header field to unsubscribe. Assuming they see it up in the headers when they're being bombarded by a bunch of messages from some strange source. Still, it sounds like a promising long-term solution. Matt   Received: from ietf.org by ietf.org id aa16441; 28 Feb 97 17:44 EST Received: from cnri by ietf.org id aa16371; 28 Feb 97 17:43 EST Received: from inet2.tek.com by CNRI.Reston.VA.US id aa21493; 28 Feb 97 17:43 EST Received: from icebox.vnd.tek.com by inet2.tek.com id ; Fri, 28 Feb 1997 14:41:19 -0800 Received: from icebox (localhost [127.0.0.1]) by icebox.vnd.tek.com (8.7.5/8.7.3) with ESMTP id OAA18735; Fri, 28 Feb 1997 14:48:33 -0800 (PST) Message-Id: <199702282248.OAA18735@icebox.vnd.tek.com> To: "voccnet.com" Cc: ietf@CNRI.Reston.VA.US Sender:ietf-request@ietf.org From: "Ted Brunner 503.627.1317" Subject: remove In-reply-to: Your message of Sun, 23 Feb 1997 05:08:17 -0800. <199702231308.FAA10781@georgia.sallynet.com> Date: Fri, 28 Feb 1997 14:48:33 -0800 X-Orig-Sender: tedb@vnd.tek.com Source-Info: From (or Sender) name not authenticated. Ted Brunner Video and Networking Division Tektronix MS 50-490 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005   Received: from ietf.org by ietf.org id aa17535; 28 Feb 97 17:55 EST Received: from apprentice.qualcomm.com by ietf.org id aa17310; 28 Feb 97 17:53 EST Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA06442; Fri, 28 Feb 1997 14:49:37 -0800 (PST) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <199702272316.SAA24523@also.media.org> References: <9702272212.AA18017@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Feb 27, 97 05:12:43 pm Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Eudora [Macintosh version 3.1b23-3.97] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Fri, 28 Feb 1997 14:23:29 -0800 To: "Carl Malamud [IMS]" Sender:ietf-request@ietf.org From: "John W. Noerenberg" Subject: Re: don't shoot the messenger Cc: "Theodore Y. Ts'o" , tkeller@unlinfo2.unl.edu, bran@metacomm.com, schulzrinne@cs.columbia.edu, cnielsen@pbi.net, ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 6:16 PM -0500 2/27/97, Carl Malamud [IMS] wrote: >I agree with Ted ... there is a very strong and very real cost >to spamming and mailbombing. When Santa was mailbombed at >north.pole.org, we had three people working for a a week >doing nothing but handle the situation. Likewise with spamming, >a problem we had with tpc.int where people decided they >had to fax 500 copies of a notice to 500 members of congress. > >IP level blocking was the only serious way to handle these >problems. DNS blocks in sendmail or inetd were partially >effective, but we found folks that spend their time damaging >the world also tend not to have very effective network >implementations (e.g., their dns tables are inevitably screwed >up). I'm not denying the costs. They are real, substantial, and the cause is truly onerous. But there can no doubt that appropriate use of the net is a social concern. Those of us who have grown up on the net are used to an environment free from the invasions of crass commercialism that characterizes the behavior of spammers, and the social ineptitude of those who would disrupt the net's operation in other ways. But there is no getting away from the fact that the population of the net is becoming more like the population of the world around us. Inasmuch as managing and directing human behavior is the province of social institutions that range from villages to nations, then social institutions must be the vehicle for sanctioning and disciplining behavior that is inappropriate. However, the net is a fundamentally different place. Never before has there existed a means of sweeping aside the constraints that mark the borders of every other human endeavor. The equivalent of villages or nations do not exist on the net. The barriers on which we rely to define interactions with other individuals and other communities do not exist. Many others, including you, Carl, have written eloquently on how the net has changed our perception of what human society can be and the individual's place in it. Yet here we are reporting techniques and debating the merits of methods that do create barriers and do limit the dissemination of information, information which many of us in this community find objectionable, no doubt. But building walls! Putting up fences!!! Is this truly what we seek? John Gilmore once said, "The Net treats censorship as damage and routes around it." The question about technical alternatives is not an idle one. john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- She discovered, as many a living being had discovered, that rational decisions are far more easily made than carried out. -- Orson Scott Card, Speaker for the Dead, 1986 --------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa17494; 28 Feb 97 17:55 EST Received: from ietf.ietf.org by ietf.org id aa15878; 28 Feb 97 17:37 EST To: IETF-Announce: ; Subject: Hotel Reservation Update Date: Fri, 28 Feb 1997 17:37:20 -0500 Sender:ietf-announce-request@ietf.org From: Marcia Beaulieu Message-ID: <9702281737.aa15878@ietf.org> 1. If you are on the waiting list at the Peabody Hotel, the hotel should call you when a room becomes available. Per the IETF contract, you are entitled to the IETF group rate ($119 single; $129 double) if a room is available at any time up to the start of the meeting. 2. As of this date, we have been informed that there are still rooms available at the alternate hotel: Holiday Inn Select 160 Union Avenue Memphis, TN 38103 Phone: 901-525-5491 (you must call the hotel directly) CI 1500; CO 1100 75 Rooms reserved until Monday, March 17, 1997 US$ 99.00/single; US$99.00/double (please add 13.25% tax) Specify: IETF or Internet Engineering Task Force One night's room and tax to be submitted at time of reservation. This deposit is refundable if the reservation is canceled by 5:00pm CST on the day prior to arrival. Deposit or guarantee may be in the form of check or credit card. 3. We recognize that the primary hotel room block has filled relatively quickly for the past several meetings. While we typically must negotiate the block size up to two years in advance, we are looking at ways to increase the size for the meetings following Memphis.   Received: from ietf.org by ietf.org id aa06028; 28 Feb 97 20:38 EST Received: from zephyr.isi.edu by ietf.org id aa05506; 28 Feb 97 20:31 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 28 Feb 1997 17:28:18 -0800 Message-Id: <199703010128.AA00785@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2113 on Router Alert Option Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 28 Feb 97 17:28:18 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2113: Title: IP Router Alert Option Author: D. Katz Date: February 1997 Mailbox: dkatz@cisco.com Pages: 4 Characters: 7924 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2113.txt This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path. 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@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@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@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@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@ds.internic.net" Content-Type: text/plain Content-ID: <970228172439.RFC@ISI.EDU> SEND /rfc/rfc2113.txt --OtherAccess Content-Type: Message/External-body; name="rfc2113.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970228172439.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13364; 28 Feb 97 22:01 EST Received: from shell1.aimnet.com by ietf.org id aa12858; 28 Feb 97 21:56 EST Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id SAA24121; Fri, 28 Feb 1997 18:54:01 -0800 (PST) Date: Fri, 28 Feb 1997 18:54:01 -0800 (PST) Sender:ietf-request@ietf.org From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: Matt Magri cc: ietf@ietf.org Subject: Re: Remove us from the mailing list In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Fri, 28 Feb 1997, Matt Magri wrote: > Assuming they see it up in the headers when they're being bombarded > by a bunch of messages from some strange source. Still, it sounds like > a promising long-term solution. And assuming that their UA even shows the header. The decent UAs I've seen don't by default blast that confusing junk on the screen. Dave Morris   Received: from ietf.org by ietf.org id aa19297; 2 Mar 97 14:05 EST Received: from Ostrogoth.gv-itf.unisource.nl by ietf.org id aa12978; 2 Mar 97 12:50 EST Received: from ostrogoth.gv-itf.unisource.nl (ostrogoth.gv-itf.unisource.nl [194.151.95.241]) by ostrogoth.gv-itf.unisource.nl (8.7.6/8.7.3) with SMTP id OAA00818; Fri, 28 Feb 1997 14:55:18 +0100 Date: Fri, 28 Feb 1997 14:55:18 +0100 (MET) Sender:ietf-request@ietf.org From: Frank de Lange X-Orig-Sender: frank@ostrogoth.gv-itf.unisource.nl Reply-To: Frank de Lange Subject: Re: Forging subscriptions - was Re: Remove us from the mailing list To: Edward Lewis cc: ietf@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Source-Info: From (or Sender) name not authenticated. > >Forging people's names on subscriptions to mailing lists is becoming a > >daily occurance.... > > Just a thought, not to start a deep technical thread on the general list. > > Without being able to authenicate the subscription requestor (at this > time), could a tape-and-glue fix be as simple as: when a request for > subscription is received, a confirmation is requested (i.e., in a mail > message to the subscribing address), and until a returned confirmation is > received, the subscription is not made? I've heard that this approach is > being used with at least one (non-IETF) mail list. > > A forger would have to be in the path of the forged address to see the > confirmation message. To prevent predicatability of the confirmation a > somewhat random phrase could be used in the confirmation request and reply. This does indeed work, a mechanism like this is in use at several sites (an example of which is ml.org (Monolith), which uses a three-way handshake to authenticate `subscribers' to their services (free DNS listings, but the same principle is valid in any other service). Frank WWWWW ___________________________ ## o o\ / Frank de Lange \ }# \| / +31-70-3712708 day \ ##---# _/ +31-320-252965 night \ #### \frank.de.lange@inet.unisource.nl/ \ frank.de.lange@net.info.nl / ------------------------------