On Wed Jul 11 22:33:31 UTC 2012, Gregg Vanderheiden
wrote:
> Well one thing missed is that the emergency responder (9-1-1 PSAP) is
> always responding.
> So I think you should have it that the first message from EITHER party
> should be able to use to ping.
> What about if you are in the middle
On Wed Jul 11 21:44:21 UTC 2012, Gunnar Helstrom <
gunnar.hellst...@omnitor.se> wrote:
> Dave, Sounds good.
Can you convert your conclusion to modification proposals for chapter 5
and 6.2?
Please hold off until Version 0.4;
I already made changes and like comments in the next review cycle.
On 2012-07-11 4:27 PM, "Dave Cridland" wrote:
>
> OK, so, loosely:
>
> 1) If you know the remote disco (via caps, typically, or by a previous
query), then you can follow that. Sending protocol to a remote endpoint
that you *know* cannot support it is not going to make people happy. This
will cover
Well one thing missed is that the emergency responder (9-1-1 PSAP) is always
responding.
So I think you should have it that the first message from EITHER party should
be able to use to ping.
What about if you are in the middle of a message and it becomes clear that it
should move to rtt?
On 2012-07-11 22:27, Dave Cridland wrote:
OK, so, loosely:
1) If you know the remote disco (via caps, typically, or by a previous
query), then you can follow that. Sending protocol to a remote
endpoint that you *know* cannot support it is not going to make people
happy. This will cover anyo
On Wed, Jul 11, 2012 at 9:39 PM, Matthew Miller
wrote:
> On Jul 11, 2012, at 14:37, Mark Rejhon wrote:
>
>> ETA is Monday but I will try to accelerate the changes to allow an
>> additional interirm version for reviewers like you.
>>
>> It is just mostly grammatical and wording choices, and section
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 11, 2012, at 14:37, Mark Rejhon wrote:
> ETA is Monday but I will try to accelerate the changes to allow an
> additional interirm version for reviewers like you.
>
> It is just mostly grammatical and wording choices, and section refinements
>
ETA is Monday but I will try to accelerate the changes to allow an
additional interirm version for reviewers like you.
It is just mostly grammatical and wording choices, and section refinements
discussed thus far. v0.4 will be relatively minor update in comparison to
the current v0.3.
On 2012-07-
OK, so, loosely:
1) If you know the remote disco (via caps, typically, or by a previous
query), then you can follow that. Sending protocol to a remote endpoint
that you *know* cannot support it is not going to make people happy. This
will cover anyone in your roster, and indeed almost anyone you k
On Tue, Jul 10, 2012 at 9:08 PM, Mark Rejhon wrote:
>> I'm still aiming to do a review of the XEP soon - I'll try to suggest
>> appropriate text for bits that I suspect need it when I do.
>
>
> Please. Thanks! Keep in mind of the big laundry lists of suggestions
> already submitted by others;
I
On 2012-07-11 5:55 AM, "Dave Cridland" wrote:
>
> At the risk of opening a whole new can of worms, if you're modelling an
RTT conversation as a textphone call, don't you want to be ringing, and
accepting the call, via Jingle?
>
> If it's modelled as an enhancement of existing IM text chat, then us
On 2012-07-11 4:58 AM, "Gunnar Hellström"
wrote:
>
> Mark,
> In all this, I get the impression that you design for the fragmented
case, when each XMPP service provider selects its own behavior for its
clients and only expects their clients to have communication with other
clients of the same servi
At the risk of opening a whole new can of worms, if you're modelling an RTT
conversation as a textphone call, don't you want to be ringing, and
accepting the call, via Jingle?
If it's modelled as an enhancement of existing IM text chat, then using
XEP-0085's model, with it's fallback from disco an
Mark,
In all this, I get the impression that you design for the fragmented
case, when each XMPP service provider selects its own behavior for its
clients and only expects their clients to have communication with other
clients of the same service provider.
I am still hoping that the world shal
On 2012-07-10 3:13 PM, "Peter Saint-Andre" wrote:
> > http://xmpp.org/extensions/xep-0085.html#bizrules-gen
> >
> > Oh wow -- This is a massive surprise for me.
> > *precedent* in a *Final* standard -- that allows bypassing disco!
> >
> > This is XEP-0085 Chat States (Final standard) advocatin
On Tue, Jul 10, 2012 at 3:51 PM, Kevin Smith wrote:
> On Tue, Jul 10, 2012 at 7:34 PM, Mark Rejhon wrote:
> > Oh wow -- This is a massive surprise for me.
> > *precedent* in a *Final* standard -- that allows bypassing disco!
>
> Before planning too much based on the precedent that CSN sets, it'
On Tue, Jul 10, 2012 at 7:34 PM, Mark Rejhon wrote:
> Oh wow -- This is a massive surprise for me.
> *precedent* in a *Final* standard -- that allows bypassing disco!
Before planning too much based on the precedent that CSN sets, it's
worth noting that the precedent in question is that there was
On 7/10/12 12:34 PM, Mark Rejhon wrote:
> (Starting over, from good grounds)
> (NOTE: This big email is regarding what is essentially a *single
> controversial sentence* added to XEP-0301 protocol)
Welcome to the wonderful world of standards development. :)
> On Tue, Jul 10, 2012 at 1:17 PM, Pete
(Starting over, from good grounds)
(NOTE: This big email is regarding what is essentially a *single
controversial sentence* added to XEP-0301 protocol)
On Tue, Jul 10, 2012 at 1:17 PM, Peter Saint-Andre
wrote:
> > Metaphorically speaking:
> i.e. in a manner of speaking, we strongly believe se
19 matches
Mail list logo
