Subject: Re: [core] coap #101 (new): Review media type registry

From: Zach Shelby <[email-masked]>
Date: Fri, 11 Mar 2011 11:04:58 +0200

On Feb 7, 2011, at 6:40 PM, core issue tracker wrote:

> #101: Review media type registry
> 
> From [http://www.ietf.org/mail-archive/web/uri-
> review/current/msg01321.html Björn Höhrmann's review]:
> 
> "it might be a good idea to have [email-masked] review the 'Media
> Type Registry' defined in the document. I am also worried by 'Correct
> examples from Table 8 include application/link-format,
> application/atom+xml and application/x-obix-binary' since one of these
> types cannot by registered and another one isn't registered, though I see
> there is a draft for the unregistered one."

Good point, we should just remove that sentence as it is misleading.

> 
> So the current list of initial assignments should be reviewed and, when
> it's in good shape, a request to review the section should be sent to the
> ietf-types mailing list.

Are there more media types in this initial registration that could be removed? I am not convinced that we need application/fastinfoset or application/soap+fastinfoset at this point, have not head of anyone actually using these. All the rest of them I actually know of current or potential uses for, so I think they should be kept. 

Zach

> 
> 
> -- 
> ----------------------------+-----------------------------------------------
> Reporter:  hartke@…        |       Owner:     
>     Type:  task            |      Status:  new
> Priority:  minor           |   Milestone:     
> Component:  coap            |     Version:     
> Severity:  -               |    Keywords:     
> ----------------------------+-----------------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/101>
> core <http://tools.ietf.org/core/>
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
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: Mon, 21 Mar 2011 13:02:07 +0100

> Are there more media types in this initial registration that could be
removed?
> I am not convinced that we need application/fastinfoset or
> application/soap+fastinfoset at this point, have not head of anyone
actually
> using these. All the rest of them I actually know of current or potential
uses
> for, so I think they should be kept.
As far as I know FastInfoset also has a schema informed mode similar to EXI.
I evaluated FI as being nearly as efficient as EXI compressing realistic XML
messages. So it might be still interesting (both FI and EXI) for folks using
XML representations. Maybe remove application/soap+fastinfoset, but leave
application/fastinfoset as more general media type?

Guido

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Zach Shelby
> Gesendet: Freitag, 11. März 2011 10:05
> An: core issue tracker
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [core] coap #101 (new): Review media type registry
> 
> Are there more media types in this initial registration that could be
removed?
> I am not convinced that we need application/fastinfoset or
> application/soap+fastinfoset at this point, have not head of anyone
actually
> using these. All the rest of them I actually know of current or potential
uses
> for, so I think they should be kept.
> 
> Zach
> 
> >
> >
> > --
> >

---

From: "Charles Palmer" <[email-masked]>
Date: Mon, 21 Mar 2011 14:46:53 -0000

Hi all

Guido writes:

"As far as I know FastInfoset also has a schema informed mode similar to
EXI.
I evaluated FI as being nearly as efficient as EXI compressing realistic
XML
messages."

I am not familiar with FastInfoset, but see that it is encoded as ASN.1
(tag, length, value). Note that IEEE 11073 uses ASN.1 encoding for
messages exchanged with personal health devices, as does DLMS, as used
in smart energy applications. Should provision be made for ASN.1
messages?

One advantage of ASN.1 cited by the IEEE11073 authors is that it allows
devices to prepare "canned" messages in which only some bytes change.
This is advantageous for simple devices. Does this also apply to EXI
messages? See examples here:
http://en.wikipedia.org/wiki/ISO/IEEE_11073_Personal_Health_Data_%28PHD%
29_Standards

I have long wondered about the complexity of encoding and decoding EXI
vs ASN.1 in small devices - does anyone know about this?

Regards - Charles Palmer 

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email message may contain confidential and/or privileged information, and
is intended solely for the addressee(s). If you have received this email in     
error, please notify Onzo immediately. Unauthorised copying, disclosure or 
distribution of the material in this email is forbidden.
--------------------------------

---

From: Zach Shelby <[email-masked]>
Date: Tue, 22 Mar 2011 08:44:49 +0200

> application/fastinfoset as more general media type?

Sure, I had the same conclusion from analyzing FI, "looks interesting". But is anyone really using it or needing it, such that we need an entry in the initial CoAP code allocation? I guess we could keep application/fastinfoset, but I agree that application/soap+fastinfoset should be removed.

Zach

---

From: Zach Shelby <[email-masked]>
Date: Tue, 22 Mar 2011 09:01:32 +0200

Hi,

> in smart energy applications. Should provision be made for ASN.1

Surely ASN.1 is useful for all kinds of things, and it is used in many application or protocol-specific MIME types today. However, there are no MIME types assigned for any of the generic ASN.1 encoding rules. I did find http://tools.ietf.org/html/draft-ietf-asid-mime-ber-00 but this is long expired. It is outside our scope to start defining new types. 

> vs ASN.1 in small devices - does anyone know about this?

It doesn't really matter for this WG as our job isn't to compare encodings. But just for fun :-)

You can't compare EXI and ASN.1 directly, as EXI is an XML encoding. FI uses ASN.1 for an equivalent purpose. Their complexity level is pretty similar from what I could tell. Now, if you just want to encode an integer or a simple struct, ASN.1 could surely be used for that and is simple enough. Google protobuf or JSON are often used for the same purpose. 

Zach