The intention of this is to provide some background material for a group discussion and consensus on various 1.0 subtle and obvious issues. Some of these are functionality issues, some are common user interface issues, and some interoperability and understanding (lack of documentation) issues.
UID Handling: "common" usage formats for jids
Normal Functionality based on UID format:
user@host (user identity)
user@host/res (user's connection identity)
host/res (agent or entity, non-user, part of server/transport)
Naming new/unknown jids:
if user@ do a vcard lookup
failing lookup, use just "user (res)"
if host* look at the list of agents, failing that do an agent query to it
failing lookup, use just "host (res)"
(res) is resource in paren, only included if part of the jid.
ALWAYS hide any res data after the ? character in normal usage, show only in an advanced dialog/properties
All resources fall under their parent user or host if known
Username compares must be case insensitive
Transports (from transport authors POV)
Using the roster to maintain the registration
Building the buddy list from the users roster
Discuss handling presence requests and <transport/>
Fields: Locked Form
Same model as registration
Streaming response model
Look at flags, acceptable?
transport @=>% and space smash
Groupchat local / public
use sub agents for list? for topic?
have local public/private?
iq:data namespace to get/set raw xml data?
auth error - redirect to new IP?
Common Naming/Wording guidelines of everything, two sets, one for simple, one for advanced
s10n status display
agent special handling
own resource handling
presence and resource display
Registration w/ server handling
setting offline presence
incoming s10n handling, dialogs
always try digest
if have ssl always try ssl
colorize based on delay, for presence too
subject in chats
default all to user@host
replies to sender id including resource and return thread
fneg and yxroproxy (zeroproxy)
socket disconnect handling, reconnect?