Subject: [apps-discuss] proposal: adding profile support to JSON

From: Erik Wilde <[email-masked]>
Date: Sun, 03 Nov 2013 09:27:38 -0800

hello.

seeing that http://tools.ietf.org/html/draft-ietf-json-rfc4627bis is 
making good progress, i wanted to raise the question of maybe adding 
profile support to the JSON media type.

http://tools.ietf.org/html/draft-wilde-atom-profile is a proposal for 
adding profile support to the atom media type, and the "profile" 
optional media type parameter 
(http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-4.1.1) 
is what could be added to JSON as well.

the advantage would be that different JSON-based formats could be 
distinguished by their (mediatype+profile). this would allow JSON-based 
formats to become more visible on the web level, instead of always just 
saying "i am JSON", without any ability to differentiate.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 05 Nov 2013 17:41:05 +0900

Hello Erik,

> saying "i am JSON", without any ability to differentiate.

I don't understand this. JSON-based formats can be distinguished by 
registering a mime type. E.g., application/foo+json can be distinguished 
from application/bar+json. If that's not what you mean, can you give 
some examples of what you mean?

In general, adding a parameter doesn't work very well, because the 
infrastructure (e.g. setting mechanisms on the server side,...) isn't 
developped.

With respect to your atom profile proposal, it contains ideas for actual 
usage, but they all use "would". I think you should wait to pursue that 
draft until you have an *actual* use case, i.e. an actual profile 
parameter value. Just defining protocol slots without values isn't 
something that's done in the IETF, and isn't something that makes sense 
to spend IETF resources on.

Regards,   Martin.

---

From: Tim Bray <[email-masked]>
Date: Tue, 5 Nov 2013 07:57:47 -0800

Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html

On Tue, Nov 5, 2013 at 12:41 AM, "Martin J. Dürst"
<[email-masked]>wrote:

> from application/bar+json. If that's not what you mean, can you give some
> examples of what you mean?
>
> draft until you have an *actual* use case, i.e. an actual profile parameter
> value. Just defining protocol slots without values isn't something that's
> done in the IETF, and isn't something that makes sense to spend IETF
> resources on.
>
> Regards,   Martin.
>
>  thanks and cheers,
>>
>> dret.
>>
>>  _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Baker <[email-masked]>
Date: Tue, 5 Nov 2013 11:59:05 -0500

> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html

I'm with Martin. What that spec is trying to do with profiles is to
supplant the typical role of a media type. If it's representative of
what Erik has in mind for the use of a profile parameter with Atom (or
anywhere), then I think that needs to be reconsidered too.

Mark.

---

From: mike amundsen <[email-masked]>
Date: Tue, 5 Nov 2013 12:18:48 -0500

I'm using the profile link rel (currently in-message) to add domain
semantics (not protocol semantics) to Collection+JSON representations.

This does not, IMO, "supplant the typical role of a media type."

Of course, that's a bit of a bike shed since "typical" is a quality term. ;)

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mamund

---

From: Erik Wilde <[email-masked]>
Date: Tue, 05 Nov 2013 10:10:08 -0800

another existing example is 
http://lists.geojson.org/pipermail/geojson-geojson.org/2013-November/thread.html

On 2013-11-05, 07:57 , Tim Bray wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello Erik,
>
>
>         seeing that
>         http://tools.ietf.org/html/__draft-ietf-json-rfc4627bis
>         <http://tools.ietf.org/html/draft-ietf-json-rfc4627bis> is
>         http://tools.ietf.org/html/__draft-wilde-atom-profile
>         <http://tools.ietf.org/html/draft-wilde-atom-profile> is a
>         proposal for
>         (http://tools.ietf.org/html/__draft-wilde-atom-profile-02#__section-4.1.1
>         <http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-4.1.1>)
>     registering a mime type. E.g., application/foo+json can be
>     distinguished from application/bar+json. If that's not what you
>     mean, can you give some examples of what you mean?
>
>     infrastructure (e.g. setting mechanisms on the server side,...)
>     isn't developped.
>
>     With respect to your atom profile proposal, it contains ideas for
>     actual usage, but they all use "would". I think you should wait to
>     pursue that draft until you have an *actual* use case, i.e. an
>     actual profile parameter value. Just defining protocol slots without
>     values isn't something that's done in the IETF, and isn't something
>     that makes sense to spend IETF resources on.
>
>     Regards,   Martin.
>
>         thanks and cheers,
>
>         dret.
>
>     _________________________________________________
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/apps-discuss
>     <https://www.ietf.org/mailman/listinfo/apps-discuss>
>
>

---

From: James M Snell <[email-masked]>
Date: Tue, 5 Nov 2013 10:14:58 -0800

+1. Adding support for "profile" is harmless. It can safely be ignored
by anyone who feels it is unnecessary and introducing new profiles is
far less complicated than getting a new media sub-type accepted.

On Sun, Nov 3, 2013 at 9:27 AM, Erik Wilde <[email-masked]> wrote:
> hello.
>
> seeing that http://tools.ietf.org/html/draft-ietf-json-rfc4627bis is making
> good progress, i wanted to raise the question of maybe adding profile
> support to the JSON media type.
>
> http://tools.ietf.org/html/draft-wilde-atom-profile is a proposal for adding
> profile support to the atom media type, and the "profile" optional media
> type parameter
> (http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-4.1.1) is
> what could be added to JSON as well.
>

---

From: Erik Wilde <[email-masked]>
Date: Tue, 05 Nov 2013 10:33:58 -0800

hello mark.

> anywhere), then I think that needs to be reconsidered too.

i understand your concerns, but profiles do not attempt to "replace 
media types", even though they could be (mis-)used to try to do just 
that. [1] tries to explain the goal: they are for specializing and/or 
constraining existing media types; representing both the nature of the 
underlying type ("this is an atom feed and can be processed as a generic 
feed") as well as the specialized/constrained profile ("this feed 
carries podcast data, and can be processed as a podcast feed").

james snell blogged about the bigger problem [2] that media types as 
they are today are not a terribly well-designed concept. i think that's 
correct, and profiles are just a minor "patch" in that space. what james 
suggests would be much more comprehensive and much more involved, but 
would affect so may parts of internet/web architecture that maybe using 
profiles as a stepping stone is a useful first step.

cheers,

dret.

[1] http://dret.typepad.com/dretblog/2013/03/on-profiles.html
[2] 
http://www.chmod777self.com/2012/04/more-on-future-of-mime-media-types.html

---

From: James M Snell <[email-masked]>
Date: Tue, 5 Nov 2013 11:17:23 -0800

On Tue, Nov 5, 2013 at 10:33 AM, Erik Wilde <[email-masked]> wrote:
> hello mark.
>[snip]
>
> james snell blogged about the bigger problem [2] that media types as they
> are today are not a terribly well-designed concept. i think that's correct,
> and profiles are just a minor "patch" in that space. what james suggests
> would be much more comprehensive and much more involved, but would affect so
> may parts of internet/web architecture that maybe using profiles as a
> stepping stone is a useful first step.
>

heh... why do I suddenly have the sense that Erik is defending the
profile proposal as a significantly less crazy idea than what I was
suggesting ;-) ...

Stepping back a bit, it ought to be recognized that media types are
being asked to do far more today than they have been in the past. XML
and JSON are generic data formats used for a very broad range of
purposes. Falling back on the simple application/json and
application/xml media types is certainly not sufficient and attempting
to come up with an application/[variation]+[base] media type for every
possible variation simply is not a scalable approach in the long run.
Allowing for "profile" provides a useful escape hatch by eliminating
the need to register and track every possible variation.

That said, even profile is limited in a sense. The "Content Profile"
approach I suggested in my blog post (as radically different it may
appear) would deal with scalability issues inherent in the current
media type scheme... but I suspect that the likelihood of making such
changes is exceedingly low.

- James

---

From: Erik Wilde <[email-masked]>
Date: Tue, 05 Nov 2013 13:47:30 -0800

hello.

> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html

while i of course like the idea of I-JSON being a profile of JSON, if 
that's supposed to work in the same way as RFC 6906 ("The 'profile' Link 
Relation Type") specifies, then

http://tools.ietf.org/html/draft-bray-i-json-00.html#section-2.1

and

http://tools.ietf.org/html/rfc6906#section-3.1

are in conflict. that's because RFC-6906 profile identifiers must be 
URIs. one option therefore might be to use something like 
urn:ietf:rfc:XXXX as the profile identifier (or something else, if it 
should be stable before the RFC number is assigned).

cheers,

dret.

---

From: Mark Baker <[email-masked]>
Date: Wed, 6 Nov 2013 09:20:58 -0500

Hi Erik,

On Tue, Nov 5, 2013 at 1:33 PM, Erik Wilde <[email-masked]> wrote:
> i understand your concerns, but profiles do not attempt to "replace media
> types", even though they could be (mis-)used to try to do just that. [1]
> tries to explain the goal: they are for specializing and/or constraining
> existing media types; representing both the nature of the underlying type
> ("this is an atom feed and can be processed as a generic feed") as well as
> the specialized/constrained profile ("this feed carries podcast data, and
> can be processed as a podcast feed").

I've read your RFC, and both referenced blog posts, but still find
myself asking the same question; what problem does it solve? Yes,
media types have their issues, but in my many years in Web development
and standardization, I've yet to encounter a problem that didn't have
a workable solution through the correct use of link relations and
media types. This includes my time advising on the development of a
compound document editor at Justsystem, and representing them on the
W3C Compound Document Formats WG.

We agree that a document containing some OPDS extensions is still an
Atom document that can be delivered as application/atom+xml, I
believe. You appear to suggest that there's value in exposing the
existence of those OPDS extensions using an additional external
metadata protocol element. I believe that this is at best an
optimization, since the consumer can easily detect the existence of
the extension by inspecting the content (and understanding the
extensibility model of the host format). But at worst, it's a recipe
for interop problems; does the meaning of the document change if the
profile is declared vs not? What if the v2 profile URI is declared and
the document contains a v1 extension? etc..

This really smells to me like a solution in search of a problem.

> are today are not a terribly well-designed concept.

I strongly disagree with that post (blog commenting seems broken, but
I won't respond in detail here except to say "rel=icon" :). I believe
media types are far better designed than is commonly appreciated; a
single label for a compatible evolution of a document format is a
simple yet extremely powerful protocol that promotes compatibility in
extensions and penalizes incompatible deviations... but still permits
them when required.

And FWIW, this is coming from the guy who, AFAIK, started the whole
profile parameter ball rolling in RFC 3236. That went in there only as
a compromise with the WAPforum, but was never/rarely used in practice.

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 6 Nov 2013 16:41:02 +0100

> the document contains a v1 extension? etc..

As you say, in XML you can leverage namespacing to create fully
self-descriptive messages without requiring another media type. In this
thread, however, we are talking about JSON which doesn't support
namespacing. So, how would you (or any of the numerous JSON APIs out there)
signal the semantics of such "extensions" in a JSON document without minting
a new media type?

--
Markus Lanthaler
@markuslanthaler

---

From: mike amundsen <[email-masked]>
Date: Wed, 6 Nov 2013 11:18:05 -0500

<snip>I've read your RFC, and both referenced blog posts, but still find
myself asking the same question; what problem does it solve?</snip>

Mark:

I use profiles to _add_ domain-specific information to an existing
hypermedia format (like HTML or Collection+JSON).

Separation of Concerns
This makes it possible to separate protocol details (HTTP) from domain
details (accounting, microblogging) which make re-use of existing media
types possible even when you encounter a new problem domain.

Decoupling & Reuse
Using profiles also creates a "closed world" model of a domain (e.g.
microblogging) and that makes it possible to code a client all that
recognizes that domain *independent* of the media type.  This speeds/eases
the effort to create an M2M domain client since you are working in "layers"
you can take an existing hypermedia type (e.g. HTML) parser and _add_ the
domain-specific coding.

IMO, this is solving a problem that existing now and will continue to
exist. It offers the ability for developers to "level-up" and stop coding
protocol and focus on domain specifics *without* losing fidelity to a
protocol.

mamund
+1.859.757.1449
skype: mca.amundsen

---

From: James M Snell <[email-masked]>
Date: Wed, 6 Nov 2013 08:28:58 -0800

Please consider the examples I gave in that post to just be a
strawman. The more significant point is that the media type syntax, as
currently defined, does not scale very well for the types of uses
developers are currently attempting to use them for, and the process
around which new media types is defined and standardized leaves much
to be desired. I won't go in detail here except to reference the ugly
hack that is RFC 6839 ;-)

- James

On Wed, Nov 6, 2013 at 6:20 AM, Mark Baker <[email-masked]> wrote:
[snip[

---

From: "Rushforth, Peter" <[email-masked]>
Date: Wed, 6 Nov 2013 16:56:24 +0000

Hey Mark,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Baker
> Sent: November 6, 2013 09:21
> To: Erik Wilde
> Cc: [email-masked] application-layer protocols
> Subject: Re: [apps-discuss] proposal: adding profile support to JSON
> 
> Hi Erik,
> 
> >>> Well, for example, 
> >>> http://www.tbray.org/tmp/draft-bray-i-json-01.html
> >>
> >> what Erik has in mind for the use of a profile parameter with Atom 
> >> (or anywhere), then I think that needs to be reconsidered too.
> >
> >
> > underlying type ("this is an atom feed and can be processed as a 
> > generic feed") as well as the specialized/constrained 
> profile ("this 
> > feed carries podcast data, and can be processed as a podcast feed").
> 
> I've read your RFC, and both referenced blog posts, but still 
> find myself asking the same question; what problem does it 
> solve? Yes, media types have their issues, but in my many 
> years in Web development and standardization, I've yet to 
> encounter a problem that didn't have a workable solution 
> through the correct use of link relations and media types. 
> This includes my time advising on the development of a 
> compound document editor at Justsystem, and representing them 
> on the W3C Compound Document Formats WG.
> 
> We agree that a document containing some OPDS extensions is 
> still an Atom document that can be delivered as 
> application/atom+xml, I believe. You appear to suggest that 
> there's value in exposing the existence of those OPDS 
> extensions using an additional external metadata protocol 

> element. I believe that this is at best an optimization, 
> since the consumer can easily detect the existence of the 
> extension by inspecting the content 

How can the consumer *request* the extended semantics, if not through the media type?
Lots of stuff gets transmitted under guise of text/html, application/xml, application/json
that should be encouraged to register.

> But at worst, it's a 
> recipe for interop problems; does the meaning of the document 
> change if the profile is declared vs not? 

According to RFC 2045, it falls back to the base media type/subtype without 
that parameter.

"   Parameters are modifiers of the media subtype, and as such do not
   fundamentally affect the nature of the content. 
...
   MIME implementations must ignore any parameters whose names they do not
   recognize."

> What if the v2 
> profile URI is declared and the document contains a v1 
> extension? .

That would be an error, unless v1 is wholly included in v2.

Furthermore, media type parameters are meant to help the
client interpret the meaning of the message.  An optional parameter should not
be not a 'slot', it should be a recommendation to future registrations to define
values of it.  I think the recommended use of a URI perhaps
leads one to think it can be assigned ad hoc.  I think values 
should be registered, like what Tim is doing.

> > they are today are not a terribly well-designed concept.
> 
> I strongly disagree with that post (blog commenting seems 
> broken, but I won't respond in detail here except to say 
> "rel=icon" :). I believe media types are far better designed 
> than is commonly appreciated; a single label for a compatible 
> evolution of a document format is a simple yet extremely 
> powerful protocol that promotes compatibility in extensions 
> and penalizes incompatible deviations... but still permits 
> them when required.

+1

> 
> And FWIW, this is coming from the guy who, AFAIK, started the 
> whole profile parameter ball rolling in RFC 3236. That went 
> in there only as a compromise with the WAPforum, but was 
> never/rarely used in practice.

Interesting, thanks for pointing that out.

Regards,
Peter Rushforth

---

From: Erik Wilde <[email-masked]>
Date: Wed, 06 Nov 2013 10:35:34 -0800

hello mark.

On 2013-11-06, 06:20 , Mark Baker wrote:
> media types.

as i am sure you know, "profile" is a link relation. so what you're 
saying that it's not a "correct" use of link relations? i am really just 
trying to understand your perspective here. a profile media type 
parameter just exposes that link relation in a special place, because it 
matters for the media type, and it is more convenient to see it exposed 
there, instead of first having to parse the representation.

> believe.

yes, absolutely.

> You appear to suggest that there's value in exposing the
> metadata protocol element.

yes, because then profiles can, for example, take part in wen-level 
mechanisms such as conneg, instead of being "hidden" only in the 
representations.

> I believe that this is at best an
> extensibility model of the host format).

true for reading, not true for writing, where profiles can also indicate 
what constrained media types a server is willing to accept.

> But at worst, it's a recipe
> profile is declared vs not?

no it doesn't. the RFC (at least tries to) make that clear. if the 
processing model of the underlying media type cannot be safely applied 
to a representation using a profile, then you shouldn't use a profile.

> What if the v2 profile URI is declared and

this is no different from the media type versioning problem.

cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Wed, 06 Nov 2013 10:51:17 -0800

hello markus.

thanks for the feedback.

> signal the semantics of such "extensions" in a JSON document without minting

i think there are several ways in which you can do this. if your JSON 
format supports generic linking somehow somewhere in the format, then 
you can simply add a "profile" link. if it doesn't, you might have a 
specific profile identifier in the format, similar to HTML's 
head/@profile. but that's of course assuming you already *have* some 
processing model in place that's used for the representation, so we 
might have a chicken-and-egg problem here.

maybe that points to the fact that in practice, profiles make more sense 
on more meaningful media types (such as adding profiles to Atom or HTML 
that signify certain ways of how these formats are constrained), and 
less so on very generic ones. on the other hand, I-JSON may be a good 
example for how even something as generic as plain JSON might benefit 
from profiles being exposable on the media type level.

cheers,

dret.

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 6 Nov 2013 20:10:40 +0100

> format supports generic linking somehow somewhere in the format, then

I was specifically talking about application/json.

> might have a chicken-and-egg problem here.

Right, to signal it you could use a HTTP Link header, but that wouldn't work for conneg.

> from profiles being exposable on the media type level.

I think quite the contrary is the case. IMO generic media types such as JSON or vanilla XML are the ones benefitting most of this.

--
Markus Lanthaler
@markuslanthaler

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 07 Nov 2013 12:53:04 +0900

Hello Tim,

> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html

Well, I may be repeating what others have said, but:

- I think this draft provides value in that somebody can point to it and 
say "I'm accepting JSON, but only if it conforms to this" (meaning no 
single surrogates, no duplicate object keys,...).

- I think the profile parameter and the "self-identification" are total 
overkill. They would be needed if we imagine a receiver that accepts 
both restricted (i-json) and general (JSON) stuff, but I can't see the 
point of doing that (except for the constructed example of a service 
that checks which of the two it is).

- If I restrict myself to accepting i-json, I have to check for problems 
anyway, even if it comes with a profile parameter and a 
"self-identification". So these two items don't really help.

Because I don't know you as somebody who makes protocols and formats 
needlessly complex, I'm really wondering what you think these two 
features are good for. I hope you can explain.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 07 Nov 2013 12:57:13 +0900

> http://lists.geojson.org/pipermail/geojson-geojson.org/2013-November/thread.html

That thread seems to say that it's too difficult or tedious to register 
a Mime media type. That's actually not the case, in particular if you 
don't insist on a registration in the standard tree.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 07 Nov 2013 15:09:54 +0900

On 2013/11/06 3:33, Erik Wilde wrote:
> that.

Well, James just said:

which at least comes close.

> [1] tries to explain the goal: they are for specializing and/or

Looking at that, I see:

it should be possible to have meaningful applications using the services 
without knowing/using the profile. specifically, for this reason it 
would not be a proper use of profiles to say that podcasts or OPDS are 
profiles of RDF or XML, because you cannot meaningfully consume podcasts 
or OPDS just based on on parsing RDF or XML.

I don't know of meaningful JSON *applications* that would work without 
using a profile (or knowing what's supposed to be sent in the first 
place, or using a more specialized mime type).

> profiles as a stepping stone is a useful first step.

This kind of discussion comes up from time to time. Of course media 
types aren't perfect. But they aren't really broken, either.

Regards,   Martin.

---

From: Mark Baker <[email-masked]>
Date: Thu, 7 Nov 2013 11:01:12 -0500

Hi Erik,

On Wed, Nov 6, 2013 at 1:35 PM, Erik Wilde <[email-masked]> wrote:
> as i am sure you know, "profile" is a link relation. so what you're saying
> that it's not a "correct" use of link relations? i am really just trying to
> understand your perspective here. a profile media type parameter just
> exposes that link relation in a special place, because it matters for the
> media type, and it is more convenient to see it exposed there, instead of
> first having to parse the representation.

Yes, I wasn't trying to single out "profile" at all, just speak to the
general utility of type/rel.

...

> what constrained media types a server is willing to accept.

Ok. But AFAICT, the I-JSON draft isn't using profile=i-json as an
optimization. IMO, if it needs for the "urn:ietf:i-json" key to have
special meaning, media types are the only way we currently have to
communicate that fact to JSON recipients (over HTTP at least). But I
have to admit to not understanding the context for I-JSON's existence,
not being involved in those discussions, so perhaps I'm missing
something. Regardless of the specifics of that example, my general
concern is that what you admit is an optimization for these types of
scenarios, may be misunderstood as being something more than that (as
James' suggests when he talks about it eventually replacing media
types).

If your claim is that the true value for profiles is elsewhere, I'd
like to see a concrete proposal before we begin to standardize on
protocol elements for their use. I'm personally skeptical (I'm sure
you're shocked to hear this :) as I've put considerable effort into
exploring this space over the years (including lots of test case
code).

See http://www.markbaker.ca/Talks/2004-media-types-and-compdocs/slide1-0.html
which Markus might also be interested in, to explain why XML
namespaces don't do what he claims. W3C members might also be
interested in the strawman proposal motivated by that presentation;
https://lists.w3.org/Archives/Member/member-cdf/2006Apr/0000.html

---

From: Tim Bray <[email-masked]>
Date: Thu, 7 Nov 2013 08:20:14 -0800

Well, my thinking was like this. Suppose people start requiring I-JSON for
some protocol or other.  What we would like is to convince the authors of
the existing JSON libraries to implement I-JSON mode, where they signal an
error when they hit a dupe key or whatever.  I suppose in most cases this
would be done with a new JSONParserFactory#setIJSONMode() method, or
something like that.

But, speaking as the author of quite a bit of markup parsing software, the
notion of putting a force-I-JSON-mode in the instance struck me as
potentially useful for:
- a bug-catcher
- Postel’s-law-following receivers who want to check how careful they have
to be about name/value mapping, broken Unicode, etc - as it stands, you
really can’t safely use UTF-8 conformant String#length on JSON strings in
the general case.

I guess I’m also influenced by the generally good experience with the XML
declaration.

But this is not something I’m passionate about, just something that’s worth
thinking about. -T

On Wed, Nov 6, 2013 at 7:53 PM, "Martin J. Dürst" <[email-masked]>wrote:

> overkill. They would be needed if we imagine a receiver that accepts both
> restricted (i-json) and general (JSON) stuff, but I can't see the point of
> doing that (except for the constructed example of a service that checks
> which of the two it is).
>
> needlessly complex, I'm really wondering what you think these two features
> are good for. I hope you can explain.
>

---

From: James M Snell <[email-masked]>
Date: Thu, 7 Nov 2013 08:28:57 -0800

> I guess I’m also influenced by the generally good experience with the XML

Just as an aside, using HTTP Prefer's handling=strict vs.
handling=lenient would also be a great way of toggling whether or not
to optionally apply an I-JSON parsing mode.

- James

>> say "I'm accepting JSON, but only if it conforms to this" (meaning no single
>> surrogates, no duplicate object keys,...).
>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 08 Nov 2013 19:00:59 +0900

> would be done with a new JSONParserFactory#setIJSONMode() method, or

Yes. I'm very much with you up to here. I'd personally use a parameter 
to the factory constructor, but that's a minor detail.

> notion of putting a force-I-JSON-mode

But it's NOT a 'force-I-JSON-mode'. There are lots of old JSON parsers 
out there that don't know anything about i-json.

> in the instance struck me as
> potentially useful for:
> - a bug-catcher

Yes, if you have lots of JSON (I- or not) lying around somewhere, and 
you want to check how much of what's supposed to be of the I- variant, 
then it may be useful. But that's what I call a meta-usecase, which by 
my book shouldn't drive design.

> really can’t safely use UTF-8 conformant String#length on JSON strings in

It's difficult for me to imagine a receiver that checks some of the JSON 
it receives more carefully. If I have an application, let's say with a 
database behind it, and I don't want to have any unpaired surrogate 
stuff and the like in that database, I'll check all incoming data, and 
won't care about whether it comes with the necessary flags or not.

> I guess I’m also influenced by the generally good experience with the XML

The XML declaration was there from the start (of XML). There isn't any 
such thing for JSON up to now.

The XML declaration, if it is there (it's not mandatory) is always at 
the very start of an XML document (no spaces allowed). There have been 
strong doubts about whether the i-json indication inside the document 
can be made to appear early on in an object.

> thinking about.

Yes. My thinking hasn't turned up much in favor, but maybe somebody 
else's thinking will?

Regards,   Martin.

-T
>
>
> On Wed, Nov 6, 2013 at 7:53 PM, "Martin J. Dürst"<[email-masked]>wrote:
>