Re: [IPv6] Case-sensitivity issue of zone identifiers in draft-ietf-6man-rfc6874bis-05

[Brian E Carpenter <[e-mail]>]

The authors will wait for AD and WG Chair guidance after the IESG ballot is
complete.

Personally I prefer David Farmer's suggestion: "For clarity and to avoid
compatibility issues with the URI syntax, this specification RECOMMENDS the
use of lowercase letters only when assigning Zone IDs to interfaces."

Regards
    Brian Carpenter

On 16-Mar-23 05:32, Shang Ye wrote:
> Ted and Brian,
> 
> RFC 8820 says it "targets the authors of specifications that constrain
> the syntax or structure of URIs or parts of them", and is thus, I believe,
> irrelevant when it comes to extending the URI syntax in RFC 3986. IMHO
> my proposal to recommend treating a zone ID as case-sensitive is just as
> backward compatible as the choice of "%" as a delimiter preceding a zone ID,
> because the Zone ID format wasn't at all allowed in RFC 3986 and thus we're
> free to specify the way a parser MUST handle it, let alone we're only discussing
> about a SHOULD.
> 
> I understand Brian's concerns for browsers not being able to follow along,
> but since neither the draft nor RFC 4007 strictly forbids the use of a zone ID
> that contain uppercase letters, there ought to be at least some clarification
> on how parsers should handle such a zone ID, so as to avoid inconsistencies
> in parsing a specific URI before and after normalization.
> Such inconsistencies may include, for example:
> 
>      When a URI, say <http://[fe80::1%En1]>, is parsed without normalization,
>      an application is able to reach the server `fe80::1` through the interface `En1`
>      provided by the parser; however, when the same URI is normalized (zone ID
>      being lowercased) and parsed again, the application may fail to reach the
>      same server through the interface `en1` because such an interface doesn't
>      exist or the two interfaces are different.
> 
> Also, the text in RFC 3986 doesn't really favor either lower or upper case for
> a zone ID. The statement "the scheme and host are case-insensitive and
> therefore should be normalized to lowercase" in Section 6.2.2.1 is in fact
> a bit misleading, considering that percent-encoded octets are normalized
> to *uppercase* within a host component.
> 
> If there weren't percent-encoding in RFC 3986, we would be free to choose
> whether to normalize percent-encoded octets to lower or upper case when
> they are included, as either way the change would be backward compatible.
> I think the current situation is no different from this, except that the zone ID
> is case-sensitive and a zone ID in either case is perfectly valid on certain
> operating systems.
> 
> Regards,
> Shang
> 
> On 2023/3/15 17:50, Ted Hardie wrote:
>> On Tue, Mar 14, 2023 at 8:42 PM Brian E Carpenter <[e-mail]> wrote:
>>
>>     Shang,
>>
>>     You are correct, and I feel that the underlying issue here is that
>>     RFC 4007 under-specifies the Zone ID format, which is very hard to
>>     fix. But the URI syntax is very explicit that "the scheme and host
>>     are case-insensitive." I don't see that we can really override that
>>     with a SHOULD and expect the browsers to follow along. 
>>
>>
>> I think that it is true, and that the guidance on this is pretty clear.   RFC 8820 has this text in Section 2.2:
>>
>> Scheme definitions define the presence, format, and semantics of an authority component in URIs; all other Specifications MUST NOT constrain or define the structure or the semantics for URI authorities, unless they update the scheme registration itself or the structures it relies upon (e.g., DNS name syntax, as defined in Section 3.5 <https://www.rfc-editor.org/rfc/rfc1034#section-3.5> of [RFC1034 <https://www.rfc-editor.org/rfc/rfc8820#RFC1034>]).For example, an Extension or Application cannot say that the "foo" prefix in "https://foo_app.example.com" is meaningful or triggers special handling in URIs, unless they update either the "http" URI scheme or the DNS hostname syntax.Applications can nominate or constrain the port they use, when applicable. For example, BarApp could run over port nnnn (provided that it is properly registered).
>>
>> regards,
>>
>> Ted Hardie
>>
>>     I understand
>>     that it's relatively easy for a stand-alone parser to do this, but
>>     the browser implementations are a different story.
>>
>>         Brian
>>
>>     On 14-Mar-23 19:54, Shang Ye wrote:
>>     > Hi Brian,
>>     >
>>     > I notice that the current version of the draft mentions the case-sensitivity issue
>>     > of zone identifiers in this paragraph:
>>     >
>>     >> RFC 3986 also states that the host subcomponent of a URI is case-
>>     >> insensitive and is normalised to lower case.  The mechanism described
>>     >  > here will therefore fail for zone identifiers that contain upper case
>>     >  > letters, since RFC 4007 implies case-sensitivity.
>>     >
>>     > Indeed it has pointed out the issue, but it doesn't really tell people how a
>>     > zone identifier that contain upper case letters may be resolved. Should
>>     > they pass it directly to a mapping function, say `if_nametoindex`, normalize
>>     > it to lower case first, or, "fail" to resolve it as implied in the paragraph?
>>     >
>>     > When I modified my own URI parser to support rfc6874bis, I felt that the only
>>     > correct option is passing the zone identifier as it is, considering the fact that
>>     > interface names are case-sensitive on Linux. Personally I feel it quite wrong
>>     > to either reject an uppercase zone identifier or turn it into lower case first.
>>     >
>>     > Also, I notice that you doubted that making zone identifiers case-sensitive
>>     > would cause a major problem for the URI parsers in every browser, especially in Firefox.
>>     > I admit that some browsers may have their *URL* parsing code so convoluted that it can be very hard to make the change, but I believe that it isn't
>>     > the case with those relatively simple *URI* parsers that serve other use cases.
>>     >
>>     > Therefore, I'd suggest we instead say somewhere in Section 3 that "URI parsers SHOULD treat a
>>     > zone identifier as case-sensitive and preserve the letter case of a zone identifier when
>>     > it is normalized as part of a URI or mapped into a numeric zone index."
>>     > This way it'd be okay if browser people decide it's unreasonably hard to
>>     > follow this specific requirement, and it would benefit the users of other conforming
>>     > implementations by ensuring that everything goes just as expected.
>>     >
>>     > Regards,
>>     > Shang
>>     >
>>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     [e-mail]
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     --------------------------------------------------------------------
>>