Re: [lemonade] WGLC Notifications

Eric Burger wrote:
> I have written up the shepherd document.  Is this OK?
>
>
>
> inline
>   
See below.
> On May 6, 2008, at 10:07 AM, Alexey Melnikov wrote:
>   
>> Eric Burger wrote:
>>     
>>> Work Group Last Call for Lemonade Notifications Architecture,
>>> http://tools.ietf.org/html/draft-ietf-lemonade-notifications-08
>>> starts now and ends 5 May 2008.
>>>       
>> The draft is in much better shape now.
>>
>> Some comments below:
>>     
>>> *    NF and DF:  When internal to the mail store, these are
>>> typically implemented using Sieve and hence a Sieve management
>>> protocol is used for client modifications.  See [IMAP-SIEVE] and
>>> [MANAGE-SIEVE] for more information.  When the NF is within a
>>> notification server, it is out of scope of Lemonade.
>>>       
>> I don't think [IMAP-SIEVE] is relevant in case of NF or DF.
>> Unless NF is invoked on message flag changes, etc.
>>     
> We are not saying, "you can only use Sieve."  I read this as "you can  
> use Sieve."  In a purely Informational document, "typically  
> implemented" has no normative meaning.
>   
You've missed my point. I was trying to say that the sentence:
  See [IMAP-SIEVE] and [MANAGE-SIEVE] for more information.

Should read:
 See [MANAGE-SIEVE] for more information.

As [IMAP-SIEVE] has nothing to do with NF or DF (I think. I would like Randy to clarify the intent of the text)

>>> Note that when implementing DF using Sieve, the 'enotify'
>>> [SIEVE-NOTIFY] and 'variables' [SIEVE-VARIABLES] Sieve extensions
>>> are needed.
>>>       
>> If NF is generating notifications on mail delivery, than 'enotify' +
>> 'variables' is also needed there.
>> If NF is generating notifications both on mail delivery and IMAP  
>> events,
>> then 'enotify' + 'variables' are *only* needed in NF.
>>     
> Do we really need to change the words here?
>   
Yes, I want the proposed architecture to be clear.
>>> 4.  Push Email
>>>
>>> A good user experience of "push email" requires that when
>>> "interesting" events occur in the mail store, the client is informed
>>> so that it can connect and resynchronize.  The Lemonade Profile
>>> [LEMONADE-PROFILE] contains more information, especially in Section
>>> 4.1.2.
>>>       
>> I can't find section 4.1.2 in draft-ietf-lemonade-profile-bis-08.txt.
>>     
> I would offer that since profile-bis has a propensity to renumber, we  
> reference by name not number.  That way, if we use IPv6 section  
> headers, our application still works :-)
>
> OLD
>
> especially in Section 4.1.2
>
> NEW
>
> especially in the section "External Notifications"
>   
Fine with me.
> Nit: When I read this, I had no idea what "it" is.  Here is my guess.
>
> Section 5.2
>
> OLD
>
> notification system; it then becomes
>
> NEW
>
> notification system.  Thus the security relationship then becomes
>   

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade