Talk:Media Transfer Protocol

Main Purpose of MTP?

The General section claims that: The main purpose of the protocol is to transfer media files. However, if that were the case, then surely UMS would simply have been adopted. Can we not therefore conclude that the main purpose of MTP is to enforce DRM? -- Ralphbk 08:35, 13 November 2007 (UTC)

No, this is not the main purpose behind the protocol. Moreover, the MTP Basic component of the protocol does not use DRM at all, and this is the component that is up for standardization. --Meiqur 07:45, 15 February 2007 (UTC)

While DRM support is a part of Microsoft's implementation, I believe the syncronization, automatic transcoding and syncronization are very compelling features. What worries me is that while you can turn off MTP and revert to a UMS mode on my Sansa player, nothing uploaded in MTP mode is even present in the UMS filesystem. But this just may be a fluke of my particular implementation. http://www.directionsonmicrosoft.com/sample/DOMIS/update/2004/10oct/1004mpumsf_sb.htm 68.226.79.69 17:37, 18 September 2007 (UTC)

I would argue that this is another monopolistic attempt on Microsoft's part due to the fact that the only OS that really has decent MTP support right now is Windows. Why else would they completly cut out support for MSC (aka UMS) mode with Plays For Sure II? Currently Sandisk is updating the firmware on some of their MP3 players so that they will no longer have a selectable MSC mode as part of the compliance with Microsoft.23:40, 12 November 2007 (UTC) —Preceding unsigned comment added by 168.184.247.53 (talk)

Yes, Main purpose is DRM, and I think someone should write about this in the wiki itself. I am no authority on DRM but but it seems to me that MTP will do nothing but make it difficult to copy my music from digital music player to hd etc.. It will also make carrying software, other than music, on these devices. Why? —The preceding unsigned comment was added by 71.108.4.144 (talk) 10:14, 19 March 2007 (UTC).

No, it is absolutely possible to make MTP devices with no DRM at all. The main points about MTP are listed on the page. Do not confuse MTP with Janus, these are two separate things, even though they often appear together. Nixdorf 20:17, 19 March 2007 (UTC)

OK, so it is possible — but did any manufacturer actually do it? If so, how did they think that helped their end users? Because I am sitting here with a MTP:ed iriver T30, and I cannot see how this is better than USB mass storage. I (my kid brother, really) expected this player to act like a normal USB memory, i.e. be usable with any modern computer, with no unreasonable OS requirements and no weird software to install first. JöG 21:23, 11 April 2007 (UTC)

@JöG: You and your kid brother might find the iriver firmware updater useful. Ralphbk 06:48, 12 April 2007 (UTC)

The Samsung SGH L760v does not support DRM portions of MTP. Nixdorf (talk) 14:07, 6 May 2008 (UTC)

Exactly how I felt when first hooking up my Samsung YP-K3. I don't use WMP, wasn't interested in WMP10, but eventually was forced to install it. Copying files to it is kind of hit and miss, slow, and difficult to determine how much data in actually on the thing.

He's right, a very large percentage of XP computers do not have support for MTP mode due to MS stupidly bundling it with WMP10 which a lot of people don't bother to install. Additionally many times MTP drivers can have issues even with WMP10 installed. 23:42, 12 November 2007 (UTC)

The point of the protocol is to provide a standard means of transferring media and metadata between a computer and a device. The advantage is that it is generally much faster than MSC when transfering media files, as the device doesn't need to scan through each file to update it's database (in my experience, there's about a 20% speed increase on a Sansa E200 for synchronizing a couple hundred songs including database update, though raw data transfer speed is slower for MTP). A properly tuned implementation which didn't need to support MSC as well would probably be just as fast as MSC for data transfer, if not even faster. Whether it can be used for DRM or not is irrelevant, and the monopoly argument is severely flawed now that it's an official USB standard (the 'enhanced' operations stuff is still pretty dubious though). As for cutting support for MSC in PlaysForSure, MTP would be easier to extend for DRM, and Microsoft probably wants to encourage people to use MTP anyway since they went through all the trouble of writing it. In any case, claiming that the purpose of MTP is to enforce DRM would be original research and highly dubious. -- Fanta2 (talk) 13:42, 8 November 2009 (UTC)

s/provide/replace/. It's not like MSC wasn't already the standard. 84.209.119.158 (talk) 14:57, 25 April 2015 (UTC)

Compared to MSC, MTP abstracts away the filesystem. This is useful for devices that want to be in control of their own filesystem:

• Being a high-level file transfer protocol, both communicating parties percieve the file transfer as a file transfer. The notion of high-level filesystem operations is in any case lost in the filesystem driver (responsible for translating high-level filesystem operations to block-addressed write requests and reordering them for speed), but in the MSC case, this is before going over the wire. MSC thus allows pure storage devices to be simple & cheap, but undermines devices' ability to deduce which files are changed in the process. Hence the need to scan the filesystem afterwards to update the metadata library.
• By not having to give away control of the filesystem to the computer, the device
  • can access the filesystem at all times — no need to separate out user visible storage with inflexible partitioning.
  • can eliminate incompletely transferred files.
  • is free from risk of filesystem corruption due to the user forgetting to "remove safely".
• By not exposing the filesystem to the computer, the device
  • is free to use whatever filesystem it wants. The de-facto FAT32 has its own drawbacks: It is hardly the most flash friendly filesystem imaginable (except that flash chips are physically adapted for it), and its 4GiB filesize limit is ridiculous.
  • does not need to support FAT32, nor requires the computer to support it. Microsoft basically owns the world with its FAT32 patents (e.g. on the peculiar way long filenames are stored), for which they still receive royalties (substantially from the sale of Android phones). It therefore amazes me that precisely Microsoft is the initiative behind MTP (It could have been Apple, they also made their own USB file transfer protocol, but that's a non-standard that's now pretty well reverse-engineered).
  • hide arbitrary files from the user, possibly as a kind of DRM.

84.209.119.158 (talk) 14:57, 25 April 2015 (UTC)

MTPSync

This program is not compiling well with the instructions given by the author. After compiling like it should be it does *not* work well. It does all kind of strange things but not the right thing. This definitly is alpha code. I am writing about working with it with the Samsung YP-U3. Should this link stay on this page? Is it not better to remove it here and move it to a programmers wiki? —Preceding unsigned comment added by 89.220.236.161 (talk) 12:34, 6 May 2008 (UTC)

Possible plagiarism

The recently added text looks like it was copied in from some source, a source which should be verified as being compliant with the GFDL I will consider reverting these addition unless the anonymous submitter stands up. Nixdorf 11:31, 15 May 2006 (UTC)

Philips GoGear

I have GoGear, and it works like a classic USB Storage device, not in MTP mode. --89.79.216.123 (talk) 21:11, 25 August 2008 (UTC)

Erroneous statement ?

"For example on Windows XP, drag and drop is only allowed through Windows Explorer when the Windows Media Player synch is running."

That is erroneous for me. With both a Sansa Clip and a Samsung YP-S5J in MTP mode, i'm able to drag drop files in them without ever using Windows Media Player (wich i wouldn't never want to use anyway). But maybe it's because i'm on XP SP3 ? TulipVorlax (talk) 08:52, 16 December 2008 (UTC)

It's a service that's installed at the same time as WMP. It doesn't require WMP to be open to work 86.146.212.64 (talk) 19:46, 11 November 2014 (UTC)

Fixup

I fixed up a few bits and pieces in this article, since some of it seemed pretty strange to me.

Intro: Changed 'movie files' to 'media files', added mention of PDA support. Removed 'no known devices' bit, because it's been over a year since July 2008 and it's probably (hopefully) inaccurate by now.

Advantages: Removed sentence on MTP being able to store more files than MSC, file storage limits are filesystem-related, not MSC-related. I think MTP is usually implemented on top of a normal filesystem, so the assertation that space is saved by MTP is probably wrong, but I think I've seen that mentioned as an advantage somewhere so I put a citation needed on it.

Drawbacks: Removed section on device-specific file management software being needed (it isn't), removed section on proprietary cables being needed (they aren't), removed section on motivations (it's unsourced, and fairly NPOV as it only gives 'bad' reasons for implementing MTP), removed bit on being unable to alter keywords (device-specific, according to the USB standard), removed ancillary data section (not related to MTP, and doesn't make much sense. Why would a media application support arbitrary file transfer?). Also changed 'modification of contents', since it was a bit incorrect (the file must be deleted and reuploaded, though I think there may be a way around this in the standard which I missed). The file is transfered in 64 byte packets (a limitation of the PTP standard, though some MTP implementations ignore this and use a packet size of 512. Windows only appears to allow this for some devices, I think it's related to whether you have an MTP OS descriptor), and interfacing with a normal filesystem really isn't that difficult.

Windows MTP support: Should this even be here? I changed the Windows 7 line to present tense and added a citation needed, since I don't know for certain where the appropriate device service definition would be (though I think I've seen mention of sensors in the MTP simulator configuration files, which seems to contain a list of most or all device service GUIDs), and I'm sure there was mention of this in a WinHEC powerpoint somewhere

Support for legacy Windows versions: Ripped out the how-to section, and the MTP porting kit description too.

Deficiencies in the Windows implementation: I removed it, MTP isn't a Windows-specific protocol. There's no citations for most issues, and some redundant information about the MTP porting kit too.

Synchronization: I ripped this out, I'd say the whole point of MTP is to allow easy synchronization of metadata. As for autosync, the WMP extention for AutoSync just adds a 'changed content' operation to notify the initiator about new content added outside of MTP (ie audio/video recordings) IIRC, and I'm not sure if that's even needed to enable automatic synchronization or not.

PlaysForSure: Should probably be moved into the main playsforsure article, but I'll leave it where it is for now.

Implementations: Removed 'native' from the 'FastPictureViewer Professional' entry, since it probably uses WPD to access the device; unless it actually implements it's own version of the MTP driver (in which case, citation needed).

Hopefully this makes the article a bit clearer -- Fanta2 (talk) 13:42, 8 November 2009 (UTC)

MTP and KDE

There is no KIO for MTP support, every KDE application implements it in their own way. Also Dolphin cannot browse MTP devices at all.

https://bugs.kde.org/show_bug.cgi?id=181968 — Preceding unsigned comment added by Sergei.Stolyarov (talk • contribs) 05:12, 10 January 2012 (UTC)

That bug is now marked "resolved fixed", with references to an "MTP KIO", as of 2013-01-12, so presumably the comment above is now out of date. Guy Harris (talk) 19:26, 16 October 2015 (UTC)

MTP problems in windows

I have noticed in Windows 7 at least, that there are a number of restrictions to MTP (and PTP) that do not apply with UMS.

• Windows Explorer can not display thumbnail images for files
• Files can not be dragged-and-dropped from Windows Explorer onto other program windows (although you can drag and drop WITHIN Windows Explorer)
• Multiple files can not be selected in the OpenFile dialogs - you are only allowed to select-and-OK one file at a time. If you try to select a second file you get an error box saying "Cannot open multiple items from this location. Try selecting a single item instead"

For the details see:

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/db592cbd-e3cb-4828-9cfe-f0826c4f925a

It isn't clear how much of these restrictions are caused by Windows rather than MTP/PTP, but there are none of these propblems if you can switch the external device to use UMS instead.

Should these restrictions be added to the list of limitations on the MTP and PTP pages? — Preceding unsigned comment added by 87.194.105.103 (talk) 13:39, 19 March 2013 (UTC)

To explain some of limitations... Thumbnails _can_ be displayed (and are) but since the file has to be transferred to the PC to generate the thumb, and MTP only allows one operation at a time (list directory, get file) it can take a very long time. Re: Drag/Drop: Behind the scenes, this works by sending the path of the file to the target application. MTP has no drive letter/traditional paths so unless the app is expecting an MTP file, it won't be able to handle it. Explorer does handle MTP files so is a valid drop target. Last one is similar to the first... MTP only allows a single operation at a time, so this is a protocol limitation. And yes, it sucks badly 86.146.212.64 (talk) 19:50, 11 November 2014 (UTC)

Windows "Data security flaw"

I removed this section with the comment: Revert -- that is not an adequate reference. Furthermore, it's a flaw in Windows, not MTP. Furthermore, it's not a flaw, because C:\Users\<user> IS a secure location.

User:60.242.152.37 responded: Then the heading should be "Windows MTP data security flaw" I will change this. This fault is user verifiable. Try a second login and view other the users file path - that path is not secured on any version of windows that I've used.

He is wrong. See here, for example. If he is able to view the users folder of another user, that is because his current user is an administrator, or perhaps he has granted cross-account access at some time in the past. – Smyth\^talk 14:45, 20 April 2013 (UTC)

"He is wrong" = Smyth. Does not stand up to scrutiny. You invalidated your own statement by providing exception that demonstrates the how the very security flaw works. Yes you can restrict an "individual" non administrator login from viewing other user file paths and other parts of windows but the data copies left behind are not secure from administrator login. A company may have a "visitors" login, it will "collect" any file opened from a connected MTP configured device. The data on the MTP device is not secured. This represents a breach of copyright and privacy against the user of the MTP device. — Preceding unsigned comment added by 60.242.152.37 (talk) 01:13, 21 April 2013 (UTC)

An administrator could just as easily install a program which allowed him to remotely view your screen, or log all the data you sent over every single USB interface of every kind. Nothing is ever secure from an administrator account. If you don't trust the administrators of a computer, you shouldn't be doing private things on it. There's nothing MTP-specific about that. – Smyth\^talk 13:36, 21 April 2013 (UTC)

The generic windows install is admin, the average user, and the average business operator does understand that the MTP implementation on windows strips data from the MTP device. The data security is still valid for MTP on windows. Playing your music files would breach copyright if someone else accessed the files later. It is not informed to anyone that this is happening. You may not keep anything person on your phone but the millions of users for whom their devices are personal, are. They may want to know that the issue exists. The "citation needed", simple user testing by anyone. — Preceding unsigned comment added by 60.242.152.37 (talk)

A little history, PTP was orignally a hack of the USB implementation that saved a camera company money because they didn't have to implement a full USB stack on the camera (USB was pretty expensive then). The implementation had a side effect in that users couldn't use the full USB stack of features and so it acted like a limited DRM system. Microsoft took this side effect ( sic: feature ) further and gave us MTP. The resulting system is so restrictive that workarounds are implemented to access a users files/media or any other data they create on the device. As usual with work arounds they come with their own issues. One of those is that files have to be copied off the device before opening and as a result we have the biggest theft of personal user data the world has ever seen. — Preceding unsigned comment added by 163.189.7.40 (talk) 03:08, 28 June 2013 (UTC)

"Control" vs "allow"

User:60.242.152.37 has introduced the word "control" in numerous places in this article. Here is the explanation he left on my talk page:

The Media transfer protocol controls the transfer of data by overlaying the underlaying transfer method and limiting the full access the underlying transfer system allows. For example, it does not add to the abilties USB but it does control the access to and functioins of USB, it will not work without the underlying system functions. It does not "allow" the transfer of files, that is part of the underlying system and is already there, it controls how the data is transfered through the underlying sustem.

PTP was developed by camera manufactures to save cost by not having to supply a full USB interface. It allowed access only to those functions the device was capable of. Microsoft adapted it to control and limit the function of the full USB interface.

A paraplegic in a wheelchair will benifit from the improved access a wheelchair allows but but for a person who can walk a wheelchair controls and limits where he can go. MTP is designed to control and limit the access that the underlying system allows. — Preceding unsigned comment added by 60.242.152.37 (talk) 04:07, 20 April 2013 (UTC)

MTP is not built on top of USB Mass Storage, so it doesn't make sense to talk about "underlying abilities" of USB which are "already there". It is simply a different way of accessing an external filesystem, at the level of files rather than disk blocks. This allows certain activities which would be impossible under USB Mass Storage, such as simultaneous access by the device and the host (to different files, of course).

He is obviously trying to make a point about DRM, but the article makes it clear that DRM is an optional aspect of MTP which is not even part of the core protocol. For example, it is not used in the Android MTP implementation. – Smyth\^talk 14:54, 20 April 2013 (UTC)

What I'm trying to describe is the functional behaviour of MTP (Not DRM). MTP does not function without first connecting through the underlying interface. The MTP implementation at each end then hides the USB (or other) interface and gates off the other functions of the underlying interface, "tunnelling" to MTP components at each end. The USB connection "allows" the transfer, MTP "controls" it. The seeminigly simultanious access within the MTP configured device being provided because MTP limits tranfers to one transfer at a time for the MTP device, the device then only sees one incoming/outgoing transfer at a time "allowing" the device to perform other functions, multiple simultanious PC transfers to the MTP device are not allowed. A user from the PC side must wait until the previous transfer is complete before commencing another, therefore MTP does not provide simultanious access and the access across MTP (through the USB connection) from the PC side is "controlled" by MTP. — Preceding unsigned comment added by 60.242.152.37 (talk) 02:17, 21 April 2013 (UTC)

The "underlying interface" is simply a raw USB, TCP or Bluetooth connection, i.e. a 2-way byte stream. It has no "functions" in itself, so there is nothing to be "gated off". So I really don't know what your point is. Would you also replace "allow" with "control" in an article such as SMTP? – Smyth\^talk 13:47, 21 April 2013 (UTC)

Maybe because MTP doesn't work without the USB, TCP or Bluetooth interface? It's not called an MTP interface is it, it's a protocol - a method of communicating within set parameters. And those parameters are limited by? Well the interface within which it operates of course. It blocks and replaces any access to the other parameters available. The standard interface is still blocked, interupted, controlled by MTP. USB, TCP or Bluetooth, if it's not using the interface, what is it's protocol limits? It must first use that interface, or it's own version of the minimum, the very same thing PTP is, a stripped out version of USB. If MTP expanded on the abilities available then of course it would be "allow"ing the user to do things, the point is that it that the interface it already capable of far more than the MTP allows, therfore MTP controls the interface. — Preceding unsigned comment added by 60.242.152.37 (talk) 09:53, 27 April 2013 (UTC)

Again, nothing is being "blocked", "replaced", or "interrupted", because the underlying protocol layers do not do anything other than provide a communications medium. A USB interface is not capable of accessing a disk by itself. You are making an implicit comparison with USB mass storage, but as I have already shown, the features of MTP are not a subset of the features of USB mass storage. – Smyth\^talk 00:35, 28 April 2013 (UTC)

Deceptive (to a non-technical reader) part about block size?

"making the unit of managed storage a local file rather than an entire (possibly very large) unit of mass storage at the block level"

When the media were jpeg images, fs blocks might have been adding a lot to the transfer size over USB, but in the context of MTP, "(possibly very large)" wouldn't be accurate. — Preceding unsigned comment added by 38.99.42.130 (talk) 17:38, 19 July 2013 (UTC)

That fragment is not concerned with transfer size, but the vulnerability of exposing the storage at a too basic level. Imagine you were a storage device. As a storage device, you will likely get the blame if the fileystem stored on you becomes corrupt, even if it's the user's fault, which it might well be. The filesystem looks a lot like a house of cards (see binary tree), only with blocks instead of cards. Some filesystem operations, like adding or removing files, will sometimes need to optimize the internals of your cardhouse (rebalance a subtree). As you can imagine, replacing any one card of your cardhouse, if left half-done, will cause your cardhouse to collapse. Now, the mass-storage device protocol works like this: You are cardhouse agnostic; the client manipulates your cardhouse (overwrite blocks) directly, and you must hope you aren't disconnected in a particularly bad half-done state. MTP works more like the client tells you what to do, and you do it — either completely, or you undo it if something unforeseen happens. --84.208.189.151 (talk) 22:48, 14 March 2016 (UTC)

Implementation vs. specification

A lot of this article discusses limitations that may or may not be flaws in the Microsoft implementation of MTP. At one time, the argument could be made that it was not practical to talk about Microsoft's implementation vs. the specification as separate things. However, with Android devices using MTP there now exists significant independent support. In particular, the lack of parallelism jumps out at me as being a problem in Windows, or Windows Explorer. I can say from personal experience using go-mtpfs on Linux (written by a Google employee), that this is not true. Now, it could be that go-mtpfs does some caching and queuing tricks - I know it does this to speed up directory listing, for example. The article discusses the Android dio extensions, but is unclear about what "Drawbacks" exist because of shortcomings of the protocol itself and which exist in major implementations (i.e. Windows).

On a more minor, but related note, it seems like discussions of Windows security bugs that happen to involve MTP are largely irrelevant to the article. Like I said, at one time "Microsoft MTP" and "MTP could be said to be one and the same, but with Google's move to MTP, it's harder to say that now. 108.183.217.0 (talk) 21:45, 1 August 2014 (UTC)

Google's move to MTP seems to be more about limiting the user to functions of it's Android devices, or rather preventing users from accessing Android device file systems via MSC. Secondly, DRM extensions can be implemented automatically at any time by Google through Android updates. — Preceding unsigned comment added by 60.240.216.247 (talk) 12:06, 26 October 2014 (UTC)

Drive Letter problem

The article describes the MTP Missing Drive Letter problem, which is quite a serious limitation when accessing an Android phone from a Windows computer via USB cable. Please add information about getting around the problem. There seem to limited solutions on the Windows end, such as a plugin for TotalCommander. Solutions from the phone end seem better, such as the free app "MTP-Alternative USB Drive".-73.61.15.208 (talk) 16:56, 21 December 2017 (UTC)

MTP file data hidden missing

• android.stackexchange.com/questions/46315/not-all-files-are-visible-over-mtp
• droidguiding.com/certain-folders-and-files-missing-in-pc-while-they-are-in-phone-how-to-fix-it/

"All you need to delete the app cache and data from ‘Media Storage’ and ‘External Storage’ system apps on your phone. All files and folders will appear on the PC then."

When accessing a file system via MTP (Moto E4 And711 USB Win7pc) it may report much greater total content than can actually be seen as individual files: Almost 2GB reported total, only about 600MB seen, over 1GB missing content. Why? Is there some way to find out what files/data is being hidden? (The above two links discuss a similar problem, but in this case clearing app cache and rebooting etc does not help.) Please add relevant info to the article about this issue.-73.61.15.50 (talk) 16:56, 22 December 2017 (UTC)

MTP is unreliable and headacheful. Should these annoyances be mentioned?

In my experience, MTP sometimes gets stuck transferring files, does not show newly moved/created files and to just “Prepare for copy”, it needs half the time of the copying itself, while mass storage copying starts immediately.

And when it gets stuck, pressing “Cancel” leads to “in progress of cancelling”, which lasts indefinetly. It sounds as absurd to me as “Loading ‘error’ text. Please wait.”. The only thing one can do is physically plug the USB cable out of the phone or PC.

Additionally, MTP can get stuck in a disconnection/reconnection cycle. I left my mobile phone connected to the computer and left. When I came back, the computer greeted me with an avalanche more than 100 udev error messages that have appeared because MTP failed to reconnect to the device that many times. So MTP can flood one's computer with error messages.

Since the beginning, MTP has always been a huge bothersome, headacheful obstacle to me. I know the advantages of it, but it is so unreliable that I despise it. And PTP is no real alternative because it hides all non-photo files.

When trying to access files while something else is already being transferred, it gets unresponsive indefinitely.

MTP is a luxury problem.

I suggest this to be mentioned in the article, but I am asking here if anyone else is familiar with it. –Chanc20190325 (talk) 13:43, 2 June 2019 (UTC)

That would need citations from reliable sources for the problems; those citations would presumably indicate whether those problems are problems with the MTP protocol, or just deficiencies/bugs with the implementation on your PC or your phone. Guy Harris (talk) 18:01, 2 June 2019 (UTC)

Yeah it is hopeless, the whole article should be about that :p Pretty much never works. — Preceding unsigned comment added by 180.150.71.154 (talk) 23:36, 24 January 2020 (UTC)

What happens during “prepare to copy files”? (technical explanation)

When initiating a data transfer of thousands of files from an Android OS device, no matter whether big or small files, before the first of those files starts getting transferred, the operating system shows “Preparig to copy files”.

It might take 10 minutes before the first file has been transferred, while on mass storage, file transfer starts immediately.
Sometimes however, it just takes one minute or less, surprisingly. (It tends to take less time after rebooting the device.)

I encourage someone to add a technical explanation to this behaviour. --Handroid7 (talk) 07:10, 1 August 2019 (UTC)

Section «Comparison with USB Mass Storage» has issues

These issues:

• «The neutrality of this section is disputed.»
• «This section possibly contains original research.»

What needs to be done to resolve them?

What I think this section should be about

• Saying what it is is only meaningful to technical people; saying what it does doesn't add to anyone's understanding. I started this section in order to list some implications between the two, so to add meaning to what it is and overview to what it does.
• The comparison is there for contrast; it's not about which protocol is best. Often, as in this case, it's more telling to describe what it isn't, especially to explain the flaws it doesn't have. I think the ± notation makes it look more like a neutrality debate than it is – it isn't.
• There are some unresolved possibly implementational flaws that at least needs to be clearly separated. They do not currently aid the discussion of the inherent properties of the protocol, and they may be irrelevant if this is the goal.

—Anordal (talk) 00:23, 9 May 2023 (UTC)