[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
document status: 3028bis, body, editheader
- To: ietf-mta-filters@xxxxxxx
- Subject: document status: 3028bis, body, editheader
- From: Philip Guenther <guenther+mtafilters@xxxxxxxxxxxx>
- Date: Mon, 20 Mar 2006 22:59:50 -0800
- Dkim-signature: a=rsa-sha1; c=nowsp/nowsp; d=sendmail.com; s=tls.dkim; t=1142924391; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:From:To:Subject:Date:Sender; b=SSqFMnc0IrzDKapZ23MbSYbXt JrY4kFWNVgtIx8ddLwSFYcLXAfby6wBfckM8gVLt10UHWJtmd2g5omArYhrZrjk/8uq fOEZ18h9o0cREG+NcQV5htjq3AC02vUKdkeY+Hg4l7ovuzvaUnKWQrOB9o8/EcjZkCL w3HD4n1zWbJQ=
- Domainkey-signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:from:to:subject:date:sender; b=uMuT1hkU83NJtOLun0yxH+Th8X67SCfM5nDVoVZFMUE7iWaJ6W7DpjOSlqcQcWay1 LZ876PMC8qo5afTaICq2f0L0QSv1LqpprbYhZEe6UAcgYZ+j+CQPChBOUG/Vt2vvuCl ej25pqZjziNTg3A2eJKFNyqGNrT+Lk14dhXRRcc=
- List-archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
- List-id: <ietf-mta-filters.imc.org>
- List-unsubscribe: <mailto:firstname.lastname@example.org?body=unsubscribe>
- Sender: owner-ietf-mta-filters@xxxxxxxxxxxx
To either head-off or prime the conversation for tomorrow...
The primary issue for the base-spec has been whether it's description
of matching is inline with that description in the collation doc,
draft-newman-i18n-comparator. I _believe_ the current drafts are
in agreement on the details. Either confirmation or corrections
from others are needed.
I've made one tweak for the next rev to the wording in section 2.7.1
regarding ':match' and the definition of 'character'; I had overlooked
an off-list comment at the turn of the year. The paragraph now
The ":matches" match type specifies a wildcard match using the
characters "*" and "?"; the entire value must be matched. "*"
matches zero or more characters in the value and "?" matches a single
character in the value, where the comparator that is used (see 2.7.3)
defines what a character is. For example, the comparators "i;octet"
and "en;ascii-casemap" define a character to be a single octet so "?"
will always match exactly one octet when one of those comparators is
in use. In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
defines a character to be any UTF-8 octet sequence encoding one
Unicode character and thus "?" may match more than one octet. "?"
and "*" may be escaped as "\\?" and "\\*" in strings to match against
themselves. The first backslash escapes the second backslash;
together, they escape the "*". This is awkward, but it is
commonplace in several programming languages that use globs and
As listed in the doc, the open issues are:
1) is 'reject' going back in here as a "do the the best you can" action?
2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
when working with an IMAP store?
The latter thought actually came about from pondering the description
of fileinto after a suggestion that all the fileinto examples in
spec should use a consistent style of folder naming (e.g., always
using a prefix of "INBOX."). I felt it better to leave the spec
mixed, if just to avoid the implication that a particular style was
meant to be mandated. Indeed, I went ahead and inserted the text
in section 4.1:
Implementations MAY place restrictions on
folder names; use of an invalid folder name MAY be treated as an
error or result in delivery to an implementation-defined folder.
Should it say more than this in either direction? I pondered adding
text about mapping UTF-8 to mUTF-7 and a supporting example (the
the open issues entry), but it couldn't find a wording that didn't
feel like one step too far beyond the scope of sieve.
This had been blocked pending the settling of the comparator/charset
wording in the base spec. Again, I believe it to be in agreement
but confirmation is needed. At that point, this can be put into
the submission queue behind the 3028bis.
This has been reading for submission for a while; I think the
write-up is even done. This last rev was basically editorial.