Subject: Re: [Rmt] About Flute-revised open points

From: <[email-masked]>
Date: Mon, 9 May 2011 13:23:04 +0200

Hi all

Quick run through Dave's FLUTE iop concerns...

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

It's just a clarification. The XML schema demands that everything is in UTF8, so in practice there's no change.

        b) section 3.4.1 describes a different wraparound algorithm
than RFC3926

In practice the both specs say handling reuse of FDT instance Id (due to wraparound) is out of scope of the spec. Only very exceptional applications of FLUTE would cause wraparound, so we've been happy with this. Changing the default behavior to wraparound to the lowest unexpired instance I'd (instead of just to zero) is a nicety, after all we don't require that subsequent Ids mustn't land on unexpired Ids. So this is a slightly odd trivial change.

However, this was raised and solved already (and awaits an editorial revision):

http://www.ietf.org/mail-archive/web/rmt/current/msg01465.html

        c) section 3.4.2 modifies the meaning of "Complete"

This change does have implications for exp-revised iop. The new text could lead to a revised receiver rejecting the complete FDT of a revised server, which would not be catastrophic but would be undesirable.

Whatever the eventual consensus on good spec, I suggest revising this text as it is currently problematic. The term "exhausts" implies that such an FDT instance finishes off the list of files in the session. Whereas the following text states that it implies that the FDT instance provides a comprehensive list of all files that have ever been in the session. If we choose the latter (new) alternative, we should modify the "exhausts" sentence. But if we do, consider the above FDT instance I'd wraparound issue in conduction with this: just how massive, and how obsolete, an FDT instance would we be forcing into creation? Fortunately we discussed and agreed corrective action on this already:

http://www.ietf.org/mail-archive/web/rmt/current/msg01465.html

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

Just rewording. The meaning is preserved.

        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".

On e and f)
Discussed at length through these threads...
http://www.ietf.org/mail-archive/web/rmt/current/msg00404.html
http://www.ietf.org/mail-archive/web/rmt/current/msg01543.html
...which essentially say that the change is graceful and doesn't disturb mutual exp+revised existence.

        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."

No change to operation. Any use of these fields with the experimental (which we did do to test iop between different implementations) was adhoc and, even so, matched the assignments now in the spec.

However, this raises an interesting point: should we assign 255 as an experimental CENC so that in further experimental tests can be guided onto this an not inject any future problems?

        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.

It seems that other than possibly LCT and ALC, there are no problems with these.

...given that incrementing the version number would lead to new receivers rejecting all experimental server data in all cases, and experimental receivers rejecting all revised server data in all cases; keeping the version number seems like the more graceful approach ( based on the concerns expressed by Dave).

Cheers, Rod.

On 7.4.2011, at 18.19, "ext [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

I agree with Magnus here.    I hope that Rod can review Vincent's historical summary of the issues and provide consensus or comments to help us resolve this.

Additionally, here is a link to the message that summarizes the backwards incompatibility issues identified by Dave Harrington's AD review of FLUTE:

<http://www.ietf.org/mail-archive/web/rmt/current/msg01434.html>http://www.ietf.org/mail-archive/web/rmt/current/msg01434.html

best regards,

Brian Adamson
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

On Mar 31, 2011, at 11:01 AM, Magnus Westerlund wrote:

Hi,

I think this is a good example of what I expect in this discussion. I
think that a number of the changes has good reasons to their changes and
that we are not likely to reverse the WG documents text. For the record
I don't really remember the reasons for the designs in this schema and
what the underlying 3GPP reasons are.

I have no rapid need for an updated flute so I am willing to let this
discussion go on for a while. Especially letting people try to dig up
any more motivations. But the fact is that the WG spent 5+ years in
producing this document. There are reasons why it looks like it does.
Reversing that decision at the last minute seems dangerous and likely to
cause more issues than actually bumping the version number.

Cheers

Magnus

Everybody,

A follow-up to our long discussion during the meeting:

1- Concerning Flute version, the email that convinced
   me of the necessity to move to version 2 is the
   following one, from Mike, sent on Feb 7, 2011:

<http://www.ietf.org/mail-archive/web/rmt/current/msg01511.html>http://www.ietf.org/mail-archive/web/rmt/current/msg01511.html

2- Concerning XML extensibility, after searching a little
   bit better in my archives, I finally found the initial reasons.
   See the following 3 emails (from June 2005):

* The initial email (from Rod) explaining why 3GPP proposed
   another schema:
<http://www.ietf.org/mail-archive/web/rmt/current/msg00404.html>http://www.ietf.org/mail-archive/web/rmt/current/msg00404.html

* The answer from Magnus, with the 3GPP schema:
<http://www.ietf.org/mail-archive/web/rmt/current/msg00477.html>http://www.ietf.org/mail-archive/web/rmt/current/msg00477.html

* Finally Rod's promise (yes!!!) to include this schema:
<http://www.ietf.org/mail-archive/web/rmt/current/msg00482.html>http://www.ietf.org/mail-archive/web/rmt/current/msg00482.html

That's for the history. The question now is what do we want
to do?

 Vincent

_______________________________________________
Rmt mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/rmt>https://www.ietf.org/mailman/listinfo/rmt

--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------
_______________________________________________
Rmt mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rmt

_______________________________________________
Rmt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rmt