OK. The LEIRI spec says spaces SHOULD NOT be %-encoded, but it doesn't say MUST NOT, so I will allow this result.

Thanks.  Are you basing you response on the text

"Conversion from a LEIRI to an IRI or a URI must be performed only when absolutely necessary and as late as possible in a processing chain. In particular, neither the process of converting a relative LEIRI to an absolute one nor the process of passing a LEIRI to a process or software component responsible for dereferencing it should trigger percent-encoding."

or something else?

Yes, that's the text I was relying on. Given that we are dealing with a relative LEIRI that is not an IRI, the advice

the process of converting a relative LEIRI to an absolute one ... should [not] trigger percent-encoding

seems to cover this situation rather precisely.

Confirmed fixed.  Thanks.

I'd argue that because resolve-uri returns a new URI, the implementation is at liberty to return a URI, IRI or LEIRI regardless of the input.  Perhaps this could be clarified in the specification?  It's not _just_ converting from a relative to an absolute URI.

I'm re-opening this as a spec bug, because the final comment suggests that clarifications to the spec are needed. Also, the agreed resolution for this test contradicts the expected result of various XSLT tests including type-functions-0304 and resolve-uri-022, and I don't want to argue for a change to those tests unless and until the spec is clarified.

The spec for resolve-uri currently says 

<quote>
The function resolves the relative IRI reference $relative against the base IRI $base using the algorithm defined in [RFC 3986], adapted by treating any ·character· that would not be valid in an RFC3986 URI or relative reference in the same way that RFC3986 treats unreserved characters. No percent-encoding takes place.
</quote>

This seems to unequivocally say that if there is a space in the input, and if the implementation chooses to accept this (as a LEIRI), then there must be a space in the output, not a "%20". The argument in this bugzilla thread that LEIRI permits escaping seems vacuous, because the resolve-uri() spec does not reference LEIRI for how relative URI resolution is performed. Perhaps it should.

On the one hand, I'm happy to withdraw my original request in Comment #0.

On the other hand, the specification says 

"In addition, the implementation may accept some or all strings that conform to the rules for (absolute or relative) Legacy Extended IRI references as defined in [Legacy extended IRIs for XML resource identification]. "

One way in which an implementation might accept a LEIRI is to convert it to an IRI as per "4 Conversion of Legacy Extended IRIs to IRIs" [1] before proceeding with the rules 1 to 4 which are always stated as operating on IRIs.


[1] http://www.w3.org/TR/leiri/

DECISION: The way URI resolution is done for a LEIRI is implementation-defined and may involve use of percent-encoding to translate the LEIRI into a valid IRI.

I'm going to push back on that decision. 

(1) We currently define (implicitly) an algorithm for resolving a relative LEIRI: "using the algorithm defined in [RFC 3986], adapted by treating any ·character· that would not be valid in an RFC3986 URI or relative reference in the same way that RFC3986 treats unreserved characters". (This directly reflects the way RFC 3987 defines URI resolution for IRIs).

(2) This algorithm does not trigger percent-encoding.

(3) This is consistent with what the LEIRI spec says (see http://www.w3.org/TR/leiri/ (section 4)): 

In particular, neither the process of converting a relative LEIRI to an absolute one nor the process of passing a LEIRI to a process or software component responsible for dereferencing it should trigger percent-encoding.

Tim suggests "One way in which an implementation might accept a LEIRI is to convert it to an IRI as per "4 Conversion of Legacy Extended IRIs to IRIs" [1] before proceeding with the rules 1 to 4 which are always stated as operating on IRIs." - but that is inconsistent with the LEIRI spec, which says "Conversion from a LEIRI to an IRI or a URI must be performed only when absolutely necessary and as late as possible in a processing chain."


I don't think the algorithm is completely implementation-defined, and the LEIRI spec, while it doesn't define an algorithm for URI resolution, says that percent-encoding SHOULD NOT take place.

So my proposal is instead to add a Note as follows:

RFC3986 defines an algorithm for resolving relative references in the context of the URI syntax defined in that RFC. RFC3987 describes a modification to that algorithm to make it applicable to IRIs (specifically: additional characters permitted in an IRI are handled the same way that RFC3986 handles unreserved characters). The LEIRI specification does not explicitly define a resolution algorithm, but suggests that it SHOULD NOT be done by converting the LEIRI to a URI, and SHOULD NOT involve percent-encoding. This specification fills this gap by defining resolution for LEIRIs in the same way that RFC3986 defines resolution for IRIs, that is by specifying that additional characters are handled as unreserved characters.

Correction, in the last paragraph replace the last occurrence of RFC3986 with RFC3987.

The change in comments 8/9 was accepted, and has been applied to the spec. The test case has been modified accordingly.