SEMI Standard Ballot

Background Statement for SEMI Draft Document 3981A New Standard: SEMI E139.3 SOAP BINDING FOR RECIPE AND PARAMETER MANAGEMENT Note: This background statement is not part of the balloted item. It is provided solely to assist the recipient in reaching an informed decision based on the rationale of the activity that preceded the creation of this document. Note: Recipients of this document are invited to submit, with their comments, notification of any relevant patented technology or copyrighted items of which they are aware and to provide supporting documentation. In this context, “patented technology” is defined as technology for which a patent has issued or has been applied for. In the latter case, only publicly available information on the contents of the patent application is to be provided. What is the problem being solved?  This proposal adds XML / SOAP over http as one protocol binding for RaP services. The XML / SOAP approach has some advantages when compared with the traditional SECS protocol. Use of XML / SOAP handles large messages better than SECS. SSL provides a level of security not possible with SECS. The XML/SOAP approach also supports multiple clients. This improves support of off-tool recipe editors, which can connect to the tool as XML/SOAP clients. Finally, XML / SOAP allows separation of the link for recipe transfer from the command and control communications. Large recipe transfer can block time-critical control messages in today’s automation approach when the communication is on the SECS link. What is the history of this issue and ballot?  This document was balloted in Cycle 2, 2008. This new version corrects minor flaws identified during the ballot process. Who will this effect? How? Why?  This proposal adds an alternative and/or additional protocol for RaP communications. It need not affect any existing SECS implementations. Is this a change to an existing solution, or, is it a new activity?  This is a new subordinate standard for E139.

Ballot Background This proposal is based on SEMI E132. It shares this basis with the Equipment Data Acquisition (EDA) standards (see E125 and E134). SEMI E132 is currently based on SOAP 1.1. The RaP Task Force would prefer to structure these messages in SOAP with the TransferContainer as a binary attachment. Unfortunately, the mechanism to do this with SOAP 1.1 has been superseded. The new mechanism for attachments to SOAP messages (MTOM) is specified for SOAP 1.2. While we expect E132 to move to SOAP 1.2 in the near future, this solution is not available to us now. MTOM is “Message Transmission Optimization Mechanism”. This works by “optimizing” large base64 encoded binary message elements into binary MIME attachments. See the MTOM definition: http://www.w3.org/TR/soap12-mtom/. As a bridge to the preferred solution of MTOM and SOAP 1.2, this proposal specifies SOAP 1.1 (per E132) but places the TransferContainer inside the SOAP message as a “base64” encoded binary element. The transition path from SOAP 1.1 to SOAP 1.2 with MTOM retains this message structure. MTOM “optimization” can be added later with very low impact on implementations. The RaP task force feels that this path is the best option available at this time.

1 Attached to this file are four XML files. Two of these files are a part of the proposed standard and embody key requirements:  E139-3-V1108.RaP-Services.xsd  E139-3-V1108.RaP-Services.wsdl The other two included XML files are from E128 and E138 respectively and are included for the convenience of the voter. They are needed for validation of the E139.3 XML files listed above.  E128-V0706-Schema.xsd  CommonComponents-V0305-Schema.xsd (XML schema for E138)

Proposed New Specification Follows:

2 SEMI Draft Document 3981A New Standard: SEMI E139.3 XML/SOAP BINDING FOR RECIPE AND PARAMETER MANAGEMENT

1 Purpose 1.1.1 The purpose of this specification is to provide an implementation mapping of the SEMI E139 specification for Recipe and Parameter Management to XML format and the SOAP 1.1 protocol.

2 Scope 2.1 The scope of this specification is the representation of the RaP services and related parameters in an XML Schema and corresponding WSDL port types and bindings. It provides the following:  The XML Schema data types used to support the services defined in SEMI E139.  The WSDL port type and binding definitions used to support the operations defined by the interfaces specified in SEMI E139. 2.2 This specification does not add new domain information or concepts to the SEMI E139 specification. The only additions made are those needed to render useful WSDL or XML Schemas. 2.3 This specification builds upon SEMI E132 Specification for Client Authentication and Authorization. It defines requirements for the application of SEMI E132 concepts to the SEMI E139 specification. NOTICE: This standard does not purport to address safety issues, if any, associated with its use. It is the responsibility of the users of this standard to establish appropriate safety and health practices and determine the applicability of regulatory or other limitations prior to use. 3 Limitations 3.1 This specification addresses implementation of RaP services in the absence of other XML/SOAP-based communications. The intent of this specification is to be compatible with other capabilities that might share E132 services on an equipment. However, it does not attempt to identify or address potential interactions and conflicts should other similar communications interfaces exist (for example, E134 services). 4 Referenced Standards and Documents 4.1 SEMI Standards E121 — Guide for Style & Usage of XML for Semiconductor Manufacturing Applications E128-0706 — Provisional Specification for XML Message Structures E132 — Specification for Equipment Client Authentication and Authorization E134 — Specification for Data Collection Management E138 – XML Semiconductor Common Components 4.2 W3C Standards 1 Extensible Markup Language (XML) 1.0 (Second Edition) — W3C, 6 October 2000 (http://www.w3.org/TR/2000/REC-xml-20001006/). XML Schema Part 0: Primer — W3C, 2 May 2001 (http:// www.w3.org /TR/xmlschema-0/). XML Schema Part 1: Structures — W3C, 2 May 2001 (http:// www.w3.org /TR/xmlschema-1/). XML Schema Part 2: Datatypes – W3C, 2 May 2001 (http:// www.w3.org /TR/xmlschema-2/). Web Services Description Language (WSDL) 1.1 — W3C Note, (http://www.w3.org/TR/wsdl) Simple Object Access Protocol (SOAP) 1.1 — W3C Note, (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/)

1 World Wide Web Consortium, Massachusetts Institute of Technology (MIT), Computer Science and Artificial Intelligence Laboratory (CSAIL), 32 Vassar Street Room 32-G515, Cambridge, MA 02139, USA, Telephone: 617.253.2613, Fax: 617.258.5999, website: www.w3.org.

3 NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions. 5 Terminology 5.1 Acronyms and Abbreviations 5.1.1 SOAP — Simple Object Access Protocol 5.1.2 UML — Unified Modeling Language 5.1.3 W3C — World Wide Web Consortium 5.1.4 WSDL — Web Service Description Language 5.1.5 XML — eXtensible Markup Language 5.1.6 SSL — Secure Sockets Layer 5.1.7 RaP – Recipe and Parameter Management. Refers to the capabilities defined in SEMI E139. 5.2 Definitions 5.2.1 Port Type - A port type is a named set of abstract operations and the abstract messages involved. 5.2.2 WSDL Binding – A definition of how a port type definition is bound to a concrete network protocol and message format (for example, SOAP). 6 Conventions 6.1 Translating UML to XML Schema 6.1.1 The reader is expected to have a working knowledge of the XML, WSDL, SOAP, and Schema specifications (see ¶4.2). This document does not provide tutorial information on these subjects. 6.1.2 The Guide for Style and Usage of XML (SEMI E121) was consulted in the creation of the conventions for mapping UML to XML. 6.1.3 The key conventions for mapping the E139 UML to XML are summarized here:  Attributes of UML classes from SEMI E139 are represented as XML elements.  Composition associations are mapped to contained elements. 6.1.4 The translation of a UML class to XML Schema types is documented using the table format illustrated by Table 1. Operations defined for a UML class are translated into WSDL operations. These mappings link conceptual requirements to their implementation form. Therefore, they are considered extensions to those requirements. 6.1.5 Translation Table Column Header Description  Attribute or Role Name — If an attribute, the name of the attribute is placed here. If an association (including aggregation or composition), the role name from the UML diagram is placed here. Compositions are often not assigned role names. In that case “none” is placed here.  UML Name/Type — If an attribute, the data type of the UML attribute is placed here. If an association, the type of association is placed here. The possible association types are “Composition”, “Aggregation”, or the basic “Association”. UML defines these three types of association.  XML Element or Attribute — Lists the type of XML construct used to represent the UML attribute or association.  XML Name/Type — Provides the name and data type of the resulting XML construct. The type may be a built- in type (for example, xs:string), or a named type defined within the XML Schema. Table 1 Example Translation Table

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type Friend association Element Friend: HumanReferenceArray employees aggregation Element Employees: HumanArray Family composition Element Family: HumanArray Name string Element Name: xs:string

4 6.1.6 Translating Operations to XML Schema 6.1.6.1 The translation of an operation defined for UML interface classes to XML Schema types is documented using a table format illustrated in Table 2. One row is provided for each possible input/output argument for the operation being described. Table 2 Example Translation Table for Operation Input/Output Arguments

Argument Name Format XML Element or Attribute XML Name/Type abstract specification> abstract specification> an Element or Attribute>

6.1.7 Documenting XML Schema and WSDL Files 6.1.7.1 Associated with this document are XML Schema and WSDL files that are core components of the specification. Each such document is described using a table format illustrated by Table 3. Table 3 Example Schema/WSDL Document Description Table File Name <.xsd or .wsdl file name> Target Namespace Imported/Referenced Namespaces Description

6.2 Documenting XML Schema with Diagrams2 6.2.1 This document provides graphical representations of the included XML Schema data type and element definitions and their relationships. They are included to aid the reader in understanding the schema. These diagrams are illustrations of the requirements contained in the XML files and should not be interpreted as additional requirements. 6.2.2 Although no standard graphical notation for XML Schema could be found, various XML tools have their own notation. This document will use the notation provided by XMLSpy from Altova Corporation. Figure 1 shows a sample XML Schema diagram that will be used to provide a basis for explanation of the schema graphical notation used in the rest of the document. 6.2.3 In the diagram, rectangular boxes represent XML element definitions. The owner elements are on the left side while the elements contained within the owner element are on the right side. In the sample diagram, ParentType contains Child1, Child2, Child 3, and Child 4. In turn, Child2 contains Child2a, Child2b, and Child2c. The additional symbols (8-sided boxes) represent sequences or choices. See Table 4 for an explanation of these symbols.

5 Table 4 Altova XMLSPY® Schema Diagram Symbols

Denotes a required ordered sequence of the right hand elements with a cardinality of one for each element. (sequence) Denotes an optional ordered sequence of the right hand elements with a cardinality of one for each element. (sequence) Denotes a required, but unordered, sequence of the right hand elements with a cardinality of one for each element. (all)

Denotes a required choice of the right hand elements. Exactly one or two of the right hand elements must be present. (choice)

Name Denotes an element. Optional element if outline is dashed line.

Name Notation in top left corner denotes an element that contains parsed character data.

Notation in the bottom left corner denotes a reference to a group or element defined elsewhere

6.2.4 A graphic using a solid line is a required element; using a dashed line represents an optional element. Numbers or ranges in the lower right hand corner represent cardinality. The default cardinality is one. 6.2.5 To simplify a diagram or help focus on a particular aspect, detail may be hidden. The 8-sided symbols have a small square on the right end. If a minus sign “-” is in the box, then all detail is shown. If the box contains a plus sign “+”, then all detail to the right of that symbol is hidden. The example has no hidden detail. 6.2.6 The yellow (or gray if printed in monochrome) boxes indicate the use of other defined types. So, Child4 is of type “Child4Type”. Child4Type defines Child4a and Child4b. This detail may be hidden in the diagram. Object oriented inheritance is typically represented in XML as type extension. In Figure 1, ParentType extends Child1and2Type by adding a sequence that includes Child3 and Child4. 6.2.7 Reading Figure 1 would yield the following additional information: 1. Child1and2Type is an ordered sequence of two items: Child2 and Child1. 2. Child1 contains an optional ordered sequence of Child1a, one or more Child1b, and (optionally) Child1c. 3. Child2 contains a choice of one or two of the following: Child2a, Child2b, and Child2c. 4. Child3 contains an unordered sequence of Child3a and Child3b.

6 Figure 1 XML Schema Example Diagram 6.2.8 XML Schema Sample 6.2.8.1 The sample XML Schema for the example shown in Figure 1 is presented below as Figure 2. Refer to the XML documentation referenced in ¶4.2 for a complete description of the syntax and semantics of XML Schema.

Figure 2 XML for Sample 6.2.9 Translating UML to WSDL 6.2.9.1 In general, UML interface classes defined in the abstract specification are translated into WSDL as portType definitions, and each portType definition has a corresponding WSDL binding definition. The following tables show the convention used for documenting the WSDL port type and binding definitions for a given UML interface class.

8 Table 5 Example Interface WSDL Port Type Table Class Name WSDL Port Type Name SEMI E139 Operation   WSDL Operation

Table 6 Example Interface WSDL Binding Table SEMI E139 Class Name WSDL Binding Name SOAP Binding Style SOAP Transport

7 Overview 7.1 To promote better understanding of this specification, this section provides an overview of this specification before moving to the detailed requirements. This overview section does not specify any requirements. The descriptions contained may presume certain requirements that are specified in the requirements section below. 7.2 This specification builds upon SEMI E132. E132 provides a mechanism for making secure connections from client to service provider. Implementations of this specification can coexist with other standards based on SEMI E132, such as SEMI E125 Equipment Self-Description. Thus, the E132 port can be shared where appropriate. The alternative is that the implementation may choose to use separate ports. 7.2.1 This document focuses on the specification of the message definitions as translated from the original E139 form to one usable for XML/SOAP messages. 7.2.2 Where SEMI E132 refers to “equipment”, for the purpose of this specification, that should be interpreted as “service provider”. 7.2.3 Privileges are defined for the E139 services and are enforced using the SEMI E132 mechanisms. A separate privilege is defined for each RaP service (excepting requestToSend). 7.3 The XML/SOAP messaging approach is intended to co-exist with other messaging protocols, such as SECS. It is expected that this will provide a transition path. For example, in the case of an existing SECS communication link, the addition of XML/SOAP-based communication would allow an off-tool editor to connect to the tool via XML/SOAP messaging before the factory commits to a change to the SECS host application. 7.4 SEMI E139 defines message parameters for reporting errors that might occur during processing. However, additional possible errors are introduced with the new protocol. The response messages for the RaP services have been structured so that protocol errors may be handled separately. The message content is designed as an XML choice construct that can return either the E139 defined response or a separate protocol error construct. 7.5 TransferContainer handling in this specification is very simple. TransferContainers are included in the SOAP messages as base64 encoded binary message elements. 7.5.1 Implementers should note that some precaution should be taken to avoid instantiation in memory of messages containing very large TransferContainers. A RaPnode may have a practical size limit for messages received, based on the memory available to the application.

8 Requirements 8.1 Conformance to this specification requires satisfaction of all requirements as stated within this specification. 8.2 This specification builds directly upon SEMI E139. Implementations of this specification shall conform to the requirements of SEMI E139. 8.3 A RaPnode may provide RaP services via more than one defined protocol. For example, both SECS (per SEMI E139.2) and XML/SOAP (per this specification) might be provided. 8.3.1 When a RaPnode conforms to both SEMI E139.2 and E139.3, it shall be possible for RaP services to be available simultaneously in both protocols. 8.4 The format of the TransferContainer for the purpose of transfer shall be the same .ZIP form as defined in the current version of E139.2 as of the publication date of this specification, including all related requirements and restrictions from that specification.

9 8.5 SEMI E132 Foundation 8.5.1 Implementations of this specification shall conform to the requirements of SEMI E132 (Specification for Equipment Client Authentication and Authorization). 8.5.1.1 Note that SEMI E132 provides for multiple clients to access the service provider simultaneously. This is necessary for RaP because one or more recipe editors might need to connect to an equipment at the same time that the FICS makes a RaP connection. 8.5.2 RaP communication sessions shall be unidirectional. That is, RaP service requests can be initiated only by the client. 8.5.2.1 Note that a separate connection can be established in the reverse direction if both communication partners are RaPnodes (that is, if they both provide RaP services). 8.5.3 SEMI E132 provides an EnhancedEstablishSession service. This service allows the client to establish a session that provides only the capabilities it specifies. The collected RaP services shall constitute one E132 session capability. 8.5.3.1 Note that the name of this RaP services capability is specified by E132 to be of the form “SEMI-E139- MMYY”, where MMYY represent the month and year of release of the E139 standard. For example, the November 2008 release of RaP would result in a capability named “SEMI-E139-1108”. 8.6 XML Schema and WSDL Files 8.6.1 Each interface definition in SEMI E139 is mapped to a WSDL portType and a binding definition. Each WSDL portType definition is named after the interface and its operations as they appear in SEMI E139. WSDL binding definitions of each portType are used to specify the SOAP 1.1 envelope contents for each operation and to define the corresponding XML encoding styles and HTTP header usage. All SEMI E139.3 WSDL interfaces use document/literal encoding, with the complete SOAP header and body contents defined in XML Schema file(s) via global element definitions. 8.6.1.1 Implementations of this specification shall conform to the schema file defined in Table 7 below (see “File Name”). The schema shall apply to all three types of RaPnode defined by SEMI E139. Table 7 shows additional information about the namespaces defined or imported by this RaP services schema.

Table 7 XML Schema File Name E139-3.V1108.RaP.Services.xsd Target Namespace urn:semi-org:xsd.E139-3.V1108.RaP-Services Imported/Referenced http://www.w3.org/2001/XMLSchema Namespaces urn:semi-org:xsd.CommonComponents.V0305.ccs Description This file defines all of the E139 data types and elements used by the RaP interface.

8.6.1.2 Implementations of this specification shall conform to the WSDL file defined in Table 8 below (see Filename). The WSDL shall apply to all three types of RaPnode defined by SEMI E139. Table 8 shows additional information about the namespaces defined or imported by this RaP services WSDL file. 8.6.1.3 Table 8 notes that a schema file for SEMI E128 is referenced. The RaP implementation shall conform to SEMI E128-0706. The version of SEMI E132 used in conjunction with implementations of this specification shall also be one that is compatible with this version of SEMI E128.

Table 8 RaP PortType and Binding Definitions File Name E139-3.V1108.RaP.Services.wsdl Target Namespace urn:semi-org:ws.E139-3.V1108.RaP-Services http://www.w3.org/2001/XMLSchema Imported/Referenced http://schemas.xmlsoap.org/wsdl/ Namespaces http://schemas.xmlsoap.org/wsdl/soap/ urn:semi-org:xsd.E128.V0706.xms This file defines all of the input/output messages and operations for the RaP interface, Description based on the data types defined in the SEMI RaP services schema. It also binds the abstract portType definitions to HTTP and SOAP.

10 8.6.1.4 The schema and WSDL files named in Table 7 and Table 8 are a part of this specification and are intended to be distributed with this document. The contents of these files constitute the core part of this specification. 8.7 Service Mapping 8.7.1 Table 9 shows the mapping of each service defined in SEMI E139. Following this table, each message is detailed individually to show how the contents of the E139 service maps to the XML message content. These mappings define the required implementation of E139 messages, parameters, and related constructs in XML format.

Table 9 Mapping of E139 Services to WSDL Message Names E139 Service Name WSDL Input Message Name WSDL Output Message Name getPDEdirectory() GetPDEDirectoryRequest GetPDEDirectoryResponse deletePDE() DeletePDERequest DeletePDEResponse getPDEheader() GetPDEHeaderRequest GetPDEHeaderResponse getPDE() GetPDERequest GetPDEResponse requestToSendPDE() RequestToSendPDERequest RequestToSendPDEResponse sendPDE() SendPDERequest SendPDEResponse resolvePDE() ResolvePDERequest ResolvePDEResponse verifyPDE() VerifyPDERequest VerifyPDEResponse

8.7.2 Error Reporting 8.7.2.1 For reporting errors in XML/SOAP messages, the chosen format is the ccs:ErrorType defined in SEMI E138. The ErrorType is shown in Figure 3.

Figure 3 ErrorType 8.7.2.2 E139 Error Constructs Mapped to XML/SOAP 8.7.2.2.1 The response for each service defined in E139 contains one or more error constructs. Each of these simple enumerated lists of error codes is mapped to the ccs:ErrorType as shown in Table 10. The enumerations are translated in Table 11 to integer values for representation in the ErrorType “code” attribute. When an instance of ErrorType is sent, the sender shall populate the description field with text that includes the name of the corresponding enumeration value from E139 (for example, see Column 1 of Table 11).

Table 10 E139 Service Parameters Mapped To ccs:ErrorType Data Parameter(s) XML/SOAP E139 Service Mapped to ErrorType Data Element getPDEdirectory() dirRspStat DirRspStat: ccs:ErrorType deletePDE() delRspStat ResponseStatus: ccs:ErrorType getPDEheader() and getRspStat ResponseStatus: ccs:ErrorType getPDE() requestToSendPDE() rtsRspStat RtsRspStat: ccs:ErrorType sendRspStat SendRspStat: ccs:ErrorType sendPDE() verifyRspStat VerifyRspStat: ccs:ErrorType

11 Data Parameter(s) XML/SOAP E139 Service Mapped to ErrorType Data Element resolvePDE() resPDEStat ResponseStatus: ccs:ErrorType verifyPDE() verifyRspStat ResponseStatus: ccs:ErrorType

8.7.2.1 Use of Common Error Type 8.7.2.1.1 Table 11 below provides a mapping of error names to their corresponding common error codes. These supplement any common error codes defined in the SEMI E138 specification. 8.7.2.1.2 The error names correspond to error values defined in E139 (see enumerations delRspStat, dirRspStat, getRspStat, resPDEstat, rtsRspStat, sendRspStat, and verifyRspStat). 8.7.2.1.3 Some error codes are repeated in the table with different error names. This duplication is for backward compatibility. The error name that corresponds to the error value defined in E139 shall be used in every case.

Table 11 Error Code Mapping Error Name Common Error Code Error Name Common Error Code OK 9000 TransferNotAllowed 9013 Other 9001 VerificationFailed 9014 PDENotFound 9002 ChecksumFail 9015 PDELocked 9003 SyntaxError 9016 BadFilter 9004 ContentError 9017 BadAttribute 9005 NoExecutionTarget 9018 MapPDENotFound 9006 OutputParameterError 9019 ReferencedPDENotFound 9007 NoVerification 9020 InvalidInputMap 9008 NotFound 9002 ResolveDenied 9009 MissingMapPDE 9006 NoResources 9010 MissingReferencedPDE 9007 TransferContainerTooLarge 9011 TargetMismatch 9018 NoStorageSpace 9012 MissingTargetPDE 9021

8.7.2.1 Protocol Errors 8.7.2.1.1 SEMI E139 specifies errors related to consumption of the messages by applications (that is, application errors). There are other potential errors related to message transport and delivery. The nature of these errors is specific to the messaging protocol used. These protocol errors are provided for in the response message defined for each service. 8.7.2.1.2 Figure 4 shows an example of this protocol error construct in the context of the GetPDEDirectoryResponse message. Each RaP response message is constructed at the top level as a “choice” of “Result” or “Error”. The content of the “Result” for each message definition corresponds to the E139 message definition, including the application error fields. The “Error” choice shall be used for reporting all protocol specific errors. This allows protocol specific errors to be efficiently handled separately from protocol independent content.

12 Figure 4 Protocol Error Construct Example 8.7.3 getPDEdirectory() 8.7.3.1 GetPDEDirectoryRequest – Figure 5 shows the XML structure of the GetPDEDirectoryRequest message. Table 12, Table 13, and Table 14 map the E139 message definition to the required XML form.

Figure 5 GetPDEDirectoryRequest Table 12 Translation Table for GetPDEDirectoryRequest Arguments

XML Element or Argument Name Format XML Name/Type Attribute (list of) PDEFilter Structured data element PDEFilters: PDEFilterList (list of) PDEAttribute Structured data element PDEAttributes: PDEAttributeList

13 Table 13 Translation Table for (list of) PDEFilter

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type PDEFilter Structured data element Item: PDEFilterType PDEAttributeName: PDEAttributeName Enumeration element PDEAttributeNameType Operator Enumeration element Operator: OperatorType Multiple formats PDEAttributeValue: PDEAttributeValue element allowed PDEAttributeValueType Table 14 Translation Table for (list of) PDEAttribute

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type PDEAttribute Enumeration element Item: PDEAttributeType

8.7.3.2 GetPDEDirectoryResponse – Figure 6 shows the XML structure of the GetPDEDirectoryResponse message. Table 15 and Table 16 map the E139 message definition to the required XML form.

Figure 6 GetPDEDirectoryResponse Table 15 Translation Table for GetPDEDirectoryResponse Arguments

Argument Name Format XML Element or Attribute XML Name/Type (list of) PDEDirItem Structured data element PDEDirItems: PDEDirItemList dirRspStat Structured data element DirRspStat: ccs:ErrorType Table 16 Translation Table for (list of) PDEDirItem

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type PDEDirItem Structured data element Item: PDEDirItemType uid UUID element UID: UUID (list of) PDEAttributeItems: Structured data element PDEAttributeItem PDEAttributeItemList PDEAttributeItem Structured data element Item: PDEAttributeItemType PDEAttribute Enumeration element PDEAttribute: PDEAttributeType Multiple formats PDEAttributeValue: PDEAttributeValue element allowed PDEAttributeValueType

14 8.7.4 deletePDE() 8.7.4.1 DeletePDERequest – Figure 7 shows the XML structure of the DeletePDERequest message. Table 17 and Table 18 map the E139 message definition to the required XML form.

Figure 7 DeletePDERequest Table 17 Translation Table for DeletePDERequest Arguments

Argument Name Format XML Element or Attribute XML Name/Type (list of) uid Structured data element UIDs: ListOfUUID Table 18 Translation Table for (list of) uid

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type uid UUID element UID: UUID

8.7.4.2 DeletePDEResponse – Figure 8 shows the XML structure of the DeletePDEResponse message. Table 19 and Table 20 map the E139 message definition to the required XML form.

Figure 8 DeletePDEResponse Table 19 Translation Table for DeletePDEResponse Arguments

Argument Name Format XML Element or Attribute XML Name/Type delRspInfo Structured data element DelRspInfo: ResponseInfoType Table 20 Translation Table for delRspInfo

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type delRspStat Structured data element ResponseStatus: ccs:ErrorType uid UUID element UID: UUID

15 8.7.5 getPDEheader() 8.7.5.1 GetPDEHeaderRequest – Figure 9 shows the XML structure of the GetPDEHeaderRequest message. Table 21 and Table 22 map the E139 message definition to the required XML form.

Figure 9 GetPDEHeaderRequest Table 21 Translation Table for GetPDEHeaderRequest Arguments

Argument Name Format XML Element or Attribute XML Name/Type (list of) uid Structured data Element UIDs: ListOfUUID Table 22 Translation Table for (list of) uid

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type uid UUID Element UID: UUID

8.7.5.2 GetPDEHeaderResponse – Figure 10 shows the XML structure of the GetPDEHeaderResponse message. Table 23 and Table 24 map the E139 message definition to the required XML form.

Figure 10 GetPDEHeaderResponse Table 23 Translation Table for GetPDEHeaderResponse Arguments

Argument Name Format XML Element or Attribute XML Name/Type tcid UUID element TCID: UUID transferContainer Binary element TransferContainer: xs:base64Binary getRspInfo Structured data element GetRspInfo: ResponseInfoType

16 Table 24 Translation Table for getRspInfo

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type uid UUID element UID: UUID getRspStat Structured data element ResponseStatus: ccs:ErrorType

8.7.6 getPDE() 8.7.6.1 GetPDERequest – Figure 11 shows the XML structure of the GetPDERequest message. Table 25 and Table 26 map the E139 message definition to the required XML form.

Figure 11 GetPDERequest Table 25 Translation Table for GetPDERequest Arguments

Argument Name Format XML Element or Attribute XML Name/Type (list of) uid Structured data Element UIDs: ListOfUUID Table 26 Translation Table for (list of) uid

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type uid UUID Element UID: UUID

8.7.6.2 GetPDEResponse – Figure 12 shows the XML structure of the GetPDEResponse message. Table 27 and Table 28 map the E139 message definition to the required XML form.

Figure 12 GetPDEResponse

17 Table 27 Translation Table for GetPDEResponse Arguments

Argument Name Format XML Element or Attribute XML Name/Type tcid UUID element TCID: UUID transferContainer Binary element TransferContainer: xs:base64Binary getRspInfo Structured data element GetRspInfo: ResponseInfoType Table 28 Translation Table for getRspInfo

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type uid UUID element UID: UUID getRspStat Structured data element ResponseStatus: ccs:ErrorType

8.7.7 requestToSendPDE() 8.7.7.1 RequestToSendPDERequest – Figure 13 shows the XML structure of the RequestToSendPDERequest message. Table 29 maps the E139 message definition to the required XML form.

Figure 13 RequestToSendPDERequest Table 29 Translation Table for RequestToSendPDERequest Arguments

Argument Name Format XML Element or Attribute XML Name/Type tcid UUID element TCID: UUID transferSize Integer element TransferSize: xs:unsignedLong

8.7.7.2 RequestToSendPDEResponse – Figure 14 shows the XML structure of the RequestToSendPDEResponse message. Table 30 maps the E139 message definition to the required XML form.

Figure 14 RequestToSendPDEResponse Table 30 Translation Table for RequestToSendPDEResponse Arguments

Argument Name Format XML Element or Attribute XML Name/Type rtsRspStat Structured data element RtsRspStat: ccs:ErrorType

18 8.7.8 sendPDE() 8.7.8.1 SendPDERequest – Figure 15 shows the XML structure of the SendPDERequest message. Table 31 maps the E139 message definition to the required XML form.

Figure 15 SendPDERequest Table 31 Translation Table for SendPDERequest Arguments

Argument Name Format XML Element or Attribute XML Name/Type tcid UUID element TCID: UUID transferContainer Binary element TransferContainer: xs:base64Binary

8.7.8.2 SendPDEResponse – Figure 16 shows the XML structure of the SendPDEResponse message. Table 32 and Table 33 map the E139 message definition to the required XML form.

Figure 16 SendPDEResponse Table 32 Translation Table for SendPDEResponse Arguments

Argument Name Format XML Element or Attribute XML Name/Type sendRspInfo Structured data element SendRspInfo: SendResponseInfoType Table 33 Translation Table for sendRspInfo

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type uid UUID element UID: UUID sendRspStat Structured data element SendRspStat: ccs:ErrorType verifyRspStat Structured data element VerifyRspStat: ccs:ErrorType

19 8.7.9 resolvePDE() 8.7.9.1 ResolvePDERequest – Figure 17 shows the XML structure of the ResolvePDERequest message. Table 34 and Table 35 map the E139 message definition to the required XML form.

Figure 17 ResolvePDERequest Table 34 Translation Table for ResolvePDERequest Arguments

Argument Name Format XML Element or Attribute XML Name/Type targetPDE UUID element TargetPDE: UUID inputMap Structured data element InputMap: MapType Table 35 Translation Table for inputMap

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type pdeRef UUID element PDERef: UUID resolution UUID element Resolution: UUID

8.7.9.2 ResolvePDEResponse – Figure 18 shows the XML structure of the ResolvePDEResponse message. Table 36, Table 37, and Table 38 map the E139 message definition to the required XML form.

Figure 18 ResolvePDEResponse

20 Table 36 Translation Table for ResolvePDEResponse Arguments

Argument Name Format XML Element or Attribute XML Name/Type outputMap Structured data element OutputMap: MapType resPDEinfo Structured data element ResPDEInfo: ResponseInfoType Table 37 Translation Table for outputMap

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type pdeRef UUID element PDERef: UUID resolution UUID element Resolution: UUID Table 38 Translation Table for resPDEinfo

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type pdeRef UUID element UID: UUID uid UUID Element UID: UUID resPDEstat UUID element ResponseStatus: ccs:ErrorType 8.7.9.3 In Table 38 above, both pdeRef and uid are shown to map to UID. These are alternates shown for backward compatibility. One or the other will appear in any single version of E139. In either case, the XML representation is the same. 8.7.10 verifyPDE() 8.7.10.1 VerifyPDERequest – Figure 19 shows the XML structure of the VerifyPDERequest message. Table 34 and Table 35 map the E139 message definition to the required XML form.

Figure 19 VerifyPDERequest Table 39 Translation Table for VerifyPDERequest Arguments

Argument Name Format XML Element or Attribute XML Name/Type targetPDE UUID element TargetPDE: UUID inputMap Structured data element InputMap: MapType verifyType Enumeration element VerifyType: VerifyTypeType verifyDepth Enumeration element VerifyDepth: VerifyDepthType

21 Table 40 Translation Table for inputMap

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type pdeRef UUID element PDERef: UUID resolution UUID element Resolution: UUID

8.7.10.2 VerifyPDEResponse – Figure 20 shows the XML structure of the VerifyPDEResponse message. Table 41 and Table 42 map the E139 message definition to the required XML form.

Figure 20 VerifyPDEResponse Table 41 Translation Table for VerifyPDEResponse Arguments

Argument Name Format XML Element or Attribute XML Name/Type verifySuccess Boolean Element VerifySuccess: xs:boolean verifyInfo Structured data Element VerifyInfo: ResponseInfoType Table 42 Translation Table for verifyInfo

Attribute or Role Name Format/Type XML Element or Attribute XML Name/Type uid UUID Element UID: UUID verifyRspStat Structured data Element VerifyRspStat: ccs:ErrorType

8.8 Privileges 8.8.1 SEMI E132 defines the use of “privileges” that may be assigned to a client session with a service provider. Privileges define the client’s access to services and functions within an E132 capability. This specification defines privileges for use with the RaP services capability. 8.8.2 Privileges for the RaP services capability are defined based on the individual RaP services. Each RaP service, with the exception of requestToSendPDE(), corresponds to a separate privilege. The following privileges shall be provided for RaP services for use in conjunction with the E132 “Authorization” capability:  getPDEdirectory – Allows the client to request the getPDEdirectory() service from the connected RaPnode.  deletePDE – Allows the client to delete one or more PDE’s by requesting the deletePDE() service from the connected RaPnode.  getPDEheader – Allows the client to obtain the PDEheader of any available PDE on the connected RaPnode by requesting the getPDEheader() service.  getPDE – Allows the client to obtain one or more PDE’s on the connected RaPnode by requesting the getPDE() service.

22  sendPDE – Allows the client to send a PDE to the connected RaPnode by requesting the sendPDE() service. The requestToSendPDE() service is also allowed with this privilege.  resolvePDE – Allows the client to invoke the resolvePDE() service on the connected RaPnode.  verifyPDE – Allows the client to invoke the verifyPDE() service on the connected RaPnode. 8.8.3 Note that E132 allows the definition of Roles that aggregate one or more privileges. The use of Roles can make the configuration and maintenance of RaP clients easier for the user.