[core] On Content Transcode

Yusuke DOI <yusuke.doi@toshiba.co.jp> Wed, 23 July 2014 21:49 UTC

Return-Path: <yusuke.doi@toshiba.co.jp>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B69521B2827 for <core@ietfa.amsl.com>; Wed, 23 Jul 2014 14:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.393
X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yYKduZeHkl5i for <core@ietfa.amsl.com>; Wed, 23 Jul 2014 14:49:17 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D813A1A030B for <core@ietf.org>; Wed, 23 Jul 2014 14:49:16 -0700 (PDT)
Received: from arc11.toshiba.co.jp ([]) by imx12.toshiba.co.jp with ESMTP id s6NLnFCn028455 for <core@ietf.org>; Thu, 24 Jul 2014 06:49:15 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id s6NLnFQc018241 for core@ietf.org; Thu, 24 Jul 2014 06:49:15 +0900 (JST)
Received: from ovp11.toshiba.co.jp [] by arc11.toshiba.co.jp with ESMTP id GAA18240; Thu, 24 Jul 2014 06:49:15 +0900
Received: from mx12.toshiba.co.jp (localhost []) by ovp11.toshiba.co.jp with ESMTP id s6NLnFsH000100 for <core@ietf.org>; Thu, 24 Jul 2014 06:49:15 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6NLnELO002987; Thu, 24 Jul 2014 06:49:14 +0900 (JST)
Received: from [] (ivpn-1-148.mobile.toshiba.co.jp []) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 5335897D84 for <core@ietf.org>; Thu, 24 Jul 2014 06:49:13 +0900 (JST)
Message-ID: <53D02DAD.3070005@toshiba.co.jp>
Date: Thu, 24 Jul 2014 06:48:29 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: core@ietf.org
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/core/cRzM5MQxUQO4Wbtm_6BGyZySnR8
Subject: [core] On Content Transcode
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jul 2014 21:49:19 -0000


With regards to content transcoding of core-http mapping, let me
describe (expected) use case on SEP2 (now IEEEP2030.5).



Unlike CBOR, EXI does not have one-to-one mapping with XML instance. EXI
can encode XML document in various ways: schemaless, schema-informed,
bunch of options, profiles... etc. In particular, schema-informed
encoding make use of a XML schema as a grammar. Thus, even a slightest
difference in the schema may break interoperability in EXI. So,
something like footype+exi is not sufficient if the content is expected
to be encoded in schema-informed EXI. (It is reasonable to use
schemaless EXI in that case).

To deal with the issue, SEP2 defined two media types: sep-exi and sep+xml.


So, if some node try to speak SEP2 over CoAP (though, SEP2 spec is
defined in HTTP), a trancoder should be aware of the schema as part of
media type.


What I'd appreciate if the document can mention such specific case are
out of the scope of the document and the implementor should be
responsible and be aware of the side-effect (may not specific to EXI
cases). In particular, schema-informed EXI will be mapped to
application/exi without any schema information OR
application/octet-stream. In-band metadata is lost in the case and the
proxy should be aware of the metadata required to manage the metadata
(schema, or any other application-specific data).

If I need to implement a transcoding proxy (though I have no plan to
make it by myself), I'd add per-path(regexp) configuration of
transcoding rule with such metadata.