Subject: [Insipid] Proposal for Backwards Compatibility Session-ID

From: James Polk <[email-masked]>
Date: Mon, 16 Sep 2013 17:10:20 -0500

INSIPID

I wrote a draft on way around our backwards compatibility issues 
between kaplan implementations and jones/insipid implementations, 
such that jones/insipid implementations advertise their adherence 
with a to-be standards-track RFC from this WG.

There are a couple of choices we as a WG need to make in this 
proposal. Namely, at the bottom of section 3 is an alternative choice 
for all jones implementations to continuously advertise they are 
jones implementations, even when communicating with kaplan 
implementations. The Session-IDs in call flows in section 3.1 and 3.2 
will be affected by this choice.

As of now, I decided not to include this alternative throughout the 
rest of the ID, because I felt like having two ways to accomplish the 
goal of backwards compatibility would be confusing to the WG. ;-)

http://www.ietf.org/internet-drafts/draft-polk-insipid-bkwds-compatibility-proposal-02.txt

I'm already to the -02 rev because I found little mistakes in the -00 
and -01 (which were submitted earlier this afternoon).

Comments are welcome.

The goal of this draft is to come to agreement and interweave that 
agreement in the INSIPID solution draft. Right now, this draft is not 
intended to become an RFC.

James

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Sep 2013 08:15:35 +0000

Hi James,

Based on a first look at the draft (I have not read the transfer sections yet), it looks more or less like my proposal.  But, a few comments:

Q_1: 	I don't think we should mandate the usage of 32 zeros for the "null" value. It will put extra burden on parsers etc. Why not use a single zero, or something similar?

Q_2:	In section 3, where Bob supports [Kaplan], you assume that Bob will not copy the "remote" parameter into the 200 OK response. That is not necessarily true - Bob might very well copy the parameter into the response (but Bob will of course not change the "null" value into something else). So, Alice needs to be prepared for a 200 OK with, or without, the "remote" parameter. But, in both cases it tells Alice that Bob supports [Kaplan].

Q_3:	In section3, related to Q_2, WHATEVER Bob returns in the 200 OK, I think Alice shall use that in future requests/responses within the dialog. So, if there is no "remote" parameter in the 200 OK, Alice shall not add it in future requests/responses within the dialog.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta James Polk
Lähetetty: 17. syyskuuta 2013 1:10
Vastaanottaja: [email-masked]
Aihe: [Insipid] Proposal for Backwards Compatibility Session-ID

INSIPID

I wrote a draft on way around our backwards compatibility issues between kaplan implementations and jones/insipid implementations, such that jones/insipid implementations advertise their adherence with a to-be standards-track RFC from this WG.

There are a couple of choices we as a WG need to make in this proposal. Namely, at the bottom of section 3 is an alternative choice for all jones implementations to continuously advertise they are jones implementations, even when communicating with kaplan implementations. The Session-IDs in call flows in section 3.1 and 3.2 will be affected by this choice.

As of now, I decided not to include this alternative throughout the rest of the ID, because I felt like having two ways to accomplish the goal of backwards compatibility would be confusing to the WG. ;-)

I'm already to the -02 rev because I found little mistakes in the -00 and -01 (which were submitted earlier this afternoon).

Comments are welcome.

The goal of this draft is to come to agreement and interweave that agreement in the INSIPID solution draft. Right now, this draft is not intended to become an RFC.

James

_______________________________________________
insipid mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 Sep 2013 12:51:19 -0400

Christer,

> Q_1: 	I don't think we should mandate the usage of 32 zeros for the "null"
> value. It will put extra burden on parsers etc. Why not use a single zero,
> or something similar?

If the UUID types are treated as strings by the parser, the parser just
passing two strings to the application.  It would not matter if the string
is 32 octets or 1.

However, if those strings are converted to valid UUIDs, then the parser
would have to have the proper logic to know that there is this special "0"
value that needs to be expanded to 16 zero octets.

Likewise, if performing signaling interworking between SIP and H.323, it's
simpler to not have special rules when handling a single "0" value.

Thus, I'd argue using a string of zeros is better since the parser has to
have a single logic path.

Unrelated to parsing, there is perhaps benefit in not introducing special
logic in the logging code to handle single "0" values.

> Q_2:	In section 3, where Bob supports [Kaplan], you assume that Bob will
> not copy the "remote" parameter into the 200 OK response. That is not
> necessarily true - Bob might very well copy the parameter into the
> response (but Bob will of course not change the "null" value into
> something else). So, Alice needs to be prepared for a 200 OK with, or
> without, the "remote" parameter. But, in both cases it tells Alice that
> Bob supports [Kaplan].

This seems pretty significant.  Why would a Kaplan device echo back
parameters for which it has absolutely no understanding?  Are you
speculating or do implementations do, in fact, echo whatever parameters are
present in an INVITE?

Even if they do, an INSIPID device can still detect Bob is a Kaplan device
since the reply should not contain a NULL remote parameter.  (And the first
parameter should be different in a reply.
 
> Q_3:	In section3, related to Q_2, WHATEVER Bob returns in the 200 OK, I
> think Alice shall use that in future requests/responses within the dialog.
> So, if there is no "remote" parameter in the 200 OK, Alice shall not add
> it in future requests/responses within the dialog.

This touches on the "alternative" flow that is mentioned at the end of
section 4 and described in my email messages, but not elaborated in this
document.

In the flows in this draft, Alice (INSIPID) just echoes back what Bob
(Kaplan) replies with.  This did not extend to the "remote" parameter or
"foo" or "bar".  Those are not defined in the Kaplan draft.

That said, my personal preference is that Alice (INSIPID) always include a
remote parameter.  The reason is that when the call with Bob (Kaplan) is
later transferred (joined via PBX) with Carol (INSIPID), Carol can detect
Alice as INSIPID and the devices can switch modes to properly convey a
unique end-to-end identifier.

Here's a flow:

      Session ID
         ---     Alice             Bob             Carol
        {A,null}   |-----INVITE---->|                |
        {A}        |<-----200 OK----|                |
        {A,null}   |------ACK------>|                |
        {C,null}   |                |<----INVITE-----|
                   (Put Alice on hold to answer Carol)               
        {C}        |                |------200 OK--->|          
        {C,null}   |                |<-----ACK-------|
               (Put Carol + Alice on hold to transfer call) 

               (PBX initiates signaling to get calls joined)
                 Alice             PBX             Carol              
        {A,null}   |                |-----INVITE---->|

        {C,A}      |                |<-----200 OK----|
        {C,A}      |<-----INVITE----|                |
        {A,C}      |------200 OK--->|                |
        {A,C}      |                |------ACK------>| 
        {C,A}      |<-----ACK-------|                |

The above signaling can vary a lot, but this is one flow that has been used.
I don't want to pick over the flow, but just highlight that by allowing
Alice to continue to advertise "null", it allows the PBX to just mindlessly
forward Alice's Session-ID to Carol and end up with {A,C} as an end result
-- which is what we should have.

Paul

> I wrote a draft on way around our backwards compatibility issues between
> kaplan implementations and jones/insipid implementations, such that
> jones/insipid implementations advertise their adherence with a to-be
> standards-track RFC from this WG.
> 
> There are a couple of choices we as a WG need to make in this proposal.
> Namely, at the bottom of section 3 is an alternative choice for all jones
> implementations to continuously advertise they are jones implementations,
> even when communicating with kaplan implementations. The Session-IDs in
> call flows in section 3.1 and 3.2 will be affected by this choice.
> 
> As of now, I decided not to include this alternative throughout the rest
> of the ID, because I felt like having two ways to accomplish the goal of
> backwards compatibility would be confusing to the WG. ;-)
> 
> I'm already to the -02 rev because I found little mistakes in the -00 and
> -01 (which were submitted earlier this afternoon).
> 
> Comments are welcome.
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Sep 2013 11:41:01 +0000

Hi Paul,

>> value. It will put extra burden on parsers etc. Why not use a single 
>> zero, or something similar?
>
> If the UUID types are treated as strings by the parser, the parser just passing two strings to the application.  It would not matter if the string is 32 octets or 1.

Well, SOMEONE (either the parser or the app) has to check whether the number is 32.

> However, if those strings are converted to valid UUIDs, then the parser would have to have the proper logic to know that there is this special "0"
> Likewise, if performing signaling interworking between SIP and H.323, it's simpler to not have special rules when handling a single "0" value.
>
> Thus, I'd argue using a string of zeros is better since the parser has to have a single logic path.
>
> Unrelated to parsing, there is perhaps benefit in not introducing special logic in the logging code to handle single "0" values.

The logging code doesn't need to care about the length of the string, I believe.

I still think we shall also consider a feature tag, or an option tag. See more on this in Q_3.

------------------

>> without, the "remote" parameter. But, in both cases it tells Alice 
>> that Bob supports [Kaplan].
>
> This seems pretty significant.  Why would a Kaplan device echo back parameters for which it has absolutely no understanding?  Are you speculating or do implementations do, in fact, echo whatever parameters are present in an INVITE?

I haven't checked with my implementation guys, so at this point I am speculating. But, I would not be surprised if implementations simply copy the whole header field value, including possible parameters.

I haven't double check whether draft-kaplan says anything regarding this, but as it doesn't define any parameters to begin with I doubt it.

> Even if they do, an INSIPID device can still detect Bob is a Kaplan device since the reply should not contain a NULL remote parameter.  (And the first parameter should be different in a reply.

Correct, that is what I said :)

So, instead of trying to figure out what every implementation out there does, I think Alice needs to be prepared for both cases.

------------------
 
>> So, if there is no "remote" parameter in the 200 OK, Alice shall not 
>> add it in future requests/responses within the dialog.
>
> This touches on the "alternative" flow that is mentioned at the end of section 4 and described in my email messages, but not elaborated in this document.
>
> (Kaplan) replies with.  This did not extend to the "remote" parameter or "foo" or "bar".  Those are not defined in the Kaplan draft.
>
> That said, my personal preference is that Alice (INSIPID) always include a remote parameter.  The reason is that when the call with Bob (Kaplan) is later transferred (joined via PBX) with 
> Carol (INSIPID), Carol can detect Alice as INSIPID and the devices can switch modes to properly convey a unique end-to-end identifier.

Another reason why we really should have another indicator for INSIPID support... 

Otherwise, you may end up in a situation where the Session-ID value looks different in each and every message (request and response) sent between Alice and Bob throughout the session, depending on who is sending the message, whether it is a request or response, etc...

Regards,

Christer

---

From: James Polk <[email-masked]>
Date: Wed, 18 Sep 2013 13:46:04 -0500

Christer

in line below

At 06:41 AM 9/18/2013, Christer Holmberg wrote:
> > If the UUID types are treated as strings by the parser, the 
> parser just passing two strings to the application.  It would not 
> matter if the string is 32 octets or 1.
>

just asking, just how much harder is it to check if a value is 
exactly 1 or exactly 32 (which all other UUIDs are)?

> > However, if those strings are converted to valid UUIDs, then the 
> parser would have to have the proper logic to know that there is 
> this special "0"
> > Likewise, if performing signaling interworking between SIP and 
> H.323, it's simpler to not have special rules when handling a single "0" value.
> >
> > Unrelated to parsing, there is perhaps benefit in not introducing 
> special logic in the logging code to handle single "0" values.
>
> > This seems pretty significant.  Why would a Kaplan device echo 
> back parameters for which it has absolutely no understanding?  Are 
> you speculating or do implementations do, in fact, echo whatever 
> parameters are present in an INVITE?
>
>I haven't checked with my implementation guys, so at this point I am 
>speculating. But, I would not be surprised if implementations simply 
>copy the whole header field value, including possible parameters.

so, no harm is done with 32 zeros (which is the exact length of a 
valid UUID)...?

>I haven't double check whether draft-kaplan says anything regarding 
>this, but as it doesn't define any parameters to begin with I doubt it.
>
> > Even if they do, an INSIPID device can still detect Bob is a 
> Kaplan device since the reply should not contain a NULL remote 
> parameter.  (And the first parameter should be different in a reply.
>
>So, instead of trying to figure out what every implementation out 
>there does, I think Alice needs to be prepared for both cases.

whatever we reach consensus on will be written into the insipid 
draft, even if it's multiple choices - but I'd prefer that we keep it 
to a list of as few choices as possible, explicitly *not* taking 
"...every implementation out there..." into account, after all, there 
is only 1 draft that's been implemented, therefore there should only 
be one way to do that (kaplan) implementation

> > This touches on the "alternative" flow that is mentioned at the 
> end of section 4 and described in my email messages, but not 
> elaborated in this document.
> >
> > (Kaplan) replies with.  This did not extend to the "remote" 
> parameter or "foo" or "bar".  Those are not defined in the Kaplan draft.
> >
> > That said, my personal preference is that Alice (INSIPID) always 
> include a remote parameter.  The reason is that when the call with 
> Bob (Kaplan) is later transferred (joined via PBX) with
> > Carol (INSIPID), Carol can detect Alice as INSIPID and the 
> devices can switch modes to properly convey a unique end-to-end identifier.
>

not necessary, if every transferee that's a jones/insipid 
implementation includes two UUIDs in their initial request (from the 
primary polk proposal) or in *all* messages regardless of which 
implementation version Bob or Alice is communicating with (from the 
alternative polk proposal that Paul is pushing for us to specify).

>Otherwise, you may end up in a situation where the Session-ID value 
>looks different in each and every message (request and response) 
>sent between Alice and Bob throughout the session, depending on who 
>is sending the message, whether it is a request or response, etc...

huh?

If Alice is a kaplan, and Bob is an insipid, and Alice calls Bob, 
she'll have her UUID first in every Session-ID header-value in every 
message of the communications session up until the 200 OK to the BYE 
ending the session.

If Alice is a kaplan, and Bob is an insipid, and Bob calls Alice, 
he'll have his UUID first in every Session-ID header-value in every 
message of the communications session up until the 200 OK to the BYE 
ending the session.

The only question is if we have an insipid implementation include a 
remote value or not. If one is present, that in and of itself 
indicates to every entity in the signaling path that that UA is an 
insipid endpoint, and explicitly *not* a kaplan endpoint.

That's what the WG is after (wrt backwards compatibility).

 From there, we get into the minor issues of

#1 - whether every jones/insipid UA always includes 2 UUIDs
     1a - where one is a null value if the UA transmits the request, or
     1b - where the second one is a null value the UA is responding
          to a request.

#2 - next, the format of the value
     2a - 32 zeros (the exact length of a UUID value
     2b - a single zero
     2c - *new* the string "null" (i.e., remote=null)

Have I left anything out?

If so, what?

Does everyone agree with some of all of this above?

James

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2013 07:03:43 +0000

Hi James,

I will skip the questions regarding the format of the null value for the moment, because I think it is more important to first agree on IF/HOW it is going to be used.

...
...
...

> be one way to do that (kaplan) implementation

There are only two choices: either the [Kaplan] device copies the header field parameter(s), or it doesn't :)

------------------

>That's what the WG is after (wrt backwards compatibility).

And hearing you saying that is music to my ears :)

But, I still think that using a "dummy parameter value" as a capability indicator is bad design. A feature/option tag would be as explicit as a dummy value.

Also keep in mind that, even if a [Kaplan] device would copy both values, the [Insipid] device cannot "switch" the order, as it would both entities were [Insipid].

So, as shown in the example, the remote parameter would always represent the [Insipid] device, no matter in which direction a message is sent.

Example:

[Kaplan]                                     [Insipid]

 --------- S-ID: xyz;r=null ----------->
<---------S-ID: xyz;r=null ------------

[Kaplan]                                     [Insipid]

<--------- S-ID: xyz;r=null -----------
-----------S-ID: xyz;r=null ---------->

So, in my opinion it is better two use two values when both endpoints actually support them, and use something else as [Insipid] capability indicator.

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 19 Sep 2013 14:37:37 +0000

The key parts of the kaplan draft is the following:

   The UAC MUST include the Session-ID header field in every SIP

   message it transmits.

...

   A UAS compliant with this document MUST copy a received Session-ID

   header field in a request, into responses and subsequent upstream

   requests sent within the dialog.

   If an out-of-dialog request is received without a Session-ID header

   field, the UAS SHOULD generate a new one for subsequent use in the

   transaction and dialog, as defined for a UAC, and use the same value

   in all responses and upstream in-dialog requests for the same

   dialog.

So my reading is that it occurs in a response even if it was not in a request.

As far as 3GPP is concerned it is only called up for conference participants, conference focus and IBCF where it is mandatory for all. The references are to implement as specified in Kaplan.

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 19 September 2013 08:04
To: James Polk; Paul E. Jones; [email-masked]
Subject: Re: [Insipid] Proposal for Backwards Compatibility Session-ID

Hi James,

...
...
...

------------------

Example:

[Kaplan]                                     [Insipid]

[Kaplan]                                     [Insipid]

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2013 14:57:24 +0000

Hi Keith,

So, based on the text you copied, I guess that means that, when an [Insipid] entity sends a request to a [Kaplan] entity, the [Kaplan] entity would copy header field parameters (read: remote parameter) into the response (see example below).

[Kaplan]                                     [Insipid]

But, from an INSIPID 2-value perspective I see no usage of the 'null' remote parameter (other than insipid capability indicator, for which I think there are more appropriate mechanisms).

Because, the Session-ID header field will look the same in each direction (i.e. the local UUID value will always be the same, and the remote UUID value will always be the same, no matter in which direction the message is sent), it's the same as not having a remote parameter at all (see example below).

[Kaplan]                                     [Insipid]
<--------- S-ID: xyz--------------------
              <dedicated insipid indicator>

-----------S-ID: xyz------------------->

Regards,

Christer

From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: 19. syyskuuta 2013 17:38
To: Christer Holmberg; James Polk; Paul E. Jones; [email-masked]
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID

   message it transmits.

...

   dialog.

Regards

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 19 September 2013 08:04
To: James Polk; Paul E. Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [Insipid] Proposal for Backwards Compatibility Session-ID

Hi James,

...
...
...

------------------

Example:

[Kaplan]                                     [Insipid]

[Kaplan]                                     [Insipid]

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 19 Sep 2013 15:09:54 +0000

Well l guess the question is whether the receiver of a unrecognised header field parameter discards that header field parameter before doing the copying. So the response could I guess just be the value with no parameter.

So if you are looking to determine whether the remote end supports Kaplan, I guess you should take either the presence of a r= parameter with null, or the absence of a r= parameter when you sent one, as an indication of the support of Kaplan.

I suspect that an intervening B2BUA supporting Kaplan may introduce other variations of receiving one or the other.

Keith

________________________________
From: Christer Holmberg [mailto:[email-masked]]
Sent: 19 September 2013 15:57
To: DRAGE, Keith (Keith); James Polk; Paul E. Jones; [email-masked]
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID

Hi Keith,

[Kaplan]                                     [Insipid]

[Kaplan]                                     [Insipid]

Regards,

Christer

   message it transmits.

...

   dialog.

Regards

Keith

Hi James,

...
...
...

------------------

Example:

[Kaplan]                                     [Insipid]

[Kaplan]                                     [Insipid]

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2013 16:14:34 +0000

Hi Keith,

> Well l guess the question is whether the receiver of a unrecognised header field parameter discards that 
> header field parameter before doing the copying. So the response could I guess just be the value with no 
> parameter.

The draft-kaplan text you copied in your previous e-mail indicated that a receiver would copy unrecognised header field paramters.

> So if you are looking to determine whether the remote end supports Kaplan, I guess you should take either > the presence of a r= parameter with null, or the absence of a r= parameter when you sent one, as an 
> indication of the support of Kaplan.

That would be ok, if there was actually some other usage of the null value, and we would get the insipid capability indication "for free".

But, the proposal now is to include a null value only for capability indication purpose, and for that I think we should use an appropriate SIP mechanism. 

I am actually quite surprised that people have issues with using a feature/option-tag. It has never been an issue in the past, afair...

Regards,

Christer

Hi Keith,

[Kaplan]                                     [Insipid]

But, from an INSIPID 2-value perspective I see no usage of the ‘null’ remote parameter (other than insipid capability indicator, for which I think there are more appropriate mechanisms).

Because, the Session-ID header field will look the same in each direction (i.e. the local UUID value will always be the same, and the remote UUID value will always be the same, no matter in which direction the message is sent), it’s the same as not having a remote parameter at all (see example below).

[Kaplan]                                     [Insipid]

Regards,

Christer

…

Regards

Keith

Hi James,

…
…
…

------------------

Example:

[Kaplan]                                     [Insipid]

[Kaplan]                                     [Insipid]

Regards,

Christer

---

From: James Polk <[email-masked]>
Date: Thu, 19 Sep 2013 14:03:56 -0500

At 02:03 AM 9/19/2013, Christer Holmberg wrote:
>Hi James,
>
>I will skip the questions regarding the format 
>of the null value for the moment, because I 
>think it is more important to first agree on IF/HOW it is going to be used.
>
>…
>…
>…
>
>There are only two choices: either the [Kaplan] 
>device copies the header field parameter(s), or it doesn't :)
>
>------------------
>
>But, I still think that using a "dummy parameter 
>value" as a capability indicator is bad design. 
>A feature/option tag would be as explicit as a dummy value.
>
>Also keep in mind that, even if a [Kaplan] 
>device would copy both values, the [Insipid] 
>device cannot "switch" the order, as it would both entities were [Insipid].
>
>So, as shown in the example, the remote 
>parameter would always represent the [Insipid] 
>device, no matter in which direction a message is sent.
>
>Example:
>
>[Kaplan]                                     [Insipid]
>
>So, in my opinion it is better two use two 
>values when both endpoints actually support 
>them, and use something else as [Insipid] capability indicator.

because not all communications sessions are just 
between non-server endpoints. Why introduce a 3rd 
value when a second value does the job?

Also, there are a lot of folks against "just use 
another option tag", as evidenced personally 
during the Location Conveyance drafting (which turned into RFC6442).

James

---

From: James Polk <[email-masked]>
Date: Thu, 19 Sep 2013 14:14:20 -0500

At 09:57 AM 9/19/2013, Christer Holmberg wrote:
>Hi Keith,
>
>So, based on the text you copied, I guess that 
>means that, when an [Insipid] entity sends a 
>request to a [Kaplan] entity, the [Kaplan] 
>entity would copy header field parameters (read: 
>remote parameter) into the response (see example below).
>
>[Kaplan]                                     [Insipid]
>But, from an INSIPID 2-value perspective I see 
>no usage of the ‘null’ remote parameter (other 
>than insipid capability indicator, for which I 
>think there are more appropriate mechanisms).
>
>Because, the Session-ID header field will look 
>the same in each direction (i.e. the local UUID 
>value will always be the same, and the remote 
>UUID value will always be the same, no matter in 
>which direction the message is sent), it’s the 
>same as not having a remote parameter at all

not true IMO

it's plainly obvious which is an/the insipid 
implementation and which is a/the kaplan 
implementation to *all* signaling entities between the two endpoint UAs.

>(see example below).

Keith pointed to the text that says the kaplan 
implementations receiving a request that has this 
feature/option tag MUST simply copy the 
Session-ID header-value "as is" - to include 
having this feature/option tag included in what's 
copied into the reply. Thus, giving this explicit 
indication that any and all kaplan 
implementations will response as if they are 
insipid implementations, even though they do not include a second UUID.

That's just confusing, and should be avoided IMO

James

>As far as 3GPP is concerned it is only called up 
>for conference participants, conference focus 
>and IBCF where it is mandatory for all. The 
>references are to implement as specified in Kaplan.
>
>Regards
>
>Keith
>
>----------
>From: 
><mailto:[email-masked]>[email-masked] 
>[mailto:[email-masked]] On Behalf Of Christer Holmberg
>To: James Polk; Paul E. Jones; <mailto:[email-masked]>[email-masked]

---

From: James Polk <[email-masked]>
Date: Thu, 19 Sep 2013 14:20:53 -0500

At 10:09 AM 9/19/2013, DRAGE, Keith (Keith) wrote:
>Well l guess the question is whether the 
>receiver of a unrecognised header field 
>parameter discards that header field parameter 
>before doing the copying. So the response could 
>I guess just be the value with no parameter.

that's just a guess - and based on the individual 
implementation, and shouldn't we attempt to avoid 
guess work when dealing with interoperability issues?

>
>So if you are looking to determine whether the 
>remote end supports Kaplan, I guess you should 
>take either the presence of a r= parameter with 
>null, or the absence of a r= parameter when you 
>sent one, as an indication of the support of Kaplan.
>
>I suspect that an intervening B2BUA supporting 
>Kaplan may introduce other variations of receiving one or the other.

Exactly.

Further, the B2BUA only supporting kaplan will 
prune the r=(null) value (which does no harm) or 
pass it to the kaplan endpoint (which, again, does no harm).

James

>same as not having a remote parameter at all (see example below).
>
>[Kaplan]                                     [Insipid]
>

---

From: James Polk <[email-masked]>
Date: Thu, 19 Sep 2013 14:29:01 -0500

At 11:14 AM 9/19/2013, Christer Holmberg wrote:
> receiver of a unrecognised header field parameter discards that
> > header field parameter before doing the 
> copying. So the response could I guess just be the value with no
> > parameter.
>
>The draft-kaplan text you copied in your 
>previous e-mail indicated that a receiver would 
>copy unrecognised header field paramters.
>
> > So if you are looking to determine whether 
> the remote end supports Kaplan, I guess you 
> should take either > the presence of a r= 
> parameter with null, or the absence of a r= parameter when you sent one, as an
>That would be ok, if there was actually some 
>other usage of the null value, and we would get 
>the insipid capability indication "for free".
>
>But, the proposal now is to include a null value 
>only for capability indication purpose, and for 
>that I think we should use an appropriate SIP mechanism.
>
>I am actually quite surprised that people have 
>issues with using a feature/option-tag. It has 
>never been an issue in the past, afair...

SIP Location Conveyance (RFC 6442) had a great 
deal of trouble from the greybeards in the SIP 
community with adding option tags into IANA, so 
that statement is not at all true. Things might 
have changed, but we're only 600 RFCs from 
Location Conveyance, so it hasn't been that long 
since new option tags were opposed.

James

>From: [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2013 20:10:05 +0000

Hi James,

>implementation to *all* signaling entities between the two endpoint UAs.

I am not arguing against that. But, there is a reason for having 2 values, but it doesn't apply in this case (as there will be no "switch").

> That's just confusing, and should be avoided IMO

Hold on... the feature/option tag is NOT part of the Session-ID header field, and is NOT copied.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2013 20:13:37 +0000

Hi,

> since new option tags were opposed.

Well, feature tags are easier to register than option-tags, and have been registered relatively frequently. They don't even require an RFC, eventhough in this case we obviously would define it as part of the INSIPID spec.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2013 20:16:55 +0000

Hi,

> guess work when dealing with interoperability issues?

Exactly. And, by NOT adding a null value we don't need to "guess" whether a Kaplan device is going to copy it or not :)

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 20 Sep 2013 13:37:12 +0000

Just to respond on your allegation of a guess - well unless anyone is sitting with an deviant implemention in front of them, then it is just a guess - you are guessing as much as I.

What I am basically identifying is that it depends whether the syntactic parsing of the header fields is performed before any analysis is done. Any unrecognized header field parameters get discarded at that point. Therefore when a UA copies a header field from what is received, does it copy the unparsed header field (which could also contains syntactic errors as well as unrecognized fields) or does it copy the parsed and processed one, which does not include unrecognized information.

In other words is a UA allowed to generate parameters for which it does not know the ABNF for. 

I'd say the answer to that is indeterminate.

Certainly when we get to what gets passed on by a B2BUA from request to request, or response to response, I think both options exist. The fully legalistic view would be that you can only pass on what gets implemented in the B2BUA. So a B2BUA with this view and only implementing Kaplan would only pass on a Kaplan valid header field. A B2BUA implementing both solutions would pass on the full string. By we all know that B2BUAs do not necessarily work that way.

Regards

Keith

> -----Original Message-----
> From: James Polk [mailto:[email-masked]]
> Sent: 19 September 2013 20:21
> To: DRAGE, Keith (Keith); Christer Holmberg; James Polk; Paul E. Jones;
> [email-masked]
> >no usage of the 'null' remote parameter (other
> >which direction the message is sent), it's the

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 20 Sep 2013 13:39:43 +0000

I'm unhappy with the feature tag or option tag because what we are trying to identify is whether the Kaplan draft is supported by the remote end; i.e. not identifying whether the full solution is supported by the remote end.

That implies that the feature tag should be there to say "I support Kaplan", and we know a solution of that form is not going to happen.

Regards

Keith

> Sent: 19 September 2013 21:10
> To: James Polk; DRAGE, Keith (Keith); Paul E. Jones; [email-masked]
> I am not arguing against that. But, there is a reason for having 2 values,
> but it doesn't apply in this case (as there will be no "switch").
> 
> 
> >>(see example below).
> >>
> >>[Kaplan]                                     [Insipid]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2013 14:21:30 +0000

Hi,

I have said all the time that we shall not make assumptions on whether a Kaplan device will discard the (unknown) parameter, or whether it will copy it.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Lähetetty: 20. syyskuuta 2013 16:37
Vastaanottaja: James Polk; Christer Holmberg; Paul E. Jones; [email-masked]
Aihe: RE: [Insipid] Proposal for Backwards Compatibility Session-ID

Regards

Keith

> To: DRAGE, Keith (Keith); Christer Holmberg; James Polk; Paul E. 
> Jones; [email-masked]
> >Well l guess the question is whether the receiver of a unrecognised 
> >header field parameter discards that header field parameter before 
> >doing the copying. So the response could I guess just be the value 
> >with no parameter.
> 
> that's just a guess - and based on the individual implementation, and 
> shouldn't we attempt to avoid guess work when dealing with 
> interoperability issues?
> 
> >
> >So if you are looking to determine whether the remote end supports 
> >Kaplan, I guess you should take either the presence of a r= parameter 
> >with null, or the absence of a r= parameter when you sent one, as an 
> >I suspect that an intervening B2BUA supporting Kaplan may introduce 
> >other variations of receiving one or the other.
> 
> Exactly.
> 
> Further, the B2BUA only supporting kaplan will prune the r=(null) 
> value (which does no harm) or pass it to the kaplan endpoint (which, 
> again, does no harm).
> 
> James
> 
> >
> >Keith
> >
> >
> >----------
> >So, based on the text you copied, I guess that means that, when an 
> >[Insipid] entity sends a request to a [Kaplan] entity, the [Kaplan] 
> >But, from an INSIPID 2-value perspective I see no usage of the 'null' 
> >remote parameter (other than insipid capability indicator, for which 
> >I think there are more appropriate mechanisms).
> >
> >Because, the Session-ID header field will look the same in each 
> >direction (i.e. the local UUID value will always be the same, and the 
> >remote UUID value will always be the same, no matter in which 
> >direction the message is sent), it's the same as not having a remote 
> >parameter at all (see example below).
> >
> >[Kaplan]                                     [Insipid]
> >
> >As far as 3GPP is concerned it is only called up for conference 
> >participants, conference focus and IBCF where it is mandatory for 
> >all. The references are to implement as specified in Kaplan.
> >
> >Regards
> >
> >Keith
> >
> >
> >----------
> >From:
> >To: James Polk; Paul E. Jones; 
> ><mailto:[email-masked]>[email-masked]
> >I will skip the questions regarding the format of the null value for 
> >the moment, because I think it is more important to first agree on 
> >IF/HOW it is going to be
> used.
> >
> >...
> >...
> >...
> >
> > >>> I haven't double check whether draft-kaplan says anything 
> > >>> regarding this, but as it doesn't define any parameters to begin 
> > >>> with I doubt
> it.
> > >>>
> > > draft, even if it's multiple choices - but I'd prefer that we keep 
> > > it to a list of as few choices as possible, explicitly *not* 
> > > taking "...every implementation out there..." into account, after 
> > > all, there is only 1 draft that's been implemented, therefore 
> > > there should only be one way to do that (kaplan) implementation
> >
> >There are only two choices: either the [Kaplan] device copies the 
> >header field parameter(s), or it doesn't :)
> >
> >------------------
> >
> >But, I still think that using a "dummy parameter value" as a 
> >capability indicator is bad design.
> >Also keep in mind that, even if a [Kaplan] device would copy both 
> >values, the [Insipid] device cannot "switch" the order, as it would 
> >both entities were
> [Insipid].
> >
> >So, as shown in the example, the remote parameter would always 
> >represent the [Insipid] device, no matter in which direction a 
> >message is sent.
> >
> >Example:
> >
> >[Kaplan]                                     [Insipid]
> >
> >So, in my opinion it is better two use two values when both endpoints 
> >actually support them, and use something else as [Insipid] capability 
> >indicator.
> >
> >Regards,
> >
> >Christer
> >
> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2013 14:26:25 +0000

Hi,

>That implies that the feature tag should be there to say "I support Kaplan", and we know a solution of that form is not going to happen.

I don't agree. If we have a feature tag saying "I support Insipid", and if it is not present then, it DOES identify that Kaplan is not supported. Nowhere is it said that identification must be done based on the presence of some information element - it can as well be based on the lack of some information element.

Regards,

Christer

> >>But, from an INSIPID 2-value perspective I see no usage of the 
> >>'null' remote parameter (other than insipid capability indicator, 
> >>for which I think there are more appropriate mechanisms).
> >>
> >>direction (i.e. the local UUID value will always be the same, and 
> >>the remote UUID value will always be the same, no matter in which 
> >>parameter at all
> >it's plainly obvious which is an/the insipid implementation and which 
> >is a/the kaplan implementation to *all* signaling entities between 
> >the two endpoint UAs.
> 
> I am not arguing against that. But, there is a reason for having 2 
> values, but it doesn't apply in this case (as there will be no "switch").
> 
> 
> >>(see example below).
> >>
> >>[Kaplan]                                     [Insipid]
> > Keith pointed to the text that says the kaplan implementations 
> > receiving a request that has this feature/option tag MUST simply 
> > copy the Session-ID header-value "as is" - to include having this 
> > feature/option tag included in what's copied into the reply. Thus, 
> > giving this explicit indication that any and all kaplan 
> > implementations will response as if they are insipid 
> > implementations, even though they do not include a second UUID.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2013 16:50:47 +0000

Hi,

> I don't agree. If we have a feature tag saying "I support Insipid", and if it is not present then, it DOES identify that Kaplan is not supported. 

Correction: If not present, it identifies that Kaplan IS supported.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Sep 2013 13:12:43 -0400

> That implies that the feature tag should be there to say "I support Kaplan", and we know a solution of that form is not going to happen.

I assume the opposite: the option tag says "I support full insipid".  If this option tag is missing, it means you don't support the insipid RFC, but you do support the legacy kaplan one (since you included a Session-ID header at all).

And I think option tag makes more sense than feature tag, fwiw; if for no other reasons than because option tags apply to MESSAGE requests too, which don't have Contact headers and thus don't convey feature tags.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2013 22:22:09 +0000

Hi,

> And I think option tag makes more sense than feature tag, fwiw; if for no other reasons than because option tags apply to MESSAGE requests too, which don't have Contact headers and thus don't conve…

Use feature caps,

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 21 Sep 2013 20:35:55 +0000

Interesting.  Given this behavior, I think we could actually get the 
Kaplan endpoints to perhaps behave like INSIPID endpoints.

So, rather than send the "null" value, perhaps an initiating INSIPID 
device fabricates both the local and remote values and sends those in 
the initial INVITE.  A Kaplan endpoint would echo them both back.  We 
have two distinct UUIDs, which is what we want.  If the answering device 
is INSIPID, it will replace one of those values (one in the "remote" 
position) when replying.

So, we have this:

[Kaplan]                         [Insipid]

<--------- S-ID: xyz;r=rst -----------
---------- S-ID: xyz;r=rst ---------->

and

[Kaplan]                         [Insipid]

---------- S-ID: xyz       ----------->
<--------- S-ID: xyz;r=rst ------------

and

[Insipid]                        [Insipid]

<--------- S-ID: xyz;r=rst -----------
---------- S-ID: def;r=xyz ---------->

In the last example, the INSIPID device recognizes the received value as 
incorrect and replaces the "remote" value with it's own UUID.
Paul

------ Original Message ------
From: "Christer Holmberg" <[email-masked]>
To: "DRAGE, Keith (Keith)" <[email-masked]>; "James 
Polk" <[email-masked]>; "Paul E. Jones" <[email-masked]>; 
"[email-masked]" <[email-masked]>
Sent: 9/19/2013 10:57:24 AM
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID
>entity would copy header field parameters (read: remote parameter) into 
>the response (see example below).
>
>
>
>[Kaplan]                                     [Insipid]
>
>
>But, from an INSIPID 2-value perspective I see no usage of the ‘null’ 
>remote parameter (other than insipid capability indicator, for which I 
>remote UUID value will always be the same, no matter in which direction 
>the message is sent), it’s the same as not having a remote parameter at 
>all (see example below).
>
>
>
>[Kaplan]                                     [Insipid]
>
>
>participants, conference focus and IBCF where it is mandatory for all. 
>The references are to implement as specified in Kaplan.
>
>
>
>Regards
>
>
>
>Keith
>
>
>
>--------------------------------------------------------------------------------
>From:[email-masked] [mailto:[email-masked]] On 
>Behalf Of Christer Holmberg
>IF/HOW it is going to be used.
>
>
>
>…
>
>…
>
>…
>
>
>
>But, I still think that using a "dummy parameter value" as a capability 
>indicator is bad design. A feature/option tag would be as explicit as a 
>dummy value.
>
>
>
>both entities were [Insipid].
>
>
>
>represent the [Insipid] device, no matter in which direction a message 
>is sent.
>
>
>
>Example:
>
>
>
>[Kaplan]                                     [Insipid]
>
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 21 Sep 2013 20:43:29 +0000

The proposal James wrote did not require knowing whether the Kaplan 
draft would copy it or not.  If it did, no harm: we can still tell it's 
a Kaplan draft, since it did not insert correct values.  If it did not, 
we can also tell since it's missing a value.

Paul

------ Original Message ------
From: "Christer Holmberg" <[email-masked]>
To: "James Polk" <[email-masked]>; "DRAGE, Keith (Keith)" 
<[email-masked]>; "Paul E. Jones" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 9/19/2013 4:16:55 PM
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID
>Exactly. And, by NOT adding a null value we don't need to "guess" 
>whether a Kaplan device is going to copy it or not :)
>
>Regards,
>
>Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 21 Sep 2013 17:08:49 -0400

There is an issue with using options:

Supported and Required apply to the UA. It doesn't make sense for 
proxies to insert them.

	Thanks,	
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Sep 2013 08:09:41 +0000

Hi Paul,

Why would a proxy (as defined in RFC 3261) insert the value?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Sunday, 22 September 2013 12:08 AM
To: [email-masked]
Subject: Re: [Insipid] Proposal for Backwards Compatibility Session-ID

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Sep 2013 08:26:30 +0000

Hi Paul,

Even if the INSIPID devie fabricates both a local and remote value, I don't think you will get the Kaplan endpoint to "behave like an INSIPID endpoint". Because (as your examples also show), even if the Kaplan device will copy all values, it will not switch the order of them in the other direction.

Having said that, I don't have a problem with the INSIPID device fabricating both the local and remove value, eventhough from a technical viewpoint I don't think:

[Kaplan]                         [Insipid]

... is different from:

[Kaplan]                         [Insipid]

<--------- S-ID: xyz ----------------
---------- S-ID: xyz --------------->

BUT, in the Kaplan-Insipid case, if the header sent from a Kaplan device does NOT contain a remote value, I don't see why the INSIPID device should add one.

So, in my opinion:

[Kaplan]                         [Insipid]

...could be:

[Kaplan]                         [Insipid]

---------- S-ID: xyz ----------------->
<--------- S-ID: xyz ------------------

Then we would always have the same value in both directions when at least one of the endpoints is Kaplan.

Regards,

Christer

________________________________
From: Paul E. Jones [[email-masked]]
Sent: Saturday, 21 September 2013 11:35 PM
To: Christer Holmberg; DRAGE, Keith (Keith); James Polk; [email-masked]
Subject: Re: [Insipid] Proposal for Backwards Compatibility Session-ID

Interesting.  Given this behavior, I think we could actually get the Kaplan endpoints to perhaps behave like INSIPID endpoints.

So, rather than send the "null" value, perhaps an initiating INSIPID device fabricates both the local and remote values and sends those in the initial INVITE.  A Kaplan endpoint would echo them both back.  We have two distinct UUIDs, which is what we want.  If the answering device is INSIPID, it will replace one of those values (one in the "remote" position) when replying.

So, we have this:

[Kaplan]                         [Insipid]

and

[Kaplan]                         [Insipid]

and

[Insipid]                        [Insipid]

In the last example, the INSIPID device recognizes the received value as incorrect and replaces the "remote" value with it's own UUID.
Paul

------ Original Message ------
From: "Christer Holmberg" <[email-masked]<mailto:[email-masked]>>
To: "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>>; "James Polk" <[email-masked]<mailto:[email-masked]>>; "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>; "[email-masked]" <[email-masked]<mailto:[email-masked]>>
Sent: 9/19/2013 10:57:24 AM
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID
Hi Keith,

[Kaplan]                                     [Insipid]

[Kaplan]                                     [Insipid]

Regards,

Christer

From: DRAGE, Keith (Keith) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 19. syyskuuta 2013 17:38
To: Christer Holmberg; James Polk; Paul E. Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID

   message it transmits.

…

   dialog.

Regards

Keith

Hi James,

…
…
…

------------------

Example:

[Kaplan]                                     [Insipid]

[Kaplan]                                     [Insipid]

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Sep 2013 08:27:13 -0400

> Why would a proxy (as defined in RFC 3261) insert the value?

Can't a record-routing proxy insert Session-ID if one hasn't previously 
been inserted? I thought that was an important feature. Or have we moved 
to the point where we assume that all "proxies" are really B2BUAs?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Sep 2013 13:34:38 +0000

Hi,

> been inserted? I thought that was an important feature. 

My understanding is that it would be considered "B2BUA behavior".

> Or have we moved to the point where we assume that all "proxies" are really B2BUAs?

I made that assumption many years ago :)

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Sep 2013 02:17:36 +0000

Whether a header field can be inserted by a proxy or not depends on the specification defining that header field, either in the old table 1 and 2 format, or in the a section frequently entitled proxy procedures. In the absence of such statements, one must either assume it is not permitted (or that the specification is incomplete...).

As far as I am aware the Kaplan draft has no such procedures.

Keith

> Sent: 22 September 2013 14:35
> To: Paul Kyzivat
> Cc: [email-masked]
> >>>> I'm unhappy with the feature tag or option tag because what we are
> trying to identify is whether the Kaplan draft is supported by the remote
> end; i.e. not identifying whether the full solution is supported by the
> remote end.
> >>>>
> >>>> That implies that the feature tag should be there to say "I support
> Kaplan", and we know a solution of that form is not going to happen.
> >>>
> >>> I don't agree. If we have a feature tag saying "I support Insipid",
> and if it is not present then, it DOES identify that Kaplan is not
> supported.
> >>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Sep 2013 02:23:37 +0000

I think this has missed the point I was making.

The presence of Feature tags, option tags and feature capability indicators should be used for identifying what the remote end supports. One should not try and determine by the absence of such indicators anything about something not being supported, and therefore potentially something else being supported.

Regards

Keith

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: 20 September 2013 18:13
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; James Polk; Paul E. Jones; [email-masked]
> I assume the opposite: the option tag says "I support full insipid".  If
> this option tag is missing, it means you don't support the insipid RFC,
> but you do support the legacy kaplan one (since you included a Session-ID
> header at all).
> 
> And I think option tag makes more sense than feature tag, fwiw; if for no
> other reasons than because option tags apply to MESSAGE requests too,
> which don't have Contact headers and thus don't convey feature tags.
> 
> -hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Sep 2013 04:59:21 +0000

Hi,

The only thing one needs to know is whether the remote endpoint supports Insipid or not - and the presence/absence of the indicator indicates that. No indicator - no Insipid.

The presence/absence of the header field itself indicates whether the remote endpoint supports either Insipid or Kaplan, so we don't need any extra indicator for that.

Regards,

Christer

________________________________
From: DRAGE, Keith (Keith) [[email-masked]]
Sent: Monday, 23 September 2013 5:23 AM
To: Hadriel Kaplan
Cc: Christer Holmberg; James Polk; Paul E. Jones; [email-masked]
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID

Regards

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Sep 2013 15:43:28 -0400

> As far as I am aware the Kaplan draft has no such procedures.

But in the case of (hypothetical) options, we aren't talking about what 
Kaplan did, we are talking about what INSIPID might do. If 
Supported:insipid were the mechanism, then it couldn't be used by a 
proxy that wants to insert the (insipid) session-id on behalf of the UAC 
(for requests) or UAS (responses).

	Thanks,
	Paul

---

From: James Polk <[email-masked]>
Date: Mon, 23 Sep 2013 14:51:09 -0500

At 11:59 PM 9/22/2013, Christer Holmberg wrote:

>Hi,
>
>
>
>The only thing one needs to know is whether the remote endpoint 
>supports Insipid or not - and the presence/absence of the indicator 
>indicates that. No indicator - no Insipid.
>
>
>
>The presence/absence of the header field itself indicates whether 
>the remote endpoint supports either Insipid or Kaplan, so we don't 
>need any extra indicator for that.

you sold me. There is no need for an option/feature/capabilities 
indicator. We just need to look at what's in the header-value to tell 
whether it's "...either Insipid or Kaplan...", which is what I've 
been saying since I made my proposal. The format of the Session-ID 
header itself indicates which version is supported (insipid or kaplan).

James

>The presence of Feature tags, option tags and feature capability 
>indicators should be used for identifying what the remote end 
>supports. One should not try and determine by the absence of such 
>indicators anything about something not being supported, and 
>therefore potentially something else being supported.
>
>Regards
>
>Keith
>
> > From: Hadriel Kaplan 
> [<mailto:[email-masked]>mailto:[email-masked]]

---

From: James Polk <[email-masked]>
Date: Mon, 23 Sep 2013 15:17:52 -0500

At 02:43 PM 9/23/2013, Paul Kyzivat wrote:
>>Whether a header field can be inserted by a proxy or not depends on 
>>the specification defining that header field, either in the old 
>>table 1 and 2 format, or in the a section frequently entitled proxy 
>>procedures. In the absence of such statements, one must either 
>>assume it is not permitted (or that the specification is incomplete...).
>>
>But in the case of (hypothetical) options, we aren't talking about 
>what Kaplan did, we are talking about what INSIPID might do. If 
>proxy that wants to insert the (insipid) session-id on behalf of the 
>UAC (for requests) or UAS (responses).

I'm having a tough time coming up with a realistic scenario in which 
an INSIPID implementation would include a Supported header (with 
whatever option-tag we come up with) and not include a Session-ID 
header or header-value, just to have some SIP server (of whatever 
flavor) insert the Session-ID header (or header-value) or to just let 
downstream signaling entities learn that this SIP message came from 
an INSIPID capable implementation...

James

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 23 Sep 2013 21:06:36 +0000

Christer,

You're right that the Kaplan endpoints would not behave like INSIPID 
ones.  Poor wording on my part.  The interesting behavior is that we 
might see two UUIDs on the wire from Kaplan devices that are called by 
INSIPID devices.

I still think there is value in INSPID devices responding to Kaplan 
devices with a "remote" parameter.  I assume if the call is transferred 
by the PBX, it might mindlessly forward the Session-ID header.  Having 
the remote parameter present, the called device (if INSIPID) would 
behave properly in assigning its own UUID and then putting the called 
device's UUID into the "remote" parameter.

That said, this could introduce another interop problem if a Kaplan 
device just echoes what it receives.  I can imagine a call from INSIPID 
to Kaplan where Kaplan echoes the "remote" parameter.  Later, the PBX 
joins the Kaplan leg with a different INSIPID endpoint.  The end result 
is that the Kaplan device produces a false advertisement and the INSIPID 
device re-orders values.

The re-ordering of values is not the problem.  Rather, it's the fact 
that the Kaplan device just echos values. If two separate Kaplan devices 
using their own Session-IDs are joined together by a PBX, we run into 
the same issue where both sides have a different understanding of the 
Session-ID.

So, given we can't really get away from all interworking issues -- even 
if INSIPID never existed -- I think it's reasonable to try to do what's 
helpful for INSIPID devices longer-term.  By that, I mean I think we 
should have INSIPID devices advertise two values from the outset, with 
the "remote" parameter set to NULL or with it set to some other UUID.  
(This would not be necessary if Kaplan devices did not exist, but we 
need to address the call join case where two INSIPID endpoints are 
joined.  They should follow the INSIPID procedures.)

Paul

------ Original Message ------
From: "Christer Holmberg" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "DRAGE, Keith (Keith)" 
<[email-masked]>; "James Polk" <[email-masked]>; 
"[email-masked]" <[email-masked]>
Sent: 9/22/2013 4:26:30 AM
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID
>Hi Paul,
>
>
>
>Even if the INSIPID devie fabricates both a local and remote value, I 
>don't think you will get the Kaplan endpoint to "behave like an INSIPID 
>endpoint". Because (as your examples also show), even if the Kaplan 
>device will copy all values, it will not switch the order of them in 
>the other direction.
>
>
>
>Having said that, I don't have a problem with the INSIPID device 
>fabricating both the local and remove value, eventhough from a 
>technical viewpoint I don't think:
>
>
>
>[Kaplan]                         [Insipid]
>
>BUT, in the Kaplan-Insipid case, if the header sent from a Kaplan 
>device does NOT contain a remote value, I don't see why the INSIPID 
>device should add one.
>
>So, in my opinion:
>
>[Kaplan]                         [Insipid]
>
>have two distinct UUIDs, which is what we want.  If the answering 
>device is INSIPID, it will replace one of those values (one in the 
>"remote" position) when replying.
>
>So, we have this:
>
>[Kaplan]                         [Insipid]
>
>In the last example, the INSIPID device recognizes the received value 
>as incorrect and replaces the "remote" value with it's own UUID.
>Paul
>
>>entity would copy header field parameters (read: remote parameter) 
>>into the response (see example below).
>>
>>
>>
>>[Kaplan]                                     [Insipid]
>>
>>
>>direction the message is sent), it’s the same as not having a remote 
>>regarding
>>it
>>capability indicator is bad design. A feature/option tag would be as 
>>explicit as a dummy value.
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Sep 2013 22:14:32 -0400

On 9/23/13 4:17 PM, James Polk wrote:
>>> the specification defining that header field, either in the old table
>>> 1 and 2 format, or in the a section frequently entitled proxy
>>> procedures. In the absence of such statements, one must either assume
>>> it is not permitted (or that the specification is incomplete...).
>>>
> I'm having a tough time coming up with a realistic scenario in which an
> INSIPID implementation would include a Supported header (with whatever
> option-tag we come up with) and not include a Session-ID header or
> header-value, just to have some SIP server (of whatever flavor) insert
> the Session-ID header (or header-value) or to just let downstream
> signaling entities learn that this SIP message came from an INSIPID
> capable implementation...

I'd have a hard time with that too. It wasn't what I was suggesting.

I'm suggesting the case where the UAC doesn't support INSIPID (or 
Kaplan) at all, but an intermediary (in this case a proxy) wants to act 
on its behalf. I believe that is one of the use cases.

My point was that *if* Supported were proposed as the mechanism to 
formally distinguish use of insipid from use of Kaplan, then it would be 
a problem for the proxy. The proxy wouldn't be allowed to insert the 
Supported.

If people have gotten past that ideal, and are satisfied to distinguish 
insipid support solely by what is in the Session-ID header, then we 
don't need to talk about this any longer.

	Thanks,
	Paul

>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf
>>>> Of Christer Holmberg
>>>>>>> Hold on... the feature/option tag is NOT part of the Session-ID
>>>>>>> header
>>>>>>> field, and is NOT copied.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Christer

---

From: James Polk <[email-masked]>
Date: Tue, 24 Sep 2013 12:55:04 -0500

>I'd have a hard time with that too. It wasn't what I was suggesting.

I'm sorry. That's what I thought I read.

>Kaplan) at all, but an intermediary (in this case a proxy) wants to 
>act on its behalf. I believe that is one of the use cases.

I believe it is.

>formally distinguish use of insipid from use of Kaplan, then it 
>would be a problem for the proxy. The proxy wouldn't be allowed to 
>insert the Supported.

No, it would not.

>If people have gotten past that ideal, and are satisfied to 
>distinguish insipid support solely by what is in the Session-ID 
>header, then we don't need to talk about this any longer.

That's what I've been work towards all along (that the header itself, 
wholly contained within itself, distinguish which implementation it supports).

James