java.net.URI and RFC 3986 compliance

[Peter Firmstone]

We can certainly use different constructors and different parsers to 
achieve each form, where it will get interesting is equality.

The existing URI implementation is more likely to give false negatives, 
while RFC 3986 is not likely to, due to its well defined normalisation.

In fact, I'd be inclined to use RFC 3986 for equality and identity if 
possible.

I started listing the differences, java.net.URI also deviates from the 
standard, so those deviations also need to be taken into account, when 
originally implementing RFC 3986 I started from Harmony's URI, however 
3986 uses sufficiently different terminology, such that the strategy I 
used was to create different legal lists for each URI component and 
escape the rest.

Some of the deviations in javal.net.URI were adopted by 3986.

Regards,

Peter.

On 10/07/2014 6:43 PM, Michael McMahon wrote:
> On 10/07/14 09:11, Peter Levart wrote:
>> On 07/10/2014 02:50 AM, Peter Firmstone wrote:
>>> Are there parties on this list interested in updating java.net.URI 
>>> to RFC3986?
>>>
>>> Is there anyone here who has previously attempted this?  If so what 
>>> issues did you find with regard to backward compatibility?
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>
>> Hi Peter,
>>
>> I think It's good that you started this discussion. Since you already 
>> have some experience with RFC3986 and possibly also know the 
>> differences to RFC 2396 (I have just started reading both RFCs, so I 
>> am in no way a relevant source of information in this area), please 
>> feel free to ignore my noob questions...
>>
>> Would it be possible to add a method to URI, say URI.normalize3986() 
>> and leave existing logic of URI unchanged? What could and what 
>> couldn't be achieved by that?
>>
>> Regards, Peter
>>
>
> I think the starting point should be a list of the differences, and 
> then we can see whether additional methods
> would suffice. Apart from anything else, the behavior of each method 
> has to be fully specified and documented in the class.
> I'll try to locate any relevant history.
>
> But, support for RFC3986 is definitely desirable. I agree also, that 
> it shouldn't be predicated on a global switch.
> Additional constructors/factory methods would be one approach, but it 
> is dependent on what the differences are.
>
> Michael
>