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

From: Mikael Pahmp <[email-masked]>
Date: Tue, 19 Jan 1999 23:05:08 +0100

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

---

From: erik guttman <[email-masked]>
Date: Tue, 19 Jan 1999 14:23:15 -0800

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

It is *not* necessary that the concrete service types be registered with
IANA to be registered in a service template.  It is necessary to cite an
available protocol specification, however.  The intention is to allow people
to register templates for services which do not necessarily have RFCs
published about them.

> sufficient for accessing the printer.

If you are looking for a service:printer:raw-tcp service (which 
supports certain attributes), you will do so as you know how to drive
it.  That seems like a circular argument - showing there is no ambiguity
if you are looking for something which is not highly constrained.  But
the problem is constrainable if the other attributes registered with the
raw-tcp print server specify the specifics of the raw-tcp service (concrete
protocol, device id, etc.). 

Erik

--------------------------------------------------------------------------
Erik Guttman                                     Germany: +49 7263 911 701
Sun Microsystems - Advanced Network Development  USA:      +1 650 786 5992