Subject: [EAI] 5738bis / keywords

From: Timo Sirainen <[email-masked]>
Date: Wed, 24 Oct 2012 08:56:49 +0300

I'm guessing this could be too late to add now, but I'll mention it anyway:

People have been wanting to use human-readable strings for IMAP keywords for a while now. But since they're restricted to being atoms, it would require some kind of encoding to do it. There has been a little bit talk about what such encoding could be, but nothing really came out of it. Now would anyway be a nice time to define this easily:

UTF8=* capability advertised by IMAP server means that the client can send UTF8 keywords. ENABLE UTF8=* by client means that the server can send UTF8 keywords to client. For ABNF this simply means:

flag-keyword    = atom / quoted

Conversion between UTF8 and non-UTF8 keywords could be left unspecified (they could simply be hidden).

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 24 Oct 2012 18:52:42 +0800

----- Original Message ----- 
From: "Timo Sirainen" <[email-masked]>
To: "IETF EAI" <[email-masked]>
Sent: Wednesday, October 24, 2012 1:56 PM
Subject: [EAI] 5738bis / keywords

> UTF8=* capability advertised by IMAP server means that the client can send UTF8 keywords. ENABLE UTF8=* by client means that the server can send UTF8 keywords to client. 
>

I do not think that UTF8 keywords are good ideas.

I  can read UTF-8 Chinese characters. But if the server send me the UTF-8 Russian keywords, I can not read it.

Jiankang Yao
>
>For ABNF this simply means:
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 24 Oct 2012 14:00:31 +0300

> I  can read UTF-8 Chinese characters. But if the server send me the UTF-8 Russian keywords, I can not read it.

The idea is that keywords could be used as some kind of an alternative to mailboxes. Their problems would then be exactly the same. The server wouldn't send you russian keywords if you didn't add such keywords..

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Oct 2012 07:13:19 -0400

>> I'm guessing this could be too late to add now, but I'll

See separate note.

>> People have been wanting to use human-readable strings for
>> IMAP keywords for a while now. But since they're restricted
>> to being atoms, it would require some kind of encoding to do
>> it. There has been a little bit talk about what such encoding
>> could be, but nothing really came out of it. Now would anyway
>> be a nice time to define this easily:
>> 
>> UTF8=* capability advertised by IMAP server means that the
>> client can send UTF8 keywords. ENABLE UTF8=* by client means
>> that the server can send UTF8 keywords to client. 

> I  can read UTF-8 Chinese characters. But if the server send
> me the UTF-8 Russian keywords, I can not read it.

And that is exactly why the base SMTPUTF8/EAI specs carefully
avoid allowing non-ASCII header field names and, more generally,
why IETF i18n efforts generally have tried to distinguish
between "protocol parameters" -- fundamental elements of a
protocol and not appropriate for internationalization -- and
text fields of various sorts.

   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Oct 2012 07:25:47 -0400

--On Wednesday, October 24, 2012 08:56 +0300 Timo Sirainen
<[email-masked]> wrote:

> IMAP keywords for a while now. But since they're restricted to
> being atoms, it would require some kind of encoding to do it.
> There has been a little bit talk about what such encoding

Timo, at least in my opinion, the one thing the WG has had
strong and consistent consensus about (at least since we started
on the standards-track work) is that it is important to get this
work finished.  There are people desperately waiting for the
features and groups waiting to deploy code.  So far, everyone
has been very good about delaying deployment before all details
of the standards are settled, but, from various things I've
heard and observed, I don't believe we can count on indefinite
forbearance.  I don't want to be too alarmist about this, but
there is a real chance that each week we delay in getting things
finished and signed off brings us closer to having to deal with
implementations that are incompatible because people didn't (or
couldn't) keep waiting.

So, unless you can make a case that an issue is really an
important showstopper or a problem that was overlooked by the
WG, not just design tuning, I'd appreciate it you would just
drop it (or accept it as the price of coming in late in the
discussion).  Let me say that more strongly, with my co-chair
hat firmly in place: raising "this could have been done a
different way, can we discuss that" or "this would be a nice
time to..." questions/issues at this point is off-topic and
disruptive and I would encourage people to not post them or
respond to them.

The UTF8=ONLY question is a good example of something that it
still on-topic.   It _is_ a showstopper, not because Barry (as
AD) and others are questioning the decision but because the text
in the document was unclear and subject to multiple
interpretations.  That problem, which was brought up during Last
Call and has to be fixed, opens the question of what the WG
really intended (and intends) and, in particular, if "ONLY" is
something we still want and need or whether it is now mostly an
artifact of a time when drafts of the spec had far more options
including the ability to specify whether or not UTF8 was
acceptable on a per-command, rather than per-session, basis.
Had the document been clear, I would have pushed back against
attempts to reopen the design question even if multiple people
were having second thoughts about it, especially if the issue
had not been brought up during Last Call. 

So let's please stop this.  If you want non-ASCII IMAP keywords,
header fields, or anything else, I'd suggest you wait until the
IESG signs off on the current documents and then write an
"updating" specification and see if you can get consensus for
it.  It is not a topic on the EAI agenda.  For the reason
mentioned in my earlier note, I think you will have a lot of
trouble getting traction, but that is just a personal opinion.

regards,
   john

---

From: [email-masked]
Date: Wed, 24 Oct 2012 08:15:15 -0700 (PDT)

> People have been wanting to use human-readable strings for IMAP keywords for
> a while now. But since they're restricted to being atoms, it would require some
> kind of encoding to do it. There has been a little bit talk about what such
> encoding could be, but nothing really came out of it.

I think this is a localization problem, as opposed to an internationalization
problem, and solving it by simply allowing the keywords to represent 
Unicode characters (never mind how) would in fact be the wrong approach.

More specifically, keywords represent some sort of state for the message. You
want that state expressed in the user's language, whatever that happens to be.
This is very different from an address, which should appear appear in the
language chosen by it's owner, irrespective of who the reader happens to be.
(And yes, this last does create problems, none of which are worth rehashing in
this context.)

> Now would anyway be a nice time to define this easily:

> UTF8=* capability advertised by IMAP server means that the client can send
> UTF8 keywords. ENABLE UTF8=* by client means that the server can send UTF8
> keywords to client. For ABNF this simply means:

> Conversion between UTF8 and non-UTF8 keywords could be left unspecified (they could simply be hidden).

I disagree that this is a useful or desirable change. I don't really believe
the mapping of keywords to user-visible strings belongs in IMAP at all. But
what may be needed is a lightweight way to register the meanings of certain
flag names, so that clients can translate them properly.

				Ned