PMP Mail Archive: FW: IPP> Re: PMP> IPP "channel" in the Printer MIB

PMP Mail Archive: FW: IPP> Re: PMP> IPP "channel" in the Printer MIB

FW: IPP> Re: PMP> IPP "channel" in the Printer MIB

lpyoung@lexmark.com
Wed, 19 May 1999 14:14:11 -0400

This request was submitted by Tom last week. There has not been
any discussion on this change since submitted. If someone wants
this change to be incorporated in the Printer MIB, the following
process needs to be followed:
1. Someone needs to submit the exact change that is requested to
be made to the MIB with no unanswered questions. Tom has several valid
unanswered questions in the original request. These questions need to
be answered before a change can be incorporated in the MIB.
2. If an exact change request is submitted to the mailing list, the
proposed change will only be make if a consensus can be reached on
the mailing list. Silence is counted as disagreement.

If no further action is taken on this change then I will assume that
the change is not needed in the Printer MIB.

Lloyd
------- Forwarded by Lloyd Young/Lex/Lexmark on 05/19/99 02:01 PM --------

To: Lloyd Young@LEXMARK
cc: ipp%pwg.org@interlock.lexmark.com, pmp%pwg.org@interlock.lexmark.com
Subject: FW: IPP> Re: PMP> IPP "channel" in the Printer MIB

Lloyd,

Can you add this registration of IPP to the draft Printer MIB for
identifying the job submission channel in the Printer MIB?

chIPP(??),
-- Internet Printing Protocol (IPP)
-- See documents relating to IPP 1.0
-- (RFCs 2565 and 2566).

It would help for people to know what the enum value will be as well.

The reason NOT to use the chPortHTTP (42) is that many printers also have a
web interface for job submission using file up load. They would be using 42
for that, perhaps with a different port number.

However, I think that there is more work than just adding the enum. There
is opportunity to specify the port using a Port: keyword that would have to
be specified in the registration for use in the prtChannelInformation
object.
What else?

The following keywords have been defined for other protocols:

Keyword (meaning) Protocol
------- ------- --------
Name (Printer Name) for AppleTalk PAP
Queue (Printer queue name) for LPD
PServer (Print Server Name), ... for Netware RPrinter
Server (Server Name), PServer (PServer), ... for Netware PServer
Name (Service Name) for SMB
Port (Port Number) for TCP
etc.

We can define any we thing useful for IPP. It would seem to me that the
Port would be helpful.

What about the "printer-name"? Or is that already captured in the new
prtGeneralPrinterName object (that is not in RFC 1759)?

What about the URL of the IPP Printer?

We should specify how the version number is represented in the
prtChannelProtocolVersion object. Since an IPP implementation can support
multiple versions, we probably need to specify the syntax of a list of
version numbers. How about a comma separated list?

For example the text string inside these quotes: "1.1, 1.0"

Someone needs to step up and propose something. This is a case of the IPP
and PMP WGs working together.

Tom

Here is the definition of the Print Job Delivery Channel from the Printer
MIB:

2.2.10 Print Job Delivery Channels

The print job delivery channel sub-units identify the independent
sources of print data (here print data is the information that is
used to construct printed pages and may have both data and
control aspects). A printer may have one or more channels. The
channel sub-units are represented by the Print Job Delivery
Channel Group in the Model. Each channel is typically identified
by the electronic path and service protocol used to deliver print
data to the printer. A channel sub-unit may be independently
enabled (allowing print data to flow) or disabled (stopping the
flow of print data). It has a current Control Language which can
be used to specify which interpreter is to be used for the print
data and to query and change environment variables used by the
interpreters (and SNMP). There is also a default interpreter that
is to be used if an interpreter is not explicitly specified using
the Control Language. Print Job Delivery Channel sub-units can,
and usually are, based on an underlying interface.

Here is more information from the spec about the attributes of each channel:

-- The Print Job Delivery Channel Group

--
-- Implementation of every object in this group is mandatory.
--
-- Print Job Delivery Channels are independent sources of print
-- data. Here, print data is the term used for the information
-- that is used to construct printed pages and may have both data
-- and control aspects. The output of a channel is in a form
-- suitable for input to one of the interpreters as a
-- stream. A channel may be independently enabled (allowing
-- print data to flow) or disabled (stopping the flow of
-- print data). A printer may have one or more channels.
--
-- The Print Job Delivery Channel table describes the
-- capabilities of the printer and not what is currently being
-- performed by the printer
--
-- Basically, the print job delivery channel abstraction
-- describes the final processing step of getting the print data
-- to an interpreter. It might include some level of
-- decompression or decoding of print stream data.
-- channel. All of these aspects are hidden in the channel
-- abstraction.
--
-- There are many kinds of print job delivery channels; some of
-- which are based on networks and others which are not. For
-- example, a channel can be a serial (or parallel) connection;
-- it can be a service, such as the UNIX Line Printer Daemon
-- (LPD), offering services over a network connection; or
-- it could be a disk drive into which a floppy disk with

Turner Printer MIB V2 [Page 110]

INTERNET DRAFT Printer MIB January 22, 1999

-- the print data is inserted. Each print job delivery channel is -- identified by the electronic path and/or service protocol -- used to deliver print data to a print data interpreter.

--
-- Channel example                   Implementation
--
-- serial port channel            bi-directional data channel
-- parallel port channel          often uni-directional channel
-- IEEE 1284 port channel         bi-directional channel
-- SCSI port channel              bi-directional
-- Apple PAP channel              may be based on LocalTalk,
--                                Ethernet or Tokentalk
-- LPD Server channel             TCP/IP based, port 515
-- Netware Remote Printer         SPX/IPX based channel
-- Netware Print Server           SPX/IPX based channel
--
-- It is easy to note that this is a mixed bag.  There are
-- some physical connections over which no (or very meager)
-- protocols are run (e.g. the serial or old parallel ports)
-- and there are services which often have elaborate
-- protocols that run over a number of protocol stacks. In
-- the end, what is important is the delivery of print data
-- through the channel.
--
-- The print job delivery channel sub-units are represented by
-- the Print Job Delivery Channel Group in the Model. It has a
-- current print job control language, which can be used to
-- specify which interpreter is to be used for the print data and
-- to query and change environment variables used by the
-- interpreters (and Management Applications). There is also a
-- default interpreter that is to be used if an interpreter is
-- not explicitly specified using the Control Language.

-- The first seven items in the Print Job Delivery Channel Table -- define the "channel" itself. A channel typically depends on -- other protocols and interfaces to provide the data that flows -- through the channel.

--
-- Control of a print job delivery channel is largely limited to
-- enabling or disabling the entire channel itself. It is likely
-- that more control of the process of accessing print data
-- will be needed over time. Thus, the ChannelType will
-- allow type-specific data to be associated with each
-- channel (using ChannelType specific groups in a fashion
-- analogous to the media specific MIBs that are associated
-- with the IANAIfType in the Interfaces Table). As a first
-- step in this direction, each channel will identify the
-- underlying Interface on which it is based. This is the

Turner Printer MIB V2 [Page 111]

INTERNET DRAFT Printer MIB January 22, 1999

-- eighth object in each row of the table.

-- The Print Job Delivery Channel Table

--
-- The prtChannelTable represents the set of input data sources
-- which can provide print data to one or more of the
-- interpreters available on a printer

prtChannel OBJECT IDENTIFIER ::= { printmib 14 }

prtChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" ::= { prtChannel 1 }

prtChannelEntry OBJECT-TYPE SYNTAX PrtChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each device index with a device type of 'printer'." INDEX { hrDeviceIndex, prtChannelIndex } ::= { prtChannelTable 1 }

PrtChannelEntry ::= SEQUENCE { prtChannelIndex Integer32, prtChannelType PrtChannelTypeTC, prtChannelProtocolVersion OCTET STRING, prtChannelCurrentJobCntlLangIndex Integer32, prtChannelDefaultPageDescLangIndex Integer32, prtChannelState PrtChannelStateTC, prtChannelIfIndex Integer32, prtChannelStatus PrtSubUnitStatusTC, prtChannelInformation OCTET STRING }

prtChannelIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION

Turner Printer MIB V2 [Page 112]

INTERNET DRAFT Printer MIB January 22, 1999

"A unique value used by the printer to identify this data channel. Although these values may change due to a major reconfiguration of the device (e.g. the addition of new data channels to the printer), values are expected to remain stable across successive printer power cycles." ::= { prtChannelEntry 1 }

prtChannelType OBJECT-TYPE SYNTAX PrtChannelTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this print data channel. This object provides the linkage to ChannelType-specific groups that may (conceptually) extend the prtChannelTable with additional details about that channel." ::= { prtChannelEntry 2 }

prtChannelProtocolVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the protocol used on this channel. The format used for version numbering depends on prtChannelType." ::= { prtChannelEntry 3 }

prtChannelCurrentJobCntlLangIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value of prtInterpreterIndex corresponding to the Control Language Interpreter for this channel. This interpreter defines the syntax used for control functions, such as querying or changing environment variables and identifying job boundaries (e.g. PJL, PostScript, NPAP). A value of zero indicates that there is no current Job Control Language Interpreter for this channel" ::= { prtChannelEntry 4 }

prtChannelDefaultPageDescLangIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current

Turner Printer MIB V2 [Page 113]

INTERNET DRAFT Printer MIB January 22, 1999

DESCRIPTION "The value of prtInterpreterIndex corresponding to the Page Description Language Interpreter for this channel. This interpreter defines the default Page Description Language interpreter to be used for the print data unless the Control Language is used to select a specific interpreter (e.g., PCL, PostScript Language, auto- sense). A value of zero indicates that there is no default page description language interpreter for this channel." ::= { prtChannelEntry 5 }

prtChannelState OBJECT-TYPE -- This value is a type 1 enumeration SYNTAX PrtChannelStateTC MAX-ACCESS read-write STATUS current DESCRIPTION "The state of this print data channel. The value determines whether control information and print data is allowed through this channel or not." ::= { prtChannelEntry 6 }

prtChannelIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value of ifIndex (in the ifTable; see the interface section of MIB-2/RFC 1213) which corresponds to this channel. When more than one row of the ifTable is relevant, this is the index of the row representing the topmost layer in the interface hierarchy. A value of zero indicates that no interface is associated with this channel." ::= { prtChannelEntry 7 }

prtChannelStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of the channel." ::= { prtChannelEntry 8 }

prtChannelInformation OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255))

Turner Printer MIB V2 [Page 114]

INTERNET DRAFT Printer MIB January 22, 1999

MAX-ACCESS read-only STATUS current DESCRIPTION "Auxiliary information to allow a printing application to use the channel for data submission to the printer. An application capable of using a specific PrtChannelType should be able to use the combined information from the prtChannelInformation and other channel and interface group objects to 'bootstrap' its use of the channel. prtChannelInformation is not intended to provide a general channel description, nor to provide information that is available once the channel is in use.

The encoding and interpretation of the prtChannelInformation object is specific to channel type. The description of each PrtChannelType enum value for which prtChannelInformation is defined specifies the appropriate encoding and interpretation, including interaction with other objects. For channel types that do not specify a prtChannelInformation value, its value shall be null (0 length).

When a new PrtChannelType enumeration value is registered, its accompanying description must specify the encoding and interpretation of the prtChannelInformation value for the channel type. prtChannelInformation semantics for an existing PrtChannelType may be added or amended in the same manner as described in section 2.4.1 for type 2 enumeration values.

The prtChannelInformation specifies values for a collection of channel attributes, represented as text according to the following rules:

1. The prtChannelInformation is not affected by localization.

2. The prtChannelInformation is a list of entries representing the attribute values. Each entry consists of the following items, in order:

a. a keyword, composed of alphabetic characters (A-Z, a-z) represented by their NVT ASCII [NVT ASCII] codes, that identifies a channel attribute,

Turner Printer MIB V2 [Page 115]

INTERNET DRAFT Printer MIB January 22, 1999

b. the NVT ASCII code for an Equals Sign (=) (code 61) to delimit the keyword,

c. a data value encoded using rules specific to the PrtChannelType to with the prtChannelInformation applies which must in no case allow an octet with value 10 (the NVT ASCII Line Feed code),

d. the NVT ASCII code for a Line Feed character (code 10) to delimit the data value.

No other octets shall be present.

Keywords are case-sensitive. Conventionally, keywords are capitalized (including each word of a multi-word keyword) and since they occupy space in the prtChannelInformation, they are kept short.

3. If a channel attribute has multiple values, it is represented by multiple entries with the same keyword, each specifying one value. Otherwise, there shall be at most one entry for each attribute.

4. By default, entries may appear in any order. If there are ordering constraints for particular entries, these must be specified in their definitions.

5. The prtChannelInformation value by default consists of text represented by NVT ASCII graphics character codes. However, other representations may be specified:

a. In cases where the prtChannelInformation value contains information not normally coded in textual form, whatever symbolic representation is conventionally used for the information should be used for encoding the prtChannelInformation value. (For instance, a binary port value might be represented as a decimal number using NVT ASCII codes.) Such encoding must be specified in the definition of the value.

b. The value may contain textual information in a character set other than NVT ASCII graphics characters. (For instance, an identifier might consist of ISO 10646 text encoded using the UTF-8 encoding scheme.) Such a character set and its encoding must be specified in the definition of the value.

6. For each PrtChannelType for which

Turner Printer MIB V2 [Page 116]

INTERNET DRAFT Printer MIB January 22, 1999

prtChannelInformation entries are defined, the descriptive text associated with the PrtChannelType enumeration value shall specify the following information for each entry:

Title: Brief description phrase, e.g.: 'Port name', 'Service Name', etc.

Keyword: The keyword value, e.g.: 'Port' or 'Service'

Syntax: The encoding of the entry value if it cannot be directly represented by NVT ASCII.

Status: 'Mandatory', 'Optional', or 'Conditionally Mandatory'

Multiplicity: 'Single' or 'Multiple' to indicate whether the entry may be present multiple times.

Description: Description of the use of the entry, other information required to complete the definition (e.g.: ordering constraints, interactions between entries).

Applications that interpret prtChannelInformation should ignore unrecognized entries, so they are not affected if new entry types are added."

::= { prtChannelEntry 9 }

-----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, May 03, 1999 02:14 To: jkm@underscore.com; harryl@us.ibm.com Cc: pmp@pwg.org; ipp@pwg.org Subject: RE: IPP> Re: PMP> IPP "channel" in the Printer MIB

I agree with Jay. We should register a port for IPP, as Jay suggests: chIPP(??).

Now that we have RFC numbers for IPP/1.0 we have a good reference to use in the PMP channel registration for IPP. The IPP/1.0 Model and Semantics document is RFC 2566 and the IPP/1.0 Encoding and Transport is RFC 2565 (both experimental).

How about:

chIPP(??), -- Internet Printing Protocol (IPP) -- See documents relating to IPP 1.0 -- (RFCs 2565 and 2566).

I'm not sure whether we should mention anything about future IPP versions or not.

Lloyd,

Can you add this to the draft Printer MIB document?

Furthermore, chPortHTTP(42) could be used for file up load submission of print jobs using the file up load feature of HTTP. Here is the HTTP specification:

chPortHTTP(42), -- Hypertext Transfer Protocol. See IETF -- documents relating to HTTP 1.0/1.1 -- (RFCs 1945 and 2068,etc.)

-----Original Message----- From: Jay Martin [mailto:jkm@underscore.com] Sent: Saturday, May 01, 1999 10:28 To: harryl@us.ibm.com Cc: pmp@pwg.org; ipp@pwg.org Subject: IPP> Re: PMP> IPP "channel" in the Printer MIB

I would hope a more explicit channel name represents IPP, something like "chIPP".

...jay

harryl@us.ibm.com wrote: > > I haven't seen any attempt to register an IPP channel for the Printer MIB. > Shouldn't we? Or do we assume chPortHTTP (42) covers it? > > Harry Lewis > IBM Printing Systems > harryl@us.ibm.com