Subject: [Simple] MSRP: Surpression of duplicates

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2004 15:36:27 -0500

The working group has gone round and round on whether (and how) we 
handle worry about the surpression of duplicate messages, in situations 
where a failure occurs, and the sender chooses to re-send content on a 
new session.

Since we have introduced the concept of a MessageID, this becomes fairly 
easy to accomplish. If we specify the MessageID to be globally unique, 
or even just very likely to re-occur in a relatively short time period, 
then the receive can simply watch for duplicate messageIDs. The 
receiver's action upon receiving a duplicate would be entirely up to 
local policy (although simply displaying the duplicate to the user 
without any warning of duplication would be a bad choice.)

This approach only works for detecting whole-content duplication, rather 
than chunk duplication. We recommend that chunks of a given message not 
be spread across more than one session. Within any given session, the 
chunking mechanism already provides a way to notice duplication--you can 
watch for byte-range overlaps.

If there are no subtantive objections to the approach, the next draft 
version will describe the details.

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

---

From: [email-masked]
Date: Wed, 30 Jun 2004 17:47:49 +0300

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 30.June.2004 16:41
> To: Cullen Jennings
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
> Subject: Re: [Simple] MSRP: Surpression of duplicates
> 
> 
> 
> 
> Cullen Jennings wrote:
> 
> > On 6/29/04 12:41 AM, "[email-masked]"
> > <[email-masked]> wrote:
> > 
> > 
> >>
> >>>-----Original Message-----
> >>>From: [email-masked]
> >>>[mailto:[email-masked]]On Behalf
> >>>Of ext Ben Campbell
> >>>Sent: 28.June.2004 23:36
> >>>To: Simple WG
> >>>Subject: [Simple] MSRP: Surpression of duplicates
> >>>
> >>>
> >>>be spread across more than one session.
> >>
> >>I don't like this recommendation. If I'm sending you a 5GB 
> file in chunks and
> >>the session breaks, then I would like to continue where I 
> left off. But I
> >>guess it doesn't necessarily have to be the same message ID.
> > 
> > 
> > I got lost on this - I think I agree with Hisham - I think 
> the mechanims
> > does work for chunk duplicate - you find a message using 
> the messageId and
> > if you already have data for the range of data in the 
> chunk, you can ignore
> > the part that is an overlap. Perhaps that is what you say 
> in the next
> > paragraph
> 
> Yes. I meant to say that, the message ID plus the byterange 
> information 
> is sufficient to detect chunk duplication or overlap, so we 
> don't need 
> some special chunk ID.
> 
> I believe Hisham was objecting to the recommendation not to spread 
> chunks of the same message accross sessions. I will back away 
> from that 
> a bit and say you shouldn't do it under normal conditions, 
> but it may be 
> acceptable for recovering from a failed session.
> 
> (Hisham, would that make you happier?)

Yes. I only wanted it for failed sessions.

Thanks,
Hisham

> 
> 
> > 
> > 
> > 
> >>>Within any given session, the