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

From: "Stafford, Matthew" <[email-masked]>
Date: Thu, 1 Mar 2007 16:55:19 -0600

Thank you for your comments and sorry for the (extremely) slow response.
Inline.

-----Original Message-----
From: Nancy Greene (QA/EMC) [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 12:59 AM
To: Stafford, Matthew; [email-masked]
Cc: Shih, Jerry
Subject: RE: [Simple] New Draft: Deferred Messaging Disposition
Notification

I have a couple of comments on the DMDN draft:

- in the flow in fig 1, it seems that steps 11-12 need to be followed by
a step 12 a carrying a REPORT going from Bob's UA to the App server.
This report, whether it is a success REPORT or failure REPORT is then
translated into an IMDN in a SIP MESSAGE as shown in steps 15-16. Note
that the BYE in steps 13-14 needs to be moved to be after the IMDN SIP
MESSAGE in steps 15-16. 

[MS]> I've mulled this over but I think I'm still missing something.
Looking [MS]> at the first paragraph, section 5.3 of
draft-...message-sessions-19 [MS]> (MSRP Transaction and Report Model),
I tried to compare the XMPP [MS]> [MS]> interworking example that is
briefly mentioned there to Fig 1 in our [MS]> DMDN I-D. It seems to me
that the analogous behavior would be for the
[MS]> App Server in the middle of the diagram to send an MSRP REPORT to
[MS]> Alice's UA. We argue in the comments below the figure, though,
that
[MS]> since the MSRP session is already over and done with, and setting
[MS]> a new MSRP session entails significant overhead, it would be great
if
[MS]> you could do the job with a SIP MESSAGE. (Provided that makes
sense &
[MS]> potentially represents a consensus view, perhaps I could amplify
that
[MS]> part of the text.) 

[MS]> Regarding the order of SIP MESSAGE (step 15)- agree that nothing
says 
[MS]> you have to wait for the SIP BYE/200 OK to send the thing. Maybe
it [MS]> would help to say that the ordering there is somewhat arbitrary
and [MS]> this looked like a clean way to draw the diagram?

- to set the IMDN Route header, it seems it would be straightforward -
any Record-Route header in the INVITE kept when the message was deferred
is later used to set the IMDN Route header in the SIP MESSAGE carrying
the MSRP REPORT.

[MS]> Would it really be necessary to encapsulate an MSRP REPORT in a
SIP
[MS]> MESSAGE? I guess what I was hoping is that the CPIM header with
the IM
[MS]> info would live at a higher layer and its meaning would be
independent
[MS]> of whether it happened to be encapsulated in SIP or MSRP.

Nancy

-----Original Message-----
From: Stafford, Matthew [mailto:[email-masked]] 
Sent: Tuesday, January 23, 2007 6:48 PM
To: [email-masked]
Cc: Shih, Jerry
Subject: RE: [Simple] New Draft: Deferred Messaging Disposition
Notification

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

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

<snip snip...>

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

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