Talk:Proprietary protocol

Trivial Cruft Example

Do any of the major editors of this article have a problem with the removal of the three meaningless examples of "proprietary protocols"? One is primarily a piece of software, only one is truly proprietary in the biased sense the article is meant to portray and the other is speculative definition. - Jimmi Hugh (talk) 04:39, 12 December 2008 (UTC)

No, I'm ok with it. - Jimmi Hugh (talk) 04:39, 12 December 2008 (UTC)

Ok then, deleted it is. - Jimmi Hugh (talk) 04:39, 12 December 2008 (UTC)

It is not possible to connect to the Skype network without software created by Skype because the Skype protocol is closed. It is a good example of a proprietary protocol. Skype on its website states its network uses a proprietary protocol You do not have consensus for the deletion. pgr94 (talk) 08:11, 12 December 2008 (UTC)

Fascinatingly childish. Good edits though this time, except for the other stuff you through in without thinking again, but I removed them, so don't worry. Remember though that we're not an informative source of original information, we're an encylcopedia, numerous examples will ruin the feel of an article. - Jimmi Hugh (talk) 20:56, 12 December 2008 (UTC)

"Possible revenue from royalties by licensing the protocol."

Why did you remove this obvious advantage? Microsoft earns US$ 100k per ActiveSync license. I wish you could make your edit comments clearer (or is that a proprietary protocol too). pgr94 (talk) 22:14, 12 December 2008 (UTC)

Yes they do. However that's not an advantage of ownership... it's simply a single business factor for that product; one that can't be attributed to property law in general. While it may seem the advantage is caused because it's proprietary, there are many other factors involved and it comes off as highly biased when related to this article. However, make sure any such information is on the ActiveSync article where it belongs, I'm not trying to censor information, just remove stuff that isn't really related to proprietary, so we don't end up changing the meaning of the word proprietary when attached to the word protocol. - Jimmi Hugh (talk) 12:04, 13 December 2008 (UTC)

Deleted text about the Skype protocol

Here is the deleted text that is the subject of discussion in the following sections:

The Skype protocol is a proprietary protocol. The protocol is a trade secret protected by using closed source software. Furthermore, to prevent reverse-engineering the binary is protected with anti-debugging and code obfuscation techniques.

Reason given for deletion by Jimmi Hugh: "Removed comments on source code. While it seemed fair enough, a protocol is not defined by the code that implements it, and we have no sources n the actual "protection" of the standard"

References

"a protocol is not defined by the code that implements it"

Wrong. A protocol specification is a set of rules (cf communications protocol), so it can be expressed in C, Pascal, Lisp, as a finite state automaton, or a natural language recipe. See Church-Turing thesis which concerns their equivalence. pgr94 (talk) 09:28, 18 December 2008 (UTC)

Hehe, questioning your irresponsible and thoughtless edits is "rude", but telling me I'm wrong because you don't understand the world around you isn't? Bless you. Correct, a protocol specification is a set of rules, expressed in anyway the developer likes. The Skype protocol development team has never released the stanard in the form of a C program, so we can't say that, and they've never released it as a correctly formed document either so I won't mention that. It's also childish for us to make claims that they protect the standard because a single product that implements (not defines) the standard doesn't have code available to everyone. They do protect it however, by simply not releasing the details of the standard, a process that would feature documentation, not code. Please stop revetrting for the sake of reverting simply because you don't like the way the world is, I apologise that you have a problem with closed source code and people not telling you all of their ideas, but I couldn't really care less about anything but the facts pertinent to the actual topic, presented in an encyclopedic manner. This is not your personal webpage for making a case against skype. - Jimmi Hugh (talk) 15:26, 18 December 2008 (UTC)

The executable code specifies the protocol in the same way as C source or a set of rules. You should look up the Church-Turing thesis, it is taught in all good computer science courses. By releasing the executable Skype is supplying the protocol, albeit in a hard-to-understand form. This has nothing to do with my personal opinion I am just pointing out the facts and I suggest you maintain it at that level too. pgr94 (talk) 15:52, 18 December 2008 (UTC)

Well, firstly, the Church-Turing thesis has about as much todo with this, as Classic Mechanics has todo with the specifications for a Vacuum cleaner. Secondly, it is your personal opinion that the fact the source code to a single implementation (not definition, I suggest you read up on language, implementation, source code, specifications, standards, English, release, proprietary and naive) of a protocol (look up protocol too) is not available for you to view is due to attempts ot hide the protocol. It is also extremely extremely, less than intelligent to claim that source code defined a protcol just because the protcol can be understood from it, the fact you don't understand this is extremely worrying and I really don't know how to make a logical case to someone who really doesn't understand, anything. - Jimmi Hugh (talk) 15:59, 18 December 2008 (UTC)

(Ignoring yet more insults - try rigorous argument).

I'll re-iterate why the Church-Turing thesis is relevant:

1. By definition a communications protocol is a set of rules.
2. A set of rules can be translated to a Turing machine and executed.
3. Executable code can also be translated to a Turing machine.
4. Therefore, both a communications protocol and executable code are equally expressive, that is, they can express the same things.

By this logic, it is clear that the Skype executable code is just one of many possible descriptions of the Skype protocol.

Formal specifications expressed in Z notation and UML are equally covered by the Church-Turing thesis.

If you disagree please provide a technical explanation instead of more arm-waving because it's not constructive. pgr94 (talk) 16:42, 18 December 2008 (UTC)

Well done, you repeated exactly what I said... discussion over. Source code can be just as expressive, exactly as I said. Now, you're probably going to be confused, so instead of assuming your right and making me repeat myself, go back and actually read the discussion and you'll see I've already said exactly this, and the Church-Turing thesis is of course not relevant to the deleted content. - Jimmi Hugh (talk) 17:43, 18 December 2008 (UTC)

I am just clarifying that a protocol is defined by the code that implements it. In your edit comments you have said the exact opposite to justify deletion. So if you now agree can we restore that deletion or do you have further objections? pgr94 (talk) 17:58, 18 December 2008 (UTC)

I think you misunderstand... completely. Once again, try reading the comments I've already and I will make them one last time. No, the content should not be restored. Yes source code can express a protocol, but a single implementation is not *the* definition. More importantly to this single case, we have no reason to suspect anyone in skype does consider it the definition. Even more importantly that that, we aren't here to stipulate the reason the source is not available to you, this isn't the proprietary software article, we're not pushing a POV. - Jimmi Hugh (talk) 18:04, 18 December 2008 (UTC)

You are raising many different issues and they are not being handled in any depth. For the sake of clarity I'd like to stick to one topic at the time, namely the title of this section. We can address other issues separately.

Conclusion: a protocol is defined by the code that implements it, be it source code, a technical document or executable code. pgr94 (talk) 09:44, 19 December 2008 (UTC)

That really depends on your definition of issue. I don't believe they're issues because they're gone, and because they're about as necessary to discuss as whether we should include information on the colouring used for comments in the IDE taht Skype is developed in. It's probably green, but nothing todo with the article and completely stipulated.

A Protcol is not defined by the code that implements it. I'd like to bring up again my previous Vaccum cleaner analogy. Because of the way the Universe works, we're able to view the Vaccum cleaner, even take it to pieces and discover exactly how it works. Imagine it has a single component (some sort of internal sucking device) that is the same, or based on the same design as is used in a numer of other vacuum cleaners. We wouldn't even dream of claiming that because we can take from the Vacuum cleaner enough data to accurately describe the sucking mechanism that it was the definition. You may claim that as source code is not run on the final system that's not right, so take the idea that could say the same about the machine that creates the vacuum cleaner, which you wouldn't have access to, but you still wouldn't guess that the Vacuum cleaner corporation considered that to define it's system. - Jimmi Hugh (talk) 16:10, 19 December 2008 (UTC)

So let me throw my two cents in here. I tend to agree with Jimmi Hugh on this issue. Take for example 802.11g, which defines a Media Access protocol. Each vendor's individual implementation of 802.11g is not wholly representative of the rules, although they produce the same or reasonably similar results to the reference provided by the definition of 802.11g. You seem to argue:

1. A implies B. (Communications protocols are rules)
2. B implies C. (Rules can be represented by a Turing Machine)
3. D implies C. (Executable Code can be represented by a Turing Machine)
4. Therefore, A implies D. (Communications Protocols = Executable Code)

The issue I have is with statement 4. It feels like a logical fallacy to me. It does not follow that executable code can be taken to be equivalent to the rules of a protocol it intends to implement for various reasons:

1. Bugs may exist in the executable that cause it to preform out of sync with the fullness of the protocol description.
2. A specific implementation of a protocol may have features that are not present in the protocol description.

I'm sure others can be demonstrated. To frame my argument correctly:

1. All horses have patterns.
2. An Arabian is a kind of horse.
3. A Palomino is another kind of horse.
4. The pattern of a Palomino is not the same as the pattern of an Arabian.
5. Therefore simply because P₁ and P₂ are subsets of P does not imply that P₁=P₂

Hope this helps! QuackCD (talk) 01:28, 9 January 2009 (UTC)

"a single implementation is not *the* definition"

In the case of Skype, the distributed executable is the definition of the protocol in that particular Skype version. To the best of my knowledge, the publicly available implementations are the only definitions known and I think it is original research to speculate on what you call "*the* definition". (talk) 09:51, 19 December 2008 (UTC)

In the case of skype, the distributed executable is a distributed executable. Ironically I think the exact opposite to you about the next part :-P. It's completely WP:OR to guess that the definition (think definition as in the real term, or C function decleration, not as in a C function definition) is entirely documented in the source code. I think it far more likely that we simply can't say how the protocol is defined, we can say one hundred percent that it is implemented in the executables though. An executable never defines a protcol though. I do however agree, we can't guess how they define the protcol, that's there business, so I didn't replace the comments by speculating on the internal documentation. - Jimmi Hugh (talk) 16:14, 19 December 2008 (UTC)

proprietary protocols often surpass capabilities of standards-based interoperable solutions

proprietary protocols often surpass capabilities of standards-based interoperable solutions

This statement has been removed repeatedly by User:Jimmi Hugh. The cited source says:

Dumbing down for interop

As vendors reconfigured their products in test after test, it became clear that any reconfiguration into a standards-based interoperable mode comes at the expense of value-added proprietary functionality. [...] Other vendors agreed that proprietary capabilities often surpass what standards-based interoperable solutions deliver. [...] Other vendors, too, had to throttle back valued-added proprietary functionality to interoperate.

Have I mis-interpreted the source? pgr94 (talk) 15:55, 8 January 2009 (UTC)

Perhaps we simply interpret it differently. Seeing an assumption by that article (which isn't notable enough to be taken as a definition) that the word proprietary meant something that it does not mean, I took the meaning of "standards-based" to imply open. Otherwise the quote I removed translates to nothing more than, "standards-based interoperable solutions often surpass capabilities of standards-based interoperable solutions." This really doesn't make much sense, because obviously it is not definite that a proprietary protocol is not standard or interoperable, infact these seem like fair assumptions to the opposite. Remember, proprietary simply means ownership, many open standards are still technically proprietary, this is not an issue of the medical term used in "proprietary software". - Jimmi Hugh (talk) 17:39, 9 January 2009 (UTC)

Observations

Hi Jimmi Hugh, hi pgr94, you have asked for comments on the Wikipedia:WikiProject Computer networking talk page. Don't know if it will help but I observed the following:

1. 5 pages discussion about a 1 page stub is not very effective, please consider devoting your time and energy to other topics as well.
2. In the argument about the turing machine you use different meanings of "define". For a protocol, "define" means "lay down the set of rules". In formal logic, "define" means "indistinguishable by the formal methods of the calculus". For the discussion about protocols the latter meaning, and therefore the halting problem, is not relevant even if it was true.
3. Keeping secrets and making money through licensing is only one side of proprietary protocols (PPs). It seems you both overlook the other side which is: slowly reacting standardisation bodies. PPs are often the only way to deploy improvements, and often the PP disappears after the improvements they introduce have been standardised. Example: 802.1Q replaced ISL, and now Cisco itself implements only the IEEE standard.
4. I'm not too familiar with Skype (it is illegal where I live). But if there is disagreement about it, why not a) take a different example for PPs, and b) contribute a section about the disagreement in the article Skype?

Generally, if there is disagreement about facts or interpretations, and if both sides can contribute reliable sources: Do not revert each other but document the disagreement in a section like "Controversy" or "Criticism" in the appropriate article.

Hope this helps, Pgallert (talk) 08:09, 6 February 2009 (UTC)

Business strategy

Do you have a single source connecting that seemingly arbitary commentary to proprietary protocols as a concept? Or even to application of proprietary protocols, because they are proprietary as opposed to it being an unimportant factor? - Jimmi Hugh (talk) 14:37, 18 February 2009 (UTC)

It's all in the sources I linked --- it is neither desirable nor legal to quote the whole document. Anyway, I have provided references showing that proprietary extensions to a protocol can be used as a business strategy. Hope that clarifies things for you. pgr94 (talk) 15:16, 18 February 2009 (UTC)

I hope you accidentally posted the wrong reference, if refering to [1]. This document (ignoring verifiability/notability/qualifications and the fact it isn't a third party source on any topic, but a rant) does not once make the distinction that proprietary protcols are in anyway related to the comments about Microsofts position, and for the most part is discussing Open Source software, a concept so far apart from the term proprietary protocol that I struggled to find any connection. On the mentioning of protocols within the "source", no attempt was made to define any of the discussion in the realms of ownership, or apart from the concept of open source software, which is in no way linked directly to non-proprietary protocols. The articles one use of the term proprietary is in relation to software only, and no more of the content is linked to ownership, and is therefore completely unrelated to this article. Finally, the actual statements made on this page do not in any way seem to relate to proprietary protocols. There is mention of development of protocols (not specifically proprietary) to "beat" Linux (a non-protocol topic), with the quote being once again an open source software comment. Since my original issue, comments have also been made about another protocol (again from Microsoft, though I make no insinuation that the editor has some personal vendetta...), once again not specifically related to the concept of ownership with some commentary on Vendor lock-in, that will likely not survive a clean up.

My main issue to to whether any of this information has anything to do with protocols technically owned by a group, or is once again the Biased interpretation of the term "proprietary software" aimed at portraying software decisions negatively on an article that has nothing to do with software! I understand that tose in software I have the view of all things from the perspective of software, but it does not make any of these comments valid in the context of the article. - Jimmi Hugh (talk) 16:54, 18 February 2009 (UTC)

Reverted and updated, although I don't agree with most of your claims. pgr94 (talk) 13:56, 23 February 2009 (UTC)

Well don't appease me! Bring in some sources that disprove my claims; I don't want my position forced, I want the correct information to be stated. This article really isn't about OSS, and the information I removed was. If I was mistaken on any count, you need to say so, so that we can improve the article. - Jimmi Hugh (talk) 14:20, 23 February 2009 (UTC)

Jimmi, incessant deletions and long protracted discussions result in editors being frightened away. If you are genuinely interested in this article why don't you contribute some content, or repair erroneous claims, or improve references? You might want to review your net contribution to this article. And please don't call foul, this isn't a personal attack but an invitation to get more involved in the article than in the talk page. pgr94 (talk) 15:20, 23 February 2009 (UTC)

Have just seen your edits. Well done. pgr94 (talk) 15:23, 23 February 2009 (UTC)

Hey, I'm not all about Microsoft love, I can't wait for the day a good Linux distribution takes the lead... - Jimmi Hugh (talk) 18:00, 23 February 2009 (UTC)

Reverting content

Oh, now it starts again and I also get involved... Jimmy, did you consider the possibility that my edit actually improved the article? By aligning the definition of proprietary to this article? By giving a broader perspective than was offered in the previous, now again current, version?

And did one of you consider that the good guys also develop proprietary protocols? That PPs are not only about exploitation, rip-off and money?

Anyway, I'll now leave that battleground of yours. I'll be back in a year or so to see whether the article is still as bad as it is today, or if one of you has won the fight by then. Have fun. --Pgallert (talk) 09:14, 19 February 2009 (UTC)

Your edit did not improve the article. You made some needless expansions of definition to try and focus the concept on computing, particularily networking as if it was some special form of telecommunication. You then formed a statement of such invalidity that the idea that you are making the insinuation that I do not believe there are "good guys" and you do it laughable. The opposite of proprietary protocols is not standardised protcols, it can't improve the article if it is simply wrong. Proprietary protocols can be standardised protocols, and non-proprietary protocols can non-standardised protocols, you can't simply pretend it is different in order to change the definition of proprietary. I consider that there are no good guys and bad guys, and more importantly that the Open Source advocated view would be incorrect on that matter in the case, at a 90 degree angle at any rate (I am pro Linux, not GNU...). It is pointless talk though, as we are not here to speculate on such things, and must stay netural, and correct, using actual sources to state facts. I also don't find your comments about argument helpful... I don't see a personal fight, only a continual discussion about the definition of the article, and if you wish to contribute, with understanding and sources, as opposed to unhelpful rhetoric, I would be grateful. - Jimmi Hugh (talk) 10:18, 19 February 2009 (UTC)

Proprietary protocols can be standardised protocols... Maybe I just don't see it and need some help: Which proprietary protocol would that be, and standardised by whom? --Pgallert (talk) 10:50, 19 February 2009 (UTC)

Standardised anything - "conforming to or constituting a standard " - Every protocol ever? Even those not officially written on some level form a basic standard, but I was refering to the huge number of documented protocol standards from Microsoft, IBM, the FSF, Skype, BT, AT&T, Blackberry, the US Government, the British Government, etc etc etc etc etc - Jimmi Hugh (talk) 12:04, 19 February 2009 (UTC)

Okay, now it is perfectly clear to me - that you haven't got a clue what you are talking about. I also just realised that I am not the first person telling you this, particularly in connection with the term "proprietary". So again, as you are unwilling to walk away, I will. --Pgallert (talk) 13:16, 19 February 2009 (UTC)

While you may walk away, unable to argue the clearly factual statement... I would like to set the record straight for those who read to this point that I know perfectly what I am talking about, and that the fact you do not understand the definition of the words proprietary and standardised has absolutely no bearing upon my points, only your own. - Jimmi Hugh (talk) 15:38, 19 February 2009 (UTC)

Deleting sourced material

As a good faith edit on 14 June 2009 I expanded the introduction with the following.

It also can mean any technical protocol that has no specification for an open standard, since a protocol alone is short of a standard.

This was only my best effort and hoped that other editors would improve it by either correcting it or adding other interpretations. The sentence was deleted since there was an objection to the provided source. The source is an accepted paper at a conference on libraries. I doubt this could be considered either "unreliable" or "not third-party", since the author is not an implementor of a proprietary protocol -- or an open standard for that matter. I'm not citing the paper's stance on library protocols, but instead only the good treatment of "protocol" and "standard" that are part of its introduction. If the paper is not seen as verifiable, then either more references should be added to support it or contradictory sources need to be made available.

Again, I don't think this is a strong source. I would be happy if it was replaced with a better one. I'm more concerned that an attitude of deleting -- in this case, sourced contributions -- is going to deter people from furthering an article's development. --Ashawley (talk) 19:36, 17 July 2009 (UTC)

Skype Protocol

The Citation Link is broken please --182.72.142.46 (talk) 10:02, 29 June 2012 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Proprietary protocol. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20090123141456/http://msdn.microsoft.com:80/en-us/library/cc307725.aspx to http://msdn.microsoft.com/en-us/library/cc307725.aspx
• Added archive https://web.archive.org/20090217130757/http://www.microsoft.com:80/protocols/default.mspx to http://www.microsoft.com/protocols/default.mspx

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 00:36, 26 January 2016 (UTC)