I've looked at the text several times and can't really see what would be useful to add. The best I could come up with is something like "As far as is known, this change will have no impact on non-browser deployments of link-local URIs." (If any of them are using the RFC 6874 format, it won't suddenly stop working.) Any suggestions? Regards Brian On 16-Jan-25 08:27, Brian E Carpenter wrote:
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
