Re: [Standards] Proposed XMPP Extension: Buddycloud Channels
I've started reviewing Buddycloud Channels, and have some questions/comments: - Is Buddycloud intended to become a generic term, like PubSub/MUC/Jingle? I'm curious because it is giving me the same cautious pause as if this had been submitted by Facebook and named "Facebook Channels", using the name of a corporation or other trademarked term in the protocol name. The disco identity registered here is for pubsub/channels. Would simply Channels be a better term? (XEP-0060 doesn't use the term channel, so no conflict there) - Section 2: It says that a server can have one Buddycloud channel server. Is this an artifact of the current Buddycloud implementation, or a restriction imposed by the protocol? - Section 6.1.1: XEP-0060 doesn't currently allow for using multiple elements like that. It might be better to have those as children of a element. - Section 6.3: While the Buddycloud service is using Atom for entries, does that need to be specified as part of this XEP? Some of the tables indicate that non-Atom content is used already. - Section 9.1 Inbox is missing? Although Section 9 seems superfluous right now (that's more a description of the Buddycloud project/service as a whole, not of this protocol). On the whole, I'm liking this so far. Most of my concerns stem from balancing documenting Buddycloud as it currently works vs making things a bit more general to be useable in non-Buddycloud projects. — Lance signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] XEP-0170: Recommended Order of Stream Feature Negotiation
On Apr 29, 2014, at 9:12 AM, Kim Alvefur wrote: > Hello list, > > I noticed that XEP-0170 1) talks about the old RFCs and 2) does not > mention XEP 198, Stream Management. 198 doesn't use a stream restart, > so some description about that could be useful. Is it perhaps time for > an update to this XEP (or replacement)? > > -- > Kim "Zash" Alvefur > I'm +1 for reviewing and updating XEP-0170. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] Proposed XMPP Extension: Buddycloud Channels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 4/28/14, 10:11 AM, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Buddycloud Channels > > Abstract: This document describes a profile and conventions for usage > of the PubSub protocol in the context of a new type of communication. > > URL: http://xmpp.org/extensions/inbox/buddycloud-channels.html > > The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. > Note that the inbox XEP above now should match the authors' intended results. - -- - - m&m Matthew A. Miller < http://goo.gl/LK55L > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTX9OXAAoJEOz0ck4QngW7B6cH+wcC48lcS/mCSS+dKRAs3rb1 pQjlpPKeKeKmRtCH7DB0XD9jLvEtOA2dEo19H2t5vXR49S9/Suo1yzYaIgTXWo8G A6oFuts46mLr+z0a1KlRJQaaoE68mSrKTUxlt4vdzy6J0SGA+QoVcp+8OxtedNMN UpK3ManXoA7IjCY5Y/oW9WhP98bo9OhbCv1uLEQVxUvgFeF9CfAjraOpqUSCaSsg NQqe3xCg7IvhOsDySlxLpSDDPfI2pkafNGGfuz4+6gDCyqgH6j6h2LgQQ8UwvBk4 sBveV9Yqg5lEqK+11KyxQa95C+dQJxqYbhaO16Q1Dc1z5L4FNRTZeKlYXwW4kmQ= =A3qv -END PGP SIGNATURE-
[Standards] XEP-0170: Recommended Order of Stream Feature Negotiation
Hello list, I noticed that XEP-0170 1) talks about the old RFCs and 2) does not mention XEP 198, Stream Management. 198 doesn't use a stream restart, so some description about that could be useful. Is it perhaps time for an update to this XEP (or replacement)? -- Kim "Zash" Alvefur signature.asc Description: OpenPGP digital signature
Re: [Standards] Carbons - inbound messages to bare jid
Hello,
[this is a slightly modified version of a message that got lost in moderation]
* Thijs Alkemade [2014-04-25 16:02]:
> Thinking about this a bit more, I actually disagree with this proposal.
I second the suggestion to remove or strongly reword section 6. It
should keep a reference to XMPP-IM forking, and mandate that no more
than one copy shall be sent per resource, however not enforce forking
over carbons.
A carbons-enabled client is able to handle incoming carbons anyway, and
having different semantics for bare- vs. full-JID messages only makes
matters more complicated.
> The semantics of receiving a carbon copy should be "hey this other resource
> has a conversation going, here's a copy of this message in case you want to
> follow along". That might imply, for example, that the client uses a different
> way of notifying the user: the user might have configured their client to not
> make a sound when receiving a carbon copy, as multiple devices making sounds
> gets annoying.
This is actually horribly under-defined in XEP-0280. Generally, a client
should make less intrusive user notifications on incoming carbons
(compared to regular chat messages). However, there are many situations
where the sender's resource locking mechanism fails, and you do not see
an important message that was directed to you, because your client only
got a carbon copy of it and did not notify you.
Therefore, yaxim deploys a complicated logic to make a notification
sound on the first(*) incoming carbon message, and on all regular
messages.
(*) The counter is reset whenever the user opens the chat window for the
respective contact.
> A bare-JID message is a different situation. Sending one implies the sender is
> looking for a resource that will reply to start a conversation with it, so for
> these I think it would be fine if a carbons-enabled client notifies the user
> as if it were a normal message.
This fails to account for clients (like yaxim) that do not implement
resource locking and instead always address the bare JID, relyin on the
server routing.
Also, the first-message-is-special semantics is essentially achieved
by the above application-level logic, with the bonus feature that a user
hopping his clients (i.e. when he goes out of his home) has a higher
chance to notice a new message, even if it was sent to his home
resource.
> Of course the client could add extra logic for this ("if it's a carbon copy,
> and the first message we've seen from this user this session/hour/day, play
> sounds"), but I think doing it in the way that is currently in the XEP is a
> much cleaner solution.
On the other hand, the XEP currently requires server logic (and state!)
to distinguish XEP-0280-forked bare-JID messages from other bare-JID
messages, to allow error inhibition according to section 10.3
.
That state keeping could be avoided if a server only needs to inhibit
errors for stanzas.
Georg
--
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? ||
++ IRCnet OFTC OPN ||_||
signature.asc
Description: Digital signature
Re: [Standards] Proposed XMPP Extension: Buddycloud Channels
In the latest spec we use a PTR record - but that's not so important. The DNS look up is optional. DISCO response SHOULD always take priority. The DNS look up is for s2s communications and a client is not involved at all. A client always talks to its "home" buddycloud server. The addition of a DNS lookup is for users like Simon T who use google apps and so their main XMPP server (google) won't allow them to add components. We still use DISCO as its the standard way of performing discovery. DNS is just an additional nice mechanism. _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI & DDRC - 15th December 2013 - NDAC, Chepstow On 28 April 2014 21:53, Edwin Mons wrote: > On 28/04/14 18:11, XMPP Extensions Editor wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Buddycloud Channels > > > > Abstract: This document describes a profile and conventions for usage > > of the PubSub protocol in the context of a new > type of communication. > > > > URL: http://xmpp.org/extensions/inbox/buddycloud-channels.html > > > > The XMPP Council will decide in the next two weeks whether to accept > this proposal as an official XEP. > > > > > Does para 3.2 imply that you should always do the DNS lookup, or should > a client that tries to find a Buddycloud pubsub domain only try this as > a fallback mechanism? If the former, why do the disco#info at all if an > SRV record is found? If the latter, how could the results be conflicting? > > Edwin > >
Re: [Standards] Proposed XMPP Extension: Buddycloud Channels
Sorry about the confusion with the build. I should have doubled checked that before submitting. The SRV stuff was updated to use PTR records after the discussion in the XSF muc late last year. Hopefully clearer: http://buddycloud.github.io/buddycloud-xep/#DISCOthenDNS On 28 April 2014 22:53, Edwin Mons wrote: > On 28/04/14 18:11, XMPP Extensions Editor wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Buddycloud Channels > > > > Abstract: This document describes a profile and conventions for usage > > of the PubSub protocol in the context of a new > type of communication. > > > > URL: http://xmpp.org/extensions/inbox/buddycloud-channels.html > > > > The XMPP Council will decide in the next two weeks whether to accept > this proposal as an official XEP. > > > > > Does para 3.2 imply that you should always do the DNS lookup, or should > a client that tries to find a Buddycloud pubsub domain only try this as > a fallback mechanism? If the former, why do the disco#info at all if an > SRV record is found? If the latter, how could the results be conflicting? > > Edwin > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
