Subject: RE: Escaping of attr tags in SLP API

From: James Kempf <[email-masked]>
Date: Wed, 25 Aug 1999 16:51:09 -0700 (PDT)

Roger,

Thanx for your reply. Novell has certainly had more experience with SLP
than anybody else, and so your ideas provide an important reality check.

With regard to:

>I strongly disagree with the notion of eliminating the wildcarding capabilities 
>in SLP.  At Novell we have some experience now with implementing SLP in very l

What do you think about attribute request by service type? Have you had
any need for that?

>
>At Novell we have implemented UAs, SAs, and DAs so we know what a pain the 
wildcarding can be
>(I personally have implemented all three), but remember that you code once but 
you retrieve data always at the network's expense.  I think the better direction 
would be to define how a lightweight SA could be incorporated into the SLP 
envrionment.  By lightweight I mean an SA that perhaps would not implement full 
wildcarding.  But I also believe that lightweight SAs should be the execption 
and used mostly for embedded devices and the like.    The one great advantage we 
(Novell) saw in SLP was the ability to send "smart" requests and only retrieve 
the wanted information.  So again, philosophically and from raw experience I 
strongly disagree with the notion of doing away with wildcarding to ease the 
burden of implementing an SA and DA.

Appendix B of RFC 2608 describes a way to do an SA that matches on
service type only.  No attributes and no locale. We could look at adding
a somewhat larger size that doesn't do wildcards or attribute
request by service type, when we go to standard.

		jak

---

From: Terry Lambert <[email-masked]>
Date: Wed, 25 Aug 1999 17:33:35 -0700

James Kempf wrote:
> 
> Roger,
> 
> Thanx for your reply. Novell has certainly had more
> experience with SLP than anybody else, and so your ideas
> provide an important reality check.
> 
> With regard to:
> 
> >I strongly disagree with the notion of eliminating the
> >wildcarding capabilities in SLP.  At Novell we have some
> experience now with implementing SLP in very l
> 
> What do you think about attribute request by service type?
> Have you had any need for that?

This sentiment assumes that the UA will be making complex
regular expression based requests, rather than using a
simple "*" for everything vs. an explicit service type
(for which it could equally well specify "").

I believe this assumption to be invalid on a number of
counts.

It seems to me that the bossibilities are:

o	a UA attempting to get a specific service

	This UA does not need wildcarding

o	a UA attempting to get a list of all services of
	a specific type

	This UA can use the RFC 2068 Appendix B method

o	a UA attempting to enumerate the network

	This UA must be found, and it's user shot for
	not contacting the DA

It also seems to me that a UA which does this is really
boneheaded, since it won't be able to use the resources
that it doesn't already know that it wants.

If the idea is to find some regular expression, then I
think scopes are an adequate method of specifying, in a
site specific way, classes of allowed "globbing" queries.

If the idea is to find a service, and then try to install
a driver, then I think an upper layer _built on top of SLP_,
such as the 2.1 Salutation architecture, would be more
suited to this task, than trying to overload SLP to deal
with this issue directly.

This is similar to the arguments against strange extensions
to the LDAP protocol: keep the protocol simple, and small.

Protocols which don't remain simple and small do not survive
outside a legacy market, as the NCP API's, and the inability
of anyone other than the NetWare for UNIX team to reverse
engineer the wire protocol successfully, can attest.

> >At Novell we have implemented UAs, SAs, and DAs so we
> >know what a pain the wildcarding can be (I personally
> >have implemented all three), but remember that you
> >code once but you retrieve data always at the network's
> >expense.  I think the better direction would be to
> >define how a lightweight SA could be incorporated into
> >the SLP envrionment.  By lightweight I mean an SA that
> >perhaps would not implement full wildcarding.

This is what I said before: optional implementation in
the SA and the DA ("...SAs and DAs MAY implement..."),
with a mandatory UA implementation for fallback in case
the SA or DA responds "not implemented" ("...UA API MAY
implement wildcarding entry points.  If UA API implements
these entry points, then UA API MUST implement the fallback
algorithm on behalf of SAs and DAs that do not support
wildcarding").

> >But I also believe that lightweight SAs should be the
> > execption

I don't.  There is only so much you can fit into a ROM
attached to a TCP/IP on a chip.

> > and used mostly for embedded devices and the like.

Printers, scanners, Palm Pilots, Document capture devices,
set top boxes?

I would add to this: any general putpose computer with
limited/no local storage.

I fully expect to be using light weight SLP UA's to
configure browser settings in an enterprise environment
in the near term future.

> > The one great advantage we (Novell) saw in SLP was the
> > ability to send "smart" requests and only retrieve
> > the wanted information.  So again, philosophically and
> > from raw experience I strongly disagree with the notion
> > of doing away with wildcarding to ease the burden of
> > implementing an SA and DA.

I will grudgningly grant you this for DAs.  Not for SAs.

If a network is so populated with SAs that talking to
them would be an undue traffic burden, then that network
should have one or more DAs installed.

Thus you could change "...SAs and DAs MAY implement..." to
"...SAs MAY implement, and DAs SHOULD implement...".

James ommitted your original rationale by analogy:

> > You will also remember that SAP didn't scale too well
> > in large LAN network environments and was never
> > effective in WAN networks.  With SAP you didn't have
> > a choice, and if you remove wildcarding from SLP as
> > it goes standard you will end up with a similar situation.

I believe that this rationale is bogus.  SAP was a very
bad initial design, which precluded the idea of scaling.

Likewise, UA's iterating things, instead of asking where
the directory is, and contacting it for the information,
is a bad design.

UA's which use wildcards of any type, instead of asking
for the services they want, are likewise, a bad design.

Novell's use of SLP to achive TN3270 load balancing is
innovative, but the responder doing the round robin should
be a DA, not the SA.

Multicast does not suffer the same drawbacks as broadcast.

Note that it was possible to limit SAP broadcasts to a
small number of hops (similar to the TTL=255 hack).  If
implemented correctly, this can scale to a very large
organization.  I am an alum of Novell during the time of
the great SAP storms, when Novell acquired USL and then
attempted to integrate the networks, without SAP restriction.

If we are to take a page from Novell in this, that page
should be that instead of broadcasting a general request
every time the client wants data, the client should ask
for the location of the directory at startup, and then Do
The Right Thing(tm), which is contact the directory instead
of broadcasting willy-nilly all over the place every time
it wants data.

> Appendix B of RFC 2608 describes a way to do an SA that
> matches on service type only.  No attributes and no
> locale. We could look at adding a somewhat larger size
> that doesn't do wildcards or attribute request by service
> type, when we go to standard.

I believe that there MUST be a seperation of the API,
so that it's still possible to have lightweight SA and
DA implementations.

I will buy into optionally providing API for wildcarding
(which I would suggest require the user of the API to
escape embedded special characters themselves, instead of
expecting the API to do it for them), if that's what it
takes to be able to move forward.

But I consider a UA that would use such an API to be
improperly implemented in general, and a badly behaved
SLP citizen in particular.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.