Difference between revisions of "DevCon3Agenda"

From XMPP WIKI
Jump to navigation Jump to search
m
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
Here are some possible DevCon agenda items...
Here are some possible DevCon agenda items...


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


==XMPP-CORE==
==XMPP-CORE==


[http://www.xmpp.org/extensions/xep-0198.html XEP-0198: Stanza Acknowledgements]
[http://xmpp.org/extensions/xep-0198.html XEP-0198: Stanza Acknowledgements]
* Justin to update the spec
* Justin to update the spec to reflect IRL discussion


Mixed child elements in message/presence
Mixed child elements in message/presence (Justin to write first draft of best practices spec):
* Each message stanza is of a single profile.
* 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).
* 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).
Line 23: Line 23:


==COMPONENT PROTOCOL==
==COMPONENT PROTOCOL==
Consensus to solve the basics
Consensus to solve the basics
* TLS
* TLS
Line 29: Line 28:
* Component Binding
* Component Binding
* Use jabber:client
* Use jabber:client
* Specify simple username format more carefully


No consensus to solve more advanced features yet
No consensus to solve more advanced features yet
Line 80: Line 80:
==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.xmpp.org/extensions/inbox/distributedmuc.html Distributed MUC]
* [http://xmpp.org/extensions/inbox/distributedmuc.html Distributed MUC]
* Message moderation
* Message moderation


==SECURITY==
==SECURITY==
* Requirements, requirements, requirements ([http://www.xmpp.org/extensions/xep-0210.html XEP-0210])
* Requirements, requirements, requirements ([http://xmpp.org/extensions/xep-0210.html XEP-0210])
* Stanza signing (broadcast and directed)
* 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
* Auth via PGP key? (IIRC there's a TLS method for this - see http://tools.ietf.org/html/draft-ietf-tls-openpgp-keys
Line 95: Line 95:


User registration
User registration
* CAPTCAs for 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!
* 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
* Limit number of accounts created in a time period
Line 127: Line 127:


Specs:
Specs:
* [http://www.xmpp.org/extensions/xep-0060 XEP-0060: Publish-Subscribe] (1.9)
* [http://xmpp.org/extensions/xep-0060 XEP-0060: Publish-Subscribe] (1.9)
* [http://www.xmpp.org/extensions/xep-0163.html XEP-0163: Personal Eventing] (1.0)
* [http://xmpp.org/extensions/xep-0163.html XEP-0163: Personal Eventing] (1.0)


Works in progress:
Works in progress:
* [http://www.xmpp.org/extensions/tmp/xep-0060-1.10.html XEP-0060 1.10 working draft]
* [http://xmpp.org/extensions/tmp/xep-0060-1.10.html XEP-0060 1.10 working draft]
* [http://www.xmpp.org/extensions/tmp/xep-0163-1.1.html XEP-0163 1.1 working draft]
* [http://xmpp.org/extensions/tmp/xep-0163-1.1.html XEP-0163 1.1 working draft]


IRL discussions:
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....
* 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 [http://www.xmpp.org/extensions/inbox/pdp.html PDP]
* Private node: whitelist access model, only account owner on whitelist, persist data -- see [http://xmpp.org/extensions/inbox/pdp.html PDP]
* Public node: open access model, anyone may subscribe or get items
* Public node: open access model, anyone may subscribe or get items
* Eventing node: presence access model, filtered notifications
* Eventing node: presence access model, filtered notifications
* Data node: open access model (e.g., public keys / user profile), persist items -- see [http://www.xmpp.org/extensions/inbox/pop.html POP]
* Data node: open access model (e.g., public keys / user profile), persist items -- see [http://xmpp.org/extensions/inbox/pop.html POP]


==SHARED EDITING / WHITEBOARDING==
==SHARED EDITING / WHITEBOARDING==

Latest revision as of 22:52, 27 January 2010

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

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:

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