I withdraw this proposal.
Tom
At 11:44 07/16/97 PDT, David_Kellerman@nls.com wrote:
>> There are several places in the Printer MIB where a LF by itself
>> is indicated as the way to separate lines. But US-ASCII and NVT ASCII
>> both specify that lines are ended with the two character sequence
>> CR (carriage return = decimal 13) and LF (line feed = decimal 10).
>> If you send ONLY a LF to a display console (eg, an NMS), you will NOT
>> reposition to the first column for the next fragment and these strings
>> will be displayed incorrectly (as a cascade to the right).
>> This is because LF is only a vertical motion in US-ASCII and NVT ASCII.
>> It is UNIX and C that have the convention that LF by itself is a new-line.
>>
>> The following objects are affected:
>>
>> 1. The 'prtChannelInformation' object specifies ONLY an LF (line feed)
>> as a delimiter and NOT a CR/LF pair (consistent with MIME mail and HTTP
>> header usage, US-ASCII and NVT ASCII usage).
>
>Leave it alone. We dicusssed this extensively when working on the
>prtChannelInformation object. Tom, if you recall, at one point you were
>advocating using a vertical bar (|) as the delimiter, and you ended up
>agreeing to the use of linefeed (with the suggestion that we indicate
>its code value in the description).
>
>There's a long discussion in the e-mail, but the gist of it is that the
>prtChannelInformation is intended primarily as machine-readable
>material, not human-readable text. The NVT ASCII encoding was chosen
>primarily as a way of "normalizing" the grab-bag of things that had to
>be encoded in the object. The linefeed delimiter was chosen somewhat
>arbitrarily (any value outside of the printable ASCII set would have
>sufficed) -- the important consideration was that it not be a code that
>could appear in an attribute value. In other words, the linefeed is
>just a marker; it's not a formatting code.
>
>:: David Kellerman Northlake Software 503-228-3383
>:: david_kellerman@nls.com Portland, Oregon fax 503-228-5662
>
>