Hi,
My comments:
1) Please add a reference to CardDAV (draft-ietf-vcarddav-carddav-10)
alongside LDAP and ACAP in the abstract and introduction (hopefully this
draft will be unblocked by the vcard docs).
Not sure I see the point of adding such a reference, but as long as it doesn't
have the potential of blocking publication it's Mostly Harmless.
2) So most of the document is about external lists of email addresses.
I disagree with this characterization. The language used refers to checking
"membership in an external list". Those members can and will be practically
anything: Addresses, personal names, dates, keywords, IP addresses, etc.
Moreover, the fact that the header test is required to support :list means that
the intent from the start is to be able to use things other than addresses -
if addresses were the only thing that this was about we'd only require support
in the envelope and address tests. And the requirement that string support
:list is also key, since that's opens the door to using, say, header :matches
to capture some component of a header list which you can then check against a
list.
The only place this document restricts list content to addresses is in the case
of redirect :list, which is entirely appropriate in that case. And that's
pretty much the only place besides the examples that email addresses as list
contents are even talked about.
But
then in the example in 2.8.2 we introduce a list of dates. Whilst 2.5 does
suggest that a list of dates might be one option, 2.4 kind of implies other
uses like that ought to be in a separate spec.
It does no such thing. This section is talking about the possibility of adding
list checks to other parts of Sieve and interacting with Sieve in ways other
than as a match type. It isn't talking about expanding what the possible
contents of lists might be - there's no need for that. And I have to say I have
a great deal of difficulty reading the section the way you have.
If we want to officially
support date lists in this spec, then I think that needs to be mentioned in
the abstract and introduction, and described properly in section 2.2.
I strongly disagree with this approach. Trying to come up with a list of
possible things that can be stored in an external list is unnecessarily
proscriptive, not to mention confusing. If anything we need to move in the
opposite direction and be even less specific about how this will be used.
Plus,
the RFC5260 reference ought to be normative. Alternatively we should drop
the date list option from this spec.
Disagree again. Use of something in an example doesn't translate into
a normative reference.
If anything we need more examples of uses and more informational references
along these lines. In fact, how about we add an example like this:
require ["variables", "extlists", "index", "reject"];
if header :index 1 :matches "received" "*(* [*.*.*.*])*" {
set "ip" "${3}.${4}.${5}.${6}";
if string :list "${ip}" "tag:example.com,2011-04-10:DisallowedIPs" {
reject "Message not allowed from this IP address";
}
}
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve