Martin J. Dürst wrote:
On 2009/04/12 5:16, Alexey Melnikov wrote:Randy Presuhn wrote:I agree with Randy and Doug that this should stay a SHOULD. If we view this as a protocol between the submitter and the reviewer(s)/list, a MUST is not appropriate because interoperability is possible otherwise, and because there might be good reasons (e.g. the submitter being an expert for a specific language, but not an expert in reading RFCs) to not be able to follow every last detail.From: "Alexey Melnikov" <alexey.melnikov at isode.com>8). In Section 3.5:The fields in the "Record Requested" section SHOULD follow the requirements in Section 3.1.What are the reasons not to follow requirements in Section 3.1? (I.e. why is SHOULD used instead of MUST?)I think the idea was to allow the language subtag reviewer to considerrequests that followed the spirit, if not the letter of the syntax. Sincethe LSR is not an automated process, and we do not want to introduce artificial barriers to those needing language subtags, a littleflexibility is desirable. Consequently, I think the SHOULD is ok - it's operationaladvice, and failure to follow it to the letter won't necessarily cause any problems at all.
Ok.
I understand and agree with the desire to be flexible. However my understanding is that the request sent to IANA must be in the correct form. Maybe you should clarify that.That's already done, a bit lower (currently on the same page, at the bottom, although that might change):Before forwarding any registration to IANA, the Language Subtag Reviewer MUST ensure that all requirements in this document are met.
(Pedantic) This still means that the Reviewer might violate the SHOULD while complying with the MUST.
This includes ensuring that values in the 'Subtag' field match case according to the description in Section 3.1.4 and that 'Description' fields are unique for the given record type as described in Section 3.1.5. The Reviewer MUST also ensure that an appropriate File-Date record is included in the request, to assist IANA when updating the registry (see Section 5.1).I don't think we need more; it's a fate of long and complicated documents that not everything is said in every place where a reader might look for it.
Ok.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.