RE: Encoding of Location-Id and Location-Name in draft-black-radi us-lanedge-00.txt

["CONGDON,PAUL (HP-Roseville,ex1)" <paul.congdon@hp.com>]

The origin of the current Location-ID string comes from X.500 formats.
Surely there is optimized code that can parse this...

Paul

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] 
> Sent: Saturday, January 03, 2004 12:48 PM
> To: Richard Perlman
> Cc: 'Avi Lior'; BLACK,CHUCK (HP-Roseville,ex1); CONGDON,PAUL 
> (HP-Roseville,ex1); radiusext@ops.ietf.org
> Subject: Re: Encoding of Location-Id and Location-Name in 
> draft-black-radius-lanedge-00.txt
> 
> 
> On a related note, there is a proposal in the GEOPRIV WG on encoding 
> civil (city/street) locations in DHCP; see 
> draft-schulzrinne-geopriv-dhcp-civil-01.txt
> 
> It would be really nice if there was some commonality across 
> these formats.
> 
> On 12/29/2003 12:50 PM, Richard Perlman wrote:
> 
> > Avi:
> > 
> > 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 dictionary.
> > 
> > Richard
> > 
> > On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" 
> > <chuck.black@hp.com>
> > wrote:
> > 
> > 
> >>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.
> >>
> >>/chuck
> >>
> >>
> >>-----Original Message-----
> >>From: Avi Lior [mailto:avi@bridgewatersystems.com]
> >>Sent: Monday, December 22, 2003 2:03 PM
> >>To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK 
> (HP-Roseville,ex1); 
> >>radiusext@ops.ietf.org
> >>Subject: Encoding of Location-Id and Location-Name in 
> >>draft-black-radius-l anedge-00.txt
> >>
> >>
> >>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 parse.
> >>
> >>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 
> radiusext-request@ops.ietf.org 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 
> radiusext-request@ops.ietf.org 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>