[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Wordsmithing



Based on input from Graham, Koen, and Al, I have done a little
bit more wordsmithing on the current draft, prior to sending
it up to the ADs for IETF last call.  The basic edits are:

* Fixed various typos
* Re-changed content feature to media feature where needed
* In 2.1 changed

    Media feature tags represent individual and simple dimensions of
    feature capability.  Examples of features related to media
    are:

to

    Media feature tags represent individual and simple characteristics
    related to media capabilities or properties associated with the
    resource to which they are applied.  Examples of such features are:

and

    A media feature tag identifies a single dimension of characteristic.
    Tag values should use the data types defined in 2.3.

to

    Each media feature tag identifies a single characteristic.
    Values associated with a specific tag must use the data type
    defined for that tag.  The list of allowed data types is
    presented below, in section 2.3.

* Changed the font examples to match Graham's proposal
* Changed the order of data types in 2.3 to match Graham's
* Updated the tspecials delimter
* Changed the language related to URL tree to read:

    leading facet "u.". The leading facet u. is followed by a URI [9]
    which conforms to the character limitations specified in this
    document.  The author of the URI is assumed to be registration
    authority regarding features defined and described by the content
    of the URI.

* Changed the registration form entry for listing tag values to:

    Values appropriate for use with this feature tag:

* Updated the language associated with Boolean tags to read:

      [ ] 1. The feature tag is Boolean and may have values of
           TRUE or FALSE.   A value of TRUE indicates an available
           capability.  A value of FALSE indicates the capability
           is not available.

     | If you wish to indicate two mutually exclusive possiblities
     | that cannot be expressed as the availability or lack of a
     | capability, use a two-token list, rather than a Boolean value.


Many thanks for all the wordsmithing help; comments on the
updated language as soon as possible, please!

			regards,
				Ted Hardie
				NASA/STX