Subject: Re: FW: SLP Question [about reserved characters]

From: James Kempf <[email-masked]>
Date: Thu, 3 Aug 2000 14:36:06 -0400

Using escaped versions is the right way to go. I think maybe we need to make sure
that templates have escaped versions of characters in them when they are submitted.
Perhaps we can put that on the list of things the designated expert should look for
when reviewing a template.

		jak
>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
>
>
>
>"McDonald, Ira" wrote:
>> 
>> -----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: "Hugo Parra" <[email-masked]>
Date: Thu, 03 Aug 2000 14:56:19 -0600

The ABNF grammar in section 5 of the SLP RFC (included below) seems to indicate that escaped characters are allowed only in 'opaque' attribute values.  Opaque values require all of its characters to be escaped, right?

To explicitly allow escaped characters in a 'strval' attribute value, the ABNF grammar may need to be modified as follows,

From
   strval = 1*safe-val

To
   strval = 1*stritem
   stritem = safe-val / escape-val

Any thoughts?

-Hugo

>>> James Kempf <[email-masked]> 08/03/00 12:36PM >>>

		jak

---

From: James Kempf <[email-masked]>
Date: Fri, 4 Aug 2000 08:58:03 -0400

Yes, I believe Evan point this out a few weeks back. We need to change the ABNF. Thanx
for the reminder.

		jak
>The ABNF grammar in section 5 of the SLP RFC (included below) seems to indicate
>that escaped characters are allowed only in 'opaque' attribute values.  Opaque
>values require all of its characters to be escaped, right?
>
>To explicitly allow escaped characters in a 'strval' attribute value, the ABNF
>grammar may need to be modified as follows,
>
>From
>   strval = 1*safe-val
>
>To
>   strval = 1*stritem

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 7 Aug 2000 13:09:51 -0700

Hi Erik,

Thanks!  Those are good clarifications (below).  The
characters '<' and '>' are uniquely valuable in string
attribute values that have imbedded structure and also
include URLs (because '<' and '>' are guaranteed to
never be included in URLs proper by RFC 2396), such
as 'printer-xri-supported' in SLP/LDAP 'printer:' schema.

Cheers,

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Monday, August 07, 2000 10:40 AM
To: McDonald, Ira
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: FW: SLP Question [about reserved characters]

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