Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03

[Randall Gellens <randy at qualcomm.com>]

I haven't seen any replies to your questions.  Here are my views.


At 1:48 PM +0800 7/27/06, Gang Liang wrote:

>  Questions 1:
>
>  In 10.2 (Provision Entries), "push.shared" is defined as 
> an attribute of in-band notifications (not the attribute of outband 
> notifications) while in the first example in 10.4 
> "push.shared" is regarded as the attribute of outband 
> notifications.
>
>  Why? Maybe "push.shared" should be defined as an 
> attribute of outband notifications too.

I have concerns about the concept of using mailbox annotations for 
this purpose.  For one thing, it seems to be have problems in the 
case where users have multiple devices.


>  Question 2:
>
>  In 10.3
>
>  "limit.priv" = "size=" nz-number  | 
> "total=" nz-number
>
>  ;the maximum number of bytes to send in notification payloads or 
> the total number of messages to send. Both per-day
>
>  What's the benefit of limiting the total number of messages 
> (notifications) per-day? If the number of notifications sent that 
> day has reached the limit (e.g. 10 notifications per-day ) but then 
> a very important email arrives, what should the server do?

I agree.  The issue of throttling is one that will need to be 
addressed, but a simplistic per-day limit doesn't seem to be the way 
to solve it.

>  Question 3:
>
>  In 10.3:
>
>  "push.priv" = "push" / "pull"
>
>  ;specifies whether the client expects new messages to be pushed via 
> the unsolicited FETCH response defined above, or via client issued 
> FETCH in response to an EXISTS response.
>
>  Is it possible to push new messages via outband notifications? E.g. 
> through MMS channel. If it's possible, maybe we could define such 
> an attribute for outband notification.

Personally, I don't see much benefit in using MMS to push mail or 
notifications.  More specifically on your question of including the 
message itself in the notification, I think that is feasible with 
small messages, but not large ones.  Also, to the extent that 
notifications are unreliable, this would only be an ancillary 
service; that is, the client may get messages via notifications, but 
if this fails for any reason the client will get them normally.

>  Question 4:
>
>  In 13.8
>
>  It MUST be possible to provide acknowledgment by the target to the 
> messaging system or to repeat notification until such an 
> acknowledgement is provided if supported by the notification 
> channel.
>
>  Does it mean that the target (client) should provide acknowledgment 
> for per-notification and the messaging system should repeat the 
> same notification (not send the following notifications) until 
> receive the acknowledgment for the notification?

This is what I think the document is saying, but personally I have 
concerns with this approach.

>  If so, maybe it's more appropriate to send a notification after 
> determining that the client is online (e.g. according to presence 
> status of the client provided by presence enabler).

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I had a fortune cookie the other day and it said, "Outlook not
so good."  I said, "Sure, but Microsoft ships it anyway."
                                                 --Tom Singer

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade