I-JSON is more restrictive than rfc7159, so producer of JSON would do
well to conform to it. OTH, JSON consumers cannot reject a JSON text
that conforms to rfc7159, but not I-JSON. This is reason enough not to
enforce it in JSON-P.
If there is a need to restrict JSON to I-JSON on the receiving side, the
best approach is to add a pre-processor that checks for I-JSON conformance.
-Kin-man
On 4/30/15 6:11 AM, Martin Grebac wrote:
> Hi Kin-Man ;O)
> why do you think I-JSON is more for producers? I think it's both ...
> there are rules which define how I-JSON message should look like, on
> the other hand there is an expectation on client side to be able to
> throw away messages which do not conform.
>
> https://www.tbray.org/ongoing/When/201x/2015/03/23/i-json
> 'So if you specify that your payload MUST be I-JSON message, and
> the receiver checks that, there’s one particular class of
> attacks that you no longer have to worry about.'
>
> https://tools.ietf.org/html/rfc7493
> 'A major advantage of using I-JSON is that receivers can avoid
> ambiguous semantics in the JSON messages they receive. This allows
> receivers to reject or otherwise disregard messages that do not
> conform to the requirements in this document for I-JSON messages.'
>
> I'd agree there is no need to enforce this on consumer side, though
> the consumer should have the option.
>
> MartiNG
>
>
> On 29.04.15 19:27, Eugen Cepoi wrote:
>> Transferring Kin-man answer and using the user mailing lists so we
>> can talk cross jsrs... :)
>>
>> ---------- Forwarded message ----------
>> From: *Kin-man Chung* <kinman.chung_at_oracle.com
>> <mailto:kinman.chung_at_oracle.com>>
>> Date: 2015-04-29 19:21 GMT+02:00
>> Subject: [jsr374-experts] Re: [jsonb-spec users] [jsr367-experts] Re:
>> Re: Re: Re: Re: [33-I-JSON Compatibility] Proposal
>> To: jsr374-experts_at_json-processing-spec.java.net
>> <mailto:jsr374-experts_at_json-processing-spec.java.net>
>>
>>
>> JSON-P is enforcing, but not detecting duplicate names in properties.
>> Of course this is only done when building JSON tress, not during parsing.
>>
>> IMO, I-JSON is more for JSON producers than consumers. There is no
>> need to enforce it in our specs.
>>
>> -Kin-man
>>
>>
>> On 4/29/15 5:56 AM, Eugen Cepoi wrote:
>>> Yes both could be added, but it would hurt perfs to keep track of
>>> all the seen names...esp if it is a large json.
>>>
>>> 2015-04-29 14:50 GMT+02:00 Martin Grebac <martin.grebac_at_oracle.com
>>> <mailto:martin.grebac_at_oracle.com>>:
>>>
>>> Could be, more interesting I think it would be in the profile
>>> definition for unmarshalling, where there should be a
>>> possibility to reject non I-JSON messages soonest in the stack -
>>> that I think would fall to JSON-P category, too.
>>> MartiNG
>>>
>>> On 29.04.15 14:42, Martin Vojtek wrote:
>>>
>>> Actually I think JSON-P can help at least with unique names
>>> of properties. I can imagine that JSON-P could provide
>>> option to enforce uniqueness of names of properties (in
>>> terms of key/value - keys).
>>>
>>> MartinV
>>>
>>> On Tue, Apr 28, 2015 at 2:21 PM, Eugen Cepoi
>>> <cepoi.eugen_at_gmail.com <mailto:cepoi.eugen_at_gmail.com>
>>> <mailto:cepoi.eugen_at_gmail.com
>>> <mailto:cepoi.eugen_at_gmail.com>>> wrote:
>>>
>>> +JSON-P EG
>>>
>>> I don't remember seeing I-JSON being discussed on the
>>> jsonp ML.
>>> But perhaps this spec is more at the databinding level
>>> and doesn't
>>> need to be implemented in jsonp.
>>>
>>>
>>> 2015-04-28 14:01 GMT+02:00 Romain MB
>>> <rmannibucau_at_tomitribe.com <mailto:rmannibucau_at_tomitribe.com>
>>> <mailto:rmannibucau_at_tomitribe.com
>>> <mailto:rmannibucau_at_tomitribe.com>>>:
>>>
>>> 2015-04-28 13:53 GMT+02:00 Martin Grebac
>>> <martin.grebac_at_oracle.com
>>> <mailto:martin.grebac_at_oracle.com>
>>> <mailto:martin.grebac_at_oracle.com
>>> <mailto:martin.grebac_at_oracle.com>>>:
>>> > On 27.04.15 19:26, Romain MB wrote:
>>> >>
>>> >> 2015-04-27 18:38 GMT+02:00 Martin Grebac
>>> <martin.grebac_at_oracle.com
>>> <mailto:martin.grebac_at_oracle.com>
>>> <mailto:martin.grebac_at_oracle.com
>>> <mailto:martin.grebac_at_oracle.com>>>:
>>>
>>> >>>
>>> >>> On 24.04.15 20:54, Martin Vojtek wrote:
>>> >>>>
>>> >>>> I think that the result of the discussion is as
>>> follows:
>>> >>>>
>>> >>>> 1. support of string values for big numbers by
>>> default
>>> >>>> 2. support the override of properties by default
>>> >>>> 3. fail fast when non-unique property (after
>>> override and
>>> rename) is
>>> >>>> found
>>> >>>> 4. define default algorithm for override (based
>>> on java
>>> mechanism) and
>>> >>>> check uniqueness of properties (not affecting
>>> performance)
>>> >>>> 5. Do not enable I-JSON by default due to the
>>> following
>>> recommendations
>>> >>>> - support only root objects/arrays by default
>>> >>>> - serialize binary data to base64 by default
>>> >>>
>>> >>> To me, none of the 2 reasons above seem strong
>>> enough to
>>> not support
>>> >>> I-JSON
>>> >>> by default. Binary data is a specific usecase
>>> which is
>>> most often going
>>> >>> to
>>> >>> be configured based on specific needs, and root
>>> objects
>>> are limitation of
>>> >>> current version of JSON-P as well (and I assume
>>> of some
>>> other parsers,
>>> >>> too,
>>> >>> otherwise the requirement would not be in
>>> I-JSON), so
>>> clients using
>>> >>> JSON-P
>>> >>> would have hard time parsing the default JSON
>>> Binding output.
>>> >>
>>> >> Not sure I fully get you. Ok about root objects
>>> point -
>>> this one is
>>> >> not that important I agree. That said from my
>>> understanding
>>> I-JSON
>>> >> recommands to use base64url by default (did I
>>> misunderstand?). If so I
>>> >> would prefer we don't follow this point as
>>> already explained in
>>> >> another mail.
>>> >
>>> > Thanks, I'm looking for the reasons why not to.
>>> The reasons
>>> for following
>>> > the recommendation is that base64url has its
>>> advantages,
>>> such as it is
>>> > leveraged within JSON security (encryption/signature)
>>> standards, and for
>>> > similar reasons it is a recommendation within I-JSON.
>>> Against, I found this
>>> > (let me know if I missed some other reasons, the
>>> thread is
>>> rather long):
>>> >
>>> > - byte data as base64: on johnzon we discussed it
>>> and I
>>> didn't want it
>>> > cause it was far from Java - that said it is not a
>>> super
>>> common type
>>> > so not sure it is that important
>>> >
>>> > I'm not sure what does it mean far from Java. SE8
>>> gives
>>> options to
>>> > encode/decode to base64 or base64url:
>>> >
>>> https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html
>>> >
>>>
>>> Was more in term of design. If I use byte[] then I don't
>>> expect the
>>> serializer to *automatically* create a String. If i
>>> want a base64
>>> string then I would have used a String directly IMO.
>>> Moreover
>>> if then
>>> I use a byte[][], does it serialize it as String[]
>>> or really
>>> byte[][]?
>>> In first case it will not match much cases IMO (and
>>> break default
>>> expectations) and in second case it is not
>>> consistent with byte[]
>>> serialization. So globally I would prefer to provide
>>> out of
>>> the box a
>>> converter/serializer (whatever name we use) to allow to
>>> convert it to
>>> base64url instead of having it implicitly.
>>>
>>> > You are right this is not a requirement, but
>>> recommendation,
>>> so there is an
>>> > option to opt out of this specific item (and/or
>>> some other
>>> ones within
>>> > I-JSON). Definition of recommendation is 'there
>>> may exist
>>> valid reasons in
>>> > particular circumstances to ignore a particular
>>> item, but
>>> the full
>>> > implications must be understood and carefully
>>> weighed before
>>> choosing a
>>> > different course'.In my view, I don't see the
>>> reasons for
>>> opting out (at
>>> > least not yet).
>>> >
>>> > MartiNG
>>> >
>>>
>>>
>>>
>>>
>>> --
>>> Martin Grebac, SW Engineering Manager
>>> Oracle Czech, Prague
>>>
>>>
>>
>>
>
> --
> Martin Grebac, SW Engineering Manager
> Oracle Czech, Prague