Subject: RE: Reactions to draft-guttman-svrloc-slpv2bis-00.txt ???

From: James Kempf <[email-masked]>
Date: Wed, 5 Jul 2000 09:29:59 -0700 (PDT)

Mikael,

>and then filter on the client side. It can also be discussed whether this is a 
>good way of defining a service.

Yes, that's a good question. I went around with the IPP group on this,
but they were very adament about wanting to advertise one URL that
would serve for all protocols.

>Is wild card support heavy to implement?
>

I've not found wild card support in queries particularly difficult to implement.

>I do support dropping wild cards in tag lists, i.e. AttrRqst and SrvDeReg.
>

Could you elaborate? How is this different from wild cards in queries?
Or do you feel that it is of limited utility?

		jak

---

From: "Mikael Pahmp" <[email-masked]>
Date: Wed, 5 Jul 2000 22:58:43 +0200

----- Original Message -----
From: "James Kempf" <[email-masked]>
> Or do you feel that it is of limited utility?

Its usefulness is limited and it should therefor be dropped unless someone
can motivate it. Erik had an excellent elaboration on this. See below.

-------

This concerns draft-guttman-svrloc-slpv2bis-00.txt, Section 3.2.2.

This supports the elimination of wildcards in tag lists sent
with Attribute request messages:

     This is feature only useful if you have free form attribute
     tags like

       (username.joe=Joe Moof),(username.fred=Fred Lung)

     You don't know what the attribute tags are a priori, only
     that they start with a common prefix for a particular
     purpose (like mapping user names to full names).  This is
     a very arcane thing, and there's no good reason to burden
     SAs and DAs with the feature of being able to process wild
     cards in tag lists (like "username*") just so that this sort
     of namespace can be returned efficiently.

     If you can't add wildcards to the tag lists, you can still
     request that the ENTIRE attribute list be returned.  This
     will include all the attributes, whatever their tags.

     The point is to not burden the base protocol and all
     compliant implementations with this optimization which is
     rarely of use.

Erik

---

From: Terry Lambert <[email-masked]>
Date: Wed, 05 Jul 2000 16:50:07 -0700

Mikael Pahmp wrote:
> > Could you elaborate? How is this different from wild
> > cards in queries?  Or do you feel that it is of
> > limited utility?
> 
> Its usefulness is limited and it should therefor be
> dropped unless someone can motivate it.  Erik had an
> excellent elaboration on this. See below.
> 
> -------
> 

I think you can't send duplicate tags with different
rvalues, can you?

How would one ask for an SMTP server willing to relay
outbound email for a group or user, or an IMAP4 or POP3
server where mail for a particular user is stored?

I've personally been using attribute tag suffixes for
this...

8-(.

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

---

From: Erik Guttman <[email-masked]>
Date: Thu, 6 Jul 2000 11:40:55 +0200 (MET DST)

> I think you can't send duplicate tags with different

The attribute tag list specifies which attributes to return 
in an attribute reply.  The attribute tag list in the SrvDeReg
specifies which attributes to deregister from a DA, associated
with a particular service URL.

In both cases, the wildcards are used purely as a shorthand,
in order to make transfer of the AttrRply or SrvDeReg more
efficient.

> server where mail for a particular user is stored?

You might have an attribute (SMTP-groups-allowed=a,b,c,d)
or (SMTP-users-allowed=a,b,c,d).

If you were searching for the SMTP server which allowed group b
you'd issue a request like this:

   service type:   service:smtp-relay
   search filter:  (SMTP-groups-allowed=b)

> I've personally been using attribute tag suffixes for this...

You can still use attribute tag suffixes.  There is nothing in
the suggestion above which changes their use.  We are merely
discussing removing the requirement that servers can handle
wildcards in tag lists in SrvDeReg and AttrRqst messages.

So far there haven't been any convincing arguments in favor of
keeping them.

Erik

---

From: Terry Lambert <[email-masked]>
Date: Thu, 06 Jul 2000 14:22:59 -0700

> in order to make transfer of the AttrRply or SrvDeReg more

I'm thinking of a POP3 or IMAP4 server, with a person just
added or removed from the list of people able to obtain
services from the server.

This could be a large number for any service which required
a user credential for use.  A really large number.

It doesn't really matter whether a server is "willing" or
not, the gating factor is "I want a server that recognizes
the public half of my credential, and will give me the
service if I correctly authenticate".

The problem boils down to asking who you should ask, rather
than asking for the service URL itself.

Unless I had TLS everywhere, I'd be loathe to send a name
and password pair in cleartext over the wire.

> wildcards in tag lists in SrvDeReg and AttrRqst messages.

OK.  I am looking for hierarchy management.  In other words,
I have the set of all users on the Internet, the set of all
users at a company, the set of all users at the company who
are allowed to send internal email, the set of all users at
the company allowed to send external mail, and then the
users within that set.

In order to make the most efficient search possible, I want
to search from the least qualified to the most qualified.

This isn't a real-world example, since SLP scaling to the
Internet hasn't been fully developed yet, but I might ask
for "outbound SMTP relays for ``example.com''".  I will
probably not use SLP for this phase, and will probably
federate it with DNS SRV records until I get down a level
or two ("example.com" or "eng.example.com"), at least until
SLP is ubiquitous.

Then I want to ask with increasingly specific wildcards to
aggregate suffixies:

	eng.example.com/*
	eng.example.com/hw-team/*
	eng.example.com/hw-team/floyd

The point is that I need to ask over scopes that are of a
different granularity than the SLP scope.

Think of how Kerberos realms don't map to DNS zones.

Maybe a better example is that "floyd" is a member of a
cross-functional team, and I want to ask for a mail server
that will relay outbound mail for him based on his role as
a member of the team that the mail server serves.

The point is that the scope is administrative for resource
zones, and doesn't necessarily map well to organizational
structures, particularly if your organization is not 100%
hierachically laid out.

I know, that's "blasphemy!"  and I should be forced to go
back to "lexicography school".  8-).

-- Terry Lambert