Thank you for your extensive reply.
>  Why is the (mandatory in IPP) attribute
> still in the SLP 'printer:' template draft I posted?
>> a) Because there is no unambigous way to determine that two
> SLP 'printer:' registrations refer to the SAME network
> (we have concensus in the IPP WG, I think, that
> NOT a safe attribute to check).
> b) Because typical network printers support six or more print
> at once and finding ALL the paths to a printer at once in a
> SLP 'printer:' registration has great utility for client
> (and human end-users).
> c) Because network printers are very different from file
> most other service providers. Network printers are
> multilingual. There are shipping printers that support ten
> protocols at once (across a number of protocol suites).
> d) Because actual practice and experience in a variety of
> protocols has shown that 'aliases' are more trouble than
> worth - they're a maintenance headache for a service
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
>  What about the syntax of a Raw TCP printer URL?
>> a) Mikael, I just re-read your December 1998 draft. While the
> part may make no sense (the ABNF term 'url-path' is probably
> named in the 'printer:' template), the actual full URL
> (with 'raw-tcp://host [":" port]) MUST be listed in the
> b) Also, SLP concrete URL are required to use IANA registered
> schemes. Have you or someone registered 'raw-tcp:'? The
> utterly opaque in the scheme space. How does someone guess
> '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'
>  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
> unambiguous. There are lots of other possible meanings to
> 'device-id' for printers.
>>  What about other LPR 'flavor' discriminating attributes?
>> a) Mikael, if you can find them and specify them, I'll gladly
> to the 'printer:' template.
> b) Bob Herriot has published the informational IPP<-->LPR
> from the IPP WG. The Open Group NCMG Print Architecture
> specifies certain interoperability rules for LPR usage. Both
> are seriously limited by the incoherence in LPR
> 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
> to be added to discriminate (for the print client) what 'flavor'
> 'raw-tcp:' is being used? What are the reference documents? To
> a protocol to this (or any other) SLP template, we need
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.