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

[Shang Ye <[e-mail]>]

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.

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`.

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
>>> --------------------------------------------------------------------
>>>