Subject: Re: [apps-discuss] +exi

From: Paul Duffy <[email-masked]>
Date: Thu, 09 Feb 2012 11:54:08 -0800

We are closing this SEP2 issue in the next few days.

Consensus seems to be (?):

Content_Type: application/sep+xml

... or ...

Content_Type: application/sep+exi

The first indicating POX-to-native objects processing only, the second 
indicating EXI-to-native processing (no intermediate XML ... its not a 
compression).  May be further extended to support variants of EXI 
processing.

Going once, going twice, ....

We need to get this registered with IANA, etc.

Thanks

On 12/17/2011 7:11 PM, Martin Thomson wrote:
> On 18 December 2011 06:34, Zach Shelby<[email-masked]>  wrote:
>> I don't find the SchemaId all that useful. First of all, you need to invoke your EXI parser to even get at that. It is more useful to immediately look at the content-type to decide which parser to throw a representation at. A strictly defined foo+exi registration would tell you that nicely.
> ISTM that a link relation type for schema would make some sort of
> difference.  The JSON schema draft had a "describedby" relation type
> that might fit the bill (though "schema" is shorter).
>

---

From: psaintan <[email-masked]>
Date: Thu, 09 Feb 2012 19:52:05 -0700

As I recall, Zach Shelby was going to write a short draft about the
registration requirements for +exi...

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03981.html

I haven't seen that pop out yet.

Peter

On 2/9/12 12:54 PM, "Paul Duffy" <[email-masked]> wrote:

>>> I don't find the SchemaId all that useful. First of all, you need to invoke
>>> your EXI parser to even get at that. It is more useful to immediately look
>>> at the content-type to decide which parser to throw a representation at. A
>>> strictly defined foo+exi registration would tell you that nicely.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 10 Feb 2012 14:28:33 +0200

Hi,

That's right, slipped my todo list. Pointers to fairly similar documents appreciated as a template, first time writing this kind of draft.

Paul, let's keep in touch directly regarding this. 

Zach 

-- 
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: Paul Duffy <[email-masked]>
Date: Fri, 10 Feb 2012 10:52:35 -0800

I can review.  I took the AI from Zigbee Alliance

I'm going to propose SEP2 adopt what I outlined below until/if directed 
otherwise.

We have an ongoing interop schedule for which we must meet spec content 
deadlines.

Cheers

On 2/10/2012 4:28 AM, Zach Shelby wrote:
>> On 2/9/12 12:54 PM, "Paul Duffy"<[email-masked]>  wrote:
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Feb 2012 13:08:04 -0700

> That's right, slipped my todo list. Pointers to fairly similar documents appreciated as a template, first time writing this kind of draft.

Section 7 of RFC 3023 (XML media type) might be helpful:

http://tools.ietf.org/html/rfc3023#section-7

I was hoping that RFC 4627 has something similar for JSON, but I don't
see it there.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 10 Feb 2012 21:20:37 +0100

>I was hoping that RFC 4627 has something similar for JSON, but I don't

Last I heard the idea was that draft-ietf-appsawg-media-type-regs would
formalize the `+example` convention, but someone would have to write the
registration for `+json` separately. That has not happened yet as far as
I am aware. I argued that draft-ietf-appsawg-media-type-regs should re-
gister already established conventions like `+json`, but apparently I
was unsuccessful.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 10 Feb 2012 20:22:42 +0000

> http://tools.ietf.org/html/rfc3023#section-7

Or perhaps 

 http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#naming

which is slightly more up-to-date wrt +xml

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Ned Freed <[email-masked]>
Date: Fri, 10 Feb 2012 14:01:19 -0800 (PST)

> gister already established conventions like `+json`, but apparently I

Read the draft again, in particular the IANA considerations. That's exactly
what it does do.

				Ned

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 12 Feb 2012 20:59:45 +0100

>Read the draft again, in particular the IANA considerations. That's exactly

I take it you mean

   o  The initial content of the registry shall be constructed at the
      time of the registry's creation by the designated media types
      reviewer(s) by examining the current media types registry and
      extracting all conforming uses of "+suffix" names.

I would have expected the draft to have the actual registration forms
for the suffixes in question, but okay.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Sun, 12 Feb 2012 12:21:39 -0800 (PST)

> for the suffixes in question, but okay.

Material for one time use like this turns into useless clutter the minute the
registrations are done. In fact it's worse than useless  clutter - a careless
reader might infer that the registrations in a registration document like this
are the list of available suffixes.

Additionally, I don't see any point in duplicating existing registry content
anywhere else and then having to continually check to see if any new prefixes
have shown up in the registry. So I'm also opposed to having a separate
document to do this. That's why I came up with the idea of having the reviewers
create the initial suffix registry content from the existing media types
registry.

Again, the lighter the processes we define, the better.

				Ned