Subject: Re: SLPFindAttrs()

From: James Kempf <[email-masked]>
Date: Mon, 31 Jul 2000 12:58:10 -0400

The intent is that the client uses the returned result to gauge how to form a
query. So, for example, if the client is looking for a printer and the result
of SLPFindAttrs() returns with no "color" attribute, then the client knows
not to bother querying for a color printer.

That said, the complexity of implementing the AttrRqst message by service
types is such that the expected gain does not outweigh it, which is why
we have been discussing dropping AttrRqst by service type.

I don't think adding a URL field would help. After all, the client can simply
perform a SrvRqst to find the URLs, then use AttrRqst by URL to find what
attributes the URLs have.

		jak
>
> Quick question: If SLPFindAttrs() is called with a service type, it
>returns the attributes of every service of that type. How can the UA tell
>which host belongs to a specific set of attributes?
>  
> Would it make sense to add a URL field to the SLPAttrCallback()  
>parameters?
>
>e
>

---

From: Evan Hughes <[email-masked]>
Date: Mon, 31 Jul 2000 13:27:55 -0400 (EDT)

> not to bother querying for a color printer.

  The client should know the attributes from the templates though...

> we have been discussing dropping AttrRqst by service type.

  The only use I could see of querying by service type is comparing
services to decide which one to take (where the accept criteria are such
that services must be compared against one another). 

> attributes the URLs have.

  True. Although adding the url field would cut down on the number of
messages necessary...

e