15 February 2006

Non-Confidential

Annex 5

Report by Roy Hirst _______________________________________________________________

My name is Roy Hirst. I am a Documentation Architect at Microsoft. I lead the team of over 25 documentation production experts that wrote the WSPP documentation. I hold a B.Sc in Mathematics and have 17 years experience in network and embedded systems programming. I worked for ten years as developer documentation specialist, hold a U.S. patent for server design, and have patents pending for technical documentation innovation.

Summary This Report shows an example of how a licensee engineer could use the WSPP documentation in conjunction with the available engineering art, including public standard protocols, in developing an implementation of work group server functionality equivalent to the relevant functionality of Windows servers.

The example shows how to use the engineering art, how to relate the art to the WSPP documentation, and how to use the WSPP documentation. It shows the discovery of all the necessary information needed to understand the use of a field within the DRSBind packet in the Microsoft DRS RPC interface. There are 13 steps in this discovery.

In summary, in this example, a licensee engineer:

1. Uses the existing engineering art to evaluate his proposed implementation, and to determine a list of the protocols his implementation requires. A protocol is either a public protocol, a public protocol with Microsoft extensions, or a Microsoft proprietary protocol. See Section 1.

2. Relates the art to the WSPP documentation by comparing his list of required protocols against the contents list of protocols licensed in WSPP. A protocol included in this contents list requires the use of the WSPP documentation and knowledge of the existing art to implement it; a protocol not in this contents list is implemented entirely from the existing art. See Section 2.

3. Uses the WSPP documentation to implement those Microsoft extensions to public protocols, or those Microsoft proprietary protocols, required for his implementation. See Section 3.

Section 4 lists the documentation used from the prior art and from the WSPP protocol documentation.

-2 -

Contents 1 USING THE ENGINEERING ART ................................................................. 2

2 RELATING THE ART TO THE WSPP DOCUMENTATION.......................... 6

3 USING THE WSPP DOCUMENTATION ....................................................... 8

4 DOCUMENTATION USED FROM THE PRIOR ART AND WSPP.............. 13

1 Using the engineering art A licensee engineer uses the existing engineering art to evaluate his proposed implementation, and to determine a list of those protocols that his implementation requires. A protocol is either a public protocol, a public protocol with Microsoft extensions, or a Microsoft proprietary protocol.

1. The licensee engineer determines the objectives for his solution. The art contains many examples describing the design and deployment of an Active Directory installation, and its relationship to the public directory service standards such as the X.500 standard. This includes the use of the public LDAP protocol for client-server use, and the DRS protocol for server-to-server interoperation. Examples include “Windows 2000 Active Directory” (Lowe-Norris) and “Active Directory Windows Server 2003” (Mulcare-Reimer):

Figure 1: From the art, examples explaining the structure of an Active Directory directory, and the client-server and server-to-server protocols required.

2. The licensee engineer scopes his solution. The envisaged solution is to have the same “interoperation” functionality (in the broad sense defined by the Commission) as Microsoft’s Active Directory implementation, including both client-server and server-to-server interoperation.

-3 -

The art contains material to assist the licensee engineer in scoping his solution, for example the whitepaper “How Active Directory Searches Work” that describes client-server interoperation using LDAP:

Figure 2: From the art, a whitepaper describing how client-server searches are implemented in Active Directory. This first page links to descriptive material concerning the LDAP standard. This is only the first page of the whitepaper; it provides much more information than is shown here.

The art contains examples of the use of DRS for server-to-server interoperation in Active Directory, for example the whitepaper “How the Active Directory Replication Model Works”:

-4 -

Figure 3: From the art, a sample whitepaper describing how server-server replication is implemented in Active Directory. Again, the whitepaper contains much more information than is shown here.

-5 -

3. The licensee engineer designs his implementation. After specifying the structure of his implementation at a sub-component level, the Licensee engineer can determine the protocols required for his implementation. This example, from the art, shows the structure of Microsoft’s Active Directory implementation at a sub-component level:

Figure 4: From the art, an example of an implementation design showing Microsoft’s Active Directory implementation. This schematic is from a published whitepaper “How Active Directory Replication Works”.

4. The licensee engineer determines the list of protocols to implement. The list of protocols to implement is read off the example of the art in Figure 4. There are eight protocols:

• DRS (identifiable as “DRS client”).

• SMTP

• DNS

• Kerberos

• RPC

• LDAP

-6 -

• TCP/IP

• UDP/IP

5. The licensee engineer determines the protocol requirements for adding a user to a domain, and then replicating the change to other instances of Active Directory. The art contains examples of the protocol requirements to implement this scenario, for example this schematic taken from the whitepaper in Figure 3.

Figure 5: From the art, diagram showing the protocols required for user update and replication.

2 Relating the art to the WSPP documentation A licensee engineer relates the art to the WSPP documentation by comparing his list of required protocols against the list of protocols licensed in WSPP. A protocol in this contents list requires the use of the WSPP documentation and knowledge of the existing art to implement it; a protocol not in this contents list is implemented entirely from the existing art.

-7 -

6. The licensee engineer examines the contents of the list of protocols included in WSPP. The list is shown in the contents pane (the left-hand pane) of the viewer. This example shows part of the contents pane for the User and Group Administration WSPP protocols, as seen in an Acrobat viewer.

Figure 6: From the WSPP documentation, a screenshot showing part of the contents list of WSPP protocols (see left-hand pane).

7. The licensee engineer compares his list of required protocols to the contents of the list of protocols licensed in WSPP. Of the eight protocols he requires: four (DNS, LDAP, TCP/IP, UDP/IP) are not contained in WSPP and are standard protocols implementable from the art; three (SMTP, Kerberos, RPC) are public protocols with WSPP extensions; one (DRS) is a Microsoft proprietary protocol.

Licensee list of protocols

In WSPP (public protocol extension)

In WSPP (proprietary protocol)

Public standard protocol

DRS DRS

SMTP SMTP

DNS DNS

Kerberos Kerberos

RPC RPC

LDAP LDAP

TCP/IP TCP/IP

UDP/IP UDP/IP

Figure 7: Result of the Licensee comparing his list of required protocols against the contents list of protocols licensed in WSPP. Four of his eight required protocols are included in WSPP.

-8 -

3 Using the WSPP documentation A licensee engineer uses the WSPP documentation to implement those Microsoft extensions to public protocols, or those Microsoft proprietary protocols, required for his implementation.

8. The licensee engineer understands that the DRS protocol is an RPC interface. The WSPP documentation states that DRS is an RPC interface on the opening page of the WSPP DRS reference documentation. The page contains a link to a WSPP topic “Microsoft RPC” that explains the implementation of an RPC interface, including the use of an RPC binding request (RPC BIND):

Figure 8: From the WSPP documentation, part of the first page of the documentation for the “Directory Replication Service Remote Protocol” indicates that DRS is an RPC interface.

9. The licensee engineer understands what is required to implement an RPC interface. The WSPP topic “Microsoft RPC” explains the implementation of an RPC interface, including the use of an RPC binding request (RPC BIND):

[___] Figure 9: From the WSPP documentation, a topic explaining the implementation of an RPC interface.

10. The licensee engineer understands the meaning of an RPC “Bind” command in an RPC interface. The WSPP reference topic “Microsoft RPC” links to a topic “RPC_BIND” and explains the use of RPC_BIND in this paragraph:

[___] Figure 10: From the WSPP documentation, a sample paragraph showing the meaning and use of RPC_BIND.

The WSPP reference topic “RPC_BIND” defines the format, value, and meaning of the packet fields used in an RPC Bind packet:

[___] Figure 11: From the WSPP documentation, the topic "RPC_BIND" defines the format, values, and meaning of the fields in a Bind packet in an RPC interface.

-9 -

The WSPP topic “RPC_BIND” contains a link to the contents page of the public standards documentation that defines in the art the use and meaning of an RPC BIND:

Figure 12: From the art, the public standard definition of RPC linked to by the WSPP topic "Microsoft RPC".

Clicking the reference to “Binding” in the example from the art shown in Figure 12 results in an explanation of the use and meaning of an RPC Bind:

-10 -

Figure 13: From the art, definition and explanation of an RPC Bind.

11. The licensee engineer understands that the DRS BIND packet is an example of the standard use of binding in an RPC interface as defined in the public standard. The first WSPP topic for DRS “drsuapi” explains this:

[___] Figure 14: From the WSPP documentation, the topic "drsuapi" defines the DRS BIND binding packet and links to it.

12. The licensee engineer understands the meaning of “context handle” as it is used in a DRS “Bind” command. The WSPP topic “IDL_DRSBind” defines the client request (parameters are conventionally annotated as “in”) and server response (parameters are annotated as “out”) for the binding operation, including the context handle that the server issues to the client:

[___] Figure 15: From the WSPP documentation, the IDL_DRSBind topic provides a technical reference for client request and server response in the RPC binding operation.

[___]

[___] Figure 16: From the WSPP documentation, [___] Types” defines [___] language data type of a context handle

-11 -

13. The licensee engineer understands the meaning of “void*” data type. The correct meaning of void* is defined in the “C” and “C++” programming languages, as indicated by searching the art for information on the meaning of the “void* data type”:

Figure 17: Search of the art for information on the meaning of the “void” data type. This example searches the Microsoft MSDN developer site.

One item returned from the search is a reference page about the void data type:

-12 -

Figure 18: From the art, an example of the definition of the “void” data type. This example is one page taken from MSDN reference material for the “C” and “C++” programming languages.

Within the page describing the “void” data type found in the art, a paragraph defines the usage of the term “void *” in defining a generic pointer. According to this example of the art, a generic pointer is one that can be assigned or compared to any type of pointer in the “C” and “C++” languages:

Figure 19: From the art, an example of the correct usage of the programming term "void *" to denote a generic pointer. This example is taken from the MSDN reference page shown in Figure 18.

-13 -

4 Documentation used from the prior art and WSPP Figure 1: From the art, examples explaining the structure of an Active Directory directory, and the client-server and server-to-server protocols required.................................................................................................................................. 2 Figure 2: From the art, a whitepaper describing how client-server searches are implemented in Active Directory. This first page links to descriptive material concerning the LDAP standard. This is only the first page of the whitepaper; it provides much more information than is shown here. ..................................................................................................... 3 Figure 3: From the art, a sample whitepaper describing how server-server replication is implemented in Active Directory. Again, the whitepaper contains much more information than is shown here. ............................................... 4 Figure 4: From the art, an example of an implementation design showing Microsoft’s Active Directory implementation. This schematic is from a published whitepaper “How Active Directory Replication Works”. ............ 5 Figure 5: From the art, diagram showing the protocols required for user update and replication. .................................. 6 Figure 6: From the WSPP documentation, a screenshot showing part of the contents list of WSPP protocols (see left-hand pane). ...................................................................................................................................................................... 7 Figure 7: Result of the Licensee comparing his list of required protocols against the contents list of protocols licensed in WSPP. Four of his eight required protocols are included in WSPP. .......................................................................... 7 Figure 8: From the WSPP documentation, part of the first page of the documentation for the “Directory Replication Service Remote Protocol” indicates that DRS is an RPC interface. ................................................................................ 8 Figure 9: From the WSPP documentation, a topic explaining the implementation of an RPC interface......................... 8 Figure 10: From the WSPP documentation, a sample paragraph showing the meaning and use of RPC_BIND............ 8 Figure 11: From the WSPP documentation, the topic "RPC_BIND" defines the format, values, and meaning of the fields in a Bind packet in an RPC interface. .................................................................................................................... 8 Figure 12: From the art, the public standard definition of RPC linked to by the WSPP topic "Microsoft RPC". ........... 9 Figure 13: From the art, definition and explanation of an RPC Bind. ........................................................................... 10 Figure 14: From the WSPP documentation, the topic "drsuapi" defines the DRS BIND binding packet and links to it........................................................................................................................................................................................ 10 Figure 15: From the WSPP documentation, the IDL_DRSBind topic provides a technical reference for client request and server response in the RPC binding operation. ....................................................................................................... 10 Figure 16: From the WSPP documentation, the topic "drsuapi Data Types” defines the "C" language data type of a context handle................................................................................................................................................................ 10 Figure 17: Search of the art for information on the meaning of the “void” data type. This example searches the Microsoft MSDN developer site.................................................................................................................................... 11 Figure 18: From the art, an example of the definition of the “void” data type. This example is one page taken from MSDN reference material for the “C” and “C++” programming languages. ................................................................ 12 Figure 19: From the art, an example of the correct usage of the programming term "void *" to denote a generic pointer. This example is taken from the MSDN reference page shown in Figure 18. ................................................... 12