Re: About Flute-revised open points
"David Harrington" <[email protected]> Wed, 13 Apr 2011 09:47:09 +0200
| Newsgroups | gmane.ietf.rmt |
|---|---|
| Message-ID | <C32238CBE79A491CAF9E23E5C5F1C8AC@davidPC> |
This is a multi-part message in MIME format. --===============4379615879555723089== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01CBF9BF.D1EFBB10" This is a multi-part message in MIME format. ------=_NextPart_000_00F0_01CBF9BF.D1EFBB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 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# =20 dbh =20 =20 _____ =20 From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Saturday, April 09, 2011 1:30 PM To: [email protected]; [email protected] Cc: [email protected] 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.=20 ----- Original message -----=20 > Thanks for Dave's link, I'll check this out next week.=20 >=20 > Meanwhile...=20 >=20 > 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=20 > threads that have been running a long while. Mostly we simply haven't=20 > bothered to get them resolved. For each of those years. (And I must also=20 > personally appologise for not tracking LCT and ALC at each revision so=20 > as catch the greater than agreed impact on FLUTE before they went=20 > standards track. Of course we may well have had the same end result, > just without the percenption of last minute issues). In spite of=20 > originally agreeing to maintain compatability where feasible, we're now=20 > stuck with some long term undiscolsed design decisions. Practically, we=20 > may have to embrace the unknown, but it's reasonable engineering to=20 > point out that our process has these black spots, whether communicated=20 > as last minute jitters or otherwise :)=20 >=20 > So as Magnus earlier suggested, I feel we need to be pragmatic with what=20 > 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=20 > 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=20 > would be grateful to hear that this is so).=20 >=20 > Meanwhile, to Vincent's couple of points:=20 >=20 > 1. Yes, in RMT terms that's a recent email with responses awaiting=20 > conclusion, discussion or anything. The crux is what consitutes a=20 > compatibility breaking change (e.g. Graceful and non-harmful failure of=20 > an experimental implementation does not IMHO). And what is the list of=20 > these such changes? (Which I will turn to Dave's link for)=20 >=20 > 2. Yes, a disclosed design change. Again the critical thing is the=20 > comatibility (and the design logic). As far as I can tell there's just=20 > one fatal change (long to byte - for which I have not found any=20 > explanation). Otherwise and failures are graceful and happily compatible=20 > as said in the messages that were kindly linked by Vincent. I haven't=20 > had the opportunity to follow up the namespace specifics, but as Magnus=20 > originally pointed out, leaving 'example.com' was a goof - and thus=20 > obviously experimental FLUTE recievers are experienced at ignoring that=20 > part of the XML.=20 >=20 > For my part, I'll have a look at Dave's material in the near future and=20 > work with Jani to enhance the security provisions of FLUTE-SDP. Please=20 > point out if any of the other loose threads are pending a response from=20 > me.=20 >=20 > Cheers, Rod.=20 >=20 >=20 >=20 > ----- Original message -----=20 > > I agree with Magnus here. I hope that Rod can review Vincent's=20 > > historical summary of the issues and provide consensus or comments to=20 > > help us resolve this. =20 > >=20 > >=20 > > Additionally, here is a link to the message that summarizes the=20 > > backwards incompatibility issues identified by Dave Harrington's AD=20 > > review of FLUTE:=20 > >=20 > >=20 > > http://www.ietf.org/mail-archive/web/rmt/current/msg01434.html=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > best regards,=20 > >=20 > >=20 > >=20 > > Brian Adamson=20 > > [email protected]=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > On Mar 31, 2011, at 11:01 AM, Magnus Westerlund wrote:=20 > >=20 > > > Hi,=20 > > >=20 > > > I think this is a good example of what I expect in this discussion.=20 > I=20 > > > think that a number of the changes has good reasons to their=20 > changes=20 > > > and=20 > > > that we are not likely to reverse the WG documents text. For the > > > record=20 > > > I don't really remember the reasons for the designs in this schema=20 > and=20 > > > what the underlying 3GPP reasons are.=20 > > >=20 > > > I have no rapid need for an updated flute so I am willing to let > this=20 > > > discussion go on for a while. Especially letting people try to dig=20 > up=20 > > > any more motivations. But the fact is that the WG spent 5+ years in=20 > > > producing this document. There are reasons why it looks like it=20 > does.=20 > > > Reversing that decision at the last minute seems dangerous and=20 > likely=20 > > > to=20 > > > cause more issues than actually bumping the version number.=20 > > >=20 > > > Cheers=20 > > >=20 > > > Magnus=20 > > >=20 > >=20 > >=20 > > Everybody,=20 > >=20 > > A follow-up to our long discussion during the meeting:=20 > >=20 > > 1- Concerning Flute version, the email that convinced=20 > > me of the necessity to move to version 2 is the=20 > > following one, from Mike, sent on Feb 7, 2011:=20 > >=20 > > http://www.ietf.org/mail-archive/web/rmt/current/msg01511.html=20 > >=20 > > 2- Concerning XML extensibility, after searching a little=20 > > bit better in my archives, I finally found the initial reasons.=20 > > See the following 3 emails (from June 2005):=20 > >=20 > > * The initial email (from Rod) explaining why 3GPP proposed=20 > > another schema:=20 > > http://www.ietf.org/mail-archive/web/rmt/current/msg00404.html=20 > >=20 > > * The answer from Magnus, with the 3GPP schema:=20 > > http://www.ietf.org/mail-archive/web/rmt/current/msg00477.html=20 > >=20 > > * Finally Rod's promise (yes!!!) to include this schema:=20 > > http://www.ietf.org/mail-archive/web/rmt/current/msg00482.html=20 > >=20 > > That's for the history. The question now is what do we want=20 > > to do?=20 > >=20 > > Vincent=20 > >=20 > >=20 > > > _______________________________________________=20 > > > Rmt mailing list=20 > > > [email protected]=20 > > > https://www.ietf.org/mailman/listinfo/rmt=20 > > >=20 > >=20 > >=20 > > > --=20 > > >=20 > > > Magnus Westerlund=20 > > >=20 > > >=20 > ---------------------------------------------------------------------- > > > Multimedia Technologies, Ericsson Research EAB/TVM=20 > > >=20 > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 10 7148287=20 > > > F=E4r=F6gatan 6 | Mobile +46 73 0949079=20 > > > SE-164 80 Stockholm, Sweden| mailto: [email protected]=20 > > >=20 > ---------------------------------------------------------------------- > > > _______________________________________________=20 > > > Rmt mailing list=20 > > > [email protected]=20 > > > https://www.ietf.org/mailman/listinfo/rmt=20 > > >=20 > > >=20 > >=20 > >=20 >=20 > <Attachment> ATT00001..txt=20 >=20 >=20 >=20 <Attachment> ATT00001..txt=20 ------=_NextPart_000_00F0_01CBF9BF.D1EFBB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" = "http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd"> <HTML><HEAD><TITLE></TITLE> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.7600.16722"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D230022807-13042011><FONT = color=3D#0000ff=20 size=3D2 face=3DArial>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D230022807-13042011><FONT = color=3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D230022807-13042011><FONT = color=3D#0000ff=20 size=3D2 face=3DArial>I think it makes no difference whether it is = byte-to-long or=20 long-to-byte.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D230022807-13042011></SPAN><SPAN=20 class=3D230022807-13042011><FONT color=3D#0000ff size=3D2 = face=3DArial>If one=20 implementation sends a long value to an implementation that supports = only byte,=20 they do not interoperate.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D230022807-13042011><FONT = color=3D#0000ff=20 size=3D2 face=3DArial>Both ends need to agree or you lose=20 interoperability.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D230022807-13042011><FONT = color=3D#0000ff=20 size=3D2 face=3DArial>If the specs differ, then you need a mechanism to = determine=20 which set of rules are followed - a version#</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D230022807-13042011><FONT = color=3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D230022807-13042011><FONT = color=3D#0000ff=20 size=3D2 face=3DArial>dbh</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D230022807-13042011><FONT = color=3D#0000ff=20 size=3D2 face=3DArial> </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D230022807-13042011> </SPAN></DIV> <DIV dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> </DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D2 face=3DTahoma><B>From:</B>=20 [email protected] [mailto:[email protected]] <B>On Behalf Of=20 </B>[email protected]<BR><B>Sent:</B> Saturday, April 09, 2011 1:30=20 PM<BR><B>To:</B> [email protected];=20 [email protected]<BR><B>Cc:</B> = [email protected]<BR><B>Subject:</B> Re:=20 [Rmt] About Flute-revised open points<BR></FONT><BR></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: = 5px; MARGIN-RIGHT: 0px"=20 dir=3Dltr> <DIV></DIV> <P>Error in previous message: long to byte change in xml is fine. = (Other other=20 way round could have been fatal). Cheers, Rod. <BR><BR>----- Original = message=20 ----- <BR>> Thanks for Dave's link, I'll check this out next week. = <BR>>=20 <BR>> Meanwhile... <BR>> <BR>> It seems like I am being = painted a=20 little like the outlier with last <BR>> minute jitters. As Vincent = kindly=20 pointed out there are a few unresolved <BR>> threads that have been = running=20 a long while. Mostly we simply haven't <BR>> bothered to get them = resolved.=20 For each of those years. (And I must also <BR>> personally = appologise for=20 not tracking LCT and ALC at each revision so <BR>> as catch the = greater=20 than agreed impact on FLUTE before they went <BR>> standards track. = Of=20 course we may well have had the same end result, <BR>> just without = the=20 percenption of last minute issues). In spite of <BR>> originally = agreeing=20 to maintain compatability where feasible, we're now <BR>> stuck = with some=20 long term undiscolsed design decisions. Practically, we <BR>> may = have to=20 embrace the unknown, but it's reasonable engineering to <BR>> point = out=20 that our process has these black spots, whether communicated <BR>> = as last=20 minute jitters or otherwise :) <BR>> <BR>> So as Magnus earlier=20 suggested, I feel we need to be pragmatic with what <BR>> we have. = At the=20 same time I feel we need a bit of design explanation <BR>> where it = exists=20 as the rmt mailing list has been a close approximation <BR>> to = silent on=20 these issues for most for this bis/revised era. (E.g. I <BR>> hope = I've=20 overlooked the discussion or notification of non-backwards <BR>> = comatible=20 changes prior to an updated ID appearing for LCT and ALC, and <BR>> = would=20 be grateful to hear that this is so). <BR>> <BR>> Meanwhile, to=20 Vincent's couple of points: <BR>> <BR>> 1. Yes, in RMT terms = that's a=20 recent email with responses awaiting <BR>> conclusion, discussion = or=20 anything. The crux is what consitutes a <BR>> compatibility = breaking change=20 (e.g. Graceful and non-harmful failure of <BR>> an experimental=20 implementation does not IMHO). And what is the list of <BR>> these = such=20 changes? (Which I will turn to Dave's link for) <BR>> <BR>> 2. = Yes, a=20 disclosed design change. Again the critical thing is the <BR>> = comatibility=20 (and the design logic). As far as I can tell there's just <BR>> one = fatal=20 change (long to byte - for which I have not found any <BR>> = explanation).=20 Otherwise and failures are graceful and happily compatible <BR>> as = said in=20 the messages that were kindly linked by Vincent. I haven't <BR>> = had the=20 opportunity to follow up the namespace specifics, but as Magnus = <BR>>=20 originally pointed out, leaving 'example.com' was a goof - and thus = <BR>>=20 obviously experimental FLUTE recievers are experienced at ignoring = that=20 <BR>> part of the XML. <BR>> <BR>> For my part, I'll have a = look at=20 Dave's material in the near future and <BR>> work with Jani to = enhance the=20 security provisions of FLUTE-SDP. Please <BR>> point out if any of = the=20 other loose threads are pending a response from <BR>> me. <BR>> = <BR>>=20 Cheers, Rod. <BR>> <BR>> <BR>> <BR>> ----- Original = message -----=20 <BR>> > I agree with Magnus here. = I=20 hope that Rod can review Vincent's <BR>> > historical summary of = the=20 issues and provide consensus or comments to <BR>> > help us = resolve=20 this. <BR>> > <BR>> > <BR>> >=20 Additionally, here is a link to the message that summarizes the = <BR>> >=20 backwards incompatibility issues identified by Dave Harrington's AD = <BR>>=20 > review of FLUTE: <BR>> > <BR>> > <BR>> > <A=20 = href=3D"http://www.ietf.org/mail-archive/web/rmt/current/msg01434.html">h= ttp://www.ietf.org/mail-archive/web/rmt/current/msg01434.html</A>=20 <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > = <BR>>=20 > <BR>> > <BR>> > best regards, <BR>> > <BR>> = >=20 <BR>> > <BR>> > Brian Adamson <BR>> > <A=20 = href=3D"mailto:[email protected]">[email protected]</A>= =20 <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > = <BR>>=20 > <BR>> > <BR>> > <BR>> > On Mar 31, 2011, at = 11:01 AM,=20 Magnus Westerlund wrote: <BR>> > <BR>> > > Hi, <BR>> = >=20 > <BR>> > > I think this is a good example of what I = expect in=20 this discussion. <BR>> I <BR>> > > think that a number of = the=20 changes has good reasons to their <BR>> changes <BR>> > > = and=20 <BR>> > > that we are not likely to reverse the WG documents = text.=20 For the <BR>> > > record <BR>> > > I don't really = remember=20 the reasons for the designs in this schema <BR>> and <BR>> > = >=20 what the underlying 3GPP reasons are. <BR>> > > <BR>> > = > I=20 have no rapid need for an updated flute so I am willing to let = <BR>> this=20 <BR>> > > discussion go on for a while. Especially letting = people try=20 to dig <BR>> up <BR>> > > any more motivations. But the = fact is=20 that the WG spent 5+ years in <BR>> > > producing this = document.=20 There are reasons why it looks like it <BR>> does. <BR>> > = >=20 Reversing that decision at the last minute seems dangerous and = <BR>> likely=20 <BR>> > > to <BR>> > > cause more issues than = actually=20 bumping the version number. <BR>> > > <BR>> > > = Cheers=20 <BR>> > > <BR>> > > Magnus <BR>> > > = <BR>> >=20 <BR>> > <BR>> > Everybody, <BR>> > <BR>> > A = follow-up=20 to our long discussion during the meeting: <BR>> > <BR>> > = 1-=20 Concerning Flute version, the email that convinced <BR>> > me of = the=20 necessity to move to version 2 is the <BR>> > following one, = from Mike,=20 sent on Feb 7, 2011: <BR>> > <BR>> > <A=20 = href=3D"http://www.ietf.org/mail-archive/web/rmt/current/msg01511.html">h= ttp://www.ietf.org/mail-archive/web/rmt/current/msg01511.html</A>=20 <BR>> > <BR>> > 2- Concerning XML extensibility, after = searching a=20 little <BR>> > bit better in my archives, I finally found the = initial=20 reasons. <BR>> > See the following 3 emails (from June 2005): = <BR>>=20 > <BR>> > * The initial email (from Rod) explaining why 3GPP = proposed=20 <BR>> > another schema: <BR>> > <A=20 = href=3D"http://www.ietf.org/mail-archive/web/rmt/current/msg00404.html">h= ttp://www.ietf.org/mail-archive/web/rmt/current/msg00404.html</A>=20 <BR>> > <BR>> > * The answer from Magnus, with the 3GPP = schema:=20 <BR>> > <A=20 = href=3D"http://www.ietf.org/mail-archive/web/rmt/current/msg00477.html">h= ttp://www.ietf.org/mail-archive/web/rmt/current/msg00477.html</A>=20 <BR>> > <BR>> > * Finally Rod's promise (yes!!!) to = include this=20 schema: <BR>> > <A=20 = href=3D"http://www.ietf.org/mail-archive/web/rmt/current/msg00482.html">h= ttp://www.ietf.org/mail-archive/web/rmt/current/msg00482.html</A>=20 <BR>> > <BR>> > That's for the history. The question now = is what=20 do we want <BR>> > to do? <BR>> > <BR>> > Vincent = <BR>>=20 > <BR>> > <BR>> > >=20 _______________________________________________ <BR>> > > Rmt = mailing=20 list <BR>> > > <A = href=3D"mailto:[email protected]">[email protected]</A>=20 <BR>> > > <A=20 = href=3D"https://www.ietf.org/mailman/listinfo/rmt">https://www.ietf.org/m= ailman/listinfo/rmt</A>=20 <BR>> > > <BR>> > <BR>> > <BR>> > > -- = <BR>>=20 > > <BR>> > > Magnus Westerlund <BR>> > > = <BR>>=20 > > <BR>>=20 ---------------------------------------------------------------------- = <BR>> > > Multimedia Technologies, Ericsson Research EAB/TVM = <BR>>=20 > > <BR>>=20 ---------------------------------------------------------------------- = <BR>> > > Ericsson AB = =20 = =20 = |=20 Phone +46 10 7148287 <BR>> > > F=E4r=F6gatan 6 = =20 = =20 = =20 | Mobile +46 73 0949079 <BR>> > > = SE-164=20 80 Stockholm, Sweden| mailto: <A=20 = href=3D"mailto:[email protected]">magnus.westerlund@ericsson= .com</A>=20 <BR>> > > <BR>>=20 ---------------------------------------------------------------------- = <BR>> > > _______________________________________________ = <BR>>=20 > > Rmt mailing list <BR>> > > <A=20 href=3D"mailto:[email protected]">[email protected]</A> <BR>> > > <A=20 = href=3D"https://www.ietf.org/mailman/listinfo/rmt">https://www.ietf.org/m= ailman/listinfo/rmt</A>=20 <BR>> > > <BR>> > > <BR>> > <BR>> > = <BR>>=20 <BR>> <Attachment> ATT00001..txt <BR>> <BR>> = <BR>>=20 <BR><BR><Attachment> ATT00001..txt=20 <BR><BR></P></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_00F0_01CBF9BF.D1EFBB10-- --===============4379615879555723089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rmt mailing list [email protected] https://www.ietf.org/mailman/listinfo/rmt --===============4379615879555723089==--