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 09:40:47 -0700

No, we are not talking about RADIUS attributes.  Issue 142 discusses the format for data placed in the Type-Data field of the Identity-Request message.  The latest 2284bis draft says that there can be a displayable string before a NULL character and non-displayable data after the NULL.  However, the format for the latter is not specified.  Some existing implementations use a syntax attribute1=value, ... attributeN=Value in this field.  

-Vic

-----Original Message-----
From: John Vollbrecht [mailto:[email-masked]]
Sent: Tuesday, August 05, 2003 7:32 AM
To: Lortz, Victor; [email-masked]
Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info
hint in Type-Data field of Identity-Request

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:
>
> 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

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

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 05 Aug 2003 16:55:40 -0400

Thanks - I get the idea.

So I think this is a standardization question.  If one includes this sort 
of information in the draft, then  there is a standard way to support it, 
and other implementations would have a way to interact with it.

If we don't put it in, this is still possible, but there is no standard.

I don't know but think that including this would require a lot of 
discussion about alternatives and such, which would delay the draft.  If it 
is a good thing to do, perhaps a brief informational RFC showing how it 
works would be simpler to do than put it in this draft?

-- John

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

> No, we are not talking about RADIUS attributes.  Issue 142 discusses the
> format for data placed in the Type-Data field of the Identity-Request
> message.  The latest 2284bis draft says that there can be a displayable
> string before a NULL character and non-displayable data after the NULL.
> However, the format for the latter is not specified.  Some existing
> implementations use a syntax attribute1=value, ... attributeN=Value in
> this field.
>
> -Vic
>
> 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.
>
> > 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.
> >