Subject: Re: Empty string attribute value

From: James Kempf <[email-masked]>
Date: Fri, 11 Feb 2000 08:48:01 -0800 (PST)

Actually, our implementation wouldn't allow this. Neither the attribute
list parser nor the query parser can handle empty string.

Apropos the latter, do LDAPv3 queries allow the empty string in queries?

		jak

>X-Authentication-Warning: wicked.neato.org: majordom set sender to 
[email-masked] using -f
>From: Mikael Pahmp <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: Empty string attribute value
>Date: Fri, 11 Feb 2000 12:21:01 +0100
>MIME-Version: 1.0
>
>There is a little loophole in the 'attr-list' grammar and the implicit typing 
rules in RFC 2608.
>
>For an attribute of srting type, there is sometimes the need for sending the 
empty string. There is however no way of representing it in the 'attr-list' 
grammar correctly.
>
>Since the 'strval' grammar rule is '1*safe-val', a string value must have at 
least one character. To send an empty string, it could e.g. be represented as a 
space character but then it's not an empty string and could potentially be a 
problem on the client side. The predicate grammar wouldn't have a problem with 
it since leading and trailing white spaces are stripped before comparing values.
>
>I think the grammar should rather have been 'strval = 0*safeval'. This will 
allow for the empty string. It will not cause any problems for the implicit 
typing rules since the other types require at least one character.
>
>This can be corrected when SLPv2 goes to draft standard but my question now is 
if there are any implementations out there that would have a problem with a an 
'attribute' looking like this:
>   '(attrname=)'        ; note, no character between the '=' and ')' characters
>
>Note that it's still possible to represent a multi-valued string attribute. 
E.g.:
>   '(attrname=string value,,another string value)'
>This attribute has three values. The second one is the empty string.
>
>Probably this was the intention of the author from the beginning but the 
grammar rules forbids it.
>/Mikael

---

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 15 Feb 2000 13:55:25 -0800

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.

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.

Cheers,
- Ira McDonald (consulting architect at Sharp Labs America)
  High North Inc

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Tuesday, February 15, 2000 4:26 AM
To: Mikael Pahmp
Cc: 'Erik Guttman'; [email-masked]'
Subject: RE: Empty string attribute value

> > > Probably this was the intention of the author from the 
> > beginning but 
> > > the grammar rules forbids it.
> > 
> > Mikael,
> > 
> > What is this useful for?  It was actually my intention to 
> > forbid it :-)
> > 
> > Not that I like forbidding things for their own sake, but the 
> > WG thought 
> > of an empty value as a keyword.  We didn't think that an 
> > attribute would
> > be both a keyword and a attribute-value tuple. 
> 
> E.g. when we announce the service:printer service, its attribute values
are
> fetched from the printer but doesn't always have a value for every
> attribute. In that case, when the attribute is of string type, it would be
> suitable to send the empty string. I don't know of any attribute right now
> that would cause trouble if the value was sent as e.g. a single space
> character.
> 

Let's see, there are three attributes A, B and C.  I'm looking for
something where A=1, B=2, C=* (anything).  What you are saying is
just because a given service C doesn't have a value right now, I 
should still find it.

> Thinking more about it I guess if a client really wants to discern between
> an empty string and one with only white spaces, the attribute should by
> represented as an opaque value type. Since string comparison strips
leading
> and trailing white spaces before evaluation, strings should not be used
when
> an empty string or an string with only white spaces have significance.

Remember spaces are elided with the same rule as LDAP for compatibility.
That is N spaces are the same as one.   

> So we'll go back and see if representing an empty string value as e.g. a
> space character will work for us. One thing that must not happend is that
> when the value for a string attribute is empty, the attribute is sent as
an
> keyword. That would cause problem in the implicit typing rules, e.g. in
the
> SLP Java API where this types are actually represented by different Java
> types (classes).
> 

I still have problem with the idea that services advertise attributes for
which they don't have a value set.  I would think that if a value is not
set, it wouldn't be advertised.  Searches should be for things which have
certain properties (attributes set to values) not that have attributes 
whatever they may be set to.  

An unset attribute is not really an attribute, right?  It would be like 
if you asked me "How are you?" and I answered "I am."

Erik

---

From: Mikael Pahmp <[email-masked]>
Date: Wed, 16 Feb 2000 10:55:25 +0100

Erik, Ira,

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.

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 ?

/Mikael

> From: McDonald, Ira [mailto:[email-masked]]
> Sent: den 15 februari 2000 10:55 PM
> To: 'Erik Guttman'; Mikael Pahmp
> Cc: [email-masked]'

---

From: Mikael Pahmp <[email-masked]>
Date: Wed, 16 Feb 2000 12:42:25 +0100

> From: Erik Guttman Sun Frankfurt Staff Engineer
> Sent: den 16 februari 2000 12:15 PM

...

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

Would the query mean the same thing in LDAP? I guess it would since '=*' is part of the LDAP search filter grammar.

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

I can't think of a better way for an SA to say that it doesn't have a value for an attribute than by omitting it. 

Using 'unknown' does the same for string attributes but what about integers, opaques and most of all, booleans? Better if I can say that I don't have a value for an attribute than to resort to e.g. 'false' as default value.

/Mikael

---

From: James Kempf <[email-masked]>
Date: Thu, 17 Feb 2000 09:35:47 -0800 (PST)

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

IMHO, I don't see this as a particularly difficult task and I think
it should handled if and when the working group is rechartered to
move to draft standard.

I think one change that would be needed would be to
drop the wording in RFC2609 that says a string attribute gets 
initialized with an empty string. The section on implicit
defaults for optional attributes is somewhat problematic anyway,
since if the attributes are optional with no explicit default in the
template and they are not included in the registration, then maybe
they should not be given a default value. Maybe they should just not be there
in that service advertisement. Required attributes are required to have an 
explicit default in the template, otherwise the template is syntactically
incorrect.

If we adopt the convention that empty string is space, then
attribute values lists can contain a single space to indicate empty
strings, like this: val1, ,val2. I don't see much problem
with this. Similarly, if we decide to keep default initialization
of missing optional attributes, then we can specify that
string attributes are initialized to a single space. Any other
solution causes the implicit typing rules to become complicated,
and for purposes of pattern matching, an single space is the
same as an empty string. A similar trick is used to distinguish
between a string containing an integer and an integer value, viz:
"  123" and "123". The former is interpreted as a string, the
latter as an integer.

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

Here's the ABNF for the LDAP string filter from RFC1960

     <filter> ::= '(' <filtercomp> ')'
     <filtercomp> ::= <and> | <or> | <not> | <item>
     <and> ::= '&' <filterlist>
     <or> ::= '|' <filterlist>
     <not> ::= '!' <filter>
     <filterlist> ::= <filter> | <filter> <filterlist>
     <item> ::= <simple> | <present> | <substring>
     <simple> ::= <attr> <filtertype> <value>
     <filtertype> ::= <equal> | <approx> | <greater> | <less>
     <equal> ::= '='
     <approx> ::= '~='
     <greater> ::= '>='
     <less> ::= '<='
     <present> ::= <attr> '=*'
     <substring> ::= <attr> '=' <initial> <any> <final>
     <initial> ::= NULL | <value>
     <any> ::= '*' <starval>
     <starval> ::= NULL | <value> '*' <starval>
     <final> ::= NULL | <value>

The simple item production allows only "tag=value", where "value" is
defined by RFC1776. Taking a quick look at RFC1776, there doesn't
seem to be anything in the BNF for values allowing an empty string,
but a value must be encodable as an ASN.1 Octet String. I don't know
enough ASN.1 to say whether an Octet String can be empty.

		jak

---

From: Mikael Pahmp <[email-masked]>
Date: Thu, 17 Feb 2000 22:01:54 +0100

> From: James Kempf [mailto:[email-masked]]
> Sent: den 17 februari 2000 6:36 PM
> 
> 
> 

...

>      <final> ::= NULL | <value>

It's been suggested by some (me included) to remove the use of the <approx>, <greater> and <less> filter types in SLP. This would make the implicit typing rules unnecessary and reduces SLP implemention complexity. This suggestion should be taken into account when reworking the grammar.

/Mikael

---

From: James Kempf <[email-masked]>
Date: Thu, 17 Feb 2000 14:04:22 -0800 (PST)

>It's been suggested by some (me included) to remove the use of the <approx>, 
<greater> and <less> filter types in SLP. This would make the implicit typing 
rules unnecessary and reduces SLP implemention complexity. This suggestion 
should be taken into account when reworking the grammar.

I suppose this would be ok if it's a MAY rather than a SHOULD or
a MUST. The SA would have to return MSG_NOT_SUPPORTED if it gets
a comparision operator. It will definitely simplify doing the
query handling. To the extent that this helps encourage SLP
adoption, it would probably be a good thing.

The problem is that it cuts off a whole class of applications. There
are a number of products and proposals that involve load balancing,
where being able to do comparisons with numeric attribute values
might prove helpful. For example, suppose you want to find the
terminal server with a load less than 10. Or the printer with
dpi greater than 600. 

One could argue that these kinds of things could be better done
on the client side. Have the client fetch the attribute in
question, convert it to an integer, then do the comparison.
The counterargument is that it increases network traffic. It
will also either complicate the client side or cause clients
to write to the least common denominator. 

So, on the whole, I think it would be a mixed blessing for the protocol.

		jak

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 21 Feb 2000 12:21:10 -0800

Hi James,

I'm alarmed by one of your statements below that says REQUIRED
attributes must have explicit defaults or else the template is
syntactically incorrect.  I understood (incorrectly?) that a
REQUIRED attribute could NOT have an explicit default, because
all registrations by SAs MUST include all of the REQUIRED 
attributes.

The just completed (we thought) SLP 'printer:' template v1.0
has explicit defaults for all (or most) of the OPTIONAL 
attributes but does not have explicit defaults for any of the
REQUIRED attributes.

If I got this all wrong, then we need to revise the SLP
'printer:' template.

Confused,
- Ira McDonald (IETF IPP WG member, consultant at Sharp)
  High North Inc

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, February 17, 2000 9:36 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Empty string attribute value

they should not be given a default value. Maybe they should just not be
there

		jak

---

From: James Kempf <[email-masked]>
Date: Tue, 22 Feb 2000 11:55:08 -0800 (PST)

Hi Ira,

You are right, I misspoke. Both optional and required attributes are
required to have a default *if* the attribute has a list of allowed
values. If there is no allowed values, then one of the standard defaults
is assigned. Sorry for the confusion.

		jak

>From: "McDonald, Ira" <[email-masked]>
>To: "'James Kempf'" <[email-masked]>, [email-masked], 
[email-masked]
>Cc: "McDonald, Ira" <[email-masked]>, [email-masked], 
[email-masked]
>Date: Mon, 21 Feb 2000 12:21:10 -0800
>MIME-Version: 1.0
>
>Hi James,
>

---

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 22 Feb 2000 14:16:55 -0800

Hi James,

Let me get this right.  If an attribute has a list of allowed values
('keywords' in IPP terminology), then that attribute MUST have a
default specified in the template (selected from the allowed values)?
Yes, according to page 20 of RFC 2609, section 3.2.6.4 'Default Value
or List'.

The current SLP 'printer:' template does support the above requirement
(I just checked), for all OPTIONAL attributes.

All the REQUIRED attributes in SLP 'printer:' have a default specified
in a *comment* and have allowed values (an open-ended list) specified
in a *comment* - we didn't want to have to revise the template
registered with IANA if a vendor implementation or next point
version of IPP defined a new value for 'uri-security-supported'
(for instance).

Cheers,

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, February 22, 2000 11:55 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Empty string attribute value

Hi Ira,

		jak

[email-masked]

---

From: James Kempf <[email-masked]>
Date: Wed, 23 Feb 2000 10:05:39 -0800 (PST)

I just checked RFC 2609 and it does, indeed, say that only optional
attributes are required to have a default if there is an allowed list.

		jak