DevCon3Agenda

Here are some possible DevCon agenda items...

Room: devcon@conference.jabber.org

XMPP-CORE

XEP-0198: Stanza Acknowledgements

• Justin to update the spec to reflect IRL discussion

Mixed child elements in message/presence (Justin to write first draft of best practices spec):

• Each message stanza is of a single profile.
• Transmission elements don't affect the profile, and these elements need to be noted as transmission elements in whatever document proposes them (e.g. x:delay, AMP).
• Each element is part of some profile. Unless otherwise stated, every element of a given namespace is in the same profile.
• Unknown elements don't affect the profile.
• Mixing profiles is invalid, except that you may mix the IM profile with any other profile as a fallback means.
• When determining what profile a stanza falls under, consider the IM profile as a last resort.
• need to specify in transmission specs that they are transmission elements
• need to specify in message payload specs that they are in IM profile or some other profile

Stanza size limitations

• specify that stanza-too-big error includes max stanza size
• specify IQ interaction for client to set its desired max stanza size

COMPONENT PROTOCOL

Consensus to solve the basics

• TLS
• SASL
• Component Binding
• Use jabber:client
• Specify simple username format more carefully

No consensus to solve more advanced features yet

• Domain subscription
• Namespace subscription
• Presence subscription
• Roster subscription and manipulation
• Route

COMMUNITIES

See MUCOM

Lengthy discussion about using MUC for communities. PSA to write up with help from Bruno and Yann at Wimba.

Notes......

conference/community

a profile of MUC presence only MUC (or can send messages to group) define sensible defaults deploy as separate service

disco#items to find communities disco#info to discover community type (or receive via caps)

presence subscribe to community presence subscribed from room

log in

server sends my presence to room

presence from='comm' CAPS say "I'm a community" presence

need ability to query room for member list

roster annotation for items that "this is a communities item" get annotations before get roster

who can see community via disco#items? who can join community? (subscribe to community) who can see presence of community members? whose presence is shown in community?

send my privacy list (presence out) to community so it can filter presence-out

MUC STUFF

• MUCOL -- Bruno discussed on Day One
• Distributed MUC
• Message moderation

SECURITY

• Requirements, requirements, requirements (XEP-0210)
• Stanza signing (broadcast and directed)
• Auth via PGP key? (IIRC there's a TLS method for this - see http://tools.ietf.org/html/draft-ietf-tls-openpgp-keys
• ESessions
• Justin's "JEP-Secure"
• SPAM fighting / reporting
• DDoS
• Ubiquitous TLS on open network -- can't get rid of Server Dialback anytime soon, but how do we encourage server admins to get certs? "Secure Communications Week" with TLS only?
• Server reputations? Lukewarm reaction.

User registration

• CAPTCHAs for user registration?
• Redirect to website, the web folks have to deal with this more than we do so they are probably better than we are!
• Limit number of accounts created in a time period

Groupchat spam problem

• IP hash
• Auto-ban based on bad word filter
• Host server limits number of accounts created in a time period
• Per-room karma

FILE TRANSFER

• Existing methods don't work well enough
• Requirement to send multiple files? Also thumbnails?
• Jingle to get reliable transport (e.g., ice-tcp, perhaps even IBB)
• Then: HTTP? IQs?
• IBB is a good fallback if all else fails
• Conclusion of IRL discussions: we need to clearly define requirements...

Requirements...

• Usually XMPP and HTTP servers available
• Offline use case
• Upload to MUC room
• Virus check at server
• No HTTP server available
• No XMPP server available (link-local)

PUBSUB/PEP

• publish-options
• persisting public data objects
• private data storage

Specs:

• XEP-0060: Publish-Subscribe (1.9)
• XEP-0163: Personal Eventing (1.0)

Works in progress:

• XEP-0060 1.10 working draft
• XEP-0163 1.1 working draft

IRL discussions:

• Come up with ~5 node types a la MUC room affiliations? -- all these node configuration options are too complicated and users will never be able to handle them! Here are some possibilities....
• Private node: whitelist access model, only account owner on whitelist, persist data -- see PDP
• Public node: open access model, anyone may subscribe or get items
• Eventing node: presence access model, filtered notifications
• Data node: open access model (e.g., public keys / user profile), persist items -- see POP

SHARED EDITING / WHITEBOARDING

• similaries to MUCOL (permissions / media sessions)

OTHER OPPORTUNITIES

• extended presence
• more use cases beyond IM