Further to the debate about possible expired(bogus) status and some other stuff..
Wanicki, Martin
Martin.Wanicki at Australia.Boeing.com
Tue Nov 20 11:17:45 EST 2001
Dear 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.
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.
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
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)
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?
Over to y'all
Cheers
Martin
More information about the ticker-dev
mailing list