Subject: [sieve] Working Group Last Call: draft-ietf-sieve... autoreply, notify-presence, vacation-seconds

From: Barry Leiba <[email-masked]>
Date: Mon, 11 Oct 2010 10:49:54 -0400

The working group last call ends on these three documents tomorrow
(Tuesday, 12 Oct).  I will post new versions of these tomorrow, which
address all the comments posted during the WGLC period.  If anyone
else has anything to say, please post your comments now.  Thanks.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Oct 2010 11:28:56 -0400

> else has anything to say, please post your comments now.  Thanks.

The updates have been posted (including Robins George's new email
address), and are ready for the PROTO writeups.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 12 Oct 2010 11:56:04 -0400

Hi Barry,

> address), and are ready for the PROTO writeups.

Thank you. The chairs will work on getting the write-ups together and move 
forward with submission to IESG.

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Tue, 12 Oct 2010 10:14:20 -0700 (PDT)

A few comments on http://tools.ietf.org/id/draft-ietf-sieve-autoreply-00.txt.
IMO none of this needs to be addressed immediately.

First, there's a note at the end of the introduction that probably
should be removed at this point. 

All the examples make use of the envelope extension, but none of the require
clauses list it.

The description of the first example says: "which will be used in the response
to the sender" That's not quite right - the status is the entire response. I
suggest changing this to "which will be used as the response to the sender".

Finally, the security considerations section says:

   See the referenced specifications, below for discussion of security
   considerations for Sieve scripts in general, and for each of the
   extensions in particular.

I think the intent is to say the specifications listed in the references
section talk about more general Sieve security issues, but the way it reads,
it sounds like there are references to documents in the security considerations
section, which in fact there are not. Additionally, some of the security
considerations for vacation in particular only appear in the base
specification, RFC 5230. 

I suggest adding an informative (or normative) reference to RFC 5230, and
changing this to directly reference the relevant documents, e.g., something
like:

   [RFC5230] and [I-D.ietf-sieve-vacation-seconds] discuss various security
   considerations associated with use of the vacation extension. [RFC5435]
   and the various method specifications contain similar considerations
   for the notify extension. [I-D.ietf-sieve-external-lists] discusses
   security considerations associated with accessing external lists.

That's it!

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Tue, 12 Oct 2010 19:47:38 -0400

> else has anything to say, please post your comments now.  Thanks.

=======
vacation-seconds

Section 2 heading

nit:
< 2. 'Seconds' Parameter
 > 2. The ':seconds' Parameter

=======
autoreply

no comments. +1

=======
notify-presence

The value of "unknown" should be explicity listed in section 2 for each 
item that can return that value, rather than being mentioned in passing 
at the end of section 2.

I think it would be worth putting a note in somewhere that an 
implementation may wish to cache the results of a call to 
notify_method_capability so that if it is used in a series of if/else 
tests, it only needs to be retrieved once.

     Tony Hansen
     [email-masked]

---

From: [email-masked]
Date: Tue, 12 Oct 2010 17:23:07 -0700 (PDT)

> tests, it only needs to be retrieved once.

Now that you bring this up, I'm tempted to go even further, and say that any
result should be consistent throughout the script. If statuses change and
notify_method_capability returns inconsistent results at different times in the
same script, I could see that causing some unpleasant results.

I did something similar in the date extension - currentdate is required to
use a single, consistent value throughout the script.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Oct 2010 20:49:15 -0400

> A few comments on
> http://tools.ietf.org/id/draft-ietf-sieve-autoreply-00.txt.

Easy enough to do, though; revs are cheap.

> should be removed at this point.

Already removed in the -01 version, after the question was resolved earlier.

> All the examples make use of the envelope extension, but none of the require

Thanks for catching that.  Because envelope isn't an extension, but an
optional feature of the base spec, I forgot that it needed a
"require".  Added.

> suggest changing this to "which will be used as the response to the sender".

I think "in" is as good as "as", here.  But "as" works too, so I've changed it.

> considerations for vacation in particular only appear in the base

I've changed the text to this; let me know if you think it works:

   See the Security Considerations sections of the following
   specifications for discussion of security considerations not covered
   here:
   Sieve base specification [RFC5228]
   Sieve Vacation extension [RFC5230]
   Vacation "Seconds" parameter [I-D.ietf-sieve-vacation-seconds]
   Sieve Externally Stored Lists extension
   [I-D.ietf-sieve-external-lists]
   Sieve Notify extension [RFC5435] (and any applicable notification
   methods)

If you like that text, I'll post an -02 version.

Barry

---

From: [email-masked]
Date: Tue, 12 Oct 2010 18:34:08 -0700 (PDT)

> If you like that text, I'll post an -02 version.

Yes, that looks good - it's enough to warrant that sort of list.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Oct 2010 09:55:18 -0400

> item that can return that value, rather than being mentioned in passing

I don't agree; "unknown" isn't a value of the presence, but an
artifact of retrieving it; I think it's worth keeping that separate.
Would you be happier (I think I would) if I moved it up?  My working
copy now has this as the second paragraph, just before the list:

   This document defines a set of items of notification presence, which
   may be specified in the notification-capability parameter.  The
   script tests the values of notification presence items in the key-
   list parameter.  The values that each item may have are specified in
   the list below; in addition, any item may have the value "unknown",
   if it is not possible to determine the correct value of the item.

> notify_method_capability returns inconsistent results at different times in
> the same script, I could see that causing some unpleasant results.

I like Ned's suggestion, and I will add that.  My working copy now has
this as the third paragraph, just before the list:

   If a particular presence item is tested multiple times within the
   same script execution context, implementations MUST present the same
   value each time (for example, by caching the value on first use).
   This provides consistency within a single execution.

Please let me know if you guys are happy with these changes, and I'll
post a revision.

Barry

---

From: [email-masked]
Date: Wed, 13 Oct 2010 09:09:07 -0700 (PDT)

>    This provides consistency within a single execution.

Sounds good to me.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Wed, 13 Oct 2010 22:46:25 -0400

>     if it is not possible to determine the correct value of the item.

I disagree. For example, under show it says:

	The value of this item is one of the following:

That certainly includes "unknown".

I think it's just easier to include

	unknown - the correct value could not be determined

in the appropriate places.

> Please let me know if you guys are happy with these changes, and I'll
+1

     Tony

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Oct 2010 14:56:01 -0400

> in the appropriate places.

OK.  I still disagree with you, but it's not worth arguing about: as
you say, it's easy to put it in.

I'll add it, and post the next rev now.

Barry

---

From: Tony Hansen <[email-masked]>
Date: Thu, 14 Oct 2010 18:08:32 -0400

> I'll add it, and post the next rev now.

Thanks.

< below; Note
 > below; note
or
 > below. Note

After status definition, add

unknown - The correct availability status could not be determined.

If you add the unknown definition, the entire "Note that in addition" 
sentence phrase can be removed.

     Tony

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Oct 2010 09:13:49 -0400

>> below. Note

Yeah, I forgot to change the semicolon to a period.  We'll get that in AUTH48.

> unknown - The correct availability status could not be determined.

I thought about that, but I don't think I like it.  This is a
human-readable field, and it's made clear that it's not for automated
processing.  It's plain text, most likely set by the user, and it
could be anything, including "unknown".  I don't want to try to
*reserve* the value "unknown" in any way -- we can't, anyway; we have
no control of it.

> sentence phrase can be removed.

It can be, but I think it's worth pointing out separately.

Barry