Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 11 Dec 2006 10:21:54 -0600

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

---

From: "Stafford, Matthew" <[email-masked]>
Date: Thu, 14 Dec 2006 21:40:34 -0600

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.

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 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

Why the timing? :

RjS

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Dec 2006 23:33:44 -0600

> 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.

> 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?

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.

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 15 Dec 2006 15:17:42 +0200

Mathew, Ben:

I think I agree with Ben here, that the spirit of the text is NOT to say 
that "we are in the absolute possession of the truth, and it indicates 
that IMDN does not make sense with MSRP". Instead, the spirit of the 
text tries to say that in those cases we have explored, MSRP conveys all 
the tools for providing IMDN except for the read case. But the read case 
is not applicable to session based messaging where messages are 
sequentially displayed in a chat windows (because the endpoint will 
blindly generate the IMDN-read always, so what is the point?). Please 
not the word "generally" in the text.

Now, it seems that OMA is going on step beyond the "general" use cases 
for MSRP, and I have no problem with that, but we haven't done an 
analysis of those uses cases and the impact of IMDN to those use cases.

The text in the draft also says: "If new requirements arise in the 
future determining the need for IMDN in MSRP, new specifications can be 
drafted". And this is what I would like to see, we know how IMDN is 
useful and can be applied for SIP, so let's finish the document now. I 
don't mind if we simultaneously keep on analyzing the need of IMDN for 
MSRP, and if needed, write a separate spec to apply IMDN for MSRP. Would 
that solve your concern, Mathew?

BR,

      Miguel

PS: I am in the middle of my review of MSRP, I expect to post my 
comments in the following days.

Ben Campbell wrote:
> 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.
> 
> 
> 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?
> 
> 
> 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.
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: "Stafford, Matthew" <[email-masked]>
Date: Mon, 18 Dec 2006 09:51:23 -0600

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

<<< OK in this use case for _delivery_ notification (but see below), but
what about _read_ notification? >>>

<<< 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. >>>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 18 Dec 2006 17:07:49 +0100

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Dec 2006 10:36:56 -0600

> what about _read_ notification? >>>

Yes, "read" notification is an interesting case. For direct (not  
store-and-forward) sessions, this might be doable with an MSRP  
extension adding a "read" state to the sorts of things you can report  
on.

Since it would not help for the OMA store and forward case, it might  
be easier to address with IMDN.

> put your finger squarely on an OMA use case. >>>

Just to be clear, the reason that I have resisted having us to just  
add this use case to the IMDN draft is that we do not have a clear  
understanding (or at least an agreed upon one) on how you would  
deliver an IMDN for a message that was sent in an MSRP session that  
no longer exists. Perhaps you send a page mode message, open an MSRP  
session in the opposite direction, or something completely different.  
There are also issues on how you address and route an IMDN that goes  
out via a different medium.  These are likely to create some spirited  
discussion, which will take a while to resolve.

I am happy to have that discussion, I just don't want to see the page  
mode use of IMDN blocked on it.

---

From: "Stafford, Matthew" <[email-masked]>
Date: Mon, 18 Dec 2006 11:34:52 -0600

Inline.

Thanks,
Matt

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Friday, December 15, 2006 7:18 AM
To: Ben Campbell
Cc: Stafford, Matthew; [email-masked]
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt

Mathew, Ben:

<<< If incorporating MSRP would indeed cause significant delay, I can
understand your point. If the decision is made to go ahead w/o MSRP (in
this particular document), would it be appropriate to modify the last
sentence of the abstract accordingly? >>>

BR,

      Miguel

> Perhaps a better wording in the draft is "We have not fully explored
the 
> I think the real point of removing MSRP from the document was not to
say 

> In such a case, the user request for a receipt would be satisfied by
the 

> message gets sent to a store and forward server), then we have a
_very_

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 18 Dec 2006 18:38:03 +0100

> sentence of the abstract accordingly? >>>

Yes. That was an oversight. Apologies for that. I will be fixed in the
next version.

Hisham

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 19 Dec 2006 09:28:18 +0200

> sentence of the abstract accordingly? >>>

Absolutely. I am still reviewing the draft, but I have noticed that the 
draft still has several outdated anchors to MSRP, which should be 
removed. I will have a more detailed comment together with the rest of 
my comments.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 20 Dec 2006 17:20:51 +0200

Here are my comments to IMDN-02.txt

- In several places the draft still has some MSRP leftovers, and should 
be removed:

In the Abstract, replace:

    ... processing and read notifications, for
    page-mode as well as session mode instant messages.

with

    ... processing and read notifications, for
    page-mode instant messages.

Also in the Abstract, replace:

    This document also describes how SIP and MSRP entities behave using
    this extension.

with

    This document also describes how SIP entities behave using
    this extension.

In Section 1, 3rd paragraph, remove the last line:

    The MSRP [11] SEND
    request can also be used to carry Message/CPIM messages.

In Section 1, last paragraph, replace:

    This document also describes how SIP and MSRP entities behave using
    this extension.

with:

    This document also describes how SIP and MSRP entities behave using
    this extension.

In Section 3, last bullet point, replace:

    o  Transport Protocol Message: An IM or an IMDN wrapped in a
       transport protocol like SIP or MSRP.

with:

    o  Transport Protocol Message: An IM or an IMDN wrapped in SIP.

Actually, I think it is even better to remove the definition of 
"Transport Protocol Message", because I think it is no longer used by 
the specification, now that is restricted to SIP.

Delete completely Section 13.

- Comment in the terminology (Section 3). The 'IM Sender' definition 
indicates that the IM Sender might be different from the IMDN recipient. 
Doesn't this create a security threat by allowing endpoints to redirect 
IMDNs to third parties?

- Terminology, Section 3. I would suggest to decouple the IMDN payload 
from the fact that is an XML document of MIME type message/imdn+xml, 
because in the future you could create other MIME types, and still be an 
IMDN payload. So I would suggest to replace:

    o  IMDN Payload or XML Document: An XML document carrying the
       disposition notification information.  It is always of MIME type
       "message/imdn+xml".

with:

    o  IMDN Payload: An document, typically an XML document, carrying the
       disposition notification information.

- Suggestion: add a caption to Figure 1, e.g., "Figure 1: Overview of 
the Protocol Operation", and then in the first line of the first 
paragraph in Section 4, replace:

    The basic protocol flow is depicted in the diagram below

with:

    The basic protocol flow is depicted in Figure 1

- In the paragraph under Figure 1, Section 4. Replace:

    This is specifically true for page-mode IMs where the
    Address of Record (AOR) ...

with

    For example, in page-mode IMs the
    Address of Record (AOR)

- I think Section 4 should also answer the question whether it is 
possible for an IM sender to receive several notifications with respect 
the same IM. I think the answer is yes, especially if there are 
intermediaries storing the message, so it would be nice to answer this 
question to the reader in this Section 4.

- Section 5.2 is about Processing IMDNs. I think we should provide an 
indication of when is the Processing state useful, or when can it be 
generated. Is it the case when there is a gateway or store and forward 
server?

So, replace:

    The processing notification type indicates that an IM has been
    processed by an intermediary.

with:

    The processing notification type indicates that an IM has been
    processed by an intermediary, such as a gateway or a 
store-and-forward server, and the intermediary does not have further 
information about the disposition of the IM.

- Section 5.2 in the first bullet point defines the term "processed", 
but the defined term is part of the definition. This should be avoided. 
The definition should explain with words what "processed" means, perhaps 
adding some example. Suggestion

   o "processed" indicates that a final disposition of the IM is not yet 
known, for example, due to the traversal of a gateway or 
store-and-forward server.

- Section 5.3. We could think of use the term "rendered" rather than 
"read". This is because IMs can carry any kind of message, including 
audio messages, for example. "rendered" is more generally applicable to 
all kind of messages. I would also suggest to replace "Displayed" with 
"rendered" in the first sentence:

    The read notification type indicates whether the IM Recipient
    Displayed the IM to the user or not.

- Section 5.3, in the sake of clarity, replace:

    o  "forbidden" indicate denial by the IM Recipient for the IM Sender
       to receive the requested IMDN.
with

    o  "forbidden" indicate denial by the IM Recipient to receive the 
requested IMDN.

- Section 6.1. Write the namespace (urn:ietf:params:cpim-headers:imdn) 
in a separate line of its own, such as:

    The namespace is:

         urn:ietf:params:cpim-headers:imdn

    As per CPIM [2] requirements, ...

- Section 6.1 reads:

    As per CPIM [2] requirements,
    the new headers defined in the following sections are prepended by
    the string "imdn." in CPIM messages

    The text is partly true only. The prefix is assigned by the NS 
header in CPIM, so one can choose any prefix name other than 'imdn.', so 
it would be nice to have that into consideration. Suggestion:

     The new headers are prefixed by a prefix assigned to the URN 
through the NS header field of the CPIM message. The remaining of this 
specification always assumes an NS header field like this one:

      NS: imdn <urn:ietf:params:cpim-headers:imdn>

- Section 7.1.1 should mention CPIM in addition to the RFC number. So, 
replace:

    An IM is constructed using RFC 3862 [2].

with

    An IM is constructed using the CPIM message format specified in RFC 
3862 [2].

- The second line in 7.1.1 reads:

    The Content-type header
    field indicates the MIME type of the request payload

    which is true, but why do we need to mention Content-type and not 
any of the other headers? This is not relevant at this point in time, so 
I would suggest to delete the sentence.

- Section 7.1.1.3 starts with a strange paragraph:

    In this specification, the IM Sender can request two types of
    delivery notifications: a failure delivery notification and a success
    delivery notification.

   It is strange because it starts describing the type of "Delivery" 
notification, when the title of the section is about "Disposition" 
notification. So, the reader gets a nice mixture of delivery and 
disposition. What about if you replace the above sentence with this one:

    The Disposition-Notification conveys the type of disposition 
notification requested by the IM sender. There are three types of 
disposition notification: delivery, processing, and read. The delivery 
notification is further subdivided into failure and successful delivery 
notifications.

- Section 7.2.1, 3rd paragraph reads:

    An IMDN MUST contain a Message-ID header field.  The same rules of
    uniqueness for the Message-ID header field that appears in an IM
    apply to an IMDN.

    I think it would nice to indicate that the Message-ID of the IMDN is 
different from the Message-ID header of the IM it correlates with.

- Section 7.2.1, what about IMDN-Record-Route headers in IMDN? It think 
they don't make sense in IMDNs, so this section should have normative 
text indicating that cannot be used.

- Section 7.2.1.1, first paragraph reads:

    A delivery notification is constructed in a similar fashion as an IM,
    using RFC 3862 [2].  For delivery notifications, the Content-type
    MUST be of type "message/imdn+xml".  It is an XML document.  The
    schema is described Section 11.  The delivery notification MUST
    contain a Content-Disposition header field with value "notification".
    This indicates to the IM Sender that the message is an IMDN to an IM
    it has earlier sent.

    I think it would be clear of the paragraph is replaced with:

    A delivery notification is constructed in a similar fashion as an IM,
    using a CPIM body [2] that carries a Disposition Notification XML 
document formatted according to the rules specified in Section 11.1. 
The MIME type of the Disposition Notification XML document is 
"message/imdn+xml". The CPIM Content-Disposition header field must be 
set to the value "notification". This indicates to the IM Sender that 
the message is an IMDN to an IM it has earlier sent.

- The example in Section 7.2.1.1 looks a bit strange, because it starts 
with the Content-Type header... The suggestion is either to write a 
complete SIP MESSAGE request or to remove the Content-type header and 
indicate that the example shows only the CPIM body.

- General to all the examples: the XML stuff should be properly 
formatted, so replace:

   <imdn>

   with

    <?xml version="1.0" encoding="UTF-8"?>
    <imdn xlmns="urn:ietf:params:xml:ns:imdn">

- Section 11.1.3, the text reads:

    ... This information is obtained from the To header
    field of the IM.

    It is not clear if the text refers to the CPIM To header or the SIP 
to header. I bet is the CPIM To header. In any case, to achieve 
interoperability, the text should clearly refer to the correct header.

- Section 12.1.1. This section should answer to this question: On 
creating an IMDN, how to populate the Request-URI and the SIP To header?
I think the Request-URI and To header of SIP MESSAGE should set to the 
same (except tags) of the From header field of MESSAGE that carried the IM.

Additionally, the draft should say that:

"Due to the fact that IM senders can remain anonymous, e.g., by setting 
the From header field of the SIP message to an anonymous URI, anonymous 
IM senders are not eligible for requesting disposition notifications. 
Therefore, anonymous IM senders MUST not request disposition notifications."

- General question, not tied to any section. What happens if the IM 
sender has several devices or SIP instances, sends an IM and requests 
IMDN? The desired effect is that IMDNs are received in the same device 
where the IM was sent out. This is calling for something like GRUU, but 
I don't think we can use GRUU in MESSAGE requests. It would be nice to 
either have a solution or just write the limitations of the 
specification with respect several devices/instances.

- You may want to update your e-mail address in Section 15.3

- You can remove references 8 and 14, they are no longer used.

- You need to run the idnits tool: to reports a few of them.

That's all. BR,

        Miguel

---

From: Ben Campbell <[email-masked]>
Date: Fri, 22 Dec 2006 16:12:16 -0600

I'm still working on my own comments, but here's a comment on one of  
Miguels

On Dec 20, 2006, at 9:20 AM, Miguel Garcia wrote:

>    o  "forbidden" indicate denial by the IM Recipient to receive  
> the requested IMDN.

But the IM recipient does not receive the IMDN, right? Isn't that the  
IM Sender?

I'm also a little confused about the intent of this statement in the  
draft. Who is refusing what to whom? I read it to mean something like  
"Forbidden indicates that the IM Recipient refuses to send the  
requested IMDN". Would anyone ever send that? I mean, if I am going  
to refuse to send an IMDN, I'm not going to tell you that I received  
your message, and refuse to send the IMDN. I'm going to just silently  
ignore the IMDN request.

Is there an information leak here? That is, if I send "refused", you  
know I in fact received the request, right?