[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-jones-radius-geopriv
hi henning,
thanks for you quick response.
> 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.)
i have not objections against adding privacy issues to other drafts.
as you know i was not a big fan of gml at the beginning (which motivated
jorge and christian to come up with their own location object draft) but
looking deeper in it it turns out to contain useful stuff. looking at the
features provided by it would not hurt.
>
> 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.
true. i also saw this link.
another alternative is to switch to diameter.
>
> >
> > 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 agree with you. it wouldn't be a drawback to merge some other aspects as
well.
>
> I have nothing against XML, but I'm worried about declaring it a
> religion
.. which i wouldn't do.
> where any questioning of its universal applicability is
> considered sacrilege.
our draft and our intention does not go that far. it raises some issues
(privacy, what location information could be useful,security,...), shows
scenarios and points to work done in other places in the ietf. i think is
fair todo that.
ciao
hannes
>
> --
> 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/>