> > >It might help to provide some text relating those to the GEOPRIV
> > >model to assist the GEOPRIV-literate in analysing your document.
> >
> > This is a good idea, but I cannot at the moment know that I'll hit
> > the right balance in the first try - without additional text. If
> > this is to be done in the definitions section, which is fine BTW,
> > what do you suggest I put there? This will help give me direction
> > that you won't be opposed to in my first try. (I'm tired of having to
> > rev over and over again because we didn't see eye-to-eye when we
> > thought we did in fewer words (i.e., talking passed each other
> > without knowing it)
>
>You suggested these two terms:
>
>Inserter: the signalling entity that creates or adds to the
>Geolocation header. If location information is included in the
>message by value, this entity assumes the GEOPRIV role of Location
>Server (LS) by doing so.
>
>(Location) Dereference Server: the entity that serves a location
>URI. This entity assumes the GEOPRIV role of Location Server (LS).
ok - cool, I can run with that. I believe this will directly clear up
John Elwell's (and others) confusion about the many forms of Geopriv
entity roles.
I have a more meta question that's a hole in the above "inserter" role though:
what is the role of the SIP server that inserts a location URI of
the Target?
that's gotta be defined somewhere. I believe this entity is also an
LS, because it is a location aware entity that is sighting (put aside
the fact that you hate that word) the target. This "act of sighting"
is location awareness - ergo an entity role within Geopriv
architecture. This entity would _not_, however, be an LG (that's
saved for LO creators, which this entity does not do).
James
>That's my interpretation in a few words as I can manage.
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv