Subject: Re: snmpconf PM-09 character constants

From: Steve Waldbusser <[email-masked]>
Date: Tue, 04 Dec 2001 01:56:30 -0800

Hi Randy,

  I see your point. Are there any objections?

Steve

[email-masked] wrote:

> Hi -
>
> A closer reading reveals some problems in the
> description of string and character processing in
> <draft-ietf-snmpconf-pm-09.txt> that need to be nailed down.
>
> I believe a net simplification of the language is possible
> by elimination of the char_constant and c_char productions,
> since there appears to be no cases where these are needed.
> Furthermore, the current definitions run into trouble when
> the document says:
>
> |   char_constant     Return the string of length one containing
> |                     the value of the input argument.
>
> because the underlying definitions
>
> |   non_quote:  Any character in the UTF-8 character set
> |               except single quote ('), double quote ("),
> |               backslash ('\') or newline.
> |
> |   c_char:            non_quote | '"' | escape_seq
>
> and
>
> | The String type is the set of all finite ordered sequences of
> | zero or more 8-bit unsigned integer values ("elements"). The
> | string type can store textual data as well as binary data
> | sequences. Each element is regarded as occupying a position
> | within the sequence. These positions are indexed with
> | nonnegative integers. The first element (if any) is at
> | position 0, the next element (if any) at position 1, and so
> | on. The length of a string is the number of elements (i.e.,
> | 8-bit values) within it. The empty string has length zero and
> | therefore contains no elements.
>
> conflict.  Specifically, if we have a character whose
> code-point is greater than 127 in one of these char_constants,
> the UTF-8 encoding will take more than one 8-bit element.
> Since there's currently nothing that actually needs
> char_constant, the simplest way to solve this conflict
> is to simply eliminate the production.
>
> Secondly, I think section 6.2.1's second paragraph should
> be explicit that the string representation is UTF-8,
> since much other string processing relies on this.
>
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  [email-masked]  2141 North First Street
>  Tel: +1 408 546-1006   San José, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------