Subject: [Simple] IMDN-02 WGLC comments

From: Ben Campbell <[email-masked]>
Date: Sun, 24 Dec 2006 01:27:22 -0600

Hi,

Here are my WGLC comments on draft-ietf-simple-imdn-02. Apologies if  
any of these are duplicates or rehash old discussions. Also, I was  
reading linearly, so it may be that some comments are resolved later  
in the draft.

General Comments:

I'm very confused by the intent of the "forbidden" state. I think we  
need some text describing its use in more detail, and perhaps  
describing the motive for its inclusion.

We use the term "address" a lot when we really mean "URI". They are  
not interchangeable terms.

We use the term "header" a lot when we really mean "header field".

Whenever we refer to To and From header fields, we need to be  
_exceedingly_ clear we are talking about CPIM and not SIP. I realize  
that should be obvious from context, but I will bet several beers  
that implementors will screw this up.

Abstract:

Remove MSRP and session mode references.

Section 1 paragraph 3:

Remove MSRP reference.

Paragraph 4:  Remove session-mode reference.

Terminology Section

IM Sender: Didn't we remove the ability to request an IMDN go to  
someone other than the IM Sender? If I recall, allowing a different  
destination was agreed to be an unacceptable security problem. If we  
do allow this, we need to make sure it is discussed in the security  
considerations.

Endpoint and Intermediary: See comment above in "General" section.

IMDN Payload or XML Document: Remove "or XML Document"  from the left  
side of the colon. (I assume we are defining one thing, not two. And  
in any case, leaving it there creates a circular definition.

Transport Protocol Message: I think this one would be better with its  
sense reversed. For example "A SIP or other protocol message that  
contains an IM or IMDN". Also, remove MSRP reference.

Section 4:

Paragraph 1, second sentence is hard to follow. It contains too many  
occurrences of "it" with different antecedents.

Third sentence: Inconsistent use of "or" and commas in the list of  
possible dispositions. Suggest changing to "...user or application  
received, did not receive, read, or otherwise disposed..."

Last Paragraph:

The idea of an IMDN going to someone other than the IM sender needs  
more discussion, perhaps in security considerations. At least, we  
cannot just toss the idea out and then assume it doesn't happen in  
the rest of the document. I _think_ that if the only way this can  
happen is when the From: URI resolves to more than one destination,  
it is ok in the sense that we assume all possible resolutions for the  
AoR represent the same "entity", or at least entities sharing the AoR  
identity.

Section 5.1: Paragraph 1: I think we meant to say "delivered to the  
IM Recipient's User Agent",  or "endpoint", don't we? Otherwise it is  
pretty much the same as for "read"

Section 5.2: I don't understand what "forbidden" means in this context.

Section 5.3: Still unclear on how "forbidden" is intended to be used.

last paragraph: I'm not sure that normative language is appropriate  
here. The point is to say that this mechanism is not sufficiently  
long for non-repudiation, not what you do with the knowledge you get  
from it. As currently stated, it seems to put a normative requirement  
on what _users_ do, which is rather futile. (The security  
considerations gets this right, I think.)

Section 6.1 Last Sentence:  I read this to try to say that you have  
to use the string "imdn" when you declare a CPIM namespace prefix. I  
don't think RFC 3862 intended to say that all uses of a CPIM  
namespace must use the same prefix--merely that you must use the  
string from the NS header in a _given_ CPIM message to prefix all  
header fields from that namespace. It is perfectly valid for me to  
declare "NS: foo <urn:ietf:params:cpim-headers:imdn>", then use the  
"foo" prefix throughout my CPIM message.

6.3: Third to last sentence: I think we meant to say "...mandatory  
when sending an IM that requests an IMDN". Also, should we capitalize  
"MANDATORY"?. Also, should second to last sentence use normative  
language?

Section 6.5:  s/address of that intermediary/URI representing that  
intermediary

Section 6.6: Should this section mention what intermediaries do with  
IMDN-Route?

Section 7.1.1.3 Paragraphs 4 and 5: Last line of each of these  
paragraphs belong together in a separate paragraph, I think, since  
they both talk about multiple request values, and seem like non- 
sequiturs in their current host paragraphs.

Section 7.1.2:  The final sentence is confusing. It seems to say use  
"(recipient-uri or original-recipient-uri) if multiple recipients".  
Don't we mean "recipient-uri or (original-recipient-uri if multiple  
recipients)"? If not, we need to clarify when to match on one verses  
the other.

Section 7.1.3:

I mentioned this on the previous draft, but I missed any discussion  
or change due to that comment, so I will make it again. I don't see  
the value of allowing the sender to request aggregation, considering  
that the list server has no obligation to pay any attention. Since  
aggregation policy has a major affect on URI list server performance  
and scalability, I doubt _anyone_ will configure such a server to pay  
attention to sender preferences for aggregation. IMHO, the ability  
for the sender to request whether aggregation will be used or not  
adds no value to justify the complexity.

Section 7.1.4: This entire section is closely related to 7.1.2, and  
should either be included there, or immediately afterwards.

7.2.1: Second paragraph: put quotes around "processing".

Paragraph 4: What is the motivation for requiring the Message-ID CPIM  
header field in an IMDN, since you can't send an IMDN to an IMDN?

Paragraph 5: s/address/URI/

7.2.1.1 first paragraph: Isn't the content-disposition: notification  
requirement true for all IMDN types? If so, it should be moved to 7.2.1

7.2.1.2: Last paragraph: Can we provide an example of a situation  
where this might occur?

Section 8 first paragraph: I think we need some more text here. We  
need to define what we mean by "gateways".

Second paragraph: Is this specification granting permission to  
intermediaries to change the To header? Or does that come from the  
URI-list work? If the second, we need a reference. If the first, we  
need to discuss the implications in the security considerations.  I  
raise this as a red flag since such a change is likely to break  
digital signatures, which were the primary motivators for CPIM in the  
first place.

second to last paragraph: s/pops that header/pops that value/

8.1: Please quote all occurrences of "processing". Otherwise, it is  
easy to confuse the idea of a "processing" notification with the idea  
of processing an notification.

8.2 Second Paragraph:The "MUST" level requirement is directly  
contradicted by later language giving the intermediary quite a bit of  
latitude about when and if it aggregates. (IMHO, the later language  
is correct, and the MUST is not.)

Third Paragraph: Should the last word of first sentence be IM or IMDN?

Second to last paragraph: It would be nice to see an example  
aggregated IMDN message.

Section 10: Do we reference the constructions for URI and "token"  
somewhere? Also, shouldn't we use a more general construction for  
[ Formal-name ] "<" URI ">"?  (such as addrspec?)

Section 11.1.5 : If there was any normative language requiring the IM  
recipient to do something with <subject>, I missed it.

11.1.8: ditto.

12.1.1: Can we document the motivation for requiring an IMDN to be in  
a CPIM envelope? I hear lots of people saying it should, but I have  
not yet heard a convincing reason for it beyond a general belief that  
all IMs should use CPIM. (Which we don't actually _require_).

12.1.3.1 second and third paragraphs : s/GW/gateway/ for all  
occurrences.

4th paragraph: s/error response/non-2XX SIP final response

12.2:

General for section: A lot of this is not about SIP, and probably  
belongs in the earlier "Intermediary behavior" section.

paragraphs 3 and 4 seem contradictory.

Paragraph 5: If the intermediary receives a negative-delivery report,  
shouldn't it just forward the one it received instead of generating a  
new one? (modulo aggregation)

Paragraph 6: Why "MAY"? are we allowing an intermediary to consume  
"processing" notices from downstream without forwarding them back  
upstream?

Section 13:

I don't think ever meant to say IMDN was not applicable to MSRP.  
Rather, we meant to say that we had not explored how it may be  
applicable, and it is therefore out of scope. The final paragraph  
indicates this, but the first paragraph is somewhat provocative.

I also do not think this spec should be making judgments about  
whether the general concept of "read" status is applicable in MSRP.  
We just should leave MSRP out of scope without making judgments one  
way or another.

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