Difference between revisions of "SLGOGP Draft 1/Discuss 1 Structure"

From Second Life Wiki
Jump to navigation Jump to search
(added link to nomenclature)
Line 7: Line 7:
* The worst aspect of this by far however is that the protocol specification becomes the exclusive domain of Linden Labs, and not of the AWG.  Since the document is not defining Second Life but is creating a generic interoperable protocol for all parties, it is inappropriate that this specification be under the sole control of Linden Labs. [[User:Morgaine Dinova|Morgaine Dinova]] 22:11, 11 March 2008 (PDT)
* The worst aspect of this by far however is that the protocol specification becomes the exclusive domain of Linden Labs, and not of the AWG.  Since the document is not defining Second Life but is creating a generic interoperable protocol for all parties, it is inappropriate that this specification be under the sole control of Linden Labs. [[User:Morgaine Dinova|Morgaine Dinova]] 22:11, 11 March 2008 (PDT)
* I think we should use the nomenclature of RFCs here as it makes quite clear what one has to implement and what is optional. Here is the sentence from the OAuth spec: The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .). Domain name examples use [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .). [[User:Tao Takashi|TaoTakashi]] 09:13, 13 March 2008 (PDT)
* I think we should use the nomenclature of RFCs here as it makes quite clear what one has to implement and what is optional. Here is the sentence from the OAuth spec: The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .). Domain name examples use [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .). [[User:Tao Takashi|TaoTakashi]] 09:13, 13 March 2008 (PDT)
* a glossary might be very helpful, e.g. what is a client, a viewer, agent domain etc. [[User:Tao Takashi|TaoTakashi]] 09:15, 13 March 2008 (PDT)

Revision as of 09:15, 13 March 2008

Welcome!

Comments on structure:

  • The inability to modify the parent document destroys most of the utility of wikis.
  • Since our contributions can now only be made in the discussions sections, they become merely advisary, and hence will be mostly ignored.
  • This is not really a community approach to evolving a document, as it divides the AWG into Lindens with power over the document and minions with none, and so it does not encourage contributions.
  • The worst aspect of this by far however is that the protocol specification becomes the exclusive domain of Linden Labs, and not of the AWG. Since the document is not defining Second Life but is creating a generic interoperable protocol for all parties, it is inappropriate that this specification be under the sole control of Linden Labs. Morgaine Dinova 22:11, 11 March 2008 (PDT)
  • I think we should use the nomenclature of RFCs here as it makes quite clear what one has to implement and what is optional. Here is the sentence from the OAuth spec: The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .). Domain name examples use [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .). TaoTakashi 09:13, 13 March 2008 (PDT)
  • a glossary might be very helpful, e.g. what is a client, a viewer, agent domain etc. TaoTakashi 09:15, 13 March 2008 (PDT)