Subject: [Simple] Comments to draft-ietf-simple-imdn-00.txt

From: Miguel Garcia <[email-masked]>
Date: Fri, 07 Jul 2006 16:29:03 +0300

Hi:

Here are some comments to the IMDN draft.

1) I think the draft is desperately looking for a terminology section 
within Section 2. I think we ought to define the following terms (this 
my understanding):

IM or Instant Message: a SIP or MSRP message that contains a 
message/cpim body

IMDN: a SIP or MSRP message that contains an IMDN document

IMDN document: an XML document that complies with the Schema of Section 9.3

message/cpim body: a document that complies with RFC 3862. It can also 
contain the extensions defined in this document.

So, notice that we have definitions of SIP/MSRP carrying either a 
regular IM or an IMDN. We have a name for the XML part of the IMDN, and 
  a name for the document part of a regular IM. Don't know if this fits 
with your intention, I hope so.

Then please stick to the terminology: avoid terms like 'Message/CPIM IM'.

2) In Section 3, Overview, I am missing an overview description of the 
Aggregation feature.

3) Make sure that it is always spelled out if you are referring to the 
Content-Type header in SIP or MSRP, or the Content-Type header that goes 
into the message/cpim body

4) The text in Section 4.1 reads:

    In this extension, the Message/CPIM IM MAY contain a Message-ID
    header field if an IMDN is requested.  The Message-ID field is
    populated with a value that is unique in space and time.  This header
    field enables the message sender to match any notifications with
    their corresponding IMs.  This header need not be present if the
    instant message sender is not requesting any IMDNs or if no state of
    any kind is kept for an IM.

First, I don't know what "In this extension" means... I guess it should 
be "Implementations according with this specification..."

Then I think we should encourage implementations to include a Message-ID 
header whenever they are requesting IMDN, even when they do not keep 
state... It may help when debugging, for example.

5) Section 4.1, third paragraph: there seems to be a repetition for the 
justification of the timestamp:

    It is therefore necessary to add a time stamp in the IM to indicate
    when it was sent in order to enable the human user to correlate the
    IM with the IMDN.  This time stamp is returned in the IMDN in order
    to enable the user to correlate the IM with the IMDN at the human
    level.

6) I would suggest renaming Section 4.1 as "Requesting Disposition 
Notifications".

7) Section 4.2. I am missing to put a context to IMDNs. Specifically, 
the text should answer to the question: "is the IMDN XML stuff inserted 
as SIP/MSRP payload or as message/cpim payload?. So I would start this 
section with some text along these lines (according to the suggested 
terminology in my first bullet point).

"An IMDN is a SIP or MSRP message that contains a message/cpim body 
whose payload is an IMDN document compliant with the XML schema of 
Section 9.3."

8) The last paragraph in Section 4.2 starts speaking about the 
"Really-From" header like if the reader were familiar with it, but this 
is the first occurrence of this header. So I would suggest to add a 
couple of sentence that describes what this header is all about right 
before this paragraph.

9) The titles in Sections 4.2 and 4.3 are very similar... With the 
terminology suggestion I made in my first bullet point, Section 4.3 will 
  become "Constructing an IMDN document".

10) Sections 4.2.1 and 4.2.2 should describe how to populate all the 
elements of the IMDN XML document, but they are not described. Instead, 
The Content-Disposition header is described, but that one falls into 
Section 4.2, not 4.2.1.

11) Section 4.2.2 reads:

    There are situations where the recipient user agent cannot determine
    if or when the message has been read.  The recipient user agent in
    this case generates a read notification with a <status> value of
    "error" to indicate an internal error by the server.

If the status is unknown, why don't you choose "unknown" as the value, 
rather than "error"?

12) Is '"aggregate" a parameter of the whole header field or a parameter 
of a value. I think of the latter, the text first says the former, and 
then indicates that the latter can be done.... Take a look at the 
following sentences included in the first paragraph in Section 4.3:

    The endpoint does so by adding the Disposition-Notification header
    field parameter "aggregate".

So the above clearly says that 'aggregate' is a parameter of the whole 
header, not of the individual values. But the text then reads:

    For example, a IM sender
    can request delivery notification to be aggregated but read reports
    to be sent individually.  For example:

    Disposition-Notification: positive-delivery;aggregate, read

So I believe the example is correct, and the first sentence should read:

    The endpoint does so by adding a parameter "aggregate" close to the
    value of the Disposition-Notification header that requires
    aggregation. The "aggregate" parameter affects each value
    independently.

13) In Section 4.4 I found the term "Requesting endpoint". Perhaps it is 
good to include it in the definitions, I guess it is not the "sender".

14) Section 5, second paragraph, I guess the 'may' is really a 'MAY':

     An intermediary that forwards an IM may change the recipient address...

15) I found a bit weird a paragraph in Section 5 that speaks about 
procedures that an intermediary can do when it does not support this 
specification. So, if the intermediary does not support the 
specification, it will not insert any "Really-From" header either. This 
is the text I am referring to:

    An intermediary MAY choose to remain on the path of IMDNs for a
    specific IM.  It can do so by adding a CPIM Really-From header field
    as the top Really-From header and populating it with its own address.
    This works well with intermediaries that don't support this extension
    in that IMDNs would therefore traverse directly from receiver to
    sender or to intermediaries that do support the extension.

16) I hate the names of these headers "Really-From", "Really-To". I 
would suggest something more meaningful, for examlpe "Reply-Via" and 
"Via", respectively.

17) I don't understand this text in Section 9.1.4, looks like a 
contradiction that the <original-recipient-uri> contains the URI of the 
final recipient rather than that of the original recipient.

    The <original-recipient-uri> element is optional and carries the URI
    of the final recipient.

18) Section 9.2, first paragraph reads:

    The SIP
    [9] MESSAGE request [10] or the MSRP SEND request [11] that is used
    to carry the IMDN that also carries payload type information MUST
    identify the payload as MIME type "message/imdn+xml" in the Content-
    Type header field.

Ouch, didn't we say that the IMDN document goes into message/cpim body? 
At least the examples in 4.2.1 and 4.2.2 indicate it that way. Also the 
above text contradicts most of the text around Section 10.1

NITS:

- Missing full stop at the end of the paragraph in Section 3.1.
- s/Recipient/recipient
- s/content-type/Content-Type (or is true that the message/cpim header 
is typically spelled as Content-type? RFC 3862 spells it like that...)
- Extra space in before the DateTime header at the end of Section 4.1
- The examples in 4.2.1 and 4.2.2 show a couple of identities in the 
<recipient-uri> and <original-recipient-uri> elements, but they do not 
look like URIs, since they don't contain a URI scheme. I guess they 
should be prepended with "im:"
- The first paragraph in Section 4.3 contains twice "it does so". Can we 
please spell out what is "so", because it may be misleading when you 
have previously said that there are two options to do something.
- Extra ";" at the end of elements in the titles of Sections 9.1.3, 
9.1.4, and 9.1.5.

/Miguel

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

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

---

From: Eric McMurry <[email-masked]>
Date: Thu, 27 Jul 2006 13:59:36 -0500

These are good comments.  I'll second the entire list.  I've embedded  
a few additional comments on them.  Thanks,

Eric

------
Eric McMurry
Estacado Systems

On Jul 7, 2006, at 8:29 AM, Miguel Garcia wrote:

> 1) I think the draft is desperately looking for a terminology  
> section within Section 2. I think we ought to define the following  
> terms (this my understanding):
>

since the goal is to have this be transport independent and SIP and  
MSRP are ostensibly used as examples, perhaps the definition should  
leave out the transports.

> IMDN: a SIP or MSRP message that contains an IMDN document

How about: a message that contains a message/cpim body that contains  
an IMDN document

> message/cpim body: a document that complies with RFC 3862. It can  
> also contain the extensions defined in this document.
>
>
> regular IM or an IMDN. We have a name for the XML part of the IMDN,  
> and  a name for the document part of a regular IM. Don't know if  
> this fits with your intention, I hope so.
>
> 2) In Section 3, Overview, I am missing an overview description of  
> the Aggregation feature.
>
> 3) Make sure that it is always spelled out if you are referring to  
> the Content-Type header in SIP or MSRP, or the Content-Type header  
> that goes into the message/cpim body
>
> First, I don't know what "In this extension" means... I guess it  
> should be "Implementations according with this specification..."
>
> Then I think we should encourage implementations to include a  
> Message-ID header whenever they are requesting IMDN, even when they  
> do not keep state... It may help when debugging, for example.
>

I'll make a stronger version of this statement.  I think that this  
should be a MUST.  This is not that onerous even for a client that  
doesn’t keep state and it makes dealing with the requests easier for  
intermediaries that need to correlate IMs to IMDNs.

> 5) Section 4.1, third paragraph: there seems to be a repetition for  
> the justification of the timestamp:
>
> 7) Section 4.2. I am missing to put a context to IMDNs.  
> Specifically, the text should answer to the question: "is the IMDN  
> XML stuff inserted as SIP/MSRP payload or as message/cpim payload?.  
> So I would start this section with some text along these lines  
> (according to the suggested terminology in my first bullet point).
>
> "Really-From" header like if the reader were familiar with it, but  
> this is the first occurrence of this header. So I would suggest to  
> add a couple of sentence that describes what this header is all  
> about right before this paragraph.
>
> terminology suggestion I made in my first bullet point, Section 4.3  
> will  become "Constructing an IMDN document".
>
> 10) Sections 4.2.1 and 4.2.2 should describe how to populate all  
> the elements of the IMDN XML document, but they are not described.  
> Instead, The Content-Disposition header is described, but that one  
> falls into Section 4.2, not 4.2.1.
>
> 11) Section 4.2.2 reads:
>
> If the status is unknown, why don't you choose "unknown" as the  
> value, rather than "error"?
>
> 12) Is '"aggregate" a parameter of the whole header field or a  
> parameter of a value. I think of the latter, the text first says  
> the former, and then indicates that the latter can be done.... Take  
> a look at the following sentences included in the first paragraph  
> in Section 4.3:
>
> So the above clearly says that 'aggregate' is a parameter of the  
> whole header, not of the individual values. But the text then reads:
>
>    For example, a IM sender
> 13) In Section 4.4 I found the term "Requesting endpoint". Perhaps  
> it is good to include it in the definitions, I guess it is not the  
> "sender".
>
> procedures that an intermediary can do when it does not support  
> this specification. So, if the intermediary does not support the  
> specification, it will not insert any "Really-From" header either.  
> This is the text I am referring to:
>
> would suggest something more meaningful, for examlpe "Reply-Via"  
> and "Via", respectively.
>
> contradiction that the <original-recipient-uri> contains the URI of  
> the final recipient rather than that of the original recipient.
>
> Ouch, didn't we say that the IMDN document goes into message/cpim  
> body? At least the examples in 4.2.1 and 4.2.2 indicate it that  
> way. Also the above text contradicts most of the text around  
> Section 10.1
>
>
> NITS:
>
> - s/content-type/Content-Type (or is true that the message/cpim  
> header is typically spelled as Content-type? RFC 3862 spells it  
> like that...)
> - The examples in 4.2.1 and 4.2.2 show a couple of identities in  
> the <recipient-uri> and <original-recipient-uri> elements, but they  
> do not look like URIs, since they don't contain a URI scheme. I  
> guess they should be prepended with "im:"
> - The first paragraph in Section 4.3 contains twice "it does so".  
> Can we please spell out what is "so", because it may be misleading  
> when you have previously said that there are two options to do  
> something.

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 31 Jul 2006 12:54:21 +0200

> would suggest something more meaningful, for examlpe "Reply-Via" and 

These headers will be used solely for routing IMDNs. How about 
"IMDN-Via" when in an IM and "Via" when in an IMDN?

Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 31 Jul 2006 14:28:43 +0200

> "IMDN-Via" when in an IM and "Via" when in an IMDN?

Actually now that I think about it a little more, I don't like 
"IMDN-Via" and "Via". In SIP "Via" is used to route responses and IMDNs 
are not responses. They are requests. This will confuse some people. I 
now prefer "IMDN-Record-Route" and "IMDN-Route".

Comments?

Hisham

---

From: Ben Campbell <[email-masked]>
Date: Mon, 31 Jul 2006 08:32:04 -0500

On Jul 31, 2006, at 7:28 AM, Hisham Khartabil wrote:

>>> 16) I hate the names of these headers "Really-From", "Really-To".  
>>> I would suggest something more meaningful, for examlpe "Reply- 
>>> Via" and "Via", respectively.
>>>
>>
> "IMDN-Via" and "Via". In SIP "Via" is used to route responses and  
> IMDNs are not responses. They are requests. This will confuse some  
> people. I now prefer "IMDN-Record-Route" and "IMDN-Route".
>

As I mentioned previously, it would be better to choose something  
that does not use the same several-character opening sequence.

But more to the point, the fact that we seem to want to relate this  
to one SIP mechanism or another makes me nervous. How much of SIP are  
we going to recreate? How long until someone asks for a loose-routing  
mechanism, or maybe retransmissions?

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 31 Jul 2006 15:50:43 +0200

On Jul 31, 2006, at 3:32 PM, Ben Campbell wrote:

> As I mentioned previously, it would be better to choose something that 
> does not use the same several-character opening sequence.
>
> But more to the point, the fact that we seem to want to relate this to 
> one SIP mechanism or another makes me nervous. How much of SIP are we 
> going to recreate? How long until someone asks for a loose-routing 

There is a specific reason for doing this, and that is *some* 
intermediaries need to see IMDNs. Information in the To and From 
headers are not enough.

Hisham