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

[Shang Ye <[e-mail]>]

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