Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 06:41:40 -0600

Let say a that there were two different formats defined and called sep1 and sep2 - they both happen to be EXI. 

A client supporting both and would prefer to get sep2, but it would be willing to get sep1 is the server did not support sep2. 

have a media type of application/sep1+exi and application/sep2+exi allow the client to say it would prefer sep2 but take sep1, and the server can return sep2 if it supports that and sep1 if it does not. 

If we just used application/exi for both sep1 and sep2, this would not work. I do understand that the actually data transferred may also have information inside the body that allows an exi parser to figure out if it is sep1 or sep2. 

Identifying the schema and such in the EXI does add significant sizes to the EXI in some cases.

On Mar 6, 2012, at 6:39 AM, Guido Moritz wrote:

> I am still the opinion that this is way too much semantics that is tried to
> push into the Media Type field. EXI has its own mechanisms/header field for
> this (i.e. EXI header including SchemaID field). 
> 
> To get a comprehensive solution, also all the other options of the EXI
> header (alignment, compression, strict, preserve...) must be included in the
> Media Type definition.
> 
> I still do not get the point, why the way EXI handles these by internal
> options is not sufficient? The only thing to carry in the Media Type is that
> whether it is EXI or not. Everything beyond that, i.e. the specific EXI
> mode, should be expressed by the existing EXI options. 
> 
> All these definitions are application/protocol specific. Sure, it must be
> defined somewhere. But I would say define a new Media Type for each possible
> combination of protocol schemas, application specific schemas and schema
> versions is not an appropriate solution. 
> 
> Maybe some realistic examples of +exi Media Types to be defined would help
> to generate new input for this discussion? 
> 
> Guido
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Zach Shelby [mailto:[email-masked]]
>> Gesendet: Dienstag, 6. März 2012 14:22
>> An: Guido Moritz
>> Cc: 'core WG'
>> Betreff: Re: AW: [core] Fwd: New Version Notification for
> draft-shelby-exi-
>> registration-00.txt
>> 
>> Hi,
>> 
>> On Mar 6, 2012, at 1:44 PM, Guido Moritz wrote:
>> 
>>> Hi Zach,
>>> 
>>> I have read the draft and also stumbled through the discussion on the
> APPS
>>> WG list. You describe two scenarios for the usage of +exi. I would
> mainly
>>> pick up the second:
>> 
>> The idea was that the use of +exi is recommended for both bullet points.
> The
>> point of that section is just to guide readers to where the use of +exi is
>> appropriate compared to the existing exi content encoding or
> application/exi
>> approaches.
>> 
>>> 
>>>  o  Use EXI as a native encoding (without the use of XML as an
>>>     interemediate) in Strict Schema-informed mode, and the base Media
>>>     Type indicates to the protocol the Schema that was used to produce
>>>     the EXI grammar.
>>> 
>>> The major intention of this use case is to indicate the used schemas
> that
>>> are required to generate the appropriate EXI grammar.
>> 
>> Not only the used schema, but also the underlying semantics of what is
>> contained in the schema.
>> 
>>> To come up with an
>>> example I would use application/soap. But there is no clear relationship
>>> which schemas have to be included if application/soap+exi is used. Is it
>>> only the SOAP schema? Which version of SOAP? Is it also the
> WS-Addressing
>>> schema? Which version of WS-Addressing? What WS-* or application
> specific
>>> schemas else?!
>> 
>> The purpose of this draft is to define the registration guidelines for
> someone
>> registering an application/foo+exi media type. So it would be up to the
> person
>> requesting that media type to describe what schemas are used and how to
>> interpret the Schema ID field (in case multiple schemas are possible
> e.g.). So if
>> you are registering the media type application/soap+exi then you need to
>> define those details.
>> 
>>> Thus, it would be required to define for each Media Type very strict
> which
>>> schemas and versions are required and which not.
>> 
>> Yes, each media type registration needs to define these things. This is
> needed
>> to ensure interoperability. Is that a bad thing?
>> 
>>> The approach described in
>>> the draft is too generic. I would argue this definition is not in the
>>> responsibility of the IETF, but must be e.g. part of the W3C EXI WG.
>> 
>> This draft is just defining the +exi suffix registration procedure, which
> should be
>> generic. In my understanding the iETF is the right place to do it.
>> 
>> Zach
>> 
>> 
>>> 
>>> My 2 cents,
>>> Guido
>>> 
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: [email-masked] [mailto:[email-masked]] Im Auftrag
> von
>>>> Zach Shelby
>>>> Gesendet: Montag, 5. März 2012 10:51
>>>> An: core WG
>>>> Betreff: [core] Fwd: New Version Notification for
>>> draft-shelby-exi-registration-
>>>> 00.txt
>>>> 
>>>> Here is a draft I wrote up describing a +exi Media Type suffix, and
> which
>>> we
>>>> have discussed over on the apps-discuss mailing list. Soliciting any
>>> comments
>>>> from CoRE as well.
>>>> 
>>>> http://www.ietf.org/id/draft-shelby-exi-registration-00.txt
>>>> 
>>>> Zach
>>>> 
>>>> Begin forwarded message:
>>>> 
>>>>> From: [email-masked]
>>>>> Date: March 5, 2012 11:43:30 AM GMT+02:00
>>>>> To: [email-masked]
>>>>> Subject: New Version Notification for
>>> draft-shelby-exi-registration-00.txt
>>>>> 
>>>>> A new version of I-D, draft-shelby-exi-registration-00.txt has been
>>> successfully
>>>> submitted by Zach Shelby and posted to the IETF repository.
>>>>> 
>>>>> Filename:	 draft-shelby-exi-registration
>>>>> Revision:	 00
>>>>> Title:		 The +exi Media Type Suffix
>>>>> Creation date:	 2012-03-05
>>>>> WG ID:		 Individual Submission
>>>>> Number of pages: 5
>>>>> 
>>>>> Abstract:
>>>>> Efficient XML Interchange (EXI) is an XML representation technique
>>>>> specified by the W3C to provie a binary alternative to the standard
>>>>> text XML representation.  This document defines a new Structure
>>>>> Syntax Suffix &quot;+exi&quot; for use in a specific class of
>>> protocols, where
>>>>> &quot;exi&quot; content-type encoding or the generic
>>>> &quot;application/exi&quot; Media
>>>>> Type are not applicable.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> The IETF Secretariat
>>>> 
>>>> --
>>>> Zach Shelby, Chief Nerd, Sensinode Ltd.
>>>> http://www.sensinode.com
>>>> http://zachshelby.org  - My blog "On the Internet of Things"
>>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
>>>> Mobile: +358 40 7796297
>>>> 
>>>> _______________________________________________
>>>> core mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/core
>>> 
>> 
>> --
>> Zach Shelby, Chief Nerd, Sensinode Ltd.
>> http://www.sensinode.com
>> http://zachshelby.org  - My blog "On the Internet of Things"
>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
>> Mobile: +358 40 7796297
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Skip Ashton <[email-masked]>
Date: Fri, 20 Apr 2012 12:48:03 +0000

The problem we were discussing in SE2 this week is it is not enough to say
SE2 since we have to expect there will be SE2.1 and SE 2.2 etc.  So it is
not enough for a device to say it does SE2, we would also need schema
negotiation between devices.  Have people thought about how to do this?

Skip

On 4/20/12 8:41 AM, "Cullen Jennings" <[email-masked]> wrote:

>A client supporting both and would prefer to get sep2, but it would be
>willing to get sep1 is the server did not support sep2.
>
>have a media type of application/sep1+exi and application/sep2+exi allow
>the client to say it would prefer sep2 but take sep1, and the server can
>return sep2 if it supports that and sep1 if it does not.
>
>If we just used application/exi for both sep1 and sep2, this would not
>work. I do understand that the actually data transferred may also have
>information inside the body that allows an exi parser to figure out if it
>is sep1 or sep2. 
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 07:21:28 -0600

Yes, you would register a new media type for every different schema. 

So perhaps my example should have been 

application/se2dot1+exi

---

From: [email-masked]
Date: Fri, 20 Apr 2012 15:33:54 +0200

>So perhaps my example should have been 

What about using resource discovery and link-format for fine-grained 
schema negotiation?
We just need a new attribute for the schema id and we also may have to 
define some kind of attribute inheritance to avoid repeating the schema on 
every single resource.
application/sep2+exi is still useful if we assume se2.1, 2.2... have 
compatible schemas. When compatibility is broken just go with another 
content type.
I don't think it is reasonable to register each minor schema variation 
from all standards in a 2-byte registry.

Matthieu

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 14:14:11 -0600

> compatible schemas. When compatibility is broken just go with another 

Well if 2.2 is backwards compatible with 2.1, then agree that one can just register 2 and use it for all the 2.x, a non backwards compatible change would force the registrations of 3. 

> from all standards in a 2-byte registry.

If there is any concern we might run out, should probably move this to allow 3 byte values as well.