At 13:25 08/10/02, Phillips, Addison wrote: >> >> [chair hat on] >> I think I have seen very strong opposition to having multiple >> records with the same variant subtag, for implementation reasons, >> and nobody fighting for multiple records as such. Addison and Mark, >> unless this is already covered in -17, can I ask you to draft some >> language covering this (and only this) point? > >I already drafted it in the editor's copy and just proposed removing said >draft for lack of any consensus. draft-18 on inter-locale has the proposed text. I have read all the follow-ups, but I'm responding to this mail because that way, I can express things more clearly. [chair hat on] The above drafted text, as far as I understand, refers to: >>>> Requests to assign an additional record of a given type with an existing subtag value MUST be rejected. For example, the variant subtag 'rozaj' already exists in the registry, so adding a second record of type 'variant' with the subtag 'rozaj' is prohibited. >>>> I think that I'm able to say that we have consensus to exclude multiple records with the same variant subtag. That's exactly what the above paragraph is saying. Therefore, I instruct the editors to consider this very paragraph as part of our official post-lastcall version. I haven't been able to identify consensus beyond this specific issue. [technical hat on] I think that whatever text I have seen so far about semantics, meaning, 4-digit numbers for years, and so on, is either vague to the extent of being of no real use (two reasonable people can come to different conclusions based on the text in many cases) or is too specific, to reach consensus, tending in one or the other direction. Also, while there is in principle the hope that clearer direction in RFC 4646bis would make the work of ietf-languages easier, which would be highly desirable, I haven't seen any example where this would indeed be guaranteed. I therefore think that this is one of the points where we should stop adding additional language just to keep ourselves busy. [chair hat on] Unless I see some clear progress soon towards precise and consise text that addresses a clear need, I plan to close the discussion on further editing regarding this issue in a day or two, so that we finally can move on. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.