Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and fail ed connections?

From: Ben Campbell <[email-masked]>
Date: Mon, 16 May 2005 21:41:48 -0500

Not like Ben, apparently, as Ben is _much_ later coming to this  
party. Sorry about that. I'd make excuses but it would be rather  
pointless.

The original point in allowing the use of the same message ID in a  
replacement session is so the sender can tell the receiver that "this  
is the same as a previous message I tried to send but don't know if  
it succeeded. If you have already gotten this, ignore it." (Or  
overwrite it, but that is a different argument.)

So, if we mandate that we cannot ever repeat a message ID, we take  
away that ability. I can resend the message if I want, but if the  
recipient has already gotten it, he will get it again.

Are people okay with removing that feature? Or am I misreading this  
whole argument?

On Apr 26, 2005, at 2:56 PM, Eric Burger wrote:

> I agree wholeheartedly.  Yes, like Ben, I'm coming to this party late.
> However, a unique message ID fixes a bunch of problems we can see  
> coming
> (see previous thread).  Moreover, it makes message delivery  
> notification (my
> next project) a lot easier.
>
> Since the namespace of Message ID is rather large, and SMTP has been
> generating unique Message ID's for, what, 20 years, do you think we  
> could
> get consensus on this issue?
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Ignacio Más
>> Ivars (KI/EAB)
>> Sent: Thursday, April 14, 2005 8:13 AM
>> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat
>> Cc: SIMPLE mailing list
>> Subject: RE: [Simple] message-sessions-10 WGLC: unique
>> message ID and failed connections?
>>
>> Paul, Gonzalo:
>>
>> I agree completely with Gonzalo's comment. That is why I was
>> suggesting that we just add the paragraph from RFC 2822 were
>> the uniqueness of message ID is defined, i.e:
>>
>>  ======================rfc2822
>>  The "Message-ID:" field provides a unique message identifier that
>>    refers to a particular version of a particular message.  The
>>    uniqueness of the message identifier is guaranteed by the host  
>> that
>>    generates it.  This message identifier is intended to be
>>    machine readable and not necessarily meaningful to humans.
>>  A message
>>    identifier pertains to exactly one instantiation of a particular
>>    message; subsequent revisions to the message each receive
>> new message
>>    identifiers.
>> ======================rfc2822
>>
>> That would not introduce any other disruptment to the draft, would  
>> it?
>>
>> /Ignacio
>>
>> -----Original Message-----
>> From: Gonzalo Camarillo
>> To: Paul Kyzivat
>> Cc: Ignacio Más Ivars (KI/EAB); SIMPLE mailing list
>> Sent: 4/13/2005 8:41 PM
>> Subject: Re: [Simple] message-sessions-10 WGLC: unique
>> message ID and failed connections?
>>
>> Paul,
>>
>>
>>> But, as with everything else, this could get complex in a 3pcc
>>> situation. A 3pcc controller might do a transfer using
>>>
>> reinvites. As
>>
>>> result, one endpoint thinks it has a replacement session, while the
>>> other thinks it has a new session. The guy who thinks its a new
>>>
>> session
>>
>>> can't very well know what message ids had been used before.
>>>
>>
>> I agree with you on this one. We have already been there
>> (e.g., the comedia and the preconditions stuff), and relaying
>> on the concept of a SIP session to set the scope of any
>> media-related identifier is not a good idea.
>>
>> Paul and I tried exactly the same in comedia (using
>> identifiers scoped by the SIP session) and cocluded that they
>> did not work.
>>
>>
>>> Its only
>>> soluiton is to use message ids that are guaranteed to be
>>>
>> globally  > unique.
>>
>> Yes, I agree this is the way to resolve the problem. In fact,
>> I believe this is how RFC 2822 defines uniqueness of message
>> identifiers. With your proposal we kill two birds with the
>> same stone. We align with RFC
>> 2822 and we resolve the session mobility problem.
>>
>> Thanks,
>>
>> Gonzalo
>>
>> _______________________________________________
>> Simple mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/simple
>>
>>
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>
>

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

---

From: Ignacio Mas Ivars <[email-masked]>
Date: Tue, 17 May 2005 09:16:40 +0200

Well, rpecisely because we want the receiver to be able to differentiate
that this is the same message being resent we need to have unique
message IDs in time and space. The scenario you describe is perfectly
possible. If the sender wants to resend the message it will use the same
message ID and the receiver knows positively that it is a copy of the
previous message. The problem can arise when we don't require ID's to be
unique, since there could be some pathological scenarios where the
receiver can have doubts on whether is the same or a new message. So, in
my opinion we are precisely ensuring that we can have that ability. We
never said that you can't repeat a message ID, only that you can't
repeat message ID in two *different* messages... or am I missing
something here?

/Ignacio

-- 
Ignacio Más Ivars
Service enablers and protocols, Ericsson Research (EAB/TBG/B)
Ericsson AB                     Phone: +46 8 4045580
Torshamsgatan 23                Fax:   +46 8 7575720
SE-164 80 Stockholm, Sweden     mailto: [email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 17 May 2005 07:47:38 -0500

To summarize then, you are saying that Message ID should be unique,  
but if we resend the _same_ message we still use the _same_ message  
ID. Is this correct?

If so, then I think this is a good idea.

I think I got confused by previous statements about a different  
_version_ of the message getting a new ID. Or maybe I just can't read.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2005 09:59:09 -0400

Ben Campbell wrote:
> To summarize then, you are saying that Message ID should be unique,  but 
> if we resend the _same_ message we still use the _same_ message  ID. Is 
> this correct?

Yes, yes, yes - this is how it must be!

If I type "Are you there" into my client, then it needs to assign a 
message ID to that and then try to send it. If there is some problem 
with the stream, then it can reinvite to reestablish the stream and then 
send the same message with the same message ID.

If I type "Are you there" *again*, then that needs to be assigned a 
*different" message ID.

I don't know how much of this we must say, but we must be clear.

	Paul