Subject: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request

From: [email-masked] (Bernard Aboba)
Date: Sat, 2 Aug 2003 20:22:52 -0700 (PDT)

There are a few issues with the proposed approach.

a. This is not what current implementations do, and RFC 2284bis is
primarily about documenting existing behavior.  By going with XML we would
be creating two distinct and non-interoperable "hint" specifications, and
that seems like a bad idea.

b. Given that the Identity method doesn't support fragmentation, we are
limited by the minimum MTU (see Issue 162).  Given those limitations it
would seem that the additional overhead of XML would be potentially
problematic.

-----------------------------------------------------------------------
In Issue 142, Bernard has suggested that specification of the Type-Data
field data of Identity-Request after the nul character should include:

a) An ABNF describing the grammar for the parameters and values;
b) IANA considerations for allocation of parameters and values.

Here is a suggestion for dealing with points a) and b).

Suppose we use XML syntax instead of the previously proposed syntax for
this data.  IANA considerations can  be dealt with using the XML
namespace mechanism.  Here is an example:

display-string\0<?xml><NetInfo xmlns=3D"urn:ietf.org:EAP:Netinfo"
networkid=3D"SomeSSID" nasid=3D"SomeNASName"  portid=3D"123" />

The schema associated with urn:ietf.org:EAP:Netinfo would define the
attributes networkid, nasid, portid,  and whatever else might be
appropriate.  The leading <?xml> is not strictly necessary, but it might
be useful to help avoid confusion with existing practice that uses
comma-separated attribute=3Dvalue syntax.

One advantage of this approach is that vendor or domain-specific
extensions can easily be added without requiring additional IANA
requests.  For example,

display-string\0<?xml><NetInfo xmlns=3D"urn:ietf.org:EAP:Netinfo"
xmlns:gsm=3D"urn:3gpp.org:wlan-info:1"  networkid=3D"SomeSSID"
nasid=3D"SomeNASName" portid=3D"123" gsm:VPLMNS=3D"123456 123654 111222"
/>

To simplify parsing, it might be preferable that the schema restrict the
NetInfo element to have only attributes, as shown in these examples (no
child elements).   Besides the parsing simplifications that this
restriction would provide, attributes are also more compact than
elements (no need for a trailing </element>  tag).

Regards,
Vic Lortz
Intel Corporation