John Calcote wrote:
> Here's the relevant portion of section 6.4 of RFC 2608:
>
> "String lists used in SLP define the comma to be the delimiter between list
> elements, so commas in data strings must be escaped in this manner."
>
> I read this to mean (explicitly) that commas used to separate list elements
> are NOT to be escaped. All other commas should be escaped. I believe this is
> what Roel meant when he referred to "data strings" - the content within a
> single list element is data. Thus, sending code must be careful to escape
> data before adding it to an element list.
Seems that you are indicating that a client, using the OpenSLP API, must 
manually escape strings before sending it? For example something like

slptool register service:foo:http://foo.bar:1234 "(Description=This 
service\29 and any sub service\29 is a foo)"

Is that what you are indicating? I'm fine with that interpretation, 
although it means that any client will need to know to deal with this. 
This seems to imply that the server/client API's don't do any escaping 
tho, no?
>
> On the other hand, receiving code must be careful to parse lists into
> elements before decoding them so that the element list can be parsed
> properly. If decoding is done first, then the receiver won't know which
> commas are meant to separate elements, and which ones are part of data
> strings.
I think the cause of my concern is the following statement from section 5

"The <attr-list>, if present, MUST be scanned prior to evaluation for
    all occurrences of the escape character `\'.  Reserved characters
    MUST be escaped (other characters MUST NOT be escaped).  All escaped
    characters must be restored to their value before attempting string
    matching."

This seems to imply that the server and the client have to scan the list 
and convert escaped/reserved characters, at least the '\' character, but 
I think the second sentence indicates all reserved characters MUST be 
dealt with. It doesn't appear OpenSLP is doing that.
>
> Our server SA/DA has two options regarding escaping:
>
> 1. It can unescape elements stored in the database and then re-encode them
> before sending them to other remote entities (UA/DA), or
> 2. It can simply disregard escaping entirely, storing escaped strings in the
> local database, comparing strings sent from remote entities without
> unescaping them, and forwarding them as-is to remote entities.
>
> Personally, I opt for 2 - why do the extra work unless you need to interpret
> the data for some reason other than comparison with other strings sent by
> remote entities?
This option means that a client app, using the OpenSLP api's has to 
escape/unescape the strings manually?


Am I misunderstanding something?
jim

>
> More than one problem exists if the C version of our UA doesn't escape
> element contents (data strings) before embedding them in lists: element
> parsing and comparison will be broken on the server.
>
> It sounds like Jim's discovered a discrepancy between the way the Java and C
> UAs encode data before embedding them in element lists.
>
> John
>
> -----Original Message-----
> From: Jim Marshall [mailto:jim.marsh...@wbemsolutions.com]
> Sent: Tuesday, September 20, 2011 11:58 AM
> To: openslp-users@lists.sourceforge.net
> Cc: John Calcote
> Subject: Re: [Openslp-users] Attribute values with comma's treated
> differently between Java and C
>
> Roel van de Kraats wrote:
>> The way I understand section 6.4 of
>> http://www.openslp.org/doc/rfc/rfc2608.txt is that commas only need to
>> be escaped when they are part of the data strings, not when they are
>> used as delimiter.
>>
>> If so, the java implementation should be modified not to escape the
>> delimiters.
>>
>> BR,
>>      Roel
> Hi,
>    I am not sure I fully follow this logic, perhaps I am misunderstanding
> something. How would a client (like slptool) know when a string is
> considered a "data string" or not? Specifically look at this hypothetical:
>
> slptool register service:foo:http://foo.bar:1234 "(Description=This service,
> and any sub service, is a foo)"
>
> In this case the intention is that the attribute value is a 'data string',
> as such the client should escape the commas - no? But how can the client
> determine that is the case? In other words the client could infer that this
> attribute is a data string where the comma should be be escaped or it could
> be a string list that has 3 entries "This service", "and any sub service",
> "is a foo" where the commas are not escaped?
>
> Am I misunderstanding the escaping rules?
>
> It doesn't appear that the C API escapes any characters. For example
>
> slptool register service:foo:http://here.com:2268 "(attr=<hello>)"
>
> The '<'&  '>' should be escaped since they are reserved, but wireshark shows
> the text being sent across as is. This is particularly an issue whe the
> string contains parens as what gets sent across the wire is invalid.
>
>
> unfortunately I don't seem to have an environment to build a debug version
> of the C API so I can't debug the code like I would normally do to see what
> is happening. I am working on getting one tho.
>
> Thanks agains
> Jim
>
>


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Openslp-users mailing list
Openslp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-users

Reply via email to