FLUSH - 1.0 issues

Streams

• redirects
• I made a proposal to have a stream redirect in the <stream:stream element, is this worth pursuing?  It might add a bit too much complexity for simple clients, and I'm not entirely sure of it's value...
• no redirects
  
• versioning?
• Do we need to add a version tag of sorts at the stream level?  the version would be for the namespace within the stream.  I'm of the feeling, that the version IS the namespace, ie. when we make significant and conflicting changes to the protocol, we become xmlns="jabber:client2".
• yes, use the namespace for major changes
  

ID's

• valid characters
• there are three zones within the ID, user, server, and resource.
• user: instead of saying which characters are allowed, we'll just  exclude certian ones, which allows international people to use native characters  in usernames.
• [@] obviously... replacement character for an @ is a %
• [:] of course
• [\r\n\t ] whitespace is disallowed
• [ctrl-] control characters are disallowed
• ['"<>&] xml special characters are disallowed
• others?
• username is case insensitive when compared, but case is preserved throught the system
• username is 64 characters max
  
• server: server name is restricted under the same rules as any DNS hostname, and is NOT case sensitive
• resource: I want to enforce the fact that the resource is 100% UNLIMITED.  Any data stream can be in a resource, any valid XML CDATA.  There are no restrictions here.
  
• naming
• It is common for software to present a "name" to the end user or  display the ID in a nice format.  Here are some guidelines to get started  in standardizing this: with user@host.net you would use "user", with host.net  you would use "host" or the first part of the hostname, with host.net/resource  you use "host_resource", with host.net/resource?stuff you use the same host_resource,  hiding the stuff.  The main thing to take away from this is that when someone  is writing software that will be sending things w/o a user, it can be fairly  safe in knowing how this from address will be presented to end users and  name the resource appropriately.  Also, that the extra data after a ? in  a resource is hidden.  Obviously, if there is an item in the roster with a name="" assigned, use that, but this process can also be used to fill in default names when creating a roster item.
  
• jabber:
• It really bothers me that we are using a jabber: appendage to all the IDs, and we don't have a good reason for it.  If we aren't going to support other type:'s at the protocol level, why even use it?  If we ARE going to use it, we need to say so so that implementors can be aware of it.  We need to get our story straight.  It wouldn't bother me to just drop it completely :)
• drop it!
  
• from's being sent from one session w/ other resources
• The idea here is that, when you are connected and authenticated, you can send a message and put a from="" attribute on your packets yourself.  The server will check to make sure that the from you assigned is still YOU, but you can specify any resource under your account.  Right now the server allows this, I can't see any reason NOT to.
  
• Note: you can't do this w/ presence packets, it breaks model badly (jer: enforce this in the server)
• No usefulness found for this
  
• to's?
• On the same line, should the server leave the to="" attribute on the packets when they are to another resource besides the one assigned to that session?  Should the server automatically route unknown resources to the primary session?  Clients would not be expected to act differently, but special applications might be able to take advantage of this feature.  Does it break anything though?
• This will be added, but can be ignored
  

  Messages

• priority
• This is an almost useless field, drop it?  The intention is to allow a user to express importance on a particular message, where it might break through a DND mode or sort it to the top, play a different noise, etc.  If we do use it, we need to define ranges or values for different characteristics.
• drop it
  
• chat /me
• It's already supported by the win32 clients, but we need to standardize on the /me being used to express an action.  Do we want to support this in all messages, not just chat/groupchat?  I can see the value, I've wanted to do a /me in ICQ many times on individual messages.  Basically, a client looks at the first three chracters of a body of a message for a "/me" and turns them into *name or name.
• This is an optional additional feature
• groupchat
• I know there's some issues here but don't have time to look them up... <insert discussion here>
  
• tags in body
• DECISION:  Allow extra XML in the body?  Obviously, this being XML we can't stop anyone, but do we reccomend in the spec that this is supported or unsupported?  For simplicity of clients I'd like to say unsupported and any extra XML is at the packet level in an extension, but I don't want to cut anything important off.  If anyone brings up XHTML or other XML-in-text needs, why can't they just be an alternate :x: in the message element and we require that the body is just the textual representation?
• body element is only for text
  
• mime
• On that same subject, what happened to the MIME proposal from last fall?  I still like it and want to support it, but based on the previous topic, support it as an :x: in the message element?  Is it critical that we allow it to be randomly embedded within the body?  Maybe soas to show placement/location within the body?
• MIME is an :x:, need to find a way to specify if it's an alternate body (XHTML)
  
• subject?
• Is the subject useful?  Should we keep it and demote it a little?  Do all clients need to support it?  I don't really like it, but maybe there's some really-important reason to keep it I can't think of :)
• depreciated, subject is an optional feature, not expected to be on a typical new-message form
  
• thread usage
• I'm doubting that anyone has supported the thread element yet, but I believe this is an important element to support.  It is simply sent back to the sender verbatim, so that the sender can track a conversation and thread things correctly.  It can be used for things like opening two chat windows to a single user and having different conversations, each one uses it's own thread identifier.  I don't know how many times I've had three conversations with another person and get a "sure" back and not know which msg it was in response to.  Fully functional clients should always send a thread id for any new messages their user creates, and responses can show "in response to" on the screen.
• definately needs to be supported
  

Presence

• negative priority
• Right now the server treats negative priority the same as "unavailable" when determining primary sessions or the availability of any user ID.  But a client can differentiate this in a GUI.  Unavailable says that the other resource is not currently available, but a negative priority says that it's available but doesn't want to be sent to.  Is this useful?
• drop negative priority, it's only a positive integer 
• probe: server only?
• probes are server->server only at the moment, and never sent on to a client.  Should this change?  Should clients be able to send/receive probes?  If I changed this, it means that any client implementing presence would be required to be able to respond to a probe, otherwise the server->server model will break down.  Personally, I want to completly hide probes from clients, it's a server ONLY packet.  Any functionality that a client might want from a probe we can/should implement as a CTCP IQ. 
• definately server only
• icon/show
• Ahh, important and tough one :)  We need a good and agreed upon way of expressing all the "common" states, away, dnd, sleeping, meeting, etc.  This is what I want to use the show element for, and creating a common set of states.  Now, what about that icon element?  They kind of overlap.  We could support a system with a common icon library, and a standard size/format for specifying URL's to new icons, but IMHO we have enough to do and that can be a future 1.1 or beyond feature as an :x:.  Just drop the icon element for now?
• drop icon
• show is either: chat/away/na/dnd
  
• meta-data?
• This is an important feature for app->app functionality.  It might be way too much to try for 1.0 though.  The intention is having a way of expressing the capability or type of entity this is, within the presence.  Such as "I'm a pager" or "I'm a checker game".  Again, just drop for now and postpone until after 1.0?
• 1.1 + proposal
  
• location?  as :x:/other dtd?
• I know I want to drop this from the main protocol, but I just wanted to mention it to see if there were any existing XML dtd's for location information that we could just point to as an extension.  Personally, I would love to see this fully supported, bringing up an app and seeing where all my buddies are all over the world, etc :)  Or while traveling, and for mobile users, or if we have a mobile phone client, etc :)
• 1.1 + proposal
  
• per-contact presence issues
• (jer: fix you-know-what here)
• What this means is, you can express alternate presence on a per-id basis.  So you can show yourself as unavailable to one user and available to another, or any combination of the above.  There are a few ways to do this.  When you send presence to the server it is your "default" presence and broadcast out to everyone in your roster.  Then you can send individual presence to any ID specifically, and it "overrides" that default presence at the receivers end.  This works, but isn't perfect since the other user might see you blink on/off if you do this right away, and their server can always probe and get your default again.  An alternate way is to never send your default, and send each user individually presence.  You also have to send yourself presence first to enable you to become a primary session and receive user@host messages.
  
• unavailable, GUI?
• It came up the other day... yes, a client should be tracking and showing ALL the resources it's received presence for, even for unavailable ones.  A user should still be able to address messages to an unavailable resource so that the message can be received when it becomes available again.
• all unavail resoures should be kept/tracked and made available to an end user somehow, in a histor or sub menu.  messages can still be sent to them specifically.
  

Extension Issues

• x:register misc fields, xforms, GUID, return URL
• Lots of things here...
• Do we need to suppor the "misc" fields or generic fields in the register namespace?  What fields are the absolute minimum required?
• Wouldn't it be nice to move to XML Forms?  But that adds a HUGE requirement to clients, and just as HUGE benifits for those building applications ontop of Jabber.  A 1.1 feature?
• We need to add in a <id>23452345</id> to the get, and is returned in the set, so that you can't falsify a registration by sending your own from attrib.
  
• x:offline GUI?  tracking, routing/filtering
• There are some issues with the offline namespace, <insert large discussion here>
  
• x:delay descriptions, GUI
• How would/should a GUI showing the delay look?  How useful are the descriptions?  what if there isn't a description?
  
• x:ident
• Nobody uses this, is it useful? Is everyone confused about it?  (probably :)
• rename to x:envelope
  
• iq:fneg, useful?
• Feature Negotiation, <insert discussion here>
• 1.1 discussion
  
• x:oob, HEAD
• <insert discussion here>
• implement, discuss, use HTTP 100%
  
• iq:userinfo/vcard
• <insert discussion here>     
• find a subset, implement
• iq:agents transport/ID generation, @=>%
• When using the transport/add-user ID thingy, a client needs to translate @ characters into % characters, and check for illegal characters and warn the user.
  
• CTCP
• version / time / ping, etc...
• iq:version and iq:time, time the response for "ping"
     

XML

  
• for :x: and :iq:, force element name?  namespace validity
• There is the issue that, for xml namespace validity, the element the  xmlns="" is defined in must be in the DTD.  If we start supporting alternate  existing DTD's, they won't have "query" or "x" defined in their DTD, so  a valid extension using an alternate namespace would have it's own element  name.  This might mean you get an <iq><vcard xmlns="vcard.foo">...  Thoughts?
• use the namespace root element name as appropriately, x/query are only for our stuff
  

Misc

• anonymous
• Implement anonymous connections in another stream namespace, jabber:anon     
• master server list? (jud)
• Use JUD to create a master server list?  Is this required server feature for 1.0, to report back to a master server, for searchability and tracking, etc...
  
• forwarding entire account
• How is it best to handle forwarding an entire account, and managing that feature?
  
• client caching
• There are certian things that it is good for a client to cache.  The first is the agents query, and offering a "refresh" button.  The server doesn't need to be asked every time as this is mostly static data.  The second is the roster, in case of a server error or problem, as many people apply lots of value to their roster.  The problem with that is that a client can't edit the s10n field... hmmm.... maybe a post-1.0 thing
  
• sizes
• max msg size, 1.1
  

Theoretical non-norm apps

• Dynamic DNS / Mobile Server
• App -> App
• offline opt for just app
• presence filtering to find other apps
• sharing w/ client, branching, plugins