On 7/19/12 1:40 PM, Kevin Smith wrote:
> On Thu, Jul 19, 2012 at 8:18 PM, Mark Rejhon wrote:
-- Since you are the primary author -- when do you plan to execute a
LAST
CALL for XEP-0308?
>>> I'm not opposed to requesting one ~=now, if it's useful.
>> It's been less than 12 months si
On 7/19/12 2:19 AM, Lance Stout wrote:
>> I think it's worth including the id on every RTT edit, rather than
>> just the first - it makes the state machine easier for the
>> receiving clients and doesn't hurt the sending client.
>
> +1 on this. Even though the use of the seq value and error detec
to XEP-0301 can be kept to as little as a single paragraph, the problem
> is I'd have to mention a potentially rarely used (for a long while) 'id'
> attribute in an early XEP-0301 chapter, which I don't like to have to
> introduce until XEP-0308 is Draft and more widey used.
>
> That said, I'd like still need to hear about some clarity about
> XEP-0308 proper usage, from the perspective of Lance's message. Peter?
Kevin wrote XEP-0308, so I'll defer to him. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
y need the element at all?
I think not.
> One argument in favor of identifiers for reasons v.s. just some text is
> localization. In that case I'd go with Kim's proposal.
If we need it, then providing a way for it to be localized is a good idea.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 7/17/12 2:39 AM, Kevin Smith wrote:
> On Mon, Jul 16, 2012 at 4:35 PM, 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 mig
lating negotiation
> (which specs generally sort out themselves via Jingle, or just aren't
> negotiated) with discovery, which I think decloaking aids with.
>
> Cutting it out makes this very simple and doesn't seem to harm us.
+1, I think. I don't believe that this would be used in an automated
fashion.
Peter
--
Peter Saint-Andre
https://stpeter.im/
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:
>>
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 extensi
;, which I find to be
void for vagueness and thus impossible to operationalize. IMHO it would
be better to phrase this in terms of how the receiving entity needs to
behave (e.g., drop the message without showing it to a human).
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 7/4/12 3:16 AM, Philipp Hancke wrote:
> On Thu, 31 May 2012, Peter Saint-Andre wrote:
>>> We have http://xmpp.org/extensions/xep-0225.html - although support is
>>> less widespread than for 114.
>>
>> Now that I have more free time, I'd be happy to finish
resource and MUST NOT make the requested change."
Peter
--
Peter Saint-Andre
https://stpeter.im/
detail for implementors
> to address how they see fit.
Good point, and consistent with what we've said in other specs IIRC.
Will fix in the next version.
Peter
--
Peter Saint-Andre
https://stpeter.im/
2 at 1:17 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> > Metaphorically speaking:
>
> > i.e. in a manner of speaking, we strongly believe senders should be
> > allowed to "dial the phone".
> > Even if we don&#
> until everyone agrees :-)
>
>
> On Mon, Jul 9, 2012 at 7:00 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> 1. What does it mean to "signal intent"? XEP-0030 provides a way to
> signal support. By "signal intent" do you
RTT data with a particular conversation partner, or for a particular
chat session or MUC room, or something else?
2. What does it mean to "want to be informed"? Do you mean "want to
receive RTT data"? If so, again do you mean with a conversation partner
or for a session/room or something else?
3. It's always possible for a client to ignore anything it wants, so I
don't see what #3 is all about.
Thanks!
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 7/9/12 9:24 AM, Todd Herman wrote:
> Currently, specifically XEP-0176. We have already implemented
> support for XEP-0166. I may look into what is required to move that
> extension forward as well but for now I have to focus on XEP-0176
> (ICE). I am actually doing all of this for Relayed Nod
to
> function as STUN servers in order to interpret and respond to the requests.
I'll forward that question to the jingle@ list for discussion there.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 7/9/12 12:24 AM, Barry Dingle wrote:
> Hi Edward,
>
> I understand about the need to educate people about the 'traditional'
> Textphone/TTY text protocols. However, I think that XEP-0301 should
> specify real-time text over XMPP only.
Yes, please.
Peter
--
On 7/8/12 10:10 PM, Mark Rejhon wrote:
> On Sat, Jul 7, 2012 at 7:53 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> Hi Mark,
>
> Thanks for working so diligently to incorporate the mass of feedback
> you received recently. Given the scop
Hi Mark,
Thanks for working so diligently to incorporate the mass of feedback you
received recently. Given the scope of the changes, you might want to
give folks more than just a few days to provide feedback before pushing
out 0.4 (perhaps a week from now?). I know I plan to review it again
this w
On 7/3/12 5:10 PM, Mark Rejhon wrote:
> On Tue, Jul 3, 2012 at 3:06 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> > A minor edit to to clarify this for multiple characters forming one
> > glyph, is to add "incompletely formed glyphs" t
here and would prefer to leave it out
if possible, because it doesn't seem that we're really talking about
"The actual, concrete image of a glyph representation having been
rasterized or otherwise imaged onto some display surface." I think it's
best if RTT talks about characters and code points.
Peter
--
Peter Saint-Andre
https://stpeter.im/
hrough audio/video to "ring through", but blocks RTT until specifically
> turned on by going through several menus.
Again, that is a matter of policy, not protocol.
> I've already added one additional sentence to Section 5 of XEP-0301 to
> specifically discourage stopping a
ery useful due to
>> performance problems) to implement audio/video in-band, but those aren't
>> the proposed standards we have for RTT and audio/video in XMPP.
>
> Please Read : http://www.itu.int/rec/T-REC-F.703/en
> Its new standaard F.703.
Published in November of 2000. I wouldn't exactly call it new.
Peter
--
Peter Saint-Andre
https://stpeter.im/
t;> I did some tests with several languages, including Arabic, and it all
>> works over XEP-0301.
>
> did you test bi-directional text?
>
> I wonder if there are any special considerations here
Bidirectional text always leads to special considerations. This could
get very complicated very quickly...
Peter
--
Peter Saint-Andre
https://stpeter.im/
onsider a situation where software advertises audio (XEP-0266), video
> (XEP-0299) but does not advertise RTT (XEP-0301) even though it's
> implemented.
XEP-0301 says that if it's implemented then it must be advertised,
right? The solution here seems to be "file a bug report" or "submit a
patch".
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 6/27/12 1:16 PM, Lance Stout wrote:
> It may be useful to include some note on how this would interact with
> XEP-0071 for XHTML-IM, if at all.
>
> If the two can be used together, then I would imagine that any HTML
> formatting would be ignored when sending RTT, and only sent in a normal,
> fu
racter encoding." It seems more natural to talk in terms of
> characters than in terms of code points.
>
>
> On cover, I agree...
> But for internal implementation, it's problematic. Especially on
> platforms that don't store internally in UTF-8.
The question of "code point" vs. "character" is terminological, not a
matter of encoding.
> Actual real-time implementors within our taskgroup have gradually
> shifted to a preference for Code Points for many reasons (not just the
> ones I indicated).
>
>
> Your comments are welcome and useful!
> Thank you very much!
> We'd love a response to the remaining comments too -
Time is limited. I'll reply as I can.
Peter
--
Peter Saint-Andre
https://stpeter.im/
ss 'expensive' than a
> video call, or an in-band file transfer.
I don't think Kurt was suggesting that the spec mandate turning off RTT
if encryption is supported, but that it might be a wise thing for
implementations to do in multi-resource scenarios.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 6/26/12 2:22 AM, Mark Rejhon wrote:
> On Mon, Jun 25, 2012 at 10:19 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> I've had a chance to review XEP-0301 in some detail.
>
>
> First, overall I think it is in good shape, I don't have
]).
NEW
A good implementation of Message Retransmission will improve user
experience, regardless of whether or not the software follows Best
Practices for Resource Locking [14].
SECTION 10.2
OLD
The load between participants using this specification in the
recommended way, will cause a load that is only marginally higher than a
user communicating without this specification.
NEW
Use of this specification in the recommended way will cause a load that
is only marginally higher than a user communicating without this
specification.
I have some even smaller issues of grammar and punctuation, but I can
save those for a XEP Editor review before or after Last Call.
Thanks!
Peter
--
Peter Saint-Andre
https://stpeter.im/
FYI.
I have updated XEP-0068 to reference this spec instead of the old
Internet-Draft.
/psa
Original Message
Subject: BCP 178, RFC 6648 on Deprecating the "X-" Prefix and Similar
Constructs in Application Protocols
Date: Mon, 25 Jun 2012 10:31:34 -0700 (PDT)
From: rfc-edi...@rf
lear. I'll work to send feedback by then. We
can think of it as a "pre-last-call". ;-)
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 6/22/12 2:39 PM, Mark Rejhon wrote:
> On Fri, Jun 22, 2012 at 4:32 PM, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote:
>
> > I'm aware. We'd like to finish the current queue of
> > corrections/improvements (several of which have been queue
ernmental agencies as well as mainstream vendors, expressing
> interest. Your comments will greatly improve the chance of acceptance
> to Draft.
Well, I'm not sure about *that*, but I'm happy to review the spec
because I think this functionality is important in certain contexts.
Peter
--
Peter Saint-Andre
https://stpeter.im/
you know, the next step would be for the XMPP Council to issue
a Last Call in accordance with XEP-0001. Do you think the spec is ready
for a Last Call now, or would you prefer to receive additional reviews
beforehand?
FWIW I'm planning to review it in detail soon. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
ur server. If there's no server, you wouldn't need to use XEP-0257. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
rk and is not tied to
usernames and passwords. One approach would be to use client
certificates -- thus you'd present those certs during TLS negotiation
and just reference them using SASL EXTERNAL during SASL negotiation.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 6/20/12 8:42 AM, Peter Saint-Andre wrote:
> On 6/20/12 6:03 AM, Sergey Dobrov wrote:
>> On 06/20/2012 01:32 AM, Peter Saint-Andre wrote:
>>> On 6/19/12 10:17 AM, XMPP Extensions Editor wrote:
>>>> The XMPP Extensions Editor has received a proposal for a new XEP.
&
On 6/20/12 6:03 AM, Sergey Dobrov wrote:
> On 06/20/2012 01:32 AM, Peter Saint-Andre wrote:
>> On 6/19/12 10:17 AM, XMPP Extensions Editor wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>>
>>> Title: Data Forms XML Element
>>
g/TR/REC-xml/#NT-element
So at least we need to change the element name. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
The authors had sent me an outdated version. I've pushed a revised
version to the website.
On 6/19/12 10:17 AM, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Security Labels in PubSub
>
> Abstract: This document describes an extensio
ion-text-names/hash-function-text-names.xml
I am still trying to convince the IANA to register their own URN scheme,
so we might not need to mint a URN for this usage in the xmpp tree. I'll
poke my IANA contact about that again right now. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
As posted at http://xmpp.org/2012/06/xmpp-summit/ ...
We’ve decided to hold the next XMPP Summit in Portland, Oregon at the
end of October. Mark your calendars for October 25th, which is the day
after the Keeping it Realtime conference [1]. Co-locating the XMPP
Summit with krtconf makes a lot of s
On 6/12/12 1:44 PM, Justin Karneges wrote:
> On Tuesday, June 12, 2012 12:10:30 PM Peter Saint-Andre wrote:
>> On 5/24/12 8:44 AM, Peter Saint-Andre wrote:
>>> On 5/24/12 1:01 AM, Sergey Dobrov wrote:
>>>> On 05/23/2012 04:45 AM, Peter Saint-Andre
On 5/24/12 8:44 AM, Peter Saint-Andre wrote:
> On 5/24/12 1:01 AM, Sergey Dobrov wrote:
>> On 05/23/2012 04:45 AM, Peter Saint-Andre wrote:
>>> Old thread alert!
>>>
>>>
>>> Well, the spec says that the length restriction applies to the
>>> b
On 6/10/12 5:08 AM, Sergey Dobrov wrote:
> On 06/10/2012 04:44 PM, Sergey Dobrov wrote:
>> On 06/08/2012 10:41 PM, Peter Saint-Andre wrote:
>>
>> I see the following reasons here:
>> 1) some of these fields have more complex types that just a string. For
>> exam
On 6/8/12 3:56 AM, Sergey Dobrov wrote:
> On 06/08/2012 06:16 AM, Peter Saint-Andre wrote:
>> On 5/30/12 1:07 PM, Sergey Dobrov wrote:
>>
>> So we have at least three options:
>>
>> 1. Map the atom:feed elements to x:data fields.
>> 2. Define a generic &quo
Hi Dirk, that all sounds good! I'll poke Thijs and Kim about updating
the spec.
On 5/31/12 12:38 PM, Dirk Meyer wrote:
> Hi,
>
> On 05/31/2012 07:49 PM, Peter Saint-Andre wrote:
>> Given that Dirk it not really actively involved in XMPP any longer
>> (AFAIK)
>
>
On 5/30/12 1:07 PM, Sergey Dobrov wrote:
> On 05/31/2012 01:51 AM, Peter Saint-Andre wrote:
>> On 5/30/12 12:24 PM, Sergey Dobrov wrote:
>>> On 05/31/2012 12:02 AM, Peter Saint-Andre wrote:
>>>> changing the subject...
>>>>
>>>> On 5/30/12 3:07
The new version is much improved. Some points are still a bit nebulous,
but the general direction is clear. Looking forward to v0.3.
On 5/30/12 11:03 AM, Peter Saint-Andre wrote:
> Hi Kev, many thanks for updating XEP-0289. I'll need to take some time
> to review it completely, and
Sorry about top-posting, but I wanted to preserve the entire message for
Dirk Meyer (cc'd).
Given that Dirk it not really actively involved in XMPP any longer
(AFAIK), I think it would be good for Thijs and perhaps Kim to take over
maintenance of this spec.
I also agree about decoupling this spec
reat thing about open source is that we can contribute code
to any projects that don't support it yet. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
d more an issue.
>
> We have http://xmpp.org/extensions/xep-0225.html - although support is
> less widespread than for 114.
Now that I have more free time, I'd be happy to finish XEP-0225. There
are a few existing implementations, so step one might be to gather feedback.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 5/30/12 12:24 PM, Sergey Dobrov wrote:
> On 05/31/2012 12:02 AM, Peter Saint-Andre wrote:
>> changing the subject...
>>
>> On 5/30/12 3:07 AM, Sergey Dobrov wrote:
>>
>> The main problem I see here is that the data you get with item='meta'
>>
the energy to do another round.
>
> On Wed, Feb 8, 2012 at 2:10 AM, Peter Saint-Andre wrote:
>> - from the perspective of a far user, is the mirror room just a standard
>> MUC room? if not, why not (and exactly how)?
>
> Entirely standard.
>
>> - do mirror rooms
changing the subject...
On 5/30/12 3:07 AM, Sergey Dobrov wrote:
> On 05/30/2012 05:33 AM, Peter Saint-Andre wrote:
>> On 5/28/12 1:53 AM, Sergey Dobrov wrote:
>>> On 05/26/2012 01:23 AM, Peter Saint-Andre wrote:
>>>> On 5/23/12 1:28 AM, Sergey Dobrov wrote:
>&
state about this? Is this planned to be
> updated in the spec or not?
Olivier Crête started working on this last year:
http://xmpp.org/extensions/xep-0293.html
It's deferred because it hasn't been updated in 12+ months. Feel free to
provide comments on it, chat with Olivier, offer to co-maintain it, etc.
Peter
--
Peter Saint-Andre
https://stpeter.im/
ne to them. I realize that's not as "clean" from a protocol
perspective, but the protocol details can be hidden from the end user
anyway (something like right-clicking "appear visible to this group" in
the roster list can trigger some number of directed presence stanzas).
Peter
--
Peter Saint-Andre
https://stpeter.im/
proving federation of core XMPP servers, not components.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 5/29/12 4:31 PM, Goffi wrote:
> Le 29/05/2012 19:01, Peter Saint-Andre a écrit :
>> So it sounds as if you're a target user for privacy lists. :) I'm not
>> necessarily interested in forbidding or deprecating privacy lists, but
>> in general I think they're
On 5/28/12 1:53 AM, Sergey Dobrov wrote:
> On 05/26/2012 01:23 AM, Peter Saint-Andre wrote:
>> On 5/23/12 1:28 AM, Sergey Dobrov wrote:
>>> On 05/23/2012 03:24 AM, Peter Saint-Andre wrote:
>>>>
>>>> But I certainly might want to receive the last publi
ce-based delivery.
> So they will
> send me events even if I am offline, but I can lose some events if my
> resource was not with higher priority, and this is the problem, I think...
In general, yes.
Peter
--
Peter Saint-Andre
https://stpeter.im/
n't say anything about outbound presence
probes. Unless I'm missing something. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 5/29/12 10:16 AM, Goffi wrote:
> G'day,
>
> It seems that it's not possible to be visible to only a roster group with
> XEP-0186 (except by sending directed presence to each jid individually).
>
> For me it's an important point do manage visibility at the roster group
> level,
> this is pos
ch as probe='true' to
> allow the client to ask the server to probe contacts (with the
> consequence of not necessarily being so "invisible" any more).
That slightly complicates this ultra-simple extension. Since the 'probe'
attribute would default to FALSE, I&#
On 5/29/12 10:02 AM, Kevin Smith wrote:
> On Tue, May 29, 2012 at 4:35 PM, Peter Saint-Andre wrote:
>> I'm not a big fan of invisibility, but if we're going to do it then we
>> might as well do it right.
>>
>> Some clients and servers use XEP-0018, but it v
XEP-0186, but if so it would be good to
know. In any case, I'm wondering if folks are interested in seeing
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
Thoughts?
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 5/23/12 1:28 AM, Sergey Dobrov wrote:
> On 05/23/2012 03:24 AM, Peter Saint-Andre wrote:
>> On 5/22/12 12:40 PM, Sergey Dobrov wrote:
>>
>> Well, the need to *change* it from the default to some reasonable value
>> implies that the default value is unreaso
On 5/24/12 1:01 AM, Sergey Dobrov wrote:
> On 05/23/2012 04:45 AM, Peter Saint-Andre wrote:
>> Old thread alert!
>>
>>
>> Well, the spec says that the length restriction applies to the
>> base64-encoded data, so I think we meant that this does *not* apply to
>
On 5/22/12 4:13 PM, Matthew Wild wrote:
> Old draft alert! I really thought I had sent this... sorry.
>
> On 31 January 2012 09:07, Sergey Dobrov wrote:
>> On 01/31/2012 05:54 AM, Peter Saint-Andre wrote:
>>> At its meeting on December 20, 2011, the XMPP Council agreed
Old thread alert!
On 1/31/12 2:07 AM, Sergey Dobrov wrote:
> On 01/31/2012 05:54 AM, Peter Saint-Andre wrote:
>> At its meeting on December 20, 2011, the XMPP Council agreed to
>> issue a "Call for Experience" regarding XEP-0047 (In-Band
>> Bytestreams), in prepara
On 5/22/12 3:20 PM, Matt Miller wrote:
>
> On May 22, 2012, at 15:11, Matthew Miller wrote:
>
>>
>> On May 22, 2012, at 15:10, Peter Saint-Andre wrote:
>>
>>> On 5/22/12 3:08 PM, Matthew Miller wrote:
>>>>
>>>> On May 22, 2012, at 14
On 5/22/12 3:08 PM, Matthew Miller wrote:
>
> On May 22, 2012, at 14:58, Peter Saint-Andre wrote:
>
>> On 5/21/12 1:21 AM, Philipp Hancke wrote:
>>> On Thu, 26 Apr 2012, Philipp Hancke wrote:
>>>
>>>> old thread alert...
>>>>
>>&g
On 5/22/12 2:42 PM, Philipp Hancke wrote:
> mostly xsf-land but since this touches multiplexing...
> Am 22.05.2012 19:04, schrieb Peter Saint-Andre:
>> On 5/22/12 9:23 AM, Philipp Hancke wrote:
>>> On Tue, 22 May 2012, Peter Saint-Andre wrote:
>>>
>>>&
suggest
that we remove this sentence:
"For client-to-server connections, the client MUST NOT attempt to enable
stream management until after it has completed Resource Binding unless
it is resuming a previous session (see Resumption)."
> typo in section 1: "By conStrast with stream management"
Fixed.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 5/22/12 12:40 PM, Sergey Dobrov wrote:
> On 05/23/2012 12:55 AM, Peter Saint-Andre wrote:
>> On 5/22/12 11:56 AM, XMPP Extensions Editor wrote:
>>> Version 0.6 of XEP-0277 (Microblogging over XMPP) has been released.
>>>
>>> Abstract: This specification def
sub#max_items?
Why change "pubsub#send_last_published_item" to "never"?
I don't understand the special meaning of ItemID = zero for metadata. I
think there might be a better way to handle this.
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 5/22/12 9:23 AM, Philipp Hancke wrote:
> On Tue, 22 May 2012, Peter Saint-Andre wrote:
>
>> On 5/21/12 7:22 AM, Matthew Wild wrote:
>>> On 21 May 2012 09:08, Philipp Hancke wrote:
>>>> The argument of keeping the negotiation of stream features in one place
>
ement and deploy it seems even more fun.
> Even if we keep the same authenti...thingy around, at least we should
> have something more integrated into our normal feature negotiation.
> like SASL is.
We had discussions long ago about defining a SASL mechanism for
dialback. That would slot in rather nicely, no?
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 5/16/12 4:49 PM, XMPP Extensions Editor wrote:
> Version 0.5 of XEP-0268 (Incident Handling) has been released.
>
> Abstract: This specification defines methods for incident reporting among
> XMPP server deployments using the IODEF format produced by the IETF's INCH
> Working Group.
>
> Chan
important; it can be a URI,
> a URN, a Java reverse-domain, or something else.
>
>
> On May 15, 2012, at 17:26, Peter Saint-Andre wrote:
>
>> I've been thinking about this further, and I'm not sure about the MUST
>> for the field name formatting, which in
Thus I've checked in 1.2rc5:
http://xmpp.org/extensions/tmp/xep-0068-1.2.html
http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2rc5
http://xmpp.org/extensions/diff/api/xep/0068/diff/1.2rc4/vs/1.2rc5
(the diffs don't render yet, but should soon)
On 5/16/12 6:48 AM, Peter S
Exactly.
On 5/15/12 11:44 PM, Joe Hildebrand wrote:
> That sounds fine to me. The real requirement is that the author is certain
> that the field name is not going to collide with anyone else's field name
> that might have a different meaning.
>
>
> On 5/15/12 5:26
ue in the next Council meeting if there is no
discussion on the list before then.
On 5/9/12 11:01 AM, Peter Saint-Andre wrote:
> Based on further feedback from Ralph Meijer, I suggest that we might
> want to add another paragraph to clarify existing usage:
>
> ###
>
> For reason
I've attached a patch which simply adds a timezone element to XEP-0080:
> User Location. Have I missed something here? Is there somewhere more
> appropriate for this information?
We do have a spec for "Entity Time"...
http://xmpp.org/extensions/xep-0202.html
Peter
--
Peter Saint-Andre
https://stpeter.im/
d
deprecating the convention.
###
On 5/9/12 9:38 AM, Peter Saint-Andre wrote:
> In its meeting just now, the XMPP Council discussed [1] some changes to
> XEP-0068 (Field Standardization for Data Forms) to align this spec with
> a forthcoming recommendation at the IETF [2] to deprecate the
In its meeting just now, the XMPP Council discussed [1] some changes to
XEP-0068 (Field Standardization for Data Forms) to align this spec with
a forthcoming recommendation at the IETF [2] to deprecate the "x-"
prefix for protocol parameters.
As a result of that discussion, I'm proposing some adju
FYI, the document deprecating the "x-" convention has been approved by
the IESG. I think it's now safe to move forward with version 1.2 of
XEP-0068, and I'll ping the Council about that for its next meeting.
I've made some further small changes to XEP-0068 in order to track
changes to the xdash doc
>>> It's very old and might not reflect up-to-date thinking about
>>> interactions between entities.
> This is why I'd like to reanimate the discussion :)
Markus, I can put you in touch with Evan if you'd like. Let's see if
he still has any interest in thi
This is a major rewrite, now using IODEF (RFC 5070) instead of a custom
schema. There's still much work to do on the various communication
flows, but feedback would be welcome on the general approach. For
comparison purposes, the previous version is at [1].
/psa
On 4/17/12 10:00 AM, XMPP Extensio
quot;
>
> I think it should be "(b) the *initiating* entity MAY have a policy of
> following redirects only if it has authenticated the receiving entity"
You're right!
> But thanks for it, it's much more clear than previous version of the RFC.
I'm happy to hear it.
Peter
--
Peter Saint-Andre
https://stpeter.im/
te
Building. I don't know how widely this kind of thing is used, but
currently the element is not limited to the special kind of
location-uri from RFC 6442.
> If all these checks come out positive, then it may be possible to
> just add to the usage description of the URI element in XEP
n by creating a discussion list at xmpp.org. If
you're interested in these topics, please sign up here:
http://mail.jabber.org/mailman/listinfo/iot
Thanks!
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/28/12 2:18 PM, Kevin Smith wrote:
> On Tue, Mar 27, 2012 at 12:58 AM, Peter Saint-Andre
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> The IETF’s XMPP Working Group will hold an in-person meeting th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The IETF’s XMPP Working Group will hold an in-person meeting this week
at IETF 83 in Paris. The topics will include end-to-end encryption,
server-to-server federation, and internationalization. Remote access
will also be accommodated. Here are the part
muc> > | iconv -t UTF-8 | openssl dgst -sha1 -binary | openssl base64
>> q07IKJEyjvHSyhy//CH0CxmKi8w=
>>
>> It'd be interesting to hear how you got to your results.
>>
>> Regards, Florian Zeitz
>
> Good day, Florian,
>
> Yes, I've tested ag
ng from a
I see your point. When XEP-0301 advances to Draft, we'll want to
update XEP-0085 as well. Essentially, a message with but no
is something in between a content message and a standalone
message, in the terminology of XEP-0085. We could think of it as an
interim message,
On 3/11/12 4:07 AM, Joe Hildebrand wrote:
> On 3/8/12 2:25 PM, "Peter Saint-Andre" wrote:
>
>>>
>>>
>>
>> Well, this is presence. Let's see if we can shorten it.
>>
>> = 49 chars
>>
>> = 35 chars
>
>
user an updated vCard
unless they asked for it or tried to view it. Using pubsub just improves
things underneath (because your client doesn't need to poll).
Peter
--
Peter Saint-Andre
https://stpeter.im/
601 - 700 of 3395 matches
Mail list logo
