[rfc-dist] RFC 3774 on IETF Problem Statement

[rfc-editor at rfc-editor.org ([e-mail])]

A new Request for Comments is now available in online RFC libraries.


        RFC 3774

        Title:      IETF Problem Statement
        Author(s):  E. Davies, Ed.
        Status:     Informational
        Date:       May 2004
        Mailbox:    [e-mail]
        Pages:      22
        Characters: 55172
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-problem-issue-statement-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3774.txt


This memo summarizes perceived problems in the structure, function,
and processes of the Internet Engineering Task Force (IETF).  We are
attempting to identify these problems, so that they can be addressed
and corrected by the IETF community.

The problems have been digested and categorized from an extensive
discussion which took place on the \'problem-statement' mailing list
from November 2002 to September 2003.  The problem list has been
further analyzed in an attempt to determine the root causes at
the heart of the perceived problems: The result will be used to guide
the next stage of the process in the Problem Statement working group
which is to recommend the structures and processes that will carry
out the corrections.

This document is a product of the Problem Statement Working Group of
the IETF.

This memo provides information for the Internet community.  It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri May  7 15:34:51 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri May  7 15:35:53 2004
Subject: [rfc-dist] RFC 3744 on Web Distributed Authoring and Versioning
	(WebDAV) Access Control Protocol
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3744

        Title:      Web Distributed Authoring and Versioning (WebDAV)
                    Access Control Protocol
        Author(s):  G. Clemm, J. Reschke, E. Sedlar, J. Whitehead
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail],
                    [e-mail],
                    [e-mail], [e-mail]
        Pages:      72
        Characters: 146623
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-webdav-acl-13.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3744.txt


This document specifies a set of methods, headers, message bodies,
properties, and reports that define Access Control extensions to the
WebDAV Distributed Authoring Protocol.  This protocol permits a client
to read and modify access control lists that instruct a server
whether to allow or deny operations upon a resource (such as
HyperText Transfer Protocol (HTTP) method invocations) by a given
principal.  A lightweight representation of principals as Web
resources supports integration of a wide range of user management
repositories.  Search operations allow discovery and manipulation of
principals using human names.

This document is a product of the WWW Distributed Authoring and
Versioning 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed May 12 17:25:06 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed May 12 17:25:46 2004
Subject: [rfc-dist] RFC 3756 on IPv6 Neighbor Discovery (ND) Trust Models
	and Threats
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3756

        Title:      IPv6 Neighbor Discovery (ND) Trust Models and
                    Threats
        Author(s):  P. Nikander, Ed., J. Kempf, E. Nordmark
        Status:     Informational
        Date:       May 2004
        Mailbox:    [e-mail],
                    [e-mail], [e-mail]
        Pages:      23
        Characters: 56674
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-send-psreq-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3756.txt


The existing IETF standards specify that IPv6 Neighbor Discovery (ND)
and Address Autoconfiguration mechanisms may be protected with IPsec
Authentication Header (AH).  However, the current specifications limit
the security solutions to manual keying due to practical problems
faced with automatic key management.  This document specifies three
different trust models and discusses the threats pertinent to IPv6
Neighbor Discovery.  The purpose of this discussion is to define the
requirements for Securing IPv6 Neighbor Discovery.

This document is a product of the Securing Neighbor Discovery Working
Group of the IETF.

This memo provides information for the Internet community.  It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Thu May 13 16:39:27 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Thu May 13 16:41:04 2004
Subject: [rfc-dist] RFC 3798 on Message Disposition Notification
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3798

        Title:      Message Disposition Notification
        Author(s):  T. Hansen, Ed., G. Vaudreuil, Ed.
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      30
        Characters: 64049
        Updates:    3461, 2046
        Obsoletes:  2298

        I-D Tag:    draft-vaudreuil-mdnbis-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3798.txt


This memo defines a MIME content-type that may be used by a mail user
agent (MUA) or electronic mail gateway to report the disposition of a
message after it has been successfully delivered to a recipient.  This
content-type is intended to be machine-processable.  Additional
message headers are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message.  The
purpose is to extend Internet Mail to support functionality often
found in other messaging systems, such as X.400 and the proprietary
"LAN-based" systems, and often referred to as "read receipts,"
"acknowledgements", or "receipt notifications."  The intention is to
do this while respecting privacy concerns, which have often been
expressed when such functions have been discussed in the past.

Because many messages are sent between the Internet and other
messaging systems (such as X.400 or the proprietary "LAN-based"
systems), the MDN protocol is designed to be useful in a
multi-protocol messaging environment.  To this end, the protocol
described in this memo provides for the carriage of "foreign"
addresses, in addition to those normally used in Internet Mail.
Additional attributes may also be defined to support "tunneling" of
foreign notifications through Internet Mail.

This is now a Draft 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri May 14 16:45:26 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri May 14 16:46:52 2004
Subject: [rfc-dist] RFC 3780 on SMIng - Next Generation Structure of
	Management Information
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3780

        Title:      SMIng - Next Generation Structure of Management
                    Information
        Author(s):  F. Strauss, J. Schoenwaelder
        Status:     Experimental
        Date:       May 2004
        Mailbox:    [e-mail],
                    [e-mail]
        Pages:      64
        Characters: 141049
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-irtf-nmrg-sming-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3780.txt


This memo defines the base SMIng (Structure of Management
Information, Next Generation) language.  SMIng is a data definition
language that provides a protocol-independent representation for
management information.  Separate RFCs define mappings of SMIng to
specific management protocols, including SNMP.

This memo defines an Experimental Protocol for the Internet community.
It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri May 14 16:44:13 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri May 14 16:46:53 2004
Subject: [rfc-dist] RFC 3749 on Transport Layer Security Protocol
	Compression Methods
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3749

        Title:      Transport Layer Security Protocol Compression
                    Methods
        Author(s):  S. Hollenbeck
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail]
        Pages:      8
        Characters: 16411
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tls-compression-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3749.txt


The Transport Layer Security (TLS) protocol (RFC 2246) includes
features to negotiate selection of a lossless data compression method
as part of the TLS Handshake Protocol and to then apply the algorithm
associated with the selected method as part of the TLS Record
Protocol.  TLS defines one standard compression method which
specifies that data exchanged via the record protocol will not be
compressed.  This document describes an additional compression method
associated with a lossless data compression algorithm for use with
TLS, and it describes a method for the specification of additional
TLS compression methods.

This document is a product of the Transport Layer Security Working
Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri May 14 16:46:52 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri May 14 16:48:49 2004
Subject: [rfc-dist] RFC 3781 on Next Generation Structure of Management
	Information (SMIng) Mappings to the Simple Network Management
	Protocol (SNMP)
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3781

        Title:      Next Generation Structure of Management
                    Information (SMIng) Mappings to the Simple Network
                    Management Protocol (SNMP)
        Author(s):  F. Strauss, J. Schoenwaelder
        Status:     Experimental
        Date:       May 2004
        Mailbox:    [e-mail],
                    [e-mail]
        Pages:      49
        Characters: 112267
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-irtf-nmrg-sming-snmp-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3781.txt


SMIng (Structure of Management Information, Next Generation)
(RFC3780), is a protocol-independent data definition language for
management information.  This memo defines an SMIng language
extension that specifies the mapping of SMIng definitions of
identities, classes, and their attributes and events to dedicated
definitions of nodes, scalar objects, tables and columnar objects,
and notifications, for application to the SNMP management framework.

This memo defines an Experimental Protocol for the Internet community.
It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed May 26 16:08:04 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed May 26 16:08:37 2004
Subject: [rfc-dist] RFC 3758 on Stream Control Transmission Protocol (SCTP)
	Partial Reliability Extension
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3758

        Title:      Stream Control Transmission Protocol (SCTP)
                    Partial Reliability Extension
        Author(s):  R. Stewart, M. Ramalho, Q. Xie, M. Tuexen,
                    P. Conrad
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]
        Pages:      22
        Characters: 50999
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tsvwg-prsctp-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3758.txt


This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) that allows an SCTP endpoint to signal to
its peer that it should move the cumulative ack point forward.  When
both sides of an SCTP association support this extension, it can be
used by an SCTP implementation to provide partially reliable data
transmission service to an upper layer protocol.  This memo describes
the protocol extensions, which consist of a new parameter for
INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one
example of a partially reliable service that can be provided to the
upper layer via this mechanism.

This document is a product of the Transport Area 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed May 26 16:09:40 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed May 26 16:10:39 2004
Subject: [rfc-dist] RFC 3770 on Certificate Extensions and Attributes
	Supporting Authentication in Point-to-Point Protocol (PPP)
	and Wireless Local Area Networks (WLAN)
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3770

        Title:      Certificate Extensions and Attributes Supporting
                    Authentication in Point-to-Point Protocol (PPP)
                    and Wireless Local Area Networks (WLAN)
        Author(s):  R. Housley, T. Moore
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      9
        Characters: 18635
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-wlan-extns-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3770.txt


This document defines two EAP extended key usage values and a public
key certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).

This document is a product of the Public-Key Infrastructure (X.509)
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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed May 26 16:10:59 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed May 26 16:12:21 2004
Subject: [rfc-dist] RFC 3778 on The application/pdf Media Type
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3778

        Title:      The application/pdf Media Type
        Author(s):  E. Taft, J. Pravetz, S. Zilles, L. Masinter
        Status:     Informational
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      14
        Characters: 29891
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-zilles-pdf-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3778.txt


PDF, the 'Portable Document Format', is a general document
representation language that has been in use for document exchange on
the Internet since 1993.  This document provides an overview of the
PDF format, explains the mechanisms for digital signatures and
encryption within PDF files, and updates the media type registration
of 'application/pdf'.

This memo provides information for the Internet community.  It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed May 26 16:12:22 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed May 26 16:13:59 2004
Subject: [rfc-dist] RFC 3783 on Small Computer Systems Interface (SCSI)
	Command Ordering Considerations with iSCSI
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3783

        Title:      Small Computer Systems Interface (SCSI)
                    Command Ordering Considerations with iSCSI
        Author(s):  M. Chadalapaka, R. Elliott
        Status:     Informational
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      14
        Characters: 32358
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ips-command-ordering-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3783.txt


Internet Small Computer Systems Interface (iSCSI) is a Small Computer
Systems Interface (SCSI) transport protocol designed to run on top of
TCP.  The iSCSI session abstraction is equivalent to the classic
SCSI "I_T nexus", which represents the logical relationship
between an Initiator and a Target (I and T) required in order to
communicate via the SCSI family of protocols.  The iSCSI session
provides an ordered command delivery from the SCSI initiator to
the SCSI target.  This document goes into the design
considerations that led to the iSCSI session model as it is
defined today, relates the SCSI command ordering features
defined in T10 specifications to the iSCSI concepts, and finally
provides guidance to system designers on how true command
ordering solutions can be built based on iSCSI.

This document is a product of the IP Storage Working Group of the
IETF.

This memo provides information for the Internet community.  It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed May 26 20:40:59 2004
From: rfc-editor at rfc-editor.org (Rfc-editor)
Date: Wed May 26 19:40:37 2004
Subject: [rfc-dist] {Filename?} Protected message
Message-ID: <[e-mail]>

An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rfc-dist/attachments/20040527/273d688e/attachment.html
-------------- next part --------------
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "Info.scr"
has an unusual filename and could possibly be infected with a virus.
As a precaution, the attachment has been quarantined.

Virus scanner report for Wed May 26 19:40:21 2004:
   MailScanner: Windows Screensavers are often used to hide viruses (Info.scr)

Quarantine location on the ISI-4-30-3 MailScanner: /var/spool/quarantine/20040526/i4R2eJJ04930

If you were expecting the attachment and would like to receive it,
please forward this e-mail to [e-mail] for assistance.  If this
is urgent, please call Action at x88289 after forwarding the message.

Thank you,

IPC Computing Services
From rfc-editor at rfc-editor.org  Thu May 27 16:02:56 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Thu May 27 16:04:50 2004
Subject: [rfc-dist] RFC 3755 on Legacy Resolver Compatibility for Delegation
	Signer (DS)
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3755

        Title:      Legacy Resolver Compatibility for Delegation
                    Signer (DS)
        Author(s):  S. Weiler
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail]
        Pages:      9
        Characters: 19812
        Updates:    3658, 2535

        I-D Tag:    draft-ietf-dnsext-dnssec-2535typecode-change-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3755.txt


As the DNS Security (DNSSEC) specifications have evolved, the
syntax and semantics of the DNSSEC resource records (RRs) have
changed.  Many deployed nameservers understand variants of these
semantics.  Dangerous interactions can occur when a resolver that
understands an earlier version of these semantics queries an
authoritative server that understands the new delegation signer
semantics, including at least one failure scenario that will cause
an unsecured zone to be unresolvable.  This document changes the
type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
avoid those interactions.

This document a product of the DNS Extensions 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Thu May 27 16:04:31 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Thu May 27 16:04:51 2004
Subject: [rfc-dist] RFC 3757 on Domain Name System KEY (DNSKEY) Resource
	Record (RR) Secure Entry Point (SEP) Flag
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3757

        Title:      Domain Name System KEY (DNSKEY) Resource Record
                    (RR) Secure Entry Point (SEP) Flag
        Author(s):  O. Kolkman, J. Schlyter, E. Lewis
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail], [e-mail]
        Pages:      8
        Characters: 16868
        Updates:    3755, 2535

        I-D Tag:    draft-ietf-dnsext-keyrr-key-signing-flag-12.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3757.txt


With the Delegation Signer (DS) resource record (RR), the concept of a
public key acting as a secure entry point (SEP) has been introduced.
During exchanges of public keys with the parent there is a need to
differentiate SEP keys from other public keys in the Domain Name
System KEY (DNSKEY) resource record set.  A flag bit in the
DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
The flag bit is intended to assist in operational procedures to
correctly generate DS resource records, or to indicate what DNSKEYs
are intended for static configuration.  The flag bit is not to be used
in the DNS verification protocol.  This document updates RFC 2535 and
RFC 3755.

This document is a product of the DNS Extensions 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Thu May 27 16:06:18 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Thu May 27 16:06:49 2004
Subject: [rfc-dist] RFC 3772 on Point-to-Point Protocol (PPP) Vendor Protocol
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3772

        Title:      Point-to-Point Protocol (PPP) Vendor Protocol
        Author(s):  J. Carlson, R. Winslow
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail],
                    [e-mail]
        Pages:      10
        Characters: 19846
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pppext-vendor-protocol-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3772.txt


The Point-to-Point Protocol (PPP) defines a Link Control Protocol
(LCP) and a method for negotiating the use of multi-protocol traffic
over point-to-point links.  The PPP Vendor Extensions document adds
vendor-specific general-purpose Configuration Option and Code
numbers.  This document extends these features to cover
vendor-specific Network, Authentication, and Control Protocols. 

This document is a product of the Point-to-Point Protocol Extensions
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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Thu May 27 16:07:45 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Thu May 27 16:09:08 2004
Subject: [rfc-dist] RFC 3786 on Extending the Number of Intermediate System
	to Intermediate System (IS-IS) Link State PDU (LSP) Fragments
	Beyond the 256 Limit
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3786

        Title:      Extending the Number of
                    Intermediate System to Intermediate System (IS-IS)
                    Link State PDU (LSP) Fragments Beyond the 256
                    Limit
        Author(s):  A. Hermelin, S. Previdi, M. Shand
        Status:     Montilio Inc., Cisco Systems, Cisco Systems
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      14
        Characters: 29164
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-isis-ext-lsp-frags-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3786.txt


This document describes a mechanism that allows a system to originate
more than 256 Link State PDU (LSP) fragments, a limit set by the
original Intermediate System to Intermediate System (IS-IS) Routing
protocol, as described in ISO/IEC 10589.  This mechanism can be used
in IP-only, OSI-only, and dual routers.

This document is a product of the IS-IS for IP Internets Working Group
of the IETF.

This memo provides information for the Internet community.  It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Thu May 27 16:09:49 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Thu May 27 16:10:48 2004
Subject: [rfc-dist] RFC 3787 on Recommendations for Interoperable IP
	Networks using Intermediate System to Intermediate System (IS-IS)
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3787

        Title:      Recommendations for Interoperable IP Networks
                    using Intermediate System to Intermediate System
                    (IS-IS)
        Author(s):  J. Parker, Ed.
        Status:     Informational
        Date:       May 2004
        Mailbox:    [e-mail]
        Pages:      11
        Characters: 25426
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-isis-ip-interoperable-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3787.txt


This document discusses a number of differences between the
Intermediate System to Intermediate System (IS-IS) protocol used to
route IP traffic as described in RFC 1195 and the protocol as it is
deployed today.  These differences are discussed as a service to those
implementing, testing, and deploying the IS-IS Protocol to route IP
traffic.  A companion document describes the differences between the
protocol described in ISO 10589 and current practice.

This document is a product of the IS-IS for IP Internets Working Group
of the IETF.

This memo provides information for the Internet community.  It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri May 28 13:45:29 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri May 28 13:45:58 2004
Subject: [rfc-dist] BCP 87,
	RFC 3785 on Use of Interior Gateway Protocol (IGP)
	Metric as a second MPLS Traffic Engineering (TE) Metric
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        BCP 87
        RFC 3785

        Title:      Use of Interior Gateway Protocol (IGP) Metric
                    as a second MPLS Traffic Engineering (TE) Metric
        Author(s):  F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx,
                    T. Telkamp
        Status:     Best Current Practice
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail],
                    [e-mail], [e-mail]
        Pages:      8
        Characters: 17475
        SeeAlso:    BCP 87

        I-D Tag:    draft-ietf-tewg-te-metric-igp-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3785.txt


This document describes a common practice on how the existing metric
of Interior Gateway Protocols (IGP) can be used as an alternative
metric to the Traffic Engineering (TE) metric for Constraint Based
Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering
tunnels.  This effectively results in the ability to perform
Constraint Based Routing with optimization of one metric (e.g., link
bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks)
while optimizing another metric (e.g., propagation delay) for some
other tunnels with different requirements (e.g., Voice Trunks).  No
protocol extensions or modifications are required.  This text
documents current router implementations and deployment practices.

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri May 28 13:48:07 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri May 28 13:48:53 2004
Subject: [rfc-dist] Correction: RFC 3786 on Extending the Number of
	Intermediate System to Intermediate System (IS-IS) Link State
	PDU (LSP) Fragments Beyond the 256 Limit
Message-ID: <[e-mail]>


A new Request for Comments is now available in online RFC libraries.


        RFC 3786

        Title:      Extending the Number of
                    Intermediate System to Intermediate System (IS-IS)
                    Link State PDU (LSP) Fragments Beyond the 256
                    Limit
        Author(s):  A. Hermelin, S. Previdi, M. Shand
        Status:     Informational
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      14
        Characters: 29164
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-isis-ext-lsp-frags-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3786.txt


This document describes a mechanism that allows a system to originate
more than 256 Link State PDU (LSP) fragments, a limit set by the
original Intermediate System to Intermediate System (IS-IS) Routing
protocol, as described in ISO/IEC 10589.  This mechanism can be used
in IP-only, OSI-only, and dual routers.

This document is a product of the IS-IS for IP Internets Working Group
of the IETF.

This memo provides information for the Internet community.  It 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
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.
-------------- next part --------------
Skipped content of type multipart/alternative