Subject: [clue] Framework, level of mandation for providing dimensions

From: Stephan Wenger <[email-masked]>
Date: Mon, 29 Dec 2014 02:35:18 +0000

Hi,

Mark and I are editing the framework document to address comments.
This is with reference to my review, dated 12/16/2014, and specifically point 4 therein, reproduced as follows:

4. Page 15, MUST strength for providing physical dimensions of known to the system.  I like this philosophically, but I think it's meaningless in practice, as the knowledge of coordinates of a pProvider is known to the consumer only as a side effect of sending  the measurements, right?  Perhaps less draconian language is more appropriate?  Sounds to me like a good place for a "SHOULD"?

Unless someone objects the two MUST statements in section 6, second bullet (page 15) will be replaced with less draconian SHOULD.  The modified bullet in markup is shown below.

I suggest a deadline of January 9, 2015, but do so without checking with the chairs-who are of course free to set a different date if they choose so.

Regards,
Stephan

 o  Coordinates can be either in real, physical units (millimeters),
      have an unknown scale or have no physical scale.  Systems which
      know their physical dimensions (for example professionally
      installed Telepresence room systems) MUST SHOULD always provide those
      real-world measurements.  Systems which don't know specific
      physical dimensions but still know relative distances MUST SHOULD use
      'unknown scale'.  'No scale' is intended to be used where Media
      Captures from different devices (with potentially different
      scales) will be forwarded alongside one another (e.g. in the
      case of an MCU).

---

From: "Roni Even" <[email-masked]>
Date: Mon, 29 Dec 2014 12:46:11 +0200

Hi Stephan,

I am not sure what is the difference here between a MUST and a SHOULD. Since
it is required to send the scale value in the data model
(https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section-15
.4 ), what is the SHOULD here? 

Roni Even

As individual

From: clue [mailto:[email-masked]] On Behalf Of Stephan Wenger
Sent: 29 December, 2014 4:35 AM
To: CLUE
Subject: [clue] Framework, level of mandation for providing dimensions

Hi,

This is with reference to my review, dated 12/16/2014, and specifically
point 4 therein, reproduced as follows:

4. Page 15, MUST strength for providing physical dimensions of known to the
system.  I like this philosophically, but I think it's meaningless in
practice, as the knowledge of coordinates of a pProvider is known to the
consumer only as a side effect of sending  the measurements, right?  Perhaps
less draconian language is more appropriate?  Sounds to me like a good place
for a "SHOULD"?

Unless someone objects the two MUST statements in section 6, second bullet
(page 15) will be replaced with less draconian SHOULD.  The modified bullet
in markup is shown below.

I suggest a deadline of January 9, 2015, but do so without checking with the
chairs-who are of course free to set a different date if they choose so.

Regards,

Stephan

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Dec 2014 10:05:00 -0500

On 12/28/14 9:35 PM, Stephan Wenger wrote:
> 4. Page 15, MUST strength for providing physical dimensions of known to
> the system.  I like this philosophically, but I think it’s meaningless
> in practice, as the knowledge of coordinates of a pProvider is known to
> the consumer only as a side effect of sending  the measurements, right?
>   Perhaps less draconian language is more appropriate?  Sounds to me
> like a good place for a “SHOULD”?
>
> Unless someone objects the two MUST statements in section 6, second
> bullet (page 15) will be replaced with less draconian SHOULD.  The
> modified bullet in markup is shown below.

I think this is fine but, as always, some guidance should be given about 
what constitutes adequate justification for violating the SHOULD.

	Thanks,
	Paul

> I suggest a deadline of January 9, 2015, but do so without checking with
> the chairs—who are of course free to set a different date if they choose so.
> Regards,
> Stephan
>
>        installed Telepresence room systems)MUST  _SHOULD_  always provide those
>        physical dimensions but still know relative distancesMUST  _SHOULD_  use
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Dec 2014 10:10:32 -0500

On 12/29/14 5:46 AM, Roni Even wrote:
> Hi Stephan,
>
> I am not sure what is the difference here between a MUST and a SHOULD.
> Since it is required to send the scale value in the data model
> (https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section-15.4
> ), what is the SHOULD here?

I guess it really isn't necessary to have any normative language about 
items that are required in the data model schema. The normative language 
ought to focus on those places where there is a choice - in this case 
when it makes sense to use noscale, unknown, and mm. Language about that 
is already in the data model, but isn't normative. But it is clear 
enough, so maybe all is good.

	Thanks,
	Paul

> Roni Even
>
> As individual
>
> *From:*clue [mailto:[email-masked]] *On Behalf Of *Stephan Wenger
> *Sent:* 29 December, 2014 4:35 AM
> *To:* CLUE
> *Subject:* [clue] Framework, level of mandation for providing dimensions
>
> Hi,
>

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 29 Dec 2014 17:26:11 +0000

>enough, so maybe all is good.

The reason of the ³SHOULD² is that a ³MUST² is unsupervisable and
unenforcible.

The language in the framework stated that a system MUST include
measurements when they are known.  So suppose you have a system that is
all measured in, values entered through config files or UI, and whatnot,
ready to go.  How does a remote system know that?  It doesn¹t.  It only
knows it once it sees the measurements on the wire.  If the measured-in
endpoint decides not to send those measurement because it rains, because
it¹s Monday, or because it has somehow identified the remote system to be
from a competitor and does not want to send the best possible media to
make that remote system look bad, there is nothing anyone could do.  Or
identify the sender as broken, based on bits on the wire.

I think that it is good practice in system level standards (and generally
widely followed) not to provide hard MUSTs (or shalls or whatever) for
unsupervisable and unenforcible properties.

The data model statement is different, I think.  If I understand it
correctly, the data model simply requires the measurements to be signaled
when a certain mode is signaled.  That¹s all fine.

Clearer?

Stephan

>> the system.  I like this philosophically, but I think it¹s meaningless
>> like a good place for a ³SHOULD²?
>>
>> the chairs‹who are of course free to set a different date if they
>>choose so.
>>
>> Regards,
>>
>> Stephan
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Dec 2014 12:32:28 -0500

> when a certain mode is signaled.  That¹s all fine.

I think you are making the case that this shouldn't be normative. So 
instead of MUST or SHOULD, use "should". And that is what is already 
done in the data model.

	Thanks,
	Paul

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 29 Dec 2014 17:36:39 +0000

A non-normative “should” would work for me.
Stephan

On 12/29/14, 09:32, "Paul Kyzivat" <[email-masked]> wrote:

>>>>(https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#secti
>>>>on
>>>> -15.4

---

From: "Roni Even" <[email-masked]>
Date: Mon, 29 Dec 2014 20:51:30 +0200

Hi,
The whole idea of the telepresence work was to provide the required information that will allow for optimal user experience and to standardize it.
Saying that one vendor will want to ignore it to make the other system bad is missing this target and it will be better to have such system as non-compliant.

The texts states the cases for using each of the options so you must have a reason to send no scale. The data model requires you to provide the information. 

So non-normative at all may look good but I am not sure if it means something at all. I expect that the framework will provide guidelines and normative language to make the best user experience and this attribute is about it

Roni

> -----Original Message-----
> Sent: 29 December, 2014 7:37 PM
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [clue] Framework, level of mandation for providing dimensions
> 
> >>> I guess it really isn't necessary to have any normative language
> >>>about  items that are required in the data model schema. The
> >>>normative language  ought to focus on those places where there is a
> >>>choice - in this case  when it makes sense to use noscale, unknown,
> >>>and mm. Language about that  is already in the data model, but isn't
> >>>normative. But it is clear  enough, so maybe all is good.
> >>
> >>measurements when they are known.  So suppose you have a system that
> >>is  all measured in, values entered through config files or UI, and
> >>whatnot,  ready to go.  How does a remote system know that?  It
> >>doesn¹t.  It only  knows it once it sees the measurements on the wire.
> >>If the measured-in  endpoint decides not to send those measurement
> >>because it rains, because  it¹s Monday, or because it has somehow
> >>identified the remote system to be  from a competitor and does not
> >>want to send the best possible media to  make that remote system look
> >>bad, there is nothing anyone could do.  Or  identify the sender as
> >>broken, based on bits on the wire.
> >>
> >> I think that it is good practice in system level standards (and
> >>generally  widely followed) not to provide hard MUSTs (or shalls or
> >>whatever) for  unsupervisable and unenforcible properties.
> >>
> >>correctly, the data model simply requires the measurements to be
> >>signaled  when a certain mode is signaled.  That¹s all fine.
> >
> >>>> This is with reference to my review, dated 12/16/2014, and
> >>>>specifically  point 4 therein, reproduced as follows:
> >>>>
> >>>> 4. Page 15, MUST strength for providing physical dimensions of
> >>>>known to  the system.  I like this philosophically, but I think it¹s
> >>>>meaningless  in practice, as the knowledge of coordinates of a
> >>>>pProvider is known to  the consumer only as a side effect of sending
> >>>>the measurements, right?
> >>>>    Perhaps less draconian language is more appropriate?  Sounds to
> >>>>me  like a good place for a ³SHOULD²?
> >>>>
> >>>> I suggest a deadline of January 9, 2015, but do so without checking
> >>>>with  the chairs‹who are of course free to set a different date if
> >>>>they  choose so.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Stephan
> >>>>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 30 Dec 2014 18:38:24 +0000

Hi Roni,

On 12/29/14, 10:51, "Roni Even" <[email-masked]> wrote:

>Hi,
>The whole idea of the telepresence work was to provide the required
>information that will allow for optimal user experience and to
>standardize it.

Ok, that’s a solid argument.  And it’s by no means a novelty that the IETF
specifies things that industry will occasionally ignore.  I’m fine
reverting back to MUST (meaning: no change from what was in -19).

Stephan

>Saying that one vendor will want to ignore it to make the other system
>bad is missing this target and it will be better to have such system as
>non-compliant.
>
>The texts states the cases for using each of the options so you must have
>a reason to send no scale. The data model requires you to provide the
>information. 
>
>So non-normative at all may look good but I am not sure if it means
>something at all. I expect that the framework will provide guidelines and
>normative language to make the best user experience and this attribute is
>about it
>
>Roni
>