'
and so on).
Hopefully this helps! :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
es to focus the energy of forcing adoption. (Like a
standardized file transfer that works between all the clients, instead
of Google Talk off in their own little world, and many servers not
supporting s5b proxies, and a Jingle file transfer spec that isn't
widely adopted yet.) :
(and with
less code!) during the transitional period between EXPERIMENTAL and
DRAFT status specifications.
That said, I know urn:xmpp:tmp:foo is a more strictly 'proper'
hierarchy, so I don't particularly care about the order that much.
So +1 in general, with one offhanded comm
on is less than ideal. Joe, is there
a particular reason that you dislike 3?
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
Are we there yet?!? ;-)
If you ask that again, I will turn this standards committee around and
head home! Just watch! ;)
("He's reaching into MY part of the protocol." "Am not!" "Are to!"
"Stop presence-probing me!" "Make me!")
onally 'os') into caps.
Since we now have a XEP-0115 draft with n/v/os, let's go with that
unless anyone has a real major objection?
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
On Jan 17, 2008 6:42 AM, Rachel Blackman <[EMAIL PROTECTED]>
wrote:
Seriously, we're talking about breaking a really good protocol for
information that is only mildly useful...
Sure, but then recognize some people will iq:version flood because
they'll feel the need to query a
s XEP on when you query
and cache on a per-JID basis.)
I do agree that this bit can be pulled out of the caps discussion at
this point, though; the only bearing it had on caps was that
previously the node#ver values of the original caps meant that you
could map that to
oogle Talk users, and so on), in which
case, the 'I need client information' usage case is 'the person
came online.'
In this case you can surely just use the node which is provided in
caps anyway?
This is true! So that particular usage case is still addressed by new
c
one set (i.e., showing the Psi logo for Psi
users, an iChat chat-bubble for iChat users, a Google chat-bubble for
Google Talk users, and so on), in which case, the 'I need client
information' usage case is 'the person came online.'
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
he only gain from keeping this tied into
XEP-0115 is the saving of a couple of bytes.
(However, given how paranoid we as a community are about sticking too
much stuff into presence, that small bandwith savings may be reason
enough to merit stuffing it into caps.)
There's my take
name (the version
can even be part of the display name) into the presence; if it's
there, clients that care about it can display it, and if it's not, we
can safely assume the client doesn't want that sort of information
displayed.
--
Rachel Blackman <[EMAIL PROTECTED
tures will
once again effectively have a 'flood' of discovery requests of some
form, in order to have a friendly name to display.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
r SHA-256, consider (in the future!) a
change to the MTI algorithm by issuing an updated version of the
spec (after proper list discussion etc.).
Fine. With the additional caveat that anyone who uses a algorithm
that isn't MTI isn't likely to be able to interoperate.
Also +1
be sent to the
bare-JID, and the server would deliver as appropriate (to all
resources, or to the highest-priority, or whatever). Like e-mail,
where you can read it from whatever client. Chat could then continue
to use the current logic, which honestly makes more sense to me.
--
Rachel Bl
we broke with backwards compatibility by removing the ability to
query on the hash, we should have just kept node/ver with their old
meanings, and added a separate hash attribute.
Anyway, what's done is done; I point this out only to show that we
shouldn't let this happen agai
just adding 'hash'
in separately would've solved the backwards compatibility issue
nicely. However, that ship has probably sailed, so even just
including 'v' will solve the 'users will ask for this' concern I had
about displaying version strings. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
ing functionality
will always generate end-user bug report/feature request tickets. And
sometimes features are driven by 'what users want' rather than by any
solid engineering goal. (Is there a real engineering benefit to
avatars? No, but users demonstrably wanted them.) Just my
to the element from within the same stanza via a sid of
some kind).
In the XHTML-IM body:
...and then within the same message stanza...
La. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
On Nov 9, 2007, at 10:27 AM, Rachel Blackman wrote:
On Nov 9, 2007, at 8:47 AM, Tobias Markmann wrote:
There are already several binary-to-text encodings which perform
a bit
better than Base64, two of them are:
1. http://en.wikipedia.org/wiki/ASCII85 invented by Adobe
2. http://base91
ument. :)
Both from a design standpoint, and a practical standpoint (re-using
existing XML parsers for XMPP is easy given that XMPP obeys a subset
of the XML rules). So one would think that < and & are still equally
important not to have appearing raw in an XMPP stream.
--
Rachel Bl
not particularly relevant to the point. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
width-efficient manner (i.e., avoiding our old-school
iq:version flood) is a good idea.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
nk, since you are not on a cellular bandwidth
plan).
I'm just not convinced this is a problem which doesn't already have
multiple available solutions, much less one severe enough to require
throwing out the underlying stream definition and starting over. :)
--
Rachel Blackman
to send you this type of data, how do I get it
to you?' There's very few cases I can think of where we would want to
be sending binary blobs in a server-cached manner anyway.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
cannot envision a situation where
a client /breaks/ by expecting this behavior on an older server,
other than simply not necessarily displaying the proper presence for
yourself if you are in your own roster. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger
our lives.
+1!
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
ients, but
will continue to interoperate with legacy clients fine, and -- for
newer ones -- will have not only the nice hash for verification, but
the version for display purposes. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
I don't think it's a modification, just a clarification.
As Rachel Blackman mentioned, this is a change of behavior between
the
rfc's, and any client depending on this behavior will not be able to
work properly with existing servers - unless it adds the special case
(wh
d the code in /every/ case.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
to your roster for any users
who DO want their own JID there. So that every time you change your
own status, you have to go look up if your own JID is on your roster
and generate an event just like a presence change for it. Hardly a
disaster, but makes the status stuff messier than necessa
se in
the whiteboard session) should see those things drawing out
simultaneously, or nearly so.
This design seems very useful in a general case, but strikes me as
probably generating more traffic than an optimized whiteboard drawing
protocol.
--
Rachel Blackman <[EMAIL PROTECTED]&g
as
suggesting something similar, turning your existing XMPP stream
temporarily into a data stream, then returning to normal usage. So,
let us not get derailed... back to file transfers! :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
lients speaking to a compression-enabled server to still just
send the data as-is, and have the server re-compress to send to the
bandwidth-limited recipient. That seems to me to alleviate bandwidth
concerns while still keeping backwards compatibility.
--
Rachel Blackman <[EMAIL PROTECT
a debate about that. :)
It does not quite seem to fit into either.
I know it would be a real pain, but maybe this deserves its own
namespace? jabber:internal, perhaps? Or jabber:service?
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
ewhat sensible) middle ground, which
is probably why it will stick around. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
CDATA is purely XML level and doesn't carry any semantic meaning.
And yes, the normal compliant XML parser doesn't even bother to tell
you how the data was encoded in the byte stream.
You are seriously confusing layers here.
Fair enough that I shouldn't have used spaces as the example; you're
On Jul 30, 2007, at 6:28 PM, Justin Karneges wrote:
On Monday 30 July 2007 5:37 pm, Rachel Blackman wrote:
If I send ' [EMAIL PROTECTED]' to the server in a
roster add/remove request, it will almost certainly eat that
whitespace at the beginning.
It most certainly must not do
On Jul 30, 2007, at 5:28 PM, Robin Redeker wrote:
On Mon, Jul 30, 2007 at 05:12:16PM -0700, Rachel Blackman wrote:
Can I use <[CDATA[ in, say, roster additions or removals? If I'm
using it there, how do I need to process the text on the server-side
for the JIDs? If I send ' [EM
On Jul 30, 2007, at 4:43 PM, Tobias S. Josefowitz wrote:
On 7/31/07, Rachel Blackman <[EMAIL PROTECTED]> wrote:
Not that I disagree that XMPP should be defined as a rational subset
of XML, rather than including the whole spec, but... this seems to be
needlessly splitting hairs,
lete XML stream is indeed still a complete
and valid document.
(I assume that for the sake of sanity -- and given that at that point
the /entire stream/ is encrypted -- we can assume that a stream would
be decrypted before being validated.)
--
Rachel Blackman <[EMAIL P
whole lot less straight-
forward.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
probable targets, is like painting a bulls-eye.
By restricting messages to those already on the list, you make it
Just Work, rather than having to rely on client implementations of
blocking.
That would be my guess, anyway. (Sean? Anyone?)
--
Rachel Blackman <[EMAIL PROTECTED
Otherwise, I think we may want to come up with a separate 'visually
identifying resource' profile which is basically a case-insensitive
resourceprep, and use that for MU-C roomnicks, cooperative-browsing/
virtual chatroom roomnicks, and so on.
--
Rachel Blackman <[EMAIL PROTECT
a buzzing noise, and even if not the window jittering around
rapidly looks a bit like a buzzer going off.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
mplemented on any service or
client as your message window jittering around on the recipient's
desktop like a toddler who's just drunk a venté espresso, people tend
to send a message, then hit poke.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
eviated name in our /mail clients/ without it wrapping?
How many of us could display it without truncation or wrapping in our
XMPP client? Could you do the same with something /6.27 times longer/?
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
esence, then you would
only need probe any particular version of any particular client once
and you have the results for everyone else using that client. When
they come online you get that small key, and if it's something you
already recognize, you already have your answer. Other
the client version in
tooltips out of the early builds of Astra, the testers howled bloody
murder until I put it back. So, for whatever reason, I can attest
that my users actually do want it. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
Bar installed. With ext, client Foo has the same
capabilities hash in both cases, but one has an additional ext hash
for plugin Bar's capabilities.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
On Jul 3, 2007, at 7:01 AM, Joe Hildebrand wrote:
On Jul 2, 2007, at 5:12 PM, Rachel Blackman wrote:
Because the caching logic is not identical; hash-forms are global,
rather than client-specific. If Psi and Exodus have precisely the
same capabilities, they will generate the same hash
s, old clients can use it just fine with old-style logic. Only
the new client needs to know that h$ means 'take everything after
that $, and treat it as a hash;' old clients can still query seamlessly.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
d be both validated against the result, and -- if it matches
-- cached globally instead of per-client. But for backwards
compatibility, a disco on node#h$ would still give you the
proper results, and COULD be cached on a per-client basis.
--
Rachel Blackman <[EMAIL PROTECTED]>
If we add these bits to -115, will everyone agree to never bring up
changing caps again, and to all agree on that the next time a n00b
comes around?
while (1) {
printf("+1!!\n"); // express agreement vehemently
sleep(1); // do not consume all CPU
}
:)
to wave
around one-paragraph definitions of ideas, instead of turning them
into useful XEPs.
Anyway, I'm going to sleep. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
tive XEP was presented, and got
accepted. It's not a conspiracy, it's not shutting out alternatives,
it's just that no one seems interested in /writing up/ any
alternative they propose as an actual formal XEP.
Got an idea? Write a XEP, and a reference implementation.
retty sure it /
is/ one of the few that actually had a reference implementation
provided way back when. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
to mention this in
darn near every post lately, but we STILL have two incompatible file
transfer specifications live on the network right now unless Google
Talk has decided to implement stream initiation. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
On Jun 23, 2007, at 7:42 PM, Joe Hildebrand wrote:
However, 1024 octets please, rather than characters, like JIDs.
+1 on that over here. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
27;s a little longer, but on the other hand it has all
the information we need. If you support that namespace, you know
that namespace, thus you know the application type. If you don't
support that namespace, then knowing the other side supports it is
fundamentally fairly useless
nctional
and widely deployed XEP is not the best use of our time when we still
have situations such as two incompatible file transfer protocols
floating around. That may be just me, though. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
61 matches
Mail list logo
