IPP> SLP - Summary of next 'printer:' template proposal

IPP> SLP - Summary of next 'printer:' template proposal

IPP> SLP - Summary of next 'printer:' template proposal

Mikael Pahmp mikael.pahmp at axis.com
Tue Jan 19 17:05:08 EST 1999


Thank you for your extensive reply.

> [2] Why is the (mandatory in IPP) attribute
'printer-uri-supported'
>     still in the SLP 'printer:' template draft I posted?
> 
> a)  Because there is no unambigous way to determine that two
separate
>     SLP 'printer:' registrations refer to the SAME network
printer
>     (we have concensus in the IPP WG, I think, that
'printer-name' is
>     NOT a safe attribute to check).
> b)  Because typical network printers support six or more print
protocols
>     at once and finding ALL the paths to a printer at once in a
single
>     SLP 'printer:' registration has great utility for client
software
>     (and human end-users).
> c)  Because network printers are very different from file
servers or
>     most other service providers.  Network printers are
inherently
>     multilingual.  There are shipping printers that support ten
or more
>     protocols at once (across a number of protocol suites).
> d)  Because actual practice and experience in a variety of
directory
>     protocols has shown that 'aliases' are more trouble than
they're
>     worth - they're a maintenance headache for a service
registering
>     itself.

Your arguments are convincing. It seems to me as if will be
somewhat more difficult to compose client SLP queries to discover
printers within a set of protocols supporteed.

The SRVLOC WG should probably take this into account in future
work.

> [4] What about the syntax of a Raw TCP printer URL?
> 
> a)  Mikael, I just re-read your December 1998 draft.  While the
path
>     part may make no sense (the ABNF term 'url-path' is probably
badly
>     named in the 'printer:' template), the actual full URL
syntax
>     (with 'raw-tcp://host [":" port]) MUST be listed in the
template.

OK

> b)  Also, SLP concrete URL are required to use IANA registered
URL
>     schemes.  Have you or someone registered 'raw-tcp:'?  The
name is
>     utterly opaque in the scheme space.  How does someone guess
that
>     'raw-tcp:' in a directory means *print* service?

In my mind, the complete URL advertised would be
'service:printer:raw-tcp://nn.nn.nn.nn'. In this case it is clear
that the service is a printer. The 'service:' part indicates that
this is a service: URL from which information may be obtained
sufficient for accessing the printer.
I will go back and look at how you define your URLs and the
sematics indicated in the 'Service Templates and service: Schemes'
document.

> [5] Should we add the IEEE 1284 'device-id' attribute?
> 
> a)  Yes, I agree.
> b)  But we should name it 'ieee-1284-device-id' or something
equally
>     unambiguous.  There are lots of other possible meanings to
plain
>     'device-id' for printers.

Agree.

> 
> [6] What about other LPR 'flavor' discriminating attributes?
> 
> a)  Mikael, if you can find them and specify them, I'll gladly
add them
>     to the 'printer:' template.
> b)  Bob Herriot has published the informational IPP<-->LPR
gateway spec
>     from the IPP WG.  The Open Group NCMG Print Architecture
Phase 1
>     specifies certain interoperability rules for LPR usage. Both
specs
>     are seriously limited by the incoherence in LPR
implementations
>     from various vendors.

I will look into this to see what I can find.

> I have one more question of my own.  What are the attributes
that need
> to be added to discriminate (for the print client) what 'flavor'
of
> 'raw-tcp:' is being used?  What are the reference documents?  To
add
> a protocol to this (or any other) SLP template, we need
definitive
> references.

I'm not aware of any flavors but I will forward the question to
bits-and-bytes-implementors at Axis.
It is a problem that the use of raw TCP for printing is not a
documented standard but a de-facto standard used by e.g. Microsoft
and HP. I will do some inquiries to see if some kind documentation
exists and can be referenced.

/Mikael



More information about the Ipp mailing list