[Ballot discuss]
Need contact information that works for the authors.

Ted spend a bunch of time with me and explained why the group wanted this and some of the background. I had previous asked if some of the "why this design" could be included in the draft but I realize now this would not improve the draft and would be far too much to include. I am OK with having both the relative and absolute time mechanisms.

I would like to talk about how to improve the advice of when each one should be used. I would guess that the absolute time will have less than perfect results in some time zones for some major vendors. Now it is easy to say theses vendors have bugs and get what they deserver but given they have no intention of fixing theses bugs and don't acknowledge them as bugs - interoperability will suffer. There is nothing this group can do about this or should have to do about this - clearly we can't design for everything being broken. However, I think the relative times will end up having better interoperability in practice. If I was along in this opinion, I would just shut up but it seems that many others share this concern. Clearly the WG feels there are some cases where the relative times will not be usable.

Here's my proposal - we add some text along the following lines

* in general relative times should be used if possible because there the users of the device can see the time and/or time zone that the device thinks it is using and can adjust their behavior accordingly

* if the device knows it's time and time zone, it SHOULD use the relative time and do time zone conversion on the local devices ideas so it uses the local devices idea of time zones - it is possible that the server has a more up to date idea view of time zones but doing it on the device will present the least surprises to the user

* if a device does not know it's time zone but the time request is in "local time", a relative time SHOULD be used

Clearly my text is not using the correct terminology and is not precise enough but I think you get the idea. I'm not sure the correct wording to work this into the draft but I was hoping someone could propose some exact text that we could all consider and see if felt it was an improvement.

Thanks, Cullen

[Ballot discuss]
Ted spend a bunch of time with me and explained why the group wanted this and some of the background. I had previous asked if some of the "why this design" could be included in the draft but I realize now this would not improve the draft and would be far too much to include. I am OK with having both the relative and absolute time mechanisms.

I would like to talk about how to improve the advice of when each one should be used. I would guess that the absolute time will have less than perfect results in some time zones for some major vendors. Now it is easy to say theses vendors have bugs and get what they deserver but given they have no intention of fixing theses bugs and don't acknowledge them as bugs - interoperability will suffer. There is nothing this group can do about this or should have to do about this - clearly we can't design for everything being broken. However, I think the relative times will end up having better interoperability in practice. If I was along in this opinion, I would just shut up but it seems that many others share this concern. Clearly the WG feels there are some cases where the relative times will not be usable.

Here's my proposal - we add some text along the following lines

* in general relative times should be used if possible because there the users of the device can see the time and/or time zone that the device thinks it is using and can adjust their behavior accordingly

* if the device knows it's time and time zone, it SHOULD use the relative time and do time zone conversion on the local devices ideas so it uses the local devices idea of time zones - it is possible that the server has a more up to date idea view of time zones but doing it on the device will present the least surprises to the user

* if a device does not know it's time zone but the time request is in "local time", a relative time SHOULD be used

Clearly my text is not using the correct terminology and is not precise enough but I think you get the idea. I'm not sure the correct wording to work this into the draft but I was hoping someone could propose some exact text that we could all consider and see if felt it was an improvement.

Thanks, Cullen

[Ballot discuss]
Ted spend a bunch of time with me and explained why the group wanted this and some of the background. I had previous asked if some of the "why this design" could be included in the draft but I realize now this would not improve the draft and would be far too much to include. I am OK with having both the relative and absolute time mechanisms.

I would like to talk about how to improve the advice of when each one should be used. I would guess that the absolute time will have less than perfect results in some time zones for some major vendors. Now it is easy to say theses vendors have bugs and get what they deserver but given they have no intention of fixing theses bugs and don't acknowledge them as bugs - interoperability will suffer. There is nothing this group can do about this or should have to do about this - clearly we can't design for everything being broken. However, I think the relative times will end up having better interoperability in practice. If I was along in this opinion, I would just shut up but it seems that many others share this concern. Clearly the WG feels there are some cases where the relative times will not be usable.

Here's my proposal - we add some text along the following lines

* in general relative times should be used if possible because there the users of the device can see the time and/or time zone that the device thinks it is using and can adjust their behavior accordingly

* if the device knows it's time and time zone, it SHOULD use the relative time and do time zone conversion on the local devices ideas so it uses the local devices idea of time zones - it is possible that the server has a more up to date idea view of time zones but doing it on the device will present the least surprises to the user

* if a device does not know it's time zone but the time request is in "local time", a relative time SHOULD be used

Clearly my text is not using the correct terminology and is not precise enough but I think you get the idea. I'm not sure the correct wording to work this into the draft but I was hoping someone could propose some exact text that we could all consider and see if felt it was an improvement.

Thanks, Cullen

[Ballot discuss]
(Edited after the 2006-6-22 telechat.)

Section 4.1, paragraph 2:

>    It is believed that servers will have accurate time, and can trivally
>    convert between these mechanisms.  It is also accepted that the
>    protocol and implementation overhead of offering these two mechanisms
>    is low, and that few interoperability challenges are anticipated.

        In order to prevent messages from being sent at the wrong time,
        it seems important that the server SHOULD/MUST be configured to
        only advertise "future-release-date-time" capabilities if its local clock
        and timezone are accurate. As Russ' DISCUSS indicates,
        delivery at incorrect times can have security implications.

        (Nit: s/trivally/trivially/ also elsewhere in the text)

[Ballot comment]
I'm uncomfortable with the claim that this extension can only be
offered over the submission port.  I can see the reason you don't want
it offered over the smtp port.  However I'm going to be really annoyed
if I try to set up a test server on some random port and it ends up
offering a different feature set because of the port I used.

[Ballot discuss]
Clearly the WG must have had long discussion on why the release-date-time was needed. However, from reading the document, I don't understand why they came to the conclusion they did. I don't understand the argument about a device not knowing it's local time zone. If it does not know it's local time zone or time, how will it specify that it wants something delivered at 8 am local time. I have a hard time imagining a device that does SMTP and has a user interface that could use this feature but does not know it's time zone - I'm willing to believe the WG has a good example, just mention what it is in the draft so that people understand this design decision. I will point out that the two major enterprise mail servers, Exchange and Lotus notes have a different idea about what time it is in some parts of world (such as brazil) some times of the year. If my windows CE based PDA thinks it 8AM in my current time zone, and my IBM mail server thinks it is 7AM in my local time zone, I see all kinds of interoperability problems - for a small part of the year. It would be much easier to let the time zone conversions happen on the client so that any decisions were consistent with what the user expected that device to do with time zones. 

I suspect the date-time approach will be littered with implementation bugs. I think the draft would be better if this was removed. If it is not removed, the draft needs to clearly explain in what situations it should be used and try to limit it to only be used when the other approach would not be possible.

[Ballot comment]
Section 6:
  According to the IANA website, this extension will be added to the
  list of SMTP extensions on the Mail Parameters webpage once this
  draft becomes a Standards Track RFC.

Although I don't think this will be missunderstood by IANA, I think it is a bit incorrect to say that the registration will not happen until it becomes a Standards track RFC. Normally IANA do the registration upon the approval of the document by the IESG and before the publication as an RFC. I think one normally simple request that IANA performs the registration without being explicit about which phase.

[Ballot discuss]
1. Section 3:

      The max-future-release-date-time is a timestamp, normalized to
      Universal Coordinated Time (UTC), indicating the most remote date
      and time in the future until which the MSA will hold messages for
      future release.

This seem to be insufficient specified. No reference or any procedures are specified of how to create the seconds value so that it fulfills the 1-999999999 value allowed by the ABNF. It is not also not clear that we are talking about Absolute timestamps here.

2. Missing ABNF definition: Internet-style-date-time-UTC

The value is not defined. Am I correct that what is intended is the following:

Internet-style-date-time-UTC = date-time
date-time = <See RFC 3339>

[Ballot discuss]
1. Section 3:

      The max-future-release-date-time is a timestamp, normalized to
      Universal Coordinated Time (UTC), indicating the most remote date
      and time in the future until which the MSA will hold messages for
      future release.

This seem to be insufficient specified. No reference or any procedures are specified of how to create the seconds value so that it fulfills the 1-999999999 value allowed by the ABNF.

2. Missing ABNF definition: Internet-style-date-time-UTC

The value is not defined. Am I correct that what is intended is the following:

Internet-style-date-time-UTC = date-time
date-time = <See RFC 3339>

[Ballot discuss]
Section 3:

      The max-future-release-date-time is a timestamp, normalized to
      Universal Coordinated Time (UTC), indicating the most remote date
      and time in the future until which the MSA will hold messages for
      future release.

This seem to be insufficient specified. No reference or any procedures are specified of how to create the seconds value so that it fulfills the 1-999999999 value allowed by the ABNF.

[Ballot discuss]
Section 4.1, paragraph 2:

>    It is believed that servers will have accurate time, and can trivally
>    convert between these mechanisms.  It is also accepted that the
>    protocol and implementation overhead of offering these two mechanisms
>    is low, and that few interoperability challenges are anticipated.

        In order to prevent messages from being sent at the wrong time,
        it seems important that the server SHOULD/MUST only advertise
        "future-release-date-time" capabilities if it is *sure* that its
        local clock and timezone are accurate. As Russ' DISCUSS indicates,
        delivery at incorrect times can have security implications. The
        "future-release-interval" method doesn't seem to require this and
        I can't think of something that can only be done with
        "future-release-date-time" - why not simply remove it?

        (Nit: s/trivally/trivially/ also elsewhere in the text)

[Ballot discuss]
Section 4.1, paragraph 2:

>    It is believed that servers will have accurate time, and can trivally
>    convert between these mechanisms.  It is also accepted that the
>    protocol and implementation overhead of offering these two mechanisms
>    is low, and that few interoperability challenges are anticipated.

        In order to prevent messages from being sent at the wrong time,
        it seems important that the server SHOULD/MUST only advertise
        "future-release-date-time" capabilities if it is *sure* that its
        local clock and timezone are accurate. As Russ' DISCUSS indicates,
        delivery at incorrect times can have security implications. The
        "future-release-interval" method doesn't seem to require this and
        I can't think of something that can only be done with
        "future-release-date-time" - why not simply remove it?

        (Nit: s/trivally/trivially/ also elsewhere in the text)

IANA Last Call Comments:

Uppon approval of this document the IANA will make the following
assignments in the SMTP registry located at:
http://www.iana.org/assignments/mail-parameters

Service Ext EHLO Keyword Parameters Reference
Send in Future FUTURERELEASE number [vanderuil]

We are not sure where in the registry to register the other
new parameters defined:
HOLDUNTIL and HOLDFOR.

The document mentions that there is currently no registry for standard
response codes in SMTP. This document adds to that list, without help
from the mail commuinty, IANA can not create such a registry.

[Ballot comment]
Two comments from the SecDir review Radia Perlman:

  Under security considerations, it says "an MSA that supports future
  message release MUST also support at least one of the authorization
  mechanisms."  That is, the MSA may not require the client use it.
  If this is true, then there needs to be an error that indicates
  that the MSA could not accept your future-release message because
  authentication will be required.

  There is an error for a user exceeding his own quota.  Assuming that
  the MSA is willing to overbook and there are a lot of users using
  this feature, the total shared storage might be exceeded.  Should
  there be a separate error for "you didn't exceed your own quota,
  but I still don't have any room left for your future-release
  message".

[Ballot discuss]
If future-release is being used for something really important, like
  financial results that must not be released until the markets close,
  then the MSA may become more critical.  This ought to be pointed out
  in the security considerations.

[Ballot comment]
Nits from Gen-ART review by Francis Dupont:

- the "MSA" abbrev is never introduced (I suggest to both explain what
  it stands for and to put a reference to n3)
- (in 6) standards-track -> Standards Track
- I can't parse the first statement of 7 (where is the verb "who"
  is the subject?)
- (in 9) Jauuary -> January)