Subject: RE: Empty string attribute value

From: Erik Guttman Sun Frankfurt Staff Engineer <[email-masked]>
Date: Wed, 16 Feb 2000 11:15:09 +0-100

SLP query string syntax has LDAP search string semantics.  
If empty strings are allowed in LDAP search filters, they
are allowed in SLP, too.  Is it possible to request something
like "(attr=)"?  I thought this was illegal by RFC 2254 syntax.

On Tue, 15 Feb 2000 13:55:25 -0800 
"Ira McDonald" <[email-masked]> wrote:
>Hi Mikael and Erik,
>
>In the particular example 'service:printer', I made sure that
>every attribute which might have no known value was OPTIONAL
>in the template and had a default value (in the template) of
>the string 'unknown'.  Thus, if the attribute is not supplied
>by the SA during service registration, the DA (which understands
>the well-known template 'service:printer') will automatically
>add the missing OPTIONAL attribute to the actual registration
>with the default value of 'unknown'.
>
>Hugo Parra (Novell) suggested the above approach for print
>servers which had been connected to printers but didn't yet
>know (via network protocols or adminstrative configuration)
>some of the characteristics of those printers.

I agree that the best thing to do (from a template perspective)
is to include a value for attributes to set by default, or when
the true value is not yet known.

>On the other hand, there are a great many OCTET STRING objects
>defined in current IETF standards track MIBs (with a refined
>type of 'SnmpAdminString' or 'DisplayString') which can have
>the empty string as a valid value.  Forcing them to take a
>single space in an SLP template representation seems a bit
>clumsy.

Wouldn't it be sufficient not to advertise these strings when
they are not set?  

Or is there value advertising them as being specifically not set?  
This would mean something like "The Vendor Name has no value."  All 
the other attributes that are advertised mean something like "The 
Operator's name is Fred Mousaka."  

I favor the scheme in which the vendor's name is not registered by
SAs, nor is it returned in Attribute replies nor would a request
for (vendor name=*) match the service since the service has NO vendor
name, right?

On Wed, 16 Feb 2000 10:55:25 +0100
"Mikael Pahmp" <[email-masked]> wrote:
>It never occured to me ( :-< ) that an optional attribute, for which there is no
>known value, could (SHOULD ?) just be omitted from the SA's service
>registration. We haven't implemented it like that but we probably should. It
>solves some problems we have.

Do you agree with my argument above?

>In RFC 2609 (Service Templates) at the end of section 3.2.6.4, it talks about
>assigning defualt values for optional attributes which doesn't have default
>values in a Service Template. It mentions the 'empty string'. Is this text
>intended for UAs/SAs/DAs ?

Indeed you seem to have done the right thing according to RFC 2609:

   The default value or list indicates what values the attribute is
   given if no values are assigned to the attribute when a service is
   registered.  If an optional attribute's definition includes no
   default value or list, the following defaults are assigned: 

    1. String values are assigned the empty string,

The problem is that SLP doesn't allow empty strings to be expressed
in attribute lists (SrvReg, AttrRply, etc.) or in SrvRqst search
filters.  So I humbly suggest that this rule is wrong and needs to
be corrected.  Sigh.

Erik

---

From: Terry Lambert <[email-masked]>
Date: Wed, 16 Feb 2000 09:56:56 -0800

> like "(attr=)"?  I thought this was illegal by RFC 2254 syntax.

This is not allowed for a search filter, but it is allowed
for a match to the search filter "(attr=*)".  LDAP itself
will allow an empty string, even if it has to BASE64 encode
the thing (e.g. "attr::" in LDIF).  I think there is a
significant benefit to be had by mapping SLP attributes into
LDAP object attributes.

The most significant barrier to disallowing empty attributes,
I think, is that not all standardized schema which one might
wish to use allow optionally missing attributes.  One could
easily imagine an SNMP MIB exposing the same hierarchical data
as an LDAP directory, file system, or other hierarchical data
access interface (DNS, etc. leap to mind).

I think that NUL-valued attributes are different from missing
optional attributes, and that this difference can be important.

> Or is there value advertising them as being specifically not set?

Yes, precisely.  You could infer, for example, that they
could take on alternate values, and that you must be
prepared for this in the case of the attribute being
updated.  Being prepared to handle an attribute that did
not exist, but now exists, is a much harder problem, since
you can't wait for something you don't know isn't there.
It would be onerous to have to wait for all optional
attributes instead of a few or one.

> for (vendor name=*) match the service since the service has NO vendor

The problem with this is that I now have to issue N! searches
for any service for which I would prefer values for attributes
which can be NUL-valued, if there are N such attributes.

The printer case is a particularly bad example, in that it's
a "well behaved" schema, and doesn't really expose the corner
cases that this discussion is trying to address.  I'll be the
first to admit that I might not be doing them justice, either.
But say I would prefer to display the vendor string, but I was
willing to live without it, IFF the vendor string was not set.

A better example might be a non-optional attribute called
"input data restrictions=", where the NUL-valued string
means that there are no restrictions, and a non-NUL-valued
string is a comma seperated list of restrictions.

> filters.  So I humbly suggest that this rule is wrong and needs to

But this is an expression grammar problem, not a semantic
impossibility.  I think it would be better to update the
grammar to allow it.

-- 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, 17 Feb 2000 14:52:50 +0100 (MET)

"Terry Lambert" <[email-masked]> wrote:

> I think there is a

Excellent arguments.

>  <[email-masked]> wrote:

I've been pursuaded.  

The question is now who wants to help come up with the revision?  
As I see it there are two work items.  The first is to come up with
the exact (LDAP) semantics we need.  The second is to arrive at a 
set of deltas for SLP to support them.

I am not competent for the LDAP work, but I'm happy to help on the
SLP grammar deltas given a specific set of requirements.  

Would any of you (Ira, Mikael, Terry, Jim, someone on the svrloc
list) be able to help out?

Thanks,

Erik
SVRLOC WG Chair