Subject: RE: [Simple] Instant Message Delivery and Read Reports

From: Goix Walter <[email-masked]>
Date: Tue, 17 May 2005 17:59:25 +0200

[snip]

> 
> The point of using CPIM is to decouple it from MSRP. "Limiting" it to 
> CPIM does not prevent it from applying to other content precisely 
> because CPIM is itself a wrapper type and may contain all those other 
> types. CPIM becomes the higher level solution you are looking for.

Sure. My point was just about avoiding overhead by encapsuling messages,
by defining support for both with and without cpim encapsulation. For
sure cpim guarantees independence from the actual transport mechanism if
we use it to carry the message-id, receipt-request and actual delivery
report. In this case I would be interesting to lower an optional
Expires: header or similar as a message header in the cpim envelope to
indicate the validity duration.

> 
> > - For intermediary-type of behavior, it may be interesting to use 
> > RLS-type of XML data format to get delivery information about  each 
> > user. In this case, it may also be interesting to have the 
> option to 
> > request delivery notification through an event-based 
> paradigm, as an 
> > alternative to get notified
> 
> Please say more - I don't have a clear idea what you have in 
> mind. The 
> problem with having the intermediary package of the reports 
> is that it 
> doesn't know how long to wait.

The idea was, as an alternative to the current proposal of sending back
one IM per delivery notification in the intermediary, for the
intermediary to provide a subscription-based mechanism for a watcher to
get notified about delivery reports. This could enable, based on
policies, other watchers to get notified about the message delivery
besides the message sender itself. Optionally, the event package could
also enable control over the sending process to interrupt the sending
process. Besides, reusing an RLS-type of XML format could ease the
notification of delivery state to the watcher.
The time for which the intermediary keeps the reports may be
implementation dependent (a certain amount of time after the last
positive/negative/read report has been received), or based on some extra
parameter provided by the original sender (time limited by local
configuration). Whilst the reports are kept by the intermediary, the
watcher can log out and back in without losing the report information,
while this would require an additional store-and-forward feature in a
MESSAGE paradigm. I also understand that the 1-to-1 MESSAGE paradigm at
the intermediary between the received and the sent delivery report does
not require additional implementation in the sender (and the
intermediary).

It is not clear to me what the value of the <recipient-uri> is. The
examples do not include the scheme of the URI (may im: be provided as
sip: if the recipient was a SIP endpoint) nor provide a good
understanding of the actual value to be put in in case of redirection.
In any case, would this be the AOR of the user, or its contact (in case
of forking to distinguish endpoints) ?

walter

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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