Option #2 explains why my registrations didn't work -- instead of embedding
the escaped sequence directly in the .reg file, I was expecting some sort of
parsing to be done on load.
--Nick
On Tue, Sep 20, 2011 at 1:46 PM, John Calcote <john.calc...@gmail.com>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.
>
> 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
>
------------------------------------------------------------------------------
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
