Jay,
In response to your comments regarding my recent suggestions for
the new draft:
>> page #33,34: Add the following descriptions for PrtChannelTypeTC.
>>>> chLPDServer(8), --TCP port 515, RFC 1179
>> chFTP(13), --RFC 959
>> chTFTP(14), --RFC 1350
>> chIBM3270(16), --IBM Coax Data Stream
>> chIBM5250(17), --IBM Twinax Data Stream
>> chDECLAT(32), --Local Area Transport Protocol
>> --Digital Equipment Corp.
>> We should strive for consistency whenever possible, particularly if
> doing so requires very little work, right? If so, then if a particular
> Channel Type may be referenced by an RFC number, let's just make that
> RFC reference the only description. Also, the naming conventions should
> be consistent; for example, the above items should be:
>> chLPD(8), --RFC 1179
> chFTP(13), --RFC 959
> chTFTP(14), --RFC 1350
Addition of the port number would be helpful, but consistency is
essential. The RFC numbers must definitely be included. Knowing
the RFC number, one can easily find the port.
> Similarly, we should probably normalize channel type "names" with respect
> to the "sponsoring vendor names", for example:
>> chIBM3270(16), --Coax Data Stream
> --IBM
> chIBM5250(17), --Twinax Data Stream
> --IBM
> chDECLAT(32), --Local Area Transport Protocol
> --Digital Equipment Corp.
I would agree with this. Right now there is no description for the two
IBM channels.
>> page #105: The end of the description of prtConsoleDisplayBufferIndex
>> should read:
>>>> "...values are normally expected to remain stable across
>> successive power cycles."
>> Does the term "normally" make it sound to wishy-washy with respect to
> conformance? How about leaving out that word so the phrase reads:
>> "...values are expected to remain stable across successive
> power cycles."
Taken out of context, you are correct. However, if you read the
entire paragraph it appears to be conflicting. (i.e. I interpret
the existing text to say; "The values may change but are expected
to remain stable".) Addition of what appears to be "wishy-washy",
IMHO clarifies the intention.
"A unique value for each console line in the printer. The
value is used to identify this console line. Although
these values may change due to a major reconfiguration of
the device (e.g. the addition of new console lines to the
printer), values are expected to remain stable across
successive printer power cycles."
I propose the following new paragraph:
"A unique value for each console line in the printer. The
value is used to identify this console line. Although
these values may change due to a major reconfiguration of
the device (e.g. the addition of new console lines to the
printer), *the* values are *normally* expected to remain stable
across successive printer power cycles."
>> page #76: The description for prtMarkerIndex should read...
>>>> "A unique value used by the printer to identify this marking
>> subunit. ..."
>> These index values should be expected to remain consistent across power-
> cycles, right?
What??? My comment here is that the present text reads:
"A unique value used by the printer to identify this marking
SubUnitStatus."
>> page #90: The third paragraph under "The Channel Group" should read:
>>>> "Channel Table describes the installed capabilities of the
>> printer. ..."
>> Are we looking at the same draft? (I'm looking at the Postscript version
> of what was put on the ftp server a couple of weeks ago, where the content
> is a "marked-up" (ie, red-lined) version of the draft.)
>> No matter what, wouldn't it be overly confusing to have such a sentence in
> that group that does not qualify what "capabilities" are? Perhaps it should
> read something like:
>> "Channel Table describes the installed print job delivery
> capabilities of the printer. ..."
Again, the current draft reads:
-- The Print Job Delivery Channel table describes the capabilities of the
-- printer and not what is currently being performed by the printer.
The change to the wording was discussed and agreed to in a past meeting.
(I believe that it was proposed by Steve Zilles.) I feel it is a simpler
way to say what is intended in the current wording. I am not proposing
a new definition or meaning.
>> And for chTransport1(20), the description "This RFC should also be
>> referenced for other channel enumerations utilizing TCP port numbers
>> 0 through 1024." sounds more like a reminder to the editor to add
>> some new text. This note does not appear to be applicable to most
>> of the ports in this range. It would be best if the note were added
>> only to those ports that required this additional information.
>> Otherwise, it will be very difficult to use the RFC as a reference
>> document. (I do not see any other enums that require this note!)
> And of course, I've saved the best for last... ;-)
>> It might be useful to recall a posting by Dave Kellerman whereby the
> historical background of "Transport1" is described:
---BOOM--- I stepped on a land mine here! Looks like this will
require a little more work. I will volunteer to make a proposal
within a week. (Gee, I thought is was a simple suggestion!)
Ron Bergman
Dataproducts Corp
rbergma at dpc.com