prtMagicCookie updated proposal

prtMagicCookie updated proposal

prtMagicCookie updated proposal

Jeff Schnitzer jds at
Tue Oct 15 10:26:54 EDT 1996

Randy Turner <rturner at> wrote:
> I uploaded a copy of my proposal to revise David Kellerman's
> earlier prtMagicCookie channel fix. The document is in:
> 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

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.

Jeffrey D. Schnitzer      |   Email:  jds at 
Underscore, Inc.          |   Voice:  (603) 889-7000
41-C Sagamore Park Rd     |     Fax:  (603) 889-2699   
Hudson, NH  03051-4915    |     Web:

--Text of 
  from Randy Turner <rturner at>, 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
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
to represent the prtMagicCookie string be a "DisplayString" object type.
forces implementers to make sure that this string is displayable and
readable. In addition, I would like to propose that a prtMagicCookie
be used to describe the contents of this string.  The rationale behind
grammar is to solve the machine-parsability requirement decided on
previously. This cookie grammar or syntax would also be human readable
could be stored in the MIB as an additional object within the channel
or, it could be a requirement for registering channel types and
applications in a global registry managed by IANA or other sanctioned

    I would like to propose two solutions to the grammar/syntax string. 
first proposal would be that we use a standard C language scanf/printf
string to describe the contents of the prtMagicCookie string. As an
to describe an implementation of LPD within an agent that implements
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
for this implementation, as well as any extended control file options
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,
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"

The syntax/grammar specification would be owned by the vendor or
that is registering the channel type. Again, this proposal does not
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
description of the printf/scanf format descriptor.

Another descriptor format that could be used would be a Backus-Naur
(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
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.


More information about the Pwg mailing list