Subject: [clue] Slides for design team today

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Oct 2013 09:19:12 -0400

You can find Christer's slides for today at:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/CLUE_Legacy_1oct13.pptx

See you shortly.

	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 1 Oct 2013 09:26:07 -0500

I'm in another meeting so unfortunately cannot attend today.  But, I would
really, really like to get away from the term "legacy" -  the English
language definition of "legacy" is not correct. CLUE isn't superseding any
functionality of current SIP endpoints.  It's adding additional
functionality. I would much rather select something like "non-Clue enabled
endpoint".   We can shorten if folks are concerned about the length of a
more appropriate alternative term.

As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly
more appropriate since it's a different architecture and entirely new
application - i.e., it isn't based on RFC 3261, but CLUE is, so any
suggestion that it's replacing any current SIP functionality isn't correct.

Regards,
Mary.

On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <[email-masked]> wrote:

> http://trac.tools.ietf.org/wg/**clue/trac/attachment/wiki/**
> Design-Team/CLUE_Legacy_**1oct13.pptx<http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/CLUE_Legacy_1oct13.pptx>
>
> See you shortly.
>
>         Paul
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Oct 2013 12:22:56 -0400

Mary,

The minutes are now posted. We did talk about this, briefly.
We decided we didn't want to use the meeting time to discuss what word 
to use - that we could do that on the list.

I agree with you, I also think "legacy" has the wrong connotation for 
what we mean, so I would like to find a better term. I have no ideas 
that I love, but a couple that I could live with: "non-clue", "clueless".

	Thanks,
	Paul

On 10/1/13 10:26 AM, Mary Barnes wrote:
> I'm in another meeting so unfortunately cannot attend today.  But, I
> would really, really like to get away from the term "legacy" -  the
> English language definition of "legacy" is not correct. CLUE isn't
> superseding any functionality of current SIP endpoints.  It's adding
> additional functionality. I would much rather select something like
> "non-Clue enabled endpoint".   We can shorten if folks are concerned
> about the length of a more appropriate alternative term.
>
> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy___1oct13.pptx
>     <http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/CLUE_Legacy_1oct13.pptx>
>
>     See you shortly.
>
>              Paul
>     _________________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/clue
>     <https://www.ietf.org/mailman/listinfo/clue>
>
>

---

From: Robert Hansen <[email-masked]>
Date: Tue, 01 Oct 2013 17:45:21 +0100

I am personally very fond of 'CLUEless' :)

Rob

On 01/10/2013 17:22, Paul Kyzivat wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Mary Barnes <[email-masked]>
Date: Tue, 1 Oct 2013 11:51:27 -0500

Yeah - I think clueless is a reasonable and compact term to use.

On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen <[email-masked]> wrote:

>>> <mailto:[email-masked]>**> wrote:
>>>
>>> http://trac.tools.ietf.org/wg/**__clue/trac/attachment/wiki/__**
>>> Design-Team/CLUE_Legacy___**1oct13.pptx<http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy___1oct13.pptx>
>>>
>>>
>>> <http://trac.tools.ietf.org/**wg/clue/trac/attachment/wiki/**
>>>     ______________________________**___________________
>>>     clue mailing list
>>>     https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>>     <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>> >
>>>
>>>
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Oct 2013 18:16:05 +0000

Hi,

I am not saying we can't use 'clueless', but I want a term that I can use and reference outside CLUE, e.g. in 3GPP specifications. So, we also need some definition text. I can work on that, and suggest something, as part of the lega... eeeeh... clueless interworking task.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] on behalf of Mary Barnes [[email-masked]]
Sent: Tuesday, 01 October 2013 7:51 PM
To: Robert Hansen
Cc: CLUE
Subject: Re: [clue] Its not "legacy", its ???

On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen <[email-masked]<mailto:[email-masked]>> wrote:
I am personally very fond of 'CLUEless' :)

Rob

     Thanks,
     Paul

As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly
more appropriate since it's a different architecture and entirely new
application - i.e., it isn't based on RFC 3261, but CLUE is, so any
suggestion that it's replacing any current SIP functionality isn't
correct.

Regards,
Mary.

On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    See you shortly.

             Paul
    _________________________________________________
    clue mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/__listinfo/clue
    <https://www.ietf.org/mailman/listinfo/clue>

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Mary Barnes <[email-masked]>
Date: Tue, 1 Oct 2013 13:35:31 -0500

Sure. We can make a definition for the term "clueless", something like:
A SIP endpoint that is not enabled to support the CLUE protocol and
required SDP/RTP extensions.

We have this concept in XCON and we just use the term non-XCON enabled
client (but we didn't have the convenience of a catch term to use in place
of the expanded term ;)

Mary.

On Tue, Oct 1, 2013 at 1:16 PM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
>
>
> I am not saying we can't use 'clueless', but I want a term that I can use
> and reference outside CLUE, e.g. in 3GPP specifications. So, we also need
> some definition text. I can work on that, and suggest something, as part of
> the lega... eeeeh... clueless interworking task.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
> ------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of Mary
> Barnes [[email-masked]]
> *Sent:* Tuesday, 01 October 2013 7:51 PM
> *To:* Robert Hansen
> *Cc:* CLUE
> *Subject:* Re: [clue] Its not "legacy", its ???
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Oct 2013 17:40:28 -0400

> I am personally very fond of 'CLUEless' :)

One of the reasons I liked the name "clue" for the wg was because it 
gave us an excuse to use "clueless" and "clueful". However they do have 
the feel of "informal" usage - a bit odd for formal use. (But I can get 
over that.)

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 02 Oct 2013 13:29:29 +1000

I'm not sure that "CLUEless" is the same as "legacy". "Legacy" seems to 
imply the absence of the CLUE protocol AND a certain "media stream 
configuration". I think Christer's slides from the design team meeting 
illustrated this. CLUEless to me suggests that the CLUE channel has been 
removed (along with the CLUE specific SDP) it doesn't suggest a fall 
back to a base media set. I think this is fine as CLUE and SDP (which 
does the fallback) are and should be decoupled.

So if we are talking about "fallback to legacy" an equivalent would be 
to say "reverting to a CLUEless session with a basic media configuration".

With regards to the definition of CLUEless: the one below seems to focus 
on endpoint, you could also have a clueless session. I.e. the endpoint 
is CLUE enabled but doesn't use CLUE for the session.

Perhaps it would be sufficient to say: "CLUEless: Indicates an absence 
of the CLUE protocol"?

Christian

On 2/10/2013 4:35 AM, Mary Barnes wrote:
> client (but we didn't have the convenience of a catch term to use in 
> place of the expanded term ;)
>
> Mary.
>
>
> On Tue, Oct 1, 2013 at 1:16 PM, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     I am not saying we can't use 'clueless', but I want a term that I
>     can use and reference outside CLUE, e.g. in 3GPP specifications.
>     So, we also need some definition text. I can work on that, and
>     suggest something, as part of the lega... eeeeh... clueless
>     interworking task.
>
>     Regards,
>
>     Christer
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] on behalf
>     of Mary Barnes [[email-masked]
>     <mailto:[email-masked]>]
>                 On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Oct 2013 07:42:12 +0000

Hi,

I think we need to separate between two things: 

1) Whether an entity supports CLUE or not; and
2) Whether a session between two CLUE-enabled entities are in "clue" or "clueless" state.

So, I guess my "fallback" slide should say "fallback to clueless mode", because both entities are CLUE-enabled.

And, when two CLUE-enabled entities establish a session, the initial Offer will bring them to "clueless" state. Later, when the CLUE channel is established etc, they will turn into "clue" state.

But, I would not like us to use the terminology for indicating whether an entity supports CLUE or not, and to indicate the state of a session between two CLUE entities.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 2. lokakuuta 2013 6:29
To: [email-masked]
Subject: Re: [clue] Its not "legacy", its ???

I'm not sure that "CLUEless" is the same as "legacy". "Legacy" seems to imply the absence of the CLUE protocol AND a certain "media stream configuration". I think Christer's slides from the design team meeting illustrated this. CLUEless to me suggests that the CLUE channel has been removed (along with the CLUE specific SDP) it doesn't suggest a fall back to a base media set. I think this is fine as CLUE and SDP (which does the fallback) are and should be decoupled.

So if we are talking about "fallback to legacy" an equivalent would be to say "reverting to a CLUEless session with a basic media configuration".

With regards to the definition of CLUEless: the one below seems to focus on endpoint, you could also have a clueless session. I.e. the endpoint is CLUE enabled but doesn't use CLUE for the session.

Perhaps it would be sufficient to say: "CLUEless: Indicates an absence of the CLUE protocol"?

Christian

---

From: Paul Coverdale <[email-masked]>
Date: Wed, 2 Oct 2013 09:35:00 -0400

I thought the proposal of "clueless' was just a joke when I first saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, but I
would suggest "non-CLUE" equipped". But if you insist on using "clueless",
at least hyphenate it (clue-less).

...Paul

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: [email-masked]
>>> We decided we didn't want to use the meeting time to discuss what
>>> word to use - that we could do that on the list.
>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is
>>>> slightly more appropriate since it's a different architecture and
>>>> entirely new application - i.e., it isn't based on RFC 3261, but
>>>> CLUE is, so any suggestion that it's replacing any current SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 2 Oct 2013 08:56:54 -0500

It is a fine line.  I personally have a preference for "non-CLUE enabled".
  I really don't think we'll be using that in too many places in the
documents that it's too much typing.  If someone thinks that's the case,
perhaps we use "clueless" in the docs until we're ready to ship them out of
the WG and then just do a global change.  As I've said before for XCON, we
do use the term "non-XCON enabled" which I think has the right semantics
and really isn't too much of a mouthful to say either.

Mary.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Oct 2013 14:12:34 +0000

Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we have is something where CLUE does not exist, not the creation of some other concept of a "non-CLUE" to complement a "CLUE". You want to apply the negation to the "enabled" which is something like "disabled", "unenabled" or whatever.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57
To: Paul Coverdale
Cc: CLUE
Subject: Re: [clue] Its not "legacy", its ???

It is a fine line.  I personally have a preference for "non-CLUE enabled".   I really don't think we'll be using that in too many places in the documents that it's too much typing.  If someone thinks that's the case, perhaps we use "clueless" in the docs until we're ready to ship them out of the WG and then just do a global change.  As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right semantics and really isn't too much of a mouthful to say either.

Mary.

On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale <[email-masked]<mailto:[email-masked]>> wrote:
I thought the proposal of "clueless' was just a joke when I first saw it,
but apparently not.

...Paul

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>Paul Kyzivat
>To: [email-masked]<mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 2 Oct 2013 09:17:13 -0500

"non-CLUE enabled" means the endpoint does not support the CLUE protocol
(at all) or the endpoint is not using the CLUE protocol for whatever reason
(e.g., fallback case)

I think the "non-CLUE" is more in line with the original implication of the
term "legacy".

Mary .

On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> ****
>
> Just to add a pedantic point, I am not sure what a “non-CLUE” is. What we
> have is something where CLUE does not exist, not the creation of some other
> concept of a “non-CLUE” to complement a “CLUE”. You want to apply the
> negation to the “enabled” which is something like “disabled”, “unenabled”
> or whatever.****
>
> ** **
>
> Keith****
>
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mary Barnes
> *Sent:* 02 October 2013 14:57
> *To:* Paul Coverdale
> *Cc:* CLUE
>
> ****
>  ** **
> and really isn't too much of a mouthful to say either.****
>
> ** **
>
> Mary. ****
>
> ** **
>
> On Wed, **Oct 2, 2013** at **8:35 AM**, Paul Coverdale <
> [email-masked]> wrote:****
>
> ...Paul****
> >From: [email-masked] [mailto:[email-masked]] On Behalf Of**
> **
>
> >Paul Kyzivat
> >Sent: Tuesday, **October 01, 2013** **5:40 PM**
> >To: [email-masked]
> >****
> >>>>****
> >>>> <http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team*
> ***
>
> >>>> /CLUE_Legacy_1oct13.pptx>
> >>>>
> >>>>
> >>>>
> >>>>     See you shortly.
> >>>>
> >>>>              Paul
> https://www.ietf.org/mailman/listinfo/clue****
>
> ** **
>

---

From: Paul Coverdale <[email-masked]>
Date: Wed, 2 Oct 2013 10:21:43 -0400

I'm not sure I agree with your reasoning, Keith. It's the "CLUE" part we
want to negate, not whether it is enabled or not. If we negate "enabled",
using "disabled' or whatever, it would imply some other type of system which
has CLUE capability, but for some reason doesn't want to use it.

...Paul

From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2013 10:13 AM
To: Mary Barnes; Paul Coverdale
Cc: CLUE
Subject: RE: [clue] Its not "legacy", its ???

Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we
have is something where CLUE does not exist, not the creation of some other
concept of a "non-CLUE" to complement a "CLUE". You want to apply the
negation to the "enabled" which is something like "disabled", "unenabled" or
whatever.

Keith

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: 02 October 2013 14:57
To: Paul Coverdale
Cc: CLUE
Subject: Re: [clue] Its not "legacy", its ???

It is a fine line.  I personally have a preference for "non-CLUE enabled".
I really don't think we'll be using that in too many places in the documents
that it's too much typing.  If someone thinks that's the case, perhaps we
use "clueless" in the docs until we're ready to ship them out of the WG and
then just do a global change.  As I've said before for XCON, we do use the
term "non-XCON enabled" which I think has the right semantics and really
isn't too much of a mouthful to say either.

Mary. 

On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale <[email-masked]>
wrote:

...Paul

>>>> <http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Oct 2013 14:44:11 +0000

Hi,

I agree that "non-CLUE enabled" refers to an entity that doesn't support CLUE, or for whatever reason does not want to use CLUE.

But, still, even when a session is established between two CLUE enabled clients, the initial Offer/Answer will be for a "non-CLUE session" - in order to interwork with non-CLUE enabled devices. Then, if both endpoints are CLUE enabled, the data channel will be established, CLUE messages will be sent, and one or more CLUE specific Offer/Answers will be sent.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Coverdale [[email-masked]]
Sent: Wednesday, 02 October 2013 5:21 PM
To: 'DRAGE, Keith (Keith)'
Cc: 'CLUE'
Subject: Re: [clue] Its not "legacy", its ???

I’m not sure I agree with your reasoning, Keith. It’s the “CLUE” part we want to negate, not whether it is enabled or not. If we negate “enabled”, using “disabled’ or whatever, it would imply some other type of system which has CLUE capability, but for some reason doesn’t want to use it.

...Paul

Just to add a pedantic point, I am not sure what a “non-CLUE” is. What we have is something where CLUE does not exist, not the creation of some other concept of a “non-CLUE” to complement a “CLUE”. You want to apply the negation to the “enabled” which is something like “disabled”, “unenabled” or whatever.

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57
To: Paul Coverdale
Cc: CLUE
Subject: Re: [clue] Its not "legacy", its ???

Mary.

...Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Oct 2013 14:45:10 +0000

That is just saying the negative chosen is the wrong one.

"CLUE unsupported"

"CLUE inhibited"

"CLUE disallowed"

"CLUE frustrated"

Keith

________________________________
From: Paul Coverdale [mailto:[email-masked]]
Sent: 02 October 2013 15:22
To: DRAGE, Keith (Keith)
Cc: 'CLUE'
Subject: RE: [clue] Its not "legacy", its ???

I'm not sure I agree with your reasoning, Keith. It's the "CLUE" part we want to negate, not whether it is enabled or not. If we negate "enabled", using "disabled' or whatever, it would imply some other type of system which has CLUE capability, but for some reason doesn't want to use it.

...Paul

Keith

Mary.

...Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Oct 2013 14:45:09 +0000

If you don't have a telephone, you don't suddenly have a "non-telephone", on which you make your "non-calls".

You need to apply the negation to the right word, and it is not CLUE that is subject to the negation.

Keith

________________________________
From: Mary Barnes [mailto:[email-masked]]
Sent: 02 October 2013 15:17
To: DRAGE, Keith (Keith)
Cc: Paul Coverdale; CLUE
Subject: Re: [clue] Its not "legacy", its ???

"non-CLUE enabled" means the endpoint does not support the CLUE protocol (at all) or the endpoint is not using the CLUE protocol for whatever reason (e.g., fallback case)

I think the "non-CLUE" is more in line with the original implication of the term "legacy".

Mary .

On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we have is something where CLUE does not exist, not the creation of some other concept of a "non-CLUE" to complement a "CLUE". You want to apply the negation to the "enabled" which is something like "disabled", "unenabled" or whatever.

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57
To: Paul Coverdale
Cc: CLUE

Mary.

...Paul

---

From: Mary Barnes <[email-masked]>
Date: Wed, 2 Oct 2013 09:52:02 -0500

On Wed, Oct 2, 2013 at 9:45 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> ****
>
> If you don’t have a telephone, you don’t suddenly have a “non-telephone”,
> on which you make your “non-calls”.
>
[MB] CLUE isn't an endpoint - it's functionality supported by an endpoint.
 So, non-CLUE means you don't support the CLUE protocol or related
processing to handle that protocol. [/MB]

> ****
>
> ** **
>
> You need to apply the negation to the right word, and it is not CLUE that
> is subject to the negation.****
>
> ** **
>
> Keith****
>
> ** **
> *From:* Mary Barnes [mailto:[email-masked]]
> *Sent:* 02 October 2013 15:17
> *To:* DRAGE, Keith (Keith)
> *Cc:* Paul Coverdale; CLUE
>
> (e.g., fallback case)****
>
> ** **
>
> I think the "non-CLUE" is more in line with the original implication of
> the term "legacy".  ****
>
> ** **
>
> Mary .****
>
> ** **
>
> On Wed, **Oct 2, 2013** at **9:12 AM**, DRAGE, Keith (Keith) <
> [email-masked]> wrote:****
>
> *Cc:* CLUE****
> *Subject:* Re: [clue] Its not "legacy", its ???****
>
>  ****
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 2 Oct 2013 09:53:47 -0500

On Wed, Oct 2, 2013 at 9:44 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
>
>
> I agree that "non-CLUE enabled" refers to an entity that doesn't support
> CLUE, or for whatever reason does not want to use CLUE.
>
>
>
> But, still, even when a session is established between two CLUE enabled
> clients, the initial Offer/Answer will be for a "non-CLUE session" - in
> order to interwork with non-CLUE enabled devices.
>
[MB] Actually, you just don't know at that point.  I don't think we even
need to use the concept of "non-CLUE" at that point.   I think we are (as
usual) over-analyzing.  [/MB]

> Then, if both endpoints are CLUE enabled, the data channel will be
> established, CLUE messages will be sent, and one or more CLUE specific
> Offer/Answers will be sent.
>
>
>
> Regards,
>
>
>
> Christer
>
>
> *From:* [email-masked] [[email-masked]] on behalf of Paul
> Coverdale [[email-masked]]
> *Sent:* Wednesday, 02 October 2013 5:21 PM
> *To:* 'DRAGE, Keith (Keith)'
>
> *Cc:* 'CLUE'
>   I’m not sure I agree with your reasoning, Keith. It’s the “CLUE” part
> we want to negate, not whether it is enabled or not. If we negate
> “enabled”, using “disabled’ or whatever, it would imply some other type of
> system which has CLUE capability, but for some reason doesn’t want to use
> it.
>
>
>
>
>
> ...Paul
>
>
>
> *From:* DRAGE, Keith (Keith) [mailto:[email-masked]]
> *Sent:* Wednesday, October 02, 2013 10:13 AM
> *To:* Mary Barnes; Paul Coverdale
> *Cc:* CLUE
> *Subject:* RE: [clue] Its not "legacy", its ???
>
>
>
> or whatever.
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Mary Barnes

---

From: Paul Coverdale <[email-masked]>
Date: Wed, 2 Oct 2013 13:16:46 -0400

Well, we can add a few more:

"CLUE agnostic"

"CLUE couldn't care less"

"CLUE what's all this fuss about anyway"

......

But if you want to get away from "non" in front of CLUE, your proposal of
"CLUE unsupported" seems reasonable to cover what we are looking for.

...Paul

From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2013 10:45 AM
To: Paul Coverdale
Cc: 'CLUE'
Subject: RE: [clue] Its not "legacy", its ???

"CLUE unsupported"

"CLUE inhibited"

"CLUE disallowed"

"CLUE frustrated"

Keith

  _____  

 

...Paul

Keith

  _____  

Mary. 

...Paul

---

From: Michael Hammer <[email-masked]>
Date: Wed, 2 Oct 2013 17:43:42 +0000

Or just call it pre-CLUE.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Coverdale
Sent: Wednesday, October 02, 2013 1:17 PM
To: 'DRAGE, Keith (Keith)'
Cc: 'CLUE'
Subject: Re: [clue] Its not "legacy", its ???

"CLUE agnostic"

......

...Paul

"CLUE unsupported"

"CLUE inhibited"

"CLUE disallowed"

"CLUE frustrated"

Keith

  _____  

 

...Paul

Keith

  _____  

Mary. 

...Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Oct 2013 16:36:28 -0400

I think I am in agreement with Mary!!!

In practice we can't distinguish between an endpoint that is incapable 
of supporting clue and one that chooses not to support clue. And that is 
true even if it was previously supporting clue in the session. (Perhaps 
it is mobile, and can change from a state where it supports clue to one 
where it does not.)

We do have endpoints that claim conformance to CLUE, and others that don't.

A given session can be using CLUE, or not. If the session is using CLUE, 
then both endpoints support CLUE. We can write specifications for how 
both ends are to behave in that case. We can also write specifications 
for how an endpoint supporting CLUE is to behave in a session where SIP 
without CLUE is in use. But in that case we can't specify any behavior 
for the other end other that referencing other specs that it might be 
supporting.

We are using the "CLUE channel" in two ways: to indicate support for 
CLUE, and to do CLUE specific signaling. But it need not be the case 
that the absence of a CLUE channel means that we are not using CLUE in 
the session.

If we got a CLUE channel up and were using CLUE on a session, and then 
the channel breaks for some reason, then we don't have a clue channel, 
but I think we are still using clue on the session. Then our 
specification can contain rules for what to do to either reestablish the 
channel, or continue using clue in a degraded mode without it, or stop 
using CLUE on the session. We could (if we wanted) define a way to 
explicitly drop the clue channel and continue in degraded mode without it.

I think the following state machine describes the state of a *session*:
(This *should* display in fixed width.)

   +----------+     +----------+
   | STARTING |---->| CLUELESS |
   +----------+     +----------+
         |               ^
         v               |
+-----------------------+-------+
|            CLUEFUL            |
|  +---------+                  |
|  | Channel |<----------+      |
|  |  Open   |           |      |
|  +---------+           |      |
|        ^               |      |
|        |               |      |
|        v               v      |
|  +---------+      +---------+ |
|  | Channel |----->| Channel | |
|  | Broken  |      | Closed  | |
|  +---------+      +---------+ |
+-------------------------------+

I've used CLUEFUL and CLUELESS above for convenience, but CLUE-mode and 
non-CLUE-mode would probably be more suitable formal terms.

If we were to follow the above, then we would need to specify the exact 
conditions that cause state transitions. In particular, how to 
distinguish between CLUELESS and CLUEFUL with channel broken or closed.

     Thanks,
     Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 3 Oct 2013 14:56:28 +0000

You're running into the problem of the lack of scoping parentheses in natural language.  It's not (non-CLUE) enabled, it's non-(CLUE enabled).

Would "non-CLUE-enabled" (with the extra hyphen) be clearer?

On Oct 2, 2013, at 10:45 AM, "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>>
 wrote:

If you don’t have a telephone, you don’t suddenly have a “non-telephone”, on which you make your “non-calls”.

Keith

________________________________
From: Mary Barnes [mailto:[email-masked]<http://gmail.com>]
Sent: 02 October 2013 15:17
To: DRAGE, Keith (Keith)
Cc: Paul Coverdale; CLUE
Subject: Re: [clue] Its not "legacy", its ???

Mary .

Keith

Mary.

...Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 3 Oct 2013 16:59:59 +0000

English doesn't work that way. The only way to do what you are doing is to say "CLUE non-enabled" or probably more correctly "CLUE not enabled".

Keith

________________________________
From: Jonathan Lennox [mailto:[email-masked]]
Sent: 03 October 2013 15:56
To: DRAGE, Keith (Keith)
Cc: Mary Barnes; CLUE
Subject: Re: [clue] Its not "legacy", its ???

Keith

Mary .

Keith

Mary.

...Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Oct 2013 15:01:48 -0400

On 10/3/13 12:59 PM, DRAGE, Keith (Keith) wrote:
> English doesn’t work that way. The only way to do what you are doing is
> to say “CLUE non-enabled” or probably more correctly “CLUE not enabled”.

This is why we coin special terms and give them precise definitions.
If they look like regular words then its best if the precise definitions 
are consistent with the informal connotation of the words, but 
ultimately it is the formal definition that matters.

	Thanks,
	Paul

> *From:*Jonathan Lennox [mailto:[email-masked]]
> *Sent:* 03 October 2013 15:56
> *Cc:* Mary Barnes; CLUE
> You're running into the problem of the lack of scoping parentheses in
> natural language.  It's not (non-CLUE) enabled, it's non-(CLUE enabled).
>
> On Oct 2, 2013, at 10:45 AM, "DRAGE, Keith (Keith)"
> <[email-masked] <mailto:[email-masked]>>
>
>   wrote:
>
>
>
> If you don’t have a telephone, you don’t suddenly have a
> “non-telephone”, on which you make your “non-calls”.
>
> *From:*Mary Barnes [mailto:[email-masked] <http://gmail.com>]
> (at all) or the endpoint is not using the CLUE protocol for whatever
> reason (e.g., fallback case)
>
> the term "legacy".
> On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith)
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> Just to add a pedantic point, I am not sure what a “non-CLUE” is. What
> we have is something where CLUE does not exist, not the creation of some
> other concept of a “non-CLUE” to complement a “CLUE”. You want to apply
> the negation to the “enabled” which is something like “disabled”,
> “unenabled” or whatever.
>
> Keith
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf
> Of *Mary Barnes
> It is a fine line.  I personally have a preference for "non-CLUE
> enabled".   I really don't think we'll be using that in too many places
> in the documents that it's too much typing.  If someone thinks that's
> the case, perhaps we use "clueless" in the docs until we're ready to
> ship them out of the WG and then just do a global change.  As I've said
> before for XCON, we do use the term "non-XCON enabled" which I think has
> the right semantics and really isn't too much of a mouthful to say either.
>
> Mary.
>
>>From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of
>
>>Paul Kyzivat
>>Sent: Tuesday,October 01, 2013 5:40 PM
>>To:[email-masked] <mailto:[email-masked]>
>>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>
>>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>
>>>>>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>