> [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