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

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

On 18-Mar-23 01:36, Shang Ye wrote:
> Now that I think about it, there could be another solution to the issue, that is:
> 
> State that the zone ID in a URI is case-sensitive, that implementations MAY treat it as case-insensitive and normalize it to lower case, and that the use of uppercase letters in a zone ID is NOT RECOMMENDED.

Yes, I think that works. I think we've also established that the complex interface names with constructs like A/1/2/3 will be considered out of scope, because of their specialized use in infrastructure devices.

> 
> I agree that it's possible that we state that the zone ID in a URI is case-insensitive and is normalized to lower case, but then comes the question:
> 
> Can we make applications use the zone ID in a URI only after it is normalized to lower case?
> 
> AFAIK, many URI parsing libraries (especially those zero-copy ones) perform no normalization when parsing a URI string. They instead provide index ranges (or substrings) of each component within the string. Applications may then use the components however they like, including passing a zone ID containing uppercase letters directly to `if_nametoindex`.

Historically, I think the case-insensitive rule for the host part is directly inherited from DNS, so indeed normalization is not required. I think we can note that normalization is not required, but imposing that as a rule on browser implementations is not going to work. (It was the assertions in RFC6874 about browser behaviour that most annoyed the browser community.)

Thanks
    Brian

> 
> For this reason, I personally feel that it's better for these libraries to treat zone IDs as case-sensitive when updated to support the zone ID format, for the sake of consistency.
> 
> Considering the past discussions on the issue, I provide a possible replacement for the paragraph in question:
> 
>     The zone identifier in a URI is case-sensitive. However, considering the broad promise in RFC 3986 that the host subcomponent in a URI is case-insensitive, implementations MAY treat the zone identifier in a URI as case-insensitive and normalize it to lower case. It is therefore NOT RECOMMENDED to assign to an interface a zone identifier that contain uppercase letters, to avoid compatibility issues with the URI syntax.
> 
> Which may be moved a bit up in the document if approved.
> 
> Regards,
> Shang
> 
> On 2023/3/16 3:54, Brian E Carpenter wrote:
>> 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
>>>> --------------------------------------------------------------------
>>>>