Don't see problem supporting (in default mapping) the following point (and
actually it was the original proposal before I-JSON discussion):
- support only root objects/arrays by default
So the only point to agree upon is base64url. I don't have strong opinion
about it. My impression is that binary data is not so common case. Maybe I
am wrong.
Interoperability is about interacting with JSON documents produced by
different tools (in Java or different languages) and about JSON documents
used in different scenarios (like JSON in URL).
Thanks to JDK 8 there is no problem with Base64Url from implementation
point of view.
After some investigation I see some advantages of Base64Url over Base64 and
binary data, the strongest point is maybe that base64 encoding uses
characters that do not work well in URLs and sometimes HTTP headers.
There is raising number of specifications using base64url, e.g.
http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html
MartinV
On Tue, Apr 28, 2015 at 1:53 PM, Martin Grebac <martin.grebac_at_oracle.com>
wrote:
> On 27.04.15 19:26, Romain MB wrote:
>
>> 2015-04-27 18:38 GMT+02:00 Martin Grebac <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
>
> 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
>
>