> -----Original Message----- > From: Jim Marshall [mailto:jim.marsh...@wbemsolutions.com] > Sent: Tuesday, September 20, 2011 1:27 PM > To: John Calcote > Cc: openslp-users@lists.sourceforge.net > Subject: Re: [Openslp-users] Attribute values with comma's treated differently > between Java and C
> 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? That's exactly what I meant. In fact, there's no other way to do it when using slptool, as it accepts full element lists on the command line - if the user doesn't escape strings manually when passing the list, how will any of the code know which commas are element separators and which are embedded? In fact, the UA library calls accept complete element lists as arguments, so it must be that either the authors of 2608 intended the callers of the UA library to do all the escaping beforehand, or else they made a mistake in the specification (not impossible). Regardless, when Caldera started the project, it's pretty clear from the code that they interpreted the RFC to mean that the user is intended to pre-escape strings before passing them in. Of course, higher-level applications can manage this for the user when an application is written to register strings with the OpenSLP UA. Again, the intent is clear, from the existence of the SLPEscape and SLPUnescape functions in the C API defined in RFC 2614, that the application is intended to escape data strings on input, and unescape them on output. The problem appears to be that the Java API takes more upon itself than it should. > > > > 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." Yes, this is a sore point and one of those places where the slp designers probably disagreed and missed the lack of alignment in the final analysis. This paragraph is not even self-consistent. Consider: The subject is "<attr-list>", which by definition contains characters that must not be escaped, but which are reserved characters (e.g., the element separator - comma). In other words, it must contain unescaped reserved characters, but it also must be processed at this point to escape all reserved characters. The only reasonable way to manage this is to have <attr-list> be fully escaped before being processed at this level. > > 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. A very literal interpretation that also works would have the caller escaping only those characters that make the caller's intent unclear - embedded list element separators. Then the slp UA would escape the rest. That seems wrong in several ways (to me). I think we need to remove the internal escaping code from the Java API and provide escaping functions in the public interface, like the C API does. Regards, John ------------------------------------------------------------------------------ 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
