Subject: [Simple] Instant Message Delivery and Read Reports

From: Hisham Khartabil <[email-masked]>
Date: Wed, 4 May 2005 15:50:49 +0200

I have submitted a new draft regarding IM delivery and read reports.  
Until it appears in the archive, please pick up a copy from

http://www.imsbook.com/hisham/draft-khartabil-simple-message-delivery- 
read-report-00.txt

Comments are most welcome about the idea of delivery and read reports  
for instant messages. Technical comments are also welcome at this  
point.

Regards,
Hisham

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 May 2005 11:16:30 -0400

Hisham,

Thanks for doing this. I think it is on the right track. I have some 
relatively minor comments, and then one more major one. First the minor 
ones:

1) Section 3.1:

 > The Message-ID field is populated with a value that is
 > random is space and time.
   ^^^^^^

Don't you mean "unique"? Random is one way to approximate unique, but I 
don't know what "random in space and time" is, and I think unique is 
really the goal.

2) Section 3.1:

    If an endpoint sending an Instant message and has requested a
    positive-delivery, negative-delivery and/or read report, it MUST NOT
    start any timers.

I don't understand why this is here. Must not set any timers for what? 
Is this intended to change behavior that the client might otherwise have 
it it hadn't requested a report? Or is this just intended to say that 
there are no time limits associated with when delivery reports may be 
received?

3) Section 3.2

    The delivery report SHOULD NOT contain a Message-ID header field.

Why? It is a standard mime header, and it is harmless. It isn't useful, 
but so what? At least explain the SHOULD NOT as just being related to 
the uselessness and possible confusion.

4) Section 3.3

This talks about returning 485 if it can't determine if a message has 
been read. Might be good to talk about other possible error responses 
that are appropriate, such as: 401 (unauthorized), or 603 (decline).

5) Section 6.2

After reading this I still don't think I understand exactly how an 
exploder is supposed to work.

Then, the more fundamental thing:

6) The example in 3.2:

          Content-type: Message/CPIM

          From: Bob <im:[email-masked]>
          To: Alice <im:[email-masked]>
          Content-type: message/status-report
          Content-Disposition: confirm

I think this is wrong - if Content-Disposition is to be used, it should 
be *outside* the CPIM wrapper. If it is inside of CPIM, then maybe we 
shouldn't be using content-disposition at all, but rather some other new 
header.

My concern is that the SIP application processing MESSAGE needs to know 
what to do with body parts it sees. If there was a multipart containing 
a CPIM and and S/MIME, it would be wanting to decide at that level, 
before opening the CPIM - which might be the responsibility of an 
entirely different piece of code.

If the distinction between what is a message and what is a delivery 
report needs to be made at the sip message processing level, then the 
C-D needs to be outside the CPIM. But if the distinction needs to be 
made later, then the C-D for both should be render, and something inside 
the CPIM should determine this.

If we think both messages and delivery reports can make it through 
gateways transparently, then we should make this something inside the 
CPIM. If we think they can't, and that gateways will be responsible for 
creating and consuming these reports, then using C-D outside the CPIM 
seems right.

I'm now thinking this makes better sense as something inside the CPIM, 
not involving Content-Disposition.

	Paul

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 6 May 2005 11:51:29 +0200

I was asked to shorten the name of the draft. It is now

http://www.ietf.org/internet-drafts/draft-khartabil-simple-im-report 
-00.txt

Hisham