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 at 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)