Re: [Rmt] About Flute-revised open points

[<[e-mail]>]

Error in previous message: long to byte change in xml is fine. (Other other way round could have been fatal). Cheers, Rod.

----- Original message -----
> 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
>
>
>

<Attachment>  ATT00001..txt