Difference between revisions of "DevCon3Agenda"

From XMPP WIKI
Jump to navigation Jump to search
Line 28: Line 28:
* Roster subscription and manipulation
* Roster subscription and manipulation
* Route
* Route
==COMMUNITIES==
See [http://www.wimba.com/labs/mucom/ MUCOM]
Lengthy discussion about using MUC for communities. PSA to write up with help from Bruno and Yann at Wimba.


==MUC STUFF==
==MUC STUFF==
* [http://www.wimba.com/labs/mucol/ MUCOL] -- Bruno discussed on Day One
* [http://www.wimba.com/labs/mucol/ MUCOL] -- Bruno discussed on Day One
* [http://www.wimba.com/labs/mucom/ MUCOM]
* [http://www.xmpp.org/extensions/inbox/distributedmuc.html Distributed MUC]
* [http://www.xmpp.org/extensions/inbox/distributedmuc.html Distributed MUC]
* Message moderation
* Message moderation

Revision as of 19:12, 24 July 2007

Here are some possible DevCon agenda items...

Room: devcon@conference.jabber.org (would be an xmpp: link if this wiki supported it)

XMPP-CORE

XEP-0198: Stanza Acknowledgements

Mixed child elements in message/presence

  • 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

  • Authentication (TLS + SASL)
  • 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.

MUC STUFF

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
  • IP Hashes to reduce groupchat spam
  • Server reputations
  • 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?
  • CAPTCAs for user registration? (redirect to website, the web folks have to deal with this more than we do so they probably do it better!)

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:

Works in progress:

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