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

David,

Is strict backwards compatibility with the experimental RFC a goal ? (I agree that if it was, we did not meet it and then a new version number is required for the reasons you give).

There are a number of SDOs that have based their work on the drafts of this version and they would presumably like to reference this RFC. A change in version number wouldn't be possible for them.

I think there were a number of issues with the Experimental version would we wanted to fix, which could never have been done in a strict backwards compatible way, and so if we had ever been concerned about interop problems with RFC3926 implementations we should have increased the version number long ago.

...Mark

On Jun 9, 2010, at 3:59 PM, David B Harrington wrote:

> 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]
> 
> 
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rmt