Personally I agree with David. I'm not sure if we need to add a further "out of scope" comment about this to the draft, since it is already explicit that we don't change URI syntax.
The only case I personally know of where a link-local URI is used in a non-browser context is CUPS, which solved the problem by using the "IPvFuture" branch of RFC 3986. We intentionally removed that use case from the present draft because it doesn't have a UI aspect.
(In any case, thanks to Magnus for the review.)
Regards
Brian Carpenter
On 16-Jan-25 06:17, David Schinazi wrote:
Hi Magnus,
To me, draft-ietf-6man-zone-ui was pretty clear that - if approved - there is now no way to use zone IDs on the Web. It doesn't provide guidance for what to do instead, but I don't think that draft-ietf-6man-zone-ui needs to provide that guidance. There is guidance in draft-schinazi-httpbis-link-local-uri-bcp, which summarizes to "use .local instead", but that draft does not have any kind of community consensus. I think we should keep the current split: draft-ietf-6man-zone-ui removes the broken Web feature by obsoleting 6874, and if we want to build a new solution - or provide new guidance - that's left as future work that can be taken up by draft-schinazi-httpbis-link-local-uri-bcp or another draft in HTTPBIS.
David
On Wed, Jan 15, 2025 at 4:57 AM Magnus Westerlund via Datatracker <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote:
Reviewer: Magnus Westerlund
Review result: Ready with Issues
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx <mailto:tsv-art@xxxxxxxx> if you reply to or forward this review.
I found an issue that appear that it needs clarification. So this document has
this statement:
In this model, the zone identifier is considered independently of the
IPv6 address itself. However, this does not in itself resolve the
difficulties in considering the zone identifier as part of the HTTP
origin model [RFC6454]. Therefore, this approach does not resolve
the issue of how browsers should support link-local addresses,
discussed further in [I-D.schinazi-httpbis-link-local-uri-bcp].
Because of this, the recommendations and normative statements in this
document do not apply to web browsers.
After having read [I-D.schinazi-httpbis-link-local-uri-bcp] I think there are a
generic issue for an URI using protocol that uses URI's in the UI, even if it
primarily have been discussed in the context of web browsers. In those cases
one still will struggle with including a method for specifying the zone
identifier. So should this aspect be clarified in this document that it is
desirable for any URI application to find a way to enter the zone ID but that
if the place to add it would be the URI then one would end up in the same
problem as with the obsoleting of RFC 6874 there are now also no specification
for how zone ID are included in URI, even if they are only input usage only and
do not make sense to include in inside the protocol.
--
last-call mailing list -- last-call@xxxxxxxx <mailto:last-call@xxxxxxxx>
To unsubscribe send an email to last-call-leave@xxxxxxxx <mailto:last-call-leave@xxxxxxxx>
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
