Re: document status: 3028bis, body, editheader


Philip Guenther wrote:

To either head-off or prime the conversation for tomorrow...

draft-ietf-sieve-3028bis-06.txt
-------------------------------

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 think you've missed a couple of issues I've reported:

1). I can't see any text about stripping leading/trailing whitespaces(text moved from the relational extension)2). I think IANA template is not precisely defined, I am not clear onwhat is the difference between "capability name" and "capabilitykeyword"? Is the former supposed to be a human readable phrase? Also,what should be put into "Capability arguments" if an extension supportsmultiple actions/tests.

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
reads:
  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 "?"

I don't think en;ascii-casemap is working on octets. So either thecomparators draft need to be changed, or this sentence need to be changed.

  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
  regular expressions.


As listed in the doc, the open issues are:

My personal answers (chair hat off) to these questions:

1) is 'reject' going back in here as a "do the the best you can" action?

I would rather keep it separate, as reject is still going throughmassive changes.

2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
   when working with an IMAP store?

Yes please.

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.

I agree.

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.

Yes, the text should be carefully worded to make it clear that thisrestriction is on mailstores supporting IMAP.

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.


draft-ietf-sieve-body-03.txt
----------------------------

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.


draft-ietf-sieve-editheader-04.txt
----------------------------------

This has been reading for submission for a while; I think the
write-up is even done.  This last rev was basically editorial.

(Chair hat on): The draft needs to address the issue withleading/trailing spaces.Also there might be some interaction with reject I would like to discuss(I will send a separate email on this).