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