[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217633#comment-17217633
]
Christian Schudt commented on MDEP-489:
---
Yes, it was already enabled, so that di
[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217505#comment-17217505
]
Christian Schudt commented on MDEP-489:
---
!screenshot-1.png!
Here you see
[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schudt updated MDEP-489:
--
Attachment: screenshot-1.png
> Regression: unpack-dependencies fails on Windows for tar
[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217503#comment-17217503
]
Christian Schudt commented on MDEP-489:
---
{noformat}
[ERROR] Failed to execute
[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217500#comment-17217500
]
Christian Schudt commented on MDEP-489:
---
I've attached a sample pom f
[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schudt updated MDEP-489:
--
Attachment: pom.xml
> Regression: unpack-dependencies fails on Windows for tar.gz contain
[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217498#comment-17217498
]
Christian Schudt commented on MDEP-489:
---
The issue is most likely relate
[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208701#comment-17208701
]
Christian Schudt commented on MDEP-489:
---
[~michael-o] can you reope
[
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208699#comment-17208699
]
Christian Schudt commented on MDEP-489:
---
I can reproduce the issue as
Hi,
I have difficulties understanding the correct server side processing of inbound
„unsubscribe“ and „unsubscribed" presence, because RFC 6121 is ambiguous here:
-
§ 3.3.3. Server Processing of Inbound Unsubscribe
MUST first check if the user's bare JID is in the contact's roster with
su
Hi,
see my answers below.
> Am 25.02.2020 um 16:52 schrieb Jonas Schäfer (XSF Editor)
> :
>
> The XEP Editor would like to Call for Experience with XEP-0066 before
> presenting it to the Council for advancing it to Final status.
>
>
> During the Call for Experience, please answer the followin
Hi,
here some implementation for XEP 131 and 141 because you said „doesn’t have
enough implementation“.
=> XEP-0001 requirement (at least two implementations) is fulfilled.
— Christian
> 4) Advance to Final XEP-0131: Stanza Headers and Internet Metadata -
> https://xmpp.org/extensions/xep-01
> 1. What software has XEP-0131 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.
https://bitbucket.org/sco0ter/babbler/src/0.7.5/xmpp-extens
> 1. What software has XEP-0141 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.
I’ve implemented it in Babbler,
https://bitbucket.org/sco0t
>> TL;DR: The purpose is/was to transfer files in case the receiver is offline.
> Given the primary mechanism in -66 is iq-based, I don’t think this is true,
> or I misunderstood your point.
Maybe you are right. It was just a guess, because someone asked for the purpose
of 0066.
Because the
Hi,
I agree with you about the expected behavior.
But the behavior when changing the status is specific to the client
implementation and I think this "lock screen" behavior is nowhere specified by
XMPP (at best is should be specified in some "best practices" informational XEP
or in an "Impleme
Hi,
although I can't give you a good answer here, this is probably related to the issue I mentioned during the Call for Experience.
It's unclear if a single pubsub item should contain only one bookmark or multiple. The one bookmark per item appraoch seems to be favoured by XEP-223:
"the h
Hi,
my original question quickly drifted away to a discussion about the use case of
serverless messaging.
But I feel my concern was not addressed:
1. Why can’t the receiving entity include its Entity Caps as stream feature as
described in XEP-0115?
2. Why should we instead use disco#info? I do
> However I'm not really sure what the intended purpose of this XEP is
> and if we still have a use case for that purpose.
I understood the purpose as follows:
a) You upload some file to a server (nowadays you could also use XEP-363).
b) You send a message to a contact with XEP-0066.
c) Contact
> 1. What software has XEP-0048 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.
Enough.
> 2. Have developers experienced any problems with
> Are people still using this technology? In my experience, it was a fun
> experiment in ~2006 but didn't work well in practice: too chatty over
> the network, presence never worked correctly, you'd send a message to
> someone and it turns out they weren't available, etc.
I was considering impleme
Hi,
I find the whole passage „Discovering Capabilities“ of Serverless Messaging [1]
a bit confusing.
1. Why can’t the receiving entity include its Entity Caps as stream feature as
described in [2].
2. I can see the slight optimization of including disco#info data as stream
feature (similar as
image data is the base64 encoded binary content of the image file.
>
> "The element SHOULD contain a child whose XML character
> data is Base64-encoded data for the avatar image."
>
>
> I've never seen any examples to the contrary; and I suspect no receiving
&
Hi list,
I’ve got a question about XEP-0153. Its XML schema defines that the photo hash
is encoded as Base64:
Hi Jonas,
> You are referring to the processing entities side? The entity is free to
> choose from the set as it desires. The order of elements inside the hash set
> is undefined. It could for example iterate a list of hash functions in
> descending order of preference and look for hashes in t
Hi,
I’ve implemented Entity Capabilities 2.0 (XEP-0390) and like to share some
thoughts about it here and in the following link.
I think it could be interesting for library developers as well as the author(s)
of XEP-0390:
http://babbler-xmpp.blogspot.de/2018/02/experimenting-with-entity-capabi
Hi,
Openfire does implement it.
-- Christian
Gesendet: Donnerstag, 08. Februar 2018 um 03:26 Uhr
Von: "Peter Saint-Andre"
An: standards@xmpp.org
Betreff: Re: [Standards] XEP-0060: max-nodes-exceeded error is not described.
On 2/7/18 2:04 AM, Christian Schudt w
Hi Paul,
I don't think there's an error in specification, because I've successfully implemented it (and the test vectors).
Have a look at my Java implementation:
https://bitbucket.org/sco0ter/babbler/src/1cddf27f01fb464628e71559912b09de9457/xmpp-extensions/src/main/java/rocks/xmpp/
Hi,
an alternative would be to assume that all stanzas have been received, if the h value is higher than the number of sent stanzas.
E.g. if client sends 10 stanzas and server responds with h='20', the client would assume that the server has received all 10 stanzas. That means "clearing" t
Hi,
please consider this issue:
https://github.com/xsf/xeps/issues/581
I kindly ask the authors of XEP-0060 to describe the "max-nodes-exceeded" error in the specification or to remove it from the XML schema, if it should not be used.
Although one can guess, when this error should be u
Hi,
I’ve updated my PRECIS Java library to the new RFCs 8264, 8265 and 8266.
You can find it on Maven Central:
rocks.xmpp
precis
1.0.0
https://bitbucket.org/sco0ter/precis
Changes:
- use toLowerCase() for case mapping
- ensure that methods are idempotent
- added toComparableString() method,
ely defensive.
>
>
> On Sat, Dec 9, 2017 at 2:27 PM, Christian Schudt
> wrote:
>> Great, thanks! These code points revealed some bugs :-). They should have
>> been included in the Examples.
>>
>> Are there any known code points for the IdentifierClass / User
uot;\u00a8"
> "\u02dc"
>
>
> On Sat, Dec 9, 2017 at 8:37 AM, Christian Schudt
> wrote:
>> Hi,
>>
>> RFC 8264 introduced these new sentences:
>>
>> under certain circumstances, such as when Unicode
>> Normalization Form K
Hi,
RFC 8264 introduced these new sentences:
under certain circumstances, such as when Unicode
Normalization Form KC is used, performing Unicode normalization after
case mapping can still yield uppercase characters for certain code
points
Therefore, an implementation SHOULD apply
>
> Sigh.
>
> I'm sorry that we failed to make things clear and consistent.
>
> I agree with Bill that implementations should follow the order of rules
> in Section 7 of RFC 8264.
>
> Let me think about how we can clarify things. That might involve filing
> an erratum against RFC 8265.
>
> Pe
Hi all,
now that the new RFC 8264 / 8265 are out, I wanted to update my implementation,
which was based on the older RFCs.
Unfortunately the order of rules still confuses me.
During enforcement and comparison of a string, do I first validate a string,
then apply the rules (as written in
https
> If we would be choosing a modern hash function, something from the SHA3 family
> or blake would be more sensible.
Please consider using either SHA-1 or SHA-256, not blake.
The reason: It at least makes Java implementations easier, because those are
available on every implementation of the Jav
any state.
> Am 15.03.2017 um 18:03 schrieb Christian Schudt :
>
> Hi,
>
> I think Openfire doesn’t support Stream Resumption yet, but I’ve implemented
> Carbons in it and I think if it would support stream resumption, carbons
> state would not be restored.
> I.e. Carbons
Hi,
I think Openfire doesn’t support Stream Resumption yet, but I’ve implemented
Carbons in it and I think if it would support stream resumption, carbons state
would not be restored.
I.e. Carbons state would be the same as before.
I guess any implementation would keep some stateful session obje
Hi,
what exactly was the reason for a namespace bump for urn:xmpp:hashes:1 =>
urn:xmpp:hashes:2 ?
I couldn’t find any discussion about it in the Last Call [1], nor do I see any
real difference to the previous version 0.4 [2].
The only difference I see is, that the document now explicitly menti
> The use of a different namespace on in a disco#info reply worries
> me. This doesn’t work with XEP-0115 (I hope, because <{urn:xmpp:mix:0}feature/
>> and <{http://jabber.org/protocol/disco#info}feature/> are fundamentally
> different elements) and is, as far as I know, specified nowhere as a
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to
> clarify an existing protocol?
Partly.
XEP-0079: Advanced Message Processing already solves the same problem.
dropforward => no-copy
dropstored => no-store
> 2. Does the specification solve the problem s
Hi,
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to
> clarify an existing protocol?
Yes.
> 2. Does the specification solve the problem stated in the introduction and
> requirements?
Yes.
> 3. Do you plan to implement this specification in your code? If not, why
> Except that they’re not chat messages, so won’t be stored, and if they were
> you’d be potentially up to doubling the size of your archive (I guess adding
> a quarter to, on average) as you fill it with read markers - unless you want
> to customise the MAM service to understand unread state,
Isn't MAM supposed to address the issue of "synchronizing multiple resources/clients", so that every client sees the same history of (chat) messages, even if they were originally delivered to another client?
If that syncing works for chat messages, it should work for "read receipt" messages as
Can't XEP-0333 used for that?
A sends a message to B with a "read request".
B reads the message and sends a "read receipt" back to A.
The read receipt is stored in the server archive normally as any other (chat) message.
Clients can query the archive in a normal way, e.g. all message
This has been discovered before, but nobody cared:
https://mail.jabber.org/pipermail/standards/2014-October/029242.html
- Christian
Gesendet: Mittwoch, 23. November 2016 um 15:52 Uhr
Von: "Anno van Vliet"
An: "standards@xmpp.org"
Betreff: [Standards] XEP-0050 xml inconsistency
In th
Hi,
I just wished there was a Delayed Delivery element (XEP-0203) on inbound presence subscription requests, for the case the requested contact is offline, or ignoring the request for some time.
You don't know when the reqester originally sent the subscription request.
RFC 6121 § 3.1.3 [1]
Hi Florian,
> Subject says it all: Is an IQ request sent by the client to its bare JID
> equal to sending it without 'to' attribute?
>
> I've looked at RFC 6120 § 8.1.1.1. and 10.3.3., but couldn't get an
> answer out.
>
I think § 10.3.3 is clear on this topic. I’d answer your question with „ye
Hello,
XEP-0033: Extended Stanza Addressing § 6 (8.) [1] says:
"Each 'bcc' recipient MUST receive only the associated with that addressee."
However Example 9. [2] sends the message to a BCC recipient, which contains all addresses except the BCC addressee itself.
I think Example 9 is w
Hi,
when using Java's SASL API [1], you would use the following to create a SASL client for DIGEST-MD5 authentication:
Sasl.createSaslClient("DIGEST-MD5", authzid, "xmpp", serverName, null, cbh);
The fourth parameter "serverName" will be used in the digest-uri
It's documented as [1]:
I think this is already covered by Example 195, isn't it? (and similarly 176, 190)
-- Christian
Gesendet: Dienstag, 17. Mai 2016 um 09:40 Uhr
Von: "Daniel Gultsch"
An: "XMPP Standards"
Betreff: [Standards] Notification of lost membership of non participants in MUC
I'm currently modif
Hi,
I've had a brief discussion [1] about how the fallback to IBB works in SI
filetransfer.
It's mentioned twice in XEP-0096 and it reads like a fallback to IBB is
intended to work but it lacks a proper description about how it actually works.
My interpretion is this:
1. Initiator initiat
Hi,
let me raise one concern, which I had while implementing RFC 7564 and 7613.
I’ve raised it already on this mailing list, but it got no attention.
Instead of changing RFC 7564 §7 from MUST to SHOULD, why not changing RFC 7613
§3.2.2 (and likely other Enforcement sections) to stick to the ord
Hi,
I had a small discussion recently about RFC 6120 § 3.3 Reconnection [1].
It states "It can happen that an XMPP server goes offline unexpectedly“… and
recommends a first reconnection after max. 60 seconds.
We considered this section to not fit the reality, because in reality it’s
rarely the
8 SE).
Java uses huge Unicode arrays internally to lookup the code point, I doubt that
there’s much room for optimization and even if, probably nobody cares when
saving a few nano seconds.
— Christian
> Am 23.12.2015 um 03:04 schrieb Sam Whited :
>
> On Mon, Dec 21, 2015 at 4:08 PM,
> Am 22.12.2015 um 01:50 schrieb Sam Whited :
>
> Another quick note:
>
> In your case folding
> (https://bitbucket.org/sco0ter/precis/src/ecd82b75f3611dcb37ee0fd8890bfaf02b5caf9f/src/main/java/rocks/xmpp/precis/PrecisProfile.java?at=master&fileviewer=file-view-default#PrecisProfile.java-511),
>
> Am 21.12.2015 um 22:05 schrieb Tom Worster :
>
> To what extent do you think we could combine our efforts on unit tests?
> Standard (or at least shared) test vectors would really help, given how hard
> it is for programers to decode the RFC texts.
>
Well… if there’s some XML (or other langu
> I'm curious, what made you decide to calculate the derived properties
> on prepare instead of precomputing them? Have you done any
> benchmarking of this? I'd love to see the performance difference
> between this way and pre-computing a big trie or something of derived
> properties.
Thanks for
Dear all,
I’ve been working on an open source Java implementation for the Precis
framework since a few weeks and I'd finally like to share it with you:
https://bitbucket.org/sco0ter/precis
It supports the core Precis framework (RFC 7564), as well as the username and
opaque string profiles (RFC
Anybody has a clue about this? Thanks.
> Am 21.11.2015 um 14:12 schrieb Christian Schudt :
>
> Hi,
>
> can you please help answering the following question:
>
> When doing enforcement of a string of the UsernameCaseMappedProfile as per
> RFC 7613 § 3.2.2 and th
Hi,
can you please help answering the following question:
When doing enforcement of a string of the UsernameCaseMappedProfile as per RFC
7613 § 3.2.2 and the string contains U+212B (ANGSTROM SIGN), I would first do
the preparation and it would be disallowed by the IdentifierClass because it
ha
Hello,
> 1. What software has implemented XEP-0301? Please note that the protocol
> must be implemented in at least two separate codebases (at least one of which
> must be free or open-source software) in order to advance from Draft to
> Final. [1]
I’ve implemented it in Babbler Java client lib
While BOSH has it's own acknowledgement mechanism, there are still some subtle
differences when it comes to resumption:
With resumption you don't need to:
- re-request the roster
- resend presence
- re-establish state information (as mentioned in XEP-0198)
I see performance benefits (less HTTP qu
My explanation: Most developers just don't want to write specifications. They
don't consider it to be their job. Similar like they also shy at writing
documentation or even comments. Developers are lazy in this aspect.
Developers just want to code, fix bugs, create a nice UI, apply logical
thin
> Please discuss. I think the outcome of that discussion probably affects what
> should go into the suites.
I never really understood the purpose of these "suites", nor did I feel the XSF
is pushing them (last one is Deferred).
Nonetheless, here are my thoughts (assuming it should be some kind
> Hmm, not sure if you can translate this to xep191. What happens if a
> xep191 client removes a jid entry which was added by the server because
> the jid is the 'enemies' group?
The server should map in both ways, i.e. reflect changes to XEP-0191 into the
privacy lists, and also reflect changes
> http://mail.jabber.org/pipermail/standards/2014-December/029430.html
> The problem is that it's unclear (to me) how to map XEP-0016 rules that
> block some kinds of stanzas but not others.
If that's all, I think XEP-0191 §5 only lacks a more precise mapping of 0016
privacy list to block list.
I agree to Florian, Goffi etc...
XEP-0016 is complex, but powerful. I see no reason to deprecate it, just
because there's a similar XEP (0191). In our company we've had an requirement
to be invisible to certain roster groups. This is not solvable with other XEPs.
The other mentioned use case -b
> Seems like I'm constantly repeating on the list...
> Do those implementation resolve the following problems:
> 1) MUC friendly
> 2) Offline support
>
> From what I know Jingle FT specs don't provide a solution for those
> problems.
Funny, I've brought up exactly these two problems, too:
http://
Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov :
> Thu, 24 Sep 2015 13:10:44 +0300
> PG Stath wrote:
>
>> In general I think that XMPP might be missing developers not because
>> features are missing but because of non compatible extensions lists
>> and extension implementations among different
Hi,
> I get your point. But it feels wrong to define nearly identical
> extension elements in two XEPs. The author of xep334, Matthew Wild,
> already expressed his willingness to change xep334 so that it can be
> re-used in xep280. Therefore I'm all for changing xep334, then issue a
> last call f
Hi,
the wording is very inconsistent.
It sometimes says delete/deletion, sometimes remove/removal, even when
referring to the same use case ("removal request“, "deletion request“).
Even the namespace (delete) is different from the element name (remove).
I suggest to clean this up. I am no nati
Hi,
What about a client sending delayed stanzas upon stream resumption? Should it
add Delayed Delivery as well?
E.g. client sends a message, but no ack is received, so it stays in the
"unacknowledged queue". Eventually client detects a broken connection,
reconnects and resends the unacknowledg
I think this has already been discussed once, but wouldn't it be more intuitive
to use IQ semantics for this instead of sending a message which confirms the
(de)activation?
CSI feels similar to XEP-0186: Invisible Command and it uses IQ as well. I'd
just appreciate consistency among XEPs and CS
Hi,
there's another related XEP: XEP-0137: Publishing Stream Initiation Requests.
I am not sure if Jingle File Transfer should cover the following use cases as
well, but what I am reading and hearing more and more (in this list, in my
company, in forums) are the following two requirements:
1)
Hi,
> the question of whether we need a new mobile XEP, or just update the old one
> (potentially with entirely new text).
> I'd be very interested in hearing any opinions on this one.
I'd prefer to have an updated version of XEP-0286, just to keep it simple.
Particularly because some parts of
Hi,
> Letting the component act as a Jingle File Transfer receiver was my original
> idea as well. However if you try to find any jingle ft implementations you'll
> see that there basically aren't any. (To my knowledge there is Gajim,
> Conversations and Swift (beta) and Swift is currently inco
Hi,
I agree that XMPP is lacking such a specification („MUC File Transfer“,
„Offline File Transfer“).
Maybe it’s even better, if the client and server could negotiate the transport
method first, so that the client could choose between „HTTP Upload“, "SOCKS 5
Upload (XEP-0065)“ or „In-Band Uplo
> For me personally, the contra-Nonza arguments did not convince me. It
> appears that nothing in the specification prevents you from using Nonzas
> after resource binding with BOSH. XEP-206 3. only says "SHOULD contain".
> I also don't see why they would introduce "a bunch of conceptual and
> imp
Betreff: Re: [Standards] DRAFT: XEP-0319 (Last User Interaction in Presence)
Hi Christian, hi Kim,
On Fri, Apr 10, 2015 at 2:05 PM, Kim Alvefur wrote:On 2015-04-09
21:54, Christian Schudt wrote:
> 2. XEP-0256 should be updated (Appendix A): „superseded by XEP-0319“. Or will
> it be
Sounds good to me… except XEP-0045 still uses „MUST NOT“ for groupchat-type in
private occupant-to-occupant messages.
Might be inconsistent wording across the two specs.
Furthermore I can understand the issue raised in your linked post [1]: In
software an empty String and a null reference (here:
Hi,
I think Variant 1 violates XEP-0045: When receiving a „request“ message from an
occupant in a MUC room (type=groupchat), the receiver would send a receipt to
the sender directly, not to the MUC room, by simply sending it to the „from“
attribute of the request, which is a full JID.
It’s bas
Hi,
while implementing this, I’ve recognized a few issues:
1. It should link to XEP-0012 and clarify it’s correlation to "4. Online User
Query“. I guess if a client queries an idle client via XEP-0012 it should yield
the same result (in seconds) as the idle time broadcast via XEP-0319, no? So
I appreciate the idea, that it should advance to Draft.
I’ve implemented it in Openfire and didn’t saw any major flaws in the spec.
However, while I did, I often thought „why is it restricted to chat-type only?“.
I think enhancing it to „normal“ messages is a good idea, e.g. to let
carbons-enabl
Ok, makes sense as well.
I conclude from this discussion, that there are no extension protocols which
MUST be coupled with another one in service discovery (i.e. if A then B),
although for some they SHOULD (e.g. if urn:xmpp:jingle:transports:ibb:1 then
urn:xmpp:jingle:1).
Thanks.
-Christian
Thanks Florian, generally I agree, but please read my answers below.
>> urn:xmpp:carbons:2 ==> urn:xmpp:forward:0
>> http://jabber.org/protocol/si/profile/file-transfer ==>
>> http://jabber.org/protocol/si
>> http://jabber.org/protocol/caps ==> http://jabber.org/protocol/disco#info
>> http://jab
Hi all,
there are several features/extension protocols, which are dependent on others,
e.g.
urn:xmpp:carbons:2 ==> urn:xmpp:forward:0
http://jabber.org/protocol/si/profile/file-transfer ==>
http://jabber.org/protocol/si
http://jabber.org/protocol/caps ==> http://jabber.org/protocol/disco#info
h
Hallo,
XEP-0022 Message Events has been obsoleted and says:
Note: More modern protocol extensions for this functionality have been defined
in Chat State Notifications (XEP-0085) [1] for the composing and offline events
and in Message Delivery Receipts (XEP-0184) [2] for the delivered and displa
I have interpreted and implemented it as „normal", too.
I have also suggested it to be more clear a year ago here, but unfortunately
nobody cared:
http://mail.jabber.org/pipermail/standards/2014-January/028479.html
- Christian
Am 28.02.2015 um 14:43 schrieb Daniele Ricci :
> Thanks Kurt,
> I c
Dave, maybe could you (or somebody else) elaborate on the "shortcomings" and
the "different demands of things like buddycloud" you have discussed for those
who didn't attend the summit.
Also what's so bad about multiple parties chatting via a third party chat
service (your 2nd use case)?
For m
I agree that the example might be confusing. But the text reads ok for me. Actually the whole section boils down to:
"Just make sure to produce valid XML".
For me this is self-evident and actually shouldn't require further detailed explanation and examples.
Gesendet: Dienstag, 03. Februar
I agree, Strophe.js behaves incorrect.
Examples are provided in http://xmpp.org/rfcs/rfc6120.html#streams-ns-content
"both styles are acceptable since they are semantically equivalent"
Even the „stream“ prefix could be any other, but most server implementation
probably can’t deal with it.
- Chr
Hi Michael,
> So my question is: What is actually the problem with the latest XMPP
> end-to-end encryption and signing approaches and why isn’t it safe against
> malicious server operators and sniffing of direct client-to-client
> transmissions? And is there anything else I should know?
The "
I hope I didn’t ask dumb questions...
An answer would be appreciated! Thanks.
Christian
Am 11.01.2015 um 20:08 schrieb Christian Schudt :
> Thanks for your answer!
>
> I’ve had a lengthy discussion with another developer about „one-to-one chat
> sessions“ in general and w
Thanks for your answer!
I’ve had a lengthy discussion with another developer about „one-to-one chat
sessions“ in general and we are having difficulties to understand what is
really meant by this term.
We’ve read the following documents/paragraphs which involve „chat sessions“:
http://xmpp.org/
Hello,
by accident I stumbled over RFC 7395 (XMPP over WebSockets) [1]. I think last
time I checked there were only draft versions of this document (although I
think it must be after the document’s release date, strange..).
I also can’t remember much discussion of this document on this mailing
Hi,
I am confused about the proper handling of „one-to-one chat sessions“.
Specifically the following documents partially contradict each other:
http://xmpp.org/extensions/xep-0201.html#chat
http://xmpp.org/extensions/xep-0085.html#bizrules-threads
XEP-0201 says, a client SHOULD NOT destroy a t
+1
Seems reasonably for me.
Also this line seems weird for me:
> If the foregoing suggestions are followed, the user will appear offline to
> the contact.
I think it should be „the contact will appear offline to the user“, but it
could be removed anyway, if Sam’s suggestion takes place.
Broa
Hi,
> Receiving can mean either the
> user went idle $TIME_STANZA_SENT - 903 seconds or user went offline at that
> point. You can’t know it solely based on this stanza. You’d require further
> presence information to resolve the semantic overload.
In my opinion this isn't hard to distingish.
1 - 100 of 167 matches
Mail list logo
