RE: [Simple] IMDN?

["Burger, Eric" <[e-mail]>]

Long posts are good!  It means someone is reading the draft!!!

Disposition is a term of messaging art.  I'd be hard pressed to change it, but I too can be persuaded.

Good point on the message ID.  The SHOULD, with the clarifying text (unless you can't) sounds good.

Displayed works for me.

A lot of the editorial stuff is excellent, and should make the draft more understandable.  Thanks. 


-----Original Message-----
From: Laurent Steffan [mailto:[e-mail]] 
Sent: Thursday, March 02, 2006 1:43 PM
To: Simple WG
Cc: Burger, Eric
Subject: Re: [Simple] IMDN?

Hi Eric,

Here are some comments on your draft.

1/ On the term Delivery:

1.a) you have in some places changed "Delivery" to "Disposition", but
not consistently : for instance on page 5 (in the "Introduction") you
state "This notification message is the Instant Message Disposition
Notification (IMDN)" while the title, and elsewhere, says "Delivery".

1.b) While I do believe that reading of a message by a user is different
form the protocol action called delivery, I also find that "Disposition"
is not a very good term. Does it refer to "disposing *of*" a message ?
not really, since the message is only handed over to the user who may
then read it, delete it, have it processed by an automatic system, or do
whatever else she wants ("she" being on the receiver side...). So what
does it refer to ? Also, the term Disposition of a message may be used
(e.g. in some RFCs) to describe the layout of a message, so that's
misleading. I'd rather call the process you describe by another term:
"Acceptance", perhaps (IM User Acceptance Notification ??? er...)
OTOH, RFC 3798 makes a precedent, so I won't enter a lost battle...

2/  On the globally unique identifier :

You state  "A UAC MUST include a globally unique Message-ID.  It is
necessary for the Message-ID to be unique to the UAC in order for the
UAC to be able to exactly correlate IMDN's with the messages they refer to".

This is OK with me. However, part of your document describes conditions
in which this uniqueness is not easily achievable, if at all :

"Devices with limited resources and a high likelihood of total failure,
such as a mobile phone, will lose their IMDN request state on total failure"

so I wonder what will happen to the uniqueness of the Message-ID when
such a device is reset : what's to prevent the device from reusing
Message-IDs that it has already used ? of course I can envision deriving
the Message-ID from the contents of the message (a hash function for
instance) but is this practical for a device with "limited resources" ?

In order to take care of that difficulty, you may want to  change your
MUST to a SHOULD. (OTOH, you may want to tell me where my reasoning is
faulty, I wouldn't be too surprised...)

Also, I think you should specify how the *globally unique* Message-ID is
built : does it consist of a "device-identifier" + "local message
identifier", for instance ? or is it derived from the message itself
(see above) ? or random within a large space ? ...

3/ In 6.2.2, "processed" :

You state that "the target URI of the message is a B2BUA", but that's
not necessarily the case since in 9.2, "Recipient is the End User UAS",
you say that "the UAS SHOULD generate a processed IMDN"

4/ "There are three broad categories of disposition states", but you
actually name four. ;-)

Besides, this is the only place where you speak of categories: perhaps
you could just say "states" which is after all what you call them later.

5/ When you say "The 'read' state is straightforward", it seems a bit
odd to find that "one cannot determine a priori the user actually read
the message". Perhaps "displayed" might better capture your meaning.

oh, and on the same page (3rd line from the top) you still have a
reference to "deleted" from your previous draft. I think you might
replace it with "processed".

6/ In section 8, you mix actions of the Requesting UAC with those of the
B2BUA. I think for clarity it would be better to cleanly separate the
protocol into "Requesting UAC Behaviour", "B2BUA Behaviour" (split from
the current section 8) and "Reporting UAC Actions" (which already exists
as section 9).

OK, I'll stop there, sorry for the long post!

Best regards,
Laurent

On 19.02.2006 09:03, Burger, Eric wrote:
> There have been exactly zero comments on
> draft-burger-simple-imdn-03.txt.  I know there are many open issues.
> 
> We were hoping to submit a work group draft -00.  The deadline is
> approaching.  The open issues are still open.
> 
> Does anyone care about IMDN?  If no one reads the drafts or comments on
> them, then the work is finished, in that the draft will expire and the
> world will not have a standard mechanism for IM delivery reports.

-- 
Laurent Steffan
LAMSADE (Université Paris Dauphine)


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

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