Re: [Ltru] Re: Small bibliography error in RFC 4930

At 20:39 07/06/18, Frank Ellermann wrote:
>Martin Duerst wrote:
>
> [I've stripped "ietf-provreg" from the Cc: list]
>> Randy made the procedural argument (both RFC 3066 and RFC 4646
>> are BCPs).
>
>Just to clarify, I think you or Randy mean "RFC 3066 used to be
>a BCP before RFC 4646 obsoleted it".

Well, yes, very good point. In that sense, using RFC 3066 instead
of RFC 4646 is actually a bad idea, it means that you are going
to Draft Standard with a reference to something that was a BCP
rather than with a reference to an actual BCP.

>> I have absolutely no clue what could break in an implementation
>> when using a tag that became legal in RFC 4646.
>
>Matching is tricky in the presence of script subtags (and other
>less likely scenarios), it was one line in RFC 3066, now it's a
>separate document.

Yes, that's a valid point (but probably the only one). That means
that in RFC 4930, it might have said something like "this protocol
uses Basic Filtering as defined in RFC 4647 for matching language
tags". But my guess is that not even this is needed.

The protocol just sends languages that the server has available,
and the client is free to use that to pick whichever it thinks might
work (including, e.g., showing the list to a user).

Also, the protocol has some elements where the language can be
indicated. Here is an example, taken directly from the spec:

   - A <msg> element containing a human-readable description of the
         response code.  The language of the response is identified via
         an OPTIONAL "lang" attribute.  If not specified, the default
         attribute value MUST be "en" (English).

There is nothing in terms of matching here, just simple identfication.
[As an aside, there are several points in the above text that are
suboptimal. The first is the use of lang instead of xml:lang.
(Of course, that's difficult to change when going to Draft,
it should have been cought much earlier.)
The second is the last sentence, which seems to prescribe a
value for an attribute that is optional. It would be better if
it were reworded as "If not specified, the implied attribute
value is "en" (English)." A MUST might be appropriate e.g.
to say that the content of the <msg> element has to be English
in the absence of a lang attribute. Using 'implied' is much
clearer, because it's the terminology that XML is using.
The third problem is the use of "en" rather than "i-default".
The later is specifically defined for this fallback purpose.

>It makes perfect sense to exclude some constructs.  When I try
>the language option of a "popular" search engine I won't find
>de-1996 pages while looking for de, or en-GB-oed pages while
>looking for en (I'm too lazy to check what it was, maybe both).

It makes perfect sense for some servers to exclude some languages,
to translate into all languages that even RFC 3066 allows for
tagging would be quite expensive. But that has nothing to do
with the question of which spec to references, it is purely
an implementation/data issue.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru