[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encoding of Location-Id and Location-Name in draft-black-radius-lanedge-00.txt
I am not sure that the parsing of a string is all that much more difficult.
Given an arbitrarily large base of locations, you would probably search a
hashed list anyways, and strings are a lot easier for people to manage in
some table or file rather than having to add value assignments to a
On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" <email@example.com>
> Hi Avi,
> The encoding of Location-ID is identical to that proposed by the Wi-Fi
> Alliance in it's WISPr document in section 5.2 for their "Location-ID"
> attribute. I'm not sure where that encoding originated, so I'm not sure if
> there are other applications which make use of it or not.
> There have been discussions regarding making attributes such as Location-ID
> into a common (not vendor-specific) attribute. Since it may be used widely,
> whichever encoding format is preferable (the current WISPr or else TLV)
> should be chosen. Perhaps there are others who have knowledge of why and
> how the WISPr Location-ID format was chosen, and could add their input here.
> -----Original Message-----
> From: Avi Lior [mailto:firstname.lastname@example.org]
> Sent: Monday, December 22, 2003 2:03 PM
> To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK (HP-Roseville,ex1);
> Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l
> Hi Paul, Chuck
> I have an issue with Location-ID and Location-Name.
> Since these attribute may appear in an Access-Request message, I assume that
> they would be used by RADIUS in evaluating policy. Therefore I would not
> want these encoded as a string the way you have it. I would rather see a
> more efficient encoding scheme, one that would make it faster for RADIUS to
> In discussions on this list I proposed to use a single attribute that is of
> type string (the same as yours) that would encode the information using TLV.
> Both of these schemes provide for extensibility and optionality. But the
> TLV approach as an advantage that it is easier to parse for RADIUS ( we
> don't want to slow RADIUS down), and is more compact. The encoding approach
> in your document is human readable.
> IMO the string encoding you propose would be okay if it already has an
> application that expects this type of encoding.
> to unsubscribe send a message to email@example.com with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.