--- 1/draft-ietf-cbor-cddl-control-00.txt	2020-11-17 12:13:14.444278851 -0800
+++ 2/draft-ietf-cbor-cddl-control-01.txt	2020-11-17 12:13:14.468279460 -0800
@@ -1,18 +1,18 @@
 
 Network Working Group                                         C. Bormann
 Internet-Draft                                    Universität Bremen TZI
-Intended status: Informational                         29 September 2020
-Expires: 2 April 2021
+Intended status: Informational                          17 November 2020
+Expires: 21 May 2021
 
                  Additional Control Operators for CDDL
-                    draft-ietf-cbor-cddl-control-00
+                    draft-ietf-cbor-cddl-control-01
 
 Abstract
 
    The Concise Data Definition Language (CDDL), standardized in RFC
    8610, provides "control operators" as its main language extension
    point.
 
    The present document defines a number of control operators that did
    not make it into RFC 8610: ".cat"/".plus" for the construction of
    constants, ".abnf"/".abnfb" for including ABNF (RFC 5234/RFC 7405) in
@@ -27,21 +27,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at https://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 2 April 2021.
+   This Internet-Draft will expire on 21 May 2021.
 
 Copyright Notice
 
    Copyright (c) 2020 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents (https://trustee.ietf.org/
    license-info) in effect on the date of publication of this document.
    Please review these documents carefully, as they describe your rights
@@ -53,25 +53,25 @@
 Table of Contents
 
    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
      1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
    2.  Computed Literals . . . . . . . . . . . . . . . . . . . . . .   3
      2.1.  String Concatenation  . . . . . . . . . . . . . . . . . .   3
      2.2.  Numeric Addition  . . . . . . . . . . . . . . . . . . . .   4
    3.  Embedded ABNF . . . . . . . . . . . . . . . . . . . . . . . .   4
    4.  Features  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
-   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
+   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .   9
    7.  Security considerations . . . . . . . . . . . . . . . . . . .   9
    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
      8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
-     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10
 
 1.  Introduction
 
    The Concise Data Definition Language (CDDL), standardized in RFC
    8610, provides "control operators" as its main language extension
    point.
 
    The present document defines a number of control operators that did
@@ -282,28 +282,44 @@
    specification that does not yet describe a specific future feature to
    identify the extension point the feature can use, accepting such
    extensions while marking them as such.
 
    The ".feature" control annotates the target as making use of the
    feature named by the controller.  The latter will usually be a
    string.  A tool that validates an instance against that specification
    may mark the instance as using a feature that is annotated by the
    specification.
 
+   More specifically, the tool's diagnostic output might contain the
+   controller (right hand side) as a feature name, and the target (left
+   hand side) as a feature detail.  However, in some cases, the target
+   has too much detail, and the specification might want to hint the
+   tool that more limited detail is appropriate.  In this case, the
+   controller should be an array, with the first element being the
+   feature name (that would otherwise be the entire controller), and the
+   second element being the detail (usually another string).
+
+   foo = {
+     kind: bar / baz .feature (["foo-extensions", "bazify"])
+   }
+   bar = ...
+   baz = ... ; complex stuff that doesn't all need to be in the detail
+
    Figure 4 shows what could be the definition of a person, with
    potential extensions beyond "name" and "organization" being marked
    "further-person-extension".  Extensions that are known at the time
    this definition is written can be collected into "$$person-
    extensions".  However, future extensions would be deemed invalid
    unless the wildcard at the end of the map is added.  These extensions
    could then be specifically examined by a user or a tool that makes
-   use of the validation result.
+   use of the validation result; the label (map key) actually used makes
+   a fine feature detail for the tool's diagnostic output.
 
    Leaving out the entire extension point would mean that instances that
    make use of an extension would be marked as whole-sale invalid,
    making the entire validation approach much less useful.  Leaving the
    extension point in, but not marking its use as special, would render
    mistakes such as using the label "organisation" instead of
    "organization" invisible.
 
    person = {
      ? name: text