date:20180308

Hello! 08.03.2018, 12:18, "Dave Cridland" :The personal choice of Council was to deprecate XHTML-IM based onthese facts. The previous Council decided to ensure there werealternates for XHTML-IM use-cases instead of deprecating.Deprecating is not a serious problem. The probleb is that they are obsoleted if instead of deprecating. And that sounds really bad. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

Hello! 08.03.2018, 10:52, "Jonas Wielicki" :In contrast to XML, XHTML-IM is a custom thing which needs to be re-implemented in ~every client. Well-known XML libraries exist for mostlanguages (even if they only FFI to libxml2 or libexpat).According to my experience, building a XHTML processor using an existing XML parser is a trivial task. It doesn't took a lot of time for me to build such processor using QtXML/QDomDocument framework. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

On 7 March 2018 at 16:26, Peter Saint-Andre  wrote:
> On 3/5/18 3:37 PM, Christian Schudt wrote:
>> Hi,
>>
>> I find the whole passage „Discovering Capabilities“ of Serverless Messaging 
>> [1] a bit confusing.
>
> Are people still using this technology? In my experience, it was a fun
> experiment in ~2006 but didn't work well in practice: too chatty over
> the network, presence never worked correctly, you'd send a message to
> someone and it turns out they weren't available, etc.

I'm aware of people experimenting with this on ad-hoc networks such as
emergent vehicle networks.

While I agree that it's probably flaky as hell in practise, I think it
remains our best shot at this.

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

[Standards] DEPRECATED: XEP-0020 (Feature Negotiation)

Version 1.6 of XEP-0020 (Feature Negotiation) has been released.

Abstract:
This specification defines an XMPP protocol extension that enables two
entities to mutually negotiate feature options, such as parameters
related to a file transfer or a communications session.

Changelog:
Deprecated as per Council vote on 2018-03-07. (jwi (Editor))

URL: https://xmpp.org/extensions/xep-0020.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0153 (vCard-Based Avatars)

Version 1.1 of XEP-0153 (vCard-Based Avatars) has been released.

Abstract:
This document provides historical documentation of a vCard-based
protocol for exchanging user avatars.

Changelog:
Clarify encoding of the photo hash in the presence update. (jwi)

URL: https://xmpp.org/extensions/xep-0153.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

On 8 March 2018 at 08:34, Evgeny Khramtsov  wrote:
> TL;DR: I conclude that the only argument is that XML is a bit more
> secure (with possibly less possible holes, lol). So, as I thought, this
> is purely a matter of personal choice and not a technical decision,
> that's why we debated about it so much.

It can be both, you know.

XML's security problems are fairly limited (essentially, entities and
escaping). Because they're highly generic, XML parsers have had
support for preventing the various entities attacks at a low level for
some time, and since these attacks are generic, they're soluble at the
XML parser level.

Embedding user-generated [X]HTML into a web UI is also a well-known
security issue, and the advice from web-devs is simply not to do it -
there are a few libraries to try and make this safe, but the browsers
don't include these, and instead you need to do iframe embedding. As
HTML and CSS standards mutate, you need your library to be constantly
maintained to ensure that security issues stay closed, or be highly
restrictive in what is allowed (and essentially parse the XHTML into
an intermediate state and reassemble only the safe parts).

Whilst there are no extant and ongoing issues with XML, the issues in
XHTML-IM keep cropping up in new web clients.

Those are the technical facts.

The personal choice of Council was to deprecate XHTML-IM based on
these facts. The previous Council decided to ensure there were
alternates for XHTML-IM use-cases instead of deprecating.

These are personal choices.

As a side-note, this doesn't have any impact on embedding XHTML into
XMPP. Just that if what you want is snazzy-looking IM messages, it's
not a sensible way to do it.

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

Re: [Standards] Call for Experience: XEP-0066: Out of Band Data

2018-03-08 Thread Christian Schudt


> However I'm not really sure what the intended purpose of this XEP is
> and if we still have a use case for that purpose.

I understood the purpose as follows:

a) You upload some file to a server (nowadays you could also use XEP-363).
b) You send a message to a contact with XEP-0066.
c) Contact downloads the uploaded file.

The advantage over SI File Transfer is that a file can be sent also in offline 
case.

The end user experience should be the same for all methods of file transfer 
(SI, Jingle, OOB):
- Inform the receiver about an incoming file.
- Receiver can choose to accept it.
- It should be transparent to the user, if the sender used SI, Jingle or OOB, 
e.g. if the file is streamed from an URL (XEP-0066) or from the sender directly.

TL;DR: The purpose is/was to transfer files in case the receiver is offline.

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

Re: [Standards] [Council] XMPP Council Minutes 2018-03-07

On 7 March 2018 at 18:35, Florian Schmaus  wrote:
> On 07.03.2018 19:14, Dave Cridland wrote:
>> My votes:
>> On 7 March 2018 at 17:47, Dave Cridland  wrote:
>>> 19) CFE for XEP-0131: Stanza Headers and Internet Metadata
>>> https://xmpp.org/extensions/xep-0131.html
>>>
>>> Georg, Daniel, Kev +1, Sam +0
>>>
>>
>> I really dislike this spec, but I think it's used in pubsub isn't it?
>>
>> +1
>
> Are you +1 because it is used, and would you otherwise vote -1? Is "it
> is used somewhere" really an argument to not deprecate a spec? If so, we
> possibly need a new XEP state "discouraged by used".

If a Draft specification says "MUST do XYZ", and XYZ claims it's
deprecated, we're saying that part of a Draft spec is deprecated.

https://xmpp.org/extensions/xep-0060.html#publisher-delete-success-subid

Something's got to be wrong there.

The reason I dislike SHIM is because it's a generic container for
data, and that's basically what XML is itself. But its design is to
act as a container for RFC 5322 header fields, which is actually a
worthy goal - albeit one we've (possibly) never used it for in
practise.

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

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

2018-03-08 Thread Goffi

Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit :

> Thank you for your reply. Yes, I know about those two. As for XEP-0394, I
> feel so bad the XEP idea, so I don't even want to discuss the XEP
> itself. 

Out of curiousity, what do you dislike in this XEP? I actually find the idea 
really good, it's a clean separation between content and style, which means 
that there is not need to send a text version as we have too with XHTML-IM.
XEP-0393 on the other hand is totally mixing style and content, that's why 
I really dislike it.

Goffi


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

Re: [Standards] Call for Experience: XEP-0048: Bookmarks

2018-03-08 Thread Goffi

Can't make a detailed review today, so here's quickly:

the XEP is implemented in SàT using both private XML storage (XEP-0049) and 
PEP.

There are several issues with this XEP, the most important being the race 
condition can be specially bad as all bookmarks are saved in the same item.

Also I've tried to use it to bookmark pubsub nodes (blogs) using xmpp: 
URIs, but as it is not explicitly mentioned in the XEP, some clients just 
remove the links (don't remember which ones right now, I've tried years 
ago).

Also on the practical side, the XEP is lacking way to classify links, like 
keywords, hierarchy, or anything else.

We have been thinking for a while with Edhelas about writting an 
alternative proposal for bookmaks actually, but that's an other topic.

Goffi

Le mercredi 7 mars 2018, 20:17:24 CET Jonas Wielicki a écrit :
> The XEP Editor would like to Call for Experience with XEP-0048 before
> presenting it to the Council for advancing it to Final status.
> 
> 
> During the Call for Experience, please answer the following questions:
> 
> 1. What software has XEP-0048 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.
> 
> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0048? If so, please describe the problems and, if
> possible, suggested solutions.
> 
> 3. Is the text of XEP-0048 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
> 
> If you have any comments about advancing XEP-0048 from Draft to Final,
> please provide them by the close of business on 2018-03-21. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
> 
> 
> You can review the specification here:
> 
> https://xmpp.org/extensions/xep-0048.html
> 
> Please send all feedback to the standards@xmpp.org discussion list.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___




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

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

2018-03-08 Thread Jonas Wielicki

On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote:
> Hello!
>  
> 08.03.2018, 12:18, "Dave Cridland" :
> The personal choice of Council was to deprecate XHTML-IM based on
> these facts. The previous Council decided to ensure there were
> alternates for XHTML-IM use-cases instead of deprecating.

This was an editors mistake. The Council voted to Deprecate, not to Obsolete. 
I rectified the issue and I’m going to send out an email when the update is 
live on the website. Thanks for bringing this up and sorry for the 
inconvenience.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0048: Bookmarks

Hello! 07.03.2018, 22:18, "Jonas Wielicki (XSF Editor)" :The XEP Editor would like to Call for Experience with XEP-0048 beforepresenting it to the Council for advancing it to Final status.During the Call for Experience, please answer the following questions:1. What software has XEP-0048 implemented? Please note that theprotocol must be implemented in at least two separate codebases (atleast one of which must be free or open-source software) in order toadvance from Draft to Final.It is implemented in eyeCU and Vacuum-IM. Both of them have the same codebse.2. Have developers experienced any problems with the protocol asdefined in XEP-0048? If so, please describe the problems and, ifpossible, suggested solutions.I'm not the author of implementation, but I just contacted the author and he said that there were no problem with implementation.3. Is the text of XEP-0048 clear and unambiguous? Are more examplesneeded? Is the conformance language (MAY/SHOULD/MUST) appropriate?Have developers found the text confusing at all? Please describe anysuggestions you have for improving the text.No. Everything is all right.If you have any comments about advancing XEP-0048 from Draft to Final,please provide them by the close of business on 2018-03-21. After theCall for Experience, this XEP might undergo revisions to addressfeedback received, after which it will be presented to the XMPPCouncil for voting to a status of Final.With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] DEPRECATED: XEP-0071 (XHTML-IM)

Version 1.5.4 of XEP-0071 (XHTML-IM) has been released.

Abstract:
This specification defines an XHTML 1.0 Integration Set for use in
exchanging instant messages that contain lightweight text markup. The
protocol enables an XMPP entity to format a message using a small
range of commonly-used HTML elements, attributes, and style properties
that are suitable for use in instant messaging. The protocol also
excludes HTML constructs that may introduce malware and other
vulnerabilities (such as scripts and objects) for improved security.

Changelog:
Correction: Council voted to Deprecate, not Obsolete. (XEP Editor
(jwi))

URL: https://xmpp.org/extensions/xep-0071.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

Hello! 08.03.2018, 14:15, "Jonas Wielicki" :On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote: Hello! 08.03.2018, 12:18, "Dave Cridland" : The personal choice of Council was to deprecate XHTML-IM based on these facts. The previous Council decided to ensure there were alternates for XHTML-IM use-cases instead of deprecating.This was an editors mistake. The Council voted to Deprecate, not to Obsolete.I rectified the issue and I’m going to send out an email when the update islive on the website. Thanks for bringing this up and sorry for theinconvenience.In that case it's all right. While XEP is deprecated, I may keep develop its implementation until XEP-0394 become pwerful enogh to substitute it. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

Hello! 08.03.2018, 12:58, "Goffi" :Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit :  Thank you for your reply. Yes, I know about those two. As for XEP-0394, I feel so bad the XEP idea, so I don't even want to discuss the XEP itself.Out of curiousity, what do you dislike in this XEP? I actually find the ideareally good, it's a clean separation between content and style, which meansthat there is not need to send a text version as we have too with XHTML-IM.XEP-0393 on the other hand is totally mixing style and content, that's whyI really dislike it.I'm really sorry.  I mixed up those two. The name of those XEPs (Markup and Styling) are confusing me.So, I really dislike XEP-0393 and I find XEP-0394 interesting and worth further development. Sorry once again for confusing other subscribers of this mailing list. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

2018-03-08 Thread Manuel Rubio


Hi guys,

I usually only read to understand and learn but sometimes I head up and 
freak out with some decision. I usually read RFC and when a new one is 
released it supersedes, deprecates or obsoletes another one. But, the 
status of that RFC usually is definitive. Obviously it's definitive 
until a better one is released (as Descartes always said there are 
nothing definitive only temporal until we can find a better 
solution/theory/explanation).


In this case I can see you are putting "obsolete" to XEP-0071 and it's 
intended there are a new proposal better on the table... where? XEP-0071 
has no explanation about why it was obsoleted only a vague description 
"Per a vote of the XMPP Council, advanced to Obsolete". I wanted to know 
"why".


And more important, if the XEP-0071 is obsoleted because XEP-0393 is 
there... why XEP-0393 is experimental? I'm not pretty sure but looks 
like you are suggesting to use something experimental instead of 
something it was working for years. If XEP-0393 is the reason because 
XEP-0071 is obsoleted, I think it's fair enough to advance the state 
from experimental to something different for XEP-0393, IMO.


Last thing, what's the usual flow for the states? I cannot find 
information here: https://xmpp.org/extensions/ ; there are only the 
possibility to filter based on those states but not information about 
what means each one or even how it could be advanced from one to 
another.


Thanks.
Manuel Rubio.

El 2018-03-08 10:57, Goffi escribió:

Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit :

Thank you for your reply. Yes, I know about those two. As for 
XEP-0394, I

feel so bad the XEP idea, so I don't even want to discuss the XEP
itself.


Out of curiousity, what do you dislike in this XEP? I actually find the 
idea
really good, it's a clean separation between content and style, which 
means
that there is not need to send a text version as we have too with 
XHTML-IM.
XEP-0393 on the other hand is totally mixing style and content, that's 
why

I really dislike it.

Goffi


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

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

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

On 8 March 2018 at 10:54, Manuel Rubio  wrote:
> Hi guys,
>
> I usually only read to understand and learn but sometimes I head up and
> freak out with some decision. I usually read RFC and when a new one is
> released it supersedes, deprecates or obsoletes another one. But, the status
> of that RFC usually is definitive. Obviously it's definitive until a better
> one is released (as Descartes always said there are nothing definitive only
> temporal until we can find a better solution/theory/explanation).
>

It's not an RFC it's a XEP, and the procedures are different.

If this were an RFC, we'd be designating it "Historical".

> In this case I can see you are putting "obsolete" to XEP-0071 and it's
> intended there are a new proposal better on the table... where? XEP-0071 has
> no explanation about why it was obsoleted only a vague description "Per a
> vote of the XMPP Council, advanced to Obsolete". I wanted to know "why".
>

Summarized in this thread and intensively discussed in Council and on this list.

> And more important, if the XEP-0071 is obsoleted because XEP-0393 is
> there... why XEP-0393 is experimental? I'm not pretty sure but looks like
> you are suggesting to use something experimental instead of something it was
> working for years. If XEP-0393 is the reason because XEP-0071 is obsoleted,
> I think it's fair enough to advance the state from experimental to something
> different for XEP-0393, IMO.
>

No.

XEP-0071 is obsoleted on its own merits. The other XEPs merely show
there could be a viable alternative.

XEP-0393 will be advanced on its own merits later.

> Last thing, what's the usual flow for the states? I cannot find information
> here: https://xmpp.org/extensions/ ; there are only the possibility to
> filter based on those states but not information about what means each one
> or even how it could be advanced from one to another.

XEP-0001.

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

[Standards] UPDATED: XEP-0045 (Multi-User Chat)

Version 1.31 of XEP-0045 (Multi-User Chat) has been released.

Abstract:
This specification defines an XMPP protocol extension for multi-user
text chat, whereby multiple XMPP users can exchange messages in the
context of a room or channel, similar to Internet Relay Chat (IRC). In
addition to standard chatroom features such as room topics and
invitations, the protocol defines a strong room control model,
including the ability to kick and ban users, to name room moderators
and administrators, to require membership or passwords in order to
join the room, etc.

Changelog:
Require the service to maintain the 'id' attribute on message
reflections. (gl)

URL: https://xmpp.org/extensions/xep-0045.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

2018-03-08 Thread Konstantin Kozlov

Hello!8 марта 2018 г. 21:26 пользователь VanitasVitae  написал:Also if we'd do that, we'd have "Message Markup" and "Message Markdown"...Yeah, but it will be really funny. Just like "more" and "less" viewers Linux! :-)With my best regardsKonstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

Hello! I just want to clarify my thoughts about naming. Why do I think that "Markup" more suits for XEP-0393 and "Styling" for XEP-0394.Well known markup languages like HTML (HyperText Markup Language) and XML (eXtensible Markup Language) have markup elements mixed with text blocks to display. And syntax, which used by XEP-0393 is just a Lightweight markup language (LML) according to Wikipedia. On the other hand, when it comes to styles, we may remember CSS (Cascading Style Sheets). With CSS styles and text are separated. Styles, described in CSS are applied to the text. XEP-0394 provides similar technology: styles, described in  element of  stanza applied to unstyled text in message body, "styling" it.So, while XEP-0394 is EXPERIMENTAL and not widely implemented, I think it's a good idea to rename it to "styling" or something style-related, rename  element to  or  and change its namespace to "urn:xmpp:markup:0". And about "Message" part... Yes, I'm sure it should be changed to "Text", because in both XEP's only text part of the  stanza is affected, not the whole . With my best regards,Konstantin 08.03.2018, 21:18, "Tedd Sterr" :I have to agree with Kozlov - I struggle to tell the two apart on title alone. I think the confusion comes more from both titles being variants of 'Message Styling/Markup/Decoration.' "Text Styling" seems a more fitting title for 0393. From: Standards  on behalf of Sam Whited Sent: 08 March 2018 16:35To: standards@xmpp.orgSubject: Re: [Standards] XEP-0393 and XEP-0394 naming On Thu, Mar 8, 2018, at 10:26, Kozlov Konstantin wrote:> Yes, maybe. It was just an example.Indeed. I'm okay with renaming if others agree that "styling" is confusing for some reason, but only if someone comes up with a name that expresses the intent clearer."Message Markup", or "Lightweight Message Markup" maybe? It's a bit of a mouthful.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

2018-03-08 Thread Peter Saint-Andre

On 3/8/18 9:12 AM, Denver Gingerich wrote:
> On Thu, Mar 08, 2018 at 08:47:50AM -0700, Peter Saint-Andre wrote:
>> On 3/8/18 2:33 AM, Dave Cridland wrote:
>>> I'm aware of people experimenting with this on ad-hoc networks such as
>>> emergent vehicle networks.
>>
>> I heard about such things years ago, too. Are those active projects?
> 
> I can't speak for emergent vehicle projects, but ad-hoc networks are becoming 
> increasing popular for person to person communication given new hardware 
> technology (more on that below).  I suspect related XEP-0174 projects will 
> soon be quite active.
> 
>>> While I agree that it's probably flaky as hell in practise, I think it
>>> remains our best shot at this.
>>
>> Do *we* need to take a shot at this?
>>
>> What scenarios are we or other folks trying to solve for these days?
>>
>> The original use case was ad-hoc 1:1 chat at conferences and local
>> networks not connected to the wider Internet. While that was interesting
>> 12 years ago, is it interesting now? Is there some other interesting
>> problem that serverless messaging can solve?
> 
> I believe "local networks not connected to the wider Internet" are definitely 
> still interesting, perhaps even more interesting today than before.

The XEP-0174 use case was originally for people connected to the same
WiFi hotspot or other link-local network. The technology was driven
forward by Apple (remember when Bonjour was called Rendezvous?) and
hasn't received much attention since they stopped featuring it in iChat.

> There are a number of new devices that allow people to create their own 
> networks when away from an Internet connection.  In particular, see 
> https://www.sonnetlabs.com/ and similar projects.  Sonnet creates an IP 
> network with other Sonnets within a few kilometres - this would be a great 
> place to be able communicate via XMPP without a server, i.e. using mobile 
> XMPP clients on wifi-connected phones.
> 
> Similar devices include https://gotenna.com/pages/mesh - goTenna does not 
> create an IP network like Sonnet, but instead uses its own proprietary 
> protocols over the air and with connected Bluetooth devices.  I suspect we'd 
> be able to go far beyond goTenna's capabilities by using XMPP with a less 
> proprietary device like Sonnet.

Yes, I'm familiar with such technologies, having worked on peer-to-peer,
end-to-end encrypted, long-range radio communication devices for IoT (no
longer my current project). There are significant challenges involved in
building such things - battery life, power consumption, sleepy nodes,
firmware size, OTA updates (!), bandwidth limitations (our devices
operated at ~900 MHz), eliminating a dependency on centralized towers
(LoRaWAN, LTE-M, etc.), strong security including use a secure enclave
and a proper manufacturing process to bootstrap trust (hardware is
hard), protecting privacy over a radio frequency transport through
techniques like channel hopping and seemingly random time schedules,
etc. I am not convinced that XMPP is the right approach for such
applications. Something like Apache Mynewt might a more appropriate
foundation (it's being driven forward by some of the original technical
minds behind Silver Spring Networks), but even then there's a lot of
work required to build a true mesh protocol in a private and secure way
(e.g., the native LoRaWAN security is not strong and that architecture
depends on towers anyway).

> It is the long-term goal of the Soprani.ca family of projects that I'm 
> working on (which includes https://jmp.chat/ among others) to build and/or 
> integrate a device like Sonnet into existing phones so that we can replace 
> some of the cell network functionality with something that gives people a bit 
> more freedom.  See https://wiki.soprani.ca/ThePlan#Long-range_radios (where 
> we explicitly call out XEP-0174 as a way of doing this) for more details.

Those are great aspirations. However, I am skeptical that XMPP meets the
design goals in this space.

Peter

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

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

On 8 March 2018 at 15:47, Peter Saint-Andre  wrote:
> On 3/8/18 2:33 AM, Dave Cridland wrote:
>> On 7 March 2018 at 16:26, Peter Saint-Andre  wrote:
>>> On 3/5/18 3:37 PM, Christian Schudt wrote:
 Hi,

 I find the whole passage „Discovering Capabilities“ of Serverless 
 Messaging [1] a bit confusing.
>>>
>>> Are people still using this technology? In my experience, it was a fun
>>> experiment in ~2006 but didn't work well in practice: too chatty over
>>> the network, presence never worked correctly, you'd send a message to
>>> someone and it turns out they weren't available, etc.
>>
>> I'm aware of people experimenting with this on ad-hoc networks such as
>> emergent vehicle networks.
>
> I heard about such things years ago, too. Are those active projects?
>

Amazingly, yes.

>> While I agree that it's probably flaky as hell in practise, I think it
>> remains our best shot at this.
>
> Do *we* need to take a shot at this?
>
> What scenarios are we or other folks trying to solve for these days?
>
> The original use case was ad-hoc 1:1 chat at conferences and local
> networks not connected to the wider Internet. While that was interesting
> 12 years ago, is it interesting now? Is there some other interesting
> problem that serverless messaging can solve?

Well, that's certainly not the current use-case.

The problem they're trying to solve is where you have a number of
people and/or vehicles that are moving about, and you want structured
conversations between them, and some of these vehicles have uplinks to
a stable network. So there are gateways between XEP-0174 and S2S
floating about too.

My understanding is that it's working quite well, experimentally. But
really I'd be surprised.

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

[Standards] XEP-0393 and XEP-0394 naming

Hello! Discussing XEP-0393 and XEP-0394 I mixed them up a few times. That's because their names are really confusing. I think "Markup" more suits for XEP-0393 and "Styling" for XEP-0394.I guess, we should think about renaming those XEPs to make their names less confusing. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

On Thu, Mar 8, 2018, at 10:01, Kozlov Konstantin wrote:
> I think "Markup" more suits
> for XEP-0393 and "Styling" for XEP-0394.I guess, we should think about 
> renaming those XEPs to make their names
> less confusing. 

I'm not against this (as the author of 0393) if people find this confusing, but 
swapping the names seems even more confusing to me.

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

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

On 8 March 2018 at 15:58, Sam Whited  wrote:
> I thought we were specifically voting to obsolete (because this was about 
> wide spread security issues); the minutes do say "deprecate", but we kept 
> mixing up the terminology. I hate our process.
>

PRs to XEP-0001 welcome. :-)

> Can other council members weigh in with what they thought we were doing?
>

The agenda, minutes and chat transcripts all say explicitly
"Deprecate", with no mention of Obsoletion.

> —Sam
>
> On Thu, Mar 8, 2018, at 05:15, Jonas Wielicki wrote:
>> On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote:
>> > Hello!
>> >
>> > 08.03.2018, 12:18, "Dave Cridland" :
>> > The personal choice of Council was to deprecate XHTML-IM based on
>> > these facts. The previous Council decided to ensure there were
>> > alternates for XHTML-IM use-cases instead of deprecating.
>>
>> This was an editors mistake. The Council voted to Deprecate, not to Obsolete.
>> I rectified the issue and I’m going to send out an email when the update is
>> live on the website. Thanks for bringing this up and sorry for the
>> inconvenience.
>>
>> kind regards,
>> Jonas
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>> Email had 1 attachment:
>> + signature.asc
>>   1k (application/pgp-signature)
>
>
> --
> Sam Whited
> s...@samwhited.com
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

2018-03-08 Thread Denver Gingerich

On Thu, Mar 08, 2018 at 08:47:50AM -0700, Peter Saint-Andre wrote:
> On 3/8/18 2:33 AM, Dave Cridland wrote:
> > I'm aware of people experimenting with this on ad-hoc networks such as
> > emergent vehicle networks.
> 
> I heard about such things years ago, too. Are those active projects?

I can't speak for emergent vehicle projects, but ad-hoc networks are becoming 
increasing popular for person to person communication given new hardware 
technology (more on that below).  I suspect related XEP-0174 projects will soon 
be quite active.

> > While I agree that it's probably flaky as hell in practise, I think it
> > remains our best shot at this.
> 
> Do *we* need to take a shot at this?
> 
> What scenarios are we or other folks trying to solve for these days?
> 
> The original use case was ad-hoc 1:1 chat at conferences and local
> networks not connected to the wider Internet. While that was interesting
> 12 years ago, is it interesting now? Is there some other interesting
> problem that serverless messaging can solve?

I believe "local networks not connected to the wider Internet" are definitely 
still interesting, perhaps even more interesting today than before.

There are a number of new devices that allow people to create their own 
networks when away from an Internet connection.  In particular, see 
https://www.sonnetlabs.com/ and similar projects.  Sonnet creates an IP network 
with other Sonnets within a few kilometres - this would be a great place to be 
able communicate via XMPP without a server, i.e. using mobile XMPP clients on 
wifi-connected phones.

Similar devices include https://gotenna.com/pages/mesh - goTenna does not 
create an IP network like Sonnet, but instead uses its own proprietary 
protocols over the air and with connected Bluetooth devices.  I suspect we'd be 
able to go far beyond goTenna's capabilities by using XMPP with a less 
proprietary device like Sonnet.

It is the long-term goal of the Soprani.ca family of projects that I'm working 
on (which includes https://jmp.chat/ among others) to build and/or integrate a 
device like Sonnet into existing phones so that we can replace some of the cell 
network functionality with something that gives people a bit more freedom.  See 
https://wiki.soprani.ca/ThePlan#Long-range_radios (where we explicitly call out 
XEP-0174 as a way of doing this) for more details.

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

Re: [Standards] XEP-0393 and XEP-0394 naming

Hello! 08.03.2018, 19:03, "Sam Whited" :On Thu, Mar 8, 2018, at 10:01, Kozlov Konstantin wrote: I think "Markup" more suits for XEP-0393 and "Styling" for XEP-0394.I guess, we should think about renaming those XEPs to make their names less confusing.I'm not against this (as the author of 0393) if people find this confusing, but swapping the names seems even more confusing to me.The XEPs are not so widely implemented for the moment to care much about it.Anyway, we can just give new, less confusing names for both XEPs.For example we may rename XEP-0393 to "Markdown" 'cause its syntax somewhat similar to Markdown language. With my best regards,Konstantin 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

On 8 March 2018 at 16:18, Kozlov Konstantin  wrote:
> The XEPs are not so widely implemented for the moment to care much about it.

Actually, I think XEP-0393 has several implementations in widely
deployed clients.

I was considering suggesting a Last Call at this point.

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

Re: [Standards] XEP-0393 and XEP-0394 naming

On Thu, Mar 8, 2018, at 10:18, Kozlov Konstantin wrote:
> For example we may rename XEP-0393 to "Markdown" 'cause its syntax somewhat
> similar to Markdown[1] language. 

That seems even more confusing than the other suggestion, because we'd be 
naming it "markdown" even though it's not markdown (or even compatible with 
markdown). :)

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

Re: [Standards] XEP-0393 and XEP-0394 naming

Hello! 08.03.2018, 19:20, "Dave Cridland" :On 8 March 2018 at 16:18, Kozlov Konstantin  wrote: The XEPs are not so widely implemented for the moment to care much about it.Actually, I think XEP-0393 has several implementations in widelydeployed clients.Yeah, sure. But I think, both developers and end-users do not much care about names of implemented XEPs. End-user do care about features they have and developers usually operate with XEP numbers and namespaces. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

2018-03-08 Thread VanitasVitae

Also if we'd do that, we'd have "Message Markup" and "Message Markdown"...

Am 8. März 2018 17:23:32 MEZ schrieb Sam Whited :
>On Thu, Mar 8, 2018, at 10:18, Kozlov Konstantin wrote:
>> For example we may rename XEP-0393 to "Markdown" 'cause its syntax
>somewhat
>> similar to Markdown[1] language. 
>
>That seems even more confusing than the other suggestion, because we'd
>be naming it "markdown" even though it's not markdown (or even
>compatible with markdown). :)
>
>—Sam
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

Hello! 08.03.2018, 19:24, "Sam Whited" :On Thu, Mar 8, 2018, at 10:18, Kozlov Konstantin wrote: For example we may rename XEP-0393 to "Markdown" 'cause its syntax somewhat similar to Markdown[1] language.That seems even more confusing than the other suggestion, because we'd be naming it "markdown" even though it's not markdown (or even compatible with markdown). :)Yes, maybe. It was just an example. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

On Thu, Mar 8, 2018, at 10:26, Kozlov Konstantin wrote:
> Yes, maybe. It was just an example.

Indeed. I'm okay with renaming if others agree that "styling" is confusing for 
some reason, but only if someone comes up with a name that expresses the intent 
clearer.

"Message Markup", or "Lightweight Message Markup" maybe? It's a bit of a 
mouthful.

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

Re: [Standards] XEP-0393 and XEP-0394 naming

2018-03-08 Thread Jonas Wielicki

On Donnerstag, 8. März 2018 17:18:02 CET Kozlov Konstantin wrote:
> Hello!
>  
> 08.03.2018, 19:03, "Sam Whited" :
> On Thu, Mar 8, 2018, at 10:01, Kozlov Konstantin wrote:
> 
>  I think "Markup" more suits
>  for XEP-0393 and "Styling" for XEP-0394.I guess, we should think about
>  renaming those XEPs to make their names
>  less confusing.
> 
> I'm not against this (as the author of 0393) if people find this confusing,
> but swapping the names seems even more confusing to me.
> 
> The XEPs are not so widely implemented for the moment to care much about it.
> Anyway, we can just give new, less confusing names for both XEPs.
> For example we may rename XEP-0393 to "Markdown" 'cause its syntax somewhat
> similar to Markdown  language. 

For the love of whatever is holy to you, don’t call it Markdown. You don’t 
know which pandoras box you’re opening there.

I’ll rename XEP-0394 on the next update to something more unique.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

2018-03-08 Thread Peter Saint-Andre

On 3/8/18 2:33 AM, Dave Cridland wrote:
> On 7 March 2018 at 16:26, Peter Saint-Andre  wrote:
>> On 3/5/18 3:37 PM, Christian Schudt wrote:
>>> Hi,
>>>
>>> I find the whole passage „Discovering Capabilities“ of Serverless Messaging 
>>> [1] a bit confusing.
>>
>> Are people still using this technology? In my experience, it was a fun
>> experiment in ~2006 but didn't work well in practice: too chatty over
>> the network, presence never worked correctly, you'd send a message to
>> someone and it turns out they weren't available, etc.
> 
> I'm aware of people experimenting with this on ad-hoc networks such as
> emergent vehicle networks.

I heard about such things years ago, too. Are those active projects?

> While I agree that it's probably flaky as hell in practise, I think it
> remains our best shot at this.

Do *we* need to take a shot at this?

What scenarios are we or other folks trying to solve for these days?

The original use case was ad-hoc 1:1 chat at conferences and local
networks not connected to the wider Internet. While that was interesting
12 years ago, is it interesting now? Is there some other interesting
problem that serverless messaging can solve?

Peter

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

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)