Subject: [Simple] New Draft: Deferred Messaging Disposition Notification

From: "Stafford, Matthew" <[email-masked]>
Date: Fri, 19 Jan 2007 10:45:17 -0600

We had some discussion about a month ago re: pulling MSRP out of the
IMDN draft. Thanks to Ben, Miguel and Hisham for their responses. I'd
say the upshot of that discussion was twofold: the "slimmed-down" IMDN
draft needs to go ahead, and any push to expand IMDN's applicability
needs to start with clear documentation of requirements.

Jointly with two colleagues at Cingular/AT&T, I have submitted an I-D to
address the latter point. It is now posted at 
http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt

This draft is intended to start the ball rolling by presenting use
cases. It makes a straw proposal that IMDN usage be extended to MSRP. (I
do understand that there may be other, better ways to meet the
requirements- but this draft still seems to be a reasonable starting
point.)

Best,
Matt

-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 10:08 AM
To: Stafford, Matthew
Cc: Ben Campbell; [email-masked]
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt

Matthew,

I appreciate the requirements you are putting forward for IMDNs for
session mode messaging. It was agreed in the last IETF meeting that
this will be for further study and will be kep out of the current IMDN
draft, limiting its scope to page mode IMs.

You have valid use cases for large messages to use MSRP (although the
user doesnt know it is in fact a session) plus the store and forward
IM session (which doesnt make much sense). In any case, you will need
to bring forward those requirements in an internet draft form and we
can discuss those requirements on the mailing list. You are also free
to present them in the next IETF meeting. Once the requirements are
clear, we can start working on the solution.

One solution I can think of for your large message read report problem
is that you can send a page mode IMDN referring to the message ID of
the session, or embedding the session id and message  id into the
Message-ID header. This probably also works fine for store and
forward..

The point I'm trying to make is that it is not as easy as just saying
"this also applies to session mode". Requirements and solutions need
to be studied.

Thanks,
Hisham

On 18/12/06, Stafford, Matthew <[email-masked]> wrote:
> Thanks for your response. Inline.
>
> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, December 14, 2006 11:34 PM
> To: Stafford, Matthew
> Cc: Robert Sparks; [email-masked]
> Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
>
>
> On Dec 14, 2006, at 9:40 PM, Stafford, Matthew wrote:
>
> > I'd like to raise an issue regarding the statement that "IMDN is not
> > generally applicable to MSRP". IMHO IMDN's usefulness in the
> > context of
> > SIP MESSAGE will be compromised if it cannot also be applied to
MSRP.
> >
>
> Perhaps a better wording in the draft is "We have not fully explored
> the use cases for MSRP, so they are out of scope for this document.
> They may be addressed in a separate work."
>
> I think the real point of removing MSRP from the document was not to
> say that we know categorically that there are no valid uses with
> MSRP. Rather, it was that such uses were not entirely clear, and if
> they are needed they require further exploration. We did not want to
> block progression of the spec on how to do IMDN with page mode until
> we completely understood how to do it with MSRP.
>
>
> > I take the point that, when two subscribers are participating in an
> > ongoing session, it's odd to talk about IMDN concepts such as read
> > receipt.
> >
> > However, "one-and-done" messages can easily exceed the 1300-byte
limit
> > for SIP MESSAGE over UDP, especially when request-contained
> > distribution
> > lists and/or multimedia attachments come into play. CPIM headers
will
> > further reduce "headroom".
> >
> > To address this limitation, OMA's SIMPLE IM working group has
> > identified
> > "large message mode" (in addition to page mode and session mode). In
> > large message mode, an MSRP session is set up to transfer a one-time
> > message that is bigger than 1300 bytes. But the subscriber is
> > blissfully
> > unaware of the difference between page mode and large message mode-
> > nothing at the UI layer reflects that there is an underlying
> > session in
> > the latter case. The UI just presents a "unified composer" to the
> > subscriber. If the UI allows the subscriber to request read
> > receipts for
> > small messages but not for big ones, I think the subscriber will be
> > baffled. Consider, for example, a case in which the subscriber
> > composes
> > a text message and checks the "request read receipt" box. Then, on
the
> > fly, he/she decides to add an attachment before sending the message.
> > It's really awkward to step in at that point and say no, sorry- you
> > can
> > have one or the other but not both.
> >
>
> In such a case, the user request for a receipt would be satisfied by
> the MSRP report mechanism, wouldn't it? That is, if the client is
> smart enough to switch to using MSRP rather than page mode, it would
> also be smart enough to request a delivery confirmation using the
> mechanism already in MSRP?
>
> <<< OK in this use case for _delivery_ notification (but see below),
but
> what about _read_ notification? >>>
>
> Now, if the use case you describe is one where the IMDN needs to be
> delivered after the MSRP session is completed (for example, the large
> message gets sent to a store and forward server), then we have a
> _very_ good example of something that needs more exploration before
> we try to specify how to do it.
>
> <<< I think we do have such an example: OMA defines a deferred
messaging
> function in which the IM server stores messages for later delivery in
> the case that an intended recipient is unavailable. So I think you've
> put your finger squarely on an OMA use case. >>>
>
> > In summary, I think OMA's taxonomy of messaging modes is very
natural-
> > from the POV of supporting use cases that will make sense to the
> > average
> > subscriber. IMDN consistency across page and large message modes
seems
> > equally natural to me.
> >
> > Best,
> > Matt Stafford
> > Cingular Wireless
> >
> > -----Original Message-----
> > From: Robert Sparks [mailto:[email-masked]]
> > Sent: Monday, December 11, 2006 10:22 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
> >
> > This is a SIMPLE WGLC for
> > http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt
> >
> > Please have your comments to the list by December 25 (more on this
> > timing below)
> >
> > Please send your comments to the list and copy Hisham and Eric.
> > Given the timing, it is especially important for you to respond if
> > you think the draft is ready to go with no changes.
> >
> > IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME,
> > send email to the chairs right away. We'll extend this if there's
any
> > felt need.
> >
> > Why the timing? :
> >     First off, I was slow in issuing the last call - that should
have
> > happened at the beginning of the month.
> >     Hisham (who has the pen right now) has some travel across the
new
> > year where he will be less responsive
> >     than usual. Our take is that this draft has little to no
> > controversy left and has undergone a lot of scrutiny.
> >     If the LC feedback from the group shows it is ready to go,
Hisham
> > can make any needed minor edits before
> >     he drops offline and we can start into the request for
> > publication process. If the feedback shows more time in
> >     LC is needed, we'll adjust, moving closure into the new year. In
> > order to gauge this, it is very important that you
> >     respond even if you have no changes to suggest.
> >
> > If you are not planning to review/comment on this draft, please let
> > me know.
> >
> > RjS
> >
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> >
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
>
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>

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

---

From: "Stafford, Matthew" <[email-masked]>
Date: Tue, 23 Jan 2007 17:48:05 -0600

Prague agenda item request: we would like to have a timeslot (20 minutes
if possible) to present & discuss this draft. One of my co-authors,
Jerry Shih, will be attending the session.

Thanks,
Matt

-----Original Message-----
From: Stafford, Matthew 
Sent: Friday, January 19, 2007 10:45 AM
To: [email-masked]
Cc: Wuthnow, Mark; Shih, Jerry
Subject: [Simple] New Draft: Deferred Messaging Disposition Notification

Best,
Matt

<snip snip...>