AD Review: draft-ietf-rmt-flute-revised-11

Hi,

I have concerns that this specification might not be totally backward
compatible with version 1 (RFC3926), and should therefore have a new
revision number.

	a) The expiration time in the FDT instance is now required to
be UTF8, but was not so required in RFC3926

	b) section 3.4.1 describes a different wraparound algorithm
than RFC3926

	c) section 3.4.2 modifies the meaning of "Complete"

	d) section 3.4.2 modifies the meaning of "Content Location"

	e) section 3.4.2 modifies the namespace, and significantly
alters the XML Schema. I think an implementation which is valid using
the schema in RFC3926 would not necessarily validate using the schema
in this draft. 

	f) section 3.4.2 modifies the requirement 
		   In case the basic FDT XML Schema is extended in
terms of new
   descriptors, for attributes applying to a single file, those MUST
be
   placed within the attributes of the element "File". 
to
   In case the basic FDT XML Schema is extended in terms of new
   descriptors (attributes or elements), for descriptors applying to a
   single file, those MUST be placed within the element "File".  

	g) section 4 modifies the definition of the CENC field:
   "This field signals the content encoding algorithm used in the FDT
   Instance payload.  The definition of this field is outside the
scope
   of this specification.  Applicable content encoding algorithms
   include, for example, ZLIB [10], DEFLATE [16] and GZIP [17]."
to
   "This field signals the content encoding algorithm used in the FDT
   Instance payload.  This subsection reserves the Content Encoding
   Algorithm values 0, 1, 2 and 3 for null, ZLIB [RFC.ZLIB], DEFLATE
   [RFC.DEFLATE] and GZIP [RFC.GZIP] respectively."

	h) normative references have changed, and it is possible that
those specifications
         have changed such that rfc3926-compliant implementations may
not be compliant
         per this draft. 

I didn't spot anything I thought was problematic if the version#
changed.

I do think that this spec is rather loose, and really should be
tightened for interoperability for proposed standard.

David Harrington
[email protected]
[email protected]
[email protected]