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