IESG comments on draft-ietf-vpim-hint

Overall, draft-ietf-vpim-hint is a clean specification. Message-Context is a
rather powerful feature, since it provides a signal to an application to
organize its behaviors in possibly comprehensive ways.  The IESG believes that
it should be used only when the quality of a message-context-class has been
well-reviewed and has good support, and that therefore the vendor-specific type
of message context-classes should not exist.  

Having them exist and require nothing more than IANA registration is
inconsistent with the well-taken points in the security considerations about
ways that poorly designed or abused hints can cause trouble.

The change the IESG proposes is simply to eliminate the "vnd." form and the
language about just registering these, in favor of all future ones following
the IANA considerations and having an RFC specification.

Old:

> 
>         vnd.token = <Vendor-specific, private token> 
>     
>    Note: The values for Message-Context must be either IANA registered 
>    values or experimental, vendor tokens.  This ensures that user 
>    agents from different vendors will interoperate and perform in a 
>    uniform manner without an undue burden on the vendors. 
>     

New:

> 
>    Note: The values for Message-Context must be either IANA registered 
>    values following the directions in the IANA Considerations.
>     

Other references to vnd in the ABNF need to be deleted.

This new text is consistent with the i-d's IANA Considerations.
The current IANA Considerations is reasonable (Spec Required).

Additional fixes are needed in the ABNF, as follows:

- It needs to use the RFC 2234 form, which means '/' not '|' and it
  needs to cite 2234.
- The registration reference to Section 8 should be to Section 9.
- Prose values (<...>) may not have carriage returns in them, so the
  definition of "token" is bad.
- It isn't clear if the "[8]" is a reference to RFC 2045 or to section 8.

If the authors and WG insist that a vnd registration is needed,
the IESG wants to insist on it being Specification Required anyway.  If
we do allow "vnd", the ABNF has two more errors to fix.

- Rule names may not have periods, so "vnd.token" should be renamed to
  "vnd-token" (or something).
- vnd-token doesn't set requirement to start with "vnd." as it is now.

				Ned
----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email protected]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo