Re: [lemonade] WGLC Architecture

[Alexey Melnikov <[e-mail]>]

Eric Burger wrote:
> Work Group Last Call for the Lemonade Architecture document  
> (Informational) has begun and will end 2 June 2008.  Note that at IETF  
> 71 (and on the list via the posting and acceptance of the minutes), we  
> were planning on a 3-week WGLC.  However, that presupposed a  
> concurrent WGLC of profile-bis.  Since profile-bis is not ready, we  
> will use a normal two week WGLC.
>
> The draft is at:
> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-architecture-02.txt
>   
I've just reviewed the document and it looks good in general. But I have 
some comments (mostly minor):
> 2.2.1.  OMA MEM logical Architecture
 [...]
>    o  Other OMA enablers are needed to directly support the mobile email
>       enabler.  They are out of scope of IETF but they may include
>       support for:
>       *  Client provisioning and management for over the air
>          installation of the MEM client on the device, provisioning of
>          its settings and revocation, and
>       *  Messaging enablers for out-of-band notification, where out-of-
>          band notifications that are server to client event exchanges
>          not transported by the MEM protocol but via other channels.
Should this also mention charging? Charging is a part of OMA MEM 
architecture.
> 2.2.2.2.  OMA MEM deployment cases
>
>    OMA MEM identifies that each component (MEM client, MEM servers,
>    other enablers, and the email server) may be deployed in different
>    domains, possibly separated by firewalls and other network
>    intermediaries.  MEM proxies may be involved in front of firewall
>    that protects the MEM server domain.
>
>    OMA MEM targets support of configurations where:
>    o  All components are within a same domain, such as in a mobile
I think "a same domain" should be changed to either "a single domain" or 
"the same domain"?
>       operator

> 3.  IETF LEMONADE Architecture
 [...]
>    The LEMONADE profile [PROFILE] assumes:
>    o  IMAP protocol [RFC3501] including LEMONADE profile extensions
>       [PROFILE]
>    o  SUBMIT protocol [RFC4409], including LEMONADE profile extensions
>    o  LEMONADE profile compliant IMAP store connected to MTA (Mail
>       Transfer Agent) via ESMTP
My Lemonade server is not connected over ESMTP. It is connected over 
LMTP to our MTA which is connected over ESMTP to the rest of the world.
I don't think Isode's implementation is unique in this respect and I 
don't see a reason why the document should be limiting this.

I would suggest rephrasing this to say something like "LEMONADE profile 
compliant IMAP store. Email can be delivered to this store over ESMTP".
> [RFC1861]
Please change [RFC1861] ("Simple Network Paging Protocol - Version 3 
-Two-Way Enhanced") to [RFC2821]
>    o  LEMONADE profile compliant Submit server connected to MTA via
>       ESMTP
>    o  Lemonade profile message store / submit server protocols (URLAUTH,
>       BURL, CATENATE) (see lemonade Profile [PROFILE]).
This bullet just repeating something that is already mentioned above. I 
suggest deleting it.
>    o  Out-of-band server to client notifications relying on external
>       notification mechanisms (and notification protocols) that may be
>       out of scope of the LEMONADE profile.
>    o  A LEMONADE aware MUA (Mail User Agent).  While use of out-of-band
>       notification is described in the LEMONADE profile, support for the
>       underlying notifications mechanisms/protocols is out of scope of
>       the LEMONADE specifications.

> 4.  Filters and server to client notifications and LEMONADE
 [...]
>    In Figure 6, we define four categories of filters:
>    o  AF: Administrative Filters - The e-mail service provider usually
>       sets administrative filters.  The user typically does not
>       configure AF.  AF applies policies covering content filtering,
>       virus protection, spam filtering, etc.
>    o  DF: Deposit Filters - Filters that are executed on deposit of new
>       emails.  They can be defined as SIEVE filters [SIEVE].  They can
>       include vacation notices.
Please add a reference to RFC 5230 at the end of the last sentence.
>    o  VF: View Filters - Filters that define which emails are visible to
>       the MUA.  View filters can be performed via IMAP using the
>       facilities described in [NOTIFICATIONS].
>    o  NF: Notification Filters - Filters that define for what email
>       server event an out-of-band notification is sent to the client, as
>       described in [NOTIFICATIONS].
>
>    The MUA can manage the NF and DF filters using the SIEVE management
>    protocol.
Please add a reference to draft-martin-managesieve (currently 
draft-martin-managesieve-09.txt) at the end of the last sentence.

Regards,
Alexey


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