Subject: RE: SLP service registrations [one per printer]

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 25 Apr 2001 08:25:12 -0700

Hi Tim and James,

As James already pointed out, you only need to register CONCRETE
services with an SLP DA.

The intent of the IETF IPP WG (who developed the content of the
SLP Printer template, based on original work for LPR by Pete
St. Pierre) is that a printer only needs to register itself
ONCE (as either an IPP or LPR printer) and the template attribute
'printer-xri-supported' (REQUIRED for all registrations) should
contain the complete list of IPP, LPR, and any other URLs (this
attribute corresponds to the IPP Printer object attributes
'printer-uri-supported', 'uri-authentication-supported', and
'uri-security-supported' made into a list of triplets).

Note that vendor-specific extensions (such as NetWare NDPS URLs
that extend SLP Printer) can also be in this single list of
URLs in 'printer-xri-supported', so that ALL of the accessible
print paths (on all protocol stacks) to a given printer can be
found via reading the 'printer-xri-supported' attribute in a
single SLP registration.

Hope this helps.

Cheers,
- Ira McDonald, co-editor of SLP Printer template
  High North Inc

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 7:45 PM
To: [email-masked]; [email-masked]
Subject: Re: SLP service registrations

Tim,

>
>
>I want to support an abstract service type template.  It's actually
>the "service:printer" service type.  The "service:printer" abstract
>service type defines concrete service types, including
>"service:printer:lpr" and "service:printer:ipp".  
>
>When I register my services, is it reasonable to have separate 
>registrations for each of the following?
>
>    1) "service:printer"
>    2) "service:printer:lpr"
>    3) "service:printer:ipp"
>
>The thought would be to specify the common attributes with the first 
>(#1 above) registration, and then unique attributes when I register
>the second (#2 above) and third (#3 above).  Is this a good way to go?
>

You should only have to register the concrete types, service:printer:lpr
and service:printer:ipp. The SA and DA take care of interpreting
a SrvRqst or AttrRqst for the abstract type during query handling.

>Also, it looks like when registering, that template-type, template-version,
>template-description, and template-url-syntax are attributes that should
>be specified (as attributes to SLPReg()).  Am I getting this correct?
>If so, It seems that I would only specify these when registering #1 above,
>and that they'd be inherited by the concrete types (#2 and #3).
>

These are only part of the template, they are not included in the
registration. The actual service type registration done by an SA only
includes 
the attributes defined for the service type, not the template attributes.

>If I'm on the right track so far, I'm a little confused by the separate
>service template for the "service:printer:raw-tcp" service type.
>It has it's own template-type, template-version, template-description,
>and template-url-syntax attributes.  Would I specify them when registering
>the following?
>
>    4) "service:printer:raw-tcp"
>

No, you don't have to specify the template attributes when registering
a service of this type.

>Does that go against what I've read about not specifying attributes when
>registering a concrete service type that have already been registered
>with the corresponding abstract service type?  That is, can I specify
>the template-* attributes when registering "service:printer", and then
>again (unique values) when registering "service:printer:raw-tcp"?
>

Again, you don't have to register the abstract service type, just
the concrete types.

>Is the "service:printer" service type really the abstract service
>type for the "service:printer:raw-tcp" service type?  If so, then it
>should inherit all of the attributes that I registered with #1 above.
>Is this correct?
>

See above.

>If I want to operate as an SLPv2 SA, in an environment containing 
>SLPv1 UAs and SAs, SLPv2 UAs and SAs, and also SLPv2 Bridging DAs.
>I've read specifically that abstract service types should be avoided
>in this type of environment (because SLPv1 does not support abstract 
>service types).  How are the above service types handled?
>Will the SLPv1 UAs be able to learn about them (i.e. the concrete
>types registered by #2, #3, and #4 above)?
>

An SLPv1 UA can make a query for "service:printer" but it will not
be able to interpret the URLs that are returned because SLPv1 does
not support the abstract service type syntax. If you want to
support SLPv1, you would have to register service:lpr, service:ipp,
etc.

Hope that helps.

		jak