[Rmt] EXP2ST: FLUTE FDT extension by element should be allowed

Rod.Walsh@nokia.com Mon, 27 June 2005 13:33 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmtjw-0003Q0-6L; Mon, 27 Jun 2005 09:33:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmtjv-0003Pt-60 for rmt@megatron.ietf.org; Mon, 27 Jun 2005 09:33:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20709 for <rmt@ietf.org>; Mon, 27 Jun 2005 09:33:29 -0400 (EDT)
From: Rod.Walsh@nokia.com
Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmu93-0007C9-La for rmt@ietf.org; Mon, 27 Jun 2005 09:59:31 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5RDUZmQ027897 for <rmt@ietf.org>; Mon, 27 Jun 2005 16:30:38 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jun 2005 16:33:23 +0300
Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jun 2005 16:33:23 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Jun 2005 16:33:22 +0300
Message-ID: <7222D14EF47E0840AD88EC7BCBAD8513AF6845@trebe101.NOE.Nokia.com>
Thread-Topic: [Rmt] EXP2ST: FLUTE & ALC - "payload id" as part fo payloadnotheader
Thread-Index: AcV4L2R+eg87wLwQRxuvKk4fbNOBSAC2V5twAAOI70A=
To: rmt@ietf.org
X-OriginalArrivalTime: 27 Jun 2005 13:33:23.0343 (UTC) FILETIME=[CA4F69F0:01C57B1C]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: quoted-printable
Subject: [Rmt] EXP2ST: FLUTE FDT extension by element should be allowed
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
Sender: rmt-bounces@ietf.org
Errors-To: rmt-bounces@ietf.org

Hi All

As promised, here's another point to consider in the standards track progress of FLUTE...

The FDT (XML) schema is intentionally open to extension by both element and attributes. On oversight of the original creation was that "<xs:anyAttribute processContents="skip"/>" allows extension by attribute but not by element.

Naturally this has not interfered with any interoperability based on the specification. However, when using FLUTE as the basis of an enhanced application protocol this issue has been discovered.

Both the MBMS (3GPP/cellular multicast) (http://www.3gpp.org/ftp/Specs/html-info/26346.htm §7.2.10) and RMT/individual Object Aggregation I-D (http://www.ietf.org/internet-drafts/draft-neumann-rmt-flute-file-aggregation-00.txt, §4.3) have already encountered the need to extend by element, and thus extend the FDT in this way. [For those interested: IPDC/DVB-H and OMA work (also using FLUTE) has taken this into account in contributions].

Hence, I propose that we repair the FDT schema. The fix is to introduce "xs:any processContents="skip"" into both "FDT-Instance" and "File" elements, and thus any extension processes (elements) will be skipped by an non-enhanced FLUTE client whilst leaving the rest of the FDT Instance valid and usable by the client according to the schema. i.e. add this twice:

   <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

This is fully compatible server side. However, an experimental client encountering an element-extended FDT ought to reject it as not adhering to the experimental schema. Basically this would be "graceful failure". Then the difference between an experimental and standards track FLUTE client would be that the latter could use the remainder of an FDT Instance's data, whereas the former should reject all data of an FDT Instance including an element-extension. Given that FDT extensions are for specific enhancements and applications it would be unlikely that this will cause any problems, even if there were already a large number of deployed experimental FLUTE clients. (Please shout up if you have such a large deployment - it's good to know in any case :)

So I am happy that the change is not going to break anything in practice - even to the experimental FLUTE. And the change will also simplify future extension and inter-working with the broadcast/datacast/wireless standards work.

Comments, experiences, issues are welcome.

Cheers, Rod.

_______________________________________________
Rmt mailing list
Rmt@ietf.org
https://www1.ietf.org/mailman/listinfo/rmt