Re: draft-jones-radius-geopriv

[Henning Schulzrinne <hgs@cs.columbia.edu>]

schofenig Hannes wrote:

> hi henning,
> do you remember our discussions in the washington interim meeting? 
there we
> considered the http proposals for distributing location information. 
andrew
> daviels proposed a custom location information format. there we 
argued that
> we have to consider privacy issues (and therefore our results of the 
geopriv
> working group). the geopriv working group decided to build their location
> objects based on xml (and also the policies). some size considerations go
> along with it (also with the usage of s/mime).


That's putting it rather mildly... Given the trivial structure for the 
basic PIDF privacy information, I'm not convinced that we always need 
the full generality of a GML object. I'd like to hear a technical, 
rather than procedural, argument for disallowing that. (In HTTP, the 
size argument was largely a non-issue.)

There might be more general value in a restricted format, as it could be 
applicable to other limited-functionality and bandwidth/size-constrained 
cases. There is clearly precedent for coding information in multiple 
formats; the DHCP drafts are examples of that.

The other alternative is http://www.w3.org/TR/wbxml/, but that 'note' 
comes with warning labels that indicate that this is not exactly a 
future-proof effort.

>
> regarding your dhcp example: the dhcp scenario is a little bit 
different to the radius/diameter example
> since the location information which is distributed is not only about the
> visited network but rather about the user (and also used in this sense).


It would be a trivial exercise to embed the privacy flags into a TLV 
encoding.

I have nothing against XML, but I'm worried about declaring it a 
religion where any questioning of its universal applicability is 
considered sacrilege.

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