Difference between revisions of "DevCon3Agenda"
Jump to navigation
Jump to search
| Line 4: | Line 4: | ||
==XMPP-CORE== | ==XMPP-CORE== | ||
[http://www.xmpp.org/extensions/xep-0198.html XEP-0198: Stanza Acknowledgements] | |||
* Stanza size limitations | |||
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== | ==COMPONENT PROTOCOL== | ||
Revision as of 19:10, 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
MUC STUFF
- MUCOL -- Bruno discussed on Day One
- MUCOM
- 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
- 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