FLUSH - 1.0 issues
- 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...
- 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
- valid characters
- there are three zones within the ID, user, server, and resource.
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
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
- 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 email@example.com 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.
- 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 :)
- 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
- 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
- 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.
- 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
- 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
- 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)
- 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
- 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
- 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?
show is either: chat/away/na/dnd
- 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.
- 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?
- Nobody uses this, is it useful? Is everyone confused about it? (probably :)
rename to x:envelope
- iq:fneg, useful?
- Feature Negotiation, <insert discussion here>
- x:oob, HEAD
- <insert discussion here>
implement, discuss, use HTTP 100%
- <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
- version / time / ping, etc...
iq:version and iq:time, time the response for "ping"
- 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
- 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
- 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
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