Flute FDT inconsistent with HTTP

Hello All,

I've just noticed that the definitions for the Content-Length,
Content-Encoding, and Transfer-Length fields with the FDT in FLUTE are
inconsistent with HTTP.

>From page 13 in FLUTE:

      Where the length is described, the attribute "Content-Length" MUST
      be used for the purpose as defined in [6]. The transfer length is
      defined to be the length of the object transported in bytes. It is
      often important to convey the transfer length to receivers,
      because the source block structure needs to be known for the FEC
      decoder to be applied to recover source blocks of the file, and
      the transfer length is often needed to properly determine the
      source block structure of the file. There generally will be a
      difference between the length of the original file and the
      transfer length if content encoding is applied to the file before
      transport, and thus the "Content-Encoding" attribute is used.  If
      the file is not content encoded before transport (and thus the
      "Content-Encoding" attribute is not used) then the transfer length
      is the length of the original file, and in this case the
      "Content-Length" is also the transfer length. However, if the file
      is content encoded before transport (and thus the
      "Content-Encoding" attribute is used), e.g. if compression is
      applied before transport to reduce the number of bytes that need
      to be transferred, then the transfer length is generally different
      than the length of the original file, and in this case the
      attribute "Transfer-Length" MAY be used to carry the transfer
      length.

Re: Flute FDT inconsistent with HTTP

Justin,

Thanks for your comments. As you know, flute has past WG last-call and
is now in the final stage of IESG evaluation. I reckon it is still
possible to make important last-minute clarifications like this one,
but we will have to check with Allison and act fast.

A possible followup if for you and the authors to agree on the
smallest satisfactory set of changes and to check with Allison
if it is possible to edit the document.

	thanks,
	Lorenzo

On Tue, Jul 06, 2004 at 09:15:23PM -0500, Justin Chapweske wrote:
> Hello All,
> 
> I've just noticed that the definitions for the Content-Length,
> Content-Encoding, and Transfer-Length fields with the FDT in FLUTE are
> inconsistent with HTTP.
> 
> >From page 13 in FLUTE:
> 
>       Where the length is described, the attribute "Content-Length" MUST
>       be used for the purpose as defined in [6]. The transfer length is
>       defined to be the length of the object transported in bytes. It is
>       often important to convey the transfer length to receivers,
>       because the source block structure needs to be known for the FEC
>       decoder to be applied to recover source blocks of the file, and
>       the transfer length is often needed to properly determine the

Document Action: 'FLUTE - File Delivery over Unidirectional Transport' to Experimental RFC

The IESG has approved the following document:

- 'FLUTE - File Delivery over Unidirectional Transport '
   <draft-ietf-rmt-flute-08.txt> as an Experimental RFC

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

The IESG contact persons are Allison Mankin and Jon Peterson.

I-D ACTION:draft-ietf-rmt-bb-tfmcc-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title		: TCP-Friendly Multicast Congestion Control (TFMCC):Protocol Specification
	Author(s)	: J. Widmer, M. Handley
	Filename	: draft-ietf-rmt-bb-tfmcc-03.txt,.ps
	Pages		: 30
	Date		: 2004-7-13
	
This document specifies TCP-Friendly Multicast Congestion
Control (TFMCC).  TFMCC is a congestion control mechanism for
multicast transmissions in a best-effort Internet environment.
It is a single-rate congestion control scheme, where the
sending rate is adapted to the receiver experiencing the worst
network conditions.  TFMCC is reasonably fair when competing
for bandwidth with TCP flows and has a relatively low
variation of throughput over time, making it suitable for
applications such as streaming media where a relatively smooth
sending rate is of importance.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tfmcc-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,

I-D ACTION:draft-ietf-rmt-bb-pgmcc-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title		: PGMCC single rate multicast congestion control: Protocol Specification
	Author(s)	: L. Rizzo, et al.
	Filename	: draft-ietf-rmt-bb-pgmcc-03.txt,.ps
	Pages		: 22
	Date		: 2004-7-14
	
This document describes PGMCC, a single rate multicast
congestion control scheme which is TCP-friendly and achieves
scalability, stability and fast response to variations in
network conditions. PGMCC is suitable for both non-reliable
and reliable data transfers.  It is mainly designed for NAK-
based multicast protocols, and uses a window-based, TCP-like
control loop using positive ACKs between one representative of
the receiver group (the ACKER) and the sender.  The ACKER is
selected dynamically and may change over time.
PGMCC is made of two components: a window-based control loop,
which closely mimics TCP behaviour, and a fast and low-
overhead procedure to select (and track changes of) the ACKER.
The scheme is robust to measurement errors, and supports fast
response to changes in the receiver set and/or network
conditions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-pgmcc-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  

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

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title		: NACK-Oriented Reliable Multicast (NORM) Building Blocks
	Author(s)	: B. Adamson, et al.
	Filename	: draft-ietf-rmt-bb-norm-09.txt,.pdf
	Pages		: 30
	Date		: 2004-7-15
	
This document discusses the creation the 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-norm-09.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then

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

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title		: NACK-Oriented Reliable Multicast Protocol (NORM)
	Author(s)	: B. Adamson, et al.
	Filename	: draft-ietf-rmt-pi-norm-10.txt,.pdf
	Pages		: 70
	Date		: 2004-7-15
	
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 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
 The protocol leverages the use of FEC-based repair and other IETF
reliable multicast transport (RMT) building blocks in its design.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-10.txt

Statement of Intent for NORM

RMT-ers,

It's been a little while since the WG finished with NORM.  The IESG
approved the BB and PI not long ago, and we've recently finished
a bit of pre-approval work (ID-checklist nits, an IANA issue...).

The last issue is to let you see the Statement of Intent language
for the PI and BB, just like the language we've placed on the other
Experimentals from RMT, for instance ALC.

Statement of Intent

      This memo contains part of the definitions necessary to fully
      specify a Reliable Multicast Transport protocol in accordance with
      RFC2357.  As per RFC2357, the use of any reliable multicast
      protocol in the Internet requires an adequate congestion control
      scheme.

      While waiting for such a scheme to be available, or for an
      existing scheme to be proven adequate, the Reliable Multicast
      Transport working group (RMT) publishes this Request for Comments
      in the "Experimental" category.

      It is the intent of RMT to re-submit this specification as an IETF
      Proposed Standard as soon as the above condition is met.

Thanks,

Allison

Document Action: 'NACK-Oriented Reliable Multicast Protocol (NORM)' to Experimental RFC

The IESG has approved the following documents:

- 'NACK-Oriented Reliable Multicast (NORM) Building Blocks '
   <draft-ietf-rmt-bb-norm-09.txt> as an Experimental RFC
- 'NACK-Oriented Reliable Multicast Protocol (NORM) '
   <draft-ietf-rmt-pi-norm-10.txt> as an Experimental RFC

These documents are products of the Reliable Multicast Transport Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

RFC Editor Note 

Add to both documents at the end of the Introduction (not as a numbered 
section)

Statement of Intent

      This memo contains part of the definitions necessary to fully
      specify a Reliable Multicast Transport protocol in accordance with
      RFC2357.  As per RFC2357, the use of any reliable multicast
      protocol in the Internet requires an adequate congestion control
      scheme.

      While waiting for such a scheme to be available, or for an
      existing scheme to be proven adequate, the Reliable Multicast
      Transport working group (RMT) publishes this Request for Comments
      in the "Experimental" category.

      It is the intent of RMT to re-submit this specification as an IETF

[SUSPECTED SPAM] Re: Msg reply

------ NOTICE ------------ NOTICE ------------ NOTICE ------

1. The LBNL VirusWall REMOVED a virus from this message.
   The message is now safe to open.

2. If you need help or have questions, contact the
   Help Desk at 510-486-HELP.

3. For information, please visit:
   http://www.lbl.gov/ITSD/Security/vulnerabilities/virus.html

------------------------------------------------------------

Found virus VBS_BAGLE.GEN in file Joke.hta
The uncleanable file Joke.hta is moved to /etc/iscan/virus_quarantine/virHKDh0a41P.

---------------------------------------------------------

------ NOTICE ------------ NOTICE ------------ NOTICE ------

1. The LBNL VirusWall REMOVED a virus from this message.
   The message is now safe to open.