[Simple] Comments on draft-garcia-simple-indirect-presence-publish-01

["Thomson, Martin" <[e-mail]>]

Hi Miguel, Hannes, Henning,

On the whole, I think that this document gives fair treatment to the problem.  At problem that I am quite interested in seeing solved.

General comments:

This document needs to give the concept of presence compositing more thorough treatment.  Particularly when you look at the data model and rich presence plus location, there is a role that a PA (potentially) plays in bringing all these components together.  In effect, where presence information is provided by reference, the PA is then able to treat the server as another presence source.  This concept is a key one that elevates this document to general applicability for any type of presence information.

In this regard, you might find the definition of presence source in draft-thomson-simple-cont-presence-val-req to be helpful.

I think that the terminology could be more closely aligned with Geopriv terminology when talking about Geopriv protocols and roles.  Geopriv documents use the term location information server (LIS) instead of "LCP server".

For consistency with 3856, the term presence agent (PA) is more appropriate than presence server.

Specifics:

Section 1.1:

Rather than use the generic term "reference" in this context, I think that it is reasonable to use "location URI" as introduced by draft-ietf-geopriv-lbyr-requirements.

Figure 1 is entitled "Current Geolocation Protocols Relationship", but to be completely correct it is describing the relationship between current presence protocols and the geolocation protocols.

This statement (aside from needing s/send/sent/) is not quite correct.

   The kind of reference that is first acquired and then send to the
   location recipient determines the value that the location recipient
   gets in step 3.  Section 1.2 discusses location URIs.

"kind of reference" is a bit vague.  I assume that it refers to whether the reference is a URI or maybe the actual URI scheme used.  However, the type of reference is unlikely to say anything about the resource it references.

Figure 2 seems orphaned - there is no surrounding text.  It's key to the discussion - it's the core of what the document proposes, so it needs prose to support it.

Section 1.2:

The key message missing from the introduction of this section is absent.  That is, a location URI is an example of a reference to presence information.  Two things distinguish it from the generic "reference" referred to in discussion before this point: (1) it's a URI and (2) it refers to location information only.

(Incidentally, I don't think that it's worth your while continuing to discuss references entirely in the abstract - let's just assume that they will be URIs and move on.)

I don't think that this section needs a discussion on static and dynamic location URIs.  This digression distracts from the main goal of the draft.  It is safer (and ultimately easier) to assume that the document referenced by a location URI is dynamic.  To that end, the privacy discussion can be dropped and moved to a more appropriate place (draft-ietf-geopriv-lbyr-requirements or draft-barnes-geopriv-lo-sec maybe).

Section 1.3:

Presence Agent, Presence Source, presence terms... Location URI, LR, LS, LIS, geopriv terms...  Maybe add a brief note distinguishing location server from registrar as this becomes an overloaded term.

Section 2:

I'd like to see this entire section made generic.  This doesn't need to be location-specific, even if location remains the only use for the foreseeable future.  i.e.: "A presentity acquires a reference to presence information in the form of a URI."  Then provide an example: "For example, a HELD request is made to a LIS requesting a location URI."

I object to the restriction to sip: or sips: URIs.  I see no reason why a PA that is suitably equipped couldn't make an HTTP request.  You also forgot pres:, a scheme that seems quite appropriate.

As for options, option 1 isn't terrible, but option 3 is quite bad.  I like option 2.  You see, Geolocation is rather too specific to location information.  There is a risk that the semantics of Geolocation could be incompatible with what this new functionality might want.  More importantly, I'd like to use something that is not specific to location information.

A while back "Geolocation" was called just "Location".  That conflicted with an HTTP header that already has clear semantics that might be confused with the intent of the Geolocation header.  ("Location" taking the old-fashioned _network_ location meaning.)  If you look at those semantics they are (to me) a fairly close match with what you are looking for.  The "Location" header says: "the body of this message can be found here: <URI>".  

The drawback can be addressed by having the server indicate that it understood the header somehow.  I'm not the expert here, but this doesn't seem intractable.  Maybe this is a case for a new 'indirectpub' Require header tag.  A 420 would indicate that the UAC needs to go off and dereference itself.

Once you make a decision (and I'd encourage you to consider the above), there's obviously a lot of work to do defining headers, writing examples and so forth.

Section 4:

I don't think that doing security considerations by reference is right.  There is good text on this in geopriv documents: the aforementioned draft-ietf-geopriv-lbyr-requirements or draft-barnes-geopriv-lo-sec, plus draft-ietf-geopriv-sip-lo-retransmission all have useful text as well.

In the end, the security story is a lot simpler than sip-location-conveyance.  It's mostly about privacy.  There are two stories to tell: possession model where you rely on channel security, and access control model, where you really don't care who gets the reference.

Regards,
Martin

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]