Subject: Re: [Sipping] [BLISS] New draft submitted: draft-loreto-sipping-context-id-requirements-00

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 02 Jul 2008 14:11:30 +0300

Hi Dean,

I do not think there was ever a 01 version of this draft. Everything I 
could find with that name was the tombstone for the 00 draft.

http://www.ietf.org/proceedings/03jul/I-D/draft-willis-sip-cookies-01.txt

Cheers,

Gonzalo

Dean Willis wrote:
> On Jun 16, 2008, at 10:36 AM, Paul Kyzivat wrote:
> 
>> I seem to recall a proposal similar to this quite some time ago. Am I
>> only imagining that?
> 
> 
> Maybe:
> 
> http://www.softarmor.com/wgdb/docs/draft-willis-sip-cookies-00.txt
> 
> There was a -01 of this draft, but I seem to have misplaced it.
> 
> --
> Dean
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 10 Jul 2008 16:39:23 +0300

Hi Dale,

thanks for the comments and sorry to be late in the reply
my answers in line

/Sal

[email-masked] wrote:
>    From: Paul Kyzivat <[email-masked]>
>
>    > 3.1.  Enhance messaging conversation
>    > 
>    >       Alice and Bob are two participants in a communication space
>    >       exchanging SIP MESSAGE methods sent outside a SIP dialog[RFC3428]:
>    >       The application shows the text sent and received on the screen.
>    > 
>    >       Alice later wants to add voice to the same application.
>
>    There was an extended battle about message sessions long ago. It was 
>    concluded that MESSAGE was not intended for message sessions, and MSRP 
>    was devised as an alternative for that purpose.
>
> Speaking as someone who once contemplated a dialog in which multiple
> MESSAGE requests were exchanged, but who was convinced of the error of
> his ways:
>
>    This use case starts out with the assumption that there is a message 
>    session using MESSAGE, and introducing the context-id to this will 
>    formalize it and give the session an identifier. This is a bad thing.
>
> This use case is even higher-overhead than a dialog containing
> multiple MESSAGE requests, in that it envisions that each MESSAGE
> request is sent out-of-dialog, and thus goes through the full route
> resolution process.  If it is a bad thing to use Call-Id to correlate
> a series of MESSAGEs, it is a worse thing to use another identifier.
>   
[Sal] The Context ID usage in a MESSAGE request is not thought to tie 
two or more MESSAGEs together
in a virtual session.
The idea is to give the possibility to use the Context ID for Historical 
Context.
In this way I can send a Message and after a while start an MSRP session 
that is historically related to that MESSAGE.

[Sal] As I have answered to the Paul first comment:

    the use case I tried to describe was not based on a message session 
    using MESSAGE,
    but in one or more MESSAGEs *sent outside a session* and then link them 
    to an MSRP session.
    Something like
    Alice sends a MESSAGE to Bob
    Bob answers immediately with another MESSAGE
    Alice then thinks that is better continue the discussion establishing a 
    session, so she starts an MSRP session, but she want in some way signal 
    that the *chat* she want start is linked to the previous MESSAGE

>    > 3.2.  Including an external UA in a conversation
>    > 
>    >       Alice establishes a voice session with Bob.
>    >       Alice wants to add video to the session using her SIP-enabled
>    >       camera.
>    > 
>    >       Alice sends a REFER to her camera, which has a SIP user agent on
>    >       it, so that her camera sends an INVITE request to Bob in order to
>    >       establish a video stream.
>    > 
>    >       Alice wants Bob to treat the video stream from her camera and the
>    >       voice stream from her voice-only user agent as part of the same
>    >       communication space.  That is, Alice wants Bob to treat both
>    >       streams as if both had been established using a single SIP dialog.
>
>    I recognize this use case from somewhere. I could swear it has been 
>    discussed before, though perhaps only in email rather than in a draft.
>
>    The Join header works perfectly for this use case - it does *exactly* 
>    the right thing. Adding a new mechanism to do this differently is IMO a 
>    mistake.
>
> Unfortunately, Join doesn't do quite the right thing, as Join presumes
> that the Join recipient will function as a conference mixer.
>   
[Sal] yes, I remember that during the discussion of my previous proposal

http://www.sloreto.com/drafts/draft-loreto-sipping-dialog-correlation-01.txt

that Join header does not work in this scenario, as "the Join implicitly 
presumes that the Join recipient
will function as a conference mixer."

>    This seems to imply a different notion of session than the earlier 
>    cases, and than anything I have seen mentioned with sip. This is a 
>    memory of *past* sessions after they have completed. In this particular 
>    use case it also implies a class of data that is expected to be retained 
>    for such a session - a log of the conversation held during that session.
>
> The difficulty with this new concept is that it is not definitive as
> to the semantics of the identifier.  The identifier says that the two
> dialogs are related, somehow, but it doesn't specify *how* they are
> related.  This is fine for a diagnostic tool, or for data that will be
> heavily processed by a human before being acted on, but is treacherous
> for a protocol.  (Witness the "five uses of REFER" problem, where the
> recipient of a REFER has to distinguish a number of different contexts
> before deciding how to act on the REFER.)
>   
[Sal] well, here I do not understand how you can say that the semantic 
is not definitive.
when haven't specified yet any syntactic or semantic for this mechanism.

> Dale

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 13 Jul 2008 13:33:33 +0300

Hi,

let me try to recap the idea of the Contex-ID and what  it  should be 
used for.

The Context-ID is thought to provide a sort of preservation of state 
across  the sessions and
across the duration of a call. And of course it should be an optional 
capability.

In the draft I have drawn some possible use cases

1) Enhance messaging conversation

I am aware of the fact that there was an extended battle about message 
sessions long ago and it was  concluded that MESSAGE was not intended 
for message sessions,
and MSRP  was devised as an alternative for that purpose.

In fact the Context ID usage in a MESSAGE request is not thought to tie 

2) Including an external UA in a conversation

I remember that during the discussion of my previous proposal
http://www.sloreto.com/drafts/draft-loreto-sipping-dialog-correlation-01.txt 

a lot of people agreed on the fact that Join header does not work and 
should not be used in a similar scenario,
as "the Join implicitly presumes that the Join recipient will function 
as a conference mixer." And overloading the
meaning of Join header could be difficult.

3) Historical Session concept

I want to thank Dean Willy to have pointed me to the SIP Cookies draft 
(btw: I have only founded and read the 00 version)
however the idea in the Context-ID draft is quite different, in fact the 
idea is not to insert the HTTP Cookie functionality in SIP
but only to provide an Historical Session concept: a memory of past 
sessions after they have completed. Moreover it should a pure
end to end functionality.

As Paul has rightly pointed out some kind of historical logs are already 
deployed for IM, and all are tied to an AOR.
However I am not sure that tie them to the perceived AOR is a good idea, 
maybe it could be better tie to the GRUU;
and I am also not sure that the callid usage would be enough for 
disambiguation.
Moreover the current functionality "works" only for IM and not for all 
the possible multimedia calls or Application Interactions using SIP.
In the current functionality it is not possible define what the Lifetime 
is expected to be, neither how the data it should be access.

About the data that is expected to be retained, I don't think we have to 
over-specified them in fact they will be different in different Call 
Context:
for example in an IM call what is important is to store the historical 
logs (the messages); but if in Application Interaction using SIP as 
described in the
Tote draft, maybe I need to retain specific data related to the 
application I am interacting with.

regards
Sal