Re: [Standards] Proposal against spam

[Peter Waher]

To that, I might also add:


  1.  Nuicanse presence subscriptions can be blocked/reported using existing 
XEPs
  2.  In our most secure implementations, we also include additional legal 
identity and public cryptographic keys in presence subscriptions, allowing for 
E2EE as a mechanism to avoid 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 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 
employed).
  2.  Group Chat Messages from Groups not actively joined are also 
automatically rejected.

While (1) is somewhat more restrictive than what the RFCs permit, it works for 
all our use cases. In the cases we need unsolicited messages from sources not 
in our roster, or without active presence subscriptions, we register explicit 
validation handlers. These can algorithmically approve a message to be 
delivered through the client. Such a solution (internal filters) avoid routing 
messages through external filters (that would become vulnerable from a privacy 
and security point of view).

Best regards,
Peter


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposal against spam

[Peter Waher]

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 
employed).
  2.  Group Chat Messages from Groups not actively joined are also 
automatically rejected.

While (1) is somewhat more restrictive than what the RFCs permit, it works for 
all our use cases. In the cases we need unsolicited messages from sources not 
in our roster, or without active presence subscriptions, we register explicit 
validation handlers. These can algorithmically approve a message to be 
delivered through the client. Such a solution (internal filters) avoid routing 
messages through external filters (that would become vulnerable from a privacy 
and security point of view).

Best regards,
Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

[Peter Waher]

Hello

> This specification defines a way for an XMPP entity to announce the
limits it will enforce for data received on a stream.
>
> URL: https://xmpp.org/extensions/inbox/xep-sla.html

This is a sorely needed extension. However, the proposal does not solve the 
more general problem of knowing the limitations when you communicate with 
another, only the size and time limits between immediately connected entities. 
A sender (client1) who needs to send something to another client (client2) 
passes one or two brokers (broker[1, broker2]), each one in this path might 
have different size limitations. A notification in the stream element does not 
resolve this more general problem. Furthermore, being constantly advertised in 
every request, creates a lot of extra bytes being communicated, with not added 
value, as the information is only needed once per limitation (best case).

Would it not be better with a statement in a service discovery response? There, 
each server/component/client can declare their limitations. Any change in 
limitation would change the hash in entities capabilities, which is already 
sent. So a change would be detected by all participants, without 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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] How does the proposed Russian IT law affect use of XMPP in Russia?

[Peter Waher]

Hello

Just became aware of a new proposed IT law in Russia, that might affect use of 
XMPP in Russia:

https://www.internetsociety.org/news/statements/2020/internet-society-russias-proposal-would-weaken-the-internet-make-it-less-secure/

https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/

As an XMPP client is only connected to its broker, and external entities cannot 
deduce what final endpoints the client is communicating with, XMPP could be 
said to “hide” the name of the destination in communication from outside 
viewers. Not sure if the law explicitly references protocols such as HTTP, DNS 
over HTTPS, etc., (which would include BOSH) or if it is more general.

Any ideas from the community (Russian community members?) how such a proposed 
law would affect the legality of using XMPP in Russia?

The public can return feedback 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
___

Re: [Standards] On Stanza/Element signing

[Peter Waher]

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 past activities around creating signatures for
stanzas/elements.

There are two deferred, competing proposals (XEP-0274: Design
Considerations for Digital Signatures in XMPP ([1]) & XEP-0285:
Encapsulating Digital Signatures in XMPP ([2])).

Winfried Tilanus very recently hinted towards XAdES as another signature
standard that could be applied to XMPP ([3]).

I recently looked into xmlsec and canonicalized XML via C14N11 but I'd
like to ask if anyone has experience with creating signatures of stanza
contents and sharing signed contents over XMPP. Which mechanisms are you
using? Are you using one of the XEPs mentioned above? If not, why not?
What tooling do you use to overcome the problems of signed XML?

Happy Hacking!

Paul

[1]: https://xmpp.org/extensions/xep-0274.html
[2]: https://xmpp.org/extensions/xep-0285.html
[3]: https://mail.jabber.org/pipermail/standards/2020-August/037694.html



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stanza Content Encryption

[Peter Waher]

Hello Paul, and those in the community interested in end-to-end encryption of 
stanzas.

Within the IEEE IoT Harmonization effort, there is a mechanism to E2E-encrypt 
stanzas in XMPP:
https://gitlab.com/IEEE-SA/XMPPI/IoT/blob/master/E2E.md

Site for the IEEE IoT Harmonization project:
https://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 stuff, as well as some
> productive coding (and Mate!).
>
> I took the opportunity to once again start a discussion around partial
> stanza encryption. The results have been collected in the XMPP wiki:
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.xmpp.org%2Fweb%2FStanza_encryptiondata=02%>
>  
> 7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=YqVBLurjKA1xIqjIMqKweWXhm6hhk%2F7cdLfpwkiyOjg%3Dreserved=0<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.xmpp.org%2Fweb%2FStanza_encryptiondata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=YqVBLurjKA1xIqjIMqKweWXhm6hhk%2F7cdLfpwkiyOjg%3Dreserved=0>
>
> The ultimate goal is to create a ProtoXEP along with some experimental
> implementations, so we can finally start to gather some experience on
> this unexplored topic. I know there be dragons and we should carefully
> think about rules to prevent evil things from happening, but we also
> have to get started, as I think this topic has been postponed for all
> too long.
>
> The specification is worked on on Github and a rendered version can be
> found below (this is all what I came up with while on my train home).
> The purpose of this mail is to get some first feedback and make people
> aware about the work, so they can get involved in the process :)
>
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvanitasvitae%2Fflowdalic-xeps%2Ftree%2Fscedata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=T61uPbN2631En4SqdiDMW2Gwk5pfgrCxZXFmFxHpt%2Bg%3Dreserved=0
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeekplace.eu%2Fxeps%2Fxep-sce%2Fxep-sce.htmldata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065422005321sdata=3BvePHpJPZICLrqxlfiRW7sCL0EwLRov%2FEc6l5i%2Bkic%3Dreserved=0
>
> I also created a small MUC on the topic, although the address is not
> final, as I may move the conversation to a more stable server (mine is
> hosted behind dyndns, so Schroedingers Chat might kick in :/).
>
> xmpp:s...@conference.jabberhead.tk?join
>
> Happy Hacking!

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Let us zap master passwords from devices

[Peter Waher]

Hello Florian, all

For the generation of certificates, a CSR is of course required, but also a 
mechanism to validate claims. What claims are you basing the certificate on? 
And is the broker supposed to become a CA?

For the generation of Certificates, there’s also the ACME protocol that can be 
used. It is well established, and works fine, even if it requires HTTP to the 
CA.

Certificates are also limited in time, so I guess a mechanism to renew 
certificates is required.

Question: What is the principle reason for using certificates in the first 
place? Is it to be able to use the EXTERNAL authentication mechanism, or is 
there another reason?

For IoT, some form of public key cryptography is often used instead of 
certificates. You register an identity with a public key, and use the private 
key during authentication to prove you’re the rightful owner of the public key. 
I would personally suggest such a method instead. But it might require a new 
authentication mechanism. One way to avoid the invention of a new 
authentication mechanism is to derive a shared secret (for instance using 
ECDSA) between the server (which needs some for of public/private key also) and 
the client, and use that shared secret to authenticate the client (i.e. as 
password) using a traditional authentication scheme.

You also have XEP-0348 which proposes a secure manner to create identities in a 
controlled fashion in IoT networks. It avoids the requirement to have to work 
with certificates, 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
___

Re: [Standards] message encryption session at IETF 102

[Peter Waher]

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 tomorrow at IETF 102 from 09:30 to 12:00 EDT (i.e.,
> starting at 13:30 UTC):
>
> https://datatracker.ietf.org/meeting/102/materials/agenda-102-mls-00
>
> Remote participation is available via the following links:
>
> * Chat room: xmpp:m...@jabber.ietf.org?join
>
> * Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1028.m3u
>
> * Video conferencing: http://www.meetecho.com/ietf102/mls/
>
> Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Detecting PEP support

[Peter Waher]

Hello

A short question: Is it possible to detect if an XMPP server supports PEP 
(XEP-0163), without having an account on the server, create an account or 
knowing of an account on the server?

Use Case: Warn a user who tries to create an account on a server, that a server 
(the user has chosen) lacks/has certain features.

Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Content Types in messages vs Body Markup Hints

[Peter Waher]

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 time, many objected, since they did not see the
> > value of this annotation.
> >
> > Now, the interest seems to have been awakened again, with a new
> > proposal: "Body Markup Hints" [2]. Both seem to be based around
> > markdown, so there's an obvious common interest and common ground.
> >
> > What I wonder is: Why don't we collaborate on this? There are already
> > implementations of [1]. It solves the issue 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.
>
> Thanks for your offer Peter.
>
> Those two ProtoXEPs are indeed very similar. I have a few minor issues
> with yours, probably nothing which can't be fixed. The following list is
> not comprehensive and in no particular order:
>
> - I wouldn't define textual content for . If there is a demand
> for having different markup flavours in the same message, then I think
> something like
>
> 
>   ?
>   
> 
>
> would be better. Note that BMH does not deliver that use case, simply
> because I saw no use. But that could change.

There's definitely a use, especially if you don't know the capabilities of the 
receiver, or if there are multiple receivers with different capabilities. It is 
also how XHTML-IM works: They define a method where you send a plain text 
message in the body, and a formatted message in the corresponding tag. The 
content proposal even allows for multiple formats, not only two.

> - It is not really specified where the values for the 'type' attribute
> are defined. It should probably be IANA's Media Types registry
> (https://www.iana.org/assignments/media-types/media-types.xhtml). And
> from this registry only the 'text/*' part. But I only spot text/markdown
> in https://www.iana.org/assignments/media-types/media-types.xhtml#text.
> Since not all markup languages are defined here, I choose to go with
> custom registry in BMH instead.

Internet Content Types are assumed. If unclear, it could be explicitly stated 
For Markdown, you have RFC 7763:
https://tools.ietf.org/html/rfc7763

You can use your own content types as well, as long as you prefix your subtype 
with vnd or x.

> - There is no discovery mechanism for individual markup flavours in your
> ProtoXEP. Discovery is not really a goal for BMH, it is just a nice
> goodie that I would take along. But still, it would be nice to get same
> data from the network, which markup flavours are supported by the clients.

No, but it can easily be added.

> I'm happy to collaborate. In the end, the XSF council should decide if
> any of the ProtoXEPs is worth being accepted, and then we can continue
> to work on them. :)
>
> - Florian

Great.

How about the idea of going through a layout XML, instead of sending the actual 
markdown. And then let each client transform between markdown to XML and back 
to markdown. That would allow different clients to maintain their flavours and 
still be able to interchange formatted messages?

Best regards,
Peter
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Rich(er) text in IM vs XHTML docs

[Peter Waher]

Hello

As has been pointed out several times, there are many implementations of 
Markdown, and many different syntaxes, some even differ on basic elements.

IF we are going to make a XEP that can be used by implementations that already 
have Markdown support, I suggest, as has been pointed out by others, that we 
base it on XML and not the markdown syntax itself. Those of us that already 
have markdown parsers would at least prefer to map parsed markdown to XML, 
rather than have to change syntax, since it would affect content already 
published. Parsed XML is also easier to implement and render. And it can also 
be used to map other types of syntax too. We could also make the XML 
extensible, in the sense that we could, through the use of namespaces, add 
constructs as we see the need for them. Clients not supporting certain 
constructs could probably treat them individually as plain text, without too 
much distortion.

In any case, I'm interested in participating in the writing of such an XEP, 
regardless of if we chose an XSF Markdown flavour (one more for others to 
learn), or an XML representation of its constructs.

Having said that, I still think there's a need 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
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Content Types in messages vs Body Markup Hints.

[Peter Waher]

Hello

Regarding Goffis comments:

> Content type is useful to know, as the name state, the type of a content.

At least we agree on this, and that is the point of the proposal. To have a 
means to annotate what the content is.

> But in the case of rich text in a messaging app, we need to know in advance 
> which
> kind of content we can accept, and to be able to interpret it, this need a
> well-known restricted choice, and a well specified syntax. If you don't have a
> restricted choice, you are never sure to be able to interpret rich content.

This is besides the point. One thing is to annotate, another is to agree on 
what options could or should be used. But such things can evolve over time. The 
proposal does not assume to suggest Markdown should be used. It's only used as 
an example.

Also, we could append the suggestion with a means to declare what types are 
supported by clients, so they can agree on what to use.

> You have obviously not read any of the previous message about it so I invite
> you to do so. This has nothing to do with my "personal opinion" (I have
> nothing against Markdown and I use it myself), this is about the right thing
> to do with a specification to generate rich text which can be transmitted on
> the wire and rendered in a reproductible way.
>
> So I'll repeat myself one more time.
>
> Markdown is a terrible choice because:

Yes I have. "Terrible" is not an objective word, and you're obviously not able 
to see the pros, only the cons (at least, that is what is seen in your mail) of 
Markdown. You only declare what you see as negative aspects. You're so against 
this particular technology, so you can't see that the proposal is not actually 
about Markdown, but about annotating. If you're against Markdown, nobody will 
force you do use it. The proposal is about annotating content by those that 
have a need to use different content types (representations) that what is 
currently presented as options in available XEPs. Now, sufficient interest 
exists to have caused two proposals in this area. The need is there. If you 
like Markdown or not is not relevant, since these proposals do not use Markdown 
for more than as examples.

Furthermore, the use of Markdown in clients, social networks, discussion 
boards, content managment systems, etc., also show that markdown is very much 
liked by many (but not all). It is often even a requirement. The question 
remains: Do implementors who want to use Markdown have to find another forum 
than the XSF for defining extenions to annotate its content, or can the XSF 
cater to the needs of such developers? Nobody has asked the XSF to recommend 
Markdown as a format for interchange. The best format can be derived over time 
through competition (which is the normal way of settling disputes of this kind).

Having said this, the proposals have some differences. In the first proposal, 
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



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Content Types in messages vs Body Markup Hints.

[Peter Waher]

Hello Goffi

Internet Content Types have proven themselves to be a very successful method to 
promote interoperability on the web. Why it it would be just like "saying 
goodbye to the idea of interoperability" is a mystery to me.

That you don't like Markdown is apparent ("good alternative (i.e. not 
Markdown)"), and is just a personal oppinion, which is OK. But that's not the 
point. There are now two proposals that stem from the same need: The desire to 
be more flexible when it comes to sending different types of content, and have 
an accepted (interoperable) way to annotate what content is being transmitted. 
The question the XSF needs to ask itself: Does it want to act as a conduit to 
help XMPP developers find interoperable ways to perform what they want to do, 
or should indivudual members, based on personal opinions, block such efforts? 
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 from a well working thing to an syntax is already something I'm not
> really supporting even if I could follow if we have a good alternative (i.e.
> not Markdown), but having an open bar and letting any content type like you
> proposed is just saying goodbye to the idea of interoperability (and the
> sanity of clients developers), and it was a true relief to see a veto on this
> one.


> > 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 time, many objected, since they did not see the value
> > of this annotation.
> >
> > Now, the interest seems to have been awakened again, with a new proposal:
> > "Body Markup Hints" [2]. Both seem to be based around markdown, so there's
> > an obvious common interest and common ground.
> >
> > What I wonder is: Why don't we collaborate on this? There are already
> > implementations of [1]. It solves the issue 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
> >
> > [1] https://github.com/xsf/xeps/blob/master/inbox/content-types.xml
> > [2]
> > https://github.com/xsf/xeps/pull/529/commits/4bc652eb7cefb5489f67f31a3eda20
> > 21cba85783
>
> Hi Peter,
>
> I was one of those objecting, and I wasn't objecting because I "did not see
> the value of this annotation", but because I thought (and I'm still thinking)
> that it's a terrible solution.
>
> Moving from a well working thing to an syntax is already something I'm not
> really supporting even if I could follow if we have a good alternative (i.e.
> not Markdown), but having an open bar and letting any content type like you
> proposed is just saying goodbye to the idea of interoperability (and the
> sanity of clients developers), and it was a true relief to see a veto on this
> one.
>
>
> Cheers
> Goffi
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0337 Event Logging: Why is PubSub discouraged?

[Peter Waher]

Hello Maxime

Perhaps the phrasing could be reworked. It relates only to sensitive 
information, which perhaps should be emphasized. If access to, and lifetime of, 
what is being published using pubsub can be securely managed, it can of course 
be used. The problem is that, you have to develop data protection measures to 
make sure that that is the case (for sensitive information). If very sensitive 
information is being processed, end-to-end encryption might even have to be 
used (§7.3.1), which is even more problematic in a one-to-many communication 
patern. All these issues become easier if direct messaging is used, since it 
uses a natural point-to-point pattern, and except for offline storage, and 
in-transit processing aspects, do not persist the contents of the message. The 
XEP does not consider persistence or processing of logged events, just the 
transport of the events 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
> published openly. If there's risk for sensitive information to be
> logged, the publish/subscribe pattern should be avoided.
> """
>
> As PubSub does have access models, I am not sure I understand the risks
> mentioned in this paragraph. Does anybody have any insight on why this
> was written this way?
>
>
> [7.3.2]: https://xmpp.org/extensions/xep-0337.html#sect-idm140133614364832

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Content Types in messages vs Body Markup Hints.

[Peter Waher]

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 time, many objected, since they did not see the value of this 
annotation.

Now, the interest seems to have been awakened again, with a new proposal: "Body 
Markup Hints" [2]. Both seem to be based around markdown, so there's an obvious 
common interest and common ground.

What I wonder is: Why don't we collaborate on this? There are already 
implementations of [1]. It solves the issue 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

[1] https://github.com/xsf/xeps/blob/master/inbox/content-types.xml
[2] 
https://github.com/xsf/xeps/pull/529/commits/4bc652eb7cefb5489f67f31a3eda2021cba85783


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Interoperability tools

[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/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposal: Replacing HTTP with XMPP for Matrix's client-server transport (Matthew Hodgson)

[Peter Waher]

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 released by Hubert Chathi from the Matrix community: as many
> know Matrix is a realtime decentralised data synchronisation protocol,
> which defines long-polling HTTP+JSON as its baseline transport, but the
> door has always been open to folks to define alternative superior
> transports.
>
> So it's only been a matter of time before someone proposed using a
> protocol actually designed for realtime communication (unlike HTTP), and
> so I'm incredibly excited to share his work at
> https://www.uhoreg.ca/blog/20170401-: an elegant and concise
> proposal for replacing HTTP with XMPP as a genuine realtime transport
> for the Matrix Client/Server API.
>
>https://www.uhoreg.ca/blog/20170401-
>
>Feedback welcome O:-)
>
>--
>Matthew Hodgson
>Matrix.org

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] SHA-1

[Peter Waher]

Hello all.


SHA-1 is used in many places throughout XMPP. Examples include authentication 
mechanisms (SCRAM-SHA-1) and entity capabilities (XEP-0115), for instance. 
Concerning the recent report about vulnerabilities found in SHA-1, should there 
be an effort to upgrade all these to SHA-256 or 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/>

A Super-Common Crypto Tool Turns Out to Be 
Super-Insecure<https://www.wired.com/2017/02/common-cryptographic-tool-turns-majorly-insecure/>
www.wired.com
NIST has been warning about vulnerabilities in its SHA-1 cryptographic hash 
function for years, but some services still use it and the threats are growing.



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [xsf/xeps] Defers many old XEPs (#372)

[Peter Waher]

Hello Sam (and others)

As you know, some of these have actually been touched on more recently, but the 
editorial team chose not to accept the edits, after waiting several months. You 
yourself chose not to accept the edits, because you thought it was too 
complicated to have changes made in multiple XEPs in a single PR.

I therefore ask you to return the following to Experimental:

  *   M xep-0323.xml<https://github.com/xsf/xeps/pull/372/files#diff-8> (2)
  *   M xep-0324.xml<https://github.com/xsf/xeps/pull/372/files#diff-9> (2)
  *   M xep-0325.xml<https://github.com/xsf/xeps/pull/372/files#diff-10> (2)
  *   M xep-0326.xml<https://github.com/xsf/xeps/pull/372/files#diff-11> (2)
  *   M xep-0331.xml<https://github.com/xsf/xeps/pull/372/files#diff-13> (2)
  *   M xep-0336.xml<https://github.com/xsf/xeps/pull/372/files#diff-17> (2)
I also request another method, since you didn’t approve of the way I use Git. 
Is it possible for me to mail updates to these XEPs to the editor e-mail, as 
was possible before? If not, I request more patience on the editor side for any 
lack of profitiency using Git. I don’t know how to edit multiple XEPs and 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:subscri...@noreply.github.com>
Ämne: [xsf/xeps] Defers many old XEPs (#372)


Lots of old XEPs that haven't been touched in 12+ months and need deferring. 
Some of these are widely used and should probably be advanced; I'll ask the 
various people involved if they want to continue pushing them forward or try to 
advance them and we can undefer them if anyone wants to take over and champion 
an XEP on a case by case basis.

Fixes #369<https://github.com/xsf/xeps/issues/369>


You can view, comment on, or merge this pull request online at:

  https://github.com/xsf/xeps/pull/372

Commit Summary

  *   Defers many old XEPs

File Changes

  *   M xep-0215.xml<https://github.com/xsf/xeps/pull/372/files#diff-0> (2)
  *   M xep-0233.xml<https://github.com/xsf/xeps/pull/372/files#diff-1> (2)
  *   M xep-0264.xml<https://github.com/xsf/xeps/pull/372/files#diff-2> (2)
  *   M xep-0286.xml<https://github.com/xsf/xeps/pull/372/files#diff-3> (2)
  *   M xep-0292.xml<https://github.com/xsf/xeps/pull/372/files#diff-4> (2)
  *   M xep-0298.xml<https://github.com/xsf/xeps/pull/372/files#diff-5> (2)
  *   M xep-0318.xml<https://github.com/xsf/xeps/pull/372/files#diff-6> (2)
  *   M xep-0320.xml<https://github.com/xsf/xeps/pull/372/files#diff-7> (2)
  *   M xep-0323.xml<https://github.com/xsf/xeps/pull/372/files#diff-8> (2)
  *   M xep-0324.xml<https://github.com/xsf/xeps/pull/372/files#diff-9> (2)
  *   M xep-0325.xml<https://github.com/xsf/xeps/pull/372/files#diff-10> (2)
  *   M xep-0326.xml<https://github.com/xsf/xeps/pull/372/files#diff-11> (2)
  *   M xep-0330.xml<https://github.com/xsf/xeps/pull/372/files#diff-12> (2)
  *   M xep-0331.xml<https://github.com/xsf/xeps/pull/372/files#diff-13> (2)
  *   M xep-0333.xml<https://github.com/xsf/xeps/pull/372/files#diff-14> (2)
  *   M xep-0334.xml<https://github.com/xsf/xeps/pull/372/files#diff-15> (2)
  *   M xep-0335.xml<https://github.com/xsf/xeps/pull/372/files#diff-16> (2)
  *   M xep-0336.xml<https://github.com/xsf/xeps/pull/372/files#diff-17> (2)

Patch Links:

  *   https://github.com/xsf/xeps/pull/372.patch
  *   https://github.com/xsf/xeps/pull/372.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub<https://github.com/xsf/xeps/pull/372>, or mute the 
thread<https://github.com/notifications/unsubscribe-auth/ABE1lPqI0j5rl3T57sTlekrGaadzwelmks5rTPQWgaJpZM4Ll6Hp>.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

[Peter Waher]

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 <stpe...@stpeter.im>
Skickat: den 6 januari 2017 17:00:29
Till: XMPP Standards
Kopia: yusuke@toshiba.co.jp; Peter Waher
Ämne: Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) 
Format)

Old thread alert!

On 10/8/14 10:33 AM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0322 
> (Efficient XML Interchange (EXI) Format).
>
> Abstract: This specification describes how EXI compression can be used in 
> XMPP networks.
>
> URL: http://xmpp.org/extensions/xep-0322.html
>
> This Last Call begins today and shall end at the close of business on 
> 2014-10-21.
>
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?
> 2. Does the specification solve the problem stated in the introduction and 
> requirements?
> 3. Do you plan to implement this specification in your code? If not, why not?
> 4. Do you have any security concerns related to this specification?
> 5. Is the specification accurate and clearly written?
>
> Your feedback is appreciated!

I noticed substantive spec and security feedback in October 2014 from
several list participants. However, as far as I can see, that feedback
has not been addressed by the authors.

As part of my review of all the IoT specs, I would like to provide
feedback on XEP-0322, but it seems like wasted effort if the spec hasn't
been updated since the previous last call.

Yusuke & Peter, do you plan to update XEP-0322 or do you need a
co-author to help finish this off?

Peter


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP IoT SIG - Call for Participation

[Peter Waher]

Hello

Unfortunately, I cannot attend the meeting. I’m travelling, and will be back 
the 16th of January. For the record, I’ve documented some of the 
benefits/strengths of XMPP for IoT in the following slideshare presentations. 
While I cannot verbally fill in the blanks, they might be useful 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
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] An implementer's review of the IoT XEPs

[Peter Waher]

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 friend or not. So, if the thing receives a friendship request, it
> basically proxies the request to its provisioning server (PS), which
> will wait for an decision from the thing's owner. This process is
> described in the Provisioning XEP and is basically a proxy mechanism for
> XMPP subscription requests.

It’s called ”delegation of trust”: I.e. if the thing cannot make the decision 
it self, it can delegate the responsibility to one or more third parties 
(provisioning servers). How these reach a conclusion is not specified more than 
through example: To ask the owner. A learning mechanism is also mentioned, but 
not specified.

> The concept of friendship is a fundamental building block of the IoT
> XEPs, yet it is nowhere formal specified what friendship actually is in
> terms of XMPP. The XEPs appear map friendship between things to
> subscription states between XMPP entities, but they do not specify if
> friendship is a symmetric relation or an asymmetric one. XMPP
> subscription states are asymmetric: Just because I'm subscribed to your
> presence, it doesn't mean that your are subscribed to mine. I believe
> that the IoT XEPs assume that an thing is a friend if both are
> subscribed to each others presence. But do we really want that?

The provisioning server keeps track of friendship relationsships. This is 
symmetric in the sense, that both can subscribe to the presence of the other, 
if they want to. They don’t need to.

I’ve added a note to add a description, or definition of the friendship 
relationship, and how it relates to presence subscriptions.

> While implementing we also discovered that the XEPs do not discuss an
> important protocol flow. One of the test scenarios I implemented in
> Smack consists of a provisioning server (PS), a thing, a owner and an
> XMPP entity trying to become a friend of the thing (the 'requestor').
> The requestor sends a subscription request to the thing, in order to
> befriend the thing. Now the thing asks the PS whether or not the
> requestor is a friend and the PS will immediately return that the
> requestor is not a friend, because there was no decision from the owner
> yet. Here ends the story in the XEPs. In our scenario, the owner will
> eventually accept or reject the friendship request in the PS's web
> interface. But how does the requestor get notified about the owners
> decision? Possible XEP-0324 ? 3.2.4 ? but do we want the requestor to
> act on recommendations send from arbitrary JIDs? We also need to discuss
> this.

If no rules are defined, rejection is returned by default to the device, since 
immediate feedback is always assumed. It is also assumed the owner is notified 
of the action. But since the owner might respond to the action at a much later 
stage, that response is seen as a separate event. If the owner accepts the 
request, this event is informed asynchronously, as described in §3.2.4, as you 
mentioned.

> My general impression is that the current IoT XEPs are to large and to
> complex. It reminds me of the XEP-0136 Messaging Archiving situation,
> where this big and complex XEP got not much traction because it is so
> heavyweight and hard to implement. And now we have XEP-0313 Message
> Archive Management, which is simple, covers most uses cases and is easy
> to extend, thus allowing the missing use cases to be added on top. We
> should think big, but write simple and modular XEPs.

And yet much smaller than pubsub, which to many seems to be one of the 
cornerstones of XMPP. They are modular, that’s why they’ve been separated into 
322, 323, 324, 325, 326, 347.

> The XEPs are written in style which possible assumes that examples are
> normative: Some sections consist mostly of figures and examples. The IoT
> XEPs need more normative texts.

More normative text, and less examples? Many claim the XEPs are too long. But 
as you say, most of the text consists of examples.

> XEP-0323 - Data
> ===
>
> The data read scheme out should follow the scheme we re-introduced in
> XEP-0313: Message Archive Management: IQ-request ? data1 ? ? ? dataN ?
> IQ-result. This would allow to remove the 'done' attribute and this
> scheme is a little bit easier to implement. I going to repeat myself,
> because I said this in MAM thread years ago: I believe we always should
> use this very scheme when requesting data which we expect to be
> delivered by multiple stanzas.

Are you suggesting that using data-forms would be “easier” for transporting 
sensor data? And that constant polling to extract asynchronously retrieved data 
would be simpler? I cannot see that that would be easier using any objective 
standard. It also presupposes knowledge 

[Standards] IoT SIG: overview informational XEP

[Peter Waher]

Hello everybody

Regarding the XMPP IoT SIG deliverable §5:

> The IoT SIG should at a minumum produce an informational XEP
> that provides an overview of the XMPP IoT "landscape"; this document
> could help the XMPP community (including XSF members, leadership,
> and teams) understand the Intenet of Things and especially the
> applicability of XMPP to common IoT use cases.

Unless somebody else volunteers in writing this document, I volunteer writing 
one. Some questions:


·How is the procedure supposed to be?

·I write a draft and transmit it to the council for evaluation?

·Or should it be sent to the iot mailing list?

·Or should we agree on a disposition first, i.e. what 
sections/subsections to include?

·Are there any special criteria or considerations that have to be taken 
into account already from the beginning?

·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
___

Re: [Standards] Fwd: Internet of Things SIG

[Peter Waher]

Hello

> I propose that we form a special interest group (see XEP-0002) regarding the
> use of XMPP in the Internet of Things:
>
> http://xmpp.org/extensions/inbox/iot-sig.html

The IoT SIG sounds like an excellent idea.

> Firstly, it'd be useful to gather a sense of the current 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 are
> generally working well for them.

It might be of interest to you, to know that the IEEE is working to form a new 
Group on ”IoT Harmonization”, in which XMPP plays an important role. XEPs under 
consideration at this forming stage are 0323, 0324, 0325, 0326 & 0347. You can 
review the slides from a presentation I held yesterday on this topic:

http://www.slideshare.net/peterwaher/iot-harmonization-using-xmpp

Let me know if anybody working with XMPP & IoT is interested to participate in 
such a working group. The goal is to form the group in January and have a first 
draft ready for balloting by the end of 2017.

> Secondly, I'm of the opinion - and opinions can always be changed -
> that the existing IoT proposals are something of an isolated suite.

Yes and no. They have been abstracted. Some are more IoT related 
(323,324,325,326,347), others are more generic. EXI was written as reaction to 
the observation that XMPP is too verbose for some IoT applications and some 
networks. The Event logging (0337) is a generic infrastructural need, but it 
arose from logging in distributed IoT systems where many clients lack displays. 
HTTP over XMPP (0332) arose from the need to define web queries among 
distributed sets of sensors. Dynamic Forms (0336) as a way to create richer 
data forms, but is used in IoT since data values might take some time to fetch, 
and fields need to be able to be updated dynamically. Form signatures (0348) is 
needed to automate the creation of XMPP accounts, in a secure manner. Others 
that wait approval are also written to be generic, such as the QoS proposal – 
which originated as a need from IoT but has generic value. Event subscription 
is more directly IoT-related.

> Looking at the IETF MILE Working Group, we have the XMPP-Grid proposal
> which seems a similar shape to the IoT proposal, and similarly uses
> little of the existing mechanics we have. For example, it provides a
> publish-subscribe facility, a registration facility, and so on. The
> payloads are different, but the essential goals the same. I cannot see
> what would drive a difference in the containing protocol between (say)
> counts of stanzas in an XMPP server, temperature readings in a sensor,
> and sightings of a Cyber Observable pattern.

There’s already a publish-subscribe based IoT solution defined by the UPnP, and 
published by the OIC/OCF:
https://openconnectivity.org/resources/specifications/upnp/iot

To create another one for this purpose seems unnecessary.

While publish/subscribe might work well for several use cases, it’s not 
sufficient to cover all use cases, not even the most important use cases. It’s 
sole purpose is to make mass-dissemination more efficient. The IoT XEPs 
however, allow for a more general architecture, which is not limited to a 
single communication pattern, but allows for most patterns used today, 
depending on what is to be accomplished. See my presentation above for more 
information.

Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Signal protocol for end-to-end encryption

[Peter Waher]

Hello

Does anybody on this list have experience using the Signal protocol (previously 
axolotl protocol), from Open Whisper Systems, together with XMPP for end-to-end 
encryption? As there’s work being done on this list concerning end-to-end 
encryption (OpenPGP & OTR), it might be of interest 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: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Registrar pages

[Peter Waher]

Hello

I assume that the responsible for the new web page might be aware of this, but 
in case they are not: The registrar pages (http://xmpp.org/registrar/*) cannot 
be found. Example from XEP-0030: 
http://xmpp.org/registrar/disco-categories.html. Nor can I find new such pages 
on the new web site.

Best regards,
Peter Waher




___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Images in chat

[Peter Waher]

Hello Nick.
Thanks for your response. My answers to your comments below:

> > 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
> 
> 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
> > impossible to guess. That means everyone who knows the URL SHOULD be
> > able to access it.
> 
> It's true one doesn't need to go through HTTP auth (which might as well
> be considered broken at this point) or have an auth cookie on hand,
> and in that sense the images are accessible to third parties, but the
> long random strings in the path are essentially a password, stronger
> than what most people pick for a normal password. This is what Facebook
> and Github do with their private RSS feeds, and what Google Docs and
> Dropbox do with private sharing links.
Facebook, Github & Google Docs are examples of things to avoid in this case: 
I.e. not sharing your content with a third party. Making the URL difficult to 
guess still leaves the file on the server.
> 
> Where HTTP Upload falls over is in conjuntion with end to end
> encryption like OTR. You can encrypt the URL to the image so outside
> observers can't ask for it, and XEP 363 specs that you should can
> encrypt the actual data transfer with HTTPS, but the server itself
> still sees the image. Is that what you're concerned about?
> 
> Otherwise, it's as much third party as passing your IMs over the two
> XMPP servers is in the first place, and with the bonus that for
> self-hosted servers it's not third party at all. If you trust your
> server, you can trust HTTP Upload. If you don't trust your server then
> you need to invest in one of the other options floated. I like HTTP
> upload because it works right now, today, across any receipient server
> and even across gateways.
It's not "as much thirdparty" as asynchronous messaging between two users, as 
the latter can be encrypted using end-to-end encryption without affecting 
underlying communication patterns. Third parties, including browsers will not 
be able to eavesdrop on communication this way. And the problem is not solved 
by self-hosting your servers. There's a difference between the trust of the 
developer, or service provider, and the trust the client user has. These are 
different actors. And you also have the problem of federation, in 
communication. You would have to isolate your solution, which is undesireable. 
You cannot solve the security or integrity issues by hosting your own servers, 
since its not you, but your users who do not want to share their content with 
others, including you. The HTTP upload solves transport, but not security and 
integrity. The benefit of not storing something on a broker/server, is that 
end-to-end-encryption can be used on-top. If end-to-end-encryption can be 
worked into HTTP upload, it might solve the security/integrity case also, or 
most of the parts of it. The problem by doing so, is that you would have to 
update the handling of the normal http and https URI schemes to do so.
Best regards,Peter Waher
  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Images in chat

[Peter Waher]

Hello Goffi.
Thanks for your reply. Jingle file transfer can be negotiated using the HTTP 
over XMPP (XEP-0332) phase. The URI provided therein 
(http://xmpp.org/extensions/xep-0332.html#httpxscheme) allows parties to 
negotiate if file transder, in-band-bytestreams or jingle should be used for 
large content. Small content or dynamic content can be transferred using text, 
xml, base64 or chunked base64 methods.
Regarding XEP-0231: It looks like an interesting method, if HTTP over XMPP is 
not supported. BoB does not support partitioning the content file into smaller 
blocks it seems, but it 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 have Jingle URI (this would be easy to solve though).
> There is also XEP-0231 but it's more suitable for small images.
> 
> ++
> Goffi
> 
> Le dimanche 13 mars 2016, 15:52:01 Peter Waher a ?crit :
> > Hello Fabian
> > Thanks for your response.
> > 
> > > > So, there are two things that are needed:
> > > > 
> > > > 1) Transfer of the image content. This can be done in various ways.
> > > > 2) The receiver needs to understand the context, i.e. that the image
> > > > should be displayed in the chat window (not saved to file, shown in a
> > > > popup window, etc.)
> > > > 
> > > > What solutions are available? I know I can solve this using XHTML-IM
> > > > (XEP-0071) and HTTP over XMPP (XEP-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 other alternatives?
> > > 
> > > maybe the easiest way would be to use XEP-0363 (HTTP File upload) and
> > > then use XEP-0066 (Out of Band Data).
> > > 
> > > As you mentioned, you could then also use XEP-0071 (XHTML-IM) instead of
> > > XEP-0066, but personally I would always prefer XEP-0066 and leave it up
> > > to the client implementation to decide how to 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 conclude that
> > there are no other ways than by using XHTML-IM and HTTP over XMPP. Best
> > regards,Peter Waher
> 

  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Images in chat

[Peter Waher]

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 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 conclude that there are no other ways than by using XHTML-IM and HTTP
> >over XMPP.
> >Best regards,Peter Waher
> 
> The thing XEP 363 doesn't mention, but which I think you should take as a 
> given, is that the HTTP server is the XMPP server.  This is how Prosody's 
> mod_http_upload works and there is no other way to configure it.  So there's 
> no trusting a third party any more than any XMPP chat.
  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Images in chat

[Peter Waher]

Hello Fabian
Thanks for your response.
> > So, there are two things that are needed:
> >  
> > 1) Transfer of the image content. This can be done in various ways.
> > 2) The receiver needs to understand the context, i.e. that the image
> > should be displayed in the chat window (not saved to file, shown in a
> > popup window, etc.)
> >  
> > What solutions are available? I know I can solve this using XHTML-IM
> > (XEP-0071) and HTTP over XMPP (XEP-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 other alternatives?
> 
> maybe the easiest way would be to use XEP-0363 (HTTP File upload) and
> then use XEP-0066 (Out of Band Data).
> 
> As you mentioned, you could then also use XEP-0071 (XHTML-IM) instead of
> XEP-0066, but personally I would always prefer XEP-0066 and leave it up
> to the client implementation to decide how to 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 conclude that there are no other ways than by using XHTML-IM and HTTP over 
XMPP.
Best regards,Peter Waher
  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Images in chat

[Peter Waher]

Hello Sam
 
Thanks for your response.

> > What is the preferred way of sending an image in chat today? XHTML-IM can be
> > used to send smaller images using the data URI scheme.
> 
> Just to be clear, you want to indicate that an out-of-band image
> should be included in the UI if possible, but not actually transmit
> the image in any way?
> 
> If so, I generally advocate for XEP-0066: Out of Band Data [1].
> 
 
No, it's not an out-of-band image, such as one available through normal HTTP. 
Use case might be one user chatting with Another and wants to paste an image 
into the chat session (image might be captured from the screen and available in 
the clipboard), and the other user sees it directly in his or her chat window 
(as can be done on Skype for instance).
 
So, there are two things that are needed:
 
1) Transfer of the image content. This can be done in various ways.
2) The receiver needs to understand the context, i.e. that the image should be 
displayed in the chat window (not saved to file, shown in a popup window, etc.)
 
What solutions are available? I know I can solve this using XHTML-IM (XEP-0071) 
and HTTP over XMPP (XEP-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 other alternatives?
 
Best regards,
Peter Waher
 


 
  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Images in chat

[Peter Waher]

Hello
 
What is the preferred way of sending an image in chat today? XHTML-IM can be 
used to send smaller images using the data URI scheme. Larger images can be 
used with XHTML-IM if support for HTTP over XMPP exists. But for larger images 
on clients not supporting XEP-0332? There are multiple extensions for sending 
larger objects, if the context is understood by both parties, but will these be 
automatically understood to be included in the current chat session? Images can 
be sent using forms media elements, but sending such a form would probably 
create popup windows instead of 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
___

Re: [Standards] Multi-stage registrations

[Peter Waher]

Hello Stephen
 
Correct, it's live updating of the form based on user input. This is what 
you're saying, i.e. user submits one form and then another. 
This is called post-back in XEP-0336. So, when a field that is marked for 
post-back has been edited, the form is sent back, and a new is
returned, exactly what you wanted.
 
If you explicitly want a button to press, then I think the easiest way it to 
define a button field type. As with any field type, the button could
be marked with a post-back flag, signalling the client that if the button is 
pressed, the form is returned. XEP-0336 then describes how the
new form is joined with the old. It can be an entirely new form.
 
Additional benefits of using XEP-0336, apart from post-back, which allows for a 
richer user experience and customized server-side validation of fields, is 
better error information per field, giving better 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 Waher
 
 
> 
> > http://xmpp.org/extensions/xep-0336.html
> >
> > This XEP allows the server to respond to user actions in the form, 
> > including changing the form (adding, updating, removing fields) etc.
> 
> Hmm, this seems to solve a different purpose, that is, live updating of 
> a form based on user input.  In the multi-stage registration case, the user 
> submits one form and then another, it's not really a "dynamic form".
> 
> I'm willing to be convinced otherwise, but the two seem orthogonal.
> 


  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown in XMPP IM

[Peter Waher]

 
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.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown in XMPP IM

[Peter Waher]

Hello all
 
> If anything we should define a small microformat that looks good
> formatted or in plain text (which could just be a specific Markdown
> flavor minus the raw HTML stuff) and mandate that all clients that
> support the spec use that one format.
 
Why define something new when there's a format that people like, know and want 
to use?
 
Furthermore, leaving the format out of the XEP allows standardization of the 
format to be done in other forums.

> 
> So perhaps both approaches have their use cases? I don't fundamentally
> object to either, but including multiple renderings in a
> multipart/alternative style all the time just for improved handing of
> *this* seems overkill.
> 
 
What about an approach that allows both?
 
Say we create a new element  that we send with the 
message. If it's empty, it could be considered a hint regarding 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

  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown in XMPP IM

[Peter Waher]

Hello all
 
Regarding the recent comments:
 
> > > So perhaps both approaches have their use cases? I don't fundamentally
> > > object to either, but including multiple renderings in a
> > > multipart/alternative style all the time just for improved handing of
> > > *this* seems overkill.
> > > 
> >  
> > What about an approach that allows both?
> >  
> > Say we create a new element  that we send with the 
> > message. If it's empty, it could be considered a hint regarding the format 
> > of the message body. If it is non-empty, it contains an alternative, a 
> > formatted version of the plain text message body.
> 
> I think allowing alternate content renditions could be opening up a whole can 
> of worms. We already have the body for plain text and XHTML-IM for rich text. 
> If the plain text version happens to be structured then I think hinting as to 
> the underlying format is useful (and I am definitely emphasising that it?s a 
> hint to make the point that it can be safely ignored).
 
It's an overly pessimistic view on things. It's a simple IF, to decide where to 
take the information from, if you understand the content type. From the body 
(if the element is empty) or from the element itself (if not).

> 
> Some kind of type hinting solves the issue that sparked this thread, and I 
> like the fact that it?s potentially not limited to markdown - you could 
> imagine a system sending data in a yaml format for example, which is both 
> human and machine readable. It?s also nice and simple.
 
No it does not. Since I sparked the thread I encourage you to read my comments 
in the beginning.
 
> > What about an approach that allows both?
> > 
> > Say we create a new element  that we send with the
> > message. If it's empty, it could be considered a hint regarding the format
> > of the message body. If it is non-empty, it contains an alternative, a
> > formatted version of the plain text message body.
> 
> it's ugly and messy in my opinion. We already have 2 syntaxes: text for 
> client 
> we can't or don't want to display rich content (e.g. console client), and 
> XHTML-IM for rich content.
 
Then don't. I don't propose doing this as mandatory for clients to support. The 
question is, IF clients want to send markdown, should it be done in a 
proprietary fashion, or should the XSF provide an interoperable means to do 
this? The XSF cannot block people from doing it, it can just choose to limit 
interoperability, in case people want to, or help interoperability, by 
providing a standardized means for how it should be done, if done at all.

> 
> If we start to use rich syntax for text content, which syntax should I use in 
> my client when both markdown and XHTML is there ? And what if clients start 
> to 
> send markdown only messages ? And what about the flavours ?
 
I guess that is a question for other forums, for instance once dedicated to 
markdown.

> Markdown translates easily to XHTML(-IM) and the opposite works quite well 
> too.
 
No, it doesn't actually. Generating HTML from markdown is easy, but not 
markdown from HTML (or even knowing when received HTML is made from markdown at 
all and can be converted).

> 
> I think adding new syntaxes (non XML in addition, meaning that client need a 
> specific parser) is a bad path.
 
Only if they want to support this new syntax. If 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 you don't need to add a markdown 
parser, is if you create a bot sending markdown messages from code. But if you 
want to allow users to use markdown, you need a parser. If you don't want to 
allow users to use markdown, you're not forced to.
 
Best regards,
Peter Waher


  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown in XMPP IM

[Peter Waher]

Hello Matthew, Florian & others
 
Thanks for your input. Regarding your comments:

> >> Isn't the point of markdown that it's perfectly readable as plain text,
> >> ie that there is no markup? I'd think sending straight markdown would
> >> be just fine.
> >
> > The point of markdown is that it's easy to write and edit (focus is not
> > reading, even though it's somewhat readable as well). I thought about
> > sending markdown just as-is as well, but after thinking about it for a while
> > decided against it.
> 
> Sorry, this is definitely incorrect.
> 
> >From the author's site ( https://daringfireball.net/projects/markdown/ ):
> 
> "Markdown allows you to write using an easy-to-read, easy-to-write
> plain text format [...]"
> 
> and
> 
> "The overriding design goal for Markdown?s formatting syntax is to
> make it as readable as possible. The idea is that a Markdown-formatted
> document should be publishable as-is, as plain text, without looking
> like it?s been marked up with tags or formatting instructions."

Interesting to see how different people read the same text and come out with 
different conclusions. From the same page:
 
"Markdown’s syntax is intended for one purpose: to be used as a format for 
writing for the web."
 
and
 
"The idea for Markdown is to make it easy to read, write, and edit prose. HTML 
is a publishing format; Markdown is a writing format."
 
So, the main purspose, and why it is used in CMS systems, is because it should 
be as easy to write as possible, and yet, be as easy to read as possible, under 
those circumstances. (If writability was not the main concern, other ways 
create results that are easier to read.)
 
> 
> If you ask me, the best thing to do here would be to define a way to
> declare a message's body explicitly as being in Markdown syntax. Then
> clients will ignore that tag it and display it as text, unless they
> understand the tag, then they'll know they can run it through a
> Markdown processor and display a formatted version.
 
I was thinking along these lines as well, and Steven also, in his reply.

> Alternatively, if it's just about easier input, support Markdown on
> the sending side and use XHTML-IM. I don't think we really need more
> ways of formatting messages.
 
You would not be able to recover the markdown this way, which might be of 
interest (see my response earlier).

 
> > 
> > If you ask me, the best thing to do here would be to define a way to
> > declare a message's body explicitly as being in Markdown syntax. Then
> > clients will ignore that tag it and display it as text, unless they
> > understand the tag, then they'll know they can run it through a
> > Markdown processor and display a formatted version.
> 
> I wonder if this is even necessary. Maybe markdown libraries are able
> tell if a given String is in markdown or not. Worst thing that could
> happen are false positives, and I do think that this won't be often the
> case.
 
This is definitely possible. It it might also be undesireable, 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 clients to support XHTML-IM, which, in the case of choosing 
markdown in the first place, might be undesireable.

Best regards,
Peter Waher

  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown in XMPP IM

[Peter Waher]

Hello Travis, Steven, Goffi, Andreas & others
 
Thanks for your input. My responses below:
 
> Isn't the point of markdown that it's perfectly readable as plain text,
> ie that there is no markup?  I'd think sending straight markdown would
> be just fine.
 
The point of markdown is that it's easy to write and edit (focus is not 
reading, even though it's somewhat readable as well). I thought about sending 
markdown just as-is as well, but after thinking about it for a while decided 
against it.
 
The main reason is that text should only be interpreted as markdown if the 
sender knows it's markdown. That is, it's possible to write text that has 
markdown syntax in it, without meaning to, or knowing it's markdown, especially 
if you're using a client that does not know about markdown. So, text should 
only be interpreted as markdown if the receptor understands markdown, and if 
the sender intended to send markdown. So, some form of markup of the markdown 
is necessary.
 
A corollary of sending markdown in the same way XHTML-IM is sent, is that you 
can send a plain text version of the edited text as well. This is easy to do, 
if you already know markdown and can parse it. This means the sent message can 
be displayed in a simpler form, without showing possibly annoying markdown 
constructs.
 
 
> This could also be a client-side only feature, allowing input in
> markdown, then converting it to HTML and sending it as HTML-IM I suppose?

This would be a client-side feature. And markdown could be sent as XHTML-IM 
also, and the receptor can choose which one to display. However, markdown is 
simpler, and so markdown support should not require support for XHTML-IM.
 
> I'd say go with the XEP-0071 structure with a  element and an
> appropriate namespace (is there a common one? Google turns up nothing).
> This leaves the standard  element to contain your plain text. As to
> experience, none I'm afraid :)

I was thinking along the same lines. Markdown has no namespace that I'm aware 
of. Work is done to give it an Internet Content Type however:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/
 
> We use markdown in Salut ? Toi (http://salut-a-toi.org) and convert it to 
> XHTML-IM for microblog. We use a text only version (without markdown) for 
> text 
> version.

Good to know. Thanks. I've been thinking of converting to XHTML-IM as well, but 
lean towards sending XHTML-IM as an alternative encoding instead of the default 
encoding. Sending markdown encoded as markdown has several benefits.
 
One disadvantage of XHTML as compared to markdown, is that XHTML is not easy to 
append or send in segments. (Tags must be closed). As markdown is text, you can 
send multiple markdown messages, forming a larger markdown text segment from 
several smaller, as segments easilly join each other in a simple way. One case 
where this might be useful (and now I'm thinking aloud), is if you send a 
markdown table, for instance. You could easilly append the table with multiple 
messages, and have columns align across messages.
 
> I would suggest just converting the markdown to XHTML client-side and
> sending that one, so you're backwards-compatible. The plain text could
> just be the markdown text, as Travis Burtrum suggested (although
> embedded links look a bit strange that way).

Backwards-compatibility could be achieved by sending XHTML-IM-encoded text as 
an alternative. But as I mentioned above, there are 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
___

Re: [Standards] Markdown in XMPP IM

[Peter Waher]

Hello Ashley, and others.
 
>> I?m sure this must have been discussed and dismissed before, but would 
>> adding a some kind of content/MIME type attribute to the body help at all? 
>> That way a client can stick markdown or yaml or whatever the flavour of the 
>> day is into the body, give it a type, and then the receiving client can then 
>> decide whether it can/wants to render that type nicely or just display it as 
>> plain text?
> 
> I suppose the problem is then that it might encourage people to stick 
> non-textual content into the body too - base64 encoded binaries, etc.
> 
> Maybe having a separate ?rich body? element might work, which can contain 
> markdown, yaml, rich text, etc?
> 
> Just some thoughts...

I like this idea.
 
Would the council be in favour of accepting a protoXEP according these lines? 
Defining an element ... which can be used as 
a complement to the normal text body. It could be limited to top-level types 
"text", to avoid the problem Ashley mentions. (Or leave that as a security 
note. There might be cases where other types might be of interest as well.) In 
this way there's a standardized way to encapsulate internet content (of 
relatively small size) into a message.
 
> 
> Further to my previous message, maybe a ?content type hint? extension:
> 
> 
> 
>   # Some markdown or whatever
>   Yeah!
> 
> text/x-markdown
> 
> 
> It would be a very simple extension, could piggy-back off MIME content types, 
> and could be safely ignored by clients.

I was thinking about this solution as well (i.e. just a flag in the message 
that the body message had a specific content type). But I would prefer the 
content being a supplement of a 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
___

Re: [Standards] Markdown in XMPP IM

[Peter Waher]

Hello Travis, and others:

> > Sending markdown encoded as markdown has several benefits.
> 
> But also many downsides, there is not really such a thing as a markdown
> standard.  There are different 'flavors', such as
> github-flavored-markdown, and then there are just major/minor
> differences in various markdown libraries.  A newish effort is
> CommonMark[1][2], and it is strictly defined, but has only a few
> implementations at last check.
> 
> Point being, you couldn't write a XEP talking about 'markdown' alone and
> expect it to be very compatible across implementations.  I'd instead
> suggest client-side support for markdown, but sending it as HTML with
> the raw markdown as the text alternative.
> 
> [1]: http://commonmark.org/
> [2]: https://xkcd.com/927/
 
Yes, I'm aware of those efforts (and more). But they are not "downsides", as 
they don't limit or make things worse. The most that can happen, if you mark 
something as markdown, is that they payload is ignored. It's a similar 
situation with XHTML-IM I guess, even though it is more pronounced with 
markdown.
 
And still, it does not resolve the issue when you actually want to send 
markdown (see my earlier responses why this would be so). It's always done in a 
client-side manner, the question is: Should it be implementation specific, or 
should there be a measure of interoperability here, between 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

> 
> 
> --
> 
> Message: 2
> Date: Wed, 6 Jan 2016 15:29:31 +0100
> From: Peter Waher <peterwa...@hotmail.com>
> To: "standards@xmpp.org" <standards@xmpp.org>
> Subject: Re: [Standards] Markdown in XMPP IM
> Message-ID: <dub123-w415a48d71e18f07bb2a6a8d0...@phx.gbl>
> Content-Type: text/plain; charset="windows-1252"
> 
> Hello Matthew, Florian & others
>  
> Thanks for your input. Regarding your comments:
> 
> > >> Isn't the point of markdown that it's perfectly readable as plain text,
> > >> ie that there is no markup? I'd think sending straight markdown would
> > >> be just fine.
> > >
> > > The point of markdown is that it's easy to write and edit (focus is not
> > > reading, even though it's somewhat readable as well). I thought about
> > > sending markdown just as-is as well, but after thinking about it for a 
> > > while
> > > decided against it.
> > 
> > Sorry, this is definitely incorrect.
> > 
> > >From the author's site ( https://daringfireball.net/projects/markdown/ ):
> > 
> > "Markdown allows you to write using an easy-to-read, easy-to-write
> > plain text format [...]"
> > 
> > and
> > 
> > "The overriding design goal for Markdown?s formatting syntax is to
> > make it as readable as possible. The idea is that a Markdown-formatted
> > document should be publishable as-is, as plain text, without looking
> > like it?s been marked up with tags or formatting instructions."
> 
> Interesting to see how different people read the same text and come out with 
> different conclusions. From the same page:
>  
> "Markdown?s syntax is intended for one purpose: to be used as a format for 
> writing for the web."
>  
> and
>  
> "The idea for Markdown is to make it easy to read, write, and edit prose. 
> HTML is a publishing format; Markdown is a writing format."
>  
> So, the main purspose, and why it is used in CMS systems, is because it 
> should be as easy to write as possible, and yet, be as easy to read as 
> possible, under those circumstances. (If writability was not the main 
> concern, other ways create results that are easier to read.)
>  
> > 
> > If you ask me, the best thing to do here would be to define a way to
> > declare a message's body explicitly as being in Markdown syntax. Then
> > clients will ignore that tag it and display it as text, unless they
> > understand the tag, then they'll know they can run it through a
> > Markdown processor and display a formatted version.
>  
> I was thinking along these lines as well, and Steven also, in his reply.
> 
> > Alternatively, if it's just about easier input, support Markdown on
> > the sending side and use XHTML-IM. I don't think we really need more
> > ways of formatting messages.
>  
> You would not be able to recover the markdown this way, which might be of 
> interest (see my response earlier).
> 
>  
>

Re: [Standards] Standards Digest, Vol 146, Issue 10

[Peter Waher]

Hello Dave & Ashley, and others:

 > I'd be OK with having a namespaced attribute on the  indicating
> markdown (with optional variant); the fallback to text seems reasonable
> enough.
> 
> Ash's suggestion of an additional marker element is probably easier for
> most implementations to handle, though.
> 
> Not particularly keen on an alternate body, since the only thing I can
> think of to sensibly degrade Markdown into is its source anyway.
 
There's a lot of things in markdown that you would prefer either removed or 
handled differently in plain text, such as links, inline HTML & HTML entities, 
inclusion of images, and if supported by the client, tables (which are often 
unreadable in text form, in text you want them formatted either using tab 
characters or spaces).

> Agreed. Markdown/yaml/whatever (and in theory all the ?text/*? content types) 
> are readable as plain text (so entirely appropriate for a message body). The 
> hint is there to tell clients that might be able to do a better rendition 
> ?hey, this text body here is actually markdown? and give them an opportunity 
> to render it nicely if they can.
 
Readable, but annoying.

> 
> I?m happy to knock up a Content Type Hint ProtoXEP if anyone thinks it might 
> be useful.
 
I would personally need another solution, so I would have to go with a separate 
content element, similar to the XHTML-IM case. Now, if the coucil says it'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

  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Markdown in XMPP IM

[Peter Waher]

Hello
 
Does anyone have experience in using markdown in XMPP IM chat applications?
 
More and more applications use markdown as a simple way to format text messages 
on the fly, and I'm considering using markdown in XMPP IM chat as well. But 
instead of sending markdown as simple text in a normal 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 list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quality of Service

[Peter Waher]

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 
> really. It's part of a mechanism called "reliable messaging", and is 
> available for all sorts of protocols, even HTTP. (MQTT is mentioned in the 
> proposal, but it definitely not limited to MQTT, it was just an example.) 
> Reliable messaging is available in most protocols supporting queueing, where 
> an item can only be delivered once, and exactly once (or, the sender receives 
> a notification that it was not possible to deliver). It is used in cases 
> where retries are not sufficient. This includes all non-idempotent actions, 
> such as counting (including bank transactions) or accumulation, as opposed to 
> absolute-valued information (such as set on/off, or set to N%) which are 
> idempotent. All asynchronous communication protocols are somewhat unreliable, 
> especially if clients have intermittent network connections. While its 
> improbable that a client disconnects while a message is being transmitted, it 
> can happen. And if many messages are sent, it finally will happen. > 
> I think XEP-0198 provides sufficient reliability to traffic that the
> additional overhead here is redundant, and we have XEP-0184 message
> acknowledgements to provide end-to-end acknowledgement, too. "sufficiently 
> reliability" depends on use case, it's completely subjective. For chatting 
> maybe. Not for monetary transactions. The proposal outlines a mechanism 
> (taken from reliable messaging) that makes sure a message is delivered 
> exactly once, or provides the client with information that it could not be 
> delivered at all. Message delivery receipts defined in XEP-0184 is not 
> sufficient either. First, it does not implement the "Exactly Once" level, 
> which is also the most important, and the principal reason for writing the 
> XEP. While it can be used for the acknowledged message case, It also has 
> several weaknesses: One is that an acknowledgement is only requested. There's 
> no mechanism the request is understood. So the message can be sent, parsed, 
> body of message processed, but no acknowledgement returned, generating new 
> requests, etc. To have a solution that either works or does not work, with no 
> in-between state of working partially, you need to embed the message in 
> another construct. If that construct is not understood, the entire message is 
> discarded.
> 
> If  is used, you'll always get at-least-once, no matter the support
> for 198 along the route. Correct. But it would be a proprietary, 
> non-interoperable solution.
> 
> To get exactly-once semantics, the protoXEP recommends the receiver has an
> infinite-sized store of previously received message identifiers - if the
> store ever expires old message ids, then it's potentially allowing multiple
> copies of the request to come through, which is (presumably) highly
> undesirable. No, it does not actually. See 
> §5.2http://xmpp.org/extensions/inbox/qos.html#memory The point here is that 
> if it cannot be received (at the moment) there's a clear error message 
> returned, so the client is alerted. The state is never unknown. Furthermore, 
> processed messages are forgotten, and the double request/response mechanism 
> still makes sure the message is only delivered to the application layer only 
> once.
> 
> This could be avoided by having an if-not-modified-since semantic, which is
> very useful in other cases beyond simple 1:1 QoS. No, it would not work, 
> since that would require the receiver to remember processed messages. The 
> two-step transmission/delivery process, which is standard in reliable 
> messaging, does not require the receiver to remember processed messages.
> 
> Overall, considering the above, I'm inclined to push back until I've
> understood why existing methods are not suitable for the semantics this
> specification seeks to provide. I ask you to reconsider. The pattern 
> described in this proposal conforms to common implementations of the reliable 
> messaging Communication pattern, and is very useful, especially if you want 
> to implement queueing and transaction support. (Reliable messaging comes with 
> many names. Other popular names are Assured service, or Exactly Once 
> delivery.)
> 
> On 8 December 2015 at 17:40, XMPP Extensions Editor  wrote:
> 
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Quality of Service
> >
> > Abstract: This specification describes a generic method whereby messages
> > can be sent between clients using a predefined Quality of Service level.
> >
> > URL: http://xmpp.org/extensions/inbox/qos.html
> >
> > The XMPP Council will decide in the next two weeks whether to accept this
> > proposal as an official XEP.
> >
   

Re: [Standards] 2015-12-09 Meeting Minutes

[Peter Waher]

Hello all.
 
Regarding the QoS proposal, I've answered any comments and concerns that I have 
received. I have not received anything from Lance or Tobias yet. If you have 
anything not already discussed in previous mails, please let me know, and I'll 
do my best to answer them.
 
Regarding Peter's comments about reliable messaging being hard: It depends on 
solution. The pattern provided by reliable messaging, and proposed in the 
protoXEP is actually quite straight forward and simple enough to implement even 
in small resource-constrained devices.
 
And the comment of 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 regards,
Peter Waher
 
> ## ProtoXEP Quality of Service: Accept as Experimental
> 
> http://xmpp.org/extensions/inbox/qos.html
> 
>   - -1 Dave
>   - -1 MattJ
>   - -1 Lance
>   - Tobias on list
> 
>   - PSA notes that ensuring exactly once delivery is hard
>   - MattJ notes that MQTT does it, but is not federated
> 
> ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quality of Service

[Peter Waher]

Hello Matthew.
 
Thanks for your comments. Please see my responses 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. As I 
> > mentioned to Dave, it does not imply it is highly unreliable, just that it 
> > is somewhat unreliable, as are all asynchronous message protocols, even 
> > more so, if network connections no the client side is intermittent. If the 
> > propability of failure of transmitting a message is small, given suffient 
> > message, the probability of it occurring becomes high.
> 
> I think the key here is whether the XEP is defining a change in
> behaviour to XMPP's standard message delivery, or merely defining a
> standard way of encapsulating properties that messages have in other
> protocols (MQTT and some other systems have QoS in this same model). It's an 
> interoperable way of performing reliable messaging, which is available in 
> many other protocols, such as MQTT, but also several other queueing 
> protocols, and added ontop of other (such as HTTP/Web services).
> 
> That is, if I'm publishing to an MQTT gateway over XMPP, I'd like to
> be able to set the QoS of the message in a standard way, but the XMPP
> server itself should pay no heed to the value. I'd be in favour of
> this approach. Correct. The servers involved are not involved, so to say :) 
> (Unless the server publishes say a a queueing-component supporting QoS, but 
> then it would be the component that would support the XEP.)
> 
> However, introducing the concept of QoS to XMPP itself is
> fundamentally changing the protocol to a different model, and opening
> up a whole can of worms. I'm not in favour of that. XMPP would work as 
> normal. It would only affect clients that need to specify QoS levels.
> 
> I understand the pain if you're trying to make a 1:1 mapping between
> XMPP and MQTT or any other protocol, but honestly, there isn't always
> going to be a sane 1:1 mapping between any two protocols. You're quite
> likely to end up with something overly complex that just makes
> implementers grumble or avoid implementing it. In this case, its the feature 
> of reliable messaging that is important. MQTT is a publish/subscribe protocol 
> that uses reliable messaging. It's not a queueing protocol, like other MQ 
> protocols, MSMQ or AMQP, etc. In this case, I need reliable messaging for, 
> among 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 and 
> reusable in many different cases. Inspiration comes from queueing protocols 
> and IoT protocols. I hope you reconsider and approve of moving the proposal 
> to Experimental. Best regards,Peter Waher 
>  ___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating IBR

[Peter Waher]

Hello Florian
 
Yes, you can prevent mass-registration of non-human users using other 
mechanisms. The important part here is not to depracate the IBR method, but to 
build on it, if possible, in a pluggable manner. The CAPTCHA mechanism provided 
a start for how this can be done. But it not a good method to recommend, as 
dedicated robots today solve CAPTCHA problems quite successfully. (And the 
method selected should not rely on web technologies either, but should be work 
using XMPP alone.)
 
In XEP-0348 I propose a solution where the IBR registration form is signed 
using secret credentials, without revealing the credentials, in a secure manner 
using a signature method that has been around for a while (OAUTH). This makes 
it possible for trusted parties (manufacturer, software provider, device 
make/model etc.) to automatically create accounts, either freely or in batches 
of a specified amount on specific servers. You could also improve on this, by 
making the the signature method pluggable, for instance using Dynamic Forms 
(XEP-0336). This means, you can provide a mechanism (as the one proposed in 
XEP-0348) for things that have no human users, and another method that can be 
used by humanly operated clients (like reCAPTCHA or something similar), where 
you don't want to build in credentials into the firmware. In this way, you 
could create a solution that does not limit it to one specific signature 
method, but that has a pluggable (SASL-like) method, that can 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 no
> > longer deemed a secure protection against bots (see Google's reCAPTCHA).
> > Secondly, it doesn't solve the problem of IoT, with things not operated
> > by humans. Thirdly, you don't want clients to have 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.
> 
> Not if the goal is to prevent mass registration of non-human users. Some
> captcha like mechanisms still hold strong against automated registrations.
> 
> Your IoT case is different. You have non-human XMPP clients. The
> question now is: How to distinguish "bad" clients from "good" ones
> trying to register. If I where to design an approach how those clients
> register an account with an XMPP server, then I would simply make the
> client require a secret token for registration. And this can already be
> done with XEP-0077.
> 
> Or what is your idea how it should work?
> 
> - Florian

  

Re: [Standards] Deprecating IBR

[Peter Waher]

Hello Florian
 
XEP-0158 is not a good idea for Three reasons: First, CAPTCHA is no longer 
deemed a secure protection against bots (see Google's reCAPTCHA). Secondly, it 
doesn't solve the problem of IoT, with things not operated by humans. Thirdly, 
you don't want clients to have 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
> think that there is much need for an XMPP based registration mechanism.
> 
> Why not improve and the missing pieces to IBR XEP instead of deprecating
> it? It appears what IBR lacks is resistance against automated non-human
> mass registrations. So why not make XEP-0158 ? 4. mandatory?
> 
> - Florian

  

Re: [Standards] Deprecating IBR

[Peter Waher]

Hello Tomasz, Sam, Dave & others:
 
> What do you suggest to replace it with?

I've suggested to make IBR secure with form signatures, as described in 
XEP-0348. This would definitely secure things in many cases, and restrict the 
actors that can use automatic methods to create accounts to trusted parties. 
And even trusted parties would be able to only create a certain amount of 
accounts, as controlled by the operator of the broker.
 
An examples when this can be used:
 
Manufacturer gets rights to create N accounts (say 100, 1000 or 1, as an 
example) on a server, and pays for this service. It's up to the manufacturer to 
maintain credentials secure. When device is attempting to create an account, it 
uses these built in credentials to sign the form, and the server Counts down 
the number of accounts that particular actor can still create. Since the number 
of accounts corresponds has a value, the manufacturer is charged with the 
responsibilit to secure credentials in the firmware. (Credentials are probably 
unique to a batch.)
 
Other examples can be envisioned, such as online services or human interface 
clients. The key is as secure as it is difficult to reverse engineer. 
Publically available clients might be more difficult to make secure, while 
privately developed such clients in organizations can. Motivation to implement 
it rises from the fact that the organization wants to streamline installation 
and configuration phases of large projects.
 
> I suggest we replace it with nothing. However, as usual, I think we
> should take this one step at a time and first deprecate, THEN create
> something new if the need arrises (chances are, no one will do the
> work until they have to, so let's go ahead and deprecate). We can
> discuss alternate solutions in a different thread.
> 
> ?Sam
> 

Need aleady exists. I invite you to read XEP-0348 
(http://xmpp.org/extensions/xep-0348.html), especially §3.1, and return any 
comments, questions and suggestions.
 
> Anything that's fully automated will suffer the same problems.
> 
> I'm thinking we need to go back to user stories on this one - we need, I
> think, a mechanism which takes a potential new user through new account
> creation, and helps in configuring their client, and ideally works across
> multiple servers. And we need it to be as resistant to automation and
> multiple registration as possible.
> 
> It's not an easy problem to solve, but we do know that "classic" IBR is
> dangerously flawed.
> 
> Dave.
 
It all depends on what "fully" means here. XEP-0348 provides a mechanism 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

  

Re: [Standards] Deprecating IBR

[Peter Waher]

Hello
 
While I'm for deprecating unsecured IBR, IBR still has an important role in 
automation, especially in IoT, if it is made secure, as proposed in XEP-0348, 
§3.1. It provides a means of controlling amounts of accounts that can be 
created, and by whom (parties trusted to create certain 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:
> 
> In light of spam attacks using throw-away accounts, and given than 77 is 
> final and we?re not going to be able to mandate a significant overhaul, is it 
> time to deprecate (and obsolete) 77 and send a clear message that this should 
> not be being used on open networks?
> 
> /K

  

[Standards] Questions regarding Diffie-Hellman

[Peter Waher]

Hello
 
Regarding the latest report concerning vulnerabilities in the Diffie-Hellman 
key Exchange [1] (short introduction in [2]) and the logjam attack [3], is 
there anyone with experience in securing encypted channels or 
end-to-end-encrypted channels using either 2048 bit keys or elliptic 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://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Practical_attacks_on_Internet_traffic
[3] https://en.wikipedia.org/wiki/Logjam_(computer_security)
  

Re: [Standards] Request HTTP upload slots over XMPP

[Peter Waher]

Hello Edwin

 

 So, you're suggesting an in-band transfer mechanism for out-of-band data 
 transfers?  That sounds a bit wasteful to me. 

 

XEP-0332 allows the client and server to use different methods based on your 
requirements and capabilites. It supports both chunked transfer, as well as 
file transfer, in-band byte streams and Jingle. If out-of-band transfer is 
necessary for bandwidth requirements, I suggest the Jingle transfer method. 

 

An in-band method, or a properly negotiated P2P method out-of-band, would 
handle the case where the server resides behind a firewall, 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: Edwin Mons [mailto:j...@edwinm.ik.nu] 
Skickat: den 1 juli 2015 03:40
Till: XMPP Standards
Ämne: Re: [Standards] Request HTTP upload slots over XMPP

 

On 30/06/15 19:45, Peter Waher wrote:

Hello Daniel

 

You could use XEP-0332, HTTP over XMPP, to do this. To upload content, simply 
perform a PUT, and you can then retrieve it using a normal GET.

http://xmpp.org/extensions/xep-0332.html#PUT

 

If content is small, you can do the transfer in the same request. Otherwise, 
chunked service can be used, or integration with sipub, ibb and/or jingle as 
well, depending on capabilities.


So, you're suggesting an in-band transfer mechanism for out-of-band data 
transfers?  That sounds a bit wasteful to me.  By the way, how are updates to 
332 progressing?

Edwin

Re: [Standards] XEP-0322: EXI for constrained processing environments

[Peter Waher]

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 configurations
(§2.6). With a quick configuration ID, the entire setup is predefined. It
can be defined, either in-band using a normal handshake, as described
earlier, perhaps by a more powerful device, or out-of-band, by manual
configuration of the server.

 

There is no §2.6 - did you mean §2.2.6?

 

Correct. Thanks for spotting.

 

 Also this negotiation of quick configuration happens in XML prior to the EXI 
 switch doesn't it?

 

The document specifies one way to generate this quick configuration, in-band. 
It does not limit the ways such quick-configurations are handled by the server. 
It is understood that these quick configurations are managed by the server, and 
hence can be administrated on the server (without explicitly stating so). We 
have discussed this internally, that it can be used to preinstall 
configurations on the server. But, since it is out-of-band and server-specific, 
we didn’t include this in the XEP.

 

Note that we included a configurationLocation attribute (§3.11) to be able to 
automate preconfiguration of what schemas to include, where the devices are not 
capable of performing an XML handshake and configuration negotiation. But since 
these preconfiguration files/schemas might depend on EXI library being used, 
we’ve stated that it is server-specific.

 

 Rick's problem is that he wants to have no XML processing.

 

These preconfigurations can be accessed by the alternate binding also. (§2.4, 
step 13, and §3.11).

 

 On that basis, I'm thinking a distinct port is the most sensible, which would 
 mean a different SRV name. It may be possible to combine these ports into a 
 single autodetecting port, but I'd rather leave that experiment outside a 
 spec for now.

 

The document defines a DNS SRV record for the alternative EXI binding in §2.4.1.

 

Best regards,

Peter

Re: [Standards] XEP-0322: EXI for constrained processing environments

[Peter Waher]

Hello Rick

Thanks for your input. For small devices, that do not wish to (or cannot)
perform a dynamic handshake, there's the concept of quick configurations
(§2.6). With a quick configuration ID, the entire setup is predefined. It
can be defined, either in-band using a normal handshake, 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-0322: EXI for constrained processing environments

Hello,

I was happy to run into XEP-0322, explaining a path of integration for the
compact XML representation of EXI.

The fully specified path assumes starting off with fullblown XML and then
switching to EXI; this is a scenario that would work when the viewpoint is
saving bandwidth.  Another usecase, where EXI serves the relative simplicity
of a client, is not really dealt with under the usual clarity.

I am thinking of constrained processing environments, such as clients on
microcontrollers.  These may want to use EXI to avoid having to deal with
the full XML notation, and they would most certainly not be serviced if they
have to go through an initial handshake based on XML. 
Although 2.4 gives some ideas and possibilities, its style sounds
informative (ex. and e.g.) rather than normative, which means that there
is non real certainty to be drawn.  I am writing to emphasise that this
should IMHO be cleared up before finalising this XEP.

As for the EXI cookie, is it an idea to use a processing instruction and/or
XML declaration that would be sent to the server?  That would be in line
with common XML syntax without adding the burden of XML parsing onto the
(constrained) client.  A few forms could be used, and in all honesty, may be
better standardised as part of EXI than as part of
XEP-0322 because it would occur everywhere EXI is used:

?xml version=1.0 syntax=exi? (illegal 1.0 syntax)
?xml version=1.0-exi?   (illegal 1.0 syntax)
?xml version=1.0 exi=1.0?(illegal 1.0 syntax)
?xml version=1.1?(breaks with 1.0 requirements)
?exi version=1.0? (after ?xml...? -- upon recognition, respond
with the same string, would otherwise ignored?)

Ref: http://www.w3.org/TR/REC-xml/#sec-pi and
http://www.w3.org/TR/REC-xml/#sec-prolog-dtd

This approach would save from specifying another port, and it would be easy
to send/process in a constrained environment.  Adding NS negotiation might
be possible along the same lines, but would already be more complex.  Still,
not having to build an XML processor to be able to switch to EXI seems like
a really good usecase to me.

I hope this is useful!

Cheers,
 -Rick

Re: [Standards] Request HTTP upload slots over XMPP

[Peter Waher]

Hello Daniel

 

You could use XEP-0332, HTTP over XMPP, to do this. To upload content, simply 
perform a PUT, and you can then retrieve it using a normal GET.

http://xmpp.org/extensions/xep-0332.html#PUT

 

If content is small, you can do the transfer in the same request. Otherwise, 
chunked 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

current file transfer techniques in XMPP all share the same downside. They are 
P2P and thus don't work with Carbons and MUCs. The synchronous nature of P2P 
protocols also doesn't play nicely with MAM.

Uploading files manually to an HTTP server and sharing the link has been an 
workaround for this for a long time now. (This has also been used in the good 
old IRC age)

While users have a variety of services to choose from (imgur, mediacrush, self 
hosted OwnCloud, Google Drive, ...) the major downside of this is that an xmpp 
client can not automate this process since the different services don't share a 
common api.

Furthermore using a third party service might require the user to enter 
additional credentials on top of the XMPP credentials.

Thus it would make perfect sense to have the xmpp provider also provide a way 
to upload files to an HTTP server.

Today I want to introduce a simple protocol for requesting what I call 'HTTP 
upload slots'.

An HTTP upload slot is basically a tuple of a PUT and a GET URL.

The user requests a slot from a component (most commonly running on the users 
servers and discoverable by disco items) providing a desired file name and a 
file size. The component does some checking on the data (quota, max file size, 
authorization) and provides the user with a PUT and a GET url which both are 
unique. (long random string in path)

Examples

 

out:

 

iq to='upload.domain.tld' id='random1' type='get'

request xmlns='urn:xmpp:http:upload'

filenamea_picture.jpg/filename

/request

/iq

in:

iq to='u...@domain.tld' id='random1' type='result'

slot xmlns='urn:xmpp:http:upload'

gethttps://download.domain.tld/a_long_randomly_generated_path/a_picture.jpg/get

puthttps://upload.domain.tld/a_long_randomly_generated_path/a_picture.jpg/put

/slot

/iq

Note that the get and put host are not the same. This allows for the files to 
(optionally) be served over some standard HTTP server /or even a CDN.

Also note that the user provided file name is reflected in the GET url as well 
this way allowing the recipient of that URL to see the original file name. 
(However this is the something a sane component should do and is not required)

 

I would like to get some comments before I actually put this down into a XEP.

For those interested here: https://github.com/siacs/HttpUploadComponent is a 
sample python implementation of such a component.

And here is a branch for Conversations that can talk to that component. 
https://github.com/siacs/Conversations/tree/feature/http_upload

cheers

Daniel

Re: [Standards] Proposed XMPP Extension: REST with XMPP

[Peter Waher]

Hello

You can already do REST over XMPP using XEP-0332 (HTTP over XMPP), as mentioned 
in the proposal:
http://xmpp.org/extensions/xep-0332.html

This extension is used in UPnP+ architecture documents, where they extend UPnP 
to XMPP, extending the reach of billions of devices to XMPP.

The arguments mentioned for not using XEP-0332 are the following:

1.services are discoverable and explorable,
2.asynchronous invocation can be performed in parallel,
3.generation of clients on the fly based on the capabilities of resources, and
4.multiple input and output types definitions are possible.

Regarding (1): Services are discoverable and explorable even using HTTP over 
XMPP. One such method is CoRE, that is also used in CoAP, and is standardized 
by IETF. Another is WADL, as is mentioned by the REST over XMPP proposal. Other 
proprietary methods are also available.
https://datatracker.ietf.org/wg/core/charter/
http://www.w3.org/Submission/wadl/

Regarding (2): This can be done using HTTP over XMPP as well. (Nothing 
prohibits you from doing it, except a gentlemen's agreement in the original 
HTTP specification, something that is not even kept in modern HTTP solutions.)

Regarding (3): What does generation of clients on the fly mean? If it means 
what I think it means, there's nothing that prohibits you from doing this with 
XEP-0332.

Regarding (4): There are multiple ways to define multiple resources in HTTP, 
both for input and output as well.

Instead, it seems that this is the true argument: ... but requires an 
implementation of both protocols: XMPP and HTTP. Well, the alternative seems 
to require both XMPP and REST over XMPP. And if you define a REST interface 
(which presupposes a HTTP, or CoAP-like interface), would it be a stretch? 

Also, using REST over XMPP, you have the following problem: Say you actually 
create a REST over XMPP API. There are two possibilities:

a) Either the API is for proprietary use, i.e. no interoperability is intended. 
Why then not create a proprietary interface instead of creating an abstraction 
that implies additional complexity in the implementation stage?

b) Or the API is for use by third parties in an interoperable setting. But 
those parties, who wants to consume REST APIs, are both familiar with HTTP (or 
CoAP)-based REST-APIs, and 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 is very common 
today.

Best regards,
Peter Waher


-Ursprungligt meddelande-
Från: XMPP Extensions Editor [mailto:edi...@xmpp.org] 
Skickat: den 11 maj 2015 15:22
Till: standards@xmpp.org
Ämne: [Standards] Proposed XMPP Extension: REST with XMPP

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: REST with XMPP

Abstract: This specification defines how the Representational State Transfer 
(REST)
  architectural style can be applied to an XMPP overlay network. It specifies 
  an XMPP protocol extension for accessing resources and transporting resource 
metadata and XML-REST encoded 
  requests and responses between two XMPP entities.

URL: http://xmpp.org/extensions/inbox/rest.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.

Re: [Standards] What does The message headers matched a filter rule mean?

[Peter Waher]

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: XMPP Standards
Subject: Re: [Standards] What does The message headers matched a filter rule 
mean?

On 21 Nov 2014, at 16:04, Peter Waher 
peter.wa...@clayster.commailto:peter.wa...@clayster.com wrote:

I’ve tried (unsuccessfully) to mail the editor, and always get the response the 
message is held until the list moderator can review it for approval, based on 
the fact that “The message headers matched a filter rule”. What does this mean? 
(Trying the standards list, in case my evil headers are accepted there.)

Due to the amount of spam that account receives, there is a rule set up, but I 
think it lets anything through if it has “xep” in the subject.

—
Ash

[Standards] What does The message headers matched a filter rule mean?

[Peter Waher]

Hello

I've tried (unsuccessfully) to mail the editor, and always get the response the 
message is held until the list moderator can review it for approval, based on 
the fact that The message headers matched a filter rule. What does this mean? 
(Trying the standards list, in case my evil headers are accepted there.)

Best regards,
Peter Waher

Re: [Standards] Last call XEP-0322 XEP-0332

[Peter Waher]

Hello everybody

Sorry for being out of touch and not having responded to the many mails. I've 
been overwhelmed by work, and have had to focus on certain things to be able to 
clear things up. It is my plan to retake the effort, review all input made to 
the standards list, and update 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

Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)

[Peter Waher]

Hello Matthew

Thanks for your input. My responses to each one of your comments, below:

Two small comments:

  1) I see the examples have been fixed for streamid - streamId.
However it's worth noting that we've always conventionally used lowercase 
attributes and element names in XMPP.

I've noted a mix of syntaxes in different XEPs. Is there some kind of syntax 
convention extensions should adhere to? I know this has been discussed somewhat 
earlier. Haven't seen one, however. If the XSF wants to streamline syntax in 
new XEPs, it might be a good idea to start some kind of discussion regarding 
this, and include some guidelines in XEP-0001.

Personally, I've tried to use camel casing for attributes in all XEP's I've 
written myself. The main reason for this, is not style as such, even though it 
is easy enough to read, but to avoid the hyphen sign (-), which is often used 
as an alternative to separate words where lower-case-only names are used. The 
hyphen sign does not map well into other scripting languages, etc., and creates 
a lot of extra work, if you want to do more with the XML and schema, than 
simply use it for documentation, streaming and validation. (Other examples 
might be transformation between versions or formats, automatic code generation, 
searching, mapping in script, etc.)

  2) Servers that don't route messages in order are violating 
 http://xmpp.org/rfcs/rfc6120.html#rules-order - though we've ended up with 
 similar attributes in XEP-0047 and XEP-0301, so there is some precedent. Also 
 both these XEPs call the attribute 'seq', another opportunity for consistency.

Regards,
Matthew

Ok. Is this important to change? I would prefer not to 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

Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)

[Peter Waher]

Hello Philipp

Thanks for your comment. Just wanted to point out the possibility as such, even 
though it would probably not be used by the web server. Since content is 
normally returned based on query parameters and request headers, the actual 
content selection would probably be made by the underlying web server, and it 
would return the corresponding stream. But since there are formats including 
multiple streams, my thought was to point out the possibility of using this 
fact, as a possibility to optimize performance in such cases.

What do you refer to, when you say the new jingly-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 Extensions Editor:
 Version 0.3 of XEP-0332 (HTTP over XMPP transport) has been released.

 Abstract: This specification defines how XMPP can be used to transport HTTP 
 communication over peer-to-peer networks.

 Changelog: [See revision history] (pw)

 Diff: http://xmpp.org/extensions/diff/api/xep/0332/diff/0.2/vs/0.3

 URL: http://xmpp.org/extensions/xep-0332.html


one thing I noticed:
Using Jingle in this way makes it possible for an intelligent
server to return multiple streams the client can choose from,
something that is not done in normal HTTP over TCP. The first
candidate should however correspond to the same stream that
would have been returned if the request had been made using
normal HTTP over TCP.

That is not how candidates or ice work. You want either multiple contents or 
the new jingle-pub stuff.

Re: [Standards] Multiple resource binding

[Peter Waher]

Hello Dave  Peter. Thanks a lot for your responses. I’ll forward these to the 
UPnP forum, where the question arose.
Best regards,
Peter


From: Dave Cridland [mailto:d...@cridland.net]
Sent: den 1 juli 2014 11:51
To: XMPP Standards
Subject: Re: [Standards] Multiple resource binding

Most XMPP servers use the resource name as a key into a lookup table, and 
overstamp any inbound stanza with the client's (single) full jid before 
forwarding. This does a number of useful things: Firstly, it eliminates any 
possibility of a client using the wrong from address, and secondly it 
eliminates any need for the server to valdiate and/or stringprep the supplied 
address. For these and other reasons, the server implementors generally pushed 
back hard against XEP-0193 and similar mechanisms.

I'm personally in the anti-XEP-0193 camp, and I've not seen anything that 
suggests this should change.

RFC 6120 doesn't allow multiple resource bindings to happen; however it's not 
tremendously explicit. It does, however, say at one point that:


   A server SHOULD allow an entity to

   maintain multiple connected resources simultaneously, where each

   connected resource is associated with a distinct XML stream and is

   differentiated from the other connected resources by a distinct

   resourcepart.







-Original Message-
From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
Sent: den 1 juli 2014 12:29
To: XMPP Standards
Subject: Re: [Standards] Multiple 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 does every

 resource need a proper connection? Or can I simply invent my resource

 names as I go along (as long as I send presence), and if I don’t

 specify a resource name in a message, the “default resource name”,

 i.e. the bound one, is implicitly used?



 I noticed XEP-0193 (now obsoleted) discusses this, and it says the

 recommendations were not introduced in RFC 6120. Does 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.



We discussed this in the XMPP WG, and decided against pursuing it. Thus a bare 
JID can have multiple full JIDs associated with it, but only by means of 
separate sessions over separate connections.



Peter

[Standards] Multiple resource binding

[Peter Waher]

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 does every resource need a proper 
connection? Or can I simply invent my resource names as I go along (as long as 
I send presence), and if I don't specify a resource name in a message, the 
default resource name, i.e. the bound one, is implicitly used?

I noticed XEP-0193 (now obsoleted) discusses this, and it says the 
recommendations were not introduced in RFC 6120. Does 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

Re: [Standards] UPnP and XMPP

[Peter Waher]

Hello Steffen

The comments provided to the UPnP Cloud Task Force have been received, and are 
now being reviewed during a 60 day review period. A statement from the UPnP 
Forum will probably not be made until after this period.

To be member of any Task Force or Committee you need to be a UPnP Forum member. 
The Cloud Task Force (which deals with XMPP) and IoT Task Force (Sensor UPnP 
interfaces) are for steering committee members only, and invited members. 
There's a Multi-Screen Working Committee also. Not sure if it is for steering 
committee members only ( invites) or if any member can join, or how far 
they've come in their work. Anyhow, once you have signed the basic membership 
form and become a member, I can introduce you to the groups and people working 
in these groups. If you have experience and are interested in these fields, I 
don't see a reason why 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: Steffen Larsen [mailto:zoo...@gmail.com] 
Sent: den 11 juni 2014 17:04
To: XMPP Standards
Cc: Jabber/XMPP software development list
Subject: [Standards] UPnP and XMPP

I haven't heard anything from the XMPP/UPnP Liaisons, but I just stumbled over 
this on the UPnP homepage (http://upnp.org/news/2014/): 
https://www.youtube.com/watch?v=V-QpNnQrT2Ulist=UUY7zsGPIO9PRbUDv1obTBWQ

Personally I am hoping for some progress for Multi-Screen and XMPP which I have 
been working with for a while. Anyone know how I can get involved in this 
Committee? Any of you Liaisons that have been involved?

I thought it might be interesting for you guys. :-)

#Standards #XMPP #MUC #CLOUD 

-Cheers!
/Steffen

Re: [Standards] New revised version of proposal: Signing Forms

[Peter Waher]

-0235 so that it addresses the use cases for Signing Forms.

I hope you reconsider, taking the above comments into account.

Best regards,
Peter Waher

---BeginMessage---
Hello



Regarding IBR and a new proposal, it would be really great to have your input 
before I start, to avoid losing time needlessly.



And on a related topic, what happened to the OAUTH  XMPP effort?

http://xmpp.org/extensions/xep-0235.html

http://mail.jabber.org/pipermail/standards/2009-December/022923.html



Do you share the conclusion of Eran Hammer, that OAuth 2 is not a good idea?



Best regards,

Peter Waher



PS: Thoughts about making IBR secure in open networks:



Hello Peter  community



As I mentioned before, I have an idea on how to make IBR secure. It would work 
as follows:



* A manufacturer, or responsible party, would create an account on the xmpp 
server, or have an account created for him by an operator. There he/she could 
be allowed to create a certain number of accounts automatically.

* The manufacturer would get a shared secret (say an API Key) identifying the 
account.

* Each device or application wanting to perform IBR would have this key 
configured.

* When the device or app connects to the server, using IBR, it returns a 
registration form, as specified in IBR. But one (or two) of the fields would 
contain a challenge.

* The device or application fills in the response field according to the shared 
secret and the challenge. Perhaps using OAUTH.

* When registering, the new account would be discounted from the pool of 
accounts permitted by the key.

* If a shared secret gets to be known, the manufacturer or responsible party 
can just choose to generate a new shared secret (or key).



In this way operatos of the xmpp server can have control of who are trusted to 
create accounts automatically. And they in turn 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







From: Peter Waher
Sent: den 3 april 2014 10:56
To: Peter Saint-Andre
Subject: IBR



Hello Peter



It would be great to have your input on the IBR question and my proposal, 
before continuing.



Best regards,

Peter Waher

---End Message---

Re: [Standards] New revised version of proposal: Signing Forms

[Peter Waher]

Hello Dave,

Thanks for the valuable input. Sorry for the delay in responding. I’ll address 
your comments and suggestions one at a time:

Last one on my list. :-)

First off, it's unclear why, in §2.4, PStr does not include the 'from' 
attribute if available? I also suspect it should include the 'to' only if 
given in the stanza, and finally I think your use of type should be replaced 
with form_type to avoid confusion with the stanza's type attribute.

The reason was to stick to the OAUTH algorithm as defiend for the web, where 
BStr is defined as:

BStr:=Escape(method)+''+Escape(url)+''+Escape(PStr)

(method=GET/POST; etc..)

The closest match in XMPP the method parameter has is the type attribute used 
when submitting the form, and the closest match to the url parameter is the 
to-attribute. It is the actual ‘type’ attribute that is referred to. (I’ve made 
a small change to highlight this.) The form_type parameter is already included 
in PStr:

BStr:=Escape(type)+''+Escape(to)+''+Escape(PStr)

Clarification now reads:

“The Signature Base String (BStr) is then formed concatenating Escape(type) 
(the 'type' attribute of the form used when submitting the form), Escape(to) 
(the full destination address, including resource, if any) and Escape(PStr), 
using ampersands ('') as delimiter.“

OK?

Note however, that you can include any parameter in the signature, by posting 
hidden parameters on the form.


Next, typo - Example 6 should presumably have a title of PLAINTEXT.

Thanks. Corrected.

Overall, I really think that using the FORM_TYPE here is wrong - it means the 
only forms that can be signed are form signing forms, which seems somewhat 
introspective. Instead I recommend defining a new signing indicator, perhaps a 
field SIGNED. It's not *wonderfully* clear in XEP-0068 whether additional 
generic field names such as this, or the oauth ones, can be registered in such 
a way, but we can change that to accommodate this.

The reason I feel strongly here is because I'd like to be able to potentially 
sign forms such as MUC configurations, and the current proposal essentially 
prevents this.

Yes, I was thinking about this also. I was thinking, that instead of defining a 
completely new FORM_TYPE, just to define a suffix, for instance 
“:signature:oauth1”. This would make it easier for clients to understand. 
Examples:

For signed in-band registration with form signature:
jabber:iq:register:signature:oauth1

For in-band registration with CAPTCHA:
urn:xmpp:captcha: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 
peter.wa...@clayster.commailto:peter.wa...@clayster.com wrote:
Hello

I had forgotten to add an Acknowledgements section to the previous version. 
Here, an updated version with acknowledgements. If I’ve forgotten anybody, 
please let me know.

Best regards,
Peter Waher

From: Peter Waher
Sent: den 9 maj 2014 18:12
To: standards@xmpp.orgmailto:standards@xmpp.org
Cc: XEP Editor (edi...@xmpp.orgmailto:edi...@xmpp.org)
Subject: New revised version of proposal: Signing Forms

Hello

Attached is a revised version of the proposed XEP: Signing Forms.

All input from the community and the council has been addressed, mostly minor:


• Removed links to articles expression opinions.

• Reformulated the reference to SASL in the introduction.

• A reference to Unicode Standard Annex #15, Unicode Normalization 
Forms, and NFC normalization has been added.

Please add this to the inbox.

Best regards,
Peter Waher

Re: [Standards] UPDATED: XEP-0325 (Internet of Things - Control)

[Peter Waher]

Hello Teemu

Yes, the original plan was only to include sensor data. But that is easily 
mended, so the XEP could show both how to publish sensor data (based on 
XEP-0323), and how to publish control commands (based on XEP-0325). Would that 
be sufficient, or do you see more use cases you would 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 pubsub nodes 
and from there to subscribers. We have been using mostly SOX protoxep for that 
purpose.. I meant controlling, configuring, etc. sensors with pubsub. Should 
there be two different XEPs are will that one handle both directions?
-Teemu

2014-04-21 17:55 GMT+03:00 Peter Waher 
peter.wa...@clayster.commailto:peter.wa...@clayster.com:

Hello Teemu



I've on my to-do list a working item to write just such a document. It has been 
on the list for a while, and in XEP-0323  0325 it is called:


xep--IoT-PubSub

Defines how efficient publication of sensor data can be made in sensor networks.




But it seems to be the 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.commailto:uol...@gmail.com]
Sent: den 20 april 2014 14:34
To: XMPP Standards
Subject: Re: [Standards] UPDATED: XEP-0325 (Internet of Things - Control)



Hi all.



As Peter mentions in LinkedIn thread

https://www.linkedin.com/groupItem?view=item=5862110582659891202type=membergid=49429



If you don't have the full JID of the sensor, you can publish a set command 
(XEP-0325) to a node on a pubsub server, instead of embedding it in a message 
or iq stanza to the sensor. If the sensor subscribes to the node, it will 
receive the set command and perform the action.



Has anyone defined best practises for such or will them be defined in the next 
version of XEP-0325? I could see pubsub very useful in use cases when there 
are, e.g., one million sensors that require the same command to be executed as 
fast as possible. So they all just get the command from a pubsub node right 
after they come online, but what would be the best mechanism to tell this node 
to all the sensors?



Happy Easter.



-Teemu



2014-04-07 23:53 GMT+03:00 XMPP Extensions Editor 
edi...@xmpp.orgmailto:edi...@xmpp.org:

 Version 0.3 of XEP-0325 (Internet of Things - Control) has been released.



 Abstract: This specification describes how to control devices or actuators in 
 an XMPP-based sensor network.



 Changelog: [See revision history] (pw)



 Diff: http://xmpp.org/extensions/diff/api/xep/0325/diff/0.2/vs/0.3



 URL: http://xmpp.org/extensions/xep-0325.html

Re: [Standards] UPDATED: XEP-0325 (Internet of Things - Control)

[Peter Waher]

Hello Teemu



I've on my to-do list a working item to write just such a document. It has been 
on the list for a while, and in XEP-0323  0325 it is called:


xep--IoT-PubSub

Defines how efficient publication of sensor data can be made in sensor networks.




But it seems to be the 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 Standards
Subject: Re: [Standards] UPDATED: XEP-0325 (Internet of Things - Control)



Hi all.



As Peter mentions in LinkedIn thread

https://www.linkedin.com/groupItem?view=item=5862110582659891202type=membergid=49429



If you don't have the full JID of the sensor, you can publish a set command 
(XEP-0325) to a node on a pubsub server, instead of embedding it in a message 
or iq stanza to the sensor. If the sensor subscribes to the node, it will 
receive the set command and perform the action.



Has anyone defined best practises for such or will them be defined in the next 
version of XEP-0325? I could see pubsub very useful in use cases when there 
are, e.g., one million sensors that require the same command to be executed as 
fast as possible. So they all just get the command from a pubsub node right 
after they come online, but what would be the best mechanism to tell this node 
to all the sensors?



Happy Easter.



-Teemu



2014-04-07 23:53 GMT+03:00 XMPP Extensions Editor 
edi...@xmpp.orgmailto:edi...@xmpp.org:

 Version 0.3 of XEP-0325 (Internet of Things - Control) has been released.



 Abstract: This specification describes how to control devices or actuators in 
 an XMPP-based sensor network.



 Changelog: [See revision history] (pw)



 Diff: http://xmpp.org/extensions/diff/api/xep/0325/diff/0.2/vs/0.3



 URL: http://xmpp.org/extensions/xep-0325.html

Re: [Standards] Need help with problems regarding XEP-0114.

[Peter Waher]

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, on the client side, only one message is received, the one with the 
 resource. Furthermore, no error message is returned:

Have you checked offline storage?

Actually, no, I hadn't checked that. Would have been good if I had. The 
messages that were not forwarded to the client were stored as offline messages.

Since messages were forwarded when given a resource, I just assumed the client 
was considered to be online, which is wasn't, not in the XMPP sense. It had 
just connected, been authenticated, started a session and fetched the roster, 
but not actually sent a presence stanza. So, the server considered it to be 
offline when no resource was present in a message, and stored in in the list of 
offline messages, and online when a resource was present.

Not sure if this is the correct behavior or not, but I now get all operations 
working (except security related opterations like starttls) that are required 
for the IoT Discovery proposal. 

[Standards] Need help with problems regarding XEP-0114.

[Peter Waher]

Hello

I've now examined the possibility to use Jabber Components (XEP-0114) for IoT 
Discovery and Provisioning, but have some problems. Since it's very hard to 
find documentation on this XEP, and searching the internet for solutions only 
returns pages with people having the same problems (but no solutions), I'm 
turning to the XSF community to see if somebody has any good input.

First, I can mention that I can send and receive messages and iq stanzas to and 
from normal JIDs and a component, as long as I have the resource of the 
corresponding JID I want to communicate with. This is no problem, if the client 
itself initiates communication. But what if the server component needs to 
initiate communication? How does the server component obtain the resource(s) of 
a corresponding bare JID?

I've tried a presence probe. That only returns a not-authorized response. The 
reason being that otherwise, it would be a security problem, if the component 
was able to probe the presence of a JID, without being a friend. (However, 
sending messages and iq stanzas to the JID, if you had the resource, was OK, 
even without friendship.)

The next thing I tried was to send a presence subscription to the JID from the 
component. This request was not received by the client, regardless if I tried 
with sending it from the component itself, or a virtual JID simulated by the 
component. Searching the internet, this was the response I was given: You 
needed to simulate accounts behind the component (using the same component 
domain name).

Is there a step that needs to be taken before sending the presence 
subscription, for it to be routed correctly to the device?

Or is presence subscriptions somehow disabled in server components?

Or might this behave differently on different XMPP servers? (I'm using an 
OpenFire XMPP server to test my implementation.)

Example of communication that goes well. Here the component, given the full JID 
of a client, is able to perform an IQ get  receive a response:

C: iq from='test.clayster.cl' to='unitt...@clayster.cl/2e2b3ea4' type='get' 
id='1'query xmlns=http://jabber.org/protocol/disco#info//iq
S: iq from=unitt...@clayster.cl/2e2b3ea4 to=test.clayster.cl type=result 
id=1query xmlns=http://jabber.org/protocol/disco#info;identity 
category=client type=pc name=Clayster/feature 
var=http://jabber.org/protocol/disco#info/feature 
var=http://jabber.org/protocol/disco#items/feature 
var=jabber:iq:roster/feature var=jabber:iq:version/feature 
var=vcard-temp//query/iq

While, on the client side, it looks as follows:

S: iq from=test.clayster.cl to=unitt...@clayster.cl/2e2b3ea4 type=get 
id=1query xmlns=http://jabber.org/protocol/disco#info//iq
C: iq from='unitt...@clayster.cl/2e2b3ea4' to='test.clayster.cl' type='result' 
id='1'query xmlns=http://jabber.org/protocol/disco#info;identity 
category=client type=pc name=Clayster/feature 
var=http://jabber.org/protocol/disco#info/feature 
var=http://jabber.org/protocol/disco#items/feature 
var=jabber:iq:roster/feature var=jabber:iq:version/feature 
var=vcard-temp//query/iq


This is how the failed attempt looks like, where the component itself makes a 
presence probe to retrieve the resource of a bare JID. When it fails it tries 
to request a subscription on presence.

C: presence id=dba12ec4de04b5575d1070ae730aa351 from=test.clayster.cl 
to=unitt...@clayster.cl type=probe/
S: presence type=error to=test.clayster.cl 
from=unitt...@clayster.clerror code=401 type=authnot-authorized 
xmlns=urn:ietf:params:xml:ns:xmpp-stanzas//error/presence
C: presence id=dba12ec4de04b5575d1070ae730aa351 from=test.clayster.cl 
to=unitt...@clayster.cl type=subscribe/

Nothing is received on the client side. I try the same thing, but with a 
simulated account behind the component domain:

C: presence id=e107698373251736e53678e2e4fc1a2d 
from=unitt...@test.clayster.cl to=unitt...@clayster.cl type=probe/
S: presence type=error to=unitt...@test.clayster.cl 
from=unitt...@clayster.clerror code=401 type=authnot-authorized 
xmlns=urn:ietf:params:xml:ns:xmpp-stanzas//error/presence
C: presence id=e107698373251736e53678e2e4fc1a2d 
from=unitt...@test.clayster.cl to=unitt...@clayster.cl type=subscribe/

Nothing is received by the client.

Hopefully, somebody with more insight can answer the above questions, or give 
other insights on how to proceed. If I 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

Re: [Standards] Need help with problems regarding XEP-0114.

[Peter Waher]

Hello Waqas  community.

Thanks a lot for taking your time to help. See my comments to each one of your 
responses. It seems they do not work.

Your component can send messages to the bare JID of the user, which would then 
be sent to the resources with highest priority (depending on server config, 
etc). That's the normal way to initiate a conversation with a bare JID when you 
don't have a full JID available.

Trying this on the server I use (OpenFire), messages (and IQ stanzas) sent to 
bare JIDs are not forwarded to the corresponding client. Should it?

Sending two messages from the component:

C: message from=test.clayster.cl to=unitt...@clayster.cl/f9e7b2c1 id=1 
xml:lang=sv type=normalNormal messagebodyhej/body/message
C: message from=test.clayster.cl to=unitt...@clayster.cl id=2 
xml:lang=sv type=normalNormal messagebodyhej/body/message

However, on the client side, only one message is received, the one with the 
resource. Furthermore, no error message is returned:

S: message from=test.clayster.cl to=unitt...@clayster.cl/f9e7b2c1 id=1 
xml:lang=sv type=normalNormal messagebodyhej/body/message

Which XMPP server do you use, where this works? Is it possible for me to try to 
connect to a component to that server and see if it works differently then 
OpenFire?

Searching RFC 6120, I cannot see if sending messages and IQ stanzas to bare 
JIDs is actually allowed or not. What I find in RFC 6120 is that responding 
differently to requests sent to bare JIDs and full JIDs allows for directory 
harvesting, which is considered bad. I interpret this as a recommendation to 
disallow (and not respond) to messages/requests sent to bare JIDs, since it's 
the only way to avoid responding differently ...

Does anybody has some light to shed on this?


Regarding presence subscriptions, is your component doing any roster handling? 
It has to send a subscription request to the user, and receive the user's 
subscription acceptance, optionally storing this information (as the 
component's roster), after which it can probe the user (assuming the user 
accepted). The XMPP server does not manage rosters or subscriptions for 
XEP-0114 components. It only does so for users. The server mainly handles XMPP 
Core (RFC 6120) for components, while everything in XMPP IM (RFC 6121) is up to 
the components themselves.

I do send a presence stanza with a presence subscription request, in case the 
probe fails. Regarding roster: Since the roster is handled (or simulated) by 
the component, in what way other than sending a presence subscription stanza, 
should the component perform roster handling with the server? I thought roster 
handling was between client and its server, but not between servers or between 
component and server.

What I do is:

presence id=e107698373251736e53678e2e4fc1a2d 
from=unitt...@test.clayster.cl to=unitt...@clayster.cl type=subscribe/

A corresponding presence is not received by the client. What case of roster 
handling is supposed to happen before?

What happens between servers when I add a contact to an account on server 1? 
Does roster requests between client and server1 get propagated to server 2 
also? Is this not handled by the presence stanza?

Furthermore, I find in §3.1.1 in RFC 6121 the following statement:

  Implementation Note: Many XMPP clients prompt the user for
  information about the potential contact (e.g., handle and
  desired roster group) when generating an outbound presence
  subscription request and therefore send a roster set before
  sending the outbound presence subscription request.  This behavior
  is OPTIONAL, because a client MAY instead wait until receiving the
  initial roster push from the server before uploading user-provided
  information about the contact.  A server MUST process a roster set
  and outbound presence subscription request in either order (i.e.,
  in whatever order generated by the client).

Does that not mean 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

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Peter Waher]

Hello Edwin  Co.

You seem to confuse Historical with Deprecated.  Although the XEP is 
historical, the status is active.  Furthermore, all servers I have used so far 
support XEP-0114: this is a core feature of most implementations.

Actually, I do not. I am aware of the difference. What historical tells me, 
apart from it being historical, i.e. part of the Jabber project before being 
formalized, is that it:

* Is not sufficiently important to have been lifted and issues discussed and 
fixed, to become draft or final (or RFC).
* Any changes to it are not guaranteed to be backwards compatible.
* It's future is unclear, which is also stated in the XEP.
* It's use and implementation variants are unclear.
* Security aspects are unclear.
* It is not recommended by XSF or xmpp.org anywhere.

After having investigated XEP-0114 now in some more detail, there are various 
aspects which concerns me. Since Jabber components seems to be a third way to 
connect to an XMPP server (the other two being c2s and s2s), and a very useful 
one at that I must agree, I think the XSF should take some time and effort in 
formalizing this XEP a bit, and fixing some of its flaws. I'm told that it uses 
an old version of XMPP (0.9), and I wonder if it is not in everybody's interest 
to lift it to v1.0, and allow things such as starttls, etc. to make it more 
secure. Today, there is no way for the client (component) to validate that the 
server is who it pretends 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

Re: [Standards] Jabber Components (XEP-0114) in federated networks

[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 
peter.wa...@clayster.commailto:peter.wa...@clayster.com wrote:
Hello

I have some more questions regarding the Jabber Components protocol:

4) Regarding Federation, can clients on one server access components hosted on 
another? For example: Can client@server1 communicate with component.server2 ?

Yes; the components are externally just another S2S domain.

5) Can a client on one server discover components on another to which it is not 
connected, but with which the first server is federated?

Yes, the components are externally just another S2S domain.

Best regards,
Peter Waher

Re: [Standards] deprecating in-band registration

[Peter Waher]

Hello Peter  community

As I mentioned before, I have an idea on how to make IBR secure. It would work 
as follows:

* A manufacturer, or responsible party, would create an account on the xmpp 
server, or have an account created for him by an operator. There he/she could 
be allowed to create a certain number of accounts automatically.
* The manufacturer would get a shared secret (say an API Key) identifying the 
account.
* Each device or application wanting to perform IBR would have this key 
configured.
* When the device or app connects to the server, using IBR, it returns a 
registration form, as specified in IBR. But one (or two) of the fields would 
contain a challenge.
* The device or application fills in the response field according to the shared 
secret and the challenge. Perhaps using OAUTH.
* When registering, the new account would be discounted from the pool of 
accounts permitted by the key.
* If a shared secret gets to be known, the manufacturer or responsible party 
can just choose to generate a new shared secret (or key).

In this way operatos of the xmpp server can have control of who are trusted to 
create accounts automatically. And they in turn 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...@stpeter.im] 
Sent: den 2 april 2014 00:02
To: XMPP Standards
Subject: [Standards] deprecating in-band registration

Several folks have commented on in-band registration (IBR, XEP-0077) recently, 
wondering aloud whether we really want to recommend it for things like 
registering devices in IoT environments.

I agree with the concerns that people have expressed. I suggest that we push 
this line of thinking to its logical conclusion and strongly consider 
deprecating and then obsoleting IBR. Perhaps - perhaps! - IBR was appropriate 
in 1999 when we were trying to encourage people to easily try out this new 
technology called Jabber. Those days are long gone.

If we feel that we'd like to have some kind of method for account provisioning 
over XMPP - and I'm not convinced that we do - then I feel that we need to 
rethink the whole problem, not reuse something that is fundamentally flawed.

Peter

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Peter Waher]

Hello Philipp

Thanks for your insightful input. My response to the main item:

 section 3.4:
 I don't think IBR should be recommended anymore.

 IoT requires automatic account creation. However, I agree it must also be 
 secure, from the point of view of the server administrator, especially if 
 servers are publically available. I will post a separate XEP soon, that 
 provides a secure in-band registration mechanism that can be used by things.

 section 3.5:
 I would recommend moving the discovery to standard disco#items and to use 
 components (xep-0114) -- those are not much harder to write than standard 
 clients and have many advantages in terms of managability.

 Note sure here how this relates to 3.5. Was it a particular step you 
 referred to?

 Basically I'd like to see the method #3 in 3.5 as the one and only way to do 
 it, with examples. Basically a slightly expanded version of the determining 
 support section:
 disco#items to the server
 then disco#info to each item to look for something which has a 
 urn:xmpp:iot:discovery.

xep-0114 style components are just a very convenient way to do this in most 
server implementation, but I assumed that you had implemented this using a 
registry which was running over c2s. So I mixed up implementation comments and 
protocol comments :-/

I don't have a strong opinion whether that should be done before accepting it 
or afterwards. Might be handy to pretend the other methods never existed.

Ok. I will certainly have a look at the Jabber Components Protocol (XEP-0114). 
Even though it is historical, it looks promising. Is there any more recent 
information available than http://xmpp.org/extensions/xep-0114.html?

One of the mayor problems is that in IoT architecture, we can in many cases not 
choose the XMPP server. In some cases we do, but not in the most important 
cases where for instance large operators or companies already have their XMPP 
server chosen (their own in many cases). Since the XMPP server has already been 
chosen by the operator in these cases, we need a solution that can work 
regardless of XMPP server used.

This does not mean XEP-0114 is not a good idea to use, especially if available. 
The problem is, this cannot be guaranteed. I will most certainly explore this. 
However, is it possible that we do this during experimental phase? This gives 
me some time to investigate how widespread the support for XEP-0114 in the XMPP 
servers chosen for us is. It will 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

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Peter Waher]

Hello Lance

Thanks for taking the time to read the proposal and your input. My responses to 
your concerns below:

 Example: Consider 100'000 devices connecting to an XMPP server they've found 
 somehow, and then need to find a Thing Registry to register themselves. One 
 might be preconfigured, but I want to include the case when one is not. 
 100'000 devices cannot start looping through all possible JIDs and ask 
 service discovery to find out who can what. So it needs, as a last attempt, 
 to try to find it somehow. How do you suggest this done, if you do not 
 accept the methods proposed (as the last resource)?

The approach we would suggest is that the Thing Registry be implemented as a 
server component (and thanks to XEP-0114 can be used with any XMPP server that 
supports XEP-0114, which is to say all of them). A Thing would then iterate 
over the items in a disco#items result for the XMPP server, looking for one 
that provides the registry feature. The disco#items result for a server is on 
the order of tens, not hundreds of thousands. For example, that process is how 
a user discovers SOCKS5 proxies for file transfers.

Implementing a service like the IoT Thing Registry using a client connection 
is, from our collective experience as XMPP devs, ill advised even though it is 
technically possible. Note that several sections of the proposed XEP exist 
solely to work around issues from using a client connection (presence 
subscriptions and limitations with roster sizes) that a server component does 
not need to deal with.


As I responded to Philipp, XEP-0114 looks promising. I take the liberty to copy 
the response to the same argument:

Ok. I will certainly have a look at the Jabber Components Protocol (XEP-0114). 
Even though it is historical, it looks promising. Is there any more recent 
information available than http://xmpp.org/extensions/xep-0114.html?

One of the mayor problems is that in IoT architecture, we can in many cases not 
choose the XMPP server. In some cases we do, but not in the most important 
cases where for instance large operators or companies already have their XMPP 
server chosen (their own in many cases). Since the XMPP server has already been 
chosen by the operator in these cases, we need a solution that can work 
regardless of XMPP server used.

This does not mean XEP-0114 is not a good idea to use, especially if available. 
The problem is, this cannot be guaranteed. I will most certainly explore this. 
However, is it possible that we do this during experimental phase? This gives 
me some time to investigate how widespread the support for XEP-0114 in the XMPP 
servers chosen for us is. It will 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?


However, in terms of re-using existing protocol building blocks, you should 
look into XEP-0077 some more. People seem to overlook that XEP-0077 is not 
just IBR for new XMPP account provisioning, but also a protocol letting an 
existing JID register with an arbitrary service, and then later update or 
remove that registration. Even the cases where you need additional 
information (such as when Concentrators are used) can be handled using 
XEP-0077 if that extra data can be expressed via data forms.

Implementing some new service as a component, and letting users (which in this 
case would be Things) 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

Re: [Standards] deprecating in-band registration

[Peter Waher]

Hello Kevin

Thanks for your input.

 Hello Peter  community

 As I mentioned before, I have an idea on how to make IBR secure. It would 
 work as follows:

 * A manufacturer, or responsible party, would create an account on the xmpp 
 server, or have an account created for him by an operator. There he/she 
 could be allowed to create a certain number of accounts automatically.
 * The manufacturer would get a shared secret (say an API Key) identifying 
 the account.
 * Each device or application wanting to perform IBR would have this key 
 configured.
 * When the device or app connects to the server, using IBR, it returns a 
 registration form, as specified in IBR. But one (or two) of the fields would 
 contain a challenge.
 * The device or application fills in the response field according to the 
 shared secret and the challenge. Perhaps using OAUTH.
 * When registering, the new account would be discounted from the pool of 
 accounts permitted by the key.
 * If a shared secret gets to be known, the manufacturer or responsible party 
 can just choose to generate a new shared secret (or key).

 In this way operatos of the xmpp server can have control of who are trusted 
 to create accounts automatically. And they in turn 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?

If you're at the stage of putting shared secrets into the devices, why not 
generate certs for the devices, and do auto-provisioning of accounts based on 
the certs provided by clients? This doesn't require new protocol and allows 
fine-grained control.

Actually, I've left the nature of the shared secret open at this point to be 
able to have a discussion. I've myself been a proponent for many years of using 
certificates in assuring communication, but with very poor results to be 
honest. It has been very difficult for me to convince product manufacturers why 
they should use certificates, even when it has been possible. The problem with 
certificates is basically: They are costly (either you have to buy them, or set 
up a certificate server) and limited in time. A manufactured product like a 
sensor or meter must have a life span of 10 years. Where do you get a valid 
certificate valid for 10 years, without self-signing one and manually 
installing it in the certificate registry (something you shouldn't do)? Using 
certificates to install system components, especially server components is 
easier to motivate, or to identify public domains even easier.

This trend for a simpler method for authentication than using certificates is 
visible also in API design and mobile app development (paralleling the work to 
simplify web service requests, where developers prefer REST before SOAP). OAUTH 
[1] has become a very popular choice, and is one which I personally am leaning 
on would make a good candidate. It much easier for a non-initiated to become 
started, and it's easy for a production environment, and it is sufficiently 
secure and reliable. There's an IETF draft for a SASL extension to OAUTH [2] 
and large web API operators like Google support it [3]. It is also completely 
free and easy to automate in a production environment (or on a Web API page). 
An XMPP Server can easily produce new valid OAUTH keys by itself.

[1] http://oauth.net/ 
[2] http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14 
[3] https://developers.google.com/accounts/docs/OAuth2 

Actually, Google models their API accounts in a similar way 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

[Standards] Jabber Components (XEP-0114) TLS

[Peter Waher]

Hello

I have some questions regarding the Jabber Components protocol. Couldn't find 
anything about it in the XEP. It would be great if somebody with some insight 
could answer:

1) Regarding TLS:
1a) How is starttls used together with the component protocol and stream 
initiation?
1b) When? Before or after the handshake?

2) Regarding port number:
2a) Is there a default port for this protocol? Is it the same as 
client-to-server communication? Or another? 
2b) OpenFire seems to use 5275, is this common?

3) How about other stream initiation elements, like:
3a) features?
3b) sessions?

XEP-0114 just terminates after the handshake element.

Best regards,
Peter Waher

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Peter Waher]

Hello Philipp

Thanks a lot for the input, and taking the time to read the proposal. I'll try 
to address your concerns one at a time:

 section 3.3.1 describes how to find an xmpp servers. The methods described 
 there aren't limited to iot (at least the dhcp one), so it might be a good 
 idea to split them off. Not sure how useful that is however.

Ok. Can we break this out at a later stage? I agree it makes sense to have §3.3 
in a separate XEP. But can we wait with this until Experimental phase, when it 
is more complete and we have experimented with it a bit?

 section 3.4:
 I don't think IBR should be recommended anymore.

IoT requires automatic account creation. However, I agree it must also be 
secure, from the point of view of the server administrator, especially if 
servers are publically available. I will post a separate XEP soon, that 
provides a secure in-band registration mechanism that can be used by things. 

 section 3.5:
 I would recommend moving the discovery to standard disco#items and to use 
 components (xep-0114) -- those are not much harder to write than standard 
 clients and have many advantages in terms of managability.

Note sure here how this relates to 3.5. Was it a particular step you referred 
to?

 Having hardcoded accounts like 'discovery' is a no-go imo, even with the 
 security considerations.

Ok. Have removed the hardcoded accounts.

 Affects all examples, but that 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

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[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


From: Ivan Vučica [mailto:i...@vucica.net]
Sent: den 27 mars 2014 19:38
To: XMPP Standards
Subject: Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery


Re: section 3.3.x

Doesn't more choices for discovery mean servers and clients need to implement 
all choices? I'd go with the mDNS/DNSSD method only as it is already widely 
used for other discovery uses. DHCP may not be easily configurable by the XMPP 
server administrator.

sent from phone
On Mar 27, 2014 2:36 PM, Philipp Hancke 
fi...@goodadvice.pages.demailto:fi...@goodadvice.pages.de wrote:
Am 13.03.2014 17:26, schrieb XMPP Extensions Editor:
The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Internet of Things - Discovery

Abstract: This specification describes an architecture based on the XMPP 
protocol whereby Things can be installed and safely discovered by their owners 
and connected into networks of Things.

URL: http://xmpp.org/extensions/inbox/iot-discovery.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.

some comments after reviewing it:

section 3.3.1 describes how to find an xmpp servers. The methods described 
there aren't limited to iot (at least the dhcp one), so it might be a good idea 
to split them off. Not sure how useful that is however.

section 3.4:
I don't think IBR should be recommended anymore.

section 3.5:
I would recommend moving the discovery to standard disco#items and to use 
components (xep-0114) -- those are not much harder to write than standard 
clients and have many advantages in terms of managability.
Having hardcoded accounts like 'discovery' is a no-go imo, even with the 
security considerations.
Affects all examples, but that might be a simple search-replace.

section 3.11:
the comment from 3.5 applies here as well.

example 36 closes update instead of search.

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Peter Waher]

Hello Kevin

Thanks for taking the time to read the proposal, and come with input. I'll 
address your concerns one at a time:
 
 section 3.3.1 describes how to find an xmpp servers. The methods 
 described there aren't limited to iot (at least the dhcp one), so it 
 might be a good idea to split them off. Not sure how useful that is however.

 I think it's potentially useful outside IoT.

As I responded to Philipp: Ok. Can we break this out at a later stage? I agree 
it makes sense to have §3.3 in a separate XEP. But can we wait with this until 
Experimental phase, when it is more complete and we have experimented with it a 
bit?

I agree with Fippo that using hard-coded account/nicks isn't right.
This seems to be standard disco all the way - it then doesn't matter what form 
the JID takes, be it user-style or domain-style.

The hard-coded accounts have been removed.

But there seems to be a misunderstanding somewhere, since you and Philipp both 
refer to server-side components for detecting Thing Registries and Provisioning 
Servers. These two are not (necessarily) XMPP Servers. The default case will be 
that they are not XMPP servers. I.e. the XMPP Server is just a replaceable 
infrastructure component, and does not actually host any IoT logic.

Example: Consider 100'000 devices connecting to an XMPP server they've found 
somehow, and then need to find a Thing Registry to register themselves. One 
might be preconfigured, but I want to include the case when one is not. 100'000 
devices cannot start looping through all possible JIDs and ask service 
discovery to find out who can what. So it needs, as a last attempt, to try to 
find it somehow. How do you suggest this done, if you do not accept the methods 
proposed (as the last resource)?

 3.14 seems, at first glance, like it would be a candidate for 55 with 
 extended forms rather than inventing new protocol. Thoughts?

XEP-0055 has several shortcomings when it comes to the search function we've 
proposed. This is why we did not used it. The main arguments against the use of 
XEP-0055 are:

* XEP-0055 require you to get a data form with possible search options. 
Consider a Thing Registry with hundreds of different tags (perhaps thousands, 
since all things can invent their own, and only a few tags are standardized 
in the since they have fixed tag names and meaning, as defined in the 
document). How would such a search form look like? One field for every tag in 
the server? It would quickly diverge into something completely unusable. The 
other method is to have a set of field pairs, one with tag name, and one with 
value. But how many such pairs should be available in the form? The only way to 
solve this without imposing limits is to use dynamic forms that can dynamically 
extend the form as your input values. Needless to say, this is a very complex 
method of accomplishing a simple task.

* We want to include search operation and ranges into the search. Doing this 
would add even further fields to the form. You would need up to 4 fields per 
tag. And again, the fourth field only have meaning if a range operator is used. 
Even here, dynamic forms would be required to make sense of it all.

* How do you solve data types and validation? If you in the form don't know 
beforehand what tag is to be used? Validation of values can only be done if all 
tags are listed (and data types for tags are consistent). But as mentioned 
above, listing all tags in a form is simply not practically an option. 

* There are today no validation schemes available to XEP-0055 for the type of 
input this search required (cross field validation). Some shortcomings may be 
amended by dynamic forms, but the resulting form would just be too complicated, 
according to my point of view. (And I've written the dynamic forms extension.)

* Since Interoperability is very important in IoT, if data forms are to be 
used, the resulting form type must be registered and agreed on, a task that I 
simply judged to be impossible for this case. (i.e. make everybody agree on a 
form type, and then implement support for it)

To conclude: The implementation effort used to build this kind of search (or 
query) on-top of XEP-0055 and data forms would be, in my judgment, far greater, 
and with poor results, than by just including a new search element for this 
particular query, and skipping the data form altogether. Since XEP-0055 is a 
Historic XEP, and not a Draft or Final XEP, it cannot be considered to have to 
be used for every search query done over XMPP networks.

If it is the work search that is bothersome here (since there are many 
queries being done over 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

[Standards] Securing in-band registration

[Peter Waher]

Hello

What methods of securing automatic XMPP account creation (in-band registration, 
XEP-0077) that can be used by machines are you aware of?

I've found XEP-0158. Even though it refers to CAPTCHA, it also has some other, 
not so secure, methods.

I'm looking for a solution that would work as follows:


* A manufacturer can create an account on the XMPP Server. This account 
would identify the manufacturer and/or the application, and have contact 
details for the person responsible for the account. The account holder would 
receive a shared secret.

* A device can use this shared secret (or API key) to identify the 
application during in-band registration, using a challenge/response method 
(perhaps similar to OAUTH), so the secret is not actually transmitted.

* Once the application has been verified, the in-band registration is 
granted.

* Any misuse can be controlled by the operator by revoking the shared 
secret of the application or the entire account.

Maintaining the shared secret inside the device would be a security issue of 
course, but that can be addressed.

Do you know of any such methods, or similar, available?

Best regards,
Peter Waher

Re: [Standards] Last connection time of friend

[Peter Waher]

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 connection time of friend

Am 02.03.2014 20:08, schrieb Peter Waher:
 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.)

http://xmpp.org/extensions/xep-0012.html#offline -- not sure how many servers 
implement it though.

Re: [Standards] Last connection time of friend

[Peter Waher]

Hello Dave

Thanks for the quick response. This looks like exactly what I need.

I'm a little worried about this statement in RFC 6121 though (and the 
explanation a little circular):

   Presence probes SHOULD NOT be sent by a client, because in general a
   client will not need to send them since the task of gathering
   presence from a user's contacts is managed by the user's server.
   However, if a user's client generates an outbound presence probe then
   the user's server SHOULD route the probe (if the contact is at
   another server) or process the probe (if the contact is at the same
   server) and MUST NOT use its receipt of the presence probe from a
   connected client as the sole cause for returning a stanza or stream
   error to the client.

Sending such probes seems to me to be a great way of finding connection 
problems in Internet of Things 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: [Standards] Last connection time of friend

Some servers also respond to a probe with the last offline presence (with a 
timestamp).

On 2 March 2014 19:17, Philipp Hancke 
fi...@goodadvice.pages.demailto:fi...@goodadvice.pages.de wrote:
Am 02.03.2014 20:08, schrieb Peter Waher:

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.)

http://xmpp.org/extensions/xep-0012.html#offline -- not sure how many servers 
implement it though.

Re: [Standards] Last connection time of friend

[Peter Waher]

Hello Steven

Thanks for your input. The point here is to find a mechanism or a collection of 
tests to help finding out the reason why a collection of devices are not 
online. Is it because they cannot connect to the XMPP server? Or because one of 
many other conditions. One way to estimate if 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: [Standards] Last connection time of friend

If you know the full jid of the device, then you could always ping it? 
http://xmpp.org/extensions/xep-0199.html

_

Steven Lloyd Watkin
Software Engineer
PHP ::: Java ::: Ruby ::: Node.js ::: XMPP
ll...@evilprofessor.co.ukmailto: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 3 March 2014 16:47, Peter Waher 
peter.wa...@clayster.commailto:peter.wa...@clayster.com wrote:
Hello Dave

Thanks for the quick response. This looks like exactly what I need.

I’m a little worried about this statement in RFC 6121 though (and the 
explanation a little circular):

   Presence probes SHOULD NOT be sent by a client, because in general a
   client will not need to send them since the task of gathering
   presence from a user's contacts is managed by the user's server.
   However, if a user's client generates an outbound presence probe then
   the user's server SHOULD route the probe (if the contact is at
   another server) or process the probe (if the contact is at the same
   server) and MUST NOT use its receipt of the presence probe from a
   connected client as the sole cause for returning a stanza or stream
   error to the client.

Sending such probes seems to me to be a great way of finding connection 
problems in Internet of Things 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.netmailto:d...@cridland.net]
Sent: den 2 mars 2014 16:21
To: XMPP Standards
Subject: Re: [Standards] Last connection time of friend

Some servers also respond to a probe with the last offline presence (with a 
timestamp).

On 2 March 2014 19:17, Philipp Hancke 
fi...@goodadvice.pages.demailto:fi...@goodadvice.pages.de wrote:
Am 02.03.2014 20:08, schrieb Peter Waher:

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.)

http://xmpp.org/extensions/xep-0012.html#offline -- not sure how many servers 
implement it though.

Re: [Standards] Last connection time of friend

[Peter Waher]

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 Waher


From: Ben Langfeld [mailto:b...@langfeld.me]
Sent: den 3 mars 2014 14:20
To: XMPP Standards
Subject: Re: [Standards] Last connection time of friend

The point here is that this is a normative recommendation against doing 
presence probes, because there's often a better way to achieve the result. It 
is not denying you the option of doing so.

On 3 March 2014 13:47, Peter Waher 
peter.wa...@clayster.commailto:peter.wa...@clayster.com wrote:
Hello Dave

Thanks for the quick response. This looks like exactly what I need.

I'm a little worried about this statement in RFC 6121 though (and the 
explanation a little circular):

   Presence probes SHOULD NOT be sent by a client, because in general a
   client will not need to send them since the task of gathering
   presence from a user's contacts is managed by the user's server.
   However, if a user's client generates an outbound presence probe then
   the user's server SHOULD route the probe (if the contact is at
   another server) or process the probe (if the contact is at the same
   server) and MUST NOT use its receipt of the presence probe from a
   connected client as the sole cause for returning a stanza or stream
   error to the client.

Sending such probes seems to me to be a great way of finding connection 
problems in Internet of Things 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.netmailto:d...@cridland.net]
Sent: den 2 mars 2014 16:21
To: XMPP Standards

Subject: Re: [Standards] Last connection time of friend

Some servers also respond to a probe with the last offline presence (with a 
timestamp).

On 2 March 2014 19:17, Philipp Hancke 
fi...@goodadvice.pages.demailto:fi...@goodadvice.pages.de wrote:
Am 02.03.2014 20:08, schrieb Peter Waher:

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.)

http://xmpp.org/extensions/xep-0012.html#offline -- not sure how many servers 
implement it though.

Re: [Standards] Last connection time of friend

[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 Waher 
peter.wa...@clayster.commailto:peter.wa...@clayster.com wrote:

 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.)


The following XEP might also be of interest: 
http://xmpp.org/extensions/xep-0318.html

[Standards] Last connection time of friend

[Peter Waher]

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

[Standards] Redirection in XMPP?

[Peter Waher]

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@oldserver and 
want all its contacts to re-friend oneself to goodname@oldserver or 
goodname@newserver, i.e. you want to rename your JID and move all your friends 
to the new JID and ask all your friends to do the appropriate tasks to perform 
the change automatically?

I saw an old deferred XEP handling server redirection in a client to server 
connection. But I would want to redirect a client-client connection (or 
friendship/relationship): My JID is being changed to JID2, or Connection to 
JID2 for future communication with me.

Best regards,
Peter Waher

Re: [Standards] Redirection in XMPP?

[Peter Waher]

Hello Sergey

Thanks for the input. That would solve some, but not all of what I wanted to 
do. It would also require the server to respond. In this case the old JID would 
still be active. I wanted a client to ask another client to connect NEWJID for 
further communication with me, and receive an acknowledgement if understood or 
an error if not understood. (If not understood a chat message could be sent 
informing the client about the change.) It can be used for renaming JIDs, 
automatic ( graceful) reconfiguration of networks, etc. 

Best regards,
Peter


-Original Message-
From: Sergey Dobrov [mailto:bin...@jrudevels.org] 
Sent: den 21 februari 2014 13:16
To: XMPP Standards
Subject: Re: [Standards] Redirection in XMPP?

hey Peter,

I believe that the gone error condition was intended to serve this case? 
https://tools.ietf.org/html/rfc6120#page-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@oldserver and want all its contacts to re-friend oneself to 
 goodname@oldserver or goodname@newserver, i.e. you want to rename your 
 JID and move all your friends to the new JID and ask all your friends 
 to do the appropriate tasks to perform the change automatically?

 I saw an old deferred XEP handling server redirection in a client to 
 server connection. But I would want to redirect a client-client 
 connection (or friendship/relationship): “My JID is being changed to 
 JID2”, or “Connection to JID2 for future communication with me.”

 Best regards,

 Peter Waher

Re: [Standards] Redirection in XMPP?

[Peter Waher]

Hello Matthew

Thanks for the input.

The closest I can think of would be [XEP-0283], which is currently deferred.  
It results in a a slew of presence unsubscribes from the old JID and subscribes 
to the new JID, which sounds like what you want.  I know there is an 
implementation at a specific service provider and its official clients, but not 
sure of anyone else implementing it.

This was very close to what I was looking for. The main difference with what I 
wanted to do was that the redirection request is sent in a presence stanza. I 
would want a request/response mechanism, so that the client sending the request 
can take appropriate action (like sending a chat message before unsubscribing 
client2) if the destination client does not understand or declines the request. 
(The XEP also assumed that the old JID would vanish and that all contacts would 
be moved. I see cases where only individual contacts are moved. But that's only 
a conceptual difference I believe.)
I contacted Tory Patnoe to see if there was any interest to awaken XEP-0283 
again and/or make some changes to it, but at this time he was not interested. 
But he gave me permission to propose a new proposal with similar ideas.
Would this be a good idea or do you already now see a problem with this 
approach?
Best regards,
Peter Waher

Re: [Standards] XEP-323 timestamp

[Peter Waher]

Hello Joakim

Thanks for your input, and sorry for the delay in my response. I have been on a 
longer vacation and not been able to answer all mail.

Emmanuel had the same misgivings in a later mail, to which I replied the 
following (copied from my response to Emmanuel, his questions/comments prefixed 
by *):

* I am bit puzzled by having values listed as a sub-element of a timestamp. 
This is especially true since, for example, errors place the timestamp as an 
attribute of the error tag. What are the design decisions that led to this 
ordering?

In some cases, there's only one field value per timestamp, so this might look 
strange. But in the general case, there are multiple field values for each 
timestamp in a meter. 

Examples: Water meters report (at least) Accumulated Volume  Momentary Flow 
for each timestamp. Electricity meters report (at least) Accumulated Energy and 
Power for each timestamp. Heat meters usually report (at least) Accumulated 
Energy, Accumulated Volume, Momentary Flow, Momentary Power, Supply 
Temperature, Return Temperature and Temperature Difference, for each timestamp.

The main reason is to have a simple way to group together fields belonging 
together (by time). Otherwise, a long list of values would be provided, and the 
receiver would need to compare timestamps to know which field values belong 
together. Compressed, timestamps also require much memory compared to start/end 
element signals, and by placing the timestamp in a separate element, redundancy 
is avoided.

* In the read-out from multiple devices, I would have preferred that the 
fields are placed as sub-element of the node.

Ok. This would create redundancy in the timestamp part, as explained above.

* Wouldn't it be more future-proof to have historical* field types 
represented by a field called historical with an attribute describing the 
period of the history?

XEP-0326 contains an alternative way of reporting historical values stored in 
databases. The values shown here correspond to a momentary readout of a device, 
where the values have been flagged as historical.

The period is described 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-323 timestamp is a bit strange.

I would have a set of measurements or sensor data with an extra attribute / 
meta data which is the timestamp.
But in XEP-323 is looks like the timestamp is the top node:

fields xmlns='urn:xmpp:iot:sensordata' seqnr='4'
node nodeId='Device01'
  timestamp value='2013-03-07T19:00:00'
 numeric name='Temperature' ../
 numeric name='Runtime' .../
  /timestamp
 /node
/fields

So in this case is looks like the timestamp has a set of attributes that are 
temperatures, runtime, etc. which feels a bit strange.
I think it would make more sense if it would be like this:

sensordata
timestamp value='xxx'
numeric ...
numeric ...
numeric ...
/sensordata

or (timestamp in the sensordata node)

sensordata timestamp='xxx'
numeric ...
numeric ...
numeric ...
/sensordata




Best regards,
-- Joakim Eriksson, SICS

[Standards] IoT device Discovery XEP

[Peter Waher]

Hello

We're planning to start writing a new XEP proposal for IoT device discovery. 
I've received interest from a couple of people who wants to work on this. If 
anybody is interested in participating in this work, please let me know.

The first proposal for the proto-XEP will be published in normal order on the 
standards list for anybody to comment on.

Best regards,
Peter Waher

Re: [Standards] [IOT] Comments on XEP0323

[Peter Waher]

 constructs such as mean, median, average, etc. Maybe is peak 
misleading just by its name, or maybe is it too specific and we could allow for 
a comment (or method) attribute for the computed field type?



The real difference is that peak values are sometimes regulated and have 
special meaning - in a larger context. Also, a peak value is not necessarily a 
computed value. It can be a measured value. Note also that peak means an 
endpoint in a range (both min and max), within some time window. Also, in some 
cases, peak values can be used in billing, computation of tariffs, etc., and 
might have a legal/contractual meaning.



A computed value on the other hand is not measured, and can be any computed 
value, a value that is less accurate (but not necessarily so) than say a 
measured value. It can also include estimates, interpolations, extrapolations, 
etc.



There's a difference in quality between the two. And also a conceptual 
difference between the two, in the following sense: Even though it is possible 
to request specific field values from a device, there's also a broader more 
general means of requesting certain conceptual values. You might be interested 
in only momentary and peak values from a device, but ignore status and 
computed values - regardless of any knowledge what values these might actually 
contain. The device is not required to respond exactly, but this information 
can be used as a hint what has to be read and returned.



* My first reaction to localizing strings was that it brings unnecessary 
complexity to the XEP. The name of the fields, as transported over the 
wire/air, will seldom be shown to the user without passing through a software 
layer that would be able to perform the necessary localizations? Why should 
this information be carried as part of the protocol?



I would say on the contrary. This is precisely the point: The data provided by 
the device will be able to be processed by both machines and humans, with no 
need of updating software layers anywhere. If you would have to update each 
interface in your home every time you buy a new light bulb, you might get tired 
after a while - especially if our vision is true where each home will contain 
thousands of devices.



Now, localization is optional, but possible. If device manufacturers want to 
include such localization information in there, it is possible. We recommend it.



Please bear with me if you already have discussed some of these issues in the 
past. I hope that this input will help improving the content of the XEP.



/Emmanuel



Thanks a lot for all your input. I hope my responses answers your questions. If 
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

Re: [Standards] XEP-323 vs XEP-325

[Peter Waher]

Hello Joakim



Thanks for the response. I'll try to respond to your question below:



Then of course when having a desired room temperature in C that is a double the 
code that checks that the values are correct will need to check that this room 
temperature is between +5.0 and +30.0 or so. Is there also ways to express 
these limits too? Or is there a need for the controlling entity to know what 
it is doing by knowing that this is in fact a room temperature and not a oven 
temperature.



The control parameter exists in the context of what is defined in the control 
form. The set operation assumes knowledge of ranges, data types, units, etc., 
from what has been published in the control form. See §3.3.1 Getting a control 
form in XEP-0325, as an example.



It is assumed that unit conversion is too complex for small devices to perform, 
but relatively simple for system applications. I is not possible to control a 
parameter using a different unit than the unit defined by the device itself, 
and that's why unit information is not provided in the control command. It is 
assumed to be in the unit and within the allowed range. The meta-data 
concerning the parameter is available in the control form.



Best regards,

Peter Waher



-Original Message-
From: Joakim Eriksson [mailto:joak...@sics.se]
Sent: den 14 januari 2014 18:06
To: XMPP Standards
Subject: Re: [Standards] XEP-323 vs XEP-325



Hi Peter,



Yes, there might be reasons to be more specific when doing control, but for 
making implementations as easy as possible it would be very good if the types 
where the same and as few as possible.



I would go for something like:



int

double (or float)

boolean

datetime

string



both for querying (323) and for control (325).



Then of course when having a desired room temperature in C that is a double the 
code that checks that the values are correct will need to check that this room 
temperature is between +5.0 and +30.0 or so. Is there also ways to express 
these limits too? Or is there a need for the controlling entity to know what 
it is doing by knowing that this is in fact a room temperature and not a oven 
temperature.



Best regards

-- Joakim Eriksson, SICS





Peter Waher skrev 2014-01-14 15:38:

 Hello Joakim



 Thank you for your mail. I'll try to respond to your question:



 Hi,



 I am working on testing out the new XEP's for Internet of Things and

 Sensor networks by mapping a Heat pump connected over serial into

 these XEP's in a embedded PC. I have already made some registers

 readable over



 XEP-323 so that seems good, but why is there such a difference between

 reading out values and setting values?



 Assuming that there is a desired room temperature would be read it

 would be something like:



 ...



numeric name='DesiredRoomTemperature' momentary='true' value='21.0'



 unit='°C'/



 ...



 and to set would be (XEP-325):



 ...



 double name='DesiredRoomTemperature' value='22.0'/ ...



 I can understand omitting unit and momentary but why not keeping the

 same tag-names (e.g. numeric or double in both)?



 The reason here is because the control extension (XEP-0325) is more

 detailed when it comes to format and validation. For instance, it

 contains 3 numeric types: int, long and double. Handling integers is

 easier in control applications, but not suitable for all control

 parameters, as is the case in your example. The integer types are

 meant to be used for say simple analog outputs and the like. The

 sensor data extension (XEP-0323) is less interested in formats and

 validation, and uses only one element to convey all numeric field

 values. It also transmits meta data about the value not applicable in the 
 control case.



 I've been unable to update the site with the most recent versions of

 the extensions you mention. I've attached them instead. There are some

 minor changes documented in the revision histories of each one.



 Best regards,



 Peter Waher

Re: [Standards] XEP-323 vs XEP-325

[Peter Waher]

Hello Tomasz.

The unit and valid ranges are published in the control form. See §3.3.1 in 
XEP-0325 for examples. Reasons for not using units in the actual set operation 
is because unit conversion is assumed too complex for the device, and that set 
operations follow limits defined for the parameter by the control form.

Best regards,
Peter Waher

-Original Message-
From: Tomasz Sterna [mailto:to...@xiaoka.com] 
Sent: den 15 januari 2014 07:55
To: standards@xmpp.org
Subject: Re: [Standards] XEP-323 vs XEP-325

Dnia 2014-01-14, wto o godzinie 11:30 +0100, Joakim Eriksson pisze:
 double name='DesiredRoomTemperature' value='22.0'/ ...
 I can understand omitting unit and momentary [...]

I can't understand omitting the unit.
You need to know up front what unit does the control expect.

There's a room for misinterpretation and mistakes like ie.
frying/freezing your plants.

When you specify the unit, at least you give a chance to err-out on unhandled 
unit if the control is unable to convert.


--
Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/

Re: [Standards] XEP-323 vs XEP-325

[Peter Waher]

Hello Joakim

The control form provides means to publish limits for control values. See 
§3.3.1 for examples.

Best regards,
Peter Waher

-Original Message-
From: Joakim Eriksson [mailto:joak...@sics.se] 
Sent: den 15 januari 2014 08:51
To: standards@xmpp.org
Subject: Re: [Standards] XEP-323 vs XEP-325

Tomasz Sterna skrev 2014-01-15 11:54:
 Dnia 2014-01-14, wto o godzinie 11:30 +0100, Joakim Eriksson pisze:
 double name='DesiredRoomTemperature' value='22.0'/ ...
 I can understand omitting unit and momentary [...]

 I can't understand omitting the unit.
 You need to know up front what unit does the control expect.

 There's a room for misinterpretation and mistakes like ie.
 frying/freezing your plants.

 When you specify the unit, at least you give a chance to err-out on 
 unhandled unit if the control is unable to convert.

Yes, keeping the unit even for control make it possible for the controlled 
object so do better error control and sanity checking.

Is there a good way to inform the controller what are the limits of the values? 
E.g. max and min values of the desired room temp?
(have not yet fully read all the XEP-323/325, etc).

Best regards,
-- Joakim Eriksson, SICS

Re: [Standards] XEP-323 vs XEP-325

[Peter Waher]

Hello Joakim



I'll address your concerns one at a time:



So a resource limited device that can not translate between Fahrenheit and 
Celcius will be able to provide and parse the control forms?



Yes, in the general case. Temperature and two units is of course a trivial 
example, but the extension tries to solve the general case, which is much more 
complicated. Furthermore assembling control forms is easy, parsing them is 
often supported directly in the XMPP client library already provided.



From my perspective (being a resource constrained device software

developer) I would prefer a more lightweight approach than the control forms to 
discover the fields and their range, units, etc.



An additional approach might be possible. However, it would not remove the need 
for control forms (see below).



A complete slimmer discover fields response could be:



...

fields

int name='Temperature' min='-40' max='95' unit='C' / int name='Humidity' 
min='0' max='100' unit='%' / /fields ...



Now, sensor data (XEP-0323) can publish a lot of records, not all controllable. 
Normally, only a small fraction of published fields would be controllable. 
Furthermore, many controllable parameters would not be readable (and therefore 
not available as fields through XEP-0323). So there’s no natural connection 
between fields in XEP-0323 and control parameters in XEP-0325 in the general 
case.



Secondly, your example only include ranges. Intervals is just one validation 
method. Control forms provide more. The pluggable validation structure (i.e. 
using sub-elements) provides a more general way to defining limits than 
attributes on an element would.



Thirdly, by supposedly including this information in the field information, it 
would have to be sent every time the sensor is read, and stored with the values 
as well. A control form can be read once to know the capabilities of the 
device. When somebody wants to know the control capabilities of a device, it 
simply reads the form. It can later issue control commands without reading it 
beforehand.



Then if it is for humans - all the labels and other things could be included?



Is the current forms mechanisms intended for machine-to-machine or 
machine-to-human?



It is intended to be used by both machines and humans. Sufficient meta-data has 
been added to create an interface that can both be automated as well as be 
understood by humans with no device-specific software added, and taking into 
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



 -Original Message-

 From: Joakim Eriksson [mailto:joak...@sics.se]

 Sent: den 15 januari 2014 08:51

 To: standards@xmpp.orgmailto:standards@xmpp.org

 Subject: Re: [Standards] XEP-323 vs XEP-325



 Tomasz Sterna skrev 2014-01-15 11:54:

 Dnia 2014-01-14, wto o godzinie 11:30 +0100, Joakim Eriksson pisze:

 double name='DesiredRoomTemperature' value='22.0'/ ...

 I can understand omitting unit and momentary [...]



 I can't understand omitting the unit.

 You need to know up front what unit does the control expect.



 There's a room for misinterpretation and mistakes like ie.

 frying/freezing your plants.



 When you specify the unit, at least you give a chance to err-out on

 unhandled unit if the control is unable to convert.



 Yes, keeping the unit even for control make it possible for the controlled 
 object so do better error control and sanity checking.



 Is there a good way to inform the controller what are the limits of the 
 values? E.g. max and min values of the desired room temp?

 (have not yet fully read all the XEP-323/325, etc).



 Best regards,

 -- Joakim Eriksson, SICS







-

No virus found in this message.

Checked by AVG - www.avg.comhttp://www.avg.com

Version: 2014.0.4259 / Virus Database: 3658/6960 - Release Date: 12/30/13

Internal Virus Database is out of date.

Re: [Standards] PS: XEP-323 vs XEP-325

[Peter Waher]

Excellent.

Regarding distinction between fields and control parameters:

Fields provide sensor-data along three axes: Field Name, Node ID and Time. A 
single parameter can result in many thousands of fields across time. A control 
parameter is more direct. Control parameters exist along two axes: Parameter 
Name and Node ID. 

Apart from the fact that not all fields are from parameters and not all control 
parameters are suitable fields, there are in some cases fields that correspond 
to a set of control parameters, and vice versa, control parameters that might 
correspond to a set of fields.

Example: Control parameters might be used for calibration or configuration as 
well as control. Consider an 16-bit analog output. It might have a set of 
control parameters available to configure the output (Scale, offset, unit, 
decimals for instance), and a raw 16-bit output parameter (0-65535). But when 
reading the device only one or two fields are reported (scaled value and raw 
A/D value).

Furthermore, fields control QoS and other meta data attributes not applicable 
in control applications, and vice versa: control parameters have additional 
attributes that are not applicable in sensor data readout. There's some overlap 
as you've noticed. The idea is to let the name attribute be the key signaling 
overlap, and the interoperability interfaces to fix meanings.

Best regards,
Peter

-Original Message-
From: Joakim Eriksson [mailto:joak...@sics.se] 
Sent: den 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 perspective it would be good if we consider even very small devices 
to be candidate for actually running a complete (subset) of the XMPP stack.

I like the idea of setting up standard profiles for IoT like you are doing in 
the linked document. Even if I am not sure I like the distinction between 
fields and parameters it is a good start.

I will continue to do some implementation based on 323 + 325 and see what I 
like and dislike and provide more feedback as soon as I have more to say ;-)


Best regards,
-- Joakim Eriksson, SICS

Peter Waher skrev 2014-01-15 18:17:
 PS: Forgot to mention relating to the discussion regarding unit 
 conversion in devices:

 One important factor in the design of the IoT XEPs is interoperability 
 between devices. If support for unit conversion were to be added to 
 XEP-0325, a mechanism for publishing supported units would also be 
 necessary. Syntax of units would also be a problem to define. (Is m^3 
 written m^3 , m^3, m3 or M3?) To avoid such problems in control 
 applications, control parameters are defined by the actuator, and 
 controllers are forced to use the ranges (or other validation rules) 
 the actuator defines.

 To provide for an additional layer of interoperability between 
 devices, we’re writing a document listing interoperability interfaces 
 (contracts) for devices of different kinds. It is a working document at the 
 moment:

 http://htmlpreview.github.io/?https://github.com/joachimlindborg/XMPP-
 IoT/blob/master/xep--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 device that can not translate between Fahrenheit 
 and Celcius will be able to provide and parse the control forms?

 Yes, in the general case. Temperature and two units is of course a 
 trivial example, but the extension tries to solve the general case, 
 which is much more complicated. Furthermore assembling control forms 
 is easy, parsing them is often supported directly in the XMPP client 
 library already provided.

  From my perspective (being a resource constrained device software

 developer) I would prefer a more lightweight approach than the control 
 forms to discover the fields and their range, units, etc.

 An additional approach might be possible. However, it would not remove 
 the need for control forms (see below).

 A complete slimmer discover fields response could be:

 ...

 fields

 int name='Temperature' min='-40' max='95' unit='C' / int 
 name='Humidity' min='0' max='100' unit='%' / /fields ...

 Now, sensor data (XEP-0323) can publish a lot of records, not all 
 controllable. Normally, only a small fraction of published fields 
 would be controllable. Furthermore, many controllable parameters would 
 not be readable (and therefore not available as fields through 
 XEP-0323). So there’s no natural connection between fields in XEP-0323 
 and control parameters in XEP-0325 in the general case.

 Secondly, your example only include ranges. Intervals is just one 
 validation method

[Standards] PS: XEP-323 vs XEP-325

[Peter Waher]

PS:

While I figure out how to update the extensions on the xmpp.org site, the 
latest revisions can be found here:

http://htmlpreview.github.com/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/sensor-data.html
http://htmlpreview.github.com/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/sensor-network-Control.html

Links to all can also be found at the bottom of this page:
https://github.com/joachimlindborg/XMPP-IoT

Best regards,
Peter Waher


From: Peter Waher
Sent: den 14 januari 2014 11:38
To: standards@xmpp.org
Subject: RE: [Standards] XEP-323 vs XEP-325


Hello Joakim



Thank you for your mail. I'll try to respond to your question:



Hi,



I am working on testing out the new XEP's for Internet of Things and Sensor 
networks by mapping a Heat pump connected over serial into these XEP's in a 
embedded PC. I have already made some registers readable over

XEP-323 so that seems good, but why is there such a difference between reading 
out values and setting values?



Assuming that there is a desired room temperature would be read it would be 
something like:

...

  numeric name='DesiredRoomTemperature' momentary='true' value='21.0'

unit='°C'/

...



and to set would be (XEP-325):



...

double name='DesiredRoomTemperature' value='22.0'/ ...





I can understand omitting unit and momentary but why not keeping the same 
tag-names (e.g. numeric or double in both)?



The reason here is because the control extension (XEP-0325) is more detailed 
when it comes to format and validation. For instance, it contains 3 numeric 
types: int, long and double. Handling integers is easier in control 
applications, but not suitable for all control parameters, as is the case in 
your example. The integer types are meant to be used for say simple analog 
outputs and the like. The sensor data extension (XEP-0323) is less interested 
in formats and validation, and uses only one element to convey all numeric 
field values. It also transmits meta data about the value not applicable in the 
control case.



I've been unable to update the site with the most recent versions of the 
extensions you mention. I've attached them instead. There are some minor 
changes documented in the revision histories of each one.



Best regards,

Peter Waher

[Standards] OneM2M writes about the XMPP IoT extensions

[Peter Waher]

Hello

Look at what OneM2M ( Cisco) writes about the XMPP IoT solution.
ftp://ftp.onem2m.org/Work%20Programme/WI0008/oneM2M-TR-0009-Protocol_Analysis-V0_4_0.DOCftp://ftp.onem2m.org/Work%20Programme/WI0008/oneM2M-TR-0009-Protocol_Analysis-V0_4_0.DOC

Best regards,
Peter Waher