--On Thursday, March 12, 2015 19:05 +0900 "\"Martin J. Dürst\"" <duerst@xxxxxxxxxxxxxxx> wrote: > Here are some last call comments on > draft-ietf-appsawg-uri-scheme-reg-04. The review was started a > while ago, and completed, but the writeup took a lot of time > and is still not completed, sorry. I may be able to complete > it tomorrow, but please don't hold your breath. > > [Just in case this is necessary, as a process point, I have > seen various tracker messages (such as the draft being placed > on telechat, or that the last call has ended), but I'd like to > note that the Last Call mentions an end date of 2015-03-12, > and it's still 2015-03-12 here in Japan, which means that this > date has barely started in some other locations around the > world.] >... Hi. I had decided to just let this Last Call expire without comment -- my IETF time in the last several weeks has been completely taken up by other issues, notably URNBIS and i18n (IDNA, LUCID, etc.) work on which I'm on the critical path. However, with the last of those drafts posted, Martin's notes and a few recent comments prompt a comment from a slightly different perspective. (1) First, several people have commented, directly or indirectly, about the precision and clarity of the document. I agree: it is less clear and precise than it should be. Clarity and precision are especially important for a document that specifies expert review because there is limited exposure and broad community discussion of these documents. Registration proposal review lists are not a substitute for the type of review that occurs (or should occur) in IETF LC because people with subject matter expertise associated with a particular registration proposal are unlikely to on on those lists. (2) The clarity and precision problem is particularly important in this case because there are issues with the clarity and precision of the underlying documents. Both the apps-discuss and URN mailing lists (and associated WGs) have been treated to long, and mostly, IMO, still unresolved, threads about what RFC 3986 actually means, specifies, recommends, or requires. Regardless of the position one takes on those arguments, having a document that is necessarily dependent on 3986 is problematic unless they are adequately resolved for its purposes and should be considered unacceptable if it substantially or completely ignores those issues. I note that there have been discussions in other forums, including WHATWG, W3C, and private discussions among the latter and relevant ADs, about drafts and proposals that are being developed outside the IETF with the intention of superceding all or part of 3986 in the relatively near future. Regardless of the other effects of those efforts and how the IETF should respond to them, work that is heavily dependent on practical definitions (including definitions-by-practice (aka "running code") as well as 3986) of URIs needs to be completely clear about what it is specifying and expecting. One example arises in passing in Martin's comment (an issue that has also come up in URNBIS and elsewhere). 3986 parsing and semantics are either normative or they are not (the current working assumptions in URNBIS is that semantics need to be excluded for URNs by amending 3986 for that purpose) and, again, this document needs to be clear rather than glossing over the issue and hoping things will work out "by default". (3) Similarly, as soon as a URI-related specification starts to discuss non-ASCII characters, it either needs to link itself _very_ closely to 3986 or it inherently gets tangled up with IRIs. In that area, there is a Proposed Standard (RFC 3987). There was an effort to update 3987 in the IETF that identified a number of (IMO important) issues but that was unsuccessful in resolving then, leading to the effort collapsing. As with 3986, there are now efforts going on outside the IETF to revise or reinterpret the IRI spec and/or to simply fold IRIs and URIs together. Under other circumstances, that situation might result in a "health warning" applicability statement about 3987, but there apparently hasn't been energy to create and debate such a thing. It seems to me that we could have an interesting debate about whether 3986 applies (i.e., no non-ASCII characters except via %-encoded UTF-8), some broader statement about IRIs should be made, or some other direction taken, but that is is not acceptable to not be clear about the options for whatever is being registered. (4) Finally, this Last Call identifies a procedural issue with APPSAEG in particular and perhaps some other Area WGs. The applications area, and hence AppsAWG, span a very broad collection of topic areas (a situation that will certainly become worse with the upcoming reorganization and consolidation). Most participants are active in other WGs (to which they may have primary commitments) and few have the time and expertise to dig deeply into every topic the WG chooses to take up. I favor such WGs as a way to discussion Area-wide topics and to help strike a balance between the overhead of traditional WGs that have highly constrained and topic-specific charters and the use of AD-sponsored individual submissions for immature or controversial drafts. But because of their breadth and the difficulty of assuming that there is a significant number of WG participants who are expert about and examining each specification in careful and appropriately skeptical way, automatic use of two-week IETF Last Calls from the output of such groups may not be consistent with fairness. john