Subject: RE: [lemonade] Re: date-time and delta time [was RE: I-D ACTION:draft-ietf-lemonade-futuredelivery-02.txt]

From: "Eric Burger" <[email-masked]>
Date: Sat, 17 Sep 2005 18:37:00 -0400

<chair hat off>
Has *anyone*, *anywhere* seen a client that has an option for "deliver
at YY:ZZ time at the recipient's location / particular time zone"?

Does *anyone*, *anywhere* have the requirement to provide such
functionality?
</chair hat off>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Mark Crispin
Sent: Saturday, September 17, 2005 1:58 AM
To: Eric Burger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lemonade] Re: date-time and delta time [was RE: I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.txt]

On Sat, 17 Sep 2005, Eric Burger wrote:
> The implementation cost is someone needs to know how to convert from
> "local time" to UTC.

It all depends upon

> If we're saying the client does the conversion to UTC, UTC and
> delta-time are isomorphic, EXCECPT that UTC *assumes* clock
coordination
> between client and server.  That is a BIG assumption.  Delta-time
always
> works.

Not if I (the human user) want the message to be delivered at 9AM Tokyo 
time.  In order to derive a delta time for this task, the client must 
know:
  . my local time
  . my offset from UTC
  . Tokyo's offset from UTC

In order to derive the UTC date-time for my request, the client only
needs 
to know:
  . Tokyo's time from UTC
and maybe I (the human user) will be required to tell it that.  After
all, 
if the time I need is the time in Glennallen, Alaska, it's doubtful that

many handhelds will know that.

The whole point for allowing a date-time is when the client does NOT
have 
coordinated time, and is merely passing on a user's instructions.

As a thought exercise, consider how you will solve this problem:

1) The protocol only allows delta time.
2) The client's clock is not coordinated with the server, and in fact is
    very likely to be wrong since it's telling you that it's 2AM, the
sun
    is out, and you're not in the arctic in summer.
3) You need to send a message to be delivered after 2PM New York City
time
    today.
4) You'll be fired if it's delivered early or too late.

I think that the people who argue for "delta time only" are thinking 
exclusively about delaying a message for a fixed time, as opposed to 
delaying it until a fixed time.

Nobody is saying that there should be date-time only.  Delta time is 
superior if the user wants a fixed delay interval.  However, delta time 
does not work well if the user wants a fixed time.

We need both on the servers.  If we don't add both on the servers,
sooner 
or later people who need the other will add it as an independent 
functionality.

That will result in servers that do one but not the other; and since 
clients can't depend upon what the server has, clients will have to 
implement both.  I really don't think that you want that outcome.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: "Stephane H. Maes" <[email-masked]>
Date: Sat, 17 Sep 2005 16:09:45 -0700

Eric and all,

I have always been a bit confused by the use cases for this. I have never seen or understood a need for this. 

Furthermore, if you pursue the logic of the discussion, I would expect that it is actually the time zone of the user that matters (not his server or his possible usual location, ...). So if the user travels and uses a mobile client how would this be handled? If the user uses multiple clients (one mobile and one using the server time zone, ...). How will that be managed, especially if users is intermittently connected.

Also if differences are used, will they be between client (sender) and client (recipient) or server (sender) to server (recipient) or client/server or server / client? What happens if a user usually based in US, travels in Europe and wants to send an e-mail that should be delivered later to a user based in Japan who travels in Australia.  Will the behavior change if he sends it from his handheld (In CET) or from his laptop still in US time zone? 

Asking to send the message in absolute 15 hours should work. Anything else may be subject to confusion along the way, isn't it? But if submission to the sender's own delivery server is delayed (i.e. sent from a time zone but synchronized with backend later when in another time zone) or if any delegation to other servers takes place, decisions can again also be incorrect based on what reference time zone / time to use as starting point.

Etc...

Thanks

Stephane

_____
Stephane H. Maes, PhD,
Director of Architecture - OCS & Mobile, Oracle Corporation.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Saturday, September 17, 2005 3:37 PM
To: Mark Crispin
Cc: [email-masked]; [email-masked]
Subject: RE: [lemonade] Re: date-time and delta time [was RE: I-DACTION:draft-ietf-lemonade-futuredelivery-02.txt]

<chair hat off>

-----Original Message-----

It all depends upon

coordination
always

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Sat, 17 Sep 2005 16:13:01 -0700 (PDT)

> at YY:ZZ time at the recipient's location / particular time zone"?

This is a rather dishonest question, because we're talking about a 
capability that requires an as-yet absent extension in SMTP.

*Nobody*, *nowhere*, has seen a client that has an option for "deliver 
after N minutes at the recipient's location."  By your implied argument, 
there is therefore no need for interval either.

Incidentally, if your question was changed to be, "has there ever been a 
mailsystem that has an option to deliver after a stated date-time", then 
the answer is YES.  I wrote one, and used two others.

To some extent, the UNIX "calendar" program has some of this capability; 
but it is quite a bit more primitive than the delayed-mail facility that 
was on the systems that UNIX replaced.

> Does *anyone*, *anywhere* have the requirement to provide such

I have such a requirement.  In fact, it's a pent-up requirement.  It would 
be very nice for me to send delayed mail on modern systems, instead of 
always doing it from TOPS-20 (which has this feature).

What bewilders me is why anyone opposes having date-time in addition to 
interval.  I can understand opposition to a proposal if it wreaks some 
potential harm, but no harm has been indicated for a date-time delay. 
Yet the vehemence that I've heard against doing both suggests that there 
is a perceived threat, even if date-time is stipulated to be in UTC.

I wish that I understand what the threat is.  I have tried to do so, and 
failed utterly.  I wish that someone would enlighten me.

It isn't as if there is anything beyond a trivial effort to support both. 
A server is almost certainly going to translate delta time into date-time, 
if only because very few systems maintain an interval timer across a 
reboot.

As long as servers are required to implement both, clients can ignore the 
form that they don't need to use.

The danger for mobile clients is if Lemonade defines only delta time 
delay; then someone decides to post a specification for date-time delay. 
The unfortunate result would be that some servers will have one but not 
the other, thus forcing clients to implement both.

As a further carrot: I'd implement delta & date-time in a heartbeat, lobby 
hard to get it as a user interface feature in the next version of Pine, 
and otherwise push it.  It's something I've missed ever since I was 
dragged, kicking and screaming, into the UNIX world 18 years ago.  I doubt 
that I would go to such effort for delta time only.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Mark Crispin <[email-masked]>
Date: Sat, 17 Sep 2005 16:18:07 -0700 (PDT)

On Sat, 17 Sep 2005, Stephane H. Maes wrote:
> Furthermore, if you pursue the logic of the discussion, I would expect 
> that it is actually the time zone of the user that matters (not his 
> server or his possible usual location, ...). So if the user travels and 
> uses a mobile client how would this be handled?

Non-issue.  The date-time in the protocol would be in UTC only.  It would 
be completely up to the application program author how the feature would 
be used.

Remember that mobile clients do not constitute the entirety of user 
application space.  I hope that the WG is not seriously suggesting that it 
is a goal of Lemonade to restrict its work to be useless for anything 
other than mobile clients!

-- Mark --

http://panda.com/mrc

---

From: "Stephane H. Maes" <[email-masked]>
Date: Sat, 17 Sep 2005 16:50:55 -0700

Mark,

So you mean that only delivery at a given UTC time is supported and no attempt is made to support delivery at a given local time for the recipient or a certain number of hours after it is sent by the user?

I agree that if that is sufficient, then there may not be any issues of possible confusion.

As I am uncertain of the usefulness of this function, I can't comment if such restrictions are appropriate.

Thanks

Stephane
_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Crispin
Sent: Saturday, September 17, 2005 4:18 PM
To: Stephane H. Maes
Cc: [email-masked]
Subject: RE: [lemonade] Re: date-time and delta time [was RE:I-DACTION:draft-ietf-lemonade-futuredelivery-02.txt]

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Sat, 17 Sep 2005 17:20:33 -0700 (PDT)

On Sat, 17 Sep 2005, Stephane H. Maes wrote:
> So you mean that only delivery at a given UTC time is supported and no 
> attempt is made to support delivery at a given local time for the 
> recipient

Correct.  Such a feature, if offered, would be entirely within the user's 
application program.  In other words, if I am able to tell my mobile phone 
to deliver at 9AM Tokyo time, either I told the phone that "Tokyo time" is 
+0900 or the phone was programmed to know (FWIW, my Seattle mobile phone 
does know that).

> or a certain number of hours after it is sent by the user?

I'm not sure what you mean here.  This *is* available through the use of 
delta time, regardless of whether or not there is date-time.  IIRC, "a 
certain number of hours" would merely be multiplied by 60

> I agree that if that is sufficient, then there may not be any issues of 

Thanks.

> such restrictions are appropriate.

I think that the restriction of UTC-only is fine.  It greatly simplifies 
the protocol as well as the implementation burden demand on servers. 
Applications which don't want to use it can ignore it; other applications 
can be as clever (or not) as they wish.

-- Mark --

http://panda.com/mrc

---

From: Antony Bowesman <[email-masked]>
Date: Mon, 19 Sep 2005 09:26:44 +0300

> at YY:ZZ time at the recipient's location / particular time zone"?

That word "delivery" has crept back in again, also in Stephane's reply.  As has 
been discussed elsewhere, this is not about delivery in any time zone, it is 
about release at a given time in the future with delivery expected some 
undefined time after that.

What leads to this assumption, other than the existing draft text, is that the 
use cases for simple defer-for are less obvious than defer-until.

> Does *anyone*, *anywhere* have the requirement to provide such

Not delivery, no, but release yes.  Our mail system (Teamware Office) already 
provides defer-until which can be used to achieve it.  The MSA does not yet 
support any mapping to this feature from standard clients, although it can be 
achieved using proprietary headers.

However, I also realise the limitation that more than one recipient in more than 
one time zone is, and could not be, possible with this extension.

Antony

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 19 Sep 2005 20:30:31 -0700

> at YY:ZZ time at the recipient's location / particular time zone"?

Can *anyone* *anywhere* point me at a 2821-complaint SMTP server that  
doesn't grok UTC?

Come on guys, this whole discussion has descended into the absurd.  
The server overhead to handle absolute UTC release in addition to  
delta release is below the measurable noise floor. The amount of hot  
air blowing around over this topic would have powered the code  
generators to write the extra few lines of parsers for *all* the  
implementations three time over. It's no damned wonder the IETF has  
little credibility any more.

--lyndon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 20 Sep 2005 09:19:21 +0200

Lyndon Nerenberg writes:
>> Has *anyone*, *anywhere* seen a client that has an option for 
>> "deliver at YY:ZZ time at the recipient's location / particular time 
>> zone"?
>

Not I. But I can't say the same for clients. As Mark said, changing the 
time instead of the timezone is a common enough mistake.

> little credibility any more.

I bought a new (Philips) DECT GAP handset recently. Hand to return it, 
because it couldn't receive calls via the (Siemens) base station. As 
far as I can tell this happened because the GAP standard never bothers 
to make up its mind on a single interoperable alternative.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 20 Sep 2005 08:25:20 -0700 (PDT)

On Tue, 20 Sep 2005, Arnt Gulbrandsen wrote:
> because it couldn't receive calls via the (Siemens) base station. As far as I 
> can tell this happened because the GAP standard never bothers to make up its 
> mind on a single interoperable alternative.

Fortunately, unlike hardware, it is generally possible to remedy 
deficiencies in open-source software.

-- Mark --

http://panda.com/mrc