On Tue, 2005-02-15 at 18:42 -0800, Philip Guenther wrote:
Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> writes:
<shrug> Looking again, I see the various IETF webpages aren't
consist on this, some using "email" or "Email", others using "e-mail"
or "E-mail". I find Donald Knuth's argument for "email", as
reproduced by W. Richard Stevens at:
http://www.kohala.com/start/papers.others/knuth.email.html
persuasive, but if there's consensus to go the other way I'll change it.
I don't find that persuasive. the natural progression is "electronic
mail" -> "e-mail" -> "mail". the latter is another keystroke saved. :-)
While the prose of RFC 3028 at least partially addresses the presence
of NUL, HTAB, CR, and LF in scripts, it doesn't ban any other valid
UTF-8 character. Can you speak more on why you think control codes
should be banned from strings and comments?
"they're ugly and will mostly serve as a projectile ejector which users
can aim at their lower extremities".
but I've already changed my mind :-). we need to mimic what [IMAIL]
accepts at least for strings and multi-line strings. to make it easier
to comment out parts of the code, we should not make the syntax for
comments more restrictive.
NUL should be disallowed completely.
if we keep control characters, solitary CR or LF should be accepted just
as any other odd control character.
that is, with no special meaning. this is more lax than [IMAIL], which
says
- CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
the grammar makes it clear that the same is true for the headers. if
you prefer to be as strict as [IMAIL], that's fine by me, too.
If I want to search for control characters in a message's subject
(or body, using the body extension) or include them in a vacation
reply or notification message, why shouldn't I be able to?
for vacation, you can use ":mime" and do the quoted-printable thing
yourself.
there is a slight problem since a header can use encoding to include NUL
and other problematic characters, and the Sieve interpreter undoes this
in order to present it all as UTF-8 or plain octets to the user. I wish
there were an escape for including octets by value in strings, e.g.
"\x00". that would be an incompatible change, can we do that?
(if so, I'd want "\uXXXX" and "\UXXXXXXXX" for Unicode, too (same syntax
as Java and C99))
wrt bracket-comment, I don't think you need to complicate it much more:
bracket-comment = "/*" (*(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) / "*")
"*/"
That, like the version in 3028, permits "*/" in the middle of a
comment.
I don't think so, note the placement of the parentheses. but no matter.
a clarification about ":matches" would be useful: the pattern must match
the entire string.
How about the following for 2.7.1, paragraph 5, first sentence:
The ":matches" match type specifies a wildcard match using
the characters "*" and "?"; the entire value must be matched.
ok, but I think I prefer s/value/value argument/
--
Kjetil T.