Subject: [clue] WGLC on draft-ietf-clue-data-model-schema-09 - reminder

From: "Roni Even" <[email-masked]>
Date: Mon, 8 Jun 2015 00:00:00 +0300

Hi,

The WG chairs would like to start a WGLC on
https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-09

To allow enough time we will have it as a long one.

The WGLC will end by June 10th .

At the last IETF mating Dan Burnett, Rob Hansen and Paul Kyzivat volunteered
to review the document.

Please also verify the consistency with the CLUE framework document.

Thanks

Roni Even

CLUE WG co-chair

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Jun 2015 15:54:16 -0400

I'm sorry for being so tardy in providing a review of this document. I 
just now went through it:

* Section 2:

Capture Device: says it converts audio and video. Should probably also 
mention text.

MCC: I can't quite make sense of the this part: "... the Stream coming 
from the encoding of the composing Media Captures ...". I *think* the 
intent can be achieved by replacing that with "... the contained media 
captures ...".

Spatial Information: s/generate/generates/, s/phisical/physical/

* Section 3:

General: I'm not an xml expert. I see odds and ends of formatting 
idiosyncracies that seem odd to me, though clearly simply editor 
choices. I will not mention those. It might be good for somebody who 
isn't an author but is an XML expert to review the schema for style. Or 
perhaps it can be run through an XML pretty-printer.

In the following:

    The element and attribute definitions are formal representations of
    the concepts needed to describe the capabilities of a Media Provider
    and the streams that are requested by a Media Consumer given the
    Media Provider's ADVERTISEMENT ([I-D.ietf-clue-protocol]).

s/requested/available to be requested/

Policy for MCCs: is just a string. How are we going to specify the 
available policies?

MEDIA CAPTURE TYPE: Language is currently optional, but with max of one. 
Shouldn't multiple languages be allowed?

MEDIA CAPTURE TYPE: "mediaType" is just a string. How are we going to 
specify the available media types?

PERSON TYPE: I know we discussed this before, but I still find it 
disturbing that we have a complexType named "personType" that contains 
an element named "personType". I guess it is syntactically and 
semantically well defined, but it is certainly confusing to read the 
schema. I would expect to get confusion in the future. I suggest 
replacing personTypeType with personRoleType or personJobType or 
personDutyType, and then change the element name to match. (I recall 
there were reasons not to use Role.)

SPATIAL INFORMATION TYPE: Syntactically this allows you to provide 
spatial information yet omit both the capturePoint and the captureArea. 
IIUC it is an error to specify neither. (Should have then specified 
non-spatially-defined.) Can the XML be structured to prevent this misuse?

MOBILITY TYPE: having "dynamic" and "highly-dynamic" seems confusing. 
How about "variable" and "dynamic"?

OTHER CAPTURE TYPE: why doesn't this look exactly like TEXT CAPTURE 
TYPE? (It differs by omission of anyAttribute.)

CAPTURE POINT TYPE: it still seems odd to me to call this a *point* when 
it actually can define a vector. How about "captureVector"? Or, since 
the part that makes it a vector is optional, maybe "captureOrigin".

ENCODING ID LIST TYPE: this defined encID. Presumably this is intended 
to refer to the "encodingID" elementof captureEncodingType. Is that 
correspondence specified somewhere? Is there a reason not to use the 
IDREF mechanism? (Does the idref only work in a single document, while 
this needs to work from a configure toward an advertisement?)

* Section 10.1:

It would be helpful to say that the captureID serves as the way the 
capture is referenced from CaptureEncodings created by the consumer in 
Configure messages.

* Section 10.5.2:

It would be helpful to note that the capture area has two "sides", and 
it implies which side is the "front". (The capture point must be on the 
side from which it is possible to view the left points as left of the 
right points, and the top points as above the bottom points.)

* Section 10.8:

This says "... captures coming from the same source." But I think it is 
possible for switching to include multiple sources concurrently. So I 
think that needs to be changed to "... same sources.".

Also, in this section what is "MP"? I guess it means Media Provider? 
Either this should be added to the definitions, or it should be 
expanded. (Note that this is also used elsewhere.)

* Section 10.16:

It would be good to specify the semantics attaching to each value. I.e.:

static: SHOULD not change for the duration of the CLUE session, across 
multiple advertisements.

dynamic: MAY change in each new advertisement. Can be assumed to remain 
unchanged until there is a new advertisement.

highly-dynamic: MAY change dynamically, even between advertisements. The 
value in an advertisement is simply a snapshot of the location at the 
time of the advertisement.

* Section 21:

While this may repeat the framework, I think this section should explain 
the the references in the captureEncoding are to captures and encodings 
defined in a separate XML document (an advertisement).

* Section 22:

What is "a drafty version" intended to mean???

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 10 Jun 2015 20:30:57 +0300

Hi,
With my chair hat on, I asked for a review from the XML directorate but so
far they were unable to find someone to reveiew.
This is a pity

> idiosyncracies that seem odd to me, though clearly simply editor choices.
I will
> not mention those. It might be good for somebody who isn't an author but
is an
> XML expert to review the schema for style. Or perhaps it can be run
through an
> XML pretty-printer.

Roni Even
CLUE co-chair

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 16 Jun 2015 14:00:19 -0700

I have a few comments on Paul's comments.  I'm including here only the parts of Paul's message I am commenting on.
Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, June 09, 2015 3:54 PM
> To: CLUE
> Subject: [clue] Paul's WGLC review of draft-ietf-clue-data-model-schema-09
>
> * Section 3:
> 
> In the following:
> 
[Duckworth, Mark] I thought it was referring to a Consumer's configure message, so it would be the streams requested by a consumer.

> Policy for MCCs: is just a string. How are we going to specify the
[Duckworth, Mark] Good question.  Two policies are described in the framework: SoundLevel and RoundRobin.  It also includes an index, which in the data model examples is just tacked on to the end of the string like "SoundLevel:1".  I think the data model should be more explicit about the allowed values for MCC <policy>.

> Shouldn't multiple languages be allowed?
[Duckworth, Mark] Yes, the framework says it could be one or more languages.

> specify the available media types?
[Duckworth, Mark] It is defined in section 10.2

> an element named "personType".
[Duckworth, Mark] I think you are mistaken.  I see a complexType "peopleType", which contains element "personType", which then contains "personTypeType".

>  I guess it is syntactically and
[Duckworth, Mark] Either keeping it as is, or change the name of personTypeType is okay with me.

> right points, and the top points as above the bottom points.)
[Duckworth, Mark] I agree.  The captureArea contains this information even if capturePoint is not defined.

---

From: "Roni Even" <[email-masked]>
Date: Sat, 20 Jun 2015 11:06:39 +0300

Hi, 
Looking at Paul's comments I would like to add
Roni

> Policy for MCCs: is just a string. How are we going to specify the
available
> policies?
[Roni Even] According to the framework it is a token - need to be like the
framework

> Shouldn't multiple languages be allowed?
[Roni Even] Also Where is "language" defined?
> specify the available media types?
[Roni Even] I assume it is based on the "mediaCaptureType" we have audio,
video, other for extensibility
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Roberta Presta <[email-masked]>
Date: Tue, 23 Jun 2015 12:55:00 +0200

Dear all,
we are applying the modifications derived by your comments.
These are the first ones coming from Paul's review.
We considered also Mark's reply to Paul to answer as in the following.
Regards,

Roberta

> Capture Device: says it converts audio and video. Should probably also 

OK. Definition replaced with the one in the framework.

> intent can be achieved by replacing that with "... the contained media 

OK. Replaced with "contained media captures”.

> Spatial Information: s/generate/generates/, s/phisical/physical/

OK.

> isn't an author but is an XML expert to review the schema for style. 
> Or perhaps it can be run through an XML pretty-printer.
>

OK.

> s/requested/available to be requested/

I left "are requested" since the intention was the one detected by Mark 
in answering Paul's review.
("[Duckworth, Mark] I thought it was referring to a Consumer's configure 
message, so it would be the streams requested by a consumer.")

> Policy for MCCs: is just a string. How are we going to specify the 

OK. We added a regular expression to define the content of the <policy> 
element in the form of "token:index".

<xs:simpleType name="policyType">
  <xs:restriction base="xs:string">
       <xs:pattern value="([a-zA-Z0-9])+[:]([0-9])+"/>
     </xs:restriction>
</xs:simpleType>

> MEDIA CAPTURE TYPE: Language is currently optional, but with max of 
> one. Shouldn't multiple languages be allowed?
>

OK. XML Schema definition updated (maxOccurs="unbounded”).

> specify the available media types?

As highlighted by Mark, it is defined in section 10.2 of the document. 
Audio, video and text are just examples of valid media types. We did 
  not want to put any constraints on the set of possible media types.

> there were reasons not to use Role.)

I am OK with any change (e.g., from <personType> to <personRole>), but 
the Framework document should be changed accordingly. Our preferred 
option is to leave things as they are, btw.

> spatial information yet omit both the capturePoint and the 
> captureArea. IIUC it is an error to specify neither. (Should have then 
> specified non-spatially-defined.) Can the XML be structured to prevent 
> this misuse?
>

This is actually specified in the text, rather than formally specified 
in the XML schema.
*
*
> How about "variable" and "dynamic"?

This is indeed how mobility type has been defined in the Framework 
document. We’re OK with modifying such a definition, but framework 
should be changed accordingly.

> TYPE? (It differs by omission of anyAttribute.)

Actually, they do look identical in the current version of the document.

> CAPTURE POINT TYPE: it still seems odd to me to call this a *point* 
> when it actually can define a vector. How about "captureVector"? Or, 
> since the part that makes it a vector is optional, maybe "captureOrigin".
>

I am OK with captureOrigin. Does everybody agree?

> this needs to work from a configure toward an advertisement?)

Actually, in the definition of <encodingIDList>, the type of <encID> is 
IDREF.

> capture is referenced from CaptureEncodings created by the consumer in 

OK. Text added.

> it implies which side is the "front". (The capture point must be on 
> the side from which it is possible to view the left points as left of 
> the right points, and the top points as above the bottom points.)
>

OK, we added: "The four coplanar points are identified from the 
perspective of the capture device.”

> * Section 10.8:
>
> This says "... captures coming from the same source." But I think it 
> is possible for switching to include multiple sources concurrently. So 
> I think that needs to be changed to "... same sources.".
>

OK.

> expanded. (Note that this is also used elsewhere.)

OK. Expanded everywhere.

> dynamic: MAY change in each new advertisement. Can be assumed to 
> remain unchanged until there is a new advertisement.
>
> highly-dynamic: MAY change dynamically, even between advertisements. 
> The value in an advertisement is simply a snapshot of the location at 
> the time of the advertisement.
>

OK. Text added.

> * Section 21:
>
> While this may repeat the framework, I think this section should 
> explain the the references in the captureEncoding are to captures and 
> encodings defined in a separate XML document (an advertisement).
>

OK. Done.

> What is "a drafty version" intended to mean???

Replaced with:
The <clueInfo> element includes all the information needed to represent 
the Media Provider's description of its telepresence capabilities 
according to the CLUE framework (i.e., it actually represents the body 
of the ADVERTISEMENT message).

>     Paul

----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITÀ DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 23 Jun 2015 08:02:35 -0700

I think renaming the <capturePoint> element to <captureOrigin> makes sense.  I suppose capturePointType will then become captureOriginType.
Mark

From: clue [mailto:[email-masked]] On Behalf Of Roberta Presta
Sent: Tuesday, June 23, 2015 6:55 AM
To: [email-masked]
Subject: Re: [clue] Paul's WGLC review of draft-ietf-clue-data-model-schema-09

Dear all,

Roberta

Il 09/06/2015 21:54, Paul Kyzivat ha scritto:
I'm sorry for being so tardy in providing a review of this document. I just now went through it:

* Section 2:

Capture Device: says it converts audio and video. Should probably also mention text.

MCC: I can't quite make sense of the this part: "... the Stream coming from the encoding of the composing Media Captures ...". I *think* the intent can be achieved by replacing that with "... the contained media captures ...".

OK. Replaced with "contained media captures".

OK.

* Section 3:

General: I'm not an xml expert. I see odds and ends of formatting idiosyncracies that seem odd to me, though clearly simply editor choices. I will not mention those. It might be good for somebody who isn't an author but is an XML expert to review the schema for style. Or perhaps it can be run through an XML pretty-printer.

OK.

In the following:

I left "are requested" since the intention was the one detected by Mark in answering Paul's review.
("[Duckworth, Mark] I thought it was referring to a Consumer's configure message, so it would be the streams requested by a consumer.")

Policy for MCCs: is just a string. How are we going to specify the available policies?

OK. We added a regular expression to define the content of the <policy> element in the form of "token:index".

MEDIA CAPTURE TYPE: Language is currently optional, but with max of one. Shouldn't multiple languages be allowed?

OK. XML Schema definition updated (maxOccurs="unbounded").

MEDIA CAPTURE TYPE: "mediaType" is just a string. How are we going to specify the available media types?

As highlighted by Mark, it is defined in section 10.2 of the document. Audio, video and text are just examples of valid media types. We did  not want to put any constraints on the set of possible media types.

PERSON TYPE: I know we discussed this before, but I still find it disturbing that we have a complexType named "personType" that contains an element named "personType". I guess it is syntactically and semantically well defined, but it is certainly confusing to read the schema. I would expect to get confusion in the future. I suggest replacing personTypeType with personRoleType or personJobType or personDutyType, and then change the element name to match. (I recall there were reasons not to use Role.)

I am OK with any change (e.g., from <personType> to <personRole>), but the Framework document should be changed accordingly. Our preferred option is to leave things as they are, btw.

SPATIAL INFORMATION TYPE: Syntactically this allows you to provide spatial information yet omit both the capturePoint and the captureArea. IIUC it is an error to specify neither. (Should have then specified non-spatially-defined.) Can the XML be structured to prevent this misuse?

This is actually specified in the text, rather than formally specified in the XML schema.

MOBILITY TYPE: having "dynamic" and "highly-dynamic" seems confusing. How about "variable" and "dynamic"?

This is indeed how mobility type has been defined in the Framework document. We're OK with modifying such a definition, but framework should be changed accordingly.

OTHER CAPTURE TYPE: why doesn't this look exactly like TEXT CAPTURE TYPE? (It differs by omission of anyAttribute.)

CAPTURE POINT TYPE: it still seems odd to me to call this a *point* when it actually can define a vector. How about "captureVector"? Or, since the part that makes it a vector is optional, maybe "captureOrigin".

ENCODING ID LIST TYPE: this defined encID. Presumably this is intended to refer to the "encodingID" elementof captureEncodingType. Is that correspondence specified somewhere? Is there a reason not to use the IDREF mechanism? (Does the idref only work in a single document, while this needs to work from a configure toward an advertisement?)

Actually, in the definition of <encodingIDList>, the type of <encID> is IDREF.

* Section 10.1:

It would be helpful to say that the captureID serves as the way the capture is referenced from CaptureEncodings created by the consumer in Configure messages.

OK. Text added.

* Section 10.5.2:

It would be helpful to note that the capture area has two "sides", and it implies which side is the "front". (The capture point must be on the side from which it is possible to view the left points as left of the right points, and the top points as above the bottom points.)

OK, we added: "The four coplanar points are identified from the perspective of the capture device."

* Section 10.8:

This says "... captures coming from the same source." But I think it is possible for switching to include multiple sources concurrently. So I think that needs to be changed to "... same sources.".

OK.

Also, in this section what is "MP"? I guess it means Media Provider? Either this should be added to the definitions, or it should be expanded. (Note that this is also used elsewhere.)

OK. Expanded everywhere.

* Section 10.16:

static: SHOULD not change for the duration of the CLUE session, across multiple advertisements.

dynamic: MAY change in each new advertisement. Can be assumed to remain unchanged until there is a new advertisement.

highly-dynamic: MAY change dynamically, even between advertisements. The value in an advertisement is simply a snapshot of the location at the time of the advertisement.

OK. Text added.

* Section 21:

While this may repeat the framework, I think this section should explain the the references in the captureEncoding are to captures and encodings defined in a separate XML document (an advertisement).

OK. Done.

* Section 22:

Replaced with:
The <clueInfo> element includes all the information needed to represent the Media Provider's description of its telepresence capabilities according to the CLUE framework (i.e., it actually represents the body of the ADVERTISEMENT message).

    Thanks,
    Paul

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

----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille<http://www.unina.it/Vademecum5permille>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Jun 2015 15:35:01 -0400

> We considered also Mark's reply to Paul to answer as in the following.

Thanks Roberta! In general these look good. I have a few followup 
comments. I'm trimming out all the other stuff.

> message, so it would be the streams requested by a consumer.")

OK. I just misinterpreted.

>        <xs:pattern value="([a-zA-Z0-9])+[:]([0-9])+"/>

But which values are to be supported, what are the semantics of each, 
and how is that set extended?

I'm comfortable with registries because I understand them, so I would be 
happy with an iana registry. But I guess that xml may have other ways to 
handle this. (E.g. an enumeration. Could such a thing be extended via 
definitions in another namespace?)

>   not want to put any constraints on the set of possible media types.

The text in 10.2 appears to be an *example*, and the "..." isn't very 
normative. What is the full range of possible values?

One possibility is to reference RFC4566 for the definition used for the 
m-line.

But I think we would need additional clue specifications to support more 
than audio/video/text. So we might want to say that *this* spec only 
covers audio/video/text, but it may be extended in the future to cover 
additional types allowed by RFC4566, and that receivers MUST be able to 
accept (and presumably ignore) advertisements that contain others that 
they don't understand.

> option is to leave things as they are, btw.

My opinion remains, but it is just my opinion. So unless others sign on 
to support me it should stay as it is.

> should be changed accordingly.

Mark? Others?

> Actually, in the definition of <encodingIDList>, the type of <encID> is

My confusion is because the definition of <encodingIDListType> in the 
full schema in section 3 is *different* that the definition of 
<encodingIDListType> in section 17.2. (The one in 17.2 references IDREF, 
but the one in section 3 does not.) I presume they are intended to be 
the same.

I guess this points up a need to verify that *all* the snippets of xml 
schema throughout the document are consistent with full schema in 
section 3. (I didn't do that.)

That's all.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 23 Jun 2015 16:30:28 -0700

> Sent: Tuesday, June 23, 2015 3:35 PM
> To: [email-masked]
> > document. We're OK with modifying such a definition, but framework
 
I don't think it's confusing.  I'd rather keep it the way it is.  But if the group wants to change it, I wouldn't object too much.

Mark

---

From: Christian Groves <[email-masked]>
Date: Wed, 24 Jun 2015 11:39:31 +1000

> I don't think it's confusing.  I'd rather keep it the way it is.  But if the group wants to change it, I wouldn't object too much.
I'm for keeping the way it is. We've already gone through WGLC on the 
framework where the names for attributes were first assigned. We didn't 
change the names/values then so I think we should leave them be.

Regards, Christian

---

From: "Roni Even" <[email-masked]>
Date: Fri, 26 Jun 2015 15:33:21 +0300

Hi,

About the xml for 

<xs:attribute name="lang" type="xs:language"/>

 - where is type language defined? I did not see it in
http://www.w3.org/2001/XMLSchema

Roni

From: clue [mailto:[email-masked]] On Behalf Of Roberta Presta
Sent: 23 June, 2015 1:55 PM
To: [email-masked]
Subject: Re: [clue] Paul's WGLC review of
draft-ietf-clue-data-model-schema-09

Dear all, 

Roberta

I'm sorry for being so tardy in providing a review of this document. I just
now went through it: 

* Section 2: 

MCC: I can't quite make sense of the this part: "... the Stream coming from
the encoding of the composing Media Captures ...". I *think* the intent can
be achieved by replacing that with "... the contained media captures ...". 

OK.

* Section 3: 

General: I'm not an xml expert. I see odds and ends of formatting
idiosyncracies that seem odd to me, though clearly simply editor choices. I
will not mention those. It might be good for somebody who isn't an author
but is an XML expert to review the schema for style. Or perhaps it can be
run through an XML pretty-printer. 

OK.

In the following: 

I left "are requested" since the intention was the one detected by Mark in
answering Paul's review.
("[Duckworth, Mark] I thought it was referring to a Consumer's configure
message, so it would be the streams requested by a consumer.")

Policy for MCCs: is just a string. How are we going to specify the available
policies? 

As highlighted by Mark, it is defined in section 10.2 of the document.
Audio, video and text are just examples of valid media types. We did  not
want to put any constraints on the set of possible media types.

PERSON TYPE: I know we discussed this before, but I still find it disturbing
that we have a complexType named "personType" that contains an element named
"personType". I guess it is syntactically and semantically well defined, but
it is certainly confusing to read the schema. I would expect to get
confusion in the future. I suggest replacing personTypeType with
personRoleType or personJobType or personDutyType, and then change the
element name to match. (I recall there were reasons not to use Role.) 

I am OK with any change (e.g., from <personType> to <personRole>), but the
Framework document should be changed accordingly. Our preferred option is to
leave things as they are, btw.

SPATIAL INFORMATION TYPE: Syntactically this allows you to provide spatial
information yet omit both the capturePoint and the captureArea. IIUC it is
an error to specify neither. (Should have then specified
non-spatially-defined.) Can the XML be structured to prevent this misuse? 

This is actually specified in the text, rather than formally specified in
the XML schema.

MOBILITY TYPE: having "dynamic" and "highly-dynamic" seems confusing. How
about "variable" and "dynamic"? 

This is indeed how mobility type has been defined in the Framework document.
We're OK with modifying such a definition, but framework should be changed
accordingly.

OTHER CAPTURE TYPE: why doesn't this look exactly like TEXT CAPTURE TYPE?
(It differs by omission of anyAttribute.) 

CAPTURE POINT TYPE: it still seems odd to me to call this a *point* when it
actually can define a vector. How about "captureVector"? Or, since the part
that makes it a vector is optional, maybe "captureOrigin". 

ENCODING ID LIST TYPE: this defined encID. Presumably this is intended to
refer to the "encodingID" elementof captureEncodingType. Is that
correspondence specified somewhere? Is there a reason not to use the IDREF
mechanism? (Does the idref only work in a single document, while this needs
to work from a configure toward an advertisement?) 

* Section 10.1: 

It would be helpful to say that the captureID serves as the way the capture
is referenced from CaptureEncodings created by the consumer in Configure
messages. 

OK. Text added.

* Section 10.5.2: 

It would be helpful to note that the capture area has two "sides", and it
implies which side is the "front". (The capture point must be on the side
from which it is possible to view the left points as left of the right
points, and the top points as above the bottom points.) 

OK, we added: "The four coplanar points are identified from the perspective
of the capture device."

* Section 10.8: 

This says "... captures coming from the same source." But I think it is
possible for switching to include multiple sources concurrently. So I think
that needs to be changed to "... same sources.". 

OK.

Also, in this section what is "MP"? I guess it means Media Provider? Either
this should be added to the definitions, or it should be expanded. (Note
that this is also used elsewhere.) 

OK. Expanded everywhere.

* Section 10.16: 

highly-dynamic: MAY change dynamically, even between advertisements. The
value in an advertisement is simply a snapshot of the location at the time
of the advertisement. 

OK. Text added.

* Section 21: 

While this may repeat the framework, I think this section should explain the
the references in the captureEncoding are to captures and encodings defined
in a separate XML document (an advertisement). 

OK. Done.

* Section 22: 

Replaced with:
The <clueInfo> element includes all the information needed to represent the
Media Provider's description of its telepresence capabilities according to
the CLUE framework (i.e., it actually represents the body of the
ADVERTISEMENT message). 

    Thanks, 
    Paul 

 

----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale: 00876220633
 <http://www.unina.it/Vademecum5permille> www.unina.it/Vademecum5permille

  --

---

From: Roberta Presta <[email-masked]>
Date: Fri, 26 Jun 2015 15:21:58 +0200

Dear Paul,

please find below my replies about the definition of <policy> and mediaType.

Il 23/06/2015 21:35, Paul Kyzivat ha scritto:
> I'm comfortable with registries because I understand them, so I would 
> be happy with an iana registry. But I guess that xml may have other 
> ways to handle this. (E.g. an enumeration. Could such a thing be 
> extended via definitions in another namespace?)
>

According to the provided definition, "token" is made by one or more 
lowercase or uppercase letters from a to z and numbers from 0 to 9, 
while "index" is made by one or more numbers from 0 to 9. 
"SoundLevel:3", for example, is a valid <policy> value.
This definition is coherent with the framework one about the switching 
policy attribute ("The attribute is in the form of a token that 
indicates the policy, and an index representing an instance of the 
policy.") and allows for defining new policy names having a similar 
semantic.
Two policies have been defined to date in the framework document, i.e., 
two switching behaviors have been described (SoundLevel and RoundRobin).
In the future, you can create documents specifying new switching 
behaviors, associated with new token names, and you can keep on using 
this data model without any change.

Otherwise, we can define an enumerative type for the token part of the 
switching policy name, containing just "SoundLevel" and "RoundRobin" as 
possible values.
If new tokens need to be defined, you will need to change the data model 
document, by the way.

> One possibility is to reference RFC4566 for the definition used for 
> the m-line.
>
> But I think we would need additional clue specifications to support 
> more than audio/video/text. So we might want to say that *this* spec 
> only covers audio/video/text, but it may be extended in the future to 
> cover additional types allowed by RFC4566, and that receivers MUST be 
> able to accept (and presumably ignore) advertisements that contain 
> others that they don't understand.
>
The type definition for the mediaType attribute is intentionally as 
general as possible in order to not require changes in the data model 
when dealing with other media types besides "audio", "video", and 
"text".  In other words, for other capture types, we can specify any 
other values in the mediaType attribute and be still compliant with the 
current data model specification. Clearly the interpretation of those 
other media capture types should be shared between implementations 
and/or defined somewhere, but the point is that, by this way, using new 
values do not affect the pre-defined structure of the data model.
This is somehow the same motivation provided above for the definition of 
the <policy> type.

What do you think about these possibilities?

Roberta

----

---

From: Roberta Presta <[email-masked]>
Date: Fri, 26 Jun 2015 15:45:13 +0200

Hi Roni,

I found the definition of xs:language here:
http://www.w3.org/TR/xmlschema11-2/#language
This document is a W3C Recommendation of 2012 which is cited in the 
information you can find at http://www.w3.org/2001/XMLSchema.

Roberta

Il 26/06/2015 14:33, Roni Even ha scritto:
>   – where is type language defined? I did not see it inhttp://www.w3.org/2001/XMLSchema
>
> Roni
>
> *From:*clue [mailto:[email-masked]] *On Behalf Of *Roberta Presta
> *Sent:* 23 June, 2015 1:55 PM
> *To:* [email-masked]
> *Subject:* Re: [clue] Paul's WGLC review of 
> ("[Duckworth, Mark] I thought it was referring to a Consumer's 
> configure message, so it would be the streams requested by a consumer.")
>
>
> OK. We added a regular expression to define the content of the 
> <policy> element in the form of "token:index".
>
> The <clueInfo> element includes all the information needed to 
> represent the Media Provider's description of its telepresence 
> capabilities according to the CLUE framework (i.e., it actually 
> represents the body of the ADVERTISEMENT message).
>
>
>
>     Thanks,
>     Paul
>
> [email-masked] <mailto:[email-masked]>
> www.unina.it/Vademecum5permille <http://www.unina.it/Vademecum5permille>
>
>   
>

----

---

From: "Roni Even" <[email-masked]>
Date: Fri, 26 Jun 2015 18:12:20 +0300

Hi Roberta,

Thanks, found it and it is in line with the framework definition

Roni

From: Roberta Presta [mailto:[email-masked]] 
Sent: 26 June, 2015 4:45 PM
To: Roni Even; [email-masked]
Subject: Re: [clue] Paul's WGLC review of
draft-ietf-clue-data-model-schema-09

Hi Roni, 

Roberta

Hi,

About the xml for 

 

 

Roni

Dear all, 

Roberta

* Section 2: 

OK.

* Section 3: 

OK.

In the following: 

  

* Section 10.1: 

OK. Text added.

* Section 10.5.2: 

* Section 10.8: 

OK.

OK. Expanded everywhere.

* Section 10.16: 

OK. Text added.

* Section 21: 

OK. Done.

* Section 22: 

Replaced with:

    Thanks, 
    Paul 

 

----

  --  

----

  --

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Jun 2015 12:41:34 -0400

More inline...

> please find below my replies about the definition of <policy> and mediaType.

My questions aren't necessarily schema issues, but they are certainly 
clue issues. We can solve them in the schema, or elsewhere.

In both cases there is need to know the set of defined values, the 
semantics associated with each value, and some mechanism for adding new 
values while avoiding conflicts over a name.

For policy, a registry is an obvious solution. The schema document 
and/or one of the other normative clue documents should associate that 
with the syntax.

I think it is harder for mediaType. As I noted, an obvious answer is to 
simply refer to the SDP definition. But I think that is inadequate, 
because there are types that are valid in SDP (e.g., application) that 
we have no clue how to process. Possibly we could restrict to types 
valid in SDP that use RTP for transport. But even then, if somebody were 
to define smell-o-vision over RTP we wouldn't know how to handle it. 
(What sort of spatial info would be appropriate?) So I suspect there 
must be clue-specific semantics for each supported mediaType.

We could define a registry for those too. But it would be hard work to 
come up with rules about what needs to be specified for a new type.

The easy way out is simply to say we are currently restricted to audio, 
video, and rtt, and that adding new types requires standards action. We 
could still leave it as a token in the xml.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 01 Jul 2015 10:11:03 +1000

Hello all,

I'm for keeping the values as tokens so that we don't have to update the 
schema. We probably need to update the IANA registry section to create 
registries for these.

I did prepare some text earlier regarding CLUE enhancement that Roberta 
indicated she would include in the protocol draft (see below) but 
haven't seen in the draft yet. Maybe the data model is the more 
appropriate document?

  Updates to the CLUE protocol document:

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

  x. CLUE Protocol Enhancement

The CLUE protocol may be extended in a number of ways:

1)New values for existing:

a)Media Capture Attributes as defined in section 
7.1.1/[I-D.ietf-clue-framework],

b)MCC Attributes as defined in section 7.2.1/[I-D.ietf-clue-framework],

c)Capture Scene Attributes as in section 7.3.1/[I-D.ietf-clue-framework],

d)Capture Scene View attributes as in section 
7.3.2/[I-D.ietf-clue-framework],

2)New Media Capture, MCC, Capture Scene or Capture Scene View attributes.

3)New Error Response Codes

4)New or modified elements related to the syntax of the CLUE protocol. 
Enhancements not related to CLUE attributes or attribute values.

The CLUE OPTION mechanism is used to indicate support for enhancements 
related to attributes (i.e. 1 and 2 above). Enhancements to CLUE 
protocol syntax as a result of 3 & 4 may require a new protocol version 
or may use the OPTION mechanism. However the procedure for specifying 
and registering a syntax related OPTION is different to an OPTION 
affecting attributes/attribute values. An OPTIONs mechanism is used for 
syntax that is optional for an endpoint to receive. A new CLUE protocol 
version is used where updated syntax MUST be supported by an endpoint.

  x.1 CLUE OPTION registration

Registrations for CLUE OPTIONS are requested from the IANA. This section 
outlines the procedures for documenting and registering a new CLUE OPTION.

*x.1.1 Attribute / Attribute Value related OPTIONs*

The process for registering an attribute / attribute value related CLUE 
OPTION is deemed to be "specification required" as per [IETF RFC 5226]. 
Each OPTION may only contain a single new attribute or one or more value 
additions to an existing attribute.

/{Contributor’s note: The ability to define several attributes/attribute 
values could be added, if deemed worthwhile. The approach of a single 
value was chosen for simplicity in this first draft.}///

The specification MUST include the following information:

*OPTION NAME:*String [1-64 Characters]

/{Contributor’s note: Do we need a version for OPTIONs?}/

*OPTION DESCRIPTION:*A high level text indicating what the CLUE OPTION 
is for.

*Specification Reference: *A URL to the publically available document 
containing the OPTION.

*XML Schema Reference: *The XML schema reference

*Minimum CLUE Version:*The minimum version of the CLUE protocol that the 
OPTION pertains to.

*Attribute Name:*An existing attribute name is used when the OPTION 
introduces new value/s. A new unique attribute name is used when 
introducing a new attribute. OPTION requesters SHOULD check the IANA 
CLUE OPTION registry to ensure that new attributes have a unique name 
within the attribute type.

*Attribute Type (optional):*When introducing a new attribute the type of 
attribute, “Media Capture”, “MCC”, Capture Scene” or “Capture Scene 
View” MUST be indicated. It is not possible to change the attribute type 
of an existing attribute.

*Attribute Description*(optional): This description MUST be included for 
a new attribute. It describes the functionality associated with the 
attribute.

*Value Description:*The specification MUST include a description of the 
new values, including allowed values, values ranges, value type and a 
description of the values. The introduction of new value/s MUST NOT 
change the value type (e.g. from string to integer) nor SHOULD it change 
the meaning of existing values.

*XML Schema (optional): *The specification MUST contain an XML schema 
detailing the new attribute and its values. If an OPTION describes a new 
value in an existing value range updates to the XML schema is not 
required.**

Developers of specifications of new CLUE OPTIONS are encouraged to send 
their specifications to the IETF CLUE working group for comment before 
requesting registration of a new CLUE OPTION with the IANA.

Once the request for CLUE OPTION registration is received by IANA, it 
will be forwarded to the Internet Engineering Steering Group (IESG) 
appointed Expert for review. During the review, the specification with 
the requested CLUE OPTION will be compared to the above criteria for 
completeness, as well as being compared against protocol syntax and 
procedures. It will be compared against existing OPTIONS to see that it 
does not duplicate existing functionalities. It will be reviewed to see 
that any potential security issues are addressed. The Expert reviewer 
will then work towards a resolution of any issues with the OPTIONS 
requester. The IESG appointed Expert may complete the review in 
consultation with other CLUE experts (i.e., via email to IETF CLUE email 
list). If the CLUE OPTION is deemed suitable, the IESG appointed Expert 
shall issue a statement indicating approval, copied to IANA.

The IESG Expert reviewer will ensure the following is recorded with the 
IANA for each OPTION:

1)A unique string name is registered for each CLUE OPTION. CLUE OPTION 
names are allocated on a first come-first served basis if all other 
conditions are met.

2)The attribute type and name of the affected attribute. This is to 
facilitate cross checking of OPTIONs to ensure that namespaces and 
values within a namespace do not overlap.

3)A reference to a specification that describes the OPTION,

4)A contact name, an email and postal addresses for the CLUE OPTIONS 
requester shall be provided. The contact information shall be updated by 
the defining organization, as necessary.

*x.1.2 Syntax / Response code related OPTIONs*

The process for registering a syntax or response code related CLUE 
OPTION is deemed to be "Standards Action" as per [IETF RFC 5226].

The RFC MUST include the following information:

*OPTION NAME:*String [1-64 Characters]

/{Contributor’s note: Do we need a version for OPTIONs?}/

*OPTION DESCRIPTION:*A high level text indicating what the CLUE OPTION 
is for.

*XML Schema Reference: *The XML schema reference

*Minimum CLUE Version:*The minimum version of the CLUE protocol that the 
OPTION pertains to.

*XML Schema Description:*A description of the new XML elements and any 
possible relationship to the existing CLUE protocol elements.

*XML Schema: *The specification MUST contain an XML schema detailing the 
new syntax. It is not possible to modify or remove existing XML syntax 
via an OPTIONs specification.**

The responsible IETF WG SHALL ensure the following is recorded with the 
IANA for each syntax OPTION:

1)A unique string name is registered for each CLUE OPTION. CLUE OPTION 
names are allocated on a first come-first served basis if all other 
conditions are met.

2)An indication that the OPTION is related to syntax.

3)A reference to the RFC that describes the OPTION.

Regards, Christian

On 26/06/2015 11:21 PM, Roberta Presta wrote:
> Two policies have been defined to date in the framework document, 
> i.e., two switching behaviors have been described (SoundLevel and 
> RoundRobin).
> switching policy name, containing just "SoundLevel" and "RoundRobin" 
> as possible values.
> If new tokens need to be defined, you will need to change the data 
> model document, by the way.
>
>
> other values in the mediaType attribute and be still compliant with 
> the current data model specification. Clearly the interpretation of 
> those other media capture types should be shared between 
> implementations and/or defined somewhere, but the point is that, by 
> this way, using new values do not affect the pre-defined structure of 
> the data model.
> This is somehow the same motivation provided above for the definition 
> of the <policy> type.
>