Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

From: [email-masked]
Date: Mon, 19 Sep 2005 13:00:40 -0500

The complexity I was refering to was to have the server determine the TZ
of the client and calculate into UTC.
It sounds like we all agree that sending UTC is the solution to use, so
the complexity would be avoided.

Corby Wilson

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of ext Mark Crispin
> Sent: Monday, September 19, 2005 13:38 PM
> To: Wilson Corby (Nokia-ES/Pittsburgh)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [lemonade] I-D 
> ACTION:draft-ietf-lemonade-futuredelivery-02.t xt
> 
> On Mon, 19 Sep 2005, [email-masked] wrote:
> > In order to handle date-time delivery, one must always 
> assume the worst
> > case:
> > 1) The client time is NOT synchronized with the server.
> > 2) The client TZ is NOT the same as the server.
> 
> Correct.
> 
> That's why the date-time proposal specifies UTC time.
> 
> > When a user sets a "send on HH:MM DD/MM/YY" request he will 
> be using the
> > client clock to set this, not the server clock (since he 
> can't see it).
> 
> Incorrect.  Why do you assume that he is using either a 
> client or server 
> clock?
> 
> > So the one solution that will give us the least ammount of 
> error most of
> > the time is having the client convert the time into UTC 
> before sending
> > the request to the server.
> 
> Correct.  But note that this is not necessarily the same as 
> "convert the 
> client's time."  This does not even require the client time.
> 
> > What this allows us to do is have the client perform the calculation
> > before sending it to the server.  The user sets a message 
> to be sent on
> > Dec. 25, 2005.  The client calculates the UTC date-time to send the
> > message and sends the request to the server.
> 
> This could be as simple as accepting the user's input as UTC.  A bit 
> fancier is to look up a nearby major city in a table to get 
> its timezone 
> (LG phones have this).
> 
> In no case does it require the client's time.  If I queue a 
> message for 
> release on Dec. 25, 2005, it is irrelevant in a date-time 
> request what the 
> time now is.
> 
> > This method also works for deltas.  The client calculates 
> the UTC+delta
> > time and sends the request to the server.  This way the 
> server just has
> > to maintain a list of event triggers.
> 
> This is only true if the client and server have synchronized time.
> 
> > Personaly I don't think it's worth it to add anymore 
> complexity to the
> > futuredelivery system than this.  The return is too small for the
> > enormeous complexity we need to add to the server to get 
> this to work
> > most of the time.
> 
> What is this "enormous complexity" of which you speak?
> 
> Are you saying that it is too difficult to parse a date-time? 
>  That's a 
> surprise to any IMAP server implementor.  The fact that the 
> date-time is 
> in UTC makes it easier than the task on IMAP?
> 
> Are you saying that it's "enormous complexity" to parse a 
> delta time, add 
> it to the current time, and save that as a future date-time?  
> I agree that 
> this is additional complexity.  But it isn't enormous, and there's 
> evidence that it would help out the people who want to delay for 
> short-term intervals.
> 
> Are you an SMTP server implementor?  I am.  In fact, I wrote 
> one of the 
> oldest still-running SMTP server implementations.  I see no 
> problem with 
> adding date-time.  Delta-time will be annoying, but not too bad.
> 
> It's the clients that I worry about, and the lack of client choice.
> 
> Speaking now with my client hat on, I am EXTREMELY concerned 
> about being 
> forced to send delta-time when I really want to send a 
> date-time.  I have 
> NO use cases for delta-time, but I'm willing to go along with 
> it because 
> some people seem to think that it's important.
> 
> > If the user is too confused when using it, he will
> > stop using it.
> 
> Hence the requirement for date-time.  Your client does not 
> have to use it 
> it it doesn't want to; it can choose to use delta-time exclusively.
> 
> But if date-time is not available in the protocol, I predict 
> that there 
> will be bugs, and that users will be frustrated when their long-term 
> messages are released at other than their intended time.
> 
> H. G. Wells' epitaph comes to mind.
> 
> -- 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.
> 

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 19 Sep 2005 11:08:24 -0700 (PDT)

> the complexity would be avoided.

OK, then, we're on the same wavelength, at least on that point.

I don't think that anyone has seriously suggested sending a date-time in 
any TZ other than UTC for quite a while.  So yes, we all agree that 
sending UTC is the solution to use.

What may have been confusing was that in the past, some of us thought that 
it would be alright to send a date-time in RFC 2822 or IMAP INTERNALDATE 
format; that is, with a mandatory TZ tag.  Although that is effectively 
equivalent to sending UTC time, it raises too many issues of confusion. 
So you can consider that to be a dead idea.

-- Mark --

http://panda.com/mrc