Subject: [lemonade] IMAP NOTIFY and IDLE

From: Eric Burger <[email-masked]>
Date: Mon, 23 Jul 2007 06:25:55 -0500

<chair-hat off>

Consider what would happen if someone were to propose an IMAP method that
had a bunch of settings.  Then they said they were going to propose a
*different* IMAP method that was identical to the first method, but with all
of the settings on.

We would say, "method explosion."  If they do the same thing, they should be
the same method.

Is this not the case with IMAP NOTIFY (tell me about events that I am
interested in) and IMAP IDLE (tell me about all events)?

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: "Ben Last" <[email-masked]>
Date: Mon, 23 Jul 2007 12:31:46 +0100

Is the difference that IDLE is in widespread use and is therefore fixed, and NOTIFY is an emerging consensus as a more flexible alternative, for which people are requesting the features that they wish had been included in IDLE?
regards
b

Ben Last
R&D Manager
EMCC Software

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: 23 July 2007 12:26
To: [email-masked]
Subject: [lemonade] IMAP NOTIFY and IDLE

<chair-hat off>

Consider what would happen if someone were to propose an IMAP method that had a bunch of settings.  Then they said they were going to propose a
*different* IMAP method that was identical to the first method, but with all of the settings on.

We would say, "method explosion."  If they do the same thing, they should be the same method.

Is this not the case with IMAP NOTIFY (tell me about events that I am interested in) and IMAP IDLE (tell me about all events)?

---

From: Eric Burger <[email-masked]>
Date: Mon, 23 Jul 2007 06:56:19 -0500

By that argument, we all would still be using X.25.

On 7/23/07 6:31 AM, "Ben Last" <[email-masked]> wrote:

> Is the difference that IDLE is in widespread use and is therefore fixed, and
> NOTIFY is an emerging consensus as a more flexible alternative, for which
> people are requesting the features that they wish had been included in IDLE?
> regards
> b
> 
> Ben Last
> R&D Manager
> EMCC Software
> 
> Consider what would happen if someone were to propose an IMAP method that had
> a bunch of settings.  Then they said they were going to propose a
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and have
> received this message in error, please immediately return this by email and
> then delete it.
> 
>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Jul 2007 15:06:02 +0100

>interested in) and IMAP IDLE (tell me about all events)?
I think IMAP NOTIFY replaces IDLE. For marketing reasons, we don't want 
to remove IDLE from Lemonade Profile Bis. Once NOTIFY is widely 
deployed, IDLE can be removed.

---

From: <[email-masked]>
Date: Mon, 23 Jul 2007 16:41:08 +0300

Hi Alexey,
that does not answer Eric's concern, does it?

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>From: ext Alexey Melnikov [mailto:[email-masked]] 
>Sent: 23 July, 2007 17:06
>To: Eric Burger
>Cc: [email-masked]
>Subject: Re: [lemonade] IMAP NOTIFY and IDLE
>
>Eric Burger wrote:
>
>><chair-hat off>
>>
>>Consider what would happen if someone were to propose an IMAP method 
>>that had a bunch of settings.  Then they said they were going to 
>>propose a
>I think IMAP NOTIFY replaces IDLE. For marketing reasons, we 
>don't want to remove IDLE from Lemonade Profile Bis. Once 
>NOTIFY is widely deployed, IDLE can be removed.
>
>
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 23 Jul 2007 15:51:27 +0200

Eric Burger writes:
> propose a *different* IMAP method that was identical to the first 
> method, but with all of the settings on.
>

No, NOTIFY cann tell you about much more than IDLE. Or much less. 
Client's choice. IDLE applies to 0/1 mailbox(es). NOTIFY to n. IDLE has 
a list of three events (new, changed and deleted messages), NOTIFY n.

There's more too, but this is IMO the answer to your question.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Jul 2007 14:53:15 +0100

On Mon Jul 23 15:06:02 2007, Alexey Melnikov wrote:
> I think IMAP NOTIFY replaces IDLE.

I don't, I think it's a control method for events. Even with NOTIFY, 
some clients won't want EXPUNGE events to be transmitted outside of a 
command, and IDLE is (as it always was) merely a long running 
command, which therefore allows EXPUNGE events. Otherwise, IDLE has 
no impact at all, however it might actually be treated.

NOTIFY also serves double-duty, as it indicates to servers that 
sending events outside of a running command is useful to the client, 
whereas IMAP itself - whilst allowing this - has no mechanism for 
indicating this, and so servers usually behave very conservatively. 
IDLE has almost nothing at all to say equivalent to that side of 
NOTIFY, aside from saying that since clients can't rely on "real-time 
updates", they need to poll anyway.

To put it another way, Eric seems way off the mark here. It happens 
that IDLE is generally used to enter and leave a push-notification 
mode, but the only notifications it definitely has an effect on are 
EXPUNGEs. If all we wanted was to get push-notifications outside of 
IDLE, we could simply mandate them.

A more interesting feature-overlap is between CONTEXT and NOTIFY, 
both of which can control which notifications are considered 
interesting for the client. I'm not yet sure how much overlap there 
really is, and what the best solution for such an overlap is.

Oh, and by X.25, I think Eric meant X.400 P7, surely?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Jul 2007 08:29:50 -0700

>  interested in) and IMAP IDLE (tell me about all events)?

A major benefit of NOTIFY is that it can be used for multiple 
mailboxes, while IDLE only works for the selected mailbox.  I see 
NOTIFY as deprecating or obsoleting IDLE.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
How is the world ruled and how do wars start?  Diplomats tell lies to
journalists and then believe what they read.             --Karl Kraus

---

From: "Douglas Paul-APD028" <[email-masked]>
Date: Mon, 23 Jul 2007 16:47:07 +0100

Please don't shoot me down in flames since I am a newbie on this mailing
list but, if we don't get our finger out won't OMA EMN become the
defacto alternatiive to the NOTIFY mechanism?

Paul Douglas
European CSC
Motorola Limited

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 23 July 2007 16:30
To: Eric Burger; [email-masked]
Subject: Re: [lemonade] IMAP NOTIFY and IDLE

> interested in) and IMAP IDLE (tell me about all events)?

A major benefit of NOTIFY is that it can be used for multiple mailboxes,
while IDLE only works for the selected mailbox.  I see NOTIFY as
deprecating or obsoleting IDLE.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- How is the world
ruled and how do wars start?  Diplomats tell lies to
journalists and then believe what they read.             --Karl Kraus

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Jul 2007 17:03:24 +0100

> defacto alternatiive to the NOTIFY mechanism?
Last I heard, the OMA weren't actually moving EMN forward, but even 
if they were, NOTIFY is concerned with notifications via IMAP, 
whereas the OMA's EMN work is mostly concerned with notifications 
external to the Internet entirely.

So I think they're complementary, rather than alternatives. One item 
of interest is that a client capable of performing NOTIFY and sending 
SMSs could be used to transform NOTIFY's events (sent via IMAP) into 
EMNs (sent via SMS).

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Jul 2007 09:10:09 -0700

At 2:53 PM +0100 7/23/07, Dave Cridland wrote:

>  Even with NOTIFY, some clients won't want EXPUNGE events to be 
> transmitted outside of a command, and IDLE is (as it always was) 
> merely a long running command, which therefore allows EXPUNGE 
> events.

Which clients wouldn't want EXPUNGE events outside of a command? 
Those that use message sequence numbers, of course, but any others?

If a client is architecturally prepared for unsolicited 
notifications, wouldn't it would want them and update its cache from 
them?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Between two evils, I always pick the one I never tried before.
                                                   --Mae West.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Jul 2007 09:14:40 -0700

>  defacto alternatiive to the NOTIFY mechanism?

No shooting or flames, but a few follow-up questions: (1) which OMA 
EMN: the old one with minimal information (just a URL) or the new 
one?  (2) Is OMA updating OMA EMN or did that die?  (3) Lemonade 
always said it intended to use OMA EMN for the format of 
notifications, since the intent is to provide standardization that 
allows EMN to be used (since OMA doesn't specify how the client 
requests notifications nor much about how they are controlled or 
sent).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The illegal we do immediately.  The unconstitutional takes a bit
longer.                                        --Henry Kissinger

---

From: "Douglas Paul-APD028" <[email-masked]>
Date: Mon, 23 Jul 2007 17:27:19 +0100

OMA EMN is implemented and working, not really sure what needs moving
forward on it. Please help me understand your point?

An OMA EMN can be sent/received over WAP Push so it could easily be
received over IP. That is, if the IP bearer is up of course, obviously
that's the major advantage of WAP Push (SMS when IP bearer down, IP when
bearer up).

In regard to your last comment - food for thought, rather than sending
the NOTIFY over SMS.... Why not just send the OMA EMN (which is very
similar to a notify) over IP :-)

/Paul.

Paul Douglas
European CSC
Motorola Limited

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]] 
Sent: 23 July 2007 17:03
To: Douglas Paul-APD028
Cc: Enhancements to Internet email to support diverse service
enivronments
Subject: RE: [lemonade] IMAP NOTIFY and IDLE

On Mon Jul 23 16:47:07 2007, Douglas Paul-APD028 wrote:
> 
> Please don't shoot me down in flames since I am a newbie on this 
> mailing list but, if we don't get our finger out won't OMA EMN become 
> the defacto alternatiive to the NOTIFY mechanism?
> 
> 
Last I heard, the OMA weren't actually moving EMN forward, but even if
they were, NOTIFY is concerned with notifications via IMAP, whereas the
OMA's EMN work is mostly concerned with notifications external to the
Internet entirely.

So I think they're complementary, rather than alternatives. One item of
interest is that a client capable of performing NOTIFY and sending SMSs
could be used to transform NOTIFY's events (sent via IMAP) into EMNs
(sent via SMS).

Dave.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 23 Jul 2007 09:27:23 -0700 (PDT)

> For marketing reasons, [...]

Excuse me?

--lyndon

   Always Mount a Scratch Monkey

---

From: Mark Crispin <[email-masked]>
Date: Mon, 23 Jul 2007 09:27:35 -0700

My opinion:

NOTIFY does not belong in IMAP.  It should be a separate protocol.

This whole idea of making IMAP do things that IMAP does not normally do is 
the kind of creeping featurism that ultimately dooms an effort.

I am eagerly awaiting the extension to IMAP NOTIFY to make it report 
calendar, address book, and task list events.  This will demonstrate how 
foolish it was to put NOTIFY inside IMAP.

-- Mark --

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

---

From: "Douglas Paul-APD028" <[email-masked]>
Date: Mon, 23 Jul 2007 17:29:15 +0100

Please look at OMA EMN... It does all we need right now... 

I think we are in big danger of re-inventing the wheel...

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]] 
Sent: 23 July 2007 17:28
To: Randall Gellens
Cc: Enhancements to Internet email to support diverse service
enivronments; Alexey Melnikov
Subject: Re: [lemonade] IMAP NOTIFY and IDLE

My opinion:

This whole idea of making IMAP do things that IMAP does not normally do
is the kind of creeping featurism that ultimately dooms an effort.

-- Mark --

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Jul 2007 17:34:23 +0100

> forward on it. Please help me understand your point?
Ah, I was under the impression that there was more work considered, 
but it wasn't moving forward. I know basic EMNs are supported 
reasonably widely on handsets.

> similar to a notify) over IP :-)

Yes, that's fine - I'm not saying "send NOTIFY data raw over SMS", 
but "send the equivalent information in a suitable format by a method 
that works better for today's mobile networks". WAP Push sounds 
better than plain SMS, and I certainly had EMN in mind.

Including the provisioning of this within IMAP as an 
Informative/Experimental RFC hack would be fine by me, but I don't 
think it belongs in a Standards-Track document, really for the 
reasons Mark outlines.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Jul 2007 17:47:05 +0100

> Those that use message sequence numbers, of course, but any others?
Can't think of any good reason outside of use of sequence numbers, 
but I'm equally not yet convinced those are worthless. Then again, 
I'm also not convinced by the idea of pushing newly delivered message 
content, either. Maybe I'm just an old-fashioned stick-in-the-mud.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 23 Jul 2007 09:47:15 -0700

On Mon, 23 Jul 2007, Randall Gellens wrote:
> while IDLE only works for the selected mailbox.  I see NOTIFY as deprecating 
> or obsoleting IDLE.

Considering that IDLE doesn't work worth a damn over NAT, and NOTIFY does 
nothing to solve that problem, this is a rather hollow deprecation.

The implementation of IDLE in most clients was a disaster in spite of its 
simplicity.  Microsoft, which helped create IDLE, doesn't follow the 
specification in exiting IDLE before the 30-minute IMAP autologout timer.

UW imapd had to add major kludges to its IDLE support in order to address 
the dual problems poised by NAT and autologout.  Any server that lacks 
similar kludges is vulnerable to the "why does it stop telling me about 
new mail" complaint from Outlook and OE users, and I can assure you that 
users do NOT observe the little "session broken" icon on the status bar. 
Needless to say, the kludges obliviate the benefit of IDLE.

I know that push technology is really sexy, but it is time to take a cold 
shower.  IMAP is fundamentally pull, and it is deployed in link-level 
environments in which pull is presumed.  If you want push, you need to 
deploy it in an environment that supports push.  Note that I say 
link-level.  IMAP is application-level.

Push works so well with Blackberry and similar mechanisms because the link 
level is push-biased.

It's so easy and tempting to say that once an IMAP connection is 
established, you don't have to worry that TCP/IP/NAT are pull-biased, 
since IMAP can undo that damage at the application level.  Resist that 
temptation.  It is as flawed as any other "it works well there, it must 
work well here by definition" fallacy.

If you can't come up with a notification protocol that is resilient even 
when server to client links go away after 1 minute of inactivity, then you 
are better off abandoning the effort now.

-- Mark --

---

From: "Douglas Paul-APD028" <[email-masked]>
Date: Mon, 23 Jul 2007 17:53:48 +0100

My understanding is that High end devices are using IMAP IDLE today
mainly because they are "always on" with newer radio technologies such
as 3G or Wi-fi. Cheaper devices such as 2G/2.75G devices tend to use OMA
EMN today because they tend to be NOT "always on".

Maybe I'm over simplifying this by a huge amount but the reason for
lemonade and OMA EMN was to arrive at a solution for the handset to not
have to poll the network every 29 minutes (as is implicit in IMAP IDLE)?
OMA EMN is a working solution to the problem. 

WAP Push server determines which bearer is up and sends the OMA EMN over
the best method. If IP's around do that, if not default to good old
faithful SMS.

Someone please remind me where the problem is that we are trying to
solve again?

/Paul.

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]] 
Sent: 23 July 2007 17:34
To: Douglas Paul-APD028
Cc: Enhancements to Internet email to support diverse service
enivronments

> forward on it. Please help me understand your point?
Ah, I was under the impression that there was more work considered, but
it wasn't moving forward. I know basic EMNs are supported reasonably
widely on handsets.

> that's the major advantage of WAP Push (SMS when IP bearer down, IP 
> when bearer up).
> 

> similar to a notify) over IP :-)

Yes, that's fine - I'm not saying "send NOTIFY data raw over SMS", but
"send the equivalent information in a suitable format by a method that
works better for today's mobile networks". WAP Push sounds better than
plain SMS, and I certainly had EMN in mind.

Including the provisioning of this within IMAP as an
Informative/Experimental RFC hack would be fine by me, but I don't think
it belongs in a Standards-Track document, really for the reasons Mark
outlines.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 23 Jul 2007 09:54:20 -0700

On Mon, 23 Jul 2007, Dave Cridland wrote:
> Yes, that's fine - I'm not saying "send NOTIFY data raw over SMS", but "send 
> the equivalent information in a suitable format by a method that works better 
> for today's mobile networks". WAP Push sounds better than plain SMS, and I 
> certainly had EMN in mind.

IMHO, this seems like a much more promising direction than trying to 
pretend that IMAP (and TCP/IP/NAT) are push protocols.

If I understand the issues correctly, the advantage of OMA EMN is that in 
the environments where it is really needed, IP would be bypassed and thus 
the whole issue of NAT is irrelevant.

If so, what we need is a "this is how you use OMA EMN with Lemonade 
technology to do the push notifications" document rather than pretending 
that we can provide equivalent facilities exactly within TCP/IP/NAT/IMAP.

-- Mark --

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Jul 2007 17:57:52 +0100

On Mon Jul 23 17:47:15 2007, Mark Crispin wrote:
> I know that push technology is really sexy, but it is time to take 
> a cold shower.  IMAP is fundamentally pull,

Far be it from me to correct the instigator himself, but I always 
considered IMAP to be fundamentally push. It's merely that the client 
can sometimes tell the server when and what to push.

So, for example, EXISTS and the flag-changing FETCH aren't ever 
specifically requested, they're just pushed out. As it happens, 
clients tend to receive these only during a command, but that's 
another matter - I've never seen that as a property of the protocol, 
but of the implementations.

Strange how the same protocol can be seen in two diametrically 
opposed ways, isn't it?

On to practical, rather than philosophical, concerns, I was under the 
distinct impression that, even with a NAT box in place, silent TCP 
connections ought to remain stable, and available for unlateral 
pushing of data by the server - it's only broken NAT boxes that sever 
them if you let them go idle for a few minutes. The problem this WG 
has is that those broken NAT boxes are usually deployed on mobile 
operator's networks, and so we need an interim measure to cope with 
this.

Dave.

---

From: <[email-masked]>
Date: Mon, 23 Jul 2007 20:00:38 +0300

EMN is merely a content type definition - no mechanism whatsoever.

>From: ext Douglas Paul-APD028 [mailto:[email-masked]] 
>Sent: 23 July, 2007 18:47
>To: Randall Gellens; Eric Burger; [email-masked]
>Please don't shoot me down in flames since I am a newbie on 
>this mailing list but, if we don't get our finger out won't 
>OMA EMN become the defacto alternatiive to the NOTIFY mechanism?
>
>Paul Douglas
>European CSC
>Motorola Limited
>
>mailboxes, while IDLE only works for the selected mailbox.  I 
>see NOTIFY as deprecating or obsoleting IDLE.
>--
>Randall Gellens
>-------------- Randomly-selected tag: --------------- How is 
>the world ruled and how do wars start?  Diplomats tell lies to

---

From: <[email-masked]>
Date: Mon, 23 Jul 2007 20:02:05 +0300

BTW,
Dorothy Gellert will provide a status update about OMA MEM during the Lemonade session - please join and ask there.

---

From: <[email-masked]>
Date: Mon, 23 Jul 2007 20:04:52 +0300

Hi Dave,

>Ah, I was under the impression that there was more work 
>considered, but it wasn't moving forward. I know basic EMNs 
>are supported reasonably widely on handsets.

This is correct. There should be an LS regarding this.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 23 Jul 2007 10:31:57 -0700

On Mon, 23 Jul 2007, Dave Cridland wrote:
> Far be it from me to correct the instigator himself, but I always considered 
> IMAP to be fundamentally push. It's merely that the client can sometimes tell 
> the server when and what to push.

The very earliest IMAP designs were push, yes.  But that was back in 1986 
when I was planning that IMAP was to be UDP-based.  I was told that IMAP 
had to be TCP-based, and that forced IMAP into a pull model.

Flow control was, and remains, the problem.  If you want reliability, you 
have to accept that there will be flow control.  And when you have two 
communication paths with mutual dependencies, you have the problem of 
deadlock caused by flow control on one of the paths.

> So, for example, EXISTS and the flag-changing FETCH aren't ever specifically 
> requested, they're just pushed out. As it happens, clients tend to receive 
> these only during a command, but that's another matter - I've never seen that 
> as a property of the protocol, but of the implementations.

It *is* a property of the protocol that server responses only happen 
inside a command.  All that crap in RFC 3501 sections 5.3 and 5.5 are 
window-dressing to quell individuals (now long gone from the IMAP 
community) who refused to accept reality.

Most servers disregard section 5.3, and only send responses during a 
command.  This is not just prudent; it's demonstrably the only thing that 
works.  With the possible exception of a courtesy BYE, a server that sends 
responses outside a command is asking to get deadlocked with just about 
every client in the world.

Section 5.5 is properly seen as command pipelining.  In 1986, people were 
concerned that a SEARCH may take a while because a computer operator has 
to mount a 9-track tape, so there needed to be a way for commands to 
execute out of order.  It was a silly argument then, and is sillier today.

> connections ought to remain stable, and available for unlateral pushing of 
> data by the server - it's only broken NAT boxes that sever them if you let 
> them go idle for a few minutes.

Please give me an example of a non-broken NAT box.  I have YET to find any 
NAT box that can't be induced to drop mappings for idle connections.

The way that it works with pull sessions is that when the client does 
something, it gets a *new* mapping that happens to be identical to the 
previous mapping, and thus everything continues as if nothing happened. 
However, if the server does something, it gets a RST since there is no 
mapping.

> The problem this WG has is that those broken 
> NAT boxes are usually deployed on mobile operator's networks, and so we need 
> an interim measure to cope with this.

I think that you are misunderstanding the scope of the problem.  Broken 
NAT boxes are *everywhere*.  You can't assume that the impact of an IMAP 
extension for mobile devices will be confined to mobile devices.

If IMAP NOTIFY happens, it will be used in environments other than mobile 
devices.  And if it breaks in those environments, then the remedy for the 
breakage will be deployed and will impact mobile device environments.

It is dangerous to focus on a single environment and neglect others.  The 
Law of Unintended Consequences is strictly enforced.

-- Mark --

---

From: Ned Freed <[email-masked]>
Date: Mon, 23 Jul 2007 10:36:03 -0700 (PDT)

> connections ought to remain stable,

Well, I cannot speak to what's theoretically supposed to happen, but what
happens in practice isn't this. NAT timeouts cause connection failures at
fairly short intervals in a large number of cases. I don't know why this is,
but I see it working this way on pretty much a weekly basis from a variety of
service providers.

> and available for unlateral

In  a fair number of cases it acutally doesn't matter if hte session is silent
or not. I see NAT forcing disconnects on active connections pretty regularly.
I also see a lot more address reassignment and other DHCP crapola than there
should be.

Unfortunately the end to end Internet isn't in a lot of cases.

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Mon, 23 Jul 2007 10:47:37 -0700

+1.  Emphatically.

> In a fair number of cases it acutally doesn't matter if hte session is 
> silent or not. I see NAT forcing disconnects on active connections 
> pretty regularly. I also see a lot more address reassignment and other 
> DHCP crapola than there should be.
>

-- Mark --

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Jul 2007 20:21:27 +0100

>> For marketing reasons, [...]

IMAP IDLE is widely deployed in both servers and clients.
People are finally starting to get that IMAP IDLE is push email.

There are no implementations of IMAP NOTIFY.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Jul 2007 11:34:06 -0700

>  Please look at OMA EMN... It does all we need right now...

I thought OMA EMN was one piece, but not the everything.  I'm happy 
to be wrong, of course.

>  I think we are in big danger of re-inventing the wheel...

Can you explain the danger, please?  I don't think anyone wants to do 
that, so if we're missing something, it would be good to clarify.

-------------- Randomly-selected tag: ---------------
Democracy is a form of government in which it is permitted to wonder
aloud what the country could do under first-class management.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Jul 2007 12:05:34 -0700

At 5:47 PM +0100 7/23/07, Dave Cridland wrote:

>  Then again, I'm also not convinced by the idea of pushing newly 
> delivered message content, either. Maybe I'm just an old-fashioned 
> stick-in-the-mud.

I'm sorry, I must have missed something big.  Who suggested pushing 
message content (newly delivered or not)?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Idiot:  A member of a large and powerful tribe whose influence in
human affairs has always been dominant and controlling.
                        --Ambrose Bierce, "The Devil's Dictionary"

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Jul 2007 12:13:10 -0700

At 9:47 AM -0700 7/23/07, Mark Crispin wrote:

>  If you can't come up with a notification protocol that is resilient 
> even when server to client links go away after 1 minute of 
> inactivity, then you are better off abandoning the effort now.

This problem is part of the reason for the deployments document.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Man will occasionally stumble over the truth, but most of the
time he will pick himself up and continue on.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Jul 2007 12:32:36 -0700

>  or not. I see NAT forcing disconnects on active connections pretty regularly.

I hope (perhaps in vain) that the deployments document will help, 
since it explicitly says this breaks mobile email.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Maybe Computer Science should be in the College of Theology.  -
                                              -R. S. Barton

---

From: "Douglas Paul-APD028" <[email-masked]>
Date: Tue, 24 Jul 2007 09:41:44 +0100

My understanding is that it's an email notification mechanism hence the acronym - EMail Notification.

BTW, I wrote the OMA EMN Software Technical Requirements Specification for my employer.

Zoltan - please take a look at http://www.nokia.com/A4297065

Regards,

/Paul.

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 16:44:24 +0300

Paul,
I would like to quote the second half on the EMN specification here:

"This specification defines a content type that can be used to notify e-mail clients that new e-mail is available for retrieval on
an e-mail server. The e-mail notification (EMN) content can be sent using the WAP Push [PUSH] framework to a device
with an EMN User Agent. This specification defines the EMN User Agent to be the client-side application that handles the
EMN and triggers the e-mail client for further action. This specification does not define any normative behaviour for e-mail
clients nor e-mail servers, as both fall out of the scope of the WAP Forum. Furthermore, this specification is independent of
e-mail protocols such as POP3 or IMAP4. Nevertheless, use cases are presented to identify possible usage of the e-mail
notification.
The EMN content type is an application of the Extensible Markup Language (XML) 1.0 [XML]. WBXML [WBXML] tokens
are defined to allow for efficient over-the-air transmission."

It appears that there is no mechanism - only content type. Well, at least "can use WAP Push" is pretty far from mechanism definion on my scale (sounds more like an example). Specifications are open to (mis)interpretation though...

The specification is published on the OMA web site, draw Your own conclusions:
http://www.openmobilealliance.org/release_program/emn_v10.html

>Sent: 24 July, 2007 11:42
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); [email-masked]; 
>[email-masked]; [email-masked]
>the world

---

From: "Douglas Paul-APD028" <[email-masked]>
Date: Tue, 24 Jul 2007 15:50:24 +0100

Hi Zoltan,

Thanks for your reply, I accept the small print is as you describe but I think you'd have to be pretty obtuse to misinterpret what an email notification message is for, given the title and the information provided within the content type OMA EMN.

It's been implemented and tested by your employer and mine as well as several other server and handset manufacturers and is a live service with paying subscribers in a number of regions. 

We need all work together to come up with the best solution for everyone, I don't think that adding another notification mechanism in an area of the business that has already got far too many solutions will help anyone.

Personally, I vote for IMAP Idle in high traffic "always on" situations and OMA EMN in low traffic  "connection on demand" situations - The two solutions aren't mutually exclusive.

I would also like to add that I think the additions that lemonade group has offered in regard to "forward without download", "Quick re-sync", etc, are very valuable additions to the standards and offer solutions to real life primary use cases.

Regards,

/Paul.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 24 July 2007 14:44
To: Douglas Paul-APD028; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lemonade] IMAP NOTIFY and IDLE

Paul,

"This specification defines a content type that can be used to notify e-mail clients that new e-mail is available for retrieval on an e-mail server. The e-mail notification (EMN) content can be sent using the WAP Push [PUSH] framework to a device with an EMN User Agent. This specification defines the EMN User Agent to be the client-side application that handles the EMN and triggers the e-mail client for further action. This specification does not define any normative behaviour for e-mail clients nor e-mail servers, as both fall out of the scope of the WAP Forum. Furthermore, this specification is independent of e-mail protocols such as POP3 or IMAP4. Nevertheless, use cases are presented to identify possible usage of the e-mail notification.
The EMN content type is an application of the Extensible Markup Language (XML) 1.0 [XML]. WBXML [WBXML] tokens are defined to allow for efficient over-the-air transmission."

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 20:14:16 +0300

Hi Paul,
perhaps it was a poor choice of words, so I would like to clarify that I am not arguing against Wap Push.
I simply pointed out that OMA EMN does not define any mechanism, only a content type - therefore there is no such mechanism/protocol as OMA EMN .
The content type defined by OMA EMN can be pushed via various mechanisms, such as Wap Push for example.
I hope this makes it clear.
Thank You.

>Sent: 24 July, 2007 17:50
>Thanks for your reply, I accept the small print is as you 
>describe but I think you'd have to be pretty obtuse to 
>misinterpret what an email notification message is for, given 
>the title and the information provided within the content type OMA EMN.
>
>It's been implemented and tested by your employer and mine as 
>well as several other server and handset manufacturers and is 
>a live service with paying subscribers in a number of regions. 
>
>We need all work together to come up with the best solution 
>for everyone, I don't think that adding another notification 
>mechanism in an area of the business that has already got far 
>too many solutions will help anyone.
>
>Personally, I vote for IMAP Idle in high traffic "always on" 
>situations and OMA EMN in low traffic  "connection on demand" 
>situations - The two solutions aren't mutually exclusive.
>
>I would also like to add that I think the additions that 
>lemonade group has offered in regard to "forward without 
>download", "Quick re-sync", etc, are very valuable additions 
>to the standards and offer solutions to real life primary use cases.
>
>Regards,
>
>/Paul.
>"This specification defines a content type that can be used to 
>notify e-mail clients that new e-mail is available for 
>retrieval on an e-mail server. The e-mail notification (EMN) 
>content can be sent using the WAP Push [PUSH] framework to a 
>device with an EMN User Agent. This specification defines the 
>EMN User Agent to be the client-side application that handles 
>the EMN and triggers the e-mail client for further action. 
>This specification does not define any normative behaviour for 
>e-mail clients nor e-mail servers, as both fall out of the 
>scope of the WAP Forum. Furthermore, this specification is 
>independent of e-mail protocols such as POP3 or IMAP4. 
>Nevertheless, use cases are presented to identify possible 
>usage of the e-mail notification.
>The EMN content type is an application of the Extensible 
>Markup Language (XML) 1.0 [XML]. WBXML [WBXML] tokens are 
>defined to allow for efficient over-the-air transmission."
>
>It appears that there is no mechanism - only content type. 
>Well, at least "can use WAP Push" is pretty far from mechanism 
>definion on my scale (sounds more like an example). 
>Specifications are open to (mis)interpretation though...
>
>>My understanding is that it's an email notification mechanism 
>hence the 
>>acronym - EMail Notification.
>>
>>BTW, I wrote the OMA EMN Software Technical Requirements 
>Specification 
>>for my employer.
>>

---

From: "Glenn Parsons" <[email-masked]>
Date: Tue, 24 Jul 2007 19:40:56 -0400

Folks,

I will remind you ... As I did in the meeting today ... That the use of the EMN format and proposed extensions to make it useful are documented in the Notifications draft (draft-ietf-lemonade-notifications-04).  This draft also describes the LEMOANDE notifications architecture, server to server interaction and an informational SMS delivery.

The feedback we got from OMA MEM in the liaison this week is that EMN extensions are not possible as that work has closed.  So use it as is or do something else -- and OMA MEM is exploring the latter with the OMA Content Delivery group.

Randy volunteered to lead a design team to determine what sort of 'kick notification' (as well as server-server interaction) to describe for the LEMONADE Profile bis context. 

Cheers,
Glenn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 1:14 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lemonade] IMAP NOTIFY and IDLE

Hi Paul,

>Thanks for your reply, I accept the small print is as you describe but 
>I think you'd have to be pretty obtuse to misinterpret what an email 
>notification message is for, given the title and the information 
>provided within the content type OMA EMN.
>
>It's been implemented and tested by your employer and mine as well as 
>several other server and handset manufacturers and is a live service 
>with paying subscribers in a number of regions.
>
>We need all work together to come up with the best solution for 
>everyone, I don't think that adding another notification mechanism in 
>an area of the business that has already got far too many solutions 
>will help anyone.
>
>I would also like to add that I think the additions that lemonade group 
>has offered in regard to "forward without download", "Quick re-sync", 
>etc, are very valuable additions to the standards and offer solutions 
>to real life primary use cases.
>
>Regards,
>
>/Paul.
>"This specification defines a content type that can be used to notify 
>e-mail clients that new e-mail is available for retrieval on an e-mail 
>server. The e-mail notification (EMN) content can be sent using the WAP 
>Push [PUSH] framework to a device with an EMN User Agent. This 
>specification defines the EMN User Agent to be the client-side 
>application that handles the EMN and triggers the e-mail client for 
>further action.
>This specification does not define any normative behaviour for e-mail 
>clients nor e-mail servers, as both fall out of the scope of the WAP 
>Forum. Furthermore, this specification is independent of e-mail 
>protocols such as POP3 or IMAP4.
>Nevertheless, use cases are presented to identify possible usage of the 
>e-mail notification.
>The EMN content type is an application of the Extensible Markup 
>Language (XML) 1.0 [XML]. WBXML [WBXML] tokens are defined to allow for 
>efficient over-the-air transmission."
>
>Well, at least "can use WAP Push" is pretty far from mechanism definion 
>on my scale (sounds more like an example).

---

From: Mark Crispin <[email-masked]>
Date: Wed, 25 Jul 2007 21:50:51 -0700

+1

I spent considerable time a few years ago working on a notification 
protocol, and had a working mock-up demonstrating it, but the NAT problem 
made the whole project unattractive and it got shelved.

I suspect that any effort of push-type protocols in the IETF suite are 
similarly doomed.

On Tue, 24 Jul 2007, Douglas Paul-APD028 wrote:
> Personally, I vote for IMAP Idle in high traffic "always on" situations 
> and OMA EMN in low traffic "connection on demand" situations - The two 
> solutions aren't mutually exclusive.

-- Mark --

---

From: Ned Freed <[email-masked]>
Date: Sun, 29 Jul 2007 07:54:23 -0700 (PDT)

> since it explicitly says this breaks mobile email.

There is a chance that a deployments document might have some impact on how a
wireless service provider sets up their network. Although if past experience is
any indication the impact of such documents will be minimal even in cases where
it is directly and clearly relevant.

However, given current pricing models for wireless services, I expect to see
more and more devices that switch from using their expensive wireless
connection to a free local wifi connection whenever possible. And I can assure
you that the chances of such a document having any effect whatsoever on how
random wifi hotspots are set up is effectively nil. So someone writing either
clients or servers for such devices better not assume the advice in the
deployments document will be followed.

Frankly, we'd be a lot better off spending less time trying to establish
requirements that are going to be ignored in significant cases of interest and
instead spend more time figuring out how to specify client and server behavior
that makes devices actually work well with the networks they are likely to face
in the real world, nasty though they may be.

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Sun, 29 Jul 2007 08:58:17 -0700 (PDT)

On Sun, 29 Jul 2007, Ned Freed wrote:
> requirements that are going to be ignored in significant cases of 
> interest and instead spend more time figuring out how to specify client 
> and server behavior that makes devices actually work well with the 
> networks they are likely to face in the real world, nasty though they 
> may be.

I agree completely.  Entirely too much of the past several years' of work 
seems to be focused on undoing the earliest design decisions of IMAP, 
while pretending that the real world considerations that led to those 
design decisions are unimportant.

Successful efforts work within the framework that exists.  Unsuccessful 
efforts attempt to glom a different and totally incompatible framework on 
top of the existing framework.

-- 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.