On 2012-07-17 01:26, Lance Stout wrote:
Given that entity caps are expected to be transmitted in both the sent and
received presence (or failing that you now know a full JID which can be queried
for disco), what more do we really need other than saying that you can include
multiple values in t
Given that entity caps are expected to be transmitted in both the sent and
received presence (or failing that you now know a full JID which can be queried
for disco), what more do we really need other than saying that you can include
multiple values in the reason attribute?
> Answers should
If we want the `reason` bit to be flexible, why not make it some
combination of a text label and a registry, perhaps similar to stanza
errors.
Maybe reuse the features (XEP 30, Disco) registry, like:
Voice call
--
Regards,
Kim "Zash" Alvefur
signature.asc
Description: OpenPGP digital signat
On Mon, Jul 16, 2012 at 4:56 PM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:
>
> 6. The reason Attibute
>
> To signal the type of communication that is desired, the entity that first
> shares session presence MAY include a 'reason' attribute on the
> element. Multiple values are allowe
On 2012-07-16 19:58, Mark Rejhon wrote:
I want to comment that XEP-0276 only allows mentioning "media" or
"text" as the reason, and not both. XEP-0276 needs to be updated to
permit a single mechanism activating all three features simultaneously
(audio, video, real-time text). This might be com
On 7/16/12 1:29 PM, Matthew Wild wrote:
> On 16 July 2012 18:10, Justin Karneges
> wrote:
>> On Monday, July 16, 2012 09:53:02 AM you wrote:
>>> On 7/16/12 10:49 AM, Justin Karneges wrote:
On Monday, July 16, 2012 08:35:59 AM Peter Saint-Andre wrote:
> I've just reviewed XEP-0297 (Stanza
On 16 July 2012 18:10, Justin Karneges
wrote:
> On Monday, July 16, 2012 09:53:02 AM you wrote:
>> On 7/16/12 10:49 AM, Justin Karneges wrote:
>> > On Monday, July 16, 2012 08:35:59 AM Peter Saint-Andre wrote:
>> >> I've just reviewed XEP-0297 (Stanza Forwarding) and I think it looks
>> >> good. O
On Wed, Jul 11, 2012 at 2:01 PM, Peter Saint-Andre wrote:
>> I suggest changing "explicit user configuration" with "explicit user
>> confirmation" and then adding another sentence that the user confirmation
>> can be per request, per first request per requestor, or by setting some
>> "always de
On Monday, July 16, 2012 09:53:02 AM you wrote:
> On 7/16/12 10:49 AM, Justin Karneges wrote:
> > On Monday, July 16, 2012 08:35:59 AM Peter Saint-Andre wrote:
> >> I've just reviewed XEP-0297 (Stanza Forwarding) and I think it looks
> >> good. One small comment, it would be good to describe briefl
On 7/16/12 10:49 AM, Justin Karneges wrote:
> On Monday, July 16, 2012 08:35:59 AM Peter Saint-Andre wrote:
>> I've just reviewed XEP-0297 (Stanza Forwarding) and I think it looks
>> good. One small comment, it would be good to describe briefly the kinds
>> of extensions that might re-use this form
On Monday, July 16, 2012 08:35:59 AM Peter Saint-Andre wrote:
> I've just reviewed XEP-0297 (Stanza Forwarding) and I think it looks
> good. One small comment, it would be good to describe briefly the kinds
> of extensions that might re-use this format, and specifically to cite
> draft-miller-xmpp-
I've just reviewed XEP-0297 (Stanza Forwarding) and I think it looks
good. One small comment, it would be good to describe briefly the kinds
of extensions that might re-use this format, and specifically to cite
draft-miller-xmpp-e2e.
In Sections 4.1 and 4.2, we use the word "trust", which I find t
FYI
-- Forwarded message --
From: Kevin Smith
Date: Mon, Jul 16, 2012 at 9:24 AM
Subject: Minutes 2012-07-11
To: XMPP Council
Logs: http://logs.xmpp.org/council/120711/
1) Roll call
All present
2) Date of next meeting
2012-07-25 1500 GMT
3) Any other business
** Timing of Las
13 matches
Mail list logo
