On Thu Jan 12 08:52:43 2012, Sergey Dobrov wrote:
On 01/12/2012 03:39 PM, Dave Cridland wrote:
On Thu Jan 12 08:09:23 2012, Sergey Dobrov wrote:
2) Filter by xpath and maybe regex.
I am highly averse to anything that requires xpath or regex on
the server.
Both are big chunks of code
buckets, so you can get hold of them individually.
(I'm still thinking about your use case, which I think is actually
also mine, and Tuomas's)
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http
.
Google supports no PEP - yet - but Google users can (and do!) get
properly filtered PEP events from other servers.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope
On Wed Jan 11 15:49:58 2012, Sergey Dobrov wrote:
On 01/11/2012 10:37 PM, Dave Cridland wrote:
On Wed Jan 11 15:33:29 2012, Sergey Dobrov wrote:
I will say it again: the solution may be implemented with
transition
period which will support both methods. The second thing I
already said
that problems don't exist, or that your
problems aren't valid. They are - but I think we can solve them in a
different, and better, way.
(BTW, are you coming to the Summit? We could have a chat about this.)
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
and other
Layer-7 filtering devices. Such things do exist, and are deployed.
As a client developer, of sorts, on occasion, I'd hate to have logic
that tried to guess whether this was a message for me, or a message
I'd sent to something else. I'd really hate it, actually.
Dave.
--
Dave
On Wed Jan 4 11:12:56 2012, Kevin Smith wrote:
messagecarbonforwardmessage//forward/carbon/message
Isn't the forward/ providing no information at all, here? (Not that
it ever was).
Surely it's entirely and completely implied by the carbon/.
Dave.
--
Dave Cridland - mailto:d
On Wed Jan 4 11:24:50 2012, Kevin Smith wrote:
On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland d...@cridland.net
wrote:
On Wed Jan 4 11:12:56 2012, Kevin Smith wrote:
messagecarbonforwardmessage//forward/carbon/message
Isn't the forward/ providing no information at all, here
On Wed Jan 4 14:22:30 2012, Kevin Smith wrote:
I think it'd be good to pick something and use it consistently,
whatever that thing is.
I'd like to paint it green.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd
, the XSF has a dev room at FOSDEM 2012, and has several
slots available for interesting XMPP-related talks. In general, these
talks are best used to target audiences wider than the core XMPP
community. Talks are welcome from all.
Thanks,
Dave. (As XSF Chair)
--
Dave Cridland - mailto:d
worth noting
that the form field standardizations certainly should be normative
(but should be pointing to more discussion where needed).
What else were you missing?
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd
to suit your particular use-case, I'll leave you
to figure out the rest.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
is simply not
sufficient for your needs; you need to use something more, whether
that's more XEP-0060 features, or some other, new, protocol. But
trying to change PEP because it doesn't fit your use-case is just not
going to work.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d
On Fri Dec 16 09:41:11 2011, Sergey Dobrov wrote:
On 12/16/2011 01:02 AM, Dave Cridland wrote:
On Thu Dec 15 12:54:28 2011, Sergey Dobrov wrote:
I meant that if I have a contact in my roster with from
subscription
then I will receive it's events but I don't want to receive them
because
I
thing to do. Some of
these run quite big deployments.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
On Wed Dec 14 12:51:22 2011, Sergey Dobrov wrote:
On 12/14/2011 07:19 PM, Dave Cridland wrote:
On Wed Dec 14 11:53:50 2011, Sergey Dobrov wrote:
You can query the PEP service and it'll tell you the subscribed
nodes,
so you only need to store the services - in your described
scenario
On Wed Dec 14 16:54:55 2011, Sergey Dobrov wrote:
On 12/14/2011 10:39 PM, Dave Cridland wrote:
On Wed Dec 14 12:51:22 2011, Sergey Dobrov wrote:
On 12/14/2011 07:19 PM, Dave Cridland wrote:
On Wed Dec 14 11:53:50 2011, Sergey Dobrov wrote:
You can query the PEP service and it'll tell you
, it also breaks if PEP nodes have a non-uniform ACL, of
course.
So while the advantages you state are pretty clear, I don't see a way
around the problems.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks
they not match the
text or the intent.
So in both cases, we'd expect the schemas to be right, and welcome
fixes; technically, though, there's a distinction in normativeness
(normativity?) between RFC and XEP.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
On Fri Dec 9 16:44:23 2011, Peter Saint-Andre wrote:
On 12/9/11 9:24 AM, Dave Cridland wrote:
On Thu Dec 8 23:13:38 2011, Matthew A. Miller wrote:
I'd like to point out that all of our XML Schemas are
non-normative.
They're provided for informational use, and ought not be
considered
, which'd make them more obviously
informative.
The XSF Board chair and the XMPP Council chair have been trying to
figure out how we go about such a decision, and decided the best
thing to do was seek consensus on the lists as a first step.
Dave.
--
Dave Cridland - mailto:d...@cridland.net
in PEP;
design for that case. The most obvious example of a service which
doesn't yet do PEP is Google, but I'm confident that they would
implement PEP in a flash if there was a killer app - or just a clear
demand. Meanwhile, you have XEP-0291 as a fallback.
Dave.
--
Dave Cridland
On Tue Nov 22 13:33:36 2011, Kurt Zeilenga wrote:
On Nov 21, 2011, at 2:49 PM, Dave Cridland wrote:
One label per publish suits me.
Though that can be made to work with digital signatures, it would
be slightly odd.
You think? I think it'd be very difficult to manage multi-level
publish
here.
I had a label change concern?
Well, I do now, but I don't remember having that as a concern before.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer
. Not a major change, but a change nonetheless.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
the stream, which resulted
in the server resending them to offline storage.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
frustrates users more than having to type Did you get
that?. 198 effectively prevents this on a link basis, meaning that
184 becomes truly reliable for end-to-end, even if you lose your
connection during the e2e round-trip.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d
...
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
, that needs work outside
of the XSF that we can build on.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
it on clients.
So XEP-0077 for password changing is well supported, and indeed state
of the art. I agree it could be done better, more securely, and more
flexibly, but as I say elsewhere this needs a foundation which the
XSF is not qualified to provide.
Dave.
--
Dave Cridland - mailto:d
.
I'm mildly terrified by the notion that *any* previous message can be
corrected.
I'll try to articulate my phobia tomorrow; in general it just seems
Wrong to allow arbitrary message editing after sending, and I've a
nasty feeling there's some security impact there.
Dave.
--
Dave Cridland
add an entry to the roster prior to asking
for a subscription in order to set the name and group, but it's not
needed.
-- Bala
-Original Message-
From: standards-boun...@xmpp.org
[mailto:standards-boun...@xmpp.org] On Behalf Of Dave Cridland
Sent: Thursday, October 27, 2011 4:39
On Thu Oct 20 09:19:06 2011, Sergey Dobrov wrote:
On 10/20/2011 03:56 AM, Dave Cridland wrote:
a) Probes are sent from the bare jid.
b) Probes don't have an unavailable equivalent, needed to later
remove
the subscription.
How this solved for regular presences?
You get a later type
to by the hash.
That seems fine to me.
/K
When client should send such stanza? After each connect and to each
user
with the to subscription state?
Indeed, and then you may as well send them presence anyway.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
don't have an unavailable equivalent, needed to later
remove the subscription.
c) Probes don't have the caps inside.
For PEP to work, the PEP service needs to know all three of those, so
basically it needs your presence - or a functional equivalent of it.
Dave.
--
Dave Cridland - mailto:d
always send no label.
However, client may not always send *other* labels. (How they'd
discover them is not within the scope of XEP-0258, but they could be
policy aware and have access to the directory containing clearance
information, perhaps.)
Dave.
--
Dave Cridland - mailto:d...@cridland.net
that this is stripped from this XEP and
moved to another.
If this were done it would leave the rest of the document suitable
for Draft; otherwise I think there's more work to be done in
stabilizing the XEP-0060/XEP-0258 interaction.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d
there be a distinction between This message has no XEP-0258
label, possibly because I don't know how to put one on here, and
This message explicitly lacks a label?
Ie, the distinction between no securitylabel/ and one with an empty
label/ element?
Dave.
--
Dave Cridland - mailto:d
On Wed Oct 5 08:53:54 2011, Kevin Smith wrote:
On Tue, Oct 4, 2011 at 11:21 PM, Dave Cridland d...@cridland.net
wrote:
On Tue Oct 4 23:01:07 2011, XMPP Extensions Editor wrote:
XEP-0288 (Bidirectional Server-to-Server Connections) has been
Deferred
because of inactivity.
Abstract
thing, and run account
registration as a well-known ad-hoc command node available to
anonymous users.
Then it becomes something that some existing clients can do
instantly, and it's relatively easy to add in a streamlined way to
others.
Dave.
--
Dave Cridland - mailto:d...@cridland.net
of applying them.
Can someone can sort git access for me, and I'll sort it.
Has anyone else implemented it aside from Fippo and Isode?
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http
- in a You don't want to use BOSH on
mobile because you'll force the handset into DCH with every poll
kind of way.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope
clients request the vCard directly from the real jid if they see
one, which effectively means that forwarding vCard requests to
non-anonymous particpants rarely happens. In general, this is worth
recommending, I think (and poses no new protocol, which is nicer).
Dave.
--
Dave Cridland - mailto:d
.
Is it (or should it be) case sensitive?
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
On Tue Sep 27 16:51:39 2011, Peter Saint-Andre wrote:
XML element names are case-sensitive.
Ah, yes, indeed. For some reason I'd assumed it was an attribute name
and obviously failed to properly read the original mail, sorry.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d
On Tue Sep 27 16:53:58 2011, Dave Cridland wrote:
On Tue Sep 27 16:51:39 2011, Peter Saint-Andre wrote:
XML element names are case-sensitive.
Ah, yes, indeed. For some reason I'd assumed it was an attribute
name and obviously failed to properly read the original mail,
sorry.
Attribute
as well as near-instant deployment.
If this seems like a good starting point, then I'm perfectly happy to
write this up, and equally happy if someone else wants to.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user
On Sat Sep 17 18:44:28 2011, Alexander Holler wrote:
Am 16.09.2011 21:24, schrieb Dave Cridland:
On Fri Sep 16 17:58:17 2011, Kim Alvefur wrote:
I think it shouldn't hurt if r/ meant I'd really like you to
send an
a/ now, please, and the other party SHOULD reply with a/,
but not
MUST
to a different peer.
Send as many a/ as you like, but at least one per r/ received.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
of unknown caps ask their
localserver to expand them - this would radically reduce traffic on
the network as a whole, and their local server will probably need to
know the features anyway for PEP, etc.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
implementations often highlight bugs in specification and existing
implementations, too.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
cannot think of a case where this would have problems, I'm not
convinced there isn't either.
I do want this to work; I'm not convinced it's enough, or right, and
I do think it'll land us with a number of warts in the protocol that
we're still in a position to avoid.
Dave.
--
Dave
verifying something
like the above message is much easier than parsing _and_ verifying
a form.
Not especially, actually. There is an issue with hidden fields,
possibly, but those are pretty trivial to deal with.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
building. We're
getting closer, though.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
On Mon Sep 5 18:51:16 2011, Waqas Hussain wrote:
On Mon, Sep 5, 2011 at 5:39 PM, Dave Cridland d...@cridland.net
wrote:
On Wed Aug 31 06:48:26 2011, Waqas Hussain wrote:
Most protocol attacks are based on unexpected input. Attackers
wouldn't really care whether the values they send
On Tue Aug 16 16:12:34 2011, Peter Saint-Andre wrote:
On 8/16/11 3:35 AM, Dave Cridland wrote:
On Mon Aug 15 22:57:59 2011, Peter Saint-Andre wrote:
2) We also need to consider that many clients only handle one
status
code.
Which one do they handle?
I mean they will only process one
element)
So that's already covered.
Oh, right, yes. I entirely missed both this and the structure above
it which makes this clear. Damn it, it's not in the examples!
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user
, rather than replace, conditions.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
unreasonable.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
/protocol/activity'
working
in_a_meeting
webex xmlns='http://www.webex.com/xml/webex'/
/in_a_meeting
/working
/activity
Moreover, PEP allows you do set the activity and drop offline.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
placed in presence/, rather than PEP.
Will you forgive me for answering your rhetorical question?
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP
On Sat Aug 6 11:11:54 2011, Alexander Holler wrote:
Am 20.07.2011 12:26, schrieb Dave Cridland:
On Wed Jul 20 04:34:29 2011, Mark Rejhon wrote:
So, does anyone recommend a standardized method of a sub-70-byte
keep
alive
message ?
NOPE!
XEP-0198 Null acks are good. Just send an a/ even
instead of muc for groupchat feature.
Chatrooms can store history, and clients can tell the chatroom on
reconnect how much history they want.
If a client doesn't mention how much, a chatroom is free to pick a
sensible amount.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d
of points you raise are water
under the bridge - no pun intended - but if you are keen on getting
some kind of official statement out of the XSF, I'd suggest this is
the wrong list.
Maybe try sending to the XSF Board?
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
assume that must mean they either didn't read,
or didn't understand your view - not that, perhaps, they simply
disagreed with your assessment.
Still, it's nice to see you've not changed your habit of attempting
to slander anyone who disagrees with you.
Dave.
--
Dave Cridland - mailto:d
of this I can think of is when you have directed
presence from only one resource, in which case there's arguments for
no unlocking, since the messages may end up at a resource the account
owner doesn't want to reveal, making it awkward to respond.
Dave.
--
Dave Cridland - mailto:d...@cridland.net
all a waste of time
compared to other, more pressing, issues.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
explicitly only presenting the vendor's data has
advantages here, too.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
to disconnect the client due to silence, it
should
perform a ping first and only disconnect if it doesn't receive a
reply
- 199 will always work, or 198 if that's been negotiated. I believe
this agrees with what Dave says.
Right.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d
.
But we don't have to agree, here - just give the first case above as
a for example, and note that it's always safe to unlock.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net
that
if you've suddenly become grumpy, we may need to start bothering you
on your mobile phone instead.
I'm not sure what the word for excess hyperbole is, but I think I may
have been guilty of it there. :-)
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
the fifth definition of http://en.wiktionary.org/wiki/idle; I
think you mean the third)
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
the conversation
there/delicious_hyperbole.
pedantic_observation
very rare suggests there is, nevertheless, some possibility of you
doing so.
/pedantic_observation
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd
is the safest option.
We have a clear example of when not to unlock that we all agree on.
I think we can move on.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope
. If anyone wants to add something there about the pros
and cons of using BOSH on mobile, that's welcome too.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer
traffic from silent clients, and SHOULD only terminate the connection
of unresponsive clients, rather then merely silent ones.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net
experince the specification keeps talking about
actually is - that is, what the goal of the specification is.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope
On Tue Jul 19 17:03:00 2011, Peter Saint-Andre wrote:
On Tue, Jul 19, 2011 at 09:00:36AM +0100, Dave Cridland wrote:
My plan would be that implementers would host an XML description
of
their compliance levels, which the XSF's software listings would
consume and render into the software
On Wed Jul 20 22:43:22 2011, Matthew A. Miller wrote:
On Jul 20, 2011, at 15:34, Dave Cridland wrote:
I'm concerned by the final rule in §2.3, which suggests that
*any* presence update from the contact SHOULD break the lock. I
think this rule is fine; however I think a short discussion
.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
that on mobile networks whilst on trains, and so on, and it's very
effective.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
intentionally, in some languages.
So I'd say that we should refer to characters in a string, and deal
with Unicode code-points in the abstract. I'd expect that
implementations would convert this internally into whatever made
sense for them.
Dave.
--
Dave Cridland - mailto:d...@cridland.net
that's possible.
I don't have a solution, either, except to note that this applies to
UTF-8 octets etc as well, unless you normalize all strings first -
but then it's really not clear to me how to translate editing actions
in a GUI into that form.
Dave.
--
Dave Cridland - mailto:d
think we specify anything about the form of those newlines,
currently - I suspect that most software uses CRLF, but I can't
honestly say I've looked.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks
this having this codec listed
on this document is a bad idea?
Some valid reasons would help.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
to have already
duplicated that work, with their very own, Invented Here™, list)
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
forms.
(We do, of course, with simple attributes, but the risk there is that
we would have different comparisons in different cases, and therefore
ARGH.)
Dave
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd
by processing an XSLT over the XML form of the IANA registry,
but I can see the XML purists coming after me with troches and
pitchforks).
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http
as a new namespace and
element name for every hash, but in effect, this has already defined
8 hash functions, so we can move on and concern ourselves only with
which one we want to recommend for now.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
On Fri Jun 10 18:48:01 2011, Glenn Maynard wrote:
On Fri, Jun 10, 2011 at 8:35 AM, Dave Cridland d...@cridland.net
wrote:
What M-Link does is ping the old session on a conflict, with a
short
timeout (of, if I recall, 10 seconds).
So on a conflict, you get three cases:
1) The act
On Mon Jun 13 10:08:58 2011, Glenn Maynard wrote:
On Mon, Jun 13, 2011 at 4:04 AM, Dave Cridland d...@cridland.net
wrote:
On Fri Jun 10 18:48:01 2011, Glenn Maynard wrote:
This won't work properly if the existing client is a paused BOSH
session,
which may not unpause the session
originally tried - simply
failed to be understood by clients.
This left assignment of a new resource as the safest option without
introducing the probes.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks
with them. We do not do schema validation in
XMPP, for good reason, so this will not have any effect on
interoperability.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net
, Peter, Oh Mighty XEP Editor, I apologise for its rough form,
but hereby submit it as an Informational XEP to provide background
reading for, and expansion on, XEP-0053§4. I beseech thee, as well
as those nice chaps on the Council, to help me clear it up a bit, too.
Dave.
--
Dave Cridland
it).
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
not particularly bothered about whether future dialback
options should be signalled as individual stream features or
sub-elements of the existing dialback feature, I see no value in
changing the errors sub-element now that there exist deployed
implementations using it for signalling.
Dave.
--
Dave
.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
On Tue May 17 18:04:43 2011, Peter Saint-Andre wrote:
On 5/17/11 10:30 AM, Dave Cridland wrote:
On Tue May 17 02:14:06 2011, XMPP Extensions Editor wrote:
Changelog: Modified stream features to incorporate versioning,
thus
removing the need for an errors/ child element; clarified a few
1101 - 1200 of 1594 matches
Mail list logo
