So, we have an Internet standard process oriented BCP Draft, by the W3C generously imposed to all the Internet protocols, to document the language sub-class of tag object class.
There is a document approved as an RFC on the Editor's desk which describes "the tag URIs also known as 'tags'", i.e. that tag class. This document is authored by gentlemen from HP and W3C. This Draft by gentlemen from IBM and W3C. This RFC soon to be published (draft-kindberg-tag-uri-07.txt) is the Internet document of reference we used as a source of inspiration when documenting the "x-tags", trying to keep two W3C Drafts consistent. Everyone observed it is not that it is not easy.
The Kindberg/Hawke RFC, approved by the IESG, has still be less considered by this WG than the IESG Charter. It is however as well worded as the Draft on some points. So after having tried with the "x-" proposition, we followed Lee Guillam and disengaged through the "0-" escaped sequence. But technically it is unlikely that Draft be accepted if the "x-" does not support Kindberg RFC inheritance.
The difference between the two documents are:- the Kindberg/Hawke RFC has been approved, is open and tag class generic, respects ISO 1179, and includes a disclaimer that it may not reflect the views and opinion of the W3C - the Draft has already failed two Last Calls, is constrained and limited to tag sub-class, is not interested in aligning on ISO 11179 and does not include an IESG or W3C disclaimer.
The problem is that the ABNFs of the two documents (as it was opposed to me) are not compatible. The "x-" format I proposed was Kindberg/Hawke conformant, but was denied by the W3C author of the Draft.
There is therefore a need for the Draft either to include a disclaimer that the "W3C language tag" does not represent the views and opinion of the W3C anymore than the Kindberg/Hawke, or that to the contrary the ambiguity of the Kindberg/Hawker RFC is now clarify and the Draft do represent the views and opinions of the W3C and Unicode, at least for the part of the tag class documenting languages.
Otherwise it is likely that the Draft will be opposed the IESG approved definition of a "tag". The solution seems obvious. It is simply to modify the "x-" ABNF as:
"encapsulates a RFC X- ABNF conformant tag" and to remove the adverse language in 2.2. jfc _______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.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.