Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-07

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 1 Oct 2014 10:43:37 -0700

Paul wrote:

> Why has the definition of Simultaneous Transmission Set been changed to
> constrain to captures of the same type? I thought we explicitly agreed
> that there should be no such restriction.

I thought we explicitly agreed an STS has just a single media type.  The framework section 8 has this:
 
"This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time.  There are different Simultaneous Transmission Sets for each media type in the Advertisement."

Maybe you are thinking of Encoding Groups, which can have multiple media types in the same group?

Mark

---

From: Roberta Presta <[email-masked]>
Date: Thu, 02 Oct 2014 11:23:09 +0200

Dear Paul,
thank you for the review.
Please see the answers inline.

Il 30/09/2014 23:32, Paul Kyzivat ha scritto:
> Roberta,
>
> I tried to do a careful review of the schema again. The following are 
> my notes from that:
>
> * Terminology:
>
> Camera-Left and Right: this is now out of date with the -17 framework.
>
[RP] ok, this needs to be changed.
> Why has the definition of Simultaneous Transmission Set been changed 
> to constrain to captures of the same type? I thought we explicitly 
> agreed that there should be no such restriction.
[RP]

This is text from framework 16, Section 8 (it appears also in framework 
17, Section 8).
" /This type of constraint is expressed in a Simultaneous Transmission 
Set, which lists all the Captures of a particular media type (e.g. 
audio, video, text) that can be sent at the same time. There are 
different Simultaneous Transmission Sets for each media type in the 
Advertisement. /"

This is text from Mark's review of July 21, citing a your suggestion on 
the topic:
"/simultaneousSetType -- the framework says "For shorthand convenience, 
a Provider MAY describe a Simultaneous Transmission Set in terms of 
Capture Scene Entries and Capture Scenes".  Looks like the data model 
allows using CSE for shorthand, but not Capture Scenes.  So should there 
be a "sceneIDREF" element here? Also, as Paul noted in his review of the 
framework, there needs to be a way to identify the media type for an STS 
if it includes only scenes.  I suggest adding a <capturedMedia> (or 
<mediaType>) element to the simultaneousSetType, with the same meaning 
it has elsewhere.  Then all the media captures referenced in the STS 
must be of that media type"//
/
I'm sorry if I missed something about that.
What is the final decision?
I can easily change the text and the XML definition in the document 
accordingly.

> * <mediaCaptureType>:
>
> There is a sequence containing spatialInformation. But there are no 
> bounds on it. IIUC, it should be optional - minOccurs=0, maxOccurs=1. 
> (Doesn't make sense to appear more than once.)
>
> That assumes it belongs in mediaCaptureType. While there is a single 
> type for <spatialInformation>, audio and video have differing 
> constraints on which parts of this may/must be present and which must 
> not. ISTM that the benefit of having a single type has been lost. 
> Perhaps there should just be separate spatial info types for audio and 
> video.
>
> Also, can somebody please remind me why we need an explicit notation 
> for nonSpatiallyDefinable? (Rather than simply omitting spatial 
> information.)
>
> Similarly, is there a reason why we need "individual" as an 
> alternative to to the MCC info? Couldn't we simply have MCC info as an 
> optional fields?
>
[RP]
We use the <choice> element in the definition of mediaCaptureType 
instead of simply making the elements optional because it allows for a 
more precise construction of the <mediaCapture> elements in the XML.
The choice element makes you understand by simply reading the schema 
that, for example, only  if you are describing a MCC capture you can use 
the block of elements made by "policy", "content", "synchID", etc., 
otherwise you must not use them (i.e., you are describing an individual 
capture).
It is a way to make explicit mutually exclusive ways of description.
The choice construct also allows the receiver to know without any doubt 
that, for example, a capture is an individual one and not a 
multi-content one. If no one of the multi-content attributes is provided 
(they are all optional), the receiver has no way to be sure that the 
capture is an individual capture - it could be a MCC with no attributes 
specified.
What do you think about this motivations?
However, no problem with changing the definition and with providing 
guidance text in the document.

> The optional field element "view" of type "viewType" is confusing 
> since we switched to the sceneView and globalView terminology. I think 
> we should come up with a new name for this. A couple of terms that 
> come to mind are: "contentType" or "subjectType".
>
[RP] I propose <subject> instead of <view>, and subjectType instead of 
viewType.

> * <personTypeType>:
>
> I still find this, and the element "personType" of this type, to be 
> very confusing to read and think about. Can we find some less 
> confusing term for this? I'm tempted to suggest personRole, even 
> though I know our past discussions add a lot of baggage to this. Some 
> other terms that might work are: "personDuty", "personFunction", 
> "personJob".
>
[RP]
Please note that "personTypeType" is the name of the type, and it is not 
the name of the XML element that will appear in the ADV. Indeed, in the 
ADV you will have just <personType> XML elements.
If we change <personType> in <personRole>, for example, you will have 
"personRoleType" instead of "personTypeType", but we are no more 
compliant in terminology with the framework - you will need to choose a 
new common name indicating the role of the person and to change both 
documents accordingly.

> * Extensibility of enumerations:
>
> This came up on the call wrt sensitivityPatternType. But there are 
> several enumerations that probably have the same concern:
> - personTypeType
> - viewType
> - presentationType
> - mobilityType
> - ? scaleType
>
> The usual ietf solution for extensibility is an IANA registry. That 
> would be in lieu of enumerating them in the schema. If we went that 
> way then the element would probably simply be of type string, and text 
> would say that the valid values are defined in a registry, and that if 
> a value is not understood it should be ignored.
>
[RP]
Thank you for listing them.
I'm not sure I understand correctly.
Are you saying that we should define such types as string an saying that 
acceptable values are those registered with IANA?
Then, if we need to extend these types with new values, we need to 
update the IANA registrations and nothing more.
Right?

> * <capturePointType>:
>
> The name of this has troubled me for some time, because, once you add 
> lineOfCapturePoint it is no longer a point. As an alternative, how 
> about "captureOriginType"? (I don't love that, but I like it better 
> than what we have and haven't thought of anything better.)
>
[RP]
We have put <lineOfCapturePoint> in the definition of <capturePoint> in 
order to make invalid those documents presenting a <lineOfCapturePoint> 
element without a previous <capturePoint> element. Indeed, a line of 
capture point makes no sense in absence of a capture point.
Even if I see your point, I do not think that changing names is a good 
idea in this case (because of terminology consistency reasons).
We could simply make a separate element for <lineOfCapturePoint>, by 
removing its definition from the body of the capture point, and adding 
the rules of the correct composition of the spatial information in the 
description text of the data model document (we loose the encapsulation 
of the rule "no line of capture point without capture point" in the schema).
What do you think about it?

> * <encodingIDListType>:
>
> Why is the type of encID "string"? Shouldn't it be IDREF?
>
[RP]
IDREF is used to refer to ID that are shown in the XML document created 
accordingly to the schema.
Since individual encodings are not listed anymore in the XML document, 
and since the "original" individual encoding identifiers are written in 
SDP, you can not use the xs:IDREF type for them, otherwise you have a 
validation error.
> * <mediaCaptureIDListType>:
>
> IIUC there is a requirement that all the captureIDREFs included in one 
> list must be of the same mediaType. But this isn't stated. ISTM that 
> this should be stated.
>
[RP] I will correct after I have the confirmation about the first point 
(simultaneous sets).

> * Sample of extensibility (section 23.1):
>
>
>
> This section says:
>
>    The extension defines ... an
>    attribute for characterizing the captures belonging to an
>    "otherCaptureType" defined by the user.
>
> From this I infer that the recipient is expected to classify the 
> predefined capture types by their type, but that extension types are 
> to be classified using attributes/elements that fit within the "any" 
> atttributes/elements of otherCaptureType.
>
> Is that what is intended? It seems unnatural. Why can't extension 
> capture types be defined as extensions of mediaCaptureType, just like 
> the builtin ones are?
>
[RP]
If we go that way (S1), I agree the classification needs to be made by 
means of specific attributes/elements, we should put them within the 
otherCaptureType.
I mean, we should introduce a field saying at least the name of the 
extension.

On the other hand, if you  define a new type extending mediaCaptureType 
in another schema, and insert in the XML doc that new type of media 
capture, you obtain a validation error if you use the standard schema 
for the validation. That happens because the new media capture type is 
not recognized by using the "standard" xml schema only, and because you 
do not insert the new media capture in place of an <any> elements.
I think this is what you have in mind (S2):

New XML schema ("extension" namespace prefix):
[---]
<!-- NEW CAPTURE TYPE -->
<xs:complexType name="newCaptureType">
  <xs:complexContent>
   <xs:extension base="tns:mediaCaptureType">
    <xs:sequence>
     <xs:element name="newCaptureTypeFeature" type="xs:string"
     minOccurs="0"/>
     <xs:any namespace="##other" processContents="lax" minOccurs="0"
     maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
   </xs:extension>
  </xs:complexContent>
</xs:complexType>
[---]

XML document excerpt compliant with the new schema:

[---]
     <mediaCaptures>
         <mediaCapture 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="audioCaptureType"
         captureID="AC0"
         mediaType="audio">
             [---]
         </mediaCapture>
         <mediaCapture 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="extension:newCaptureType"
         captureID="NC1"
         mediaType="new type">
             [---]
         </mediaCapture>
     </mediaCaptures>
[---]

This XML document is not  compliant with standard schema because the 
xsi:type of the second media capture is not defined in the standard 
schema, so it is not recognizable, and the unknown element (the media 
capture of the unknown type) is not placed in correspondence of an <any> 
element.

You do not have any validation issue  only if (i) you define in the 
extension schema a new element of the new type (like a <newMediaCapture> 
of newCaptureType), and (ii) add <any>  in the <mediaCaptures> 
definition, after the envisioned sequence of media captures (S3):

Updated CLUE schema:
<!-- MEDIA CAPTURES TYPE + ANY-->
<!-- envelope of media captures -->
<xs:complexType name="mediaCapturesType">
  <xs:sequence>
    <xs:element name="mediaCapture" type="mediaCaptureType"
    maxOccurs="unbounded"/>
     <xs:any namespace="##other" processContents="lax" minOccurs="0"
     maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

New part for the new extension schema:
<xs:element name="newMediaCapture" type="tns:newCaptureType"/>

New XML excerpt compliant with the extension schema (and with the 
updated CLUE schema):
     <mediaCaptures>
         <mediaCapture
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="audioCaptureType"
                 captureID="AC0" mediaType="audio">
         [---]
         </mediaCapture>
         <ns3:newMediaCapture captureID="nc0" mediaType="new type">
         [---]
         </ns3:newMediaCapture>
     </mediaCaptures>

The second media capture can now be interpreted as an element appearing 
in the <any> part of <mediaCaptures>.
However, in this way, the parser expects that any element can appear in 
the last part of <mediaCaptures>, and not only elements of extended 
media capture type.

Each approach has pros and cons.
We will consider their effects also on the protocol usage and discuss 
them again in the next call if you agree.

> * Nit - the xml schema isn't all consistently indented.
>
>
[RP] Sorry for that, I will correct the problem.
>     Thanks,
>     Paul
Roberta

---

From: Roberta Presta <[email-masked]>
Date: Thu, 02 Oct 2014 11:01:57 +0200

Dear Paul,

[RP]

[RP]

[RP]

[RP]

[RP]

[RP]

[RP]

[---]
     <mediaCaptures>
         <mediaCapture 

Updated CLUE schema:

Roberta

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Oct 2014 13:24:44 -0400

>> agreed that there should be no such restriction.

Mark also commented on this. I was mistaken. So forget about this comment.

> otherwise you must not use them (i.e., you are describing an individual

I wasn't questioning the use of the choice. Here is the part in question:

     <xs:choice>
       <xs:sequence>
         <xs:element name="spatialInformation"
                     type="tns:spatialInformationType"/>
       </xs:sequence>
       <xs:element name="nonSpatiallyDefinable"
                   type="xs:boolean" fixed="true"/>
     </xs:choice>

IIUC, since it specifies neither maxoccurs nor minoccurs, this is just a 
more complex way of saying:

     <xs:choice>
       <xs:element name="spatialInformation"
                   type="tns:spatialInformationType"/>
       <xs:element name="nonSpatiallyDefinable"
                   type="xs:boolean" fixed="true"/>
     </xs:choice>

> guidance text in the document.

OK. Now I understand the reason for "individual".

But the same logic doesn't apply for nonSpatiallyDefinable. That is 
redundant with simply noting the absence of spatialInformation.

> [RP] I propose <subject> instead of <view>, and subjectType instead of

WFM

> new common name indicating the role of the person and to change both

OK. I'll just shut up again.

> update the IANA registrations and nothing more.

Yes. I'm offering that as one approach for handling the extensibility of 
these fields. But it seems a little odd in xml, so I'm certainly open to 
other approaches that are more natural for xml, if there are any.

>> * <capturePointType>:

I'll comment separately on this.

> SDP, you can not use the xs:IDREF type for them, otherwise you have a

Ahh! OK. That makes sense.

>> * Sample of extensibility (section 23.1):

I'll also comment on this separately.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 04 Oct 2014 08:33:33 -0400

> Maybe you are thinking of Encoding Groups, which can have multiple media types in the same group?

oh, duh! You are right - I mixed those up.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 06 Oct 2014 15:12:37 +1100

Hello Roberta,

Please see my replies below.

Regards, Christian

..snip..
>> [RP] I propose <subject> instead of <view>, and subjectType instead of
[CNG] I don't really agree with the use of "subject". When I read 
"subject" I immediately think of what the conference is about. When I 
read "view" I think of what I am seeing/hearing. I think the fact that 
we use "sceneView" and "globalView" actually strengthens the reason we'd 
use the term "view". To distinguish we could add capture i.e. 
"captureView" "captureViewType".
> ..snip..
> Yes. I'm offering that as one approach for handling the extensibility 
> of these fields. But it seems a little odd in xml, so I'm certainly 
> open to other approaches that are more natural for xml, if there are any.
[CNG] What i'd really like to see as part of the protocol document is an 
appendix with a template of exactly what a new registration would look 
like. I'd like to see that updates to CLUE can be made quickly without 
1+ year of specification effort. Rather than registering new values with 
IANA, we can register the new "option" with IANA. e.g. in Megaco we 
register the PackageID with IANA which effectively points to a template 
for values/procedures.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 10 Oct 2014 15:08:14 -0700

inline

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Monday, October 06, 2014 12:13 AM
> To: [email-masked]
> Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-07
> 
> Hello Roberta,
> 

[Duckworth, Mark] I agree with Christian.
Similarly, I suggest the MCC related elements (name="content" type="contentType") would be easier to understand if we change the name to (name="mccContent" type="mccContentType").  And also change name="configuredContent" to name="mccConfiguredContent" in the captureEncodingType.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Oct 2014 12:07:53 -0400

> "captureView" "captureViewType".

I will defer to the majority here.

> register the PackageID with IANA which effectively points to a template

Putting them into IANA *might* make adding values easier. It depends on 
what registration procedure we choose.

I am ok with making some things relatively each to add to. But not all. 
Some *ought* to have a high bar. For instance I wouldn't want to make it 
too easy to add a new viewType.

If we made these IANA tables, how would that affect clue versioning? If 
anybody can add a value then doing so shouldn't affect the versioning. 
If we make the addition of a value Standards Action, then we could tie 
changes to a version number change. But we can decide that independently 
for each item.

I'm not sure if it's "weird" to use iana registrations for xml 
enumerations - if there is some preferred way to do this for xml.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Mon, 13 Oct 2014 14:28:42 -0500

On Mon, Oct 13, 2014 at 11:07 AM, Paul Kyzivat <[email-masked]>
wrote:

> anybody can add a value then doing so shouldn't affect the versioning. If
> we make the addition of a value Standards Action, then we could tie changes
> to a version number change. But we can decide that independently for each
> item.

[MB] They should be registered as Standards Action required. [/MB]

> enumerations - if there is some preferred way to do this for xml.
[MB] This is not unusual.  Take a look at RFC 6503. [/MB]

>
>         Thanks,
>         Paul
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 14 Oct 2014 11:03:59 +1100

Hello Mary and Paul,

>     Putting them into IANA *might* make adding values easier. It
>     depends on what registration procedure we choose.
>
>     I am ok with making some things relatively each to add to. But not
>     all. Some *ought* to have a high bar. For instance I wouldn't want
>     to make it too easy to add a new viewType.
>
[CNG] I agree some should have a higher bar. I wouldn't have thought 
viewType was one. What is it about viewType that you feel should have a 
high bar.
>
>
>     If we made these IANA tables, how would that affect clue
>     versioning? If anybody can add a value then doing so shouldn't
>     affect the versioning. If we make the addition of a value
>     Standards Action, then we could tie changes to a version number
>     change. But we can decide that independently for each item. 
>
[CNG] Actually I think we want to avoid "standards action" for adding 
values/attributes. I think that "expert review" or "specification 
required" would be sufficient. I think that needing a standards action 
for every small update will stifle the potential uses of CLUE. We don't 
know all the application scenarios where CLUE will be used and there may 
be application scenario specific metadata that could be sent via CLUE. 
It should be easy to add this without a long drawn out IETF standards 
action process. Does the IESG want to be bothered with having to 
review/process/meet to add value to an existing attribute?

I agree that adding new core CLUE syntax, messages etc should be 
standards action required.

With regards to versioning I think any core protocol updates would be 
handled by version number changes. Any additional attributes/values 
other than those defined in the core protocol document would be handled 
via the OPTIONS message.

So if we take the framework document my proposal would be that any 
change to the existing protocol would require a "Standards Action" 
except for:
  7.1.1. Media Capture Attributes
  7.2.1. MCC Attributes
  7.3.1. Capture Scene attributes
  7.3.2. Capture Scene View attributes.
  9.2 Encoding Group attributes
where new values or new attributes could be added via expert 
review/specification required. The use of these new attributes/values 
would be signalled via an OPTIONS message.

>     [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Oct 2014 15:17:45 -0400

> viewType was one. What is it about viewType that you feel should have a

I didn't (though maybe Mary did). I was speaking in general about 
whatever we put into IANA registries - we need to decide case by case 
how high the bar should be.

The specific items under discussion here are:

                     - personTypeType
                     - viewType
                     - presentationType
                     - mobilityType
                     - ? scaleType

Note that I put a question mark by scaleType. I think that one deserves 
a high bar and to require version or option negotiation.

For the others, I would be comfortable with expert review. And I would 
not expect new clue version/option for it - just ignore unknown values.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 14 Oct 2014 14:58:32 -0500

On Tue, Oct 14, 2014 at 2:17 PM, Paul Kyzivat <[email-masked]> wrote:

> I didn't (though maybe Mary did). I was speaking in general about whatever
> we put into IANA registries - we need to decide case by case how high the
> bar should be.
>
[MB] Nope. I was not  speaking to view type.  I's really hard to follow
attributions when people don't preface with initials or whatever and expect
an email program's rules to be sufficient.  Certainly, expert review with
specification required could be an option.  I would be very wary of having
a registry without such. I'm not seeing in not having these things
documented somewhere if we think we need an IANA registry as is. [/MB]

> Note that I put a question mark by scaleType. I think that one deserves a
> high bar and to require version or option negotiation.
>
> For the others, I would be comfortable with expert review. And I would not
> expect new clue version/option for it - just ignore unknown values.
>
>         Thanks,
>         Paul
>
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 15 Oct 2014 10:11:54 +1100

Hello

Please see below marked [CNG].

Regards, Christian
On 15/10/2014 6:58 AM, Mary Barnes wrote:
>     whatever we put into IANA registries - we need to decide case by
>     case how high the bar should be.
>
> [MB] Nope. I was not  speaking to view type.  I's really hard to 
> follow attributions when people don't preface with initials or 
> whatever and expect an email program's rules to be sufficient.  
> Certainly, expert review with specification required could be an 
> option.  I would be very wary of having a registry without such. I'm 
> not seeing in not having these things documented somewhere if we think 
> we need an IANA registry as is. [/MB]
[CNG] I was referring to the above sentence "some *ought* to have a high 
bar. For instance I wouldn't want to make it too easy to add a new 
viewType."

>     Note that I put a question mark by scaleType. I think that one
>     deserves a high bar and to require version or option negotiation.
>
[CNG] Yes I agree this one does deserve a high bar.
>
>
>     For the others, I would be comfortable with expert review. And I
>     would not expect new clue version/option for it - just ignore
>     unknown values.
>
[CNG] I'm not sure about ignoring unknown values. There may be two 
identical captures only distinguished between by a value. How does the 
Consumer then distinguish between them? If we have the OPTIONS 
mechanism, why not use it to avoid the case where the MP sends the MC 
stuff it doesn't understand?

..snip..

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Oct 2014 20:13:02 -0400

> stuff it doesn't understand?

Do you have something in mind to couple an option to the new value in iana?

I guess part of the registration of the new value could be the clue 
version option that is required to use it. But that seems complex for 
what seems like a simple thing. That raises the bar for defining a new 
value. In addition to registering the new value you will have to also 
define the new option - requiring a schema URL to be registered.

If you don't understand the values, then you make your decisions without 
regard to that. You still have the scene views and global views to guide 
you to a reasonable choice. And if you are going beyond that it may come 
down to human input anyway.

A lesson from this discussion is that planning for extensions isn't so 
easy. Looks like it might take significant added work to get it so that 
expert review would be sufficient to do the right thing. In my 
experience that is one reason to set the bar high (standards action) as 
a way of kicking that can down the road. But I know the IESG is not in 
favor of that approach.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Oct 2014 20:23:50 -0400

On 10/14/14 3:58 PM, Mary Barnes wrote:

> attributions when people don't preface with initials or whatever and
> expect an email program's rules to be sufficient.

I guess that dig was addressed at me?

IMO the problem is that people use incompatible conventions.
I *detest* putting initials, especially when it is accompanied by 
violations of reply quoting conventions. The initials don't give any 
indication of the order of posts. And when accompanied by violations of 
the quoting conventions (as often happens) there is actually 
misdirection about the order of posts. And, unless you put your initials 
on every line, after a few replies it all becomes indecipherable.

IMO the traditional mail quoting conventions work fine until things get 
complex enough to start trimming out the detail. When I do that I have 
no expectation that the trimmed identities will be known, or matter.

I recognize that some other people detest the quoting conventions and 
*like* the initials. So I *tolerate* the mixed styles. It would probably 
be better if everyone agreed to do it one way or the other, but I don't 
expect that will happen.

I've never investigated extensively, but I have the impression that some 
mail programs (Outlook?) don't do quoting right and have encouraged the 
use of initials.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 14 Oct 2014 19:58:48 -0500

> I guess that dig was addressed at me?
[MB2] It was a general comment about this thread and wasn't necessarily
targeted at you.  I was merely suggesting a reason for the confusion as to
who said what. [/MB2]

> indication of the order of posts. And when accompanied by violations of the
> quoting conventions (as often happens) there is actually misdirection about
> the order of posts. And, unless you put your initials on every line, after
> a few replies it all becomes indecipherable.
>
[MB2] I'm not at all sure what you mean in terms of "violations of reply
quoting conventions".  Can you please provide a pointer to such
conventions?  I use a block of text starting with [MBx] and ending with
[/MBx].  I would think people would avoid commenting in the middle of the
block as otherwise, I would agree it would then be impossible to tell the
threads apart. [MB2]

> complex enough to start trimming out the detail. When I do that I have no
> expectation that the trimmed identities will be known, or matter.
>
[MB2] What do you mean by "traditional"?  Some systems use the ">"s and
others use colors, indentation, etc.
[/MB2]

> *like* the initials. So I *tolerate* the mixed styles. It would probably be
> better if everyone agreed to do it one way or the other, but I don't expect
> that will happen.

[MB2] Nope. Not gonna happen. It all depends upon the email program you use
and IETF shouldn't be dictating UIs ;) [/MB2]

> mail programs (Outlook?) don't do quoting right and have encouraged the use
> of initials.
>
[MB2] I'm not sure what you mean by "quoting right" since many email
programs do it differently. [MB2]

---

From: John Leslie <[email-masked]>
Date: Tue, 14 Oct 2014 22:01:47 -0400

> IMO the problem is that people use incompatible conventions.

   +1

> violations of reply quoting conventions.

  +1

> The initials don't give any indication of the order of posts. And
> when accompanied by violations of the quoting conventions (as often
> happens) there is actually misdirection about the order of posts.
> And, unless you put your initials on every line, after a few replies
> it all becomes indecipherable.

   +1

> no expectation that the trimmed identities will be known, or matter.

   Please let _me_ know if you have difficulty following my attributions.
I try very hard to boil things down so as to be easy to follow, and I
make sure there are carriage-returns every 70 characters or so.

> *like* the initials. So I *tolerate* the mixed styles.

   +1

   (Very often, people who like initials use them so sparingly that I
have real trouble distinguishing what text is theirs.)

   And please note: a number of us use mail-readers that very nicely
color the quoted text, which to me at least makes the difference
between being able to quickly follow the discussion or having to
skip over it. :^(

> It would probably be better if everyone agreed to do it one way or
> the other, but I don't expect that will happen.

   Clearly, it _won't_ happen. Too many of us _have_to_ use mail
readers which don't follow any reasonable (IMHO) quoting rules.

   :^(

--
John Leslie <[email-masked]>

---

From: Christian Groves <[email-masked]>
Date: Thu, 16 Oct 2014 07:42:49 +1100

Hello Paul,

Please see below.

Regards, Christian

> Do you have something in mind to couple an option to the new value in 
[CNG] I was thinking that someone would register the option with IANA 
with a pointer to a specification. The specification indicates what the 
additional attributes/values are. This provides the link.
Alternatively the registry could be of a structure:

CLUE OPTIONS
Name  Description Reference
foo   Enables foo  RFCqwer

CLUE Media Capture Attributes
Name  Description Reference
foob  whatecer    RFCqwer

I don't think its up to the registry to enforce protocol behaviour. I 
think the only function of the registry is to ensure that there's no 
identifier conflict.

> define the new option - requiring a schema URL to be registered.
[CNG] The protocol says "An option is characterized by a name, an XML 
schema of reference where the option is defined, and the version of the 
protocol which the option refers to." I think the version could be 
optional. Ideally the addition of an attribute should be dependent on 
any particular version of the base (default behaviour). However if an 
attribute did need a certain CLUE protocol version then it could 
indicate the minimum version.

>
> If you don't understand the values, then you make your decisions 
> without regard to that. You still have the scene views and global 
> views to guide you to a reasonable choice. And if you are going beyond 
> that it may come down to human input anyway.
[CNG] Yes, however we have a mechanism to avoid that situation.

> easy. Looks like it might take significant added work to get it so 
> that expert review would be sufficient to do the right thing. In my 
> experience that is one reason to set the bar high (standards action) 
> as a way of kicking that can down the road. But I know the IESG is not 
> in favor of that approach.
[CNG] I don't see the significant work. In either expert review or 
standards action we'd need to establish rules for updates.

---

From: Mary Barnes <[email-masked]>
Date: Wed, 15 Oct 2014 15:52:40 -0500

One comment at the end [MB].

Mary.

On Wed, Oct 15, 2014 at 3:42 PM, Christian Groves <
[email-masked]> wrote:

> [CNG] I was thinking that someone would register the option with IANA with
> a pointer to a specification. The specification indicates what the
>> version option that is required to use it. But that seems complex for what
>> seems like a simple thing. That raises the bar for defining a new value. In
>> addition to registering the new value you will have to also define the new
>> option - requiring a schema URL to be registered.
>>
> optional. Ideally the addition of an attribute should be dependent on any
> particular version of the base (default behaviour). However if an attribute
> did need a certain CLUE protocol version then it could indicate the minimum
> version.
>
>
>> expert review would be sufficient to do the right thing. In my experience
>> that is one reason to set the bar high (standards action) as a way of
>> kicking that can down the road. But I know the IESG is not in favor of that
>> approach.
>>

[MB] I don't either. Paul, can you further explain or provide some details
of the IESG concern.  That's the first I've heard of such.  [/MB]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Oct 2014 11:43:31 -0400

On 10/15/14 4:52 PM, Mary Barnes wrote:

>         A lesson from this discussion is that planning for extensions
>         isn't so easy. Looks like it might take significant added work
>         to get it so that expert review would be sufficient to do the
>         right thing. In my experience that is one reason to set the bar
>         high (standards action) as a way of kicking that can down the
>         road. But I know the IESG is not in favor of that approach.
>
> [MB] I don't either. Paul, can you further explain or provide some
> details of the IESG concern.  That's the first I've heard of such.  [/MB]

If changes require Standards Action, then we can (arguably) assume that 
the process of getting the change approved will consider all the 
ramifications and filter out bad ideas, even though we haven't defined 
any specific rules.

If the changes only require expert review, then we *might* make the same 
leap of faith. But that puts a lot of burden on the expert. I am an 
expert for a couple of registries, and the standards are not very clear 
on what should/shouldn't be allowed. While some might enjoy the power 
that gives, I don't appreciate it. IMO, if we call for Expert Review, 
then we should also provide the criteria that the expert is to apply to 
decide what to accept and what to reject. The significant work is to 
figure out those criteria. I don't mean to imply that it is a huge task, 
but its the kind of thing that can get bogged down.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Oct 2014 11:54:14 -0400

> think the only function of the registry is to ensure that there's no

OK, that works. Then the policy for both CLUE OPTIONS and CLUE Media 
Capture Attributes would need to require something to reference. Are you 
thinking Standards Action for that?

If so, then the bar for a new attribute value is still Standards Action. 
I thought you were asking for a lower bar there.

For instance, this would most likely preclude definition of 
vendor-specific values. (Whether you consider that a good thing or a bad 
thing.)

> indicate the minimum version.

I think it would have to specify the major versions it works with, and 
the lowest minor version for each of those. (I suppose there could be a 
default to 1.0, but I don't see the value in that. If you have to 
specify it then you will have to think about it!)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Oct 2014 12:18:05 -0400

On 10/14/14 8:58 PM, Mary Barnes wrote:
>
>
> On Tue, Oct 14, 2014 at 7:23 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:

[snip]

>     indication of the order of posts. And when accompanied by violations
>     of the quoting conventions (as often happens) there is actually
>     misdirection about the order of posts. And, unless you put your
>     initials on every line, after a few replies it all becomes
>     indecipherable.
>
> [/MBx].  I would think people would avoid commenting in the middle of
> the block as otherwise, I would agree it would then be impossible to
> tell the threads apart. [MB2]
>
>
>     IMO the traditional mail quoting conventions work fine until things
>     get complex enough to start trimming out the detail. When I do that
>     I have no expectation that the trimmed identities will be known, or
>     matter.
>

IMO the "traditional" approach is the "> "s. And it includes 
"indentation" in the sense that each subsequent reply inserts a new 
layer of "> "s. I don't know where it is documented. Presumably many 
places since a variety of mail programs implement this approach. I'm 
pretty sure this approach predates use of colors, since it predated the 
widespread availability of color.

In the mail program I use (Thunderbird), quoting using "> " is rendered 
using continuous vertical lines (replacing the ">"), making it quite 
clear what goes together and where reply commentary has been inserted, 
to many levels of replies.

>     I recognize that some other people detest the quoting conventions
>     and *like* the initials. So I *tolerate* the mixed styles. It would
>     probably be better if everyone agreed to do it one way or the other,
>     but I don't expect that will happen.
>
> [MB2] Nope. Not gonna happen. It all depends upon the email program you
> use and IETF shouldn't be dictating UIs ;) [/MB2]

I understand, and tolerate it, while grumbling to myself (and 
occasionally in public, like now).

>     I've never investigated extensively, but I have the impression that
>     some mail programs (Outlook?) don't do quoting right and have
>     encouraged the use of initials.
>

Of course the "right" way is the way *I* prefer. :-)

The problem with the [foo] ... [/foo] approach is that it is hard to 
follow when commentary is inserted in the middle of such a block. And 
the sequence in which comments were added by different authors isn't 
apparent. (Nor for a single author unless they remember to use [foo2], 
[foo3] etc.)

And it breaks down entirely when you start trimming the text down to 
focus the conversation.

The thing about the "> " approach is that it tags every line with the 
nesting level. So even with extensive trimming you can still discern at 
least the to and fro of the conversation, even if you can't tell exactly 
who said it.

I would find it interesting to take a message from an old thread with a 
lot of discussion in it, and see exactly what it looks like in all the 
popular mail programs.

Of course this is just tilting at windmills.

	Thanks,
	Paul

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 17 Oct 2014 10:58:52 +1100

Hello Paul,

Please see below.

Regards, Christian

On 17/10/2014 2:54 AM, Paul Kyzivat wrote:
> Capture Attributes would need to require something to reference. Are 
> you thinking Standards Action for that?
>
> If so, then the bar for a new attribute value is still Standards 
> Action. I thought you were asking for a lower bar there.
[CNG] No I was thinking specification required, with a reference to the 
specification. It still means it has to be a public document but doesn't 
force a standards track RFC.

> vendor-specific values. (Whether you consider that a good thing or a 
> bad thing.)
[CNG] Probably not a bad thing... but I think if you make it so that any 
SDO/Forum could register something it will probably mean that it will 
decrease the number of vendor specific optimizations. To make sure that 
vendor specific additions didn't interfere with IANA registered ones we 
could assign a value range for them to play with. i.e. Vendor specific 
options and attributes could start with a "v-", e.g. v-foo.
> the lowest minor version for each of those. (I suppose there could be 
> a default to 1.0, but I don't see the value in that. If you have to 
[CNG] I'm not fond of backwards incompatible changes. Hopefully we see 
clue v1.1 and not v2. I think in going for a new major version it would 
have to take into account the existing attributes to see if they are 
still compatible.

---

From: Christian Groves <[email-masked]>
Date: Fri, 17 Oct 2014 11:05:19 +1100

Hello Paul,

I did a similar task for Megaco (see RFC5615) to define what the expert 
has to check. I think elements of clause 5 would be appropriate. I can 
work on a text proposal for CLUE IANA considerations, it will probably 
be a couple of weeks before I have something though.

Regards, Christian

On 17/10/2014 2:43 AM, Paul Kyzivat wrote:
> If changes require Standards Action, then we can (arguably) assume 
> that the process of getting the change approved will consider all the 
> If the changes only require expert review, then we *might* make the 
> same leap of faith. But that puts a lot of burden on the expert. I am 
> an expert for a couple of registries, and the standards are not very 
> clear on what should/shouldn't be allowed. While some might enjoy the 
> power that gives, I don't appreciate it. IMO, if we call for Expert 
> Review, then we should also provide the criteria that the expert is to 
> apply to decide what to accept and what to reject. The significant 
> work is to figure out those criteria. I don't mean to imply that it is 
> a huge task, but its the kind of thing that can get bogged down.
>
>     Thanks,
>     Paul
>