prtMagicCookie updated proposal

prtMagicCookie updated proposal

prtMagicCookie updated proposal

David_Kellerman at nls.com David_Kellerman at nls.com
Thu Oct 17 22:30:39 EDT 1996


Randy's proposal for the prtChannelInformation object (aka MagicCookie)
makes some interesting suggestions in the direction of making the data
human readable, but I'm concerned that it tries to go too far in that
direction.  I'd like to suggest an alternative that addresses the issue
of human-readability in a more limited way. 


Briefly, I can see several areas of concern with the "scanf" approach
suggested by Randy: localization issues; problems with extracting
the data values from the surrounding text (quoting problems); encoding
of optional values is still open. 


object is to benefit software that is using the MIB to determine how to
interact with the printer (for job submission, in particular), and in
this context it serves to "bootstrap" to connection.  I won't try to
repeat the long justification in my earlier note on this subject, but I
still believe this is true. 


I also believe we should focus on keeping this thing small, not
speculative -- define prtChannelInformation requirements for channel
types where it clearly has a practical use, and require data values that
clearly are needed for well-defined reasons.  You ought to be able to
say, "we need item X for channel type Y because it is needed for
application Z that really is going to be implemented."  I believe there
are only a small set of candidates that can currently be justified this
way -- add others later if necessary. 


In my original prtMagicCookie proposal, the idea was that the
information string be "human-readable" in a fairly simple way.  It was
clear that the data placed in the string would be a grab-bag of things,
and it was necessary to reduce it all to some common format -- hence the
idea of using the conventional human-readable representation of the
data.  I hadn't meant to suggest that someone be able to read off the
value without benefit of a specification -- I would say this is both
unnecessary and too ambitious. 


All that said, here is an alternate suggestion for encoding the
prtChannelInformation: 


 1. The prtChannelMagicCookie value may contain information that is not
    normally coded in human-readable form.  In these cases, whatever
    symbolic representation is conventionally used for the information
    is used for encoding the prtChannelMagicCookie.  (For instance, a
    binary port value might be encoded as a decimal number.) 


 2. If the prtChannelInformation consists of multiple values, they are
    listed in a specified order, separated by linefeed characters. 


 3. If the prtChannelInformation includes optional values, they are
    listed following the required values, each preceded by an
    identifying tag consisting of alphabetic characters and a space. 


 4. The encoding defined for a particular channel type may also specify
    a way to indicate that part or all of the value is 'unknown'. 


 5. The symbolic representation (if any) of values, the specified order
    of multiple values, the tags used to identify optional items, and
    the representation of unknown items (where allowed) shall all be
    specified in the descriptive text associated with the PrtChannelType
    enumeration value for which the prtChannelInformation is required. 


I think this approach is one that will allow a software application to
simply and unambiguously decode the prtChannelInformation.  It isn't as
"human-readable."  But I haven't seen the justification for more
human-readability (in either meeting minutes or e-mail), and I can't
convince myself that more is needed. 


These are cases I can readily justify defining prtChannelInformation
values: 


    chLPDServer         -- printer queue name
    chPort9100          -- TCP port number, represented as decimal value
    chPortTCP           -- TCP port number, represented as decimal value
    chBidirPortTCP      -- TCP port number, represented as decimal value


    Note: The chPort9100 entry ought to be redundant, but are there any
        existing interfaces that implement a Printer MIB that claims a
        chPort9100 channel that is implemented on a channel other than
        9100?  (HP's JetDirect server uses a different port for each
        attached printer, for instance, but doesn't implement a Printer
        MIB, as far as I know.) 


This is also possible; I just don't know if it would ever get used: 
    chDECLAT            -- two optional values, one of which must be present:
                        --   port name (tag P)
                        --   service name (tag S)


This may not be an exhaustive list -- these are just the only instances
I can justify. 


That's my two-bits worth.  What do you think? 


::  David Kellerman         Northlake Software      503-228-3383
::  david_kellerman at nls.com Portland, Oregon        fax 503-228-5662



More information about the Pwg mailing list