Subject: [apps-discuss] Encoding considerations (was Technical Errata for RFC 6839

From: Larry Masinter <[email-masked]>
Date: Mon, 18 May 2015 23:58:06 +0000

Am I missing some major installed base which only supports 8bit or 7bit?

If not, I’d deprecate “Encoding considerations” and allow it to be omitted from
media type registrations, the assumption being that “binary” is the default.

The whole ‘Encoding considerations’ section seems like a relic.

>> In fact a lot of formats based on XML or JSON are by their nature
>> _always_ 8bit or 7bit compatible. And I see some value in pointing that out
>> where it's appropriate to do so

Could someone give an example of where it is valuable and not just another
thing to get wrong? A protocol in common use that needs 7bit or 8bit and
can’t do binary? 

Larry
—
http://larry.masinter.net

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 May 2015 19:24:06 -0500

> Am I missing some major installed base which only supports 8bit or 7bit?

What does "only supports 8-bit" even mean?

> >> where it's appropriate to do so

Encoded JSON texts can contain non-ASCII without escaping, so JSON is not
7-bit compatible, but JSON texts can be re-encoded such that all
non-ASCII Unicode codepoints are escaped, so in a sense JSON is 7-bit
compatible.  But so what?

What's the context anyways?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 May 2015 19:33:59 -0500

> What's the context anyways?

Never mind, I found the context.

Nico
--

---

From: Ned Freed <[email-masked]>
Date: Mon, 18 May 2015 22:36:32 -0700 (PDT)

> Am I missing some major installed base which only supports 8bit or 7bit?

It's called email.

> The whole ‘Encoding considerations’ section seems like a relic.

It's the relic we're using to have this discussion, so...

				Ned