Subject: [core] coap #76 (new): Media types

From: "core issue tracker" <[email-masked]>
Date: Sun, 21 Nov 2010 21:15:14 -0000

#76: Media types

 This ticket is about [http://www.ietf.org/mail-
 archive/web/core/current/msg01048.html media types in draft-ietf-core-
 coap].

-- 
----------------------------+-----------------------------------------------
 Reporter:  hartke@…        |       Owner:  zach@…            
     Type:  defect          |      Status:  new               
 Priority:  major           |   Milestone:                    
Component:  coap            |     Version:                    
 Severity:  -               |    Keywords:                    
----------------------------+-----------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/76>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 23 Nov 2010 08:39:23 -0000

#76: Media types

Changes (by zach@…):

  * priority:  major => minor
  * type:  defect => enhancement

Comment:

 Let's be very specific about what changes are suggested by this ticket to
 Section 11.2. The mail from Cullen below suggests making changes to how
 MIME types are used that is way beyond our scope. I think that is
 something that needs to be fixed in the App area, and not in this working
 group. Although I see where Cullen is coming from, some basic MIME types
 are very useful when an application specific MIME type is not available,
 especially when getting started with a new application. For example
 application/xml, text/plain, application/exi, application/json all tell
 you what kind of parser needs to be used on the payload, or how the data
 could be displayed to a human.

 That said, I do think we can do some of the things suggested by Cullen:

 1. Add a column to the table pointing to a document describing what the
 payload means semantically.

 2. Remove some types from the table not really needed. Do we really need
 the image and video ones for example? application/x-bxml also is not a
 standard nor widely deployed. I would argue that we need to keep (at least
 some of) the basic text and application types.

 3. We add a paragraph explaining how MIME types should be designed and
 used for real applications as per Cullen's mail. For example something
 like application/sep20+xml in the case of ZigBee smart energy. Or the
 proposed application/dali, application/bacnet etc. from draft-vanderstok-
 core-bc.

-- 
----------------------------+-----------------------------------------------
 Reporter:  hartke@…        |       Owner:  zach@…            
     Type:  enhancement     |      Status:  new               
 Priority:  minor           |   Milestone:                    
Component:  coap            |     Version:                    
 Severity:  -               |    Keywords:                    
----------------------------+-----------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/76#comment:1>
core <http://tools.ietf.org/core/>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 Nov 2010 10:34:47 -0700

(in my individual contributor role )

I 90% agree with your suggestion - sounds like a reasonable path - few comments inline...

On Nov 23, 2010, at 1:39 AM, core issue tracker wrote:

> MIME types are used that is way beyond our scope.

No- I am suggesting using them exactly as they were meant to be used. I am just suggesting not registering the ones that have turned out not to be usable. 

> I think that is
> you what kind of parser needs to be used on the payload,

Really ? I doubt it. Let's say you know it is json and you want to parse it. All the reason I can imagine for parsing it, other than checking validity which no one does, require you to know far more than just it is JSON to be able to parse it. 

> or how the data

Yes, but this protocol is not really for raw display to humans. 

> some of) the basic text and application types.

Why keep text/plain? All this does is cause people not to register the actually useful code point. I'm fine with having a code point that is "unknown" or allowing the header to be missing. I just rather have the mime type specify something that was a type with semantic meaning and not be just a pointer to language the type was encoded with. Knowing if the data is ASCII or EBCDIC is really of no use. I want something useful. 

BTW - I am fine with things that are not widely used being registered - the code points here are very cheap. 

> proposed application/dali, application/bacnet etc. from draft-vanderstok-

Sound good 

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core