[rfc-dist] RFC 3880 on Call Processing Language (CPL): A Language for User Control of Internet Telephony Services

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

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


        RFC 3880

        Title:      Call Processing Language (CPL):
                    A Language for User Control of Internet Telephony
                    Services
        Author(s):  J. Lennox, X. Wu, H. Schulzrinne
        Status:     Standards Track
        Date:       October 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      74
        Characters: 154991
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-iptel-cpl-09.txt

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


This document defines the Call Processing Language (CPL), a language
to describe and control Internet telephony services.  It is designed
to be implementable on either network servers or user agents.  It is
meant to be simple, extensible, easily edited by graphical clients,
and independent of operating system or signalling protocol.  It is
suitable for running on a server where users may not be allowed to
execute arbitrary programs, as it has no variables, loops, or ability
to run external programs.

This document is a product of the IP Telephony Working Goup 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.

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  Mon Nov  1 09:12:31 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Nov  1 09:14:00 2004
Subject: [rfc-dist] RFC 3945 on Generalized Multi-Protocol Label Switching
	(GMPLS) Architecture
Message-ID: <[e-mail]>


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


        RFC 3945

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Architecture
        Author(s):  E. Mannie, Ed.
        Status:     Standards Track
        Date:       October 2004
        Mailbox:    [e-mail]
        Pages:      69
        Characters: 166700
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ccamp-gmpls-architecture-07.txt

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


Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.

This document describes the architecture of GMPLS.  GMPLS extends
MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g., incoming port or
fiber to outgoing port or fiber).  The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes.  The intention is to
cover both the signaling and the routing part of that control plane.

This document is a product of the Common Control and Measurement Plane
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.

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  Mon Nov  1 09:14:25 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Nov  1 09:17:07 2004
Subject: [rfc-dist] RFC 3946 on Generalized Multi-Protocol Label Switching
	(GMPLS) Extensions for Synchronous Optical Network (SONET)
	and Synchronous Digital Hierarchy (SDH) Control
Message-ID: <[e-mail]>


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


        RFC 3946

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Extensions for Synchronous Optical Network (SONET)
                    and Synchronous Digital Hierarchy (SDH) Control
        Author(s):  E. Mannie, D. Papadimitriou
        Status:     Standards Track
        Date:       October 2004
        Mailbox:    [e-mail],
                    [e-mail]
        Pages:      26
        Characters: 52205
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ccamp-gmpls-sonet-sdh-08.txt

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


This document is a companion to the Generalized Multi-Protocol
Label Switching (GMPLS) signaling.  It defines the Synchronous
Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
technology specific information needed when using GMPLS signaling.

This document is a product of the Common Control and Measurement Plane
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.

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  Mon Nov  1 09:16:38 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Nov  1 09:17:30 2004
Subject: [rfc-dist] RFC 3903 on Session Initiation Protocol (SIP) Extension
	for Event State Publication
Message-ID: <[e-mail]>


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


        RFC 3903

        Title:      Session Initiation Protocol (SIP) Extension
                    for Event State Publication
        Author(s):  A. Niemi, Ed.
        Status:     Standards Track
        Date:       October 2004
        Mailbox:    [e-mail]
        Pages:      32
        Characters: 72062
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-sip-publish-04.txt

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


This document describes an extension to the Session Initiation
Protocol (SIP) for publishing event state used within the SIP Events
framework.  The first application of this extension is for the
publication of presence information.

The mechanism described in this document can be extended to support
publication of any event state for which there exists an appropriate
event package.  It is not intended to be a general-purpose mechanism
for transport of arbitrary data, as there are better-suited
mechanisms for this purpose.

This document is a product of the Session Initiation 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 [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.

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  Mon Nov  1 09:18:42 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Nov  1 09:21:15 2004
Subject: [rfc-dist] RFC 3924 Cisco Architecture for Lawful Intercept in IP
	Networks
Message-ID: <[e-mail]>


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


        RFC 3924

        Title:      Cisco Architecture for Lawful Intercept in IP
                    Networks
        Author(s):  F. Baker, B. Foster, C. Sharp
        Status:     Informational
        Date:       October 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      18
        Characters: 40826
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-baker-slem-architecture-02.txt

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


For the purposes of this document, lawful intercept is the lawfully
authorized interception and monitoring of communications.  Service
providers are being asked to meet legal and regulatory requirements
for the interception of voice as well as data communications in IP
networks in a variety of countries worldwide.  Although requirements
vary from country to country, some requirements remain common even
though details such as delivery formats may differ.  This document
describes Cisco's Architecture for supporting lawful intercept in IP
networks.  It provides a general solution that has a minimum set of
common interfaces.  This document does not attempt to address any of
the specific legal requirements or obligations that may exist in a
particular country.

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.

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  Mon Nov  1 09:20:07 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Nov  1 09:21:15 2004
Subject: [rfc-dist] RFC 3937 on A Uniform Resource Name (URN) Namespace for
	the International Press Telecommunications Council (IPTC)
Message-ID: <[e-mail]>


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


        RFC 3937

        Title:      A Uniform Resource Name (URN) Namespace for
                    the International Press Telecommunications Council
                    (IPTC)
        Author(s):  M. Steidl
        Status:     Informational
        Date:       October 2004
        Mailbox:    [e-mail]
        Pages:      9
        Characters: 15458
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-steidl-iptc-urn-00.txt

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


This document describes a URN (Uniform Resource Name) namespace for
identifying persistent resources published by the International Press
Telecommunications Council (IPTC).  These resources include XML Data
Type Definition files (DTD), XML Schema, Namespaces in XML, XSL
stylesheets, other XML based document and documents of other data
formats like PDF documents, Microsoft Office documents and others.

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.

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 Nov  5 16:27:13 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Nov  5 16:28:39 2004
Subject: [rfc-dist] RFC 3867 on Payment Application Programmers Interface
	(API) for v1.0 Internet Open Trading Protocol (IOTP)
Message-ID: <[e-mail]>


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


        RFC 3867

        Title:      Payment Application Programmers Interface (API)
                    for v1.0 Internet Open Trading Protocol (IOTP)
        Author(s):  Y. Kawatsura, M. Hiroya, H. Beykirch
        Status:     Informational
        Date:       November 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      106
        Characters: 234572
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-trade-iotp-v1.0-papi-06.txt

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


The Internet Open Trading Protocol (IOTP) provides a data exchange
format for trading purposes while integrating existing pure payment 
protocols seamlessly.  This motivates the multiple layered system
architecture which consists of at least some generic IOTP application
core and multiple specific payment modules.

This document addresses a common interface between the IOTP
application core and the payment modules, enabling the
interoperability between these kinds of modules.  Furthermore, such an
interface provides the foundations for a plug-in-mechanism in actual
implementations of IOTP application cores.

Such interfaces exist at the Consumers', the Merchants' and the
Payment Handlers' installations connecting the IOTP application core
and the payment software components/legacy systems.

This document is a product of the Internet Open Trading Protocol
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.

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 Nov  5 16:28:36 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Nov  5 16:29:38 2004
Subject: [rfc-dist] BCP 93, RFC 3933 on A Model for IETF Process Experiments
Message-ID: <[e-mail]>


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


        BCP 93
        RFC 3933

        Title:      A Model for IETF Process Experiments
        Author(s):  J. Klensin, S. Dawkins
        Status:     Best Current Practice
        Date:       November 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      7
        Characters: 14409
        SeeAlso:    BCP 93

        I-D Tag:    draft-klensin-process-july14-02.txt

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


The IETF has designed process changes over the last ten years in one
of two ways: announcement by the IESG, sometimes based on informal
agreements with limited community involvement and awareness, and
formal use of the same mechanism used for protocol specification.  The
first mechanism has often proven to be too lightweight, the second too
heavyweight.

This document specifies a middle-ground approach to the system of
making changes to IETF process, one that relies heavily on a "propose
and carry out an experiment, evaluate the experiment, and then
establish permanent procedures based on operational experience" model
rather than those previously attempted.

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.

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  Mon Nov  8 15:03:22 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Nov  8 15:05:09 2004
Subject: [rfc-dist] RFC 3956 on Embedding the Rendezvous Point (RP) Address
	in an IPv6 Multicast Address
Message-ID: <[e-mail]>


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


        RFC 3956
 
        Title:      Embedding the Rendezvous Point (RP) Address
                    in an IPv6 Multicast Address
        Author(s):  P. Savola, B. Haberman
        Status:     Standards Track
        Date:       November 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      18
        Characters: 40136
        Updates:    3306
 
        I-D Tag:    draft-ietf-mboned-embeddedrp-07.txt

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


This memo defines an address allocation policy in which the address
of the Rendezvous Point (RP) is encoded in an IPv6 multicast group
address.  For Protocol Independent Multicast - Sparse Mode (PIM-SM),
this can be seen as a specification of a group-to-RP mapping
mechanism.  This allows an easy deployment of scalable inter-domain
multicast and simplifies the intra-domain multicast configuration as
well.  This memo updates the addressing format presented in RFC 3306.

This document is a product of the MBONE Deployment 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.

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 Nov 19 12:04:45 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Nov 19 12:05:24 2004
Subject: [rfc-dist] RFC 3940 on Negative-acknowledgment (NACK)-Oriented
	Reliable Multicast (NORM) Protocol
Message-ID: <[e-mail]>


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


        RFC 3940

        Title:      Negative-acknowledgment (NACK)-Oriented
                    Reliable Multicast (NORM) Protocol
        Author(s):  B. Adamson, C. Bormann, M. Handley, J. Macker
        Status:     Experimental
        Date:       November 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      80
        Characters: 220549
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-rmt-pi-norm-10.txt

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


This document describes the messages and procedures of the
Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM)
protocol.  This protocol is designed to provide end-to-end reliable
transport of bulk data objects or streams over generic IP multicast
routing and forwarding services.  NORM uses a selective, negative
acknowledgment mechanism for transport reliability and offers
additional protocol mechanisms to allow for operation with minimal "a
priori" coordination among senders and receivers.  A congestion
control scheme is specified to allow the NORM protocol to fairly share
available network bandwidth with other transport protocols such as
Transmission Control Protocol (TCP).  It is capable of operating with
both reciprocal multicast routing among senders and receivers and with
asymmetric connectivity (possibly a unicast return path) between the
senders and receivers.  The protocol offers a number of features to
allow different types of applications or possibly other higher level
transport protocols to utilize its service in different ways.  The
protocol leverages the use of FEC-based repair and other IETF reliable
multicast transport (RMT) building blocks in its design.

This document is a product of the Reliable Multicase Transport Working
Group of the IETF.

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.

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 Nov 19 12:06:35 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Nov 19 12:07:52 2004
Subject: [rfc-dist] RFC 3941 on Negative-Acknowledgment (NACK)-Oriented
	Reliable Multicast (NORM) Building Blocks
Message-ID: <[e-mail]>


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


        RFC 3941

        Title:      Negative-Acknowledgment (NACK)-Oriented Reliable
                    Multicast (NORM) Building Blocks
        Author(s):  B. Adamson, C. Bormann, ,M. Handley J. Macker
        Status:     Experimental
        Date:       November 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      36
        Characters: 92785
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-rmt-bb-norm-09.txt

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


This document discusses the creation of negative-acknowledgment
(NACK)-oriented reliable multicast (NORM) protocols.  The rationale
for NORM goals and assumptions are presented.  Technical challenges
for NACK-oriented (and in some cases general) reliable multicast
protocol operation are identified.  These goals and challenges are
resolved into a set of functional "building blocks" that address
different aspects of NORM protocol operation.  It is anticipated that
these building blocks will be useful in generating different
instantiations of reliable multicast protocols.

This document is a product of the Reliable Multicast Transport Working
Group of the IETF.

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.

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  Mon Nov 22 16:50:13 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Nov 22 16:50:40 2004
Subject: [rfc-dist] RFC 3942 on Reclassifying Dynamic Host Configuration
	Protocol version 4 (DHCPv4) Options
Message-ID: <[e-mail]>


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


        RFC 3942

        Title:      Reclassifying Dynamic Host Configuration Protocol
                    version 4 (DHCPv4) Options
        Author(s):  B. Volz
        Status:     Standards Track
        Date:       November 2004
        Mailbox:    [e-mail]
        Pages:      7
        Characters: 13996
        Updates:    2132

        I-D Tag:    draft-ietf-dhc-reclassify-options-01.txt

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


This document updates RFC 2132 to reclassify Dynamic Host
Configuration Protocol version 4 (DHCPv4) option codes 128 to 223
(decimal) as publicly defined options to be managed by IANA in
accordance with RFC 2939.  This document directs IANA to make these
option codes available for assignment as publicly defined DHCP options
for future options.

This document is a product of the Dynamic Host Configuration 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.

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  Mon Nov 22 16:51:31 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Nov 22 16:53:13 2004
Subject: [rfc-dist] RFC 3943 on Transport Layer Security (TLS) Protocol
	Compression Using Lempel-Ziv-Stac (LZS)
Message-ID: <[e-mail]>


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


        RFC 3943

        Title:      Transport Layer Security (TLS) Protocol
                    Compression Using Lempel-Ziv-Stac (LZS)
        Author(s):  R. Friend
        Status:     Informational
        Date:       November 2004
        Mailbox:    [e-mail]
        Pages:      13
        Characters: 28942
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-friend-tls-lzs-compression-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3943.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 then to 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 the Lempel-Ziv-Stac (LZS) lossless data compression
algorithm for use with TLS.  This document also defines the
application of the LZS algorithm to the TLS Record Protocol.

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.

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