Subject: FW: SLP Question [about reserved characters]

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 3 Aug 2000 08:14:37 -0700

-----Original Message-----
From: McDonald, Ira 
Sent: Thursday, August 03, 2000 8:11 AM
To: [email-masked]'; [email-masked]'; McDonald, Ira;
[email-masked]'
Subject: FW: SLP Question [about reserved characters]

Hi folks,

I've forwarded a question on the legal characters in
string attribute values in SLP templates from Hugo
Parra (Novell).

The particular usage is in our SLP (and LDAP) Printer
attribute 'printer-xri-supported'.

Hugo is finding SLP implementations that are rejecting
the usage of '>' and '<' in string attribute values.

James Kempf or anyone else - some help and direction,
please?

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc
  (co-editor of SLP and LDAP Printer Schemas)

-----Original Message-----
From: Hugo Parra [mailto:[email-masked]]
Sent: Wednesday, August 02, 2000 5:37 PM
To: [email-masked]
Cc: Devon Taylor
Subject: SLP Question

Hi Ira,

We've been using SLP to advertise NDPS printers for some time, but we just
started using 'printer-xri-supported' (as per the recent versions of the
Printer SLP template).  There's some concern relating to the format of this
attribute, specifically, the use of the '<', '>', and '=' characters in its
value.  We checked RFC 2608 (June 1999) and found the following ABNF grammar
in section 5. 

   attr-list = attribute / attribute `,' attr-list
   attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
   attr-val-list = attr-val / attr-val `,' attr-val-list
   attr-tag = 1*safe-tag
   attr-val = intval / strval / boolval / opaque
   intval = [-]1*DIGIT
   strval = 1*safe-val
   boolval = "true" / "false"
   opaque = "\FF" 1*escape-val
   safe-val = ; Any character except reserved.
   safe-tag = ; Any character except reserved, star and bad-tag.
   reserved = `(' / `)' / `,' / `\' / `!'  / `<' / `=' / `>' / `~' / CTL
   escape-val = `\' HEXDIG HEXDIG
   bad-tag = CR / LF / HTAB / `_'
   star = `*'

Notice that 'reserved' includes '<', '>', and '=' and that a 'save-val' must
exclude these characters.  We've already run into a couple of SLP SA
implementations that reject registrations that include these characters.

How safe is it for the Printer template to use these characters?  Do you
know if newer versions of SLP will allow them?  Is there some way to improve
interoperability with implementations that have chosen to enforce the
exclusion rule of 'reserved' characters?  Or am I missing the boat
altogether?

Cheers,
-Hugo

---

From: Matthieu Desmons <[email-masked]>
Date: Thu, 03 Aug 2000 17:21:18 +0200

Hi,

I've had the same problem using Sun's miniSLP for exactly that same
attribute 'printer-xri-supported'

Looking at the code, the SLPReg function indeed explicitely rejects
attribute values containing that character. 

I think I solved that by using the "escaped" version of the character,
i.e. its ASCII hexadecimal code "\3e"

(printer-xri-supported= afirsturi \3e aseconduri \3e etc etc)

It seems to be accepted by the SLP library, but I'm not sure it's the
proper way to proceed.
The best solution IMHO would be to prevent using reserved characters
when defining attribute values in service templates, but since I'm not
an expert I don't know even if ">" is an actually reserved character

Matthieu

---

From: Evan Hughes <[email-masked]>
Date: Thu, 3 Aug 2000 12:06:00 -0400 (EDT)

> i.e. its ASCII hexadecimal code "\3e"

  All characters that are described as reserved (page 11 of RFC
2608) _must_ be escaped before they are passed to SLPReg(). They can be
escaped with the SLPEscape() function. 

  I've also tossed together an API for manipulating SLP attributes -- it
handles all of the escaping and string formatiing for you, so it'd
probably be very handy in this situation. You can get it from:

http://download.sourceforge.net/ssb/slp_attr.tgz

e

---

From: Erik Guttman <[email-masked]>
Date: Mon, 7 Aug 2000 19:40:03 +0200 (MET DST)

You can use the characters < and > but you have to escape them:

 \3c '<'
 \3e '>' 

When these are used in attribute lists (RFC 2608, section 5).  
This is only used in SLPv2 SrvReg and AttrRply messages.  Escapes
on send and unescapes on receive should be done automatically by 
the SLPv2 implementation.  The reason for this escape rule is historic 
(in SLPv1 the search filters allowed 'x<3', where in SLPv2 they can
only be 'x<=3' so there is no ambiguity with respect to the use of
'<' in the attribute value.)  We could drop this character as a 'reserved'
value in SLPv2 as we go to draft standard - if we really wanted to.

These characters are not reserved for Service Templates (RFC 2609)
nor for Search Filters (RFC 2254).

Erik