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

From: "Lortz, Victor" <[email-masked]>
Date: Tue, 5 Aug 2003 06:53:12 -0700

In that case, I have an additional suggestion.  I think the namespace feature of XML is a very useful feature for enabling innovation by multiple independent implementations without creating naming conflicts.  When you have a simple list of "attribute=value" syntax with no additional structure to provide context, there is a substantial risk of collisions.  

Suppose we borrow the idea of XML namespaces without actually using XML.  The original attribute set that is already planned to be standardized using IANA registration could be considered as belonging to a default namespace and thus need no namespace prefix.  This case would be 100% compatible with existing implementations.  

However, for vendor-specific or domain-specific attributes, a namespace attribute could be included along with a prefix for decorating those attributes.  Existing implementations would see both the namespace and attributes in that namespace simply as unrecognized attributes that they would presumably ignore.  The advantage is that new implementations that understand the new attributes could use them without risk of confusion with identically-named attributes that have different semantics.  The biggest impact on existing implementations would be that their attribute name parsers would need to support a namespace prefix delimiter.  We may as well use the same ":" character that XML uses.  Here is an example:

networkid=SomeSSID, nasid=SomeNASName, portid=123, 
eapns:v=urn:vendor.com:net-info:1, v:foo=some value, v:bar=some other value
 
Here is some proposed ABNF for this syntax:

identity-request-data = displayable-string [ %d0 network-info ]
displayable-string = *CHAR

network-info = item ["," item ]
item = attribute "=" value 

; attribute names must start with a letter or underscore
attribute = (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; default namespace
attribute =/ "eapns:" 1*ALPHA  ; namespace prefix declaration
attribute =/ 1*ALPHA ":" (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; namespace-qualified

value = 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except ","

Regards,
Vic

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Saturday, August 02, 2003 8:23 PM
To: [email-masked]
Subject: [eap] Re: Issue 142 suggestion: syntax for network info hint in
Type-Data field of Identity-Request

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

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 05 Aug 2003 10:31:54 -0400

I apologize for my confusion, but I need a little help.  As far as I know 
the EAP Identity Request does not include any attribute value pairs.  This 
suggestion seems to be suggesting adding an environment attribute to the 
Identity request to support vendor specific attributes.

Perhaps this is meant to be about RADIUS messages?   Is this about 
expanding the meaning of data in the Identity Response?

I think I am missing something?

-- John

--On Tuesday, August 5, 2003 6:53 AM -0700 "Lortz, Victor" 
<[email-masked]> wrote:

> In that case, I have an additional suggestion.  I think the namespace
> feature of XML is a very useful feature for enabling innovation by
> multiple independent implementations without creating naming conflicts.
> When you have a simple list of "attribute=value" syntax with no
> additional structure to provide context, there is a substantial risk of
> collisions.
>
> Suppose we borrow the idea of XML namespaces without actually using XML.
> The original attribute set that is already planned to be standardized
> using IANA registration could be considered as belonging to a default
> namespace and thus need no namespace prefix.  This case would be 100%
> compatible with existing implementations.
>
> However, for vendor-specific or domain-specific attributes, a namespace
> attribute could be included along with a prefix for decorating those
> attributes.  Existing implementations would see both the namespace and
> attributes in that namespace simply as unrecognized attributes that they
> would presumably ignore.  The advantage is that new implementations that
> understand the new attributes could use them without risk of confusion
> with identically-named attributes that have different semantics.  The
> biggest impact on existing implementations would be that their attribute
> name parsers would need to support a namespace prefix delimiter.  We may
> as well use the same ":" character that XML uses.  Here is an example:
>
> attribute = (ALPHA / "_") 1*( ALPHA / "-" / "_" / DIGIT) ; default
> namespace attribute =/ "eapns:" 1*ALPHA  ; namespace prefix declaration