Subject: RE: Escaping of attr tags in SLP API

From: James Kempf <[email-masked]>
Date: Tue, 24 Aug 1999 08:11:46 -0700 (PDT)

>
>By the way, I find this feature of selecting attribute tags using wild chars of 
little use. It's a feature I would consider removing when SLP eventually goes to 
draft standard.

Why do you think that?

It's been useful in some projects we're working on, which are more
in the area of research. Also, I can see it being useful for
obtaining all attributes as a way of displaying them for browsing,
particularly if you don't know a priori what the tags are.

		jak

---

From: Terry Lambert <[email-masked]>
Date: Tue, 24 Aug 1999 09:48:23 -0700

James Kempf wrote:
> Mikael Pahmp wrote:
> >
> > By the way, I find this feature of selecting attribute
> > tags using wild chars of little use. It's a feature I
> > would consider removing when SLP eventually goes to
> > draft standard.
> >
> >
> 
> Why do you think that?
> 

FWIW: I agree with Mikael; specifically the idea that a DA
or SA should be doing globbing on behalf of a UA seems wrong.

My immediate knee-jerk reaction the other day was to say that
an API which makes blanket statements, and then makes some
exceptions, is not orthogonal.

I think the correct place to implement globbing is in the
API, not on the other side of the wire, and that in order
to do it right, you need a seperate, optional implementation,
call at the API layer, which enumerates all possible values,
constraining its returned data to that matching the pattern.

I might even go further, and require that a user comparison
function (or functions, if you want to seperate attribute
and the remainder of the URL's globbing, and couldn't write
reasonable regex's) be passed to the API, ala the qsort(3)
compare function.

Note that this, like an over-the-wire scheme, would allow
non-matching values to be discarded, so it's hardly more
overhead than if you pounded the smarts into both the SA's
and the DA's (e.g., it is, at most, one buffer more worth
of SA/DA response for the final non-matching response, which
may be discarded).

The one issue this raises is that the over-the wire data
is increased by the proportion of data _not_ matching the
pattern.  Since the most common case is "*", and this can
be obtained by not constraining the attributes that a
responder can claim, I don't really see an issue.  If you
wanted to optimize wire overhead, you'd do something like
continue to allow UA->DA unicasts, and similar obvious wins.
If you wanted to optimize UA size, you'd get rid of the
private memory management functions in the API.  Either
way, it's not going to add any more to the UA to do globbing
at the API (and optionally, at that) than any of the other
design decisions that make a UA's life harder than it should
be.

-- 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.