Subject: [media-types] [[email-masked]] New Version Notification for draft-shelby-exi-registration-02.txt

From: Olaf Bergmann <[email-masked]>
Date: Tue, 28 Feb 2017 10:27:46 +0100

Hi all,
(core ML Cc'd due to specific interest in this topic)

We have submitted an updated version of draft-shelby-exi-registration
that documents appropriate use of the "+exi" structured syntax suffix.

This document has been around since 2012 where it has been discussed in
the IETF media-types mailing list. There has not been much progress
since, specifically because the "application/exi" media type and the
"exi" content coding deemed to be sufficient.

Recent media type registration requests---in particular for
application/senml+exi---indicate that there are cases where the generic
exi media type and content coding header are not applicable.

Any comments are welcome!

Best regards
Olaf

Subject: New Version Notification for draft-shelby-exi-registration-02.txt
From: [email-masked]
To: "Carsten Bormann" <[email-masked]>, "Zach Shelby" <[email-masked]>, "Olaf Bergmann" <[email-masked]>
Date: Mon, 27 Feb 2017 09:32:55 -0800

A new version of I-D, draft-shelby-exi-registration-02.txt
has been successfully submitted by Olaf Bergmann and posted to the
IETF repository.

Name:		draft-shelby-exi-registration
Revision:	02
Title:		The +exi Media Type Suffix
Document date:	2017-02-22
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-shelby-exi-registration-02.txt
Status:         https://datatracker.ietf.org/doc/draft-shelby-exi-registration/
Htmlized:       https://tools.ietf.org/html/draft-shelby-exi-registration-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-shelby-exi-registration-02

Abstract:
   Efficient XML Interchange (EXI) is an XML representation technique
   specified by the W3C to provide a time and space efficient encoding
   for XML documents.  This document defines a new Structured Syntax
   Suffix "+exi" for use in a specific class of protocols, where "exi"
   content-type encoding or the generic "application/exi" media type are
   not applicable.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ned Freed <[email-masked]>
Date: Tue, 28 Feb 2017 05:58:15 -0800 (PST)

Has something changed about the definition of EXI that would make it actually
appropriate as a media type suffix? Because unless there's been a change the
reason this hasn't progressed is because it's inappropriate for it to do so.

In particular, it isn't possible to process a type that ends in +exi in any
significant way without knowing the type's schema. So unless there's a way
of discovering that knowing nothing but the type name, +exi provides
no utility.

				Ned

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 28 Feb 2017 15:23:05 +0100

Hi Ned,

> reason this hasn't progressed is because it's inappropriate for it to do so.

What has changed is the fact that +exi is in actual use.

> of discovering that knowing nothing but the type name, +exi provides

Well, processing a document is one thing. But signaling that you can
process a document (with or without schema) is another thing. The "+exi"
suffix helps where application/exi and content-coding: exi are not
applicable (e.g. in a CoAP Accept option). This is pretty much what the
draft describes.

Grüße
Olaf

---

From: Ned Freed <[email-masked]>
Date: Tue, 28 Feb 2017 06:46:57 -0800 (PST)

> What has changed is the fact that +exi is in actual use.

So are many other things that don't actually make sense. Usage doesn't
make something valid to register.

> applicable (e.g. in a CoAP Accept option). This is pretty much what the

Hmm. Well, if this assessment of the mechanism in CoAP is valid - and I take no
position on that - it sounds to me like CoAP effectively extended the semantics
of media types in a fairly fundamental way.

In particular, it seems like you're using them as a signalling mechanism where
no data of the given type is actually involved. If that's indeed the case, then
that extension to the use of media types needs to be fully and completely
described, along with its security considerations, so that types intended
for this usage can undergo proper review before they are registered.

There is some precedent for such usage, in that there are cases where the
top-level name of a media type has been used for signalling, necessitating the
registration of essentially the same type under audio/ and video/. But the type
still functioned as a label for actual media.

Anyway, IMO you have a lot of work to do before the registration of +exi can
be justified.

				Ned

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 28 Feb 2017 16:59:24 +0100

> of media types in a fairly fundamental way.

I do not think it does, more likely was my description not
accurate. What CoAP does is that it assigns a numeric value to a
registered media type/content coding combination which then is used when
negotiating the acceptable content type between sender and receiver.

> for this usage can undergo proper review before they are registered.

The number is just an abbreviation of what would otherwise go into the
Content-Type or Accept header together with Content-Coding. I do not see
why this would be an extension to common handling of media types and
their encodings?

Grüße
Olaf