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
