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

From: Eric McMurry <[email-masked]>
Date: Thu, 27 Jul 2006 14:00:09 -0500

I understand that a rewrite is being considered, so I'll hold off on  
editorial comments.

1) I'm struggling a bit with the application of this to MSRP.  DNs in  
general seem to make more sense for non-realtime applications (like  
page-mode messaging).  For realtime, session-mode, applications, the  
session protocol ensures that messages are delivered.  Also, sessions  
tend to be interactive which I think greatly lessens the value of  
read notifications.  Perhaps someone has a use case for this to make  
the value more clear?

2) The available disposition states ("delivered", "read") are suited  
for responses from the target UA, but not so much for  
intermediaries.  I think reintroducing something like the "processed"  
state, but more specific, may be in order.  Take, for example, the  
store-and-forward case.

An intermediary strictly following the current spec would return a  
negative delivery notification when it was not able to reach a  
target.  If the intermediary provides store-and-forward service  
though, this results in a less than ideal experience for the user  
requesting the IMDN.  They would almost immediately receive an  
indication that their message was not delivered.  Some time later  
(assuming that the message was subsequently successfully delivered),  
they would receive another IMDN for the same message indicating  
success (this one is a bit fuzzier I think).

The net is that it is confusing to the user.  I would suggest adding  
a "stored" state to handle this.  It would be sent by an intermediary  
providing store-and-forward service and would provide the sender with  
a much more accurate view of what the intermediate disposition of  
their message was.

3) "Future extensions" are mentioned in several places, but no  
extension mechanism is specified.  Perhaps a mechanism for vendor  
specific extensions should be specified to avoid collisions with  
future versions of this spec.

4) The example of an IM body with an IMDN request (section 4.1) has  
not caught up with the addition of a CPIM namespace to the  
specification.

5) In section 4.4 "Keeping State", second paragraph, perhaps the  
phase "user choice" should read "local policy" (okay, that was a bit  
editorial :-)

6)  Description of use of the Original-To header should spell out  
that this header should only be added if it does not already exist.   
It is possible that there will be multiple intermediaries in the  
path, and only the first one should do this.

7) I agreed with Miguel Garcia's comment on Really-To and Really-From  
in another email, but allow me to reiterate.  This is a Via-like  
mechanism and would be less confusing (at least to me) if it were  
named as such.

8) Aggregation.  Let's start with a scenario.  Say there's a request  
to a list exploder with a local policy on the requested list to not  
reveal the list members.  Let's also say that the exploder is going  
to aggregate IMDNs either by policy or request.

So the request is exploded, and time passes.  The exploder collects  
some IMDNs and decides it's time to send an aggregate response.   
Since the local policy is to not reveal list members, it strips this  
info from all of the IMDNs.  Then it prepares and sends the  
aggregated IMDN.

The UA that originated the request to the list exploder then receives  
a list of IMDNs with no user information in them.  Now, how will this  
be presented to the user?  The client only knows that some number of  
users on the list received the message, some number didn't, and an  
unknown number did or didn't receive it.

The number of aggregated IMDNs could be large as well and may require  
multiple messages (only 1300 bytes available for MESSAGE) to send.  I  
would suggest that aggregated IMDNs don't make sense if the policy of  
the aggregator is to strip the recipient info.  The most useful piece  
of delivery information that can probably be obtained in this  
scenario is that the message was delivered successfully or not to the  
list server.  This could be accomplished by sending a "delivered"  
state IMDN from the list server, or if something more explicit is  
desired, another intermediate state, such as "exploded" (okay, that  
was just for fun, but it conveys the status) could be defined.

9) I'm sure this would have been covered in the next version, but  
just in case:  the text for the IANA registration of the Content- 
Disposition header (13.5) is missing.

Thanks,

Eric

-----
Eric McMurry
Estacado Systems

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

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 28 Jul 2006 15:33:44 +0200

Hi,

Thanks for the comments. Responses inline...

On Jul 27, 2006, at 9:00 PM, Eric McMurry wrote:

> tend to be interactive which I think greatly lessens the value of read 
> notifications.  Perhaps someone has a use case for this to make the 
> value more clear?

Having a message session with a machine the requires delivery of IMs in 
proper sequence and therefore need a delivery notification before 
sending the next one.

> for responses from the target UA, but not so much for intermediaries.  
> I think reintroducing something like the "processed" state, but more 
> specific, may be in order.  Take, for example, the store-and-forward 
> case.

We have deliberately limited it to delivered and read. Future 
extensions can define something like "processed"

> indication that their message was not delivered.

No. They wouldn't receive anything. The message is still to be 
delivered.

>   Some time later (assuming that the message was subsequently 
> successfully delivered), they would receive another IMDN for the same 
> message indicating success (this one is a bit fuzzier I think).

This would be the first one they get.

>
> The net is that it is confusing to the user.  I would suggest adding a 
> "stored" state to handle this.  It would be sent by an intermediary 

Added text in section 9.1 suggesting future extensions must be in an 
RFC.

> not caught up with the addition of a CPIM namespace to the 

I actually forgot this was there. I removed the definition of the new 
namespace and referred to the default namespace instead.

>
>
> 5) In section 4.4 "Keeping State", second paragraph, perhaps the phase 
> "user choice" should read "local policy" (okay, that was a bit 
> editorial :-)

I actually prefer user choice since it clearly states that the user 
makes that choice and not the implementer.

>
>
> 6)  Description of use of the Original-To header should spell out that 
> this header should only be added if it does not already exist.  It is 
> possible that there will be multiple intermediaries in the path, and 
> only the first one should do this.

Yes. This is done already in my local copy of the next version.

> mechanism and would be less confusing (at least to me) if it were 

I'll make that change.

> reveal the list members.  Let's also say that the exploder is going to 
> aggregate IMDNs either by policy or request.
>
> some IMDNs and decides it's time to send an aggregate response.  Since 
> the local policy is to not reveal list members, it strips this info 
> from all of the IMDNs.  Then it prepares and sends the aggregated 
> IMDN.

A list server can send *ONE* imdn indicating "delivered" after is has 
received some or all of the IMDNs. This is only an option of course.

> be presented to the user? 

"x users received the message" is one example. This is an 
implementation choice

>  The client only knows that some number of users on the list received 
> the message, some number didn't, and an unknown number did or didn't 
> receive it.

That acceptable, imo.

> the aggregator is to strip the recipient info.

I disagree. I think it does make sense. Sometimes I am interested that 
enough people received the message, not who.

>   The most useful piece of delivery information that can probably be 
> obtained in this scenario is that the message was delivered 
> successfully or not to the list server.  This could be accomplished by 
> sending a "delivered" state IMDN from the list server, or if something 
> more explicit is desired, another intermediate state, such as 
> "exploded" (okay, that was just for fun, but it conveys the status) 
> could be defined.

>
>
> 9) I'm sure this would have been covered in the next version, but just 
> in case:  the text for the IANA registration of the 
> Content-Disposition header (13.5) is missing.

Yes. Added.

Thanks,
Hisham

---

From: Ben Campbell <[email-masked]>
Date: Fri, 28 Jul 2006 10:04:59 -0500

On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote:

>> I understand that a rewrite is being considered, so I'll hold off  
>> on editorial comments.
>>
>>
>> 1) I'm struggling a bit with the application of this to MSRP.  DNs  
>> in general seem to make more sense for non-realtime applications  
>> (like page-mode messaging).  For realtime, session-mode,  
>> applications, the session protocol ensures that messages are  
>> delivered.  Also, sessions tend to be interactive which I think  
>> greatly lessens the value of read notifications.  Perhaps someone  
>> has a use case for this to make the value more clear?
>
> Having a message session with a machine the requires delivery of  
> IMs in proper sequence and therefore need a delivery notification  
> before sending the next one.
>

I'm not sure I buy this example. I can use the built in notification  
mechanism in MSRP to accomplish the same thing.

The only use cases I can think of involve messages that cross session  
"boundaries", i.e. when some sort of MSRP B2BUA is involved.

I've mentioned before that I think it makes more sense to leave such  
specification on how we use IMDN fpr MSRP until we define such  
applications. Or at least spec out some agreed requirements for IMDN  
in MSRP--right now we are speculating on how it might be used. I am  
not at all confident our speculation will turn out to be true.

>>
>>
>> 2) The available disposition states ("delivered", "read") are  
>> suited for responses from the target UA, but not so much for  
>> intermediaries.  I think reintroducing something like the  
>> "processed" state, but more specific, may be in order.  Take, for  
>> example, the store-and-forward case.
>

On reflection, when using SIP, I think receiving a 202 to a MESSAGE  
is means the same thing that Eric is asking for. It may be worth  
considering whether we want to have that concept in IMDN. (I lean  
towards "no"-We have a slippery slope here on adding too much  
transport functionality to IMDN.)

> No. They wouldn't receive anything. The message is still to be  

When I first read Hisham's response, I thought he was saying nothing  
would be sent unless delivery succeeded. But I think he means that  
the intermediary should not return a failure IMDN until it had  
exhausted all opportunities to deliver the message. If so, then I  
think I agree.

>> successfully delivered), they would receive another IMDN for the  
>> same message indicating success (this one is a bit fuzzier I think).
>
>> The net is that it is confusing to the user.  I would suggest  
>> adding a "stored" state to handle this.  It would be sent by an  
>> intermediary providing store-and-forward service and would provide  
>> the sender with a much more accurate view of what the intermediate  
>> disposition of their message was.
>>
>>
> Added text in section 9.1 suggesting future extensions must be in  
> an RFC.
>
>>
>>
>> 4) The example of an IM body with an IMDN request (section 4.1)  
>> has not caught up with the addition of a CPIM namespace to the  
>> specification.
>
> I actually forgot this was there. I removed the definition of the  
> new namespace and referred to the default namespace instead.

We are taking the namespace out? Why? Or did I misread your intent?

Namespaces are the defined mechanism for extending CPIM.

>> phase "user choice" should read "local policy" (okay, that was a  
>> bit editorial :-)
>

If that is the intent, we need more normative language to say the  
implementation MUST or SHOULD let the user decide. But in this case,  
I do think this is more an implementation choice than a user choice.  
I don't see an end-user being in a position to decide whether they  
want to keep state or not. This is more a matter of the type of  
device, it's memory constraints, the intended user experience, etc.

>> that this header should only be added if it does not already  
>> exist.  It is possible that there will be multiple intermediaries  
>> in the path, and only the first one should do this.
>
>> 7) I agreed with Miguel Garcia's comment on Really-To and Really- 
>> From in another email, but allow me to reiterate.  This is a Via- 
>> like mechanism and would be less confusing (at least to me) if it  
>> were named as such.
>
> I'll make that change.
>

By the way, we got feedback on MSRP to try to avoid having different  
header names start with the same several letters. It makes parsing  
harder.

>>
>>
>> 8) Aggregation.  Let's start with a scenario.  Say there's a  
>> request to a list exploder with a local policy on the requested  
>> list to not reveal the list members.  Let's also say that the  
>> exploder is going to aggregate IMDNs either by policy or request.
>>
>> So the request is exploded, and time passes.  The exploder  
>> collects some IMDNs and decides it's time to send an aggregate  
>> response.  Since the local policy is to not reveal list members,  
>> it strips this info from all of the IMDNs.  Then it prepares and  
>> sends the aggregated IMDN.
>
> A list server can send *ONE* imdn indicating "delivered" after is  
> has received some or all of the IMDNs. This is only an option of  
> course.
>
>>
>> The UA that originated the request to the list exploder then  
>> receives a list of IMDNs with no user information in them.  Now,  
>> how will this be presented to the user?
>
>>  The client only knows that some number of users on the list  
>> received the message, some number didn't, and an unknown number  
>> did or didn't receive it.
>
> That acceptable, imo.

Acceptable, maybe. Can we describe a use case for which it is _useful_.

>
>>
>> The number of aggregated IMDNs could be large as well and may  
>> require multiple messages (only 1300 bytes available for MESSAGE)  
>> to send.  I would suggest that aggregated IMDNs don't make sense  
>> if the policy of the aggregator is to strip the recipient info.
>
> I disagree. I think it does make sense. Sometimes I am interested  
> that enough people received the message, not who.
>
>>   The most useful piece of delivery information that can probably  
>> be obtained in this scenario is that the message was delivered  
>> successfully or not to the list server.  This could be  
>> accomplished by sending a "delivered" state IMDN from the list  
>> server, or if something more explicit is desired, another  
>> intermediate state, such as "exploded" (okay, that was just for  
>> fun, but it conveys the status) could be defined.
>
>
>>
>>

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 28 Jul 2006 17:25:39 +0200

Hi Ben,

Comments inline...

On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote:

>> Having a message session with a machine the requires delivery of IMs 
>> in proper sequence and therefore need a delivery notification before 
>> sending the next one.
>>
>

I used a bad example here. The draft actually says that for MSRP, 
delivery notification are not relevant since MRSP has that built in. 
The draft stresses that read notifications and any other future 
extensions might be useful.

I don't agree that we need an application to define this. Companies 
might have use cases for this that they don't want to make public yet 
that uses on IMDNs for MSRP. Why make them wait 2 years to get an RFC 
where the text in the current draft is not damaging?

> On reflection, when using SIP, I think receiving a 202 to a MESSAGE is 
> means the same thing that Eric is asking for. It may be worth 
> would be sent unless delivery succeeded. But I think he means that the 
> intermediary should not return a failure IMDN until it had exhausted 
> all opportunities to deliver the message. If so, then I think I agree.

Yes thats what I meant.

>>> a "stored" state to handle this.  It would be sent by an 

I believe using the default namespace is allowed. You can define a new 
namespace for new headers if you are worried about header name clashes. 
Or am I wrong?

> implementation MUST or SHOULD let the user decide. But in this case, I 
> do think this is more an implementation choice than a user choice. I 
> don't see an end-user being in a position to decide whether they want 
> to keep state or not. This is more a matter of the type of device, 
> it's memory constraints, the intended user experience, etc.
>
This is the text in the draft "How long to keep items in the "Sent 
Items" box is a user choice." It is not about keeping state, it is 
about keeping items in the sent items box.

This is not an implementer choice. I would smash the phone if it 
removed things from my "Sent Items" box without me doing it 
deliberately :) We are not discussing how to implement a "Sent Items" 
box anyhow in this draft.

>>> 7) I agreed with Miguel Garcia's comment on Really-To and 
>>> Really-From in another email, but allow me to reiterate.  This is a 
>>> Via-like mechanism and would be less confusing (at least to me) if 
>>> it were named as such.
>>
>> I'll make that change.
>>
>
>>> receives a list of IMDNs with no user information in them.  Now, how 
>>> will this be presented to the user?
>>
>>> received the message, some number didn't, and an unknown number did 
>>> or didn't receive it.
>>
>> That acceptable, imo.
>

What are you suggesting? Are you suggesting that no aggregation is done 
for private lists? or should the list server reject the IM? I can't 
think of a use case now, but I don't think we should add complications 
by forbidding something. This is implementation choice.

Thanks,
Hisham

>>> require multiple messages (only 1300 bytes available for MESSAGE) to 
>>> send.  I would suggest that aggregated IMDNs don't make sense if the 
>>> policy of the aggregator is to strip the recipient info.
>>
>>> successfully or not to the list server.  This could be accomplished 
>>> by sending a "delivered" state IMDN from the list server, or if 
>>> something more explicit is desired, another intermediate state, such 
>>> as "exploded" (okay, that was just for fun, but it conveys the 
>>> status) could be defined.
>>
>>
>>>
>>>
>>> just in case:  the text for the IANA registration of the