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

From: Zach Shelby <[email-masked]>
Date: Mon, 5 Mar 2012 11:50:57 +0200

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

---

From: Guido Moritz <[email-masked]>
Date: Tue, 6 Mar 2012 12:44:38 +0100

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:

   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. 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?!

Thus, it would be required to define for each Media Type very strict which
schemas and versions are required and which not. 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. 

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.
> > 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.
> >
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Tue, 6 Mar 2012 15:22:20 +0200

Hi,

> WG list. You describe two scenarios for the usage of +exi. I would mainly

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. 

> 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

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.

> 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

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

---

From: Guido Moritz <[email-masked]>
Date: Tue, 6 Mar 2012 14:39:16 +0100

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

> 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
> 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.
> 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.
> 
> Yes, each media type registration needs to define these things. This is
needed
> to ensure interoperability. Is that a bad thing?
> 
> 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
> >

---

From: Zach Shelby <[email-masked]>
Date: Thu, 8 Mar 2012 14:28:10 +0200

Guido,

It seems you are anyways in favor of the need for +exi media types, correct? Two examples where such a media type is being requested is the Smart Energy 2 profile (application/sep2+exi) and SenML (application/senml+exi), both of these have other versions of their media type being requested, and both are for M2M use. Yourself you mention application/soap+exi as being something you would find useful? Note that the purpose of this +exi suffix is not for general purpose EXI use by any means, it is meant for a narrow category of uses where a suffix makes sense. For other cases, either using the existing content-encoding or application/exi media type is recommended. 

I am happy to adjust the text in this draft so that the registration information to be provided by a media type requesting a +exi suffix is right, this was just a first straw-man. So what would help me most is if you would propose some improved text. I agree that the detailed EXI options should be controlled by the EXI header, no disagreement (this probably needs better text). I do however think that the media type registration needs to define how the SchemaID field is to be used, as the EXI standard doesn't give guidelines there. 

Zach

---

From: Guido Moritz <[email-masked]>
Date: Thu, 8 Mar 2012 14:12:17 +0100

> It seems you are anyways in favor of the need for +exi media types,
correct?
This is exactly what I am not sure about. For our use cases and experiences
it makes no sense due to the reasons given in my last mails. But of course I
am quite open if there are reasonable use cases. My first feeling simply was
that many people have only few knowledge about EXI itself and the way it
works. Thus, I would be happy to contribute with my experiences in using EXI
in the constrained world. 
One of my major points is why the existing mechanisms of EXI are not
sufficient and why there is a need for such a new mechanism. 

> Two examples where such a media type is being requested is the Smart
Energy
> 2 profile (application/sep2+exi) and SenML (application/senml+exi), both
of
> these have other versions of their media type being requested, and both
are for
> M2M use.
Sounds somewhat reasonable, but I am not an expert in SEP2 and SenML. I
would be happy to hear more about that.

> Yourself you mention application/soap+exi as being something you
> would find useful? 
No, makes no sense. SOAP deployments often use profiles (e.g. WS-I Basic
Profile, DPWS, ....). Hence, application/soap is not sufficient to point to
the required schema/grammar. 

> Note that the purpose of this +exi suffix is not for general
> purpose EXI use by any means, it is meant for a narrow category of uses
where
> a suffix makes sense. For other cases, either using the existing content-
> encoding or application/exi media type is recommended.
Agreed.

> I am happy to adjust the text in this draft so that the registration
information to
> be provided by a media type requesting a +exi suffix is right, this was
just a first
> straw-man. So what would help me most is if you would propose some
> improved text. I agree that the detailed EXI options should be controlled
by the
> EXI header, no disagreement (this probably needs better text). 
As soon I have finished my PHD thesis I am willing to assist also with text.
Would be after Paris.

> I do however
> think that the media type registration needs to define how the SchemaID
field
> is to be used, as the EXI standard doesn't give guidelines there.
I agree that the semantics of the SchemaID field needs to be defined
somewhere. But I am still not sure if there should be association with the
media type. 

Maybe it would be reasonable to discuss this issue in a F2F in Paris? We
should have plenty of time during the week.
 
Guido