Subject: [core] Content-Type Parameter

From: Yusuke DOI <[email-masked]>
Date: Mon, 15 Oct 2012 16:06:37 +0900

Dear all,

I have revised parameter option proposal (Content Type Parameter) and
re-posted it as doi-core-parameter-option.

> Filename:	 draft-doi-core-parameter-option
> Revision:	 01
> Title:		 CoAP Content-Type Parameter Option
> Creation date:	 2012-10-15
> WG ID:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-doi-core-parameter-option-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-doi-core-parameter-option
> Htmlized:        http://tools.ietf.org/html/draft-doi-core-parameter-option-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-doi-core-parameter-option-01

My intention of this proposal is to make use of (multi-schema
schema-informed) EXI in CoAP network. Efficient communication using EXI
requires schema negotiation(*). But the proposal itself is neutral to
its content-type and can be used in various ways.

*) See also: draft-doi-exi-messaging-requirements
   http://tools.ietf.org/html/draft-doi-exi-messaging-requirements-00

FAQ:

Q) Why don't use a content-type ID for a content type with parameter?
A) Because an ID cannot represent semantics in parameter. For example,
an application may want to keep backward compatibility between minor
revisions but may not have it between major revisions. A single ID
cannot represent (major).(minor) version of content. An UTF-8 String (or
any other 8-bit transparent) parameter can transfer such semantics and
be useful for client-server capability negotiation.

Regards,

// Yusuke DOI <[email-masked]>