Jump to content

Talk:Proprietary protocol

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by QuackCD (talk | contribs) at 01:28, 9 January 2009 (→"a protocol is not defined by the code that implements it"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputing: Networking Unassessed
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
???This article has not yet received a rating on Wikipedia's content assessment scale.
???This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (assessed as Mid-importance).

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)[reply]

No, I'm ok with it. - Jimmi Hugh (talk) 04:39, 12 December 2008 (UTC)[reply]
Ok then, deleted it is. - Jimmi Hugh (talk) 04:39, 12 December 2008 (UTC)[reply]

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)[reply]

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)[reply]

"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)[reply]
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)[reply]

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.[1] 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.[2]

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"

"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)[reply]

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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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 P1 and P2 are subsets of P does not imply that P1=P2

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

"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)[reply]

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)[reply]

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)[reply]

  1. ^ http://support.skype.com/en_US/faq/FA153/Which-protocols-does-Skype-use
  2. ^ P. Biondi and F. Desclaux (March 3 2006). "Silver Needle in the Skype" (PDF). {{cite web}}: Check date values in: |date= (help)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Proprietary_protocol&oldid=262877260"