Subject: [Simple] MSRP-10 - Overlapping Messages

From: Eric Burger <[email-masked]>
Date: Mon, 7 Mar 2005 14:06:00 -0500

I would offer that MRSP should explicitly state that if a sender sends
overlapping byte ranges in separate chunks, the octets MUST be identical.

This would resolve two, conflicting requirements in section 7.3.1.  Section
7.3.1 states that new chunks overwrite old chunks (the bytes 50-150 in the
second chunk overwrite bytes 50-100 in the first chunk).  However, this is
fundamentally in opposition to the over-following paragraph, that states
that the recipient UI can start rendering, if it is possible and it desires
to.

At first, I was thinking that it might not make sense to give the statement
that overlapping byte ranges MUST be identical, as there is no protocol
method of enforcement.  However, the protocol enforcement is simply that the
results are undefined.  In fact, the results ARE undefined, because
depending on whether the UI incrementally displays the message or buffers
the whole message will determine what gets rendered.

Said differently, we COULD mandate the "last chunk wins".  However, that
means that recipients would be REQUIRED to buffer entire chunked messages
before rendering them.  I would NOT want to mandate 7GB buffers on all
devices because someone wanted to send Star Trek X.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2005 14:37:40 -0500

I agree.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Mar 2005 21:08:14 -0600

We had this exact argument in a previous work group meeting. (I forget 
which one.) A couple of people very vocally stated a need to be able to 
have the latter request overwrite the original.) Rather than rehash the 
decision, is there a way we can make it work?

I think a good compromise might be that the recipient SHOULD use the 
latest received content. Having already rendered the older content is a 
bona-fide reason to stick with the older content. This does introduce 
an issue where the combined content may be non-renderable with one or 
the other choice. There fore the sender [MUST | SHOULD] not depend on 
either behavior in the recipient.