[ticker-dev] Further to the debate about possible expired(bogus) status and s ome other stuff..

[Phillips, Matthew]

Hi all,

> If a client sends a request and receives no response from 
> person(s client)
> for which it is 
> currently maintaining status information could it not then 
> safely mark that
> persons status information as offline.

This is true.  The offline status is still needed though for when a client
is shutting down and wants to indicate it is no longer there.  If we don't
have this, we will have to rely on all clients sending fairly regular
'heartbeat' updates in order not to disappear off everyone else's screens.
One of the nice things about the current approach is that, once everyone is
clear about who's out there and what their info is, nothing needs to be
transmitted until someone's state changes.

> In section 3.9 of the draft spec 0.3.1 makes mention of a status-info
> attribute which doesn't exist in the formats.

This is a typo: 'Status-Info' should have been 'Presence-Info'.  This has
been corrected in the next revision.

> If the 'presence-info' attribute is actually the one being 
> discussed in that
> section, the content of the attribute "reply"
> is also in error, and indeed the example could not easily be 
> reproduced
> using the notification format as described in section 3.7 and the
> subscription example in 3.9 

This example was originally correct, but after accepting that "reply" could
be left out of this field I forgot to update the later example.

> A client could, I suppose exclude all notifications that do 
> not contain
> "initial" or "update" as the contents of the presence attribute,
> but ever the advocate for simplicity, I make the following comments..
> 
> In actual implementation of the protocol, I'm wondering about 
> the practical
> importance of the different Presence-Info
> types. If you add "Status" "Status-Text" and "Duration" as the minimum
> *required* set of information the info type really doesn't matter
> Sure, identify it as either an unsolicited notification or a 
> reply so that a
> client can for whatever reason opt out of replies, 
> but this seems sufficient to me.
> Handle the missing attributes and only update the registry 
> with the supplied
> information seems a reasonable approach, (to me)

I think it is important since it allows clients, if they wish, to optimize
what they see.  If they do not want to see replies to requests from others,
then they can specify that be the case, if they don't care that's fine too.
If we leave the option for this sort of capability out now, it will be very
hard to add later and it's not hard to implement.

> Also I'd like to open debate on the presence protocol being used for
> initiation of a one-on-one conversation rather than the 
> thread_id of the
> tickertape format.
> I'm not suggestion thread-id be canned from the other format, 
> its *really*
> useful for the "kill thread" option, but not so much for the 
> one-on-one
> stuff, I don't think.
> I'm thinking that to integrate a conversation initiation into 
> the presence
> protocol might be a good thing. 
> Or should we develop something more along the lines of the 
> conversation
> initiation that Julian discussed for secure messaging in the workshop?

My take on this that presence is for seeing who's out there in order to send
them a message, but once that's done, there's no reason to use a different
protocol to send the message or use a different interface to read the
message.  The 'personal messaging' approach enabled by auto thread
subscription has been working well here and seems intuitive to our local
users: they simply select a person from the 'online' window and double-click
to send a ticker message to them.

I'm sure presence could aid the initiation of secure conversations.  One way
might by publishing the person's public key, assuming that the presence info
itself can be authenticated.

Cheers,

Matthew.