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

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 5 Feb 2007 11:56:04 +1100

Hi Miguel

Thanks for your comments. Some replies inline...

On 21/12/06, Miguel Garcia <[email-masked]> wrote:
> Here are my comments to IMDN-02.txt

>
> Delete completely Section 13.

I will not. The text in there lets readers that  we thought about msrp.

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

This text is in there to indicate that resolving someone's AoR when
sending the IMDN may in fact result in a different User Agent. The
text does not suggest that an IM recipient may change the IM Sender
address when sending IMDNs (although we cannot control that). I'll
clarify.

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

I would like to keep it as xml, but i will soften the "always" part.

>
> - Section 5.3. We could think of use the term "rendered" rather than
> "read".

This change is huge and way too late, imo. I'll add clarifying text
but will not change the whole draft.

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

This is mentioned in the draft, but is not called for as a limitation.
I can indicate that it is a limitation.

Thanks,
Hisham

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