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

[Daniel Gultsch]

Am Di., 25. Feb. 2020 um 15:54 Uhr schrieb Jonas Schäfer :
>
> The XEP Editor would like to Call for Experience with XEP-0066 before
> presenting it to the Council for advancing it to Final status.
>
>
> During the Call for Experience, please answer the following questions:
>
> 1. What software has XEP-0066 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.

I have implemented read and write support for x:oob in Conversations.
The implementation is independent of other implementations.

I do have read support for incoming iq:oob but I don’t think anyone
has ever used it.

>
> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0066? If so, please describe the problems and, if
> possible, suggested solutions.

Kinda. See below.

> 3. Is the text of XEP-0066 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.

I find the jabber:x:oob section a bit ambiguous. While the section
jabber:iq:oob clearly talks about file transfer, the x:oob section
talks about URIs in general. While some implementations in the wild
use that along side HTTP File Upload to communicate that a certain URL
was actually meant as a file transfer (to distinguish them from
regular, copy pasted, URLs) some clients just to regex on the input
field and if the message loosely resembles a URI they will send an
x:oob element.

These two interpretations are clearly at odds with each other because
clients that expect x:oob to mean file transfer will trip over clients
that use them for any kind of URL.

While the language in x:oob allows them to do that I honestly don’t
see the point in proving to the other side that you can do regular
expressions on the user input.

cheers
Daniel
___
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

[Christian Schudt]

Hi,

see my answers below.

> Am 25.02.2020 um 16:52 schrieb Jonas Schäfer (XSF Editor) 
> :
> 
> The XEP Editor would like to Call for Experience with XEP-0066 before
> presenting it to the Council for advancing it to Final status.
> 
> 
> During the Call for Experience, please answer the following questions:
> 
> 1. What software has XEP-0066 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.

I’ve implemented in xmpp.rocks aka Babbler (Java XMPP library).

> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0066? If so, please describe the problems and, if
> possible, suggested solutions.

Unfortunately I never really integrated it with SI File Transfer as written. 
Instead I’ve treated Example 1 as File Transfer Offer like in Example 8 and 
mapped the URL’s 'Content-Length' header to the „size“ attribute, the  
element to the „name“ attribute and the OOB  element to the SI  
element, hiding everything behind a generic interface.

That kind of works and now that XEP-0096 is deprecated I am even more wondering 
if this integration should be part of the specification.

> 
> 3. Is the text of XEP-0066 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.


Although the specification is eventually relatively clear to work with URIs, it 
often mixes the terms „URL“ and „URI“, which even misled me to introduce a bug 
(software worked with URL only, not with URI):
https://bitbucket.org/sco0ter/babbler/issues/88/oobx-url-restrictions

It is confusing that the XML element is named „url“, but in fact it can contain 
URIs.

I suggest to be more clear in the text and only use „URI“, since the XML 
element name should not change.

Kind regards,
Christian


___
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

[Kozlov Konstantin]

Hello! 23.03.2018, 02:28, "Emmanuel Gil Peyrot" :Hi,On Thu, Mar 22, 2018 at 11:57:52AM +0300, Kozlov Konstantin wrote:I don't see any XEP which describes of full procedure of file transferusing OOB.But [1]XEP-0095: Stream Initiation has [2]mention of using OOB as streammethod.I guess, this method never used before, just because there were no way getan URL of a file to transfer. But now we have [3]XEP-0363: HTTP FileUpload, which allows to upload a file to a HTTP server and get its URL.I think we need an Informational (or maybe Standards Track?) XEP, whichdescribes such way of file transfer, using [4]XEP-0096: SI File Transfer(deprecated) and [5]XEP-0324: Jingle File Transfer (recommended) as filetransfer application, [6]XEP-0066: Out of Band Data as stream method and[7]XEP-0363: HTTP File Upload as supplementary XEP for file uploading.Do you mean XEP-0370[1]?[1] https://xmpp.org/extensions/xep-0370.htmlNo. The idea was to reuse existing XEPs and namespaces, not creating another one. With my best regards,Konstantin___
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

[Emmanuel Gil Peyrot]

Hi,

On Thu, Mar 22, 2018 at 11:57:52AM +0300, Kozlov Konstantin wrote:
>Hello!
>
[snip]
>I don't see any XEP which describes of full procedure of file transfer
>using OOB.
>But [1]XEP-0095: Stream Initiation has [2]mention of using OOB as stream
>method.
>I guess, this method never used before, just because there were no way get
>an URL of a file to transfer. But now we have [3]XEP-0363: HTTP File
>Upload, which allows to upload a file to a HTTP server and get its URL.
>I think we need an Informational (or maybe Standards Track?) XEP, which
>describes such way of file transfer, using [4]XEP-0096: SI File Transfer
>(deprecated) and [5]XEP-0324: Jingle File Transfer (recommended) as file
>transfer application, [6]XEP-0066: Out of Band Data as stream method and
>[7]XEP-0363: HTTP File Upload as supplementary XEP for file uploading.

Do you mean XEP-0370[1]?

>
>With my best regards,
>Konstantin
>
> References
>
>Visible links
>1. https://xmpp.org/extensions/xep-0095.html
>2. https://xmpp.org/extensions/xep-0095.html#usecase-neg
>3. https://xmpp.org/extensions/xep-0363.html
>4. https://xmpp.org/extensions/xep-0096.html
>5. https://xmpp.org/extensions/xep-0234.html
>6. https://xmpp.org/extensions/xep-0066.html
>7. https://xmpp.org/extensions/xep-0363.html

[1] https://xmpp.org/extensions/xep-0370.html

--
Emmanuel Gil Peyrot


signature.asc
Description: PGP signature
___
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

[Kozlov Konstantin]

Hello! 21.03.2018, 14:32, "Christian Schudt" :Maybe you are right. It was just a guess, because someone asked for the purpose of 0066.Because the uploaded file is persistent (at least for some time), I concluded that the purpose is for offline file transfer.Maybe the intention was to use jabber:iq:oob, in case the recipient is online and fallback to jabber:x:oob, if the recipient is offline.Clearly the intention was to have a basic file transfer mechanism, this is what it says for jabber:iq:oob.About using jabber:iq:oob for file transfer... I don't see any XEP which describes of full procedure of file transfer using OOB.But XEP-0095: Stream Initiation has mention of using OOB as stream method.I guess, this method never used before, just because there were no way get an URL of a file to transfer. But now we have XEP-0363: HTTP File Upload, which allows to upload a file to a HTTP server and get its URL.I think we need an Informational (or maybe Standards Track?) XEP, which describes such way of file transfer, using XEP-0096: SI File Transfer (deprecated) and XEP-0324: Jingle File Transfer (recommended) as file transfer application, XEP-0066: Out of Band Data as stream method and XEP-0363: HTTP File Upload as supplementary XEP for file uploading. With my best regards,Konstantin___
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

[Christian Schudt]

 

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

> Given the primary mechanism in -66 is iq-based, I don’t think this is true, 
> or I misunderstood your point.

Maybe you are right. It was just a guess, because someone asked for the purpose 
of 0066.
Because the uploaded file is persistent (at least for some time), I concluded 
that the purpose is for offline file transfer.

Maybe the intention was to use jabber:iq:oob, in case the recipient is online 
and fallback to jabber:x:oob, if the recipient is offline.

Clearly the intention was to have a basic file transfer mechanism, this is what 
it says for jabber:iq:oob.

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

[Kevin Smith]

On 8 Mar 2018, at 09:25, Christian Schudt  wrote:
> TL;DR: The purpose is/was to transfer files in case the receiver is offline.

Given the primary mechanism in -66 is iq-based, I don’t think this is true, or 
I misunderstood your point.

/K
___
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

[Kevin Smith]

On 7 Mar 2018, at 19:17, Jonas Wielicki (XSF Editor)  
wrote:
> 
> The XEP Editor would like to Call for Experience with XEP-0066 before
> presenting it to the Council for advancing it to Final status.
> 
> 
> During the Call for Experience, please answer the following questions:
> 
> 1. What software has XEP-0066 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.

We have not, and are unlikely to do so in the current state.


There are significant security/privacy issues around 66. The payload used as a 
method of communicating URLs is fine (although I think References is ultimately 
more helpful for this - at least in the next version that we’ll have ‘soon’), 
but that a client receiving an iq is expected to immediately fetch a file and 
then say when it’s done, or error if it was unable is riddled with problems. 
Also, multiple URI schemes are allowed, including making video calls, but the 
interaction between "The receiving application MUST NOT send the IQ result 
until it has retrieved the complete file (e.g., it MUST NOT send the IQ result 
if it has merely attempted to retrieve the file or the URL provided seems to be 
valid)” and non-file URIs is not obvious. All the text around SI would 
presumably also need to go before this was advanced.

/K
___
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

[Jonas Wielicki]

On Mittwoch, 7. März 2018 20:17:29 CET Jonas Wielicki wrote:
> 1. What software has XEP-0066 implemented?

We have support for the  flow in JabberCat (GPLv3), like in gajim 
and Conversations as already mentioned elsewhere in this thread.

We do not implement the IQ workflow, nor do we intend to do so. This is not 
due to lack of peers which support this (even though if a large number of 
clients were actively using that, we would probably follow), but we think that 
there are better alternatives out there.


> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0066?

The  flow is super straightforward. However, I think it is too 
simple to be really useful. Things like MIME types, possibly a file size, 
would be good to have to allow for easier UI handling. I think that SIMS is 
more appropriate for this use-case.


> 3. Is the text of XEP-0066 clear and unambiguous?

Frankly, I didn’t read most of the text. I implemented this for compatibility 
with Conversations and others.

For the same reason, I don’t think that the XEP as-is should go to Final. Much 
of it seems to not be implemented as evidenced by the list feedback. It also 
feels superseded by more modern methods of transfer.


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-0066: Out of Band Data

[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] Call for Experience: XEP-0066: Out of Band Data

[Daniel Gultsch]

Same what Philipp said. Most (not all) clients I know implement a
small subset of the XEP to basically annotate that the URL that is
already in the body of the message should be treated as an
'attachment' or a file download instead of a regular text URL.
This feels like an odd hack and not the intended purpose of the XEP.
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.

cheers
Daniel

P.S.: I was the one who pushed the usage of this hack and it currently
does an OK job for this 'annotation' use case. That doesn‘t mean this
XEP should go forward though.

2018-03-08 0:22 GMT+01:00 Philipp Hörist :
> 1. What software has XEP-0066 implemented?
>
>
>
> Gajim, only 3. communicating a uri via message
>
>
>
> 2. Have developers experienced any problems with the protocol as
>
> defined in XEP-0066?
>
>
>
> Not with 3., but cant comment on the other XEP Parts
>
>
>
> 3. Is the text of XEP-0066 clear and unambiguous? Are more examples
>
> needed?
>
>
>
> 3. Is clear, cant comment on the rest
>
>
>
> We implemented primarily as a hack so we can mark messages that contain only
> a httpupload link, we add the uri also in the oob tag, and other Clients can
> treat this message differently, for example displaying the image, instead of
> displaying any random weblink that someone sends with a message.
>
>
>
> regards
>
>
>
> ___
> 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] Call for Experience: XEP-0066: Out of Band Data

[Kozlov Konstantin]

Hello! 07.03.2018, 22:18, "Jonas Wielicki (XSF Editor)" :The XEP Editor would like to Call for Experience with XEP-0066 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-0066 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 (partially) in eyeCU and Vacuum-IM. Both clients have the same codebase. Also, it is implemented in MRIM transport.2. Have developers experienced any problems with the protocol asdefined in XEP-0066? If so, please describe the problems and, ifpossible, suggested solutions.In Qt version of eyeCU I implemented only attaching URLs to messages right now. The same story with Vacuum-IM. Other usages of OOB is not implemented yet, but I plan to imlement them later.J2ME version of eyeCU allowed to send URLs via  stanza and control download, but it is abandoned right now.I experienced no problem implementing those features.The only suggestion is to provide mechanism to notify other party of download progress (not only of the fact, that file was downloaded).3. Is the text of XEP-0066 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.Yes. Everything is all right.If you have any comments about advancing XEP-0066 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,KonstantinYou can review the specification here:https://xmpp.org/extensions/xep-0066.htmlPlease send all feedback to the standards@xmpp.org discussion list.___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
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

[Philipp Hörist]

1. What software has XEP-0066 implemented?



Gajim, only 3. communicating a uri via message



2. Have developers experienced any problems with the protocol as

defined in XEP-0066?



Not with 3., but cant comment on the other XEP Parts



3. Is the text of XEP-0066 clear and unambiguous? Are more examples

needed?



3. Is clear, cant comment on the rest



We implemented primarily as a hack so we can mark messages that contain
only a httpupload link, we add the uri also in the oob tag, and other
Clients can treat this message differently, for example displaying the
image, instead of displaying any random weblink that someone sends with a
message.



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