Subject: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 22 Oct 2012 21:35:27 -0400

Folks,

We've posted a revised version of the proposed solution for the end-to-end
session identifier.

This draft has been substantially revised and now includes a number of
sample call flows.

As we discussed during the interim calls, this version changes the syntax in
an effort to try to make interworking with the current "Session-ID" header
workable.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Monday, October 22, 2012 7:34 PM
> To: [email-masked]
> Subject: I-D Action: draft-jones-insipid-session-id-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title           : End-to-End Session Identification in IP-Based
> Multimedia Communication Networks
> 	Author(s)       : Paul E. Jones
>                           Chris Pearce
>                           James Polk
>                           Gonzalo Salgueiro
> 	Filename        : draft-jones-insipid-session-id-01.txt
> 	Pages           : 17
> 	Date            : 2012-10-22
> 
> Abstract:
>    This document describes an end-to-end Session Identifier for use in
>    IP-based Multimedia Communication systems that enables endpoints,
>    intermediate devices, and management systems to identify a session
>    end-to-end, associate multiple endpoints with a given multipoint
>    conference, track communication sessions when they are redirected,
>    and associate one or more media flows with a given communication
>    session.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-jones-insipid-session-id
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-jones-insipid-session-id-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Oct 2012 12:53:08 +0000

Hi,

One comment on the ABNF.

First, I've had off-line discussions with the authors, where we in order to be backward compatible with draft-kaplan agreed on the following things:

1. The ABNF will be backward compatible
2. Entities must be prepared to receive a value that does not contain a value inserted by the remote peer

...so my comment is based on those assumptions.

Q_ABNF-1:	In order to be backward compatible, rcvr-uuid needs to be optional. I would suggest the following:

	Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI generic-param)

	sess-id    =  32(DIGIT / %x61-66)  ;32 chars of [0-9a-f]

	rcvr-uuid  =  "rcvr" EQUAL 32(DIGIT / %x61-66)

In fact, I am not aware of any current implementations that use the generic-param for anything, so we could even do the following:

	Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI generic-param)]

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Oct 2012 12:08:55 -0400

> 	Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI generic-param)]

IMO it is bad practice to require a specific ordering among params. So I 
would prefer:

	Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param]

	sess-id-param = rcvr-uuid / generic-param

	rcvr-uuid  =  "rcvr" EQUAL sess-id

Another thing: the above only permits lower case hex. For consistency 
with common usage both lower and upper case should be permitted. This 
can be done by:

	sess-id = 32 HEXDIG (from 5234, used in 3261)

And is there any reason to require leading zeros in the sess-id? If not, 
that can be specified via

	sess-id = 1*32 HEXDIG
or maybe
	sess-id = 1*16 (HEXDIG HEXDIG)

Or does backward compatibility require restricting to lower case and 
exactly 32 digits?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Oct 2012 16:25:28 +0000

Hi, 

>> 1. The ABNF will be backward compatible 2. Entities must be prepared 
>> to receive a value that does not contain a value inserted by the 
>> remote peer
>>
> IMO it is bad practice to require a specific ordering among params. So I would prefer:
>

...or, we could simply remove generic-param. As I said earlier, I am not aware of any existing deployments using it for anything.

> Another thing: the above only permits lower case hex. For consistency with common usage both lower and upper case should be permitted. This can be done by:
>
> And is there any reason to require leading zeros in the sess-id? If not, that can be specified via
>
>	sess-id = 1*32 HEXDIG
> or maybe
> Or does backward compatibility require restricting to lower case and exactly 32 digits?

Lower case and exactly 32 digits.

 	"Session-ID           =  "Session-ID" HCOLON sess-id 
                           *( SEMI generic-param ) 
   	sess-id              =  32(DIGIT / %x61-66)  ;32 chars of [0-9a-f] 
    
   	NOTE: The sess-id value is technically case-INSENSITIVE, but note 
   	that only lower-case characters are allowed."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Oct 2012 13:03:46 -0400

> ...or, we could simply remove generic-param. As I said earlier, I am not aware of any existing deployments using it for anything.

IMO the reason for it is not because existing deployments use it, but 
rather is "future proofing" - providing for future extensions.

>     	that only lower-case characters are allowed."

I have no idea what that note means.

I don't like this, but could live with it if it is really needed for 
backward compatibility.

	Thanks,
	Paul

---

From: James Polk <[email-masked]>
Date: Thu, 25 Oct 2012 19:45:29 -0500

Here is a list of the changes between the -00 and -01 versions of 
draft-jones-insipid-session-id, for those that have not read this draft yet:

- Rewrote a lot of the text (see the diff URL listed below as proof), 
but did not change the overall layout of the sections much, other 
than adding the new sections mentioned below.

- clarified how the Session-ID is constructed exactly.

- changed the ABNF (thanks to Paul K for the help) but did not alter 
the basic concept of two UUIDs (sender and receiver each insert their 
UUID) to construct the Session-ID.

- Added a new section on the 6 different call flow scenarios this 
document solves for, covering

   - Basic Session-ID Construction with 2 UUIDs
   - Basic Call Transfer using REFER
   - Basic Call Transfer using reINVITE
   - Single Focus Conferencing
   - Single Focus Conferencing using WebEx
   - Basic 3PCC for two UAs

each call flow shows the values of the UUIDs that make up the 
Session-ID on a per message basis (something that Robert asked for in 
the Vancouver meeting).

- decided against showing how to do a multiple focus conference call 
in this version. That call flow could be added in the next version.

- Added a new section to includeda way to be mostly backwards 
compatible with the "old way" of doing a session-id. It's not 
perfect, but attempts to address each of the 4 scenarios:

   - old calling old (should work fine)
   - new calling new (should work fine)
   - old calling new (interesting issues)
   - new calling old (more interesting issues)

Comments and questions are encouraged

James/Paul

At 08:35 PM 10/22/2012, Paul E. Jones wrote:
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 01:59:15 -0400

Christer,

I'm not sure what #2 is below.  We do want to try to achieve compatibility
in terms of syntax, thus the changes in syntax seen in this document.  I
might be in agreement with #2 if I understood it :)  If you mean that Alice
might send 'A' and then Alice might receive 'A' back, that is certainly an
backward-compatibility case we want to allow.  Was that the meaning?  We do
want to require the present solution to not do that, though, as that
effectively breaks the end-to-end identification in certain cases.

Also, we want to require the present solution to always include "rcvr-uuid".
We'll have to state that in prose since the ABNF cannot be flexible enough
to accommodate that.  And, we must allow for it to be absent on the initial
INVITE, too, since Alice would not have a value to include... unless we make
it all zeros or something.

Here's the modified ABNF (just the firt production):

    Session-ID = "Session-ID" HCOLON sess-id
                 *1( SEMI rcvr-uuid )
                 *( SEMI generic-param )

Paul

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, October 25, 2012 8:53 AM
> To: 'Paul E. Jones'; [email-masked]
> Subject: RE: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-
> 01.txt - ABNF
> 
> 
> Hi,
> 
> One comment on the ABNF.
> 
> First, I've had off-line discussions with the authors, where we in order
> to be backward compatible with draft-kaplan agreed on the following
> things:
> 
> In fact, I am not aware of any current implementations that use the
> generic-param for anything, so we could even do the following:
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 02:12:13 -0400

Paul,

OK... I now have this:

I could change the hex digits, but that would not be compatible with the
Kaplan draft.

Paul

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, October 25, 2012 12:09 PM
> To: [email-masked]
> Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-
> 01.txt - ABNF
> 
> > First, I've had off-line discussions with the authors, where we in
> order to be backward compatible with draft-kaplan agreed on the
> following things:
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 02:26:11 -0400

Christer,

> ...or, we could simply remove generic-param. As I said earlier, I am not
> aware of any existing deployments using it for anything.

Sorry, I missed that in the first message.  Are you sure it is safe?  If so,
I'm happy to remove it.

>    	that only lower-case characters are allowed."

This wording seems odd. I think we just have to say concretely that the
sess-id and rcvr-uuid is case sensitive, if we say anything.  Do we need to
say something?

Paul

---

From: <[email-masked]>
Date: Fri, 26 Oct 2012 10:51:52 +0200

Hi Paul,
looks for me OK and is inline with that what we have currently implemented in our network.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Paul E. Jones
> Gesendet: Freitag, 26. Oktober 2012 08:12
> An: 'Paul Kyzivat'; [email-masked]
> Betreff: Re: [Insipid] FW: I-D Action:
> draft-jones-insipid-session-id-01.txt - ABNF
>
> Paul,
>
> OK... I now have this:
>
> I could change the hex digits, but that would not be
> compatible with the Kaplan draft.
>
> Paul
>
> > > Q_ABNF-1: In order to be backward compatible, rcvr-uuid
> needs to be
> > optional. I would suggest the following:
> > >
> > IMO it is bad practice to require a specific ordering among
> params. So
> > I would prefer:
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2012 13:20:24 -0400

>     rcvr-uuid  =  "rcvr" EQUAL 32(DIGIT / %x61-66)

OK, now I'm moving to the esthetics of ABNF writing. None of the 
following changes what may be validly written.

1) the name of the header field is "Session-ID", so I would expect that 
a non-terminal in the syntax called <sess-id> would describe be the 
fundamental thing. But in the above it isn't. It is *half* of the ID of 
a communication session. (Except in the compatibility cases.)

2) I really dislike when specialized piece of syntax is repeated in two 
places rather than being defined once and referenced twice. Doing so 
suggests that any resemblance between the two is incidental rather than 
fundamental. In this case the syntax for <sess-id> and the value part of 
<rcvr-uuid> are fundamentally the same.

In my prior proposals I addressed (2), but not (1). Here is a proposal 
that addresses them both:

     Session-ID    = "Session-ID" HCOLON endpt-id *[SEMI sess-id-param]

     endpt-id      =  32(DIGIT / %x61-66)  ;32 chars of [0-9a-f]

     sess-id-param = rcvr-id / generic-param

     rcvr-id       =  "rcvr" EQUAL endpt-id

The above does not explicitly state that <rcvr-id> can appear at most 
once. That is a general rule for header field parameters. It could be 
specified in text for emphasis.

	Thanks,
	Paul K

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 16:34:18 -0400

Guys,

Coming back to the syntax.  I think the below syntax (including the
generic-param) is best.  We don't have a defined use for generic-param, but
we might find a use for it one day.  We should not lock ourselves out of
extensibility.

So, I have:

   Session-ID    = "Session-ID" HCOLON sess-id [SEMI sess-id-param]

Paul

> Behalf Of Paul E. Jones
> Sent: Friday, October 26, 2012 2:12 AM
> To: 'Paul Kyzivat'; [email-masked]
> > > Q_ABNF-1:	In order to be backward compatible, rcvr-uuid needs to
> be

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 16:58:00 -0400

Oops... not right.  This allows for only one optional parameter.  Also,
there was a desire to allow any order and we need to ensure 

How about this:

Session-ID     = "Session-ID" HCOLON sess-id [sess-id-params]
sess-id-params = *(SEMI generic-param) SEMI rcvr-uuid
                 *(SEMI generic-param) 
sess-id        = 32(DIGIT / %x61-66)  ;32 chars of [0-9a-f]
rcvr-uuid      = "rcvr" EQUAL 32(DIGIT / %x61-66)

We'll add prose that says:
The Session-ID header MUST NOT have more than one "rcvr" parameter.

Paul

> Sent: Friday, October 26, 2012 4:34 PM
> generic-param) is best.  We don't have a defined use for generic-param,
> but we might find a use for it one day.  We should not lock ourselves
> out of extensibility.
> 
> So, I have:
> 
> > I could change the hex digits, but that would not be compatible with
> > the Kaplan draft.
> >
> > Paul
> >
> > > Subject: Re: [Insipid] FW: I-D Action:
> > > draft-jones-insipid-session-id- 01.txt - ABNF
> > >
> > > > 1. The ABNF will be backward compatible 2. Entities must be
> > > > prepared to receive a value that does not contain a value inserted
> > > > by the remote peer
> > > >
> > > > 	Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid]
> *(SEMI
> > > > generic-param)
> > > >
> > > > 	Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid
> *(SEMI
> > > > generic-param)]
> > >
> > > Another thing: the above only permits lower case hex. For
> > > consistency with common usage both lower and upper case should be
> > > permitted. This can be done by:
> > >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2012 17:38:40 -0400

Here are some things I found while reviewing the latest version:

Section 4:

    The Session Identifier is comprised of two RFC 4122 defined UUIDs
    [4], with each UUID created by the endpoints participating in the
    session.

The above isn't correct when the id is inserted by an intermediary. I 
think it might be more correct to say:

    The Session Identifier is comprised of two RFC 4122 defined UUIDs
    [4], with each UUID representing one of the endpoints participating
    in the session.

Section 5:

    The "sess-id" value represents the UUID value of the UA transmitting
    the message.  If the UA transmitting the message previously received
    a UUID value from its peer endpoint, it MUST include that UUID as the
    "rcvr" parameter.

I gather this means that the sess-id and rcvr-uuid need to be swapped in 
the response to a request. That seems a little odd. It runs contrary to 
how most things work in responses. But apparently it is fundamental to 
the usage rules.

Section 6:

    ... Session-ID header-values MUST NOT be present in any other
    SIP header than the Session-ID header.

Why is it important to mandate this?

    UAs MUST ignore the value in the "rcvr" parameter in any message it
    receives, as this value may be incorrect due to service interactions
    as shown in examples later in this document.

If it is entirely ignored, then there is no point in sending it. For 
instance, wouldn't you want to include it when logging? (Even if the log 
also includes the local UUID.) Presumably an inconsistency between these 
values may itself be interesting and worth noting. But it can't be noted 
if the value in the message is ignored.

I'm guessing that you mean that the recipient should not be concerned if 
the value received is inconsistent with the value it is holding in local 
state, and should not replace its local value with the one received.

Section 7:

    If performing interworking between SIP and another session protocol,
    an intermediary MUST convert the Session-ID header as necessary so
    that it properly places the correct UUID value of the message
    transmitter and assumed recipient. This is a protocol gateway or
    interworking function.

The above is only possible if the other protocol has a comparable 
mechanism in which the value can be represented. Any normative behavior 
should be specified as part of the interworking specification, not here.

Section 8:

    Note, however, that this assumption of being part of the same
    conference is not always true.  For example, in a SIP forking
    scenario, there might also be what appears to be multiple sessions
    with a shared UUID value.  This is actually desirable.  What is
    desired is to allow for the association of related sessions.  Whether
    sessions are related because of forking or because endpoints are
    communicating as a part of a conference does not matter.  They are
    nonetheless related.

So, when two sessions have half of a session id in common they are 
"related", somehow. Then I might be encouraged to reuse my half when 
initiating distinct sessions that I want to be treated as "related". For 
instance, if I send a sequence of MESSAGE requests to the same 
recipient, and I think they are related, maybe I'll be inclined to use 
the same uuid in them?

Section 10.2:

The re-INVITE usage in this example seems entirely spurious. The 
sequence starting with the REFER stands on its own. The bullet:

      o UA-Bob reINVITEs Alice to call Carol, using a REFER transaction,
        as described in [RFC3515]. UA-Alice is initially put on hold,
        then told in the REFER who to contact with a new INVITE, in this
        case UA-Carol.

makes no sense to me.

Section 10.3:

This also makes no sense to me as a stand-alone example. How is it that 
Bob decides to do a re-INVITE if he wants to transfer to Bob? How is it 
that the B2BUA knows it should call Carol? And the BYE from the B2BUA to 
Alice means that the call to Carol will no longer be functional.

It is possible to construct a hybrid of what is shown in 10.2 and 10.3, 
where the REFER is terminated by the B2BUA, and not propagated to Alice. 
Instead, the B2BUA uses a re-INVITE to Alice to update her with the 
session info to Carol.

Secton 10.4:

This all seems reasonable. But it assumes that correlating that all the 
sessions are part of the same conference is more important than 
correlating the initial callin to the conference server with the portion 
after logging in to the particular conference. The conference focus is 
in control of this, based on whether it switches to a common uuid or 
not. That is fine if it is the appropriate entity to make that decision. 
Not so good for somebody trying to trace problems that require 
continuity for the entire call of one participant.

Section 10.6:

Shouldn't the ACK from the B2BUA to Alice have {B,A} ???

	Thanks,
	Paul

On 10/25/12 8:45 PM, James Polk wrote:
> but did not change the overall layout of the sections much, other than
> adding the new sections mentioned below.
>
> - changed the ABNF (thanks to Paul K for the help) but did not alter the
> basic concept of two UUIDs (sender and receiver each insert their UUID)
> to construct the Session-ID.
>
> each call flow shows the values of the UUIDs that make up the Session-ID
> on a per message basis (something that Robert asked for in the Vancouver
> meeting).
>
> - decided against showing how to do a multiple focus conference call in
> this version. That call flow could be added in the next version.
>
> - Added a new section to includeda way to be mostly backwards compatible
> with the "old way" of doing a session-id. It's not perfect, but attempts
> to address each of the 4 scenarios:
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 17:58:32 -0400

Paul,

Merging what you propose and my changes from an hour or so earlier, how is
this:

Session-ID     = "Session-ID" HCOLON endpt-id [sess-id-params]

rcvr-uuid      = "rcvr" EQUAL endpt-id

Paul

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, October 26, 2012 1:20 PM
> To: Paul E. Jones
> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2012 18:25:21 -0400

I am ok with what you propose. Others may call it overkill.
There is an understanding (I'm not certain if it is written down) that a 
single header parameter can be used at most once within a given header 
field. And if that isn't enough, it can be stated in text.

But I have no trouble with doing it in the syntax as you show. It is 
easy to do in syntax as long as there is only a single parameter. (It 
gets messier when there are several parameters and each can appear at 
most once. Then people must give up and use text.)

Otherwise, we may want to tweak the syntax more in order to give names 
that work well with the descriptions in the text. For instance:

Session-ID      = "Session-ID" HCOLON local-uuid [sess-id-params]

local-uuid      = sess-uuid

sess-uuid       = 32(DIGIT / %x61-66)  ;32 chars of [0-9a-f]

sess-id-params  = *(SEMI generic-param) SEMI remote-id-param
                   *(SEMI generic-param)

remote-id-param = "remote" EQUAL remote-uuid

remote-uuid     = sess-uuid

This is using the same local/remote terminology that 3261 uses for 
dialog state.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 18:42:27 -0400

Paul,

>     [4], with each UUID representing one of the endpoints participating

Sounds good to me.  I'll make the change.
 
> how most things work in responses. But apparently it is fundamental to

Your interpretation is correct.  The sender of the message formulates the
Session-ID header as specified.  However, how a header is set does vary.
Some remain the same in an exchange, like CSeq.  Some get modified, like the
"To" header with a tag added.  Others are set by the sender of the message,
such as the Content-Length header.  Session-ID falls into the latter group.
 
> Why is it important to mandate this?

Good question.  I'm sure there was a rationale, but it is not apparent now.
I'll remove it.
 
> if the value in the message is ignored.

We do want this value to be used by intermediaries, so they should not
ignore it.  The reason I inserted this wording is that I do not want a UA to
echo the value it receives back to the sender of that message in any
subsequent message.

Do you have a suggestion for wording that?

> state, and should not replace its local value with the one received.

Right.  If Carol (UUID=C) receives an INVITE that has "Session-ID:
A;rcvr=B", we do not want Carol to panic because C is not there, but we also
do not want Carol to echo back "Session-ID: B; rcvr=A".  Rather, we want
Carol to form a reply like "Session-ID: C; rcvr=A".
 
> should be specified as part of the interworking specification, not here.

Is there more to say re: interworking than this?  I think there is one more
sentence we should add:

     If not suitable value exists, the intermediary may allocate a
     UUID value to represent the endpoint for which it has no other
     value.

Sound reasonable?  If we move this, move it to where?  Introduce an
interworking section only with this paragraph?
 
> instance, if I send a sequence of MESSAGE requests to the same recipient,
> and I think they are related, maybe I'll be inclined to use the same
> uuid in them?

That we do not want.  Except in the case of a conference server, we want
each UA to allocate a unique UUID for each session.

Section 10.2 onward...  Let me allow James to respond on the call flows, as
he provided that text. I don't want to put words in his mouth :-)

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 19:09:36 -0400

OK... looks good.  Taking that and doing more tweaks:

session-id    = "Session-ID" HCOLON local-uuid
                *(SEMI sess-id-param)

local-uuid    = sess-uuid

remote-uuid   = sess-uuid

sess-id-param = remote-param / generic-param

remote-param  = "remote" EQUAL remote-uuid

How does that look?  You're right about the complexity of the
sess-id-params.  Trying to use syntax to prevent multiple "remote"
parameters will not work, anyway, since there is nothing in syntax to
prevent some "other" generic-param from having the value "remote".  So, we
just have to insert a normative statement like this:

   The Session-ID header MUST NOT have more than one "remote" parameter.

Look good?  I hope I didn't introduce an error.

Paul

> Sent: Friday, October 26, 2012 6:25 PM
> To: Paul E. Jones
> Cc: [email-masked]
> >> 1) the name of the header field is "Session-ID", so I would expect
> >> that a non-terminal in the syntax called <sess-id> would describe be
> >> the fundamental thing. But in the above it isn't. It is *half* of the
> >> ID of a communication session. (Except in the compatibility cases.)
> >>
> >> 2) I really dislike when specialized piece of syntax is repeated in
> >> two places rather than being defined once and referenced twice. Doing
> >> so suggests that any resemblance between the two is incidental rather
> >> than fundamental. In this case the syntax for <sess-id> and the value
> >> part of <rcvr-uuid> are fundamentally the same.
> >>
> >> In my prior proposals I addressed (2), but not (1). Here is a
> >> proposal that addresses them both:
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2012 23:42:27 -0400

This all seems fine to me!

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Oct 2012 13:39:19 -0400

Trimming out the stuff I have no further comments on:

> Do you have a suggestion for wording that?

I think you already have normative language for what values should be 
used. So the normative language here is redundant. I would recommend 
replacing this with a Note giving warnings to implementers that 
unexpected values might be seen.

> interworking section only with this paragraph?

ISTM that interworking can't be addressed in general. It must be 
addressed case by case. If you want to discuss interworking with H.323, 
then I think it would best be handled as a separate draft. If not that, 
then at least a separate section in this draft focused explicitly on 
that. (I think a separate draft because the community interested in it 
is different. Many people interested in insipid won't be able to comment 
meaningfully on this part.)

> each UA to allocate a unique UUID for each session.

This is why it's important to have a clear and explicit definition of 
those cases there a common id is appropriate and those where it is not. 
I commented on that at length in another message, so probably better to 
discuss in that thread.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 27 Oct 2012 21:48:51 +0300

Hi there

I have read the 01 and have the following questions

in Section 7. Processing by Intermediaries

I don't find anything that explain when an intermediary is "allowed" to 
inject an identifier into the session signaling
so to meet REQ7.

    REQ7: It must be possible to identity SIP traffic with an end-to-end
    session identifier from and to end devices that do not support this
    new identifier, such as by allowing an intermediary to inject an
    identifier into the session signaling.

Moreover Section 7 states

    Intermediaries MUST NOT alter the UUID values found in the Session-ID
    header, except as described in this section.

and there is nothing the the section describing it.
Do I have overlooked something ?

I am a little puzzled from the aim of Section 9.
There is nothing in that section that is necessary to fulfill the Req9c

    REQ9c: The identifier should be constructed in such a way as to make
    it suitable for transmission in SIP and RTCP [3  <http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-02#ref-3>].

Example 10.5 is a little confused, as there Alice,Bob and Carol are not 
just representation
of their respective SIP UA, but more of their device that include both 
an HTTP client + SIP UA

In general I don't find any extra value in 10.5 comparing it to the 
example in 10.4
unless there is something protocol interworking between HTTP and SIP 
that you want point out

Cheers
/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

On 10/26/12 3:45 AM, James Polk wrote:
> compatible with the "old way" of doing a session-id. It's not perfect, 
> but attempts to address each of the 4 scenarios:
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 27 Oct 2012 17:49:33 -0400

> >> instance, wouldn't you want to include it when logging? (Even if the
> >> log also includes the local UUID.) Presumably an inconsistency
> >> between these values may itself be interesting and worth noting. But
> >> it can't be noted if the value in the message is ignored.
> >
> > ignore it.  The reason I inserted this wording is that I do not want a
> > UA to echo the value it receives back to the sender of that message in
> > any subsequent message.
> >

OK, I'll strike that.  How about this note:

    It should be noted that messages received by a UA might contain
    a "remote" parameter that does match the UAs UUID.  This might
    happen as a result of service interactions by intermediaries and
    MUST NOT be regarded as an error.

> >> mechanism in which the value can be represented. Any normative
> >> behavior should be specified as part of the interworking
> specification, not here.
> >
> > Is there more to say re: interworking than this?  I think there is one
> > more sentence we should add:
> >

OK, I'll delete it entirely.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 27 Oct 2012 18:08:33 -0400

On Sat, 27 Oct 2012 21:48:51 +0300, Salvatore Loreto wrote:
>  I don't find anything that explain when an intermediary is "allowed"
> to inject an identifier into the session signaling
>  so to meet REQ7.
> 

How about this sentence:
    If a SIP message having no Session-ID header is received by
    an intermediary, the intermediary MAY assign a "local-uuid"
    value to represent the sending endpoint and insert that value
    into all signaling messages on behalf of the sending endpoint.

>  Do I have overlooked something ?

Intermediaries might change the value to facilitate call transfer, call
joins,
or insert values on behalf of endpoints.  We may have more examples where
intermediaries change values.  We do need language to restrict changes,
otherwise, devices might change things in any way they wish.

>  it suitable for transmission in SIP and RTCP [3 [18]].

Yeah, this is left over from before.  There is no normative language at
all. We had that there to indicate in what other ways this
value might be used, if we choose to define it. If we remove this
section, it would not change the solution.

I'll let James address the comments on call flows.

Paul

>  Example 10.5 is a little confused, as there Alice,Bob and Carol are
> not just representation
>  of their respective SIP UA, but more of their device that include
> both an HTTP client + SIP UA
> 
> www.sloreto.com [19]

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 28 Oct 2012 08:47:28 +0200

>      into all signaling messages on behalf of the sending endpoint.

we should also say what an Intermediary should do if it sees a SIP request
with a Session-ID header but the answer does not contain it anymore or
the answer contain only a copy of the Session-ID present in the request:
i.e. what happen if the peer does not support the Session-ID header
my guess is that it can
- remove the Session-ID header
or
- just copy back it as it has been received.

> otherwise, devices might change things in any way they wish.
my point was about the fact that I see as an alteration of the UUID also 
the possibility
for an intermediary to insert it if it was not present in the original 
request or response.

So I would like to have this point clarified in the draft.

> section, it would not change the solution.

I agree, and I would suggest to remove it.

thanks for your answers

cheers
Sal

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 28 Oct 2012 14:25:17 -0400

Sal,

That gets into territory of "how do you deal with non-compliant endpoints".
Either the Session-ID header is there or not.  If it's there, I don't think
the intermediary should take steps to ensure that it's fully-compliant with
the spec.  If it's missing entirely, that's different.  The intermediary can
act on behalf of the endpoint that does not support the header.

Perhaps I'm missing your point, but if we need language related to
interworking with Kaplan entities, we should find proper wording in Section
11.  Right now, we're not 100% sure how those entities behave, so some work
is probably needed in Section 11.

Paul

> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Sunday, October 28, 2012 2:47 AM
> To: Paul E. Jones
> Cc: [email-masked]
> Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-
> session-id
> 
> we should also say what an Intermediary should do if it sees a SIP
> request with a Session-ID header but the answer does not contain it
> anymore or the answer contain only a copy of the Session-ID present in
> the request:
> i.e. what happen if the peer does not support the Session-ID header my
> guess is that it can
> > Intermediaries might change the value to facilitate call transfer,
> > call joins, or insert values on behalf of endpoints.  We may have more
> > examples where intermediaries change values.  We do need language to
> > restrict changes, otherwise, devices might change things in any way
> > they wish.
> the possibility for an intermediary to insert it if it was not present
> in the original request or response.
> 
> > Yeah, this is left over from before.  There is no normative language
> > at all. We had that there to indicate in what other ways this value
> > might be used, if we choose to define it. If we remove this section,
> > it would not change the solution.
> 
> >>   unless there is something protocol interworking between HTTP and
> >> SIP that you want point out
> >>
> >>   Cheers
> >>   /Sal
> >>
> >> --
> >> Salvatore Loreto, PhD
> >> www.sloreto.com [19]
>

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 28 Oct 2012 21:10:14 +0200

> act on behalf of the endpoint that does not support the header.
what I am trying to understand is what will do (or is allowed to do) an 
intermediary in the case
it seats in between a Session-ID compliant end point that is trying to 
contact a non compliant end-point.

what you explain in the previous mail was the opposite scenario
where an intermediary seats in between a
non Session-ID compliant end point that is trying to contact a compliant 
end point.

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 28 Oct 2012 16:33:37 -0400

Sal,

Current text says:

    If a SIP message having no Session-ID header is received by an
    intermediary, the intermediary MAY assign a "local-uuid" value
    to represent the sending endpoint and insert that value into all
    signaling messages on behalf of the sending endpoint.

So, if Alice calls Bob and Bob does not insert a Session-ID, you want to
know what happens.  The above text would still apply, but perhaps it's not
clear.  The intermediary may assign the "local-uuid" value that represents
Bob.  What is missing is an explicit statement that says that the
intermediary should insert the appropriate "remote" value for Alice.
Perhaps we add this?

    If the intermediary is aware of a "remote" value that identifies
    the receiving UA, it MUST insert that value if also inserting the
    "local-uuid" value.

Feel free to suggest other wording.

Paul

> Sent: Sunday, October 28, 2012 3:10 PM
> To: Paul E. Jones
> Cc: [email-masked]
> > Either the Session-ID header is there or not.  If it's there, I don't
> > think the intermediary should take steps to ensure that it's
> > fully-compliant with the spec.  If it's missing entirely, that's
> > different.  The intermediary can act on behalf of the endpoint that
> does not support the header.
> intermediary in the case it seats in between a Session-ID compliant end
> point that is trying to contact a non compliant end-point.
> 
> what you explain in the previous mail was the opposite scenario where an
> intermediary seats in between a non Session-ID compliant end point that
> is trying to contact a compliant end point.
> 
> /Sal
> 
> --
> Salvatore Loreto, PhD
> www.sloreto.com
> 
> 
> >
> >>>>    REQ7: It must be possible to identity SIP traffic with an end-
> to-
> >> end
> my
> >>>>    Intermediaries MUST NOT alter the UUID values found in the
> Session-
> >> ID
> >>>>    There is nothing in that section that is necessary to fulfill
> the
> >>>> Req9c
> >>>>

---

From: <[email-masked]>
Date: Mon, 29 Oct 2012 15:18:37 +0100

Hi Paul and Paul,
Now my question is:

Is this now backward compatible as we tried to be some mails earlier?

> >>>>>       rcvr-uuid  =  "rcvr" EQUAL 32(DIGIT / %x61-66)

Thank you and Best Regards

Roland

> [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Samstag, 27. Oktober 2012 05:42
> An: Paul E. Jones
> Cc: [email-masked]
> > prevent some "other" generic-param from having the value "remote".
> > So, we just have to insert a normative statement like this:
> >
> >> There is an understanding (I'm not certain if it is written down)
> >> that a single header parameter can be used at most once within a
> >> given header field. And if that isn't enough, it can be
> stated in text.
> >>
> >> Otherwise, we may want to tweak the syntax more in order to give
> >> names that work well with the descriptions in the text.
> For instance:
> >>
> >>> Merging what you propose and my changes from an hour or
> so earlier,
> >>> how is
> >>> this:
> >>>
> >>>> that a non-terminal in the syntax called <sess-id> would
> describe
> >>>> be the fundamental thing. But in the above it isn't. It
> is *half*
> >>>> of the ID of a communication session. (Except in the
> compatibility
> >>>> cases.)
> >>>>
> >>>> two places rather than being defined once and referenced twice.
> >>>> Doing so suggests that any resemblance between the two is
> >>>> incidental rather than fundamental. In this case the syntax for
> >>>> <sess-id> and the value part of <rcvr-uuid> are
> fundamentally the same.
> >>>>
> >>>>        Session-ID    = "Session-ID" HCOLON endpt-id
> *[SEMI sess-id-
> >> param]
> >>>>
> >>>> The above does not explicitly state that <rcvr-id> can appear at
> >>>> most once. That is a general rule for header field
> parameters. It
> >>>> could be specified in text for emphasis.
> >>>>
> >>>>  Thanks,
> >>>>  Paul K
> >>>>
> >>>>> I could change the hex digits, but that would not be compatible
> >>>>> with the Kaplan draft.
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>>> From: [email-masked]
> [mailto:[email-masked]]
> >>>>>> On Behalf Of Paul Kyzivat
> >>>>>>> First, I've had off-line discussions with the
> authors, where we
> >>>>>>> in
> >>>>>>> prepared to receive a value that does not contain a value
> >>>>>>> inserted by the remote peer
> >>>>>>>
> >>>>>>> Q_ABNF-1:     In order to be backward compatible,
> rcvr-uuid needs
> > to
> >>>> be
> >>>>>>> In fact, I am not aware of any current
> implementations that use
> >>>>>>> the
> >>>>>> IMO it is bad practice to require a specific ordering
> among params.
> >>>>>> So I would prefer:
> >>>>>>
> >>>>>> And is there any reason to require leading zeros in
> the sess-id?
> >>>>>> If not, that can be specified via
> >>>>>>
> >>>>>>        sess-id = 1*32 HEXDIG
> >>>>>> or maybe
> >>>>>> Or does backward compatibility require restricting to
> lower case
> >>>>>> and exactly 32 digits?
> >>>>>>
> >>>>>>        Thanks,
> >>>>>>        Paul
> >>>>>>
> >>>>>>
> >>>>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Oct 2012 12:08:22 -0400

I believe the syntax is.  I do not know about semantics.

The syntax would be:

Alice (initial INVITE):
  Session-ID: 438f03a3fd4f420494ed7d38891123ef

Bob (e.g., 200):
  Session-ID: ee270c18dbcd4e11bb14a0bc10005517 ;
              remote=438f03a3fd4f420494ed7d38891123ef

Paul

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 29, 2012 10:19 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: AW: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-
> 01.txt - ABNF
> 
> Hi Paul and Paul,
> Now my question is:
>