Re: [Rmt] About Flute-revised open points

["David Harrington" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Saturday, April 09, 2011 1:30 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
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 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > best regards, 
> > 
> > 
> > 
> > Brian Adamson 
> > [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] 
> > > 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] 
> > > 
>
----------------------------------------------------------------------

> > > _______________________________________________ 
> > > Rmt mailing list 
> > > [e-mail] 
> > > https://www.ietf.org/mailman/listinfo/rmt 
> > > 
> > > 
> > 
> > 
> 
> <Attachment>  ATT00001..txt 
> 
> 
> 

<Attachment>  ATT00001..txt