spam also.
Best regards,
Peter
Från: Peter Waher<mailto:peterwa...@hotmail.com>
Skickat: den 7 mars 2023 11:44
Till: standards@xmpp.org<mailto:standards@xmpp.org>
Ämne: RE: Proposal against spam
Hello
We use the following simple rules in our clients to avoid spam:
1. Normal and C
Hello
We use the following simple rules in our clients to avoid spam:
1. Normal and Chat Messages received from JIDS without an approved presence
subscription are automatically rejected, unless there’s a valid exception
registered in the client. (I.e. a white-list instead of a black-list is
the added
bytes each time an entity connects. Also, a service discovery mechanism, would
allow an entity to query all participants in a route, to figure out what the
limitations are along that particular route.
Best regards,
Peter Waher
___
Standards mai
until October 5. Perhaps the XSF should prepare
a statement and send it to them?
Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Hello Paul
https://gitlab.com/IEEE-SA/XMPPI/IoT/-/blob/master/E2E.md
As you are asking about E2EE methods, I´d like to add a reference to a proposal
we’ve developed within IEEE, suitable both for things and more powerful
endpoints.
Best regards,
Peter Waher
Hi List,
I see there have been
://gitlab.com/IEEE-SA/XMPPI/IoT
Best regards,
Peter Waher
--
> Hi everyone!
>
> The Sprint in Berlin was great and it was huge fun meeting so many
> developers (and users as well!) in person. There was a ton of
> interesting discussions around OMEMO and other
, and the need to validate CSR claims properly.
https://xmpp.org/extensions/xep-0348.html
Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Hello
Tried to join the IETF 102 meeting, but it said it has concluded. It is now
July 19 (”tomorrow, as seen on the 18th”), 13:33 UTC. When is the next meeting?
Best regards,
Peter Waher
> Hi folks, the first meeting of the Messaging Layer Security working
> group will be held tomor
) lacks/has certain features.
Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Hello Florian
> On 14.10.2017 11:59, Peter Waher wrote:
> > Hello
> >
> > A year and a half ago I proposed a XEP: "Content Types in Messages" [1],
> > solving the issue of describing and annotating what type of content is
> > sent in messages. At the
to be able to annotate content
in messages, and also to be able to transmit multiple representations of the
same content in the same message.
Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
U
it's possible to include multiple different types of contents in the same
message, all to increase interoperability. It is possible to send the same
message using different content types, and allow the receiver to select which
best fits its capabilities.
Best regards,
Peter Waher
___
Just because you don't want do communicate Markdown, should it be permissible
for you to block others who wants to? And a followup: Those that want to
communicate Markdown, how should they find an interoperable manner to do so?
Inside, or outside of the XSF?
Best regards,
Peter Waher
> Moving
themselves.
Best regards,
Peter Waher
> Hi Standards,
>
> I came across 0337 and I like the idea. Reading the security
> considerations, it is said in [7.3.2]:
>
> """
> [..] even more care should be taken to log only information that can be
> publishe
using a paradigm that matches what
is elsewhere used on the internet (Content Types). Why invent something new,
and not renew the application of the original proposal? And if there's
something missing, the proposal can be updated, and the author list increased.
Best regards,
Peter Waher
[
Hello
Are you aware of any interoperability tools for XMPP servers? Tools that check
how well XMPP servers conform to the RFCs and/or selected XEPs?
Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo
Hello Matthew
Your proposal is reminiscent of XEP-0332: HTTP over XMPP. If you're interested,
you can check it out here:
https://xmpp.org/extensions/xep-0332.html
Best regards,
Peter Waher
> Whilst I'm here, it would be remiss not to highlight some sensational
> work just re
later?
Best regards,
Peter Waher
Ref:
https://www.wired.com/2017/02/common-cryptographic-tool-turns-majorly-insecure/
[https://www.wired.com/wp-content/uploads/2017/02/Cryptography-2x1-1200x630-e1487801673377.jpg]<https://www.wired.com/2017/02/common-cryptographic-tool-turns-majorly-insecure/&
push
changes in different PRs. The Windows client I use collects all commits I make
into one PR.
Best regards,
Peter Waher
Från: Sam Whited<mailto:notificati...@github.com>
Skickat: den 17 januari 2017 18:02
Till: xsf/xeps<mailto:x...@noreply.github.com>
Kopia: Subscribed<mailto:sub
Hello Peter
I'm travelling at the moment. Let's discuss this XEP in the IoT SIG, along the
others, in turn.
Best regards,
Peter
Från: Peter Saint-Andre
Skickat: den 6 januari 2017 17:00:29
Till: XMPP Standards
Kopia: yusuke@toshiba.co.jp; Peter
anyway.
http://www.slideshare.net/peterwaher/iot-harmonization-using-xmpp
http://www.slideshare.net/peterwaher/xmpp-iot-sensor-data-xep0323
Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Hello Florian
Thanks for the mail, and thanks for sharing your experiences. I’ll try to
answer your comments and questions, one at a time.
> Now, one key issue that the XEPs try to solve is that a thing ? think of
> the light-bulb next to you ? can not decide on its own if another thing
> is his
ng?
·Is there an interest by any other to co-author? Any preferences
regarding to sections?
Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
rent state of
> play. It seems to me we have a number of IoT-related XEPs and
> proposals - due to a huge amount of effort by Peter Waher - but its
> not clear to me which of these have any traction. It would be great if
> people working on IoT (and using XMPP) could say which of these
t to have an alternative for
those that want to use Signal as well. It’s currently being tested by both
Facebook and WhatsApp, and is recommended by several notable people.
Best regards,
Peter Waher
___
Standards mailing list
Info: h
the account.
Another way, more suitable for controlled creation of accounts by machines (for
instance, for IoT), is outlined in XEP-0348, and is based on signing IBR forms,
using some other credentials that can be used to distinguish approved account
creators from others.
Best regards,
Peter
site.
Best regards,
Peter Waher
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
ne apart from the sender and
> > receiver. Best regards,Peter Waher
>
> XEP 0363 addresses this explicitly:
>
> > Do not provide any kind of access control or security beyond Transport
> > Layer Security in form of HTTPS and long random pathes that are
> > impossib
includes a method for integrating the content into the
chat sessions using XHTML-IM, which is what I'm looking for. Thanks.
Best regards,Peter Waher
>
> Hello,
>
> Jingle file transfer could be used for that with and "xmpp:" URI, but we
> still
> don't
Hello Nick
Thanks for your response. Uploading the image to the XMPP server also counts as
uploading it to a third party. The image should be considered private, not
accessble to anyone apart from the sender and receiver.
Best regards,Peter Waher
> >That would require uploading the imag
display the file.
>
That would require uploading the image to a third party, in this case an HTTP
server. That is undesireable. The image should be considered private and shared
only between the two communicating parties.
I conc
P-0332), if both are supported on both clients. XHTML-IM
allows me to include an tag with a link to the image using the httpx URI
scheme (HTTP over XMPP). This scheme defines where the image can be gotten, and
negotiates how the image is to be transferred. What I wanted to know is, are
there any oth
inserting them in the current chat.
Best regards,
Peter Waher
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
r feedback to the user why the
value of a field is invalid, allowing enabling anddisabling of fields and
flagging fields to be "unknown" or "undefined", as is the case when editing
multiple objects at the same time, having different field values.
Best regards,
Peter Wa
dding, updating, removing fields) etc.
Best regards,
Peter Waher
> Date: Wed, 3 Feb 2016 10:32:53 -0500
> From: Stephen Paul Weber
> To: standards@xmpp.org
> Subject: [Standards] Multi-stage registrations
> Message-ID: <20160203153253.GA3003@singpolyma-liberty>
> Content-
Hello Dumaine
Thanks for your input. You'll see that the proposal I sent to the editor last
week will suit your needs.
Best regards,
Peter Waher
___
Standards mailing list
Info: http://mail.jabbe
users want a markdown syntax
in the chat client, then they would have to add a markdown parser, regardless
if it's sent or not over XMPP. If users don't want to use markdown syntax,
there's no need to worry. The only reason when
arding the format of
the message body. If it is non-empty, it contains an alternative, a formatted
version of the plain text message body.
Would that be an approach that the council would accept?
Best regards,
Peter Waher
_
;s
going to block any such proposal, I'll not send one. But if the coucil sees
some value for the XSF in supporting interoperability of this kind, I'll of
course send a proposal. If you Ashley want to contribute, we can write it
together.
Best regards,
Peter Waher
plain text body (as in the XHTML-case). In that
case, there's Always a simple text version available for clients not
understanding the content type used.
Best regards,
Peter Waher
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
n clients that desire
to communicate using markdown? That is, should the XSF promote a standardized
manner to communicate using markdown, or force everybody to use proprietary
means? (The aim of course, is not to standardize markdown.)
Best regards,
Peter Waher
>
>
>
able, as if a
non-markdown-compliant client sending a message to a markdown-compliant client.
Such text should be displayed as normal text.
>
> I do not see any reason to wrap markdown in an extra element like it is
> done with XHTML-IM. I would simply put it into .
That would force c
cases where the markdown
might be of interest in itself. And converting XHTML-IM back to markdown on the
receiving end is not as simple as creating XHTML-IM from markdown.
Best regards,
Peter Waher
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
ormal message, I would like to
mark it as such and provide an unformatted text version (with any markdown
formats removed) as well, much like how HTML-IM works.
Best regards,
Peter Waher
___
Standards mailing
MQTT not being federated is also a very important point:
XMPP has something very valuable, in that it is federated, which allows it to
create gobally scalable interconnected infrastructures.
I hope you reconsider, given my responses, and approve of the proposal going to
experimental stage.
Best
other things, assuring that transactions are managed properly. In
> transactions there must be no unknown states, and they must be delivered
> exactly once. Another use case, if for building multi-client FIFO queues.
> I've built the proposal in such a way as to become a generic tool
s of a degree. Receiving multiple messages by
mistake would cause a state that the receiver cannot recover from.
In general, any type of event that needs to be counted, are not idempotent.
I hope you reconsider and allow the QoS proposal to pass to the experimental
stage.
Best regards
Hello Dave
Thanks for your comments. I've responded to your concerns below:
> My initial reaction to this is that it's not providing anything beyond the
> state of the art, and it implies that delivery is highly
> unreliable (and suited to flood messaging), which is rather worrying. Not
> rea
an be used on-top of
an already established technology, such as IBR that is widely supported already.
Best regards,
Peter Waher
>
> On 15.11.2015 17:18, Peter Waher wrote:
> > Hello Florian
> >
> > XEP-0158 is not a good idea for Three reasons: First, CAPTCHA is
ve to implement support for other protocols, such
as HTTP, to fetch images (or audio/video), which will make the solution
impractical (or even impossible) on devices with limited Resources.
Best regards,
Peter Waher
> Deprecating IBR is masking the SPAM problem but not solving it. I also
>
ism where
some operator/configurator involvement is necessary. But instead of configuring
N accounts (say 1000), it is reduced to configuring 1 account (the account
creation account).
Best regards,
Peter Waher
rtain number of accounts).
Perhaps an overhaul of this process, or a new process that permits automatic
Creation of accounts in a controlled manner, is better than just deprecating
IBR without providing an alternative.
Best regards,
Peter Waher
> So, something for next Council to ponder:
>
curve
cryptography? Does anyone know to which extent there are brokers that support
such level of cryptography? Or to what extent it is even legal to use such
level of cryptography, and where?
Best regards,
Peter Waher
[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf
[2]
https
Hello Dave.
> On 30 June 2015 at 18:40, Peter Waher < <mailto:peter.wa...@clayster.com>
> peter.wa...@clayster.com> wrote:
>Thanks for your input. For small devices, that do not wish to (or cannot)
>perform a dynamic handshake, there's the concept of quick c
ewall, like the case where
you have your own personal credit-card sized server (RaspberryPi2, Cubieboard,
Tonido, etc.) at home, behind the firewall. You can still access content over
XMPP, and in web clients that understand the proposed httpx URI scheme.
Best regards,
Peter Waher
Från:
service can be used, or integration with sipub, ibb and/or jingle as
well, depending on capabilities.
Best regards,
Peter Waher
Från: Daniel Gultsch [mailto:dan...@gultsch.de]
Skickat: den 28 juni 2015 09:26
Till: XMPP Standards
Ämne: [Standards] Request HTTP upload slots over XMPP
Hi
e, as described
earlier, perhaps by a more powerful device, or out-of-band, by manual
configuration of the server.
Best regards,
Peter Waher
-Ursprungligt meddelande-
Från: Rick van Rein [mailto:r...@openfortress.nl]
Skickat: den 26 juni 2015 01:42
Till: XMPP Standards
Ämne: [Standards] XEP
have that implemented. Why should they have to
implement yet another extension?
Another benefit of using XEP-0332, is that resources can be linked to using
URLs (using the httpx uri scheme), which allows for embedding micro formats,
meta data, links, etc., into REST responses, something that
Thanks Ash & Peter. I’ve resent the mail now.
Concerning spam: Is it only the editor’s list that is affected? How is spam
kept away from the standards and iot lists?
Best regards,
Peter Waher
From: Ashley Ward [mailto:ashley.w...@surevine.com]
Sent: den 21 november 2014 13:10
To:
in case my evil headers are accepted there.)
Best regards,
Peter Waher
e the corresponding XEPs and answer all feedback
in a couple of weeks. I hope that is OK. Sorry again for the delay, and thanks
for the effort and all input.
Best regards,
Peter Waher
y-pub stuff"?
Best regards,
Peter Waher
-Original Message-
From: Philipp Hancke [mailto:fi...@goodadvice.pages.de]
Sent: den 21 augusti 2014 07:58
To: standards@xmpp.org
Subject: Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
Am 13.08.2014 18:12, schrieb XMPP Extensi
change this, since there
are various distributed solutions already in the field, and I would like to
avoid making breaking changes, unless they improve or add functionality.
But the comment still raises a valid point: Should the XSF maintain a list of
(commonly) used attributes and attribute names to promote reuse of the same?
Best regards,
Peter Waher
iple resource binding
On 7/1/14, 9:34 AM, Peter Waher wrote:
> Hello
>
> A short question, hopefully somebody knows: Does XMPP, according to
> RFC 6120, allow for multiple resource names to be used (or multiple
> resource binding to be made) over the same connection? Or doe
this mean this is not
possible, or does it mean it is done differently? Searched RFC 6120, but didn't
find anything about multiple resources.
Best regards,
Peter Waher
y they shouldn't be interested in inviting you. The groups
work separately though, so multi-screen does not use XMPP specifically, and the
cloud TF (XMPP) does not use interfaces from the other interfaces explicitly,
etc.
Best regards,
Peter Waher
-Original Message-
From: St
of a form, but not the stanza
carrying the form, even though the form type and to address are included in the
signature. So part of the stanza carrying the form is also signed.
>As such, I'm inclined to vote -1 for Signing Forms as-is in preference that we
>expand and fix XEP-
cha:signature:oauth1
Generic form signature:
urn:xmpp:xdata:signature:oauth1
Similarly, form types for MUC configuration, etc. could have their FORM_TYPE
suffixed by “:signature:oauth1”.
Would that work?
I have not reviewed this document in terms of security.
On 13 May 2014 13:58, Peter Waher
mai
like to include as well?
Best regards,
Peter Waher
From: Teemu Väisänen [mailto:uol...@gmail.com]
Sent: den 23 april 2014 05:33
To: XMPP Standards
Subject: Re: [Standards] UPDATED: XEP-0325 (Internet of Things - Control)
Hi Peter.
That description looks like the information goes from sensors to
e logical next step to write that document now... I'll
write it and publish it to the list. Any comments and suggestions are welcome.
Best regards,
Peter Waher
-Original Message-
From: Teemu Väisänen [mailto:uol...@gmail.com]
Sent: den 20 april 2014 14:34
To: XMPP Standar
Hello Philipp & community.
Thanks a lot for your input. It helped me solve this issue finally. :) Thanks
for your time.
For those with similar problems, or for the record if somebody has this problem
in the future, I'll list what was wrong.
Best regards,
Peter Waher
>> However
that roster handling is optional before sending a presence
subscription (and therefore must not affect if a presence subscription is
delivered or not)? But I cannot see how this roster handling should be applied
anyway, in the component case, since it seems to be a client-to-server
protocol. Have I misunderstood?
Best regards,
Peter Waher
can initiate communication from a server
component, it would be a very good option to use in the IoT Discovery XEP
proposal and the Provisioning XEP.
Best regards,
Peter Waher
Hello Dave
Thanks a lot for your answers.
Best regards,
Peter Waher
From: Dave Cridland [mailto:d...@cridland.net]
Sent: den 2 april 2014 16:38
To: XMPP Standards
Subject: Re: [Standards] Jabber Components (XEP-0114) in federated networks
On 2 April 2014 20:25, Peter Waher
mailto:peter.wa
s to be, which makes MITM attacks quite easy. And since
you get such a direct access to the server, it looks very much like a backdoor
to me.
Best regards,
Peter Waher
to which it is not
connected, but with which the first server is federated?
Best regards,
Peter Waher
XEP-0114 just terminates after the handshake element.
Best regards,
Peter Waher
to the one proposed
above. There, an account holder is given a certain number of API calls per time
unit, which it can then distribute among its users. The above method would do
something similar: An account holder would be given a certain number of
accounts that can be created, and can distribute this right to its users
(Thing).
Best regards,
Peter Waher
gs) opt-in for that service using XEP-0077 is a common
>historical pattern.
Not sure exactly what you mean here. In what sense do you see XEP-0077 to be
used in this proposal, apart from IBR?
Best regards,
Peter Waher
ll also give us some feedback if this can be
said to be the main option, or a supplementary option to use.
Ok?
Another concern is the following description in the introduction: "While this
component protocol is minimal and will probably be superseded by a more
comprehensive component protocol at some point".
Do you know anything about such plans for a future more comprehensive component
protocol?
Best regards,
Peter Waher
n have control of how many
accounts can be created, and monitor how many have been created. And it allows
them to create devices without preprogrammed JID:s.
What do you think about such an approach?
Best regards,
Peter Waher
-Original Message-
From: Peter Saint-Andre [mailto:stpe
XMPP that does not use XEP-0055), do you want me to
rephrase this section to discuss how to perform a "query" instead of a "search"?
Best regards,
Peter Waher
Hello Ivan.
Thanks for your question. As the XEP has been written it says “This can be done
using one of several methods:”, that is, one of the options is sufficient. But
the XEP lists different options (i.e. strategies) that might be useful in
different scenarios.
Best regards,
Peter Waher
at might be a simple search-replace.
Not really. The examples, are only examples. Now, with the hardcoded step
discovery@domain, is just a JID, like any other.
> section 3.11:
> the comment from 3.5 applies here as well.
Hardcoded accounts have been removed.
> example 36 closes update instead of search.
Updated.
Best regards,
Peter Waher
st regards,
Peter Waher
Hello Tobias
Thanks a lot. This is exactly what I need.
Best regards,
Peter Waher
From: Tobias Markmann [mailto:tmarkm...@googlemail.com]
Sent: den 3 mars 2014 14:30
To: XMPP Standards
Subject: Re: [Standards] Last connection time of friend
Hi Peter,
On 2 Mar 2014 20:10, "Peter
Hello Ben
Thanks for your input. You're correct that you can always send the probe. What
worries me is how many servers will actually route it. It only says servers
SHOULD route the probe in RFC 6121.
How would you do this use case better, than by sending a probe?
Best regards,
Peter
they cannot connect is to look at
the last time they connected (or disconnected). It’s very different if it was
only an hour ago, or a month ago.
Best regards,
Peter Waher
From: Steven Lloyd Watkin [mailto:ll...@evilprofessor.co.uk]
Sent: den 3 mars 2014 13:54
To: XMPP Standards
Subject: Re
networks. Have to do some experiments to find
out how it works out. Perhaps the explanation for why this should not be done
by clients can be revised in the RFC?
Best regards,
Peter Waher
From: Dave Cridland [mailto:d...@cridland.net]
Sent: den 2 mars 2014 16:21
To: XMPP Standards
Subject: Re: [S
Hello Philipp
Thanks for the quick reply. Should have been able to find this myself, but
missed it.
Best regards,
Peter Waher
-Original Message-
From: Philipp Hancke [mailto:fi...@goodadvice.pages.de]
Sent: den 2 mars 2014 16:17
To: standards@xmpp.org
Subject: Re: [Standards] Last
Hello
Is there a means to figure out the last time a friend connected to its XMPP
server? Can you ask the server hosting the user account for last connection
time? (You might not have been online to receive the presence message when the
user went offline.)
Best regards,
Peter Waher
with similar ideas.
Would this be a good idea or do you already now see a problem with this
approach?
Best regards,
Peter Waher
age-113
But I am really wondering which servers and/or clients support this?
On 21/02/2014 18:06, Peter Waher wrote:
> Hello
>
> Is there a means to ask a contact to automatically redirect to another
> JID for further communication with the friend? Say you have a JID
> badname@ol
hip): "My JID is being changed to JID2", or "Connection to
JID2 for future communication with me."
Best regards,
Peter Waher
scribed by the timestamp, and here you see the grouping feature
of the timestamp element.
Best regards,
Peter Waher
-Original Message-
From: Joakim Eriksson [mailto:joak...@sics.se]
Sent: den 19 januari 2014 17:44
To: XMPP Standards
Subject: [Standards] XEP-323 timestamp
I think that the XEP
f
you have any further comments on this or the other XEP:s, please feel free to
mail them at any time. I've cc:ed the standards mailing list, since I believe
discussions about the individual XEP:s better belong there.
Best regards,
Peter Waher
blished in normal order on the
standards list for anybody to comment on.
Best regards,
Peter Waher
15 januari 2014 15:39
To: Peter Waher; XMPP Standards
Cc: joak...@sics.se
Subject: Re: PS: [Standards] XEP-323 vs XEP-325
I almost would say the only important factor is interoperability ;-) Well also
that it is suitable for the IoT devices that we believe is going to make use of
XMPP. In my pers
--IoT-Interoperability.html
Best regards,
Peter Waher
From: Peter Waher
Sent: den 15 januari 2014 14:07
To: 'Joakim Eriksson'; XMPP Standards
Subject: RE: [Standards] XEP-323 vs XEP-325
Hello Joakim
I'll address your concerns one at a time:
So a resource limited devi
account aspects important for both.
Best regards,
Peter Waher
Peter Waher skrev 2014-01-15 16:22:
> Hello Joakim
>
> The control form provides means to publish limits for control values. See
> §3.3.1 for examples.
>
> Best regards,
> Peter Waher
>
> -Orig
1 - 100 of 192 matches
Mail list logo
