RE: message-sessions-10 WGLC: unique message ID and fail ed connections?

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: simple-bounces <at> ietf.org 
> [mailto:simple-bounces <at> ietf.org] 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
> Simple <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>