> I refer you to RFC 5892, section 5.1 and Appendix B: It might not surprise you, but I don't very much care that IDNAbis did it the wrong way also.
> This is pretty much identical to what IDNA did. I agree that we should > probably recruit the expert (and I hope we can recruit the same expert as > the one for IDNA Derived Properties), but I don't think the task will be > tremendously burdensome, even though it sounds that way. The point of "don't > just copy Appendix A" is to account for the possibility that the Unicode > properties might be moving targets. But for the most part, it's an act of > checking that the properties are "as expected". > > I will contact Patrik and see if he's willing. It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document. The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert. That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture. When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again. It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now. As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed. All that said, we've now had the discussion and Pete has this in hand, so even though I think it was done badly (which is beating up Pete as much as it is the working group), it's time for me to move this to a non-blocking comment. If this sort of thing comes up again, *please* do not do it this way. Get the experts involved earlier, and present the community with a finished document. Barry >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I will move to a strong "yes" on this, once we have some discussion of >> the registry defined in Section 9.1. >> >> The registry created in Section 9.1 is very odd indeed. I guess IANA is >> expected to assume that the format of the registry will look like the >> non-normative table in the appendix, but Section 9.1 doesn't say what the >> format of the registry will be. In general, I see that IANA has asked >> several questions in its review, and those questions haven't been >> responded to (and, unusually, the IANA review is in the IESG mailing list >> archive but *not* in the document history in the datatracker). They >> should be given a response. >> >> But the real oddity here is that the specification of the registry >> involves an *enormous* startup cost for the designated expert, *and* >> requires that the DE be appointed and start her work immediately. >> Normally, IANA takes the required actions as soon as the document's >> approval is announced, but in this case they will have to wait for the DE >> to be appointed and to derive the entire content of the registry. >> >> It seems to me that the right way to have handled this would have been >> for the working group to have engaged the appropriate experts and made >> the table Appendix A *be* the initial contents of the registry, rather >> than explicitly denouncing Appendix A and leaving it as a seemingly quite >> onerous startup task that will delay the IANA actions indefinitely. >> >> Why was it done this way, and what is the plan to get the registry >> content specified in a reasonable time? Should approval of the document >> wait for that content to be specified? Or are we really expecting to >> approve the document with the content of the registry left open? _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
