[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [61.202.160.132]) (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 ([133.199.90.127]) 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 [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id GAA18240; Thu, 24 Jul 2014 06:49:15 +0900
Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) 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 [133.199.16.148] (ivpn-1-148.mobile.toshiba.co.jp [133.199.16.148]) 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
Hi, With regards to content transcoding of core-http mapping, let me describe (expected) use case on SEP2 (now IEEEP2030.5). http://tools.ietf.org/html/draft-ietf-core-http-mapping-04#section-6.3.3 [Background] 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. http://www.iana.org/assignments/media-types/application/sep-exi http://www.iana.org/assignments/media-types/application/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. Regards, Yusuke
- [core] On Content Transcode Yusuke DOI