Ron,
Some comments your recent suggestions for the new draft:
> page #14: There are now two definitions of Busy. The minutes
> indicate there was some discussion regarding Busy but
> what were the results?
This remains a very critical issue, particularly for us host-side
management app developers. We really need to nail this one down,
and quickly.
> 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
Note that the substring "Server" was removed from LPD, as it is completely
superfluous. (There is the concept of a "LPD client", but there is also
the concept of a "FTP client "and a "TFTP client"; also, both FTP and TFTP
both have assign TCP port numbers, same as LPD.)
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 don't believe this is quite as important as the RFC-oriented references
above, though.
> 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."
> 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?
> 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. ..."
> 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:
> From nls.com!davek Tue Mar 12 19:33:46 1996
> Date: Tue, 12 Mar 1996 16:10:01 PST
> From: David Kellerman <davek at nls.com>
> To: pmi at hpbs987.boi.hp.com> Subject: Re: prtChannelType description clarifications
>> Jay Martin wrote:
>> >Ron Bergman wrote:
> >> chTransport1(20), -- TCP Port 35
> >
> >I kinda have a problem with this naming convention. I mean,
> >what is the significance of saying "Transport1" to imply the
> >use of TCP port number 35?
> >
> >Is the use of TCP port 35 what a particular vendor uses in
> >a proprietary product? Or is it a defacto standard of some kind,
> >in the same manner as TCP port 9100 is used (as established by
> >HP, but support by lots of other vendors because HP does it)?
>> Ron, Jay,
>> In case the identity of this "Transport1" protocol has gotten lost,
> here is some verbiage that may help specify it in more detail.
> (Unless you're trivia buffs, the rest of you might as well stop
> reading here.)
>> TRANSPORT1 is a printing protocol that originated with IMAGEN
> Corporation. QMS acquired IMAGEN and carried over TRANSPORT1
> support to some of their printers. Kodak OEM'ed technology from
> IMAGEN and QMS and the protocol is supported by some of their
> high-volume printers. Those are the only vendors using the
> protocol that I know of. There is considerable variation
> (read incompatibility) between implementations.
>> Key characteristics:
> o Client opens connection on printer port 35, transfers print
> data stream, closes connection to indicate end of data.
> o Data transfer is uni-directional.
> o Companion SENSE1 protocol uses UDP datagram query/response
> on printer port 35 for printer status inquiries. There are
> two variants of SENSE1 -- one used by IMAGEN and Kodak, the
> other used by QMS. Not present with all TRANSPORT1
> implementations.
> o Companion ACCOUNTING1 protocol uses UDP datagrams to deliver
> job accounting information to accounting clients. Not
> present with all TRANSPORT implementations.
> o Companion DQP protocol uses UDP datagrams on printer port 36
> to schedule client requests for printing. Present only with
> some Kodak implementations.
>> There are reference texts from IMAGEN, QMS and Kodak that
> describe the various implementations. I don't know who has the
> best claim of "ownership" of the protocol at this point.
>> Hopefully, you can distill a couple sentences of useful
> identification out of all that.
If "chTransport1" is indeed supposed to reflect job delivery using the
protocol Dave has described, then why don't we assign one of those companies'
names to the channel type?
Or is "chTransport1" supposed to be the channel type designation for the
simple "virtual stream" protocol used by so many printer and interface
vendors (eg, Emulex uses TCP port 2501, etc)? If this is the case, then
some simple words should be added to refer to the "prtChannelWart" object
(or whatever its name is) to resolve the target TCP port number.
...jay