IPP Mail Archive: IPP> Draft RFC's

IPP> Draft RFC's

papowell@astart.com
Tue, 24 Nov 1998 09:45:08 -0800 (PST)

Tom, I suppose that it is a little late, but I was wondering
if you are open to some minor modifications on the LPD to IPP
mapping.

By the way, you might peek at the text formats in the latest
postings -

------------

Herriot, Hastings, , [Page 2]
Jacobs, Martin Expires May 16, 1999

INTERNET DRAFT Mapping between LPD and IPP ProtocolsNovember 16, 1998

------------

Note 1: comma on the page line appears spurious.
Note 2: overlap of Protocols and November

Note: there are several places where a period appears spuriously:

Example:
file sub-command..

This looks like an artifact of the text conversion process.

COMMENT:

The LPR print request control file is required to have
N fields, which are the <file name> value referred to
in the document.

The <file name> is used in the various status requests,
reports etc. I would like to suggest that the value of the N
field be managed as follows:

LPR -> IPP: replace all spaces, non-Latin characters,
by underscores
IPP -> LPQ: remove all spaces, non-Latin characters,
by underscores

COMMENT:

I would like to suggest that the mappings from LPD document-formats
to IPP formats be made explicitly administratively configurable.
This would allow gateways to determine the type of document and
generate a more reasonable mapping for printing.

COMMENT:

Original:
-----
The follow LPD functions specify document-formats which have no IPP
equivalent, unless someone registers them. The LPD-to-IPP mapper rejects
jobs that request such a document format, and the IPP-to-LPD mapper does
not send them.
-----

Suggested:

The follow LPD functions specify document-formats which have no IPP
equivalent, unless someone registers them. The LPD-to-IPP mapper MAY reject
jobs that request such a document format, or replace them with an
administratively specified document-format. The IPP-to-LPD mapper MAY
generate document-format values for IPP document types by means of administrative
configuration.

REASONS: The above wording allows support of non-supported values to be
done in a administratively configured manner. The MAY does not force
support of this capability.

Patrick Powell Astart Technologies,
papowell@astart.com 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 619-874-6543 FAX 619-279-8424
LPRng - Print Spooler (http://www.astart.com)