Re: [Rmt] About Flute-revised open points

[<[e-mail]>]

Thanks for Dave's link, I'll check this out next week.

Meanwhile...

It seems like I am being painted a little like the outlier with last minute jitters. As Vincent kindly pointed out there are a few unresolved threads that have been running a long while. Mostly we simply haven't bothered to get them resolved. For each of those years. (And I must also personally appologise for not tracking LCT and ALC at each revision so as catch the greater than agreed impact on FLUTE before they went standards track. Of course we may well have had the same end result, just without the percenption of last minute issues). In spite of originally agreeing to maintain compatability where feasible, we're now stuck with some long term undiscolsed design decisions. Practically, we may have to embrace the unknown, but it's reasonable engineering to point out that our process has these black spots, whether communicated as last minute jitters or otherwise :)

So as Magnus earlier suggested, I feel we need to be pragmatic with what we have. At the same time I feel we need a bit of design explanation where it exists as the rmt mailing list has been a close approximation to silent on these issues for most for this bis/revised era. (E.g. I hope I've overlooked the discussion or notification of non-backwards comatible changes prior to an updated ID appearing for LCT and ALC, and would be grateful to hear that this is so).

Meanwhile, to Vincent's couple of points:

1. Yes, in RMT terms that's a recent email with responses awaiting conclusion, discussion or anything. The crux is what consitutes a compatibility breaking change (e.g. Graceful and non-harmful failure of an experimental implementation does not IMHO). And what is the list of these such changes? (Which I will turn to Dave's link for)

2. Yes, a disclosed design change. Again the critical thing is the comatibility (and the design logic). As far as I can tell there's just one fatal change (long to byte - for which I have not found any explanation). Otherwise and failures are graceful and happily compatible as said in the messages that were kindly linked by Vincent. I haven't had the opportunity to follow up the namespace specifics, but as Magnus originally pointed out, leaving 'example.com' was a goof - and thus obviously experimental FLUTE recievers are experienced at ignoring that part of the XML.

For my part, I'll have a look at Dave's material in the near future and work with Jani to enhance the security provisions of FLUTE-SDP. Please point out if any of the other loose threads are pending a response from me.

Cheers, Rod.



----- Original message -----
> 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
>
>
>
>
>
>
>
> best regards,
>
>
>
> Brian Adamson
> [e-mail]<mailto:[e-mail]>
>
>
>
>
>
>
>
>
> 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
>
> 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
>
> * The answer from Magnus, with the 3GPP schema:
> 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
>
> That's for the history. The question now is what do we want
> to do?
>
>  Vincent
>
>
> > _______________________________________________
> > Rmt mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/rmt
> >
>
>
> > --
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > ----------------------------------------------------------------------
> > Ericsson AB                              | Phone  [phone]
> > Färögatan 6                              | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]<mailto:[e-mail]>
> > ----------------------------------------------------------------------
> > _______________________________________________
> > Rmt mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/rmt
> >
> >
>
>

<Attachment>  ATT00001..txt