Randy Turner <rturner at sharplabs.com> wrote:
>> I uploaded a copy of my proposal to revise David Kellerman's
> earlier prtMagicCookie channel fix. The document is in:
>>ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.doc>> I'm assuming this is one of the topics for the teleconference.
>> R.
I've put a plain text version of Randy's document on the server
as ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.txt
And, since its only a bit over a page long, I'm taking the liberty
to also append it to the end of this message.
/Jeff
---------------------------------------------------------------
Jeffrey D. Schnitzer | Email: jds at underscore.com
Underscore, Inc. | Voice: (603) 889-7000
41-C Sagamore Park Rd | Fax: (603) 889-2699
Hudson, NH 03051-4915 | Web: http://www.underscore.com
---------------------------------------------------------------
--Text of ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.doc
from Randy Turner <rturner at sharplabs.com>, 15 Oct 1996:
At the New York meeting of the PWG, the attendees decided that the
prtMagicCookie string should be both human readable, as well as
unambiguously
machine parsable. This proposal seeks to elaborate on the earlier
prtMagicCookie proposal with a mechanism to allow both of these features
to be
supported by the prtMagicCookie string.
For purposes of clarity, I would like to suggest that the data type
used
to represent the prtMagicCookie string be a "DisplayString" object type.
This
forces implementers to make sure that this string is displayable and
human
readable. In addition, I would like to propose that a prtMagicCookie
"grammar"
be used to describe the contents of this string. The rationale behind
the
grammar is to solve the machine-parsability requirement decided on
previously. This cookie grammar or syntax would also be human readable
and
could be stored in the MIB as an additional object within the channel
group,
or, it could be a requirement for registering channel types and
associated
applications in a global registry managed by IANA or other sanctioned
organization.
I would like to propose two solutions to the grammar/syntax string.
The
first proposal would be that we use a standard C language scanf/printf
format
string to describe the contents of the prtMagicCookie string. As an
example,
to describe an implementation of LPD within an agent that implements
several
control file extensions such as Sun or Xerox, the following syntax
string could
be used:
"Line Printer Daemon (LPD) Vendor %s Version %d Port %d Options %s"
In this example, an automated job delivery client attempting to discover
how to
send jobs to LPD would know that LPD is supported through the
prtChannelType. It could then read the syntax string and discover which
vendor's implementation is being used, the version number, the TCP port
used
for this implementation, as well as any extended control file options
not
specified by the RFC 1179 standard; this options string could consist of
control file option letters like "W,Z,X" or some other string. Likewise,
a
Novell print server could utilize a grammar string like:
"Novell PSERVER %s Fileserver %s Options %s"
This would give potential print clients the PSERVER name for this
printer, as
well as a preferred file server on which the queues for this PSERVER
reside. Other options could also be specified as well in the "Options"
string.
The syntax/grammar specification would be owned by the vendor or
organization
that is registering the channel type. Again, this proposal does not
suggest
whether this syntax/grammar string is implemented as an object within
the MIB,
or as a required field in a channel type registration form. The format
of the
grammar/syntax string can be taken verbatim from the standard ANSI C
language
description of the printf/scanf format descriptor.
Another descriptor format that could be used would be a Backus-Naur
Format
(BNF) syntax for the grammar/syntax string. This is somewhat more
powerful than
the previous print/scanf format, and allows optional fields to be
inserted in
the string. Instead of BNF, a regular expression could be used/specified
to
describe the contents of the DisplayString fields. In my opinion, the C
language printf/scanf format string would be easier to implement and
meet most
of our requirements.
--