Subject: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 07:22:32 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-clue-data-model-schema-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

- 11.2: I would like to discuss whether it's a good idea to allow
arbitrary values for mediaType, beyond those types registered in IANA.
The text seem to encourage proprietary values. Did the working group
consider requiring IANA registration of some sort for new values?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive:

-11.10 - I have a similar question for <policy> as for mediaType. I
didn't put it in the discuss because I think <policy> will have an
overall smaller impact on interoperability. But I's still like to see
discussion about why arbitrary values do not create an interop problem. 

- 15, 2nd and 3rd paragraph: Would it be reasonable to promote the SHOULD
to a MUST when privacy sensitive or individually identifiable information
is carried?

Editorial and Nits:

- The shepherd mentions a hope for an xml review during IESG processing.
has that occurred? (If so, an update to the shepherd write up would be
helpful.)

-1, third paragraph, first sentence - I don't understand what the
sentence means.

-3, "CLUE Participant" - It seems a bit odd to repeat all the framework
definitions here, but not repeat the one definition from the protocol
doc.

- 4, last sentence : "As a general remark, please notice that optional
elements that don’t define what their absence means are intended to be
associated with undefined properties."

I'm not sure what that means. Can you elaborate?

-11, first paragraph : "The features that are common to all media types
   appear within the media capture type, that has been designed as an
   abstract complex type."
   
s/that/which

-11.6: "...no <spatialInformation> MUST be provided."

Consider promoting the negation into the 2119 keyword. E.g., "...
<spatialInformation> MUST NOT be provided."

- 11.7: "A multiple content capture is made
   by different captures"
   
Should "made by" be "made up of"?

-- "MAY show in its XML data model
   representation the <content> element."
   
Hard to parse. Consider " ... MAY show the <content> element in its XML
data model representation."

-- "It is composed by a list of
   media capture identifiers"
   
What is the antecedent of "It"?

- 11.6: s/highly-dinamic/highly-dynamic

- 13: "It has been conceived only for data model testing purposes..."
What is the antecedent for "It"?

- 15, 2nd paragraph: "Data model information carried within CLUE messages
SHOULD be
   accessed only by authenticated endpoints."

should "accessed" be "accessible"? (As it stands, it seems to depend on
good behavior of endpoints, which I assume is not the intent.)

-- "There might be more exceptions...
More than what?

- Normative References:
It seems a bit odd to see these second (although I don't know if there is
an actual "rule" about that.) Also, the shepherd write up said that there
were only informative references. I assume these were added after the
fact. It would be very helpful if shepherds would update the write ups
when things are overtaken by events.

---

From: "Roni Even" <[email-masked]>
Date: Wed, 1 Jun 2016 19:41:46 +0300

Inline
Roni

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, June 01, 2016 5:23 PM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15:
> (with DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> - 11.2: I would like to discuss whether it's a good idea to allow arbitrary
> values for mediaType, beyond those types registered in IANA.

[Roni Even] ] I think that the meaning was to allow the media types from the IANA registry http://www.iana.org/assignments/media-types/media-types.xhtml . The issue will be about the usage of other media types in the CLUE environment and not about the values themselves.
Alissa also suggested that we clarify it

> -11.10 - I have a similar question for <policy> as for mediaType. I didn't put it
> in the discuss because I think <policy> will have an overall smaller impact on
> interoperability. But I's still like to see discussion about why arbitrary values
> do not create an interop problem.
> 
> 
> to a MUST when privacy sensitive or individually identifiable information is
> carried?
> 
> 
> Editorial and Nits:
> 
[Roni Even] An XML review was done by Henry Thompson https://mailarchive.ietf.org/arch/msg/clue/1WeFBrIo17CLL_t_6anoHAHMwqg  
> 
> -1, third paragraph, first sentence - I don't understand what the sentence
> means.
> 
> definitions here, but not repeat the one definition from the protocol doc.
> 
> should "accessed" be "accessible"? (As it stands, it seems to depend on good
> behavior of endpoints, which I assume is not the intent.)
> 
> It seems a bit odd to see these second (although I don't know if there is an
> actual "rule" about that.) Also, the shepherd write up said that there were
> only informative references. I assume these were added after the fact. It
> would be very helpful if shepherds would update the write ups when things
> are overtaken by events.

Subject: RE: Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14
From: "Roni Even" <[email-masked]>
To: "'Henry S. Thompson'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 12 May 2016 18:36:07 +0300

Thanks for the review,
I forwarded it also to the CLUE WG mailing list
Roni Even
CLUE WG co-chair

> -----Original Message-----
> From: Henry S. Thompson [mailto:[email-masked]]
> Sent: Wednesday, May 11, 2016 6:58 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Appsdir review of XML schema in
https://tools.ietf.org/html/draft-
> ietf-clue-data-model-schema-14
> 
> [Argh, fumble-finger -- resending with correct address lines]
> 
> Document: draft-ietf-clue-data-model-schema
> Title: An XML Schema for the CLUE data model
> Reviewer: Henry S. Thompson
> Review Date: 2016-05-11
> IETF Last Call Date: 2016-05-23
> ESG Telechat Date: 2016-06-02
> 
> I have been selected as the Applications Area Directorate reviewer for
this
> draft (for background on appsdir, please see
>
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
> 
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
> 
> Summary: The XML Schema itself which is included in this draft is
conformant
> to the XML Schema 1.0 spec, and is good to go, subject to a minor
> correction.  There is a minor glitch in one of the XML examples, also
easily
> corrected.
> 
> Comments:
> 
> I tested the XML Schema document included as section 4 and it passes as
> valid against the schema for schemas.  The example document in section
> 17 is schema-valid according to the corresponding schema.  See 'Nits'
> below for a minor problem with the example document in section 18.
> 
> I briefly reviewed the schema document and it seems straightforward and
fit
> for its intended purpose.
> 
> Minor Issues:
> 
> Section 4, lines 13--14:
> 
>  <xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"
>  schemaLocation="xcard.xsd"/>
> 
> As this stands, it's not actually usable for validation purposes, because
no
> xcard.xsd file is supplied.  Furthermore, there is no Appendix A, which is
> alleged to provide it (see 11.29.1.2).
> 
> I note further that the xCard RFC (6351) doesn't contain an XSD-format
> schema document either.  The IANA XML Registry [1] schema entry for the
> urn:ietf:params:xml:ns:vcard-4.0 URN namespace _does_ however link to
> such a schema document [2].  I suggest you either
>   a) Edit the draft so the above lines read
> 
>  <xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"
>  schemaLocation="http://www.iana.org/assignments/xml-
> registry/schema/vcard-4.0.xsd"/>
> 
>   (this is what I did to do the validity checks I did);
> 
> or
> 
>  b) Delete the schemaLocation attribute and add a comment identifying
>     possible sources of a schema document for the vcard-4.0 namespace,
>     e.g. the above iana.org URI or the contents of Appendix A (if you
>     fill it in).
> 
> Nits:
> 
> Section 18, the XML example has a (copy-paste?) error, which renders that
> example invalid against the schema.  The line
> 
>              <encGroupIDREF>EG0</encGroupIDREF>
> 
> appears twice inside mediaCapture VC7, once on line 204 and once on line
> 237.  The first occurrence should be deleted.
> 
> [1] http://www.iana.org/assignments/xml-registry/xml-
> registry.xhtml#schema
> [2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.xsd
> --
>        Henry S. Thompson, School of Informatics, University of Edinburgh
>       10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
>                 Fax: (44) 131 650-4587, e-mail: [email-masked]
>                        URL: http://www.ltg.ed.ac.uk/~ht/  [mail from me
_always_ has
> a .sig like this -- mail without it is forged spam]

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Jun 2016 10:18:04 -0700

> On Jun 1, 2016, at 9:41 AM, Roni Even <[email-masked]> wrote:
> 
> Inline
> Roni
> 

I asked this same question in my AD review and Simon updated the text. I think the text as it is now is clear, but the question is whether the approach is the best one. I think overall this spec favors customization over interop more than I personally would have liked, but the WG did have consensus around this particular trade-off and other similar ones, so I respect that.

Alissa

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 13:24:13 -0400

Also inline,

On 1 Jun 2016, at 12:41, Roni Even wrote:

>> email
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> arbitrary
> [Roni Even] ] I think that the meaning was to allow the media types 
> from the IANA registry 
> http://www.iana.org/assignments/media-types/media-types.xhtml . The 
> issue will be about the usage of other media types in the CLUE 
> environment and not about the values themselves.

I'm not sure I understand your response. When you say "other media 
types", do you mean other types that are registered in the media-type 
registry, but not described in RFC6838? Or other arbitary media types 
that are not registered or otherwise publicly documented?

>> didn't put it
> [Roni Even] An XML review was done by Henry Thompson 
> https://mailarchive.ietf.org/arch/msg/clue/1WeFBrIo17CLL_t_6anoHAHMwqg

Thanks, I saw that shortly after sending.

>> sentence

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 13:36:25 -0400

On 1 Jun 2016, at 13:18, Alissa Cooper wrote:

> I asked this same question in my AD review and Simon updated the text. 
> I think the text as it is now is clear, but the question is whether 
> the approach is the best one. I think overall this spec favors 
> customization over interop more than I personally would have liked, 
> but the WG did have consensus around this particular trade-off and 
> other similar ones, so I respect that.

I reviewed 14. Checking 15... Yes, that is more clear. I can accept that 
as working group consensus (and will clear). But as a "COMMENT", I think 
it might be helpful to add a sentence or two about why working group 
chose to balance things that way. Do people expect custom media types to 
be rare?  Is there any concern about media-type name collisions?

Ben.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 01 Jun 2016 18:37:50 +0100

Hi Ben,

> >> (with DISCUSS and COMMENT)

 [snip]

> registry, but not described in RFC6838?

In case it helps: top level media types like "model", "application",
"message", and not full media types like "application/pdf". These should
be very rare. JUSTFONT WG is working on another one, but this is the
first time something was added in more than 10 years. I honestly doubt
anything other than "video", "audio" or "text" would be usable for CLUE
anyway.

> Or other arbitary media types 

I would be impressed if any undocumented or unregistered top level media
type would be interoperable, so I don't think any such media types
matter.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 13:46:00 -0400

> anything other than "video", "audio" or "text" would be usable for 

That was my assumption. That's part of why I wondered about the ability 
to ability to invent arbitrary values. (But note that I've already 
cleared my DISCUSS.)

> type would be interoperable, so I don't think any such media types

Does that mean you don't think people will use undocumented media-types 
due to the lack of interoperability, or that anyone who does will be 
effectively proprietary and we should assume they don't want to 
interoperate in the first place?

Thanks!

Ben.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 1 Jun 2016 19:43:49 +0100

Hi Ben,

> On 1 Jun 2016, at 18:46, Ben Campbell <[email-masked]> wrote:
> 
> That was my assumption. That's part of why I wondered about the ability to ability to invent arbitrary values. (But note that I've already cleared my DISCUSS.)

My understanding was that each new media type would have to be registered in the media type registry first, which is a rather high bar anyway. But maybe that is not what the WG had in mind.

I think it is more likely that "application" would be used, rather than an entirely new media type.

> Does that mean you don't think people will use undocumented media-types due to the lack of interoperability, or that anyone who does will be effectively proprietary and we should assume they don't want to interoperate in the first place?

Both :-).

Experience with media types in other places shows that new media types are hard to deploy.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 14:39:19 -0400

On 1 Jun 2016, at 14:43, Alexey Melnikov wrote:

>> That was my assumption. That's part of why I wondered about the 
>> ability to ability to invent arbitrary values. (But note that I've 
>> already cleared my DISCUSS.)
>
> My understanding was that each new media type would have to be 
> registered in the media type registry first, which is a rather high 
> bar anyway. But maybe that is not what the WG had in mind.

I didn't get that from the text in version 14 or 15. But I might have 
read it wrong. (It happens.)

> than an entirely new media type.

I think you are likely correct.

>> Does that mean you don't think people will use undocumented 
>> media-types due to the lack of interoperability, or that anyone who 
>> does will be effectively proprietary and we should assume they don't 
>> want to interoperate in the first place?
>
> Both :-).
>