RE: xFx and source address syntax

["Edward Pearson" <xap@xxxxxxxxxxxxxxxx>]

This is where the spec is very unclear: values in a key-value pair that
are=
part of protocol itself i.e., all the fields in the header. What's the all=
owable character set? Are they case sensitive?

The spec says ASCII but this can be interpreted as 7-bit ASCII or 8-bit
(an=
d by implication, but again unspecified, a code-page). But it also says
not=
hing about each element not containing '.' or ':' but doing so would
clearl=
y break all implementations.

It's been argued (but it's not stated in the spec)  that these values (eg,
=
source, target) should use the same rules as keywords which at least are
re=
asonably specified:

A..Z (A through Z), a..z (a through z) 0-9 (zero through nine), _
(undersco=
re), - (dash) and space (ASCII character 32 decimal).

But I've never seen spaces in an address element (and I don=E2=80=99t
think=
I'd want to see any).

Anyhow your example of a dash '-' seems perfectly reasonable. My suggested
=
fix would be just to extend the current alphanumeric with dash and
undersco=
re and leave it there.

Edward

-----Original Message-----
From: Per Malmberg [mailto:per@xxxxxxx]=20
Sent: Sunday, 13 March 2011 3:58 PM
To: Edward Pearson
Subject: xFx

Hello Edward,

I've found an inconsistency between xFx Express, xFx Viewer and the xAP
spe=
c.

Take the following message and feed it to the viewer and everything is OK.
=
However, letting xFx parse it results in a validation rule failing.

xap-hbeat
{
v=3D13
hop=3D1
uid=3DFF.05554CF2:0000
class=3Dxap-hbeat.alive
source=3DxFx.Hub.Eee-Box
interval=3D60
port=3D3639
}

The problem is the '-' character in the source as xFx-E only allows
alpha-n=
umerics, see regular expression 'ValidRegEx', line 91 in xAPAddress.cs.

The specification states that, when delimiter =3D is used, values are
encod=
ed as ASCII strings. The '-' is part of the ASCII table and should
therefor=
be a valid character.

I'm not sure I've got it all covered, but changing the regex to the
followi=
ng would allow for all basic ASCII characters within each element,
excludin=
g non-printable ASCII and the '.'-character.

^[\p{IsBasicLatin}-[.:\x00-\x1F]]+(\.[\p{IsBasicLatin}-[.:\x00-\x1F]]+){2,}=
(:[\p{IsBasicLatin}-[.:\x00-\x1F]]+(\.[\p{IsBasicLatin}-[.:\x00-\x1F]]+)*)?=
$

This would of course invalidate any addresses using extended ASCII, such
as=
our Swedish '=C3=A5=C3=A4=C3=B6' and likewise other Scandinavian character=
s, but I'd rather have that instead of arbitrary validation rules.

What's your opinion in this matter?

Best Regards,

Per Malmberg




------------------------------------