Randy Presuhn wrote: [...]
General: I hope the WG has discussed "let's remove all registrations from the document before publication" approach. Personally I would rather the document contain IANA registrations upon publication.Yes, this was discussed at some length back when the WG produced RFC 4645. There was considerable concern that if the content were left in the RFC, even with health warnings, the risk would be too great that developers would use the RFC rather than the registry.
Either way is fine with me, as long as this was discussed in the WG.
1. Introduction[...]In its initial phase as an Internet-Draft, this memo also contained a complete replacement of the contents of the Language Subtag Registry to be used by the Internet Assigned Numbers Authority (IANA) in updating it. This content was deleted from this memo prior to publication as an RFC.Is this paragraph useful? If the content is deleted when the updated RFC is published, this doesn't give a reader any useful information. If the content is not deleted when the updated RFC is published, then this text would be wrong.It's there to explain the absence of content in the RFC. Without it, the document would be puzzlingly content-free. We were pretty much painted into this corner by the rules on references to I-Ds, etc. Back when we did 4645, we considered many alternatives, and this was the path that got consensus. When we started the update, the question was raised whether we wanted to go this route again, but there was no groundswell of support for any alternative.I think there is at least one more place where there is a similar issue.There is strong consensus to delete the content upon publication. If we had known of a tidier way of delivering the bulk update to IANA, we'd have used it. I've just picked a nearly random registration from the document:Type: language Subtag: orv Description: Old Russian Added: 2029-09-09I am confused here. Why is the "Added" date in the future?See section 2.1: The values of the File-Date field, the Added date for each new subtag record, and the Deprecated date for each existing grandfathered or redundant tag deprecated by this update were set to a date as near as practical to the date of IESG approval of this memo. [RFC EDITOR NOTE: these dates are initially set to 2029-09-09 for easy recognition, and MUST be updated during AUTH48.]
Ah, I've missed that. Thanks.
6. Changes [RFC EDITOR NOTE: this section is provided for the convenience of reviewers and will be removed from the final document.] This memo is a new work, not an incremental update of [RFC4645]. The procedure for populating the original Language Subtag Registry, specified by the earlier [RFC4646], is included by reference to [RFC4645]. Therefore, no changes from [RFC4645] are listed in this section.I am not sure I understand this comment and I don't think I find it convincing. At least one of the acting ADs thinks that any XXXXbis draft must contain "Changes since RFC XXXX" section, which tries to summarize all major changes. (I.e. the AD would put a DISCUSS on the document until this is resolved). Personally I find a section listing all changes to be very useful, but I don't consider lack of it as a blocking issue.If the document is really not a bis draft, then the draft name is confusing.We did discuss whether an incremental update or bulk-replace update was easier to cope with, and opted for the bulk-replace approach. To describe the detailed differences in the changes section would be counterproductive at best. If this MUST be done to clear a potential DISCUSS, perhaps a compromise would be to add a summary of the form "XXX new records added, YYY old records modified." Actually listing all the new ones would NOT be something I'd like to even consider.
I understand. No, I am not asking for this.
I think the scientific term is "a gazillion," and would nearly double the length of the document, which might make it a little unwieldy. :-) I *would* consider asking the editor to list the ones to which changes (other thatn formatting changes) were made (without detailing the nature of the change),
That what I had in mind.
but only if (1) necessary to clear a DISCUSS, and (2) endorsed by the WG.
This is fine with me.
However, my strong preference is to provide no more detail than is absolutely necessary, particularly since the body is to be gutted as part of the publication process anyway.
Ok.After your explanation I think the sentence that reads "This memo is a new work, not an incremental update of [RFC4645]" should be reworded or removed. Otherwise it is just asking for a question: "if this is new work, how come it is 4645bis"? At least it is not clear to me what the WG is calling "new work".
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.