In theory, with the long to byte change problem may only occur with an experimental sender sending a >255 value to a revised receiver parsing only 8bit values. However, you would (generally) expect a revised receiver to reject the XML based on the namespace, or else understand that it is not a 'pure revised' receiver and adapt.

In practice the fec value in that field is spec'ed at 8bit and any number above 255 would not be a registered value, and so would be rejected by an experimental receiver too. (At the value-mapping stage rather than the XML parsing stage). I.e. An experimental sender will not pollute that field with values greater than would fit byte regardless of whether the receiver XML parser admits longs or only bytes.

Hence my suggestion that this "is fine". (Even if unaware why the change happened, I expect the design thinking took this "no harm in practice" aspect into account).

Did I make an error?

Cheers, Rod.



On 13.4.2011, at 10.47, "ext David Harrington" <ietfdbh@comcast.net<mailto:ietfdbh@comcast.net>> wrote:

Hi,

I think it makes no difference whether it is byte-to-long or long-to-byte.
If one implementation sends a long value to an implementation that supports only byte, they do not interoperate.
Both ends need to agree or you lose interoperability.
If the specs differ, then you need a mechanism to determine which set of rules are followed - a version#

dbh


________________________________
From: rmt-bounces@ietf.org<mailto:rmt-bounces@ietf.org> [mailto:rmt-bounces@ietf.org] On Behalf Of Rod.Walsh@nokia.com<mailto:Rod.Walsh@nokia.com>
Sent: Saturday, April 09, 2011 1:30 PM
To: brian.adamson@nrl.navy.mil; magnus.westerlund@ericsson.com
Cc: rmt@ietf.org
Subject: Re: [Rmt] About Flute-revised open points


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> http://www.ietf.org/mail-archive/web/rmt/current/msg01434.html
> >
> >
> >
> >
> >
> >
> >
> > best regards,
> >
> >
> >
> > Brian Adamson
> > <mailto:brian.adamson@nrl.navy.mil> brian.adamson@nrl.navy.mil<mailto:brian.adamson@nrl.navy.mil>
> >
> >
> >
> >
> >
> >
> >
> >
> > 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:Rmt@ietf.org> Rmt@ietf.org<mailto:Rmt@ietf.org>
> > > <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:magnus.westerlund@ericsson.com> magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>
> > >
> ----------------------------------------------------------------------
> > > _______________________________________________
> > > Rmt mailing list
> > > <mailto:Rmt@ietf.org> Rmt@ietf.org<mailto:Rmt@ietf.org>
> > > <https://www.ietf.org/mailman/listinfo/rmt> https://www.ietf.org/mailman/listinfo/rmt
> > >
> > >
> >
> >
>
> <Attachment>  ATT00001..txt
>
>
>

<Attachment>  ATT00001..txt