Hi, Eric,
> Inline. Sorry for the delay. No problem. I deleted everything we're in synch on. >> o Disposition type: the type of IMDN that can be requested. This >> specification defines three, namely "delivery", "processing" and >> "read" disposition types. >> >> Spencer (nit): I understand that "three" is correct here, but the >> Introduction breaks out successful and unsuccessful delivery, so it lists >> four notifications, while this definition lists three IMDN types. And >> then >> Section 5 breaks out all KINDS of notifications. Could these be presented >> consistently? > > Got text? Does it matter? I'm in the "it doesn't matter, except for a > symmetry that isn't there" camp. Well, sure. In the Introduction, go for This specification defines three categories of disposition types, "delivery", "processing", and "read". Specific disposition types provide more detailed information (for instance, the "delivery" category includes "delivered" to indicate successful delivery, "failed" to indicate failure in delivery, etc.). Here, go for This specification defines three categories of disposition types, "delivery", "processing", and "read". And leave Section 5 unchanged. Does this work for you? >> 9. Identifying Messages >> >> Messages are typically carried in a transport protocol like SIP [8]. >> If the payload carried by the transport protocol does not contain any >> parts of type Message/CPIM then the message is an IM. If the payload >> contains any parts of type Message/CPIM, and none of those parts >> contains a payload that is of type "message/imdn+xml", the message is >> an IM. It is not valid to attempt to carry both an IM and an IMDN in >> a multipart payload in a single transport protocol message. >> >> Spencer: I'm only asking because BLISS seems to be identifying an >> unlimited >> number of possible return codes in any situation - do IMDN-capable >> intermediaries and receivers need to check for this condition? If so, do >> you >> have a suggested return code in mind? > > Nope. >> 13. Transporting Messages using MSRP >> >> While MSRP does not provide a built-in Read or Processing >> notification dispositions, those are generally not considered as >> useful information for session IM. This is because the assumption >> behind MSRP is that SEND requests do not reach a mailbox where >> incoming IMs have to be open, but to an application that renders >> >> Spencer: sorry - don't understand "have to be open" here. > > MSRP already provides a built-in mechanism to supply positive and negative > delivery reports. These reports do not provide built-in Read or Processing > notifications. However, these notifications in session mode are not as > useful as they are for page-mode. This is because the base use case for > MSRP > is that the recipient user agent immediately renders SEND requests > sequentially, providing the session experience. This is unlike page-mode > requests where a user has to actively read the message. That is, they need > to click on a button, open a message, and so on to read the message. > > If new requirements arise in the future determining the need for IMDN in > MSRP, new specifications can be drafted. Sorry for generating a really long response - now that I've read it, all I'm asking for would be "a mailbox where incoming IMs have to be opened" - I was reading "open" as an attribute, but you were using it more like a verb. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
