Subject: [Ltru] The special status of i-default in lookup

From: "John.Cowan" <[email-masked]>
Date: Tue, 22 Nov 2005 10:23:54 -0500

"i-default" is a strange beast, like "und" and "mul", and it seems to me
that it should be treated specially in the matching draft.  In particular,
it should be the last chance in an otherwise failing lookup just before
implementation-defined behavior kicks in.

Here's the relevant section of RFC 2277/BCP 18, which is the official
reference for "i-default":

# 4.5.  Default Language
# 
#    When human-readable text must be presented in a context where the
#    sender has no knowledge of the recipient's language preferences (such
#    as login failures or E-mailed warnings, or prior to language
#    negotiation), text SHOULD be presented in Default Language.
# 
#    Default Language is assigned the tag "i-default" according to the
#    procedures of RFC 1766. It is not a specific language, but rather
#    identifies the condition where the language preferences of the user
#    cannot be established.
# 
#    Messages in Default Language MUST be understandable by an English-
#    speaking person, since English is the language which, worldwide, the
#    greatest number of people will be able to get adequate help in
#    interpreting when working with computers.
# 
#    Note that negotiating English is NOT the same as Default Language;
#    Default Language is an emergency measure in otherwise unmanageable
#    situations.
# 
#    In many cases, using only English text is reasonable; in some cases,
#    the English text may be augumented by text in other languages.

I propose that the following paragraph in 3.3 be changed from:

< When performing lookup using a language priority list, the progressive
< search MUST proceed to consider each language range before finding
< the default content or empty tag. The default content might be content
< with no language tag (or with an empty value, as with xml:lang in the
< XML specification), or it might be a particular language designated
< for that bit of content.

to this:

> When performing lookup using a language priority list, the progressive
> search MUST proceed to consider each language range before considering
> the default content.  If content tagged "i-default" is available,
> it is the default content.  Otherwise, the default content is
> implementation-dependent; it might be content with no language tag
> (or with an empty value, as with xml:lang in the XML specification),
> or it might be a particular language designated as the default for
> that bit of content.

-- 
He played King Lear as though           John Cowan <[email-masked]>
someone had played the ace.             http://www.ccil.org/~cowan
        --Eugene Field                  http://www.reutershealth.com

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Thu, 24 Nov 2005 12:20:26 +0900

Hello John,

[co-chairs hat on]
Many thanks for bring this up as an issue.

[co-chairs hat off]
I'm not sure I like your proposal. Although upon careful reading,
it does NOT imply that i-default (and thus (simplified) English)
has to be provided, it may well be read that way.

Such a reading would be inappropriate in many contexts, in
particular Web pages and the like. (In my view, it's more
appropriate for lower level messages.)

So I'd be okay to mention i-default, but in a different way,
just as one possible way to establish an (implementation-defined)
default. See below for my text.

I propose to change it to this:
 > search MUST proceed to consider each language range before finding
 > the default content or empty tag. The default content might be content
 > with no language tag (or with an empty value, as with xml:lang in the
 > XML specification), or it might be a particular language designated
 > for that bit of content, or it might be labeled as i-default [RFC 2277].

Regards,    Martin.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 24 Nov 2005 09:29:00 +0100

A bit of background on i-default:

the canonical context that caused i-default to be created was IMAP error 
messages at login time (before the user is known).
The IMAP people (and I strongly agree with them) felt that it was good to 
have a special language context for the case "negotiation can't be done", 
and felt that it was NOT good to label this with something special like the 
empty string.

So the i-default tag was created - in order to have an explicit label for 
"what we do when we don't know".

>  > for that bit of content, or it might be labeled as i-default [RFC

Actually I'd suggest doing something slightly different. It's relatively 
clear to me that there are a number of issues (ultimate fallback, one or 
many values, scores or not) that are tied more closely to the application 
of the algorithm than to the algorithm itself. So I'd suggest to put 
somewhere (not sure where yet) a paragraph like the following:

   Language tag matching is a tool, and does not by itself specify a
   complete procedure for the use of language tags. Such procedures are
   intimately tied to the application protocol in which they occur.
   When specifying a protocol operation using matching, the protocol
   must specify:

   - Which type(s) of language tag matching it uses
   - Whether the operation has to return a single result (lookup) or a
     possibly empty set of results (matching)
   - For lookup, what the result is when no matching tag is found
     (for instance failure of operation, empty value, or return i-default
     [RFC 2277]).

Then we can remove the concept of "default" or "empty tag" completely from 
the language tag matching algorithm itself.

I think that would be a net win....

                        Harald

---

From: Martin Duerst <[email-masked]>
Date: Fri, 25 Nov 2005 16:59:43 +0900

[co-chair hat off]

Okay, but in our draft, we are talking about something else,
not the state before negotiation, but after negotiation.

Having a paragraph like below is a very good idea in general.

 >Then we can remove the concept of "default" or "empty tag" completely 
from the language tag matching algorithm itself.

I disagree with removing any mention of "default" (except for i-default).
As I said before, there is a thin line between "default" and i-default.
The later by definition includes some form of English, the former doesn't
necessarily do so. There are situations where i-default is appropriate,
and others where it is not. For IMAP protocol startup, it is, but for
HTTP lanugage negotiation, it is not, at least not in my view. So I suggest
to change the last bullet point to something like:

    - For lookup, what the result is when no matching tag is found
      (for instance failure of operation, empty value, returning some
       protocol defined or implementation defined default, or return
       i-default [RFC 2277]).

Regards,    Martin.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 25 Nov 2005 09:09:16 +0100

--On fredag, november 25, 2005 16:59:43 +0900 Martin Duerst 
<[email-masked]> wrote:

> HTTP lanugage negotiation, it is not, at least not in my view.

Full agreement here.

> So I
> suggest

I think your language is better - thanks for expanding on my suggestion!

               Harald