[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New -reg- draft
At 17:20 09/07/98 -0700, Ted Hardie wrote:
>Please read the draft carefully and comment as soon
>as possible.
Ted,
I have some comments below -- mostly of the nit-picking variety.
#g
[...]
>TABLE OF CONTENTS
>
> 1 Introduction
>
> 2 Media feature tag definitions
> 2.1 Media eature tag purpose
...............^ typo
> 2.2 Media feature tag syntax
[...]
>2 Media feature tag definitions
>
>2.1 Media feature tag purpose
>
> Media feature tags represent individual and simple dimensions of
.....................[---------] "identify"
> feature capability. Examples of features related to media
> are:
Something I noticed here and elsewhere is that the concepts of "feature
tag" (a name) and "feature value" (some value) seem to be a bit muddled.
The case above is an example. I'll point out others as I go through.
> * the color depth of the screen on which something is to be displayed
> * the type of paper available in a printer
> * the support of the `floating 5 dimensional tables' feature
> * the fonts which are available to the recipient
> * the capability to display graphical content
>
> A media feature tag identifies a single dimension of characteristic.
> Tag values should use the data types defined in 2.3.
>
> Examples of media feature tags with values are:
The examples that follow don't actually include feature *tags*. Also, some
don't relate to individual media features. Thus, I suggest:
"Examples of media features are:"
> * the width of a display in pixels per centimeter represented as an
> integer value.
> * the fonts available to a recipient as an enumerated list.
The set of fonts would be several feature values. I would suggest:
"a font available to a recipient, selected from an enumerated list"
On reflection, this is an interesting case as it exposes a flaw in some of
my thinking. Feature values are defined as simple scalars, and a feature
collection has formally been treated as a finite map, which means each tag
appears only once. I think it will be necessary to allow repeated feature
tags in a feature collection, to capture cases like that of a single
document that uses multiple fonts (which is the general thrust in section 3
of -algebra-. I don't think this has any difficult ramifications, but it
needs to be dealt with in a consistent fashion.
> * the version of a protocol composed of integers "i.j.k", defined as
> either a value in an enumerated list or with a defined mapping to
.................[--]"selected from"...^ insert ','
> make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k,
> assuming j<=9 and k<=9).
>
> Further examples of media feature tags are defined in detail
............................[------------]"features, and their tags,"
> elsewhere [4].
>
> Feature collections may be composed using a number of individual
> feature tags [2]. Composition of feature collections is described
...............^ "and associated values"
> elsewhere [2]. Examples of feature collections requiring multiple
> media feature tags are:
>
> * the width and height of a display
> * the combination of color depth and resolution a display can support
In view of my comments above, maybe add:
"* the set of all fonts used by a document"
[...]
>2.2 Media feature tag syntax
>
> A media feature tag is a string consisting of one or more of the following
> US-ASCII characters: uppercase letters, lowercase letters, digits,
> colon (":"), slash ("/"), dot (".") percent ("%"), and dash
> ("-"). Feature tags are case-insensitive. Dots are understood to
> potentially imply heirarchy; a feature can be subtyped by describing
> it as tree.feature.subfeature and by indicating this in the
> registration. Tags should begin with an alphabetic character.
A passing thought: this desription suggested to me that maybe X- and Y-
values (pix-x, pix-y, res-x, res-y, etc.) should be described by faceted
values (pix.x, pix.y, etc.)
[...]
>2.3 Media feature tag values
>
> The registry will initially support the use of the following data
> types as tag values:
>
> - signed integers
> - rational numbers
> - tokens, with equality relationship
> - strings, with equality relationship
> - strings, with defined comparison
> - ordered tokens
I would suggest a slight re-arrangement of the above:
# - signed integers
# - rational numbers
# - tokens, with equality relationship
# - tokens, with defined ordering relationship
# - strings, with standard (octet-by-octet) equality relationship
# - strings, with defined equality and/or ordering relationships
> "Token" here means the token data type as defined by [7],
> which may be summarized as:
>
> token = 1*<any CHAR except CTLs or tspecials>
>
> tspecials = "(" | ")" | "<" | ">" | "@"
> | "," | ";" | ":" | "\" | <">
> | "/" | "[" | "]" | "?" | "="
> | "{" | "}" | SP | HT
Two nits:
(1) 'tspecials' is correct for RFC 2068, but I believe that in the latest
HTTP drafts it has been renamed to avoid a clash with the MIME specs.
(2) this document cites RFC2245, but the above syntax description does not
conform (uses '|' instead of '/'). (Personally, I prefer '|', but that
doesn't seem to be the way the wind is blowing.)
[...]
>2.3 ASN.1 identifiers for media feature tags
>
> Certain protocols use ASN.1 identifiers rather than human-readable
> representations for capability exchange. In order to allow both
> systems to interoperate, registrants may provide an ASN.1 identifier
> or ask that IANA assign an ASN.1 identifier during registration.
> These identifiers are not required for registration, but may provide
> assistance to those building gateways or other cross-protocol
> systems. Note that ASN.1 identifiers assigned by IANA will be
> treated as tokens, not as elements from which sub-delegated
> identifiers may be created or derived.
Good point! (The last sentence.)
[...]
>3.1.2 Global tree
>
> Tags in the global tree will be distinguished by the leading facet
> "g.". An organization may propose either a designation indicative
> of the feature, (e.g., "g.blinktags") or a faceted designation
> including the organization name (e.g., "g.organization.blinktags").
> Organizations which have registered media types under the MIME
> vendor tree should use the same organizational name for media
> feature tags if they propose a faceted designation.
Is there potential here for conflict over the use of organizational names?
> [...] The acceptance
> of the proposed designation is at the discretion of the IANA.
> If the IANA believes that a designation needs clarification
> it may request a new proposal from the proposing organization
> or otherwise coordinate the development of an appropriate
> designation.
Is this possibly a bit vague for IANA considerations? Isn't this covered
by the "expert review" policy? I think that, given "expert review", this
text might be deleted.
[...]
>3.2 Location of registered feature tag list
>
> Feature tag registrations will be posted in the anonymous FTP
> directory:
> "ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/";
> and all registered feature tags will be listed in the periodically
> issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. The
> feature tag description and other supporting material may also be
> published as an Informational RFC by sending it to "rfc-
> editor@xxxxxxx" (please follow the instructions to RFC authors [RFC-
> 1543]).
[RFC-1543] is an inconsistent form of citation, and is not included in the
references.
[...]
>3.4 Registration template
>
> To: ietf-media-feature-tags@xxxxxxxx (Media feature tags mailing list)
> (or directly to iana@xxxxxxxx)
> Subject: Registration of media feature tag XXXX
>
>
> | Instructions are preceded by `|'. Some fields are optional.
>
> Media feature tag name:
.....................[----] delete?
> ASN.1 identifier associated with feature tag: [optional]
>
> | To have IANA assign an ASN.1 identifier,
> | use the value "New assignment by IANA" here.
>
> Summary of the media feature indicated by this feature tag:
>
> | Include a short (no longer than 4 lines) description or summary
> | Examples:
> | `Use of the xyzzy feature is indicated by ...'
> | `Support of color display is indicated by ...'
> | `Number of colors in a palette which can be defined ...'
>
> Number of possible values associated with this feature tag:
>
> [ ] 1. The feature tag is Boolean and the feature tag has no
> associated value. A value of TRUE indicates the availability
> of the feature. A value of FALSE indicates the feature
> is not available
The idea of "no associated value" seems wrong: the associated value is
TRUE or FALSE.
I have two issues with this use of a Boolean value indicating "avalability":
(1) in some occurrences, a TRUE value might indicate a _requirement for_
rather than _availability of_ a feature. If a document is intended for
double-sided printing, indicating "duplex=TRUE" doesn't really indicate
availability of a feature.
(2) Boolean values can also be used to indicate two mutually exclusive
possibilities. E.g. "hardcopy=TRUE" and "hardcopy=FALSE" could indicate
printing and display terminals respectively. (It is arguable that this
case is better handled by a two-valued token enumeration. In some ways,
that is exactly how I view Boolean.)
How about TRUE indicating "a capability that may be exercised", and FALSE
indicating the "absence or converse of that capability"?
> [ ] 2. The feature has an associated numeric or enumerated value.
>
>
> For case 2: Indicate the data type of the value:
>
> [ ] 2a. Signed Integer
> [ ] 2b. Rational number
> [ ] 2c. Token (equality relationship)
> [ ] 2d. Token (ordered)
> [ ] 2e. String (equality relationship)
> [ ] 2f. String (defined comparison)
>
> |IMPORTANT: You may only chose one of the above data types.
>
>
> (Only for case 2) Detailed description of the feature value meaning,
> and of the format and meaning of the feature tag values
> for the alternative results.
>
> | If you have selected 2d you must provide the ordering mechanism
> | or a full and ordered enumeration of possible values. If you
> | have selected 2f, you must provide a defintion of the comparison.
> | Definitions by included reference must be to stable and readily
> | available specifications:
> |
> | If the number of alternative results is small, you may
> | enumerate the identifiers of the different results and describe
> | their meaning.
> |
> | If there is a limited useful numeric range of result (2b, 2c),
> | indicate the range.
Add: "including whether values may be negative" ?
> | The identifiers of the alternative results could also be
> | described by referring to another IANA registry, for example
> | the paper sizes enumerated by the Printer MIB.
>
> The feature tag is intended primarily for use in the following
> applications, protocols, services, or negotiation mechanisms:
> [optional]
>
> | For applications, also specify the number of the first version
> | which will use the tag, if applicable.
>
> Examples of typical use: [optional]
>
> Related standards or documents: [optional]
>
> Considerations particular to use in individual applications,
> protocols, services, or negotiation mechanisms: [optional]
>
> Interoperability considerations: [optional]
>
> Security considerations:
>
> Privacy concerns, related to exposure of personal information:
>
> Denial of service concerns related to consequences of specifying
> incorrect values:
>
> Other:
>
> Additional information: [optional]
>
> Keywords: [optional]
The purpose of this entry is not clear to me.
> Related feature tags: [optional]
>
> Related media types or data formats: [optional]
>
> Related markup tags: [optional]
The purpose of this entry is not clear to me.
[...]
That's all folks!
#g
------------
Graham Klyne
(GK@xxxxxxx)