ietf-mta-filters
[Top] [All Lists]

Re: Updated Sieve notification draft

2005-10-14 16:13:13


On Fri, Oct 14, 2005 at 02:53:48PM +0100, Alexey Melnikov wrote:
How about:

The implementation of a notification mechanism may modify the
final message, e.g. truncating it, if it exceeds a length limit,
or modify characters that can not be represented in the
target character set.  The implementation SHOULD keep such
modifications to a minimum.


My current text is:
   The notification method must also specified how Unicode
   characters that that can't be represented by the notification method
   are to be handled. Notification methods MUST be able to represent any
   US-ASCII character with exception of control characters.

Should I just replace it with what you've suggested, or do people feel
that the last sentence is appropriate?

IA5, the GSM character set, does not contain a backquote character
(US-ASCII dec. 96).  There goes "any US-ASCII character".  Do pagers
still exist? The devices I remember from the past contained only numbers.

A small point of clarification here: IA5 and the GSM 03.38 character set are
not the same, and IA5 does include grave accent (aka backquote) as one of its
"IRV graphic character allocations".

These days IA5 is for all intents and purposes the same as US-ASCII. (The
variants that include things like the universal currency sign rather than
dollar sign are rarely used.) The GSM charset, on the other hand, has no direct
representation for most of the IRV graphic characters and does include a bunch
of characters that aren't in IA5 or ASCII (e.g., an ae ligature).

In any case, specifications of mappings to various more restrictive charsets
have been widely used for a long time and seem to work pretty well. X.400-1984
discusses several such mappings in detail, for example. I would therefore
suggest changing the text from "able to represent" to "able to handle" or
something similar.

                                Ned