Hi Mikael, Friday (15 January 1999)
Here are some answers to all of your notes (included below).
[1] Why am I interested in SLPv1 templates?
a) Because the Open Group's NCMG (Network Computer Mgmt Group) Print
Architecture WG plans to specify SLPv1 as the common backplane of
SLP discovery for LPR and IPP speaking printers (perhaps they should
specify SLPv2, but SLPv2 hadn't even gone to IESG 'last call' when
they originally decided on this direction).
b) Because Netware 5 DOES use SLPv1. Yes, to the best of my knowledge
Novell IS interested in having SLPv1 templates for print services
(as you will have seen, I've been working with Hugo Parra, principal
Novell member of the IETF IPP WG).
[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.
[3] Should we keep the various concrete protocols in the 'printer:'
abstract template (LPR, IPP, NDPS, Raw TCP, etc)?
a) Yes, I agree that we should keep concrete protocols in the single
published SLPv2 'printer:' template.
b) I see no possible advantage to separating them for SLPv2 usage.
[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.
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?
[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.
[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 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.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
716-461-5667
> ------------------------------------------------------------
> From: Mikael Pahmp <mikael.pahmp at axis.com>
> To: "'Ira McDonald'" <imcdonal at sdsp.mc.xerox.com>
> Cc: ipp at pwg.org, srvloc at srvloc.org> Subject: RE: IPP> SLP 'printer:' template comments [language]
> Date: Thu, 14 Jan 1999 12:42:31 +0100
>> Hi Ira,
>> I'm wondering why templates for SLPv1 is considered. The only v1
> implementation and deployment of recognizable size that I know of
> is in Novell's NetWare 5. Is Novell interested in v1 printer
> templates?
>> At Axis, we are implementing v2 precisely because we want to use
> the printer services you're defining. I don't think v1 templates
> are important unless someone is explicitly requesting it. I know
> that Erik and others working with the v2 protocol specifications
> would like to see people moving to v2.
>> /Mikael
> ------------------------------------------------------------
>> From: Mikael Pahmp <mikael.pahmp at axis.com>
> To: "'Ira McDonald'" <imcdonal at sdsp.mc.xerox.com>
> Cc: ipp at pwg.org> Subject: IPP> RE: SLP - Summary of next 'printer:' template proposal
> Date: Thu, 14 Jan 1999 13:19:22 +0100
>> > -----Original Message-----
> > From: Ira McDonald [mailto:imcdonal at sdsp.mc.xerox.com]
> > Sent: den 14 januari 1999 02:45
> > To: ipp at pwg.org; srvloc at srvloc.org> > Subject: SLP - Summary of next 'printer:' template proposal
> >
> >
> > Hi folks, Wednesday (13
> > January 1999)
> >
> > This note seeks concensus before a next revision of the SLPv2
> > 'printer:'
> > template. PLEASE send your opinion to the IPP mailing list.
>> My last mail cc:'d to both ipp at pwg.org and srvloc at srvloc.org seems
> to have bounced back and forth between the lists so I'm only
> sending this to the IPP list.
>> In your latest 'printer:' template draft the notion of having only
> one SLP entry with several URI's listed in the
> 'printer-uri-supported' attribute is still there. In an earlier
> mail from Robert Herriot (included below), it sounded as if you've
> decided to go with separate SLP entries for each URI. What is the
> rationale for staying with one entry per printer?
>> /Mikael
> ------------------------------------------------------------
>> From: Mikael Pahmp <mikael.pahmp at axis.com>
> To: "'Ira McDonald'" <imcdonal at sdsp.mc.xerox.com>,
> "'ipp at pwg.org'"
> <ipp at pwg.org>,
> "'srvloc at srvloc.org'" <srvloc at srvloc.org>
> Subject: IPP> RE: SLP - Summary of next 'printer:' template proposal
> Date: Thu, 14 Jan 1999 14:35:31 +0100
>> It is not mentioned in your mail if the 'printer:' template will
> include conrete service schemes as before or if it should only
> describe the abstract part and have separate documents for the
> concrete schemes. I suggest having the conrete schemes included
> for both IPP, LPR, NDPS and Raw TCP as long as they don't add too
> many attributes to those that are common.
>> I've heard that Microsoft has a way of describing LPR printers
> that discerns how different print servers implement LPR. This
> information should probably be included as attributes for LPR
> printers. Does anyone know what this information consists of?
> I will also try to find it myself.
>> In a previous mail, someone noted that the Raw TCP printer
> template doesn't contain a syntax description for the conrete URI.
> It does. The 'url-path' is empty as it doesn't make sense to have
> a path part when addressing a raw tcp port.
>> In the Raw TCP template, a new attribute 'device-id' is included
> apart from the common ones. The data for this attribute is often
> available from a paralell port printer (if it supports the IEEE
> 1284 standard) and can easily be included in the SLP service by a
> 'print server'. The Device ID is used by Windows 95/98 Plug & Play
> to automatically select the correct printer driver. I suggest that
> this attribute is added to the list of attributes of the abstract
> printer service as an optional attribute instead as it is useful
> in all print protocols when determining print driver.
>> /Mikael
> ------------------------------------------------------------
>