You are right it is url base64 encoding not the usual base64. I wonder what
are uses cases for this? The only use case where I think one would want to
use binary data provided from some webservice is to display an "inline
image" in a html page. But even in this situation they can use plain
base64...
Otherwise using it in a URL sounds wrong to me...
2015-04-27 19:26 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> 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.
>
> > MartiNG
> >
>