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

[Christer Holmberg <[e-mail]>]

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.

...
...
...

>>> 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.
>
> 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

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

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

>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).

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