Subject: [core] Media type text/html?

From: Kerry Lynn <[email-masked]>
Date: Tue, 25 Jun 2013 14:18:42 -0400

Sorry if this is a dumb question.

We have taken pains in the spec to define proxies and now have a WG draft
describing CoAP/HTTP mapping best practices.

However, the simplest method of connecting a coap server through a cross-
proxy to the world as it exists today would appear to be by using a
browser's
natural media type: "text/html".  Some (most?) browsers will not render
text/plain.

It seems text/html was removed in response to Cullen's <rant/>:
http://www.ietf.org/mail-archive/web/core/current/msg01048.html where he
largely talks about "application/8bit" as being useless for determining the
format of a resource (which I agree with).

Was "text/html" removed for a good reason (e.g. nobody will ever want to
host
a www server on coap) or did we take issue #76 a bit too literally?
http://tools.ietf.org/wg/core/trac/ticket/76

Thanks, -K-

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Jun 2013 23:04:02 +0200

On Jun 25, 2013, at 20:18, Kerry Lynn <[email-masked]> wrote:

> Was "text/html" removed for a good reason (e.g. nobody will ever want to host

I think we just tried to be a bit more conservative than the "everything and the kitchen sink" approach we had in earlier versions.

text/html certainly can be used in a "lightweight" fashion, so maybe we should put it back.
In Klaus' experimental semi-automated media type registry it has the number:

     2567   text/html

(see http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt for the complete list).

Grüße, Carsten

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 26 Jun 2013 08:27:30 -0400

On Tue, Jun 25, 2013 at 5:04 PM, Carsten Bormann <[email-masked]> wrote:

> I think we just tried to be a bit more conservative than the "everything
> and the kitchen sink" approach we had in earlier versions.
>
> Thanks Carsten, I was unaware of that registry.  That said, I would
support a one-octet
code for text/html at some point in the future...

-K-

> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jun 2013 14:50:39 +0200

On Jun 26, 2013, at 14:27, Kerry Lynn <[email-masked]> wrote:

> Thanks Carsten, I was unaware of that registry.  

One limitation of that registry is that it doesn't provide any parameters.
Not all media types have sensible default parameters.

In this case, the default value for the charset parameter of US-ASCII applies (RFC 2046).
(HTTP defines a different, even less reasonable default, but fortunately that doesn't apply here.)

(See also RFC 6657 to further muddy the water.)

Of course, HTML has <meta charset='utf-8'> to supply an appropriate default value, but that is 22 more bytes of overhead to carry around.  Or you can use character references, but that is per-character overhead.

> That said, I would support a one-octet

(I'm not sure that byte makes much of a difference for something as verbose as HTML.
But I agree that if there is a use case for "text/html; charset=utf-8", we should register it.)

Once the IANA registry is created, you can submit a request; see the registration policies in section 12.3 of core-coap.

Grüße, Carsten

---

From: Rick Bullotta <[email-masked]>
Date: Wed, 26 Jun 2013 13:00:43 +0000

Is there a range of media type code reserved for "application specific" use? Seems unwieldy to seek approval for each new media type. Perhaps a generic code for application/user-defined that would be followed by a String for the specific type?  Counting bytes at the expense of flexibility and extensibility seems a risky bet against Moore's law.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jun 2013 15:39:37 +0200

On Jun 26, 2013, at 15:00, Rick Bullotta <[email-masked]> wrote:

> Is there a range of media type code reserved for "application specific" use?

How would that work?  How would one endpoint find out what "application" another endpoint is part of?

That said, if you just want to play around in the lab, there is a range reserved for experiments (65000..65535).

But if you want to build something that is going to get stuck to a wall for a decade or two, maybe the effort to get a number is manageable.

> Seems unwieldy to seek approval for each new media type.

The range 10000 to 64999 is "first come first served", so it is not that hard to get a number.

> Perhaps a generic code for application/user-defined that would be followed by a String for the specific type?

There already is application/octet-stream (ct=42) for things that the server doesn't want to further specify.

In your example, what would you put into that String?
How is that name space governed?

If it is a media type name, just get a number.
This is so much of a no-brainer that Klaus has set up his experiment to see whether that can't be automated.

If it is something else, maybe the best place is in the data object?
E.g., for JSON, there are conventions to put information about the "context" or "profile" of the object right into it.  So you could use application/json (ct=50) together with that.

But maybe you have a use case that we haven't properly considered yet, and I'm eager to hear about it.

Grüße, Carsten

---

From: Rick Bullotta <[email-masked]>
Date: Wed, 26 Jun 2013 14:18:08 +0000

Hi, Carsten.

Personally, I think you have it nailed down fairly well "as is". It was more a general question about the process of introducing new media types.  Personally, I'm not a big fan of lots of derivative media types/mime types (e.g. lots of domain or usage-specific JSON or XML subtypes).  I think those should be in the data/content or other domain-specific headers, as you suggest.

I do think, however, that given the COAP desire to support efficient consumption of resources (network and otherwise), perhaps some of the binary JSON-like types could/will be formalized or become more stable in the near future, and those may be good additions to the list of supported types.

The more I dive into the COAP work that you all have done, the more impressed I am with the depth of thought that went into many of the aspects.  I will admit that I have probably only scratched the surface of my understanding of the breadth of the COAP RFC's, but do plan on learning more and hopefully contributing to the effort.   Are there any general resources/presentations/papers that you might recommend that help provide a high level view of COAP and how the pieces fit together? 

Cheers,

Rick
ThingWorx
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, June 26, 2013 9:40 AM
To: Rick Bullotta
Cc: Kerry Lynn; core
Subject: Re: [core] Media type text/html?

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jun 2013 16:41:42 +0200

Hi Rick,

> Personally, I think you have it nailed down fairly well "as is". 

Thanks!

> I do think, however, that given the COAP desire to support efficient consumption of resources (network and otherwise), perhaps some of the binary JSON-like types could/will be formalized or become…

Working on that subject right now:

	http://tools.ietf.org/html/draft-bormann-cbor-02

> Are there any general resources/presentations/papers that you might recommend that help provide a high level view of COAP and how the pieces fit together? 

There is always the CoRE roadmap (which, however, is ripe for another update):

	http://tools.ietf.org/html/draft-bormann-core-roadmap-04

If you have access to IEEE documents, you might want to look at:

	http://doi.ieeecomputersociety.org/10.1109/MIC.2012.29

And, of course, the best resource is this mailing list.

Grüße, Carsten

---

From: Rick Bullotta <[email-masked]>
Date: Wed, 26 Jun 2013 14:56:25 +0000

Hi, Carsten.

Excellent!  Thanks.  

Are there separate mailing lists for each of the subtasks, or is this the place to discuss things like CBOR?

One other area I think is crucial to "get right" is future proofing date/time handling (resolution, TZ consideration, and all of the stuff that keeps us awake at night doing real projects).  Accurate time resolution in the nanosecond range will soon be an essential capability for IoT/M2M applications (the energy grid is a great example), and I think the IETF/COAP seem a great place to undertake that discussion and champion a solution/recommendation.

MfG,

Rick

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, June 26, 2013 10:42 AM
To: Rick Bullotta
Cc: core ([email-masked])
Subject: Re: [core] Media type text/html?

Hi Rick,

Thanks!

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jun 2013 18:20:23 +0200

> Are there separate mailing lists for each of the subtasks, or is this the place to discuss things like CBOR?

The CoRE WG is chartered for the transfer protocol (CoAP) and the related discovery and security specifications.

Details: http://datatracker.ietf.org/wg/core/charter/

No IETF WG is officially chartered for CBOR; the discussion on CBOR has so far happened in [email-masked] (the mailing list of the APPAREA and APPSAWG WGs).

https://www.ietf.org/mailman/listinfo/apps-discuss

> One other area I think is crucial to "get right" is future proofing date/time handling (resolution, TZ consideration, and all of the stuff that keeps us awake at night doing real projects).  Accurate time resolution in the nanosecond range will soon be an essential capability for IoT/M2M applications (the energy grid is a great example),

Absolutely.

CBOR is designed to be extensible with respect to the data formats supported ("tags").
So far, we have tags for UTC-based time formats (both string-based and binary) in the base document.
If you need nanosecond resolution, you probably also need a monotonic time scale (no leap seconds, e.g. on the TAI or GPS time scale).
That could easily be added once we understand the requirements.

> and I think the IETF/COAP seem a great place to undertake that discussion and champion a solution/recommendation.

Thanks again.

We maybe have to do a bit of mailing list juggling here.
When it comes to actually working on IETF specifications, we try to have quite focused WGs.
We don't have something like a general "M2M" activity.
The CoRE WG is the WG that is closest to an M2M WG on the application layer, but it is focusing on the REST aspects.
CBOR may be useful outside of M2M, too, so we are having the general CBOR discussion over in apps-discuss.

But let's collect the M2M requirements right here on the CoRE mailing list.

Grüße, Carsten