Subject: [lemonade] LDELIVER

From: Antony Bowesman <[email-masked]>
Date: Wed, 03 Aug 2005 18:10:40 +0300

Hi,

The multicast streaming did not pick up the room discussion on LDELIVER at the 
end of today's session, but I wanted to understand the justification for adding 
another delivery mechanism over and above the trio and existing SMTP.

IMHO, this extra, optional feature increases the complexity of client 
implementations through additional code paths, something the discussions wanted 
to avoid.

If the trio must be supported in Profile v1, does LDELIVER add any value other 
than the stated simplification of deployment (arguably not an issue with 
improved device provisioning).

Some disadvantages
- The lack of NOTARY.  It may cause further client implementation problems for 
clients that offer DSN support and want to support p-imap.
- DELIVERBY no longer possible
- It introduces a conflict with FUTUREDELIVERY which would not be possible.
- Other MAIL FROM extensions
- It complicate the process of developing and adoption of new SMTP extensions.

Antony

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

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 3 Aug 2005 08:34:59 -0700

> implementations through additional code paths, something the discussions wanted

I strongly agree.

I also thought we had decided, after much pain and suffering, not to
pursue a "imap push" type design, which is *exactly* what LDELIVER
looks like.

Additionally this new mechanism is extremely limited in functionality,
something else that the original discussions also specifically wanted
to avoid.

-Rob

(Also, nit: the LDELIVER document has way, way, way more authors than
the IESG allows -- did it really take 14 people to write a 13 page
ID?)

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

---

From: Edwin Aoki <[email-masked]>
Date: Wed, 03 Aug 2005 08:38:35 -0700

There wasn't much discussion around LDELIVER, other than an exchange 
where Stephane indicated that:
* the concern was that there would be some lag before implementation of 
the trio was widespread, and
* the mobile community has gone forward with implementations of LDELIVER 
(or, rather, of its predecessor, XDELIVER), so there's some desire to 
get it standardzied.

I share some your concerns around LDELIVER, not the least of which is 
the overlap with existing work in this WG. 
I'd like to suggest that the way forward for this is to agree that the 
trio is the way that this working group should support forward without 
download (and recommend to OMA that they do the same).  We can further 
suggest that the existing implementation of LDELIVER can be published as 
an informational or experimental draft to document the existing protocol 
extension for those mobile constituents that want to move forward in the 
interim.

My 2c...
-Edwin Aoki
-Chief Architect, America Online

[email-masked] wrote:

> Hi,
>
> The multicast streaming did not pick up the room discussion on 
> LDELIVER at the end of today's session, but I wanted to understand the 
> justification for adding another delivery mechanism over and above the 
> trio and existing SMTP.
>
> implementations through additional code paths, something the 
> discussions wanted to avoid.
>
> If the trio must be supported in Profile v1, does LDELIVER add any 
> value other than the stated simplification of deployment (arguably not 
> an issue with improved device provisioning).
>
> Some disadvantages
> - The lack of NOTARY.  It may cause further client implementation 
> problems for clients that offer DSN support and want to support p-imap.