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

[Hisham Khartabil <[e-mail]>]

Note here that the sender of the IM is the one that requests any type 
of IMDN. So, through the UI, the user has to answer all the following 
questions for every IM:

- Do I want to know if the IM is delivered
- Do I want to know if the IM has failed
- Do I want to know if the IM is read

and the new states you are asking for:

- Do I want to know if the IM is processed
- Do I want to know if the IM is stored

Of course these can be global settings, but still, too many.

My opinion is to leave those out for the future. I am outvoted 2 to 1 
here on "processed", but not "stored".

Hisham

On Jul 28, 2006, at 9:04 PM, Burger, Eric wrote:

> Given the message is likely to be processed by the UAC *automaton*, I
> will agree.  If the user will see the message, then I'm less happy with
> that.  We would figure it out, but Joe Six-pack would be mystified.
>
> -----Original Message-----
> From: Eric McMurry [mailto:[e-mail]]
> Sent: Friday, July 28, 2006 2:59 PM
> To: Burger, Eric
> Cc: [e-mail]
> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt
>
> This sound like a great reason to have a separate IMDN state for
> processed/stored to me.  In this case, the B2BUA acting as a store-
> and-forward server could send an IMDN indicating that the message was
> stored.  Now the user knows explicitly what happened.
>
> Later, when the message was finally delivered, they could get another
> IMDN indicating that.
>
>
> On Jul 28, 2006, at 1:54 PM, Burger, Eric wrote:
>
>> How would the sender have a clue that they are sending their
>> message to
>> a store-and-forward server?
>>
>> I'm sending you an IM because my presence info is out of date.  Your
>> friendly in-the-network B2BUA picks up the message, accepts it (as a
>> UAS), and now holds it for you.  I certainly didn't think I was
>> talking
>> to a B2BUA when I initiated the session.
>>
>> -----Original Message-----
>> From: Eric McMurry [mailto:[e-mail]]
>> Sent: Friday, July 28, 2006 2:51 PM
>> To: Burger, Eric
>> Cc: [e-mail]
>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt
>>
>> thanks for the reference.
>>
>> I still think it is useful though to have the possibility of IMDNs
>> generated at both an intermediary and the final recipient.  For store-
>> and-forward, I can see the user wanting to know that the message was
>> stored, and later, that it was delivered.  For a list, I can see the
>> user wanting to know that the list server processed the message, and
>> later, that recipients received/read it.
>>
>>
>>
>> On Jul 28, 2006, at 12:51 PM, Burger, Eric wrote:
>>
>>> The hint is actually old, from draft-burger-simple-imdn:
>>>
>>>    To request the generation of an IMDN, the Requesting UAC MUST
>>> include
>>>    the Disposition-Notification and Message-ID headers.  The
>>> Requesting
>>>    UAC MAY also include a List-Action header to provide down-stream
>>>    B2BUA's with the user's desire for IMDN reporting by the final
>>> target
>>>    of B2BUA expansion or the B2BUA itself.  B2BUA's SHOULD include
>>> the
>>>    Original-From header, with the value of the inbound From header,
>>>    unless privacy considerations require the B2BUA to not transmit
>>> the
>>>    Original-From header.  Likewise, B2BUA's SHOULD copy the value
>>> of the
>>>    inbound Message-ID into the outbound Original-Message-Id header.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Eric McMurry [mailto:[e-mail]]
>>> Sent: Friday, July 28, 2006 12:56 PM
>>> To: Burger, Eric
>>> Cc: Hisham Khartabil; Ben Campbell; [e-mail]
>>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt
>>>
>>> also inline...
>>>
>>> On Jul 28, 2006, at 10:50 AM, Burger, Eric wrote:
>>>
>>>> Mine, too (inline):
>>>>
>>>>> -----Original Message-----
>>>>> From: Hisham Khartabil [mailto:[e-mail]]
>>>>> Sent: Friday, July 28, 2006 11:26 AM
>>>>> To: Ben Campbell
>>>>> Cc: Eric McMurry; [e-mail]; Burger, Eric
>>>>> Subject: Re: [Simple] Re: Comments on draft-ietf-simple-imdn-00.txt
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> Comments inline...
>>>>>
>>>>> On Jul 28, 2006, at 5:04 PM, Ben Campbell wrote:
>>>>>
>>>>>>
>>>>>> On Jul 28, 2006, at 8:33 AM, Hisham Khartabil wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thanks for the comments. Responses inline...
>>>>>>>
>>>>>>> On Jul 27, 2006, at 9:00 PM, Eric McMurry 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.
>>>>>
>>>>> 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?
>>>>
>>>> I can go either way on this one.
>>>
>>> I'll buy the hidden use case and I'll also buy that there could
>>> easily be one I haven't thought of.  What I was hoping to get from my
>>> question though was someone saying that they needed this (and better
>>> still, why).
>>>
>>>>
>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> We have deliberately limited it to delivered and read. Future
>>>>>>> extensions can define something like "processed"
>>>>>>
>>>>>> 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.)
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> No. They wouldn't receive anything. The message is still to be
>>>>>>> delivered.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Yes thats what I meant.
>>>
>>> and I agree that that interpretation makes more sense.  I was just
>>> being strict on how I read "final response"
>>>
>>>>>
>>>>>>>>   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 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.
>>>>
>>>> I really, really would rather have the "processed" state.  Let the
>>>> protocol say what it is really doing, not what it thinks might be
>>>> possibly going on.  The B2BUA receives a message: it is being
>>>> processed,
>>>> so tell the UAC so.  A later delivery message should work just fine.
>>>> The B2BUA doesn't get the message, or it can't process the message:
>>>> send
>>>> a failure report.
>>>>
>>>> I don't like "stored", because that is only relevant to
>>>> store-and-forward.  IMDN should work for any B2BUA, not just a
>>>> store-and-forward B2BUA.
>>>>
>>>> Note that having the hint to the B2BUA that the UAC is looking for
>>>> the
>>>> fate of the B2BUA's handling of the message, rather than the
>>>> endpoints
>>>> handling of the message, removes the ambiguity of who should
>>>> generate
>>>> the IMDN and what the IMDN means.
>>>
>>>
>>> I'm also strongly in favor of allowing the protocol to have reporting
>>> of intermediate states.  This allows for more descriptive status to
>>> be presented to the user.
>>>
>>> I still like "stored", but not as the only option.  I was suggesting
>>> that a one example of a category of states of the "processed" ilk.
>>> However, I'm okay with using "processed" for this since we have the
>>> Note field for the intermediary to provide more descriptive
>>> information in.  The drawback to this is that we lack a standard way
>>> of conveying the more descriptive information.
>>>
>>> The use of the hint to the intermediary is new to me.  Are you
>>> suggesting that in this case, only the B2BUA would generate an IMDN?
>>> I was thinking more along the lines that the IMDN generated by the
>>> B2BUA would be an intermediate response, and that the final endpoint
>>> would also generate one.  I think this would be true for both
>>> "processed" and "stored" types of states.
>>>
>>>
>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> 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?
>>>>
>>>> Namespaces are also used for capabilities negotiation, so it really
>>>> should be included.
>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>> 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.
>>>>
>>>> Which is also why it isn't really user choice...
>>>
>>> I can't imagine a client not giving this choice to the user (except
>>> perhaps in the case of limited client resources).  That said, I think
>>> this should be left up to the implementor since it is a UI feature.
>>>
>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>
>>>> A LONG, SLOW PAINFUL DEATH TO IMPLEMENTORS THAT DO NOT BUILD A REAL
>>>> PARSER THAT FOLLOWS THE FULL SPECIFICATION.  We first tear out their
>>>> fingers so they can no longer inflict "almost compatible"
>>>> implementations that we later have to work around.
>>>>
>>>> GIVE ME A BREAK.  Too bad if my 12 character string starts with the
>>>> same
>>>> 6 characters!  If they are not reading the entire string, they have
>>>> blown it already.
>>>
>>> I wasn't going to be quite so violent in my response, but I agree :-)
>>>
>>>>
>>>>
>>>>>>>> 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?
>>>>>>>
>>>>>>> "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.
>>>>>>
>>>>>> Acceptable, maybe. Can we describe a use case for which it is
>>>> _useful_.
>>>>>
>>>>> 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.
>>>>
>>>> Agreed (with Hisham)
>>>
>>> So, a list server can then potentially:
>>>
>>> ((ignore the IMDN request) or ((optionally generate a "processed"
>>> type IMDN when the list is exploded) and (optionally generate one
>>> "delivered" IMDN when it receives some number of IMDNs from the
>>> recipients) or (optionally generate some number of aggregated IMDNs
>>> with the recipient info stripped))
>>>
>>> and the client would then have to savvy any combination of these if
>>> it wanted to send to a list.  Maybe this is reasonable, but it seems
>>> as if we've come up with several ways to skin a cat, when it may be
>>> that we really had a porcupine (and who wants to skin a porcupine?).
>>> I'll have to give this some more thought.
>>>
>>>>
>>>>>>>> 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.
>>>>
>>>> This would be handled by the UAC giving the B2BUA the hint that the
>>>> IMDN
>>>> is for the B2BUA to generate (in its role as a UAS) and not for
>>>> down-stream nodes to generate.
>>>>
>>>>
>>>>>>>> 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.
>
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/simple
>


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