Subject: [core] Lifetime (lt) and Less Than (lt)

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jan 2017 15:03:50 +0100

Hi all,

I noticed that
https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 uses
the parameter lt for lifetime and
https://tools.ietf.org/html/draft-ietf-core-dynlink-01 uses lt for Less
Than.

Both use the same parameter acronym (lt).

Can this cause problems? Should we change lifetime to lft?

Ciao
Hannes

---

From: Michael Koster <[email-masked]>
Date: Wed, 11 Jan 2017 06:46:21 -0800

Hi Hannes,

I never noticed that before!

I don't think there would ever be a situation where you would use them in the same request, so I don't think we need to change either one.

I think it's a similar idea as 2 URIs with a different path component:

/example/sensor/a
/example/sensor/b

/rd?lt=100
/some/sensor/not-an-rd?lt=25.3

Does this make sense?

Best regards,

Michael
> On Jan 11, 2017, at 6:03 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> I noticed that
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "David Navarro" <[email-masked]>
Date: Wed, 11 Jan 2017 16:51:21 +0100

Hi Michael,

I agree there is currently no risk of collision. However I think it would be
better to avoid future problem while we can.
For instance one may imagine a lifetime attribute in an observation request
so that this observation is automatically cancelled by the server.

/sensor/temperature/value?lt=10&gt=30&lt=86400

Regards,
David Navarro

-----Message d'origine-----
De : core [mailto:[email-masked]] De la part de Michael Koster
Envoyé : mercredi 11 janvier 2017 15:46
À : Hannes Tschofenig <[email-masked]>
Cc : [email-masked] WG <[email-masked]>
Objet : Re: [core] Lifetime (lt) and Less Than (lt)

Hi Hannes,

I don't think there would ever be a situation where you would use them in
the same request, so I don't think we need to change either one.

/example/sensor/a
/example/sensor/b

/rd?lt=100

Does this make sense?

Best regards,

Michael
> https://tools.ietf.org/html/draft-ietf-core-dynlink-01 uses lt for 
> Less Than.
>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 11 Jan 2017 17:08:29 +0100

I am afraid that I agree with David.
could we distinguish with capitals, lifetime is LT?

Peter

David Navarro schreef op 2017-01-11 16:51:
>> On Jan 11, 2017, at 6:03 AM, Hannes Tschofenig 
>> <[email-masked]>
> wrote:
>> 
>> Hi all,
>> 
>> I noticed that

---

From: Michael Koster <[email-masked]>
Date: Wed, 11 Jan 2017 08:19:51 -0800

Hi Peter

I believe URI parameters are not allowed to be case sensitive. Use of case is not recommended in general as it's still LT.

Best regards,

Michael

> On Jan 11, 2017, at 8:08 AM, peter van der Stok <[email-masked]> wrote:
>

---

From: "David Navarro" <[email-masked]>
Date: Wed, 11 Jan 2017 17:25:11 +0100

Hi,

What about 'lft' for lifetime ?

Regards,
David Navarro

-----Message d'origine-----
De : Michael Koster [mailto:[email-masked]] 
Envoyé : mercredi 11 janvier 2017 17:20
À : [email-masked]
Cc : David Navarro <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Objet : Re: [core] Lifetime (lt) and Less Than (lt)

Hi Peter

Best regards,

Michael

>> I agree there is currently no risk of collision. However I think it 
>> would be better to avoid future problem while we can.
>> For instance one may imagine a lifetime attribute in an observation 
>> request so that this observation is automatically cancelled by the server.
>> Envoyé : mercredi 11 janvier 2017 15:46 À : Hannes Tschofenig 
>> <[email-masked]> Cc : [email-masked] WG <[email-masked]> 
>> Objet : Re: [core] Lifetime (lt) and Less Than (lt) Hi Hannes, I 
>> never noticed that before!
>> I don't think there would ever be a situation where you would use 
>> them in the same request, so I don't think we need to change either one.
>>> https://tools.ietf.org/html/draft-ietf-core-resource-directory-09 
>>> uses the parameter lt for lifetime and

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Jan 2017 17:47:12 +0100

On 11 Jan 2017, at 17:19, Michael Koster <[email-masked]> wrote:
> 
> I believe URI parameters are not allowed to be case sensitive.

They sure are (how would you do base64 otherwise?)

> Use of case is not recommended in general as it's still LT.

I think the attempt to do case-insensitive got out of fashion with FORTRAN 66.
(Yes, we still have it for domain names, but these aren’t that much younger :-)

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Wed, 11 Jan 2017 08:55:57 -0800

OK sorry, I was thinking about this in RFC6690 which refers to something a little different:

reg-rel-type   = LOALPHA *( LOALPHA / DIGIT / "." / "-" )

I still would not recommend only changing the case to differentiate.

Carsten, do you think this is a potential conflict and should be changed?

Best regards,

Michael

PS
FORTRAN66? I'm not that much younger either ;-) CamelCase is going out of style anyway

> On Jan 11, 2017, at 8:47 AM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Jan 2017 18:02:12 +0100

> On 11 Jan 2017, at 17:55, Michael Koster <[email-masked]> wrote:
> 
> reg-rel-type   = LOALPHA *( LOALPHA / DIGIT / "." / "-“ )

Right, this (only allowing lower case) was probably done to evade the question of case-sensitivity.  It is still compatible with the case-sensitive millennium were are living in :-)
(And it is for relation-types, while we were talking about URI-query prefixes, IIRC.)

> I still would not recommend only changing the case to differentiate.

I’m actually with you on that point.  Just wanted to curb as early as possible any potential myth-building about CoAP being case-insensitive in some way.

> Carsten, do you think this is a potential conflict and should be changed?

(If this = “lt" for both lifetime and less-than:)

Well, it is certainly unfortunate.  It seems it will not confuse the machines, so we don’t HAVE to fix it, but it might confuse humans, which are even more important.  If none of these specifications were in actual use, I’d try to change it.  Do we still have the liberty?

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Wed, 11 Jan 2017 09:24:24 -0800

I believe LWM2M uses both registration lifetime and conditional notification less than parameters. David or Hannes could confirm.

There is no issue with OCF

Best regards, 

Michael

> On Jan 11, 2017, at 9:02 AM, Carsten Bormann <[email-masked]> wrote:
> 
>

---

From: "David Navarro" <[email-masked]>
Date: Wed, 11 Jan 2017 18:36:27 +0100

Yes both are used in LwM2M but the OMA DM WG is willing to remove the possible confusion.

As I wrote earlier, an hypothetical future confusion could be a lifetime attribute in an observation request so that this observation is automatically cancelled by the server:
/sensor/temperature/value?lt=10&gt=30&lft=86400
Meaning "I want notifications when the temperature crosses the 10C or the 30C threshold during the next 24 hours.
 
Regards,
David Navarro

-----Message d'origine-----
De : core [mailto:[email-masked]] De la part de Michael Koster
Envoyé : mercredi 11 janvier 2017 18:24
À : Carsten Bormann <[email-masked]>
Cc : [email-masked]
Objet : Re: [core] Lifetime (lt) and Less Than (lt)

Best regards, 

Michael

> Right, this (only allowing lower case) was probably done to evade the 
> question of case-sensitivity.  It is still compatible with the 
> case-sensitive millennium were are living in :-) (And it is for 
> relation-types, while we were talking about URI-query prefixes, IIRC.)
>

---

From: Michael Koster <[email-masked]>
Date: Wed, 11 Jan 2017 11:44:02 -0800

If we must change something, I would recommend changing the conditional notification parameter instead. 

I think there is likely to be less impact changing dynlink vs. changing RD. I think there are more implementations of RD that would be affected.

Also if we intend to have a policy of not reusing identifiers, should we have a registry of CoAP query parameters?

Best regards,

MIchael

> On Jan 11, 2017, at 9:36 AM, David Navarro <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jan 2017 21:46:37 +0100

Hi Michael,

> I think there is likely to be less impact changing dynlink vs. changing RD. I think there are more implementations of RD that would be affected.

I don't have an opinion about this aspect.

> Also if we intend to have a policy of not reusing identifiers, should we have a registry of CoAP query parameters?

I believe a registry for the parameters would be useful.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Jan 2017 00:07:13 +0100

> I believe a registry for the parameters would be useful.

If we think that is useful, we could do this informally, as in

https://svn.tools.ietf.org/svn/wg/core/registry.txt

This would mean we don’t have to wait for an IANA process, which might be too heavyweight for this.

Grüße, Carsten

---

From: Christian Groves <[email-masked]>
Date: Mon, 16 Jan 2017 13:13:21 +1100

Hello,

Changing lt in dynlink is easy enough for me to do. It seems to be the 
better choice than changing lt in RD as the dynlink draft isn't as far 
along as the RD draft. As LWM2M is the only "official" usage it probably 
comes down to which instance they'd like to change?

With respect to the registry I agree this would be useful. I tend to 
favour the IANA rather than the formal informal approach as its more 
visible but I don't have a strong preference.

Regards, Christian.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jan 2017 08:42:06 +0100

On 16 Jan 2017, at 03:13, Christian Groves <[email-masked]> wrote:
> 
> Changing lt in dynlink is easy enough for me to do. It seems to be the better choice than changing lt in RD as the dynlink draft isn't as far along as the RD draft. As LWM2M is the only "official" usage it probably comes down to which instance they'd like to change?

Right.

If we want to change lt there, we probably should change gt as well.
The pair of .LT. and .GT. has been with us as a representation of “<“ and “>" since FORTRAN II.
(There already is a bit of a surprise why there is no .LE. or .GE. — are notification thresholds always exclusive?)

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Tue, 17 Jan 2017 12:37:03 -0800

> On Jan 15, 2017, at 11:42 PM, Carsten Bormann <[email-masked]> wrote:
> 

Some observations:

I think in general equality is a weaker concept in systems without naturally occuring values.

However, there are naturally occuring values we see frequently in the systems we are building; these are the minimum and maximum scale values frequently represented by 0 and 100, respectively.

It seems to me that le and ge would be more useful, simply by being able to express le=0 and ge=100, where I only want to know if the scale limit is reached

In quantized linear systems it seems like the concepts gt and lt could be synthesized using ge and le

lt=0 and gt=100 do not have any useful meaning other than an roundabout disable mechanism.

Best regards,

Michael

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Jan 2017 17:05:37 +1100

The band parameters we've previously discussed are essentially <= and >=.

So if we rename the parameters what do people prefer?

let, grt or
lth, gth or
something else?

Regards, Christian

On 18/01/2017 7:37 AM, Michael Koster wrote:
>
>> On Jan 15, 2017, at 11:42 PM, Carsten Bormann <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> (There already is a bit of a surprise why there is no .LE. or .GE. — 
>> are notification thresholds always exclusive?)
>>
>
> Some observations:
>
> However, there are naturally occuring values we see frequently in the 
> systems we are building; these are the minimum and maximum scale 
> values frequently represented by 0 and 100, respectively.
>
> It seems to me that le and ge would be more useful, simply by being 
> able to express le=0 and ge=100, where I only want to know if the 
> scale limit is reached
>