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

[Christer Holmberg <[e-mail]>]

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) [[e-mail]]
Sent: Monday, 23 September 2013 5:23 AM
To: Hadriel Kaplan
Cc: Christer Holmberg; James Polk; Paul E. Jones; [e-mail]
Subject: RE: [Insipid] Proposal for Backwards Compatibility Session-ID

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

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[e-mail]]
> Sent: 20 September 2013 18:13
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; James Polk; Paul E. Jones; [e-mail]
> Subject: Re: [Insipid] Proposal for Backwards Compatibility Session-ID
>
>
> On Sep 20, 2013, at 9:39 AM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-
> lucent.com> wrote:
>
> > 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 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