Subject: Re: SLP API question regarding DAADVERT and SAADVERTinformation

From: James Kempf <[email-masked]>
Date: Thu, 01 Mar 2001 18:46:44 -0800

Hi Matt,

It returns the service URLs or attributes (depending on whether the SrvRqst
or AttrRqst command is given) for the given service type, even if the
type is one of the special types. This isn't too hard to to handle, it only
requires a switch on the function code of the returned message to check
whether it is a SrvRply, DAAdvert, or SAAdvert.

The motivation is to make the API functions complete in the kinds of
service information they return.

                         jak

At 05:48 PM 2/28/01 -0700, Matt Peterson wrote:
>James Kempf wrote:
> >
> > We can explicitly put this in the bis draft. Sun SLP handles the special
> > service
> > types.
> >
>
>Does Sun SLP handle the special service-types in the way suggested in
>the previous email or does it do things differently?  What will go into
>the bis draft so we can fix this in the next OpenSLP release.
>
>
>--
>Matthew Peterson
>Sr. Software Engineer
>Caldera Systems, Inc
>[email-masked]
>PGP Key: 9641 4E9B 8433 FC3E B899  A09E E12B 0490 8F8B C331

---

From: Matt Peterson <[email-masked]>
Date: Fri, 02 Mar 2001 09:12:57 -0700

> service information they return.

... So you agree with the suggested implementation?

One more question -- this one may involve RFC 2608:

How does the DA gain a list of "service:service-agent" URLs?  The
OpenSLP implementation of the SLP API uses available DAs directly to
resolve SrvRqsts.  If a SrvRqst is looking for "service:service-agent"
then the DA will not return anything because it does not know about
SAs.  I do not think that RFC 2608 addresses this issue.  Should DAs
actively discover SAs, or are UAs required to multicast all SrvRqsts
that are looking for "service:service-agent" types?  How does either of
the solutions affect scalability?  Do we really what this additional
complexity in SLP?

Thanks,