Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)

[Barry Leiba <[e-mail]>]

Don't fall off your collective chair, but, amazingly, I did get another
edit out this morning, a half hour before the deadline.  It addresses
(or specifically ignored) all the items mentioned since the WGLC.  I'll
summarise here....

First, I removed the language about stripping white space, as we
discussed -- that will be clarified in the base spec.

> I miss a section "Interaction with Other Sieve Actions".

I added one.

>    The capability string associated with extension defined in this
>    document is "relational".
> 
> I think this does not belong to "Conventions used in this document",
> but to its own section "Capability Identifier".

I did not put it into its own section, but moved it to the end of
"Introduction".  See below about more extensive editing.

>    The VALUE match type may be used with any comparator which returns
>    sort information.
> 
> And which comparator of the base language does that? All, I guess,
> but I miss reading that.

I agree with Alexey that this information doesn't belong there, and we
already refer to documentation about comparators.  I strongly object to
putting ANY details of specific comparators here.  That's what the
"comparators" document is for (see [Comp] in the non-normative
references).  As Kjetil points out, you will have to look it up in the
definitive reference anyway, if there's any doubt.

> Some of the examples use domain names like "example.com.invalid" --
> why not just "example.com" ?  Not that I expect to ever see a
> ".invalid" TLD but example.tld is supposed to be for examples.

Changed.

> Also, the examples should use "elsif" rather than "elseif".

Changed.

> Some of the examples refer to a test as "being" true or false, and
> others refer to the test as "returning" true or false.  I think
> "returning" is a bad word, and would prefer e.g. "evaluates to" .

I agree; changed.

> Should the "extended example" (section 5) require "fileinto" ?

Changed.

> The last "allof" in the extended example is missing a closing paren.

Changed.

> Change:
>    MUST be declared a require clause as defined in [SIEVE].
> To:
>    MUST be declared in a require clause as defined in [SIEVE].

Changed.

> §2 and elsewhere: change [ACAP] reference to i18n document.

Changed.

> Various places: 'syntax' -> 'usage'

I only saw one.  Why change this?  I left it as it is.

> §3 perhaps there ought to be an informative reference to 'C', or at
> least define it somewhere as 'the C programming language'.

Grumble.  I put that in as "helpful text" in a syntax comment.  No, I'm
not going to change that -- it'd be adding too many words that are
entirely irrelevant to the spec.  I suppose I could change "C" to
"Java", if we all think that it's too unclear what "C" is.

> The phrase 'number of recipients' is not strictly right as From
> addresses can be tested and that is not a 'recipient'.

Changed to "addresses".

> Exactly what are we talking about here? The number of 'addr-spec'
> elements as defined by 2822?

Good point; I've clarified (I've used "mailbox" elements, actually,
after double-checking the 2822 grammar).

> Also, I am not sure about the comment on groups.

Clarified.

> Change:
> 	comparing the total number of "to" and "cc" addresses;
> To:
> 	compares the total number of "to" and "cc" addresses;

Changed.

> Examples: all of the examples use [...] around single string-list
> items, which is not strictly necessary. I always prefer to see the
> most 'compact' syntax representation where ever possible. This is
> just a personal preference.

I understand; and I prefer the syntax that's more easily extended (to
add a second string, for instance).  :-)  No, I don't fee strongly
here, and I'm happy to change it, but I decided to leave it alone,
since it is correct as it is.

> §8: update SIEVE reference to 3028bis.

Changed.

> [My apologies for the delay in this as well.  Barry, you may scowl at
> me when we next meet.]

I owe you a scowl in Vancouver, Philip.

> The leading broilerplate is out of date.  Possibly the trailing
> broilerplate too.

Hm, possibly... but it was accepted by the I-D editor for both the -00
and -01 updates, so I'm not going to change it now.  For more extensive
editing, this ought to be converted to XML.  I'll do that between now
and when we give it to the IESG for RFC-ification, and then it'll be
easier to add or rearrange sections, and it'll pick up the then-current
boilerplate.

> I would suggest striking the second sentence of section 2 ("Any
> comparator used..."), as this document is not the source of that
> requirement and the list of exempted comparators is no longer
> accurate.

Changed.

> The last comma in section 3.1 ("...considered true[,] if any pair...")
> should be removed 

Changed (I'd already caught that one).

> In section 3.2, the phrasing of what the various tests do is a bit
> odd. The first paragraph talks about counting entities, but then
> there's no further mention of "entities".

Hm, I don't think it's odd at all.  I tried just adding "as defined
below"; see if that seems clearer to you.  Does anyone else think this
is odd or confusing?

> The reference to MATCH-TYPE in the ABNF will be rejected as there's no
> previous definition of the MATCH-TYPE non-terminal, not even in the
> base-spec, so it can't be added to with "=/".  I'm not sure what the
> best fix for this is.

For now, lacking time, I left this alone.  If someone has a fix, please
give me text.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam