Subject: [Geopriv] RE: draft-jones-radius-geopriv

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 17 Feb 2004 16:45:32 +0100

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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: jo walsh <[email-masked]>
Date: Wed, 18 Feb 2004 19:22:02 +0000 (GMT)

hello,

> > Given the trivial structure for the 

we'd like to offer some positive reasons for optionally allowing the
RDFIG namespace for geo:Points with latitude and longitude referenced to
the wgs84 datum; 

http://www.w3.org/2003/01/geo/wgs84_pos#  

<geo:Point>
<geo:lat>31.93333</geo:lat>
<geo:long>115.83333</geo:long>
</geo:Point>

- the WGS84 datum is assumed in the schema so there's no need to send a
datum attribute with each point.        
- having lat and long as separate properties arguably makes parsing and
validation easier   
- it is trivially extensible with properties from other RDF vocabularies 
http://locative.net/etcon2004/packet.html shows a guideline for a simple
'geoannotation' object which uses the FOAF vocabulary[0] to make 
assertions about the person or other presentity who annotated that point
in space and time, and the media optionally attached to it. 

http://locative.net/etcon/plan.pl?Locative_Packets_To_GML_Servlet shows a
simple rdf/xml -> GML converter for those who really want GML. This was
done at a collaborative mapping workshop at the Emerging Tech conf last
week, at which some of us saw Jon Peterson's talk about geopriv and
presence work, which led us here. thanks.  

Jo Walsh, Schuyler Erle

[0] http://xmlns.com/foaf/0.1/  
--
"Common sense won't tell you. We have to tell each other." -DNA