[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-jones-radius-geopriv

Why not re-use the encoding used in the civil version for DHCP? Compression will not help significantly unless you use a SIGCOMP approach and your dictionary is exactly right. The complexity of doing that boggles the mind.

Tschofenig Hannes wrote:

hi john,

thanks for your observation.

i see the following ways to tackle this problem: - forget xml and use a different encoding which is more "lighweight"
- switch to diameter - compress xml objects

i personally think that the privacy issues are worth thinking about these
options. 

ciao
hannes


-----Original Message-----
From: John Schnizlein [mailto:jschnizl@cisco.com]
Sent: Monday, February 16, 2004 1:53 AM
To: Tschofenig Hannes
Cc: radiusext@ops.ietf.org; geopriv@ietf.org
Subject: Re: draft-jones-radius-geopriv


I am sorry I quoted the wrong part of RFC 2865.
The length of an attribute is at most 255, one octet [page 25].
It seems unlikely that GML, or any XML, would be efficient enough to be carried in a RADIUS attribute.

At 01:12 PM 2/10/2004, John Schnizlein wrote:

One concern, if this location configuration information (LCI)
is to be carried over RADIUS, is that the example in section 6
seems to be 993 characters long. This one attribute seems to be
taking a large share of the maximum RADIUS packet size of 4096.
[RFC 2865, p 15] Is there enough room for everything else that
would be expected with this attribute?



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