direct print protocol specification1394ta.org/wp-content/uploads/2015/07/1999018.pdf ·...

TA Document 1999018

Direct Print ProtocolSpecification

Version 1.1

November 11, 1999

Sponsored by:

Digital Still Image Working Group of the 1394 Trade Association

Approved for Released by:

1394 Trade Association Board of Directors

Direct Print Protocol Specification Version 1.1 November 11, 1999, 1999018

Page- i

TABLE OF CONTENTS

1. SCOPE AND PURPOSE 1

2. DEFINITIONS AND ABBREVIATIONS 2

2.1. Conformance Glossary 2

2.2. Technical Glossary 2

2.2.1. Sect ion 5 / Th in Protocol 2

2.2.2. Sect ion 7 / Direct Pr in t Command set 2

2.2.3. Sect ion 9 / F ile Transfer Command set 3

3. BIT, BYTE AND QUADLET ORDERING 4

3.1. Bit ordering within a byte 4

3.2. Byte ordering within a quadlet 4

3.3. Quadlet ordering within an octlet 4

4. DIRECT PRINT MODEL 5

4.1. Layer Model 5

4.2. Features 6

4.3. Compatibility with DPP ver 1.0 6

5. THIN PROTOCOL 8

5.1. Overview 8

5.2. Service Model 8

5.3. Thin Protocol Layers 9

5.3.1. Th in Session Layer 9

5.3.2. Th in Transact ion Layer 9

5.3.3. Th in Session Service 9


Page- ii

5.3.4. Th in Transact ion Service 10

5.4. Thin Protocol Sequence 11

5.5. Thin Protocol Segmentation 13

5.6. Register Space 14

5.6.1. Connect ion Register 15

5.6.2. SDU Management Register 16

5.6.3. SDU Register 16

5.6.4. Register Space Summary 17

5.7. Connection Information 17

5.8. Connection Sequence 18

5.8.1. Connect 18

5.8.2. Reconnect 26

5.8.3. Disconnect 29

5.9. Asynchronous Transfer 31

5.9.1. Th in Protocol Data Transfer 32

5.9.2. Applicat ion Command Transfer 39

5.9.3. Mult iple Data Transfer 41

5.9.4. Bi-direct ional Data Transfer 42

5.9.5. Abor t 43

5.10. Timeout Sequence 45

5.10.1. Connect Timeout 45

5.10.2. Reconnect Timeout 46

5.10.3. Idle Timeout 47

5.10.4. Data Transfer Timeout 48

5.11. Thin Protocol Format 51

5.11.1. Th in Session Service 51

5.11.2. Th in Session Field Format 51

5.11.3. Negot ia t ion In format ion 53

5.11.4. Format used for Connect ion 61

5.11.5. Format used for Reconnect ion 64

5.11.6. Format used for Disconnect ion 67


Page- iii

5.11.7. Format used for Data Transfer 68

5.11.8. Format used for Command Abor t 72

5.11.9. Th in Transact ion Service 74

5.11.10. Register Space 74

5.11.11. Data Specificat ion Field 76

5.11.12. Operat ion used for Connect ion 77

5.11.13. Operat ion used for Reconnect ion 78

5.11.14. Operat ion used for Disconnect ion 79

5.11.15. Operat ion used for SDU Transfer 79

6. CONFIGURATION ROM DEFINITION FOR THIN PROTOCOL 82

6.1. Configuration ROM Definition for Thin Protocol 83

6.1.1. Power reset in it ia lizat ion 83

6.1.2. Bus in format ion block 84

6.1.3. Root directory 86

6.1.4. Unit directory 87

6.2. Instance Directory 93

6.2.1. Root Directory 94

6.2.2. Instance Directory 95

6.2.3. Keyword Leaf 96

7. DIRECT PRINT COMMAND SET (DPC) 100

7.1. Overview 100

7.1.1. Command Model 100

7.1.2. Command Sequence 101

7.1.3. Negot ia t ion 102

7.2. Requirements 102

7.3. DPC with Thin Protocol 103

7.4. Command Set Categorization 103

7.4.1. Command Set Components 103

7.4.2. Command Categor izat ion 104

7.4.3. Command List 106


Page- iv

7.5. Negotiation Command 107

7.5.1. Implementa t ion Level in Negot ia t ion Command 108

7.5.2. Item/Value List ing 111

7.5.3. Negot ia t ion Command/Response Packet Format 113

7.5.4. Query Unit List Format 115

7.5.5. Negot ia t ion Command Deta ils 123

7.5.6. Negot ia t ion Item/Value Deta ils 126

7.6. Generic Command 137

7.6.1. Implementa t ion Level in Gener ic Command 138

7.6.2. Gener ic Command/Response Packet Format 139

7.6.3. Gener ic Command/Response Parameter Format 141

7.6.4. Gener ic Command Deta ils 144

7.7. Vendor Unique Command 150

7.7.1. Vendor Unique Command/Response Packet Format 150

7.8. Command Sequence 151

7.8.1. Command Sequence Overview 151

7.8.2. Negot ia t ion 152

7.8.3. Data Transfer 156

7.8.4. Others 158

8. CONFIGURATION ROM DEFINITION FOR DPC 159

8.1. Command_Set_Spec_ID entry 159

8.2. Command_Set entry 159

8.3. Command_Set_Details entry 160

9. FILE TRANSFER COMMAND SET (FTC) 162

9.1. Scope 162

9.2. Overview 162

9.2.1. Command Model 162

9.2.2. Requirements 162

9.2.3. FTC with Th in Protocol 163


Page- v

9.3. FTC Format 164

9.3.1. FTC Structure 164

9.3.2. At t r ibute Format 165

9.3.3. Directory Structure 172

9.3.4. F ile Structure 173

9.4. FTC Command Format 174

9.4.1. Genera l Ru le 174

9.4.2. QUERY 175

9.4.3. PUT 177

9.4.4. APUT 178

9.4.5. GET 181

9.4.6. AGET 182

9.4.7. DIR 185

9.4.8. DELETE 186

9.4.9. ADELETE 187

10. CONFIGURATION ROM DEFINITION FOR FTC 190

10.1. Command_Set_Spec_ID entry 190

10.2. Command_Set entry 190

10.3. Command_Set_Details entry 191

ANNEX A. DPP IMPLEMENTATION EXAMPLES 193

A.1. DPP Flow Example 193

A.2. An Example of DPC Sequential Query and Set 194

A.3. An Example of DPC Multiple Query and Set 195

A.4. DPC Packet Format Implementation 196

ANNEX B. DPC NEGOTIATION 199

B.1. Steps of DPC Negotiation in Sequential Query and Set 199


Page- vi

B.2. Steps of DPC Negotiation in Multiple Query and Set 200

ANNEX C. IMAGE DATA FORMAT DETAILS 201

C.1. Overview 201

C.2. rawRGB 202

C.3. D-rawRGB 203

C.4. Exif 204

C.5. JFIF 206

ANNEX D. SAMPLE CONFIGURATION ROM 207

D.1. Basic device Sample 207

D.2. Multi-Function device sample 210

D.3. Multi-Protocol device sample 212

D.4. Multi-Command set device (single Thin session) sample 213

D.5. Multi-Function device (w.unified driver) sample 214

ANNEX E. DPP DEVICE DISCOVERY USING CONFIGURATION ROM 217

ANNEX F. THIN PROTOCOL STATE MACHINE (INFORMATIVE) 220

F.1. Thin Session Connect State Machine 220

F.2. Thin Session Outbound Data Transfer State Machine 222

F.3. Thin Session Inbound Data Transfer State Machine 224

F.4. Thin Transaction State Machine 225

ANNEX G. DPP VER 1.0 ENHANCEMENTS IN DPP 1.1 227

ANNEX H. CLARIFICATION OF DPP 1.0 SPECIFICATIONS 228


Page- vii

H.1. Negotiation Information ( Thin Protocol ) 228

H.2. Command ID ( Thin Protocol ) 228

H.3. Parameter Contents Length ( Direct Print Command Set ) 229


Page- viii

LIST OF FIGURES

Figure 3-1 Bit ordering ........................................................................................................... 4

Figure 3-2 Byte ordering ........................................................................................................4

Figure 3-3 Quadlet ordering ................................................................................................... 4

Figure 4-1 Direct Print Model ................................................................................................ 5

Figure 5-1 Service model........................................................................................................9

Figure 5-2 Thin Protocol sequence....................................................................................... 12

Figure 5-3 Thin Protocol segmentation ................................................................................ 13

Figure 5-4 Register space for single connection................................................................... 14

Figure 5-5 Register space for multiple connections ............................................................. 15

Figure 5-6 Connect sequence................................................................................................ 19

Figure 5-7 Multiple connection sequence............................................................................. 20

Figure 5-8 Dynamic register allocation sequence - 1 ........................................................... 21

Figure 5-9 Dynamic register allocation sequence - 2 .......................................................... 22

Figure 5-10 Dynamic register allocation sequence - 3 ......................................................... 23

Figure 5-11 Page Table Access ............................................................................................ 24

Figure 5-12 Page table element ............................................................................................ 24

Figure 5-13 Reconnect sequence.......................................................................................... 28

Figure 5-14 Disconnect sequence......................................................................................... 30

Figure 5-15 Thin Protocol segmentation .............................................................................. 31

Figure 5-16 Thin Session Single data transfer...................................................................... 33

Figure 5-17 Thin Session Segment data transfer.................................................................. 35

Figure 5-18 Thin Transaction data transfer .......................................................................... 37

Figure 5-19 Thin Transaction data transfer stop................................................................... 38

Figure 5-20 Application command transfer.......................................................................... 40

Figure 5-21 Multiple data transfer........................................................................................ 41

Figure 5-22 Bi-directional data transfer ............................................................................... 42

Figure 5-23 Abort sequence ................................................................................................. 44

Figure 5-24 Connect timeout................................................................................................ 45

Figure 5-25 Reconnect timeout ............................................................................................ 46

Figure 5-26 Idle timeout....................................................................................................... 47

Figure 5-27 Data transfer timeout - 1 ................................................................................... 49



Figure 5-30 Thin Session field format.................................................................................. 51

Figure 5-31 Negotiation information format - 2................................................................... 55


Page- ix

Figure 5-32 Vendor ID ......................................................................................................... 55

Figure 5-33 Command set ID ............................................................................................... 55

Figure 5-34 Transfer mode................................................................................................... 56

Figure 5-35 Timeout.............................................................................................................56

Figure 5-36 Register space address ...................................................................................... 57

Figure 5-37 Register space size............................................................................................ 57

Figure 5-38 Page table address............................................................................................. 58

Figure 5-39 Page table size................................................................................................... 58

Figure 5-40 Page table access capability of Initiator node ................................................... 58

Figure 5-41 Page table access notification of Responder node ............................................ 59

Figure 5-42 Vendor unique command set ............................................................................ 60

Figure 5-43 Vendor unique information............................................................................... 60

Figure 5-44 Connect request format..................................................................................... 61

Figure 5-45 Connect ack format........................................................................................... 62

Figure 5-46 Connect nack format......................................................................................... 63

Figure 5-47 Reconnect request format ................................................................................. 64

Figure 5-48 Reconnect ack format ....................................................................................... 65

Figure 5-49 Reconnect nack format ..................................................................................... 66

Figure 5-50 Disconnect format............................................................................................. 67

Figure 5-51 Application data segmentation.......................................................................... 68

Figure 5-52 Single data format............................................................................................. 69

Figure 5-53 Segment data format ......................................................................................... 71

Figure 5-54 Abort format ..................................................................................................... 72

Figure 5-55 Connection register ........................................................................................... 74

Figure 5-56 SDU register ..................................................................................................... 74

Figure 5-57 SDU management register ................................................................................ 75

Figure 5-58 Data specification field ..................................................................................... 76

Figure 5-59 Connect request ................................................................................................ 77

Figure 5-60 Connect response .............................................................................................. 77

Figure 5-61 Reconnect request............................................................................................. 78

Figure 5-62 Reconnect response........................................................................................... 78

Figure 5-63 Disconnect request............................................................................................ 79

Figure 5-64 SDU transfer ..................................................................................................... 79

Figure 5-65 SDU transfer completion .................................................................................. 79

Figure 5-66 SDU transfer stop ............................................................................................. 80

Figure 5-67 SDU transfer ready ........................................................................................... 80


Page- x

Figure 5-68 SDU transfer reject ........................................................................................... 81

Figure 6-1 Configuration ROM hierarchy............................................................................ 82

Figure 6-2 Bus information block format ............................................................................. 84

Figure 6-3 Vendor_ID entry format...................................................................................... 86

Figure 6-4 Node_Capabilities entry format .......................................................................... 86

Figure 6-5 Unit_Directory entry format ............................................................................... 87

Figure 6-6 Unit_Spec_ID entry format................................................................................. 88

Figure 6-7 Unit_SW_Version entry format .......................................................................... 88

Figure 6-8 Unit_SW_Details entry format ......................................................................... 88

Figure 6-9 Command_Set_Spec_ID entry format ................................................................ 90

Figure 6-10 Command_Set entry format.............................................................................. 90

Figure 6-11 Command_Set_Details entry format................................................................. 91

Figure 6-12 Connection_Register entry format.................................................................... 91

Figure 6-13 Write_Transaction_Interval entry format ......................................................... 92

Figure 6-14 Command_Set_Directory entry format............................................................. 92

Figure 6-15 Instance_Directory entry format ....................................................................... 94

Figure 6-16 Keyword_Leaf entry format ............................................................................. 95

Figure 6-17 Unit_Directory entry format ............................................................................. 95

Figure 6-18 Keyword leaf format......................................................................................... 96

Figure 7-1 Push model Direct Print .................................................................................... 100

Figure 7-2 Push model Direct Print .................................................................................... 101

Figure 7-3 Negotiation between image source device and target device............................ 102

Figure 7-4 Command Set Components............................................................................... 103

Figure 7-5 Command and Response Packet Encapsulation Hierarchy............................... 105

Figure 7-6 Negotiation Command and Command Parameters ........................................... 107

Figure 7-7 Negotiation Command/Response Packet Format.............................................. 113

Figure 7-8 Negotiation Command Parameters – Query Unit List ...................................... 115

Figure 7-9 Negotiation Command Parameters – Query Unit List ...................................... 116

Figure 7-10 Item Unit Format of DPC Defined Items........................................................ 117

Figure 7-11 Item Unit Format of Vendor unique Items...................................................... 119

Figure 7-12 Value Content Block Format of DPC Defined Values ................................... 120

Figure 7-13 Value Content Block Format of Vendor Unique Values ................................ 122

Figure 7-14 Value Content Format of VendorUniqueItem................................................. 127

Figure 7-15 Value Content Format of ImageFormat......................................................... 128

Figure 7-16 Value Content Format of ImageSize (Fixed Size) .......................................... 129

Figure 7-17 Value Content Format of ImageSize (Fixed Numerical Size)......................... 130


Page- xi

Figure 7-18 Value Content Format of ImageSize (MaxXY Numerical Size) ...................... 130

Figure 7-19 Value Content Format of OutputOrientation.................................................. 131

Figure 7-20 Value Content Format of Sizing...................................................................... 132

Figure 7-21 Value Content Format of PosX....................................................................... 133

Figure 7-22 Value Content Format of PosY....................................................................... 134

Figure 7-23 Value Content Format of NumPics................................................................. 135

Figure 7-24 Value Content Format of NumCopies............................................................. 136

Figure 7-25 Generic Command and Command Parameters ............................................... 137

Figure 7-26 Generic Command Responses and Response Parameters............................... 137

Figure 7-27 Generic Command/Response Packet Format.................................................. 139

Figure 7-28 Generic Command/Response Parameter Format ............................................ 141

Figure 7-29 Parameter Contents Length............................................................................. 143

Figure 7-30 Response Parameter Format of GetStatus Command ..................................... 147

Figure 7-31 Command Parameter of SendStatus Command .............................................. 148

Figure 7-32 Vendor Unique Command/Response Packet Format...................................... 150

Figure 7-33 Basic Command sequence .............................................................................. 151

Figure 7-34 Omission of GetQueryItem and/or SetQueryItem Command ......................... 152

Figure 7-35 Sequential Query and Set................................................................................ 153

Figure 7-36 Multiple Query and Set................................................................................... 154

Figure 7-37 Negotiation-less .............................................................................................. 155

Figure 7-38 One picture per one output unit ...................................................................... 156

Figure 7-39 Multiple pictures per one output unit.............................................................. 157

Figure 8-1 Command_Set_Spec_ID entry format .............................................................. 159

Figure 8-2 Command_Set entry format .............................................................................. 159

Figure 8-3 Command_Set_Details entry format................................................................. 160

Figure 9-1 Command Model .............................................................................................. 162

Figure 9-2 FTC Format....................................................................................................... 164

Figure 9-3 Command Code Attribute ................................................................................. 165

Figure 9-4 Reply Attribute.................................................................................................. 166

Figure 9-5 Error Attribute................................................................................................... 167

Figure 9-6 What (Query Category) Attribute ..................................................................... 168

Figure 9-7 File Name Attribute .......................................................................................... 168

Figure 9-8 Directory Name Attribute ................................................................................. 169

Figure 9-9 Long Name Attribute ........................................................................................ 169

Figure 9-10 Time Attribute................................................................................................. 170

Figure 9-11 File Size Attribute ........................................................................................... 170


Page- xii

Figure 9-12 File Data Attribute .......................................................................................... 171

Figure 9-13 Working Directory Attribute........................................................................... 171

Figure 9-14 Directory Structure ......................................................................................... 172

Figure 9-15 File Structure................................................................................................... 173

Figure 9-16 Error Response................................................................................................ 174

Figure 9-17 QUERY Request............................................................................................. 175

Figure 9-18 QUERY Response .......................................................................................... 175

Figure 9-19 Tag Format...................................................................................................... 176

Figure 9-20 PUT Request................................................................................................... 177

Figure 9-21 PUT Response ................................................................................................ 177

Figure 9-22 APUT Request ................................................................................................ 178

Figure 9-23 APUT Response (When all files are accepted)............................................... 179

Figure 9-24 APUT Response (When some files are accepted) .......................................... 180

Figure 9-25 Sample of APUT Response ............................................................................ 180

Figure 9-26 GET Request................................................................................................... 181

Figure 9-27 GET Response ................................................................................................ 181

Figure 9-28 AGET Request................................................................................................ 182

Figure 9-29 AGET Response (When all files are accepted)............................................... 183

Figure 9-30 AGET Response (When some files are accepted) .......................................... 184

Figure 9-31 Sample of AGET Response ............................................................................ 184

Figure 9-32 DIR Request.................................................................................................... 185

Figure 9-33 DIR Response ................................................................................................. 185

Figure 9-34 DELETE Request ........................................................................................... 186

Figure 9-35 DELETE Response......................................................................................... 186

Figure 9-36 ADELETE Request......................................................................................... 187

Figure 9-37 ADELETE Response (When all files are accepted) ....................................... 188

Figure 9-38 ADELETE Response (When some files are accepted)................................... 189

Figure 9-39 Sample of ADELETE Response..................................................................... 189

Figure 10-1 Command_Set_Spec_ID entry format ............................................................ 190

Figure 10-3 Command_Set entry format............................................................................ 190

Figure 10-5 Command_Set_Details entry format............................................................... 191

Figure A-1 DPP Flow Example .......................................................................................... 193

Figure A-2 An Example of DPC Sequential Query and Set ............................................... 194

Figure A-3 An Example of DPC Multiple Query and Set .................................................. 195

Figure A-4 An Example of GetQueryItem Command ........................................................ 196

Figure A-5 An Example of GetQueryItem Response ......................................................... 196


Page- xiii

Figure A-6 An Example of SetQueryItem Command......................................................... 197

Figure A-7 An Example of SetQueryItem Response - 1 ..................................................... 197

Figure A-8 An Example of SetQueryItem Response – 2 .................................................... 197

Figure A-9 An Example of Send Command ....................................................................... 198

Figure A-10 An Example of Send Response – 1 ................................................................ 198

Figure A-11 An Example of Send Response - 2 ................................................................. 198

Figure B-1 Steps of DPC Negotiation in Sequential Query and Set................................... 199

Figure B-2 Steps of DPC Negotiation in Multiple Query and Set...................................... 200

Figure C-1 Categorization of Image Data Format .............................................................. 201

Figure C-2 Image Data Arrangement of rawRGB.............................................................. 202

Figure C-3 Image Data Arrangement of D-rawRGB.......................................................... 203

Figure C-4 Image Data Arrangement of Exif...................................................................... 205

Figure C-5 Image Data Arrangement of JFIF .................................................................... 206

Figure D-1 Configuration ROM Sample of Basic Device.................................................. 208

Figure D-2 Configuration ROM Sample of Multi-function device .................................... 210

Figure D-3 Configuration ROM Sample of Multi-Protocol device.................................... 212

Figure D-4 Configuration ROM Sample of Multi-Command Set device........................... 213

Figure D-5 Configuration ROM Sample of a Multi-function device ................................. 215

Figure E-1 Multiple Device Topology ............................................................................... 217

Figure E-2 Step1:Printer Device Discovery ....................................................................... 218

Figure E-3 Step2: DPP Printer Device Discovery.............................................................. 218

Figure E-4 Configuration ROM Information for Device Discovery .................................. 219

Figure F-1 Thin Session connect state machine ................................................................. 220

Figure F-2 Thin Session connect state machine (continued).............................................. 221

Figure F-3 Thin Session outbound data transfer state machine.......................................... 222

Figure F-4 Thin Session inbound data transfer state machine............................................ 224

Figure F-5 Thin Transaction state machine........................................................................ 225

Figure H-1 Parameter Contents Length.............................................................................. 229


Page- xiv

LIST OF TABLES

Table 5-1 Register space summary....................................................................................... 17

Table 5-2 MsgType defined value........................................................................................ 52

Table 5-3 InfType defined value .......................................................................................... 52

Table 5-4 NegInf Tag defined value..................................................................................... 54

Table 5-5 Default timeout value........................................................................................... 56

Table 5-6 The page table access rules .................................................................................. 59

Table 5-7 Result of connect rejection................................................................................... 63

Table 5-8 Result of reconnect rejection................................................................................ 66

Table 5-9 Result of disconnect ............................................................................................. 67

Table 5-10 Command type .................................................................................................... 70

Table 5-11 Segment flag........................................................................................................ 71

Table 5-12 Data type defined value....................................................................................... 76

Table 6-1 Instance directory entries ..................................................................................... 93

Table 7-1 Command categorization ................................................................................... 104

Table 7-2 Packet Format categorization............................................................................. 104

Table 7-3 Command list ..................................................................................................... 106

Table 7-4 Item and Value ................................................................................................... 108

Table 7-5 Implementation level of Negotiation Command................................................ 108

Table 7-6 Implementation level of Item ............................................................................. 109

Table 7-7 Implementation level of Value........................................................................... 110

Table 7-8 Item/Value list.................................................................................................... 111

Table 7-9 Item Code........................................................................................................... 118

Table 7-10 Implementation level in Generic Command ..................................................... 138

Table 7-11 Send Functionality............................................................................................. 156

Table 9-1 Attribute Field Name.......................................................................................... 165

Table 9-2 Command Code.................................................................................................. 166

Table 9-3 Error Code.......................................................................................................... 167

Table C-1 DPC defined image data formats........................................................................ 201

Table C-2 Viewing Environment of sRGB ......................................................................... 202

Table C-3 Additional Restrictions....................................................................................... 204

Table C-4 Exif Tag handling............................................................................................... 204

Table C-5 Additional Restrictions....................................................................................... 206


Page- xv

Revision History

Version 1.1 (November 11, 1999)

l Added multiple connections (Thin Protocol).

l Added page table access (Thin Protocol).

l Added the vendor unique command set in negotiation information (Thin Protocol).

l Added SendRequest command (DPC).

l Added File Transfer Command set.

l Added Command set directory entry (Configuration ROM).

l Added Unit_SW_Details entry (Configuration ROM).

l Fixed editorial errors.

Version 1.0 (September 15, 1998)


Page- 1

1. Scope and Purpose

Digital still image handling devices such as digital still cameras, digital camcorders, scanners and set

top boxes, are evolving rapidly. As a result, they have created new connectivity requirements for

printers to provide output for these digital still image devices.

Such digital still image handling devices usually exchange image data via a host machine such as a PC.

"Peer to Peer" connection is one of the advantages of IEEE1394 High Performance Serial Bus. This

allows printers to be connected directly with digital image input devices to order to print without host

PC machines. It is so called a Direct Print Application. The Direct Print Application should have the

ability to enable users to use printers much more easily and will create a new digital still image culture

and market.

Furthermore, a generic file transfer is also efficient. It enables image browsing, file browsing and other

applications based on files.

This specification defines Direct Print Protocol (DPP) as a common data transfer protocol to realize

the above applications. DPP defines three parts: two command sets and one data transfer protocol.

Direct Print Command set (DPC) ensures output of one sheet of print regardless of the combination of

image source devices and target devices. It also provides the capability to obtain better output

according to the combinations and features of the devices.

File Transfer Command set (FTC) ensures the transfer of one file to the peer device. It also provides

the capability to transfer files efficiently according to the combinations and features of the devices.


Page- 2

2. Definitions and Abbreviations

2.1. Conformance Glossary

l may: A keyword that indicates flexibility of choice with no implied preference.

l Reserved: A keyword used to describe that the value is set aside for future definition. A reserved

value shall be zeroed unless otherwise noted or, upon development future specification, set to a

value defined by such a specification.

l shall: A keyword that indicates a mandatory requirement. Designers are required to implement

all such mandatory requirements to ensure interoperability with other products conforming to this

standard.

l should: A keyword that indicates flexibility of choice with a strongly preferred alternative. This

term is equivalent to the phrase “is recommended”

2.2. Technical Glossary

2.2.1. Section 5 / Thin Protocol

l Application data: Data created by an Application. All data that an application issues to the Thin

Session, is Application data. In this specification, data defined in DPC and FTC are examples of

Application data.

l Application command: Application data that includes a command to be executed.

l Thin Protocol packet: A packet created by the Thin Protocol.

l SDU: Segment Data Unit

l Machine ID: The identifier of the node. This ID is specified by an Application. In this

specification, Node_Unique_Id is used as the Machine ID.

l Initiator node: The node that issues a connect request.

l Responder node: The node that responds to a connect request.

l Sender node: The node that issues Application data or a disconnect/reconnect/abort request.

l Receiver node: The node that receives Application data or a disconnect/reconnect/abort request.

l Requester node: The node that issues a command request.

l Executor node: The node that receives a command request and executes the command.

2.2.2. Section 7 / Direct Print Command set

l Image source device: A device, such as a digital still camera or scanner, that captures or has

source image(s) to be sent to the target device.

l Target device: A device, such as a printer, that outputs images from an image source device or

that has the behavior equivalent to printing.

l Command issuing device: The device sending the command to a command responding device.

l Command responding device: The device sending the response to a command issuing device in


Page- 3

reply to the received command.

l Item: A category of parameter group that is negotiable between an image source device and a

target device.

l Value: Each parameter, of Item, representing a concrete capability.

l Exif: Exchangeable image file format for Digital Still Camera (JEIDA-49-1997:Digital Still

Camera Image File Format Standard, JEIDA.)

l JFIF: JPEG File Interchange Format, see “JPEG File Interchange Format version 1.02 Eric

Hamilton C-Cube Microsystems Sep. 1, 1992.”

2.2.3. Section 9 / File Transfer Command set

l Server device: A device that provides a service based on files.

l Client device: A device that requests a file transfer operation.


Page- 4

3. Bit, Byte and Quadlet ordering

3.1. Bit ordering within a byte

Within a byte, the most significant bit (msb) is that which is transmitted first and the least significant

bit (lsb) is that which is transmitted last on the Serial Bus, as shown below.

Figure 3-1 Bit ordering

3.2. Byte ordering within a quadlet

Within a quadlet, the most significant byte is that which is transmitted first and the least significant

byte is that which is transmitted last on the Serial Bus, as shown below.

Figure 3-2 Byte ordering

3.3. Quadlet ordering within an octlet

Within an octlet, the most significant quadlet is that which is transmitted first and the least significant

quadlet is that which is transmitted last on the Serial Bus, as shown below.

Figure 3-3 Quadlet ordering

msb lsb

most significant byte least significant bytesecond

most significant bytenext to least

significant byte

most significant quadlet

least significant quadlet


Page- 5

4. Direct Print Model

4.1. Layer Model

The model described in this specification has a layered structure as shown in Figure 4-1. The

Application uses the Thin Session service for transaction layer connection, Direct Print Command set

(DPC) for printing, and the File Transfer Command set (FTC) for file transfer.

Thin Protocol and DPC are specified to ensure that an image is printed. By using this protocol and this

command set, any image source devices can print their images to any image output devices.

Thin Protocol and FTC are specified to ensure file transferring. By using this data transfer protocol

and this command set, any files are exchanged between two devices.

Figure 4-1 Direct Print Model

l Direct Print Command set: The definition of commands used by Direct Print Application.

l File Transfer Command set: The definition of commands used by File Transfer Application.

l Thin Protocol: The definition of data transfer protocol.

l Thin Session: Responsible for management of a connection and segmentation/reassembly

of Application data to optimize the resources used by the Thin Transaction.

l Thin Transaction: Responsible for transmission/receipt of data issued by the Thin Session.

Application

IEEE 1394-1995

Scope ofthis specificationThin Protocol

File TransferCommand set

Thin Session

Thin Transaction

(Isochronous) Asynchronous

Direct PrintCommand set


Page- 6

4.2. Features

Direct Print Protocol (DPP) has the following features:

1) DPP is a layered model that defines DPC for printing, FTC for file transfer, and the Thin Protocol

for data transfer.

2) DPC defines mandatory and optional functions for printing.

3) DPC supports default values for printing parameters, which enables printing without inquiry of

capability.

4) DPC includes commands to support inquiry of target capability, thus achieving print output

according to the capabilities of various printing devices.

5) FTC enables a generic file transfer with easy operation.

6) FTC defines mandatory and optional functions for file transfer.

7) FTC includes commands to support inquiry of the server device capability. This may enable an

efficient file transfer with its capability.

8) Thin Protocol has a symmetrical structure and each node can send and receive Application data.

9) Thin Protocol dynamically allocates CSR register space when establishing a connection.

10) Thin Protocol is capable of selecting negotiation parameters at the time of establishing a

connection.

11) Thin Protocol is capable of establishing multiple connections between Initiator nodes and

Responder nodes.

DPP can achieve a print and file transfer application on the IEEE 1394 layer when being used as an

entire set. In this case DPC and FTC shall be layered above the Thin Protocol. However, the

specifications of protocols, DPC, FTC and Thin Protocol, are designed to be independent of each other,

so that they can be used individually.

4.3. Compatibility with DPP ver 1.0

DPP Version 1.1 devices that are compliant with this specification shall implement at least Thin

Protocol version 1.1 and DPC version 1.1. These devices are backward compatible with DPP version

1.0 devices.

Thin Protocol version 1.1 defined in this specification is backward compatible with Thin Protocol

version 1.0. Some features included in Thin Protocol version 1.1 are not supported in Thin Protocol

version 1.0.

DPC version 1.1 defined in this specification is backward compatible with DPC version 1.0. Some

features included in DPC version 1.1 are not supported in DPC version 1.0.


Page- 7

Part – I

Thin Protocol

Version 1.1


Page- 8

5. Thin Protocol

5.1. Overview

Thin Protocol is a symmetric transfer protocol on the IEEE 1394 layer. Both the Initiator node (which

issues a connect request) and the Responder node (which receives a connect request) can send and

receive data. Thin Protocol has been designed to achieve the following abilities:

l Symmetric communications.

l Dynamic allocation of resources used for data transfer (register space, information about

connection) when establishing a connection. This enables the optimal utilization of resources in

accordance with the Application.

l Support for segmentation and reassembly of Application data for transfer.

l Use on any other network protocol.

l Multiple independent data transfer over one connection.

l Between Initiator nodes and Responder nodes, multiple connections may be established using

Thin Protocol.

5.2. Service Model

Thin Protocol is a multiple layer model. Each layer provides services to communicate between layers.

Four types of service are defined by this specification.

l Request service: Request service is a communication from the higher layer to the lower layer to

request the lower layer to perform some action. In this specification, request service is

abbreviated as ‘req’.

l Indication service: Indication service is a communication from the lower layer to the upper layer

to indicate a change of state or other event detected by the lower layer. In this specification,

indication service is abbreviated as ‘ind’.

l Response service: Response service is a communication from the higher layer to the lower layer

to respond to an indication. In this specification, response service is abbreviated as ‘rsp’.

l Confirmation service: Confirmation service is a communication from the lower layer to the

upper layer to confirm request service. In this specification, confirmation service is abbreviated

as ‘cnf’.


Page- 9

If all four service types exist, the service model that occurred within the Requester node and the

Executor node are related as shown by the following figure.

Figure 5-1 Service model

5.3. Thin Protocol Layers

Thin Protocol has two layers, Thin Session and Thin Transaction. The functions of each layer are

described below.

5.3.1. Thin Session Layer

Thin Session layer realizes these functions.

l Management of a Thin Protocol connection.

l Segmentation and reassembly of Application data to optimize the resources used by the Thin

Transaction.

5.3.2. Thin Transaction Layer

Thin Transaction layer realizes these functions.

l Transmission and receipt of data issued by the Thin Session.

l Management of the resources that are used for transfer.

5.3.3. Thin Session Service

Thin Session provides the services listed below, to the Application. Thin Session services are

described with the ‘S_’ prefix, like S_Connect.req, S_Disconnect.ind, and so on.

l Connection establishment < S_Connect (req, ind, rsp, cnf) >

l Disconnection < S_Disconnect (req, ind) >

l Execution of Application command < S_Command (req, ind, rsp, cnf) >

l Abort execution of Application command < S_Abort (req, ind) >

l Indication of CommandID for identifying Application commands < S_CommandID (ind) >

l Indications of errors < S_Error (ind) >

RequestIndication

ConfirmResponse

Requester nodeService Layer

Executor nodeService Layer


Page- 10

5.3.4. Thin Transaction Service

Thin Transaction provides the services listed below to Thin Session. Thin Transaction services are

described with ‘T_’ prefix, like T_Connect.req, T_Disconnect.ind, and so on.

l Connection establishment and allocation of resources < T_Connect (req, ind, rsp, cnf) >

l Re-establishment of a connection < T_Reconnect (req, ind, rsp, cnf) >

l Disconnection and release of resources < T_Disconnect (req, ind) >

l Transfer of data < T_SDUSend (req, ind, rsp, cnf) >

l Abort data transfer < T_SDUStop (req, ind, rsp, cnf) >

l Indication of errors < T_Error (ind) >


Page- 11

5.4. Thin Protocol Sequence

The flow of procedure using Thin Protocol is as follows. Each process will be described in section 5.5

and later in this specification.

1) Connect

This step is provided to connect two nodes and allocate resources. What is meant here by “resources”

is the register space for transmission/receipt of data and information about the connection.

Information for the allocation of resources is determined by negotiation parameters at the time of

establishing a connection.

Sequence of connection

i) The node that starts a connection issues a connect request.

ii) The node that receives a connect request issues a connect response.

2) Command

While a connection is established, one node may request the other node to execute a command and

may transmit data.

Sequence of Command issue

i) The node that wants to send a command issues a command request.

ii) The node that has received a command request executes the command and issues a command

response.

3) Disconnect

This step is provided to terminate a connection. At this process, the resources allocated at the time of

establishing a connection are released.

Sequence of Disconnect

i) The node that terminates a connection issues a disconnect request.

The procedure described above can be illustrated as a diagram of sequence shown in Figure 5-2. The

node that starts a connection, the node that issues a command and the node that terminates a

connection may be either of the two nodes, though described as the same node in the diagram.


Page- 12

Figure 5-2 Thin Protocol sequence

ThinProtocol

ThinProtocol

ConnectIndication

ConnectResponse

ConnectRequest

CommandIndication

CommandResponse

CommandRequest

CommandConfirm

DisconnectIndication

DisconnectRequest

Connect

Command

Disconnect

Connect

ResourceAll

ResourceAllocation

ResourceAllocation

Connect

Execute

ResourceRelease

ResourceRelease

Disconnect

ConnectConfirm


Page- 13

5.5. Thin Protocol Segmentation

Thin Protocol has the capability of segmentation and reassembly for both Thin Transaction and Thin

Session. Each type of segmentation is used for the following objectives.

Thin Session segmentation: Segments Application data into multiple pieces of Segment data in

accordance with the size of the SDU register that is allocated at the time of establishing a

connection (described in later sections.)

Thin Transaction segmentation: Segments the data requested by the Thin Session (SDU:

Segment Data Unit) so as to have the maximum transfer data size of the IEEE1394 write

transaction.

Figure 5-3 Thin Protocol segmentation

Application

data

(e.g. image data)

Segment data

1394 Transaction

…..

1394 Transaction

Segment data

…..

1394Write Transaction

Thin SessionSegmentation

Thin TransactionSegmentation


Page- 14

5.6. Register Space

Thin Protocol uses the following three types of registers. Thin Protocol compliant devices shall

implement these registers.

l Connection register

l SDU management register

l SDU register

The Connection register is common across multiple connections whereas one SDU Management

register and one SDU register are allocated as a set per connection. See section 5.8.1.2 for the

procedure of allocating register spaces.

Figure 5-4 shows the register space for a single connection. Figure 5-5 shows the register space for a

multiple connection.

Figure 5-4 Register space for single connection

SDU register

Connection register

SDUmanagement

register SDU response space

SDU control space


Page- 15

Figure 5-5 Register space for multiple connections

5.6.1. Connection Register

The Connection register shall be used when establishing a connection. This register space size is fixed

(512 bytes). The base address of this register space can be determined by referring to Configuration

ROM (see section 6.1.4.7)

Thin Protocol packets using the Connection register

Connect Req: a connect request

Connect Rsp: a connect response

Reconnect Req: a reconnect request

Reconnect Rsp: a reconnect response

Disconnect Req: a disconnect request

In the following sequence diagrams, these Thin Protocol packet transfers, using the Connection

register, will be marked with a double-line ( ).

SDU register 1

Connection register

SDUmanagement

register 1 SDU response space 1

SDU control space 1

SDU register 2

SDU response space 2

SDU control space 2

Connection 1

Connection 2

SDUmanagement

register 2


Page- 16

5.6.2. SDU Management Register

The SDU management register shall be used for controlling the transfer of an SDU (Segment Data

Unit: a segment of Application data with a Thin Session header). The SDU management register has

two parts, SDU control space and SDU response space. SDU control space is used for storing the

completion notification of an SDU transfer and abort of an SDU transfer. SDU response space is used

for storing the response of an SDU transfer and the rejection of an SDU transfer.

This register space size is fixed (4 bytes for each register space, so the SDU management register size

is 8 bytes). The base address of this register space is dynamically determined by the procedure

described in section 5.8.1.2.

Thin Protocol packets using the SDU management register

SDU control space

SDU Comp: completion of SDU transfer.

SDU Stop: abort an SDU transfer.

SDU response space

SDU Ready: response of ready to write to the SDU register.

SDU Reject: rejection of SDU transfer.

In the following sequence diagrams, the Thin Protocol packet transfer using the SDU management

register will be marked with a dotted line ( ).

5.6.3. SDU Register

The SDU register shall be used for transferring an SDU. The size and base address of this register

space is dynamically allocated by the procedure described in section 5.8.1.2.

Thin Protocol packet using the SDU register

SDU Send: SDU Transfer

In the following sequence diagrams, the Thin Protocol packet transfer using the SDU register will be

marked with a bold line ( ).


Page- 17

5.6.4. Register Space Summary

Table 5-1 Register space summary

Register Thin Protocol packet arrow

Connection register Connect Req / Rsp

Reconnect Req / Rsp

Disconnect Req

SDU management register SDU Ready, SDU Reject (SDU response space)

SDU Comp, SDU Stop (SDU control space)

SDU register SDU Send

5.7. Connection Information

The Thin Protocol shall retain information about a connection, such as node_ID, Machine ID, Session

ID, Thin Protocol Version, Vendor ID, Command set ID, Transfer Mode, etc., while the connection is

established. Node_ID can be determined by analyzing the 1394 transaction header. Machine ID is

provided by the Application, and serves as the ID of the node. In this specification, Node_Unique_Id

is used as the Machine ID. Machine ID can be determined by analyzing the Thin Protocol packet. A

session ID unique for a connection and Thin Protocol Version are determined during the connection

sequence. Other information is exchanged as negotiation information in the connect sequence

(described in 5.11.3). If a bus reset occurs, connection information is updated in a reconnect sequence.

After that, communication will be resumed using the new node_ID (described in 5.8.2).


Page- 18

5.8. Connection Sequence

This section describes the sequence of the Thin Protocol connection, which consists of establishing,

resuming and terminating a connection between nodes.

5.8.1. Connect

The Thin Protocol shall use this sequence to establish a connection. In a connect sequence, each node

shall allocate necessary resources according to the negotiation information (described in section

5.11.3) contained in a connect request packet and a connect response packet. What is meant by

resources for the Thin Protocol is a register space allocation used as the SDU management register and

the SDU register (described in sections 5.6.2 and 5.6.3), buffer space, and information about the

connection (described in section 5.7). The algorithm of allocating register space is described in

section 5.8.1.2 and later in this specification.

The connect sequence shall use the following steps.

1) The Application of the node, that wants to make a connection, (Initiator node) issues a connect

request (S_Connect.req).

2) The Thin Session of the Initiator node issues a connect request (T_Connect.req) to the Thin

Transaction.

3) The Thin Transaction of the Initiator node transfers a connect request packet (Connect Req) that

includes negotiation information.1

4) The Thin Transaction of the node, that has received a connect request packet, (Responder node)

issues a connect indication (T_Connect.ind) to the Thin Session.

5) The Thin Session of the Responder node issues a connect indication (S_Connect.ind) to the

Application.

6) The Application of the Responder node checks whether communication is permitted or not and

issues a connect response (S_Connect.rsp) to the Thin Session.

7) The Thin Session of the Responder node issues a connect response (T_Connect.rsp) to the Thin

Transaction.

8) The Thin Transaction of the Responder node transfers a connect response packet (Connect Rsp)

after allocating necessary resources.2

1 A connect request packet and a connect response packet should be written to the connection register

using one write transaction. Therefore, the devices supporting the Thin Protocol shall receive a block

write transaction.2 If the connection is rejected by the higher layer, then Thin Transaction shall not allocate resources.


Page- 19

9) The Thin Transaction of the Initiator node, at the time of receiving the connect response packet,

issues a connect confirmation (T_Connect.cnf) to the Thin Session after allocating necessary

resources.3

10) The Thin Session issues a connect confirmation (S_Connect.cnf) to the Application4.

Figure 5-6 Connect sequence

3 If a connect response is nack, the Thin Transaction of the Initiator node shall not allocate resources

and shall issue a connect confirmation of connect reject to the Thin Session.4 When the Thin Session does not receive a connect confirmation from the Thin Transaction within a

connect timeout period (5 seconds), it shall issue an error indication to Application instead of a

connect confirmation (this sequence is detailed in section 5.10.1.)

3) Connect Req

8) Connect Rsp

5) S_Connect.ind

6) S_Connect.rsp7) T_Connect.rsp

9) T_Connect.cnf

1) S_Connect.req

4) T_Connect.ind2) T_Connect.req

10) S_Connect.cnf

Connect

8) ResourceAllocation

9) ResourceAllocation

Connect

ThinTransaction

ThinSession

Initiator node

ThinSession

ThinTransaction

Responder node


Page- 20

5.8.1.1. Multiple Connections

To establish multiple connections between 2 nodes, one connect request shall be issued per connection

in sequential order. Connect requests may be issued by different nodes. While a connection is being

established in a node ( in Figure 5-7 ), this node shall not issue connect requests and shall reject

connect indications.

A session identifier (described in section 5.11.2) assigned by the Initiator node upon issuing the

connect request is used to distinguish multiple connections. This session identifier shall be maintained

across the duration of the connection. Register space allocation is done per connection, as described in

section 5.8.1.2 and later in this specification.

Figure 5-7 describes a multiple connection sequence. In Figure 5-7, Connect1 and Connect2 follow

the same connect sequence described in section 5.8.1.

Figure 5-7 Multiple connection sequence

ThinProtocol

ThinProtocol

Connect indication

Connect response

Connect request

Connect 1Session identifier: m

Connect

Connect confirm

Connect

Connect indication

Connect response

Connect request

Connect 2Session identifier: n

Connect

Connect confirm

Connect


Page- 21

5.8.1.2. Dynamic Register Allocation Algorithm

This section describes the procedure for allocating a register space. In the description below, the node

which issues a connect request is referred to as the “Initiator node” and the node which issues a

connect response is referred to as the “Responder node”.

5.8.1.2.1. Standard Register Allocation Sequence

The following steps describe the dynamic register allocation sequence.

1) The Initiator node sends a connect request:

i) Transfers a connect request packet (Connect Req) including the negotiation information of the

following parameters:

l SDU management register address of Initiator node (Addr A).

l SDU register address of Initiator node (Addr B).

l SDU register size of Initiator node (Size B1). This size is determined by the maximum

contiguous address space that the Initiator node can allocate for segment data receiving,

and shall be at least 512 bytes.

l SDU register size of Responder node (Size D1). This size is determined by the maximum

segment data size that the Initiator node wishes to send, and shall be at least 512 bytes.

Figure 5-8 Dynamic register allocation sequence - 1

SDU management register

SDU register

Connection register

Responder nodeInitiator node

Size B1

Size D1

Connect Req (Addr A, Addr B, Size B1, Size D1)

Addr A

Addr BSDU management register

SDU register

Connection register


Page- 22

2) Responder node sends a connect response:

i) Allocates the SDU register and SDU management register. If the Responder node can allocate the

size requested in the connect request packet (Size D1), then the Responder node shall allocate

the SDU register with the requested size. If not, then the Responder node shall allocate the SDU

register with the maximum size that the Responder node can allocate (shall be at least 512

bytes).

ii) Determines the SDU register size of the Initiator node. The size of the SDU register shall be

equal to the size requested in a connect request packet (Size B1) or the maximum segment data

size that the Responder node wishes to send, whichever is smaller. (shall be at least 512 bytes).

iii) Determines the maximum segment data transfer size of the Responder node from the size

determined in step ii).

iv) Transfers a connect response packet (Connect Rsp) including the negotiation information of the

following parameters:

l SDU management register address of Responder node (Addr C).

l SDU register address of Responder node (Addr D).

l SDU register size of Responder node (Size D2). This size is the register size allocated in

step i).

l SDU register size of Initiator node (Size B2). This size is the register size determined in

step ii).


SDU register


SDU register

Connection register


(SizeB1)

(Size D1)

Connect Rsp (Addr C, Addr D, Size D2, Size B2)

Size B2

Size D2

Addr C


SDU register

Connection register

Addr D


Page- 23

3) Initiator node receives a connect response:

i) Allocates the SDU register and SDU management register. The size of the SDU register shall be

equal to the size contained in a connect response packet (Size B2).

ii) Determines the maximum segment data transfer size of the Responder node from the register size

contained in a connect response packet (Size D2).


As a result of this sequence, these registers shall be allocated at the following CSR space.

Initiator node SDU management register -

base address: Addr A, size: 8 bytes (fixed)

Initiator node SDU register -

base address: Addr B, size: Size B2

Responder node SDU management register -

base address: Addr C, size: 8 bytes (fixed)

Responder node SDU register -

base address: Addr D, size: Size D2


(Size B1)

(Size D1)

Size B2

Size D2


SDU register

Connection register


SDU register

Connection register

Addr C

Addr DAddr B

Addr A


Page- 24

5.8.1.2.2. Page Table Access

A page table is used for describing a single data buffer separated into multiple segments.

A page table may be used for a Thin transaction data transfer. When a page table is used, the SDU

register space is accessed indirectly through a page table as shown in Figure 5-11.

Figure 5-11 Page Table Access

The page table consists of a value length array of page table elements. Each page table element

describes a page table segment. Each page table segment shall be contiguous in address space.

In each element of the page table, the base address and length of the page table segment are described.

Figure 5-12 shows page table elements.

Segment_length shall specify the length in bytes of the page table segment area. Segment_base_hi and

Segment_base_lo shall specify the base address of the page table segment area.

When using a page table, the size of the SDU register is the sum of the values in the Segment_length

fields appearing in the page table. In this case, the negotiated SDU register size shall be ignored.

Figure 5-12 Page table element

A page table shall be in the same node as the SDU register that the page table points to. The node that

is ready to transfer data shall read the page table before any SDU transfer when the node uses the page

table. The page table shall be consistent during the connection.

Segment_length Segment_base_hi

Segment_base_lo

Data intended to

be sent to a single

data buffer

page table segment #1



page table segment #n

…..


Page- 25

The usage of page table access on the Initiator node’s SDU is shown below.

1-1) The Initiator node shall add the negotiation information for page table address and page table

size to request page table access on the Initiator node’s SDU.

1-2) If the Responder node accepts the Initiator node’s request, the Responder node shall set the

negotiation information for page table access notification. If the Responder node does not

accept the Initiator node’s request, the Responder node shall not set the negotiation

information for page table access notification.

The usage of page table access on the Responder node’s SDU is shown below.

2-1) The Initiator node shall set the negotiation information for page table capability to request page

table access on the Responder node’s SDU.

2-2) If the Responder node accepts the Initiator node’s request, the Responder node shall add

negotiation information for page table address and page table size. If the Responder node does

not accept the Initiator node’s request, the Responder node shall not add negotiation

information for page table address and page table size.

The page table access may be used simultaneously for SDU access on both nodes. In this case, 1-1 and

2-1, 1-2 and 2-2 shall be done simultaneously.


Page- 26

5.8.2. Reconnect

5.8.2.1. Reconnect sequence

When a 1394 connection is broken, by a bus reset or unexpected error, the Thin Protocol may attempt

to resume a connection by using this sequence. In a reconnect sequence, the Machine ID

(Node_Unique_Id) of a disconnected node shall be sent to another node to re-establish the connection.

When the 1394 connection is broken, a reconnect timer shall be started5. The node that wants to

reconnect shall issue a reconnect request immediately. Unless a reconnection is performed within a

reconnect timeout period (5 seconds) after notification of the error, the connection shall be discarded

and resources shall be released.

The node that has received a reconnect request shall return a reconnect ack if it retains the condition

that existed just before the bus reset. If it has already discarded the condition, then the node shall return

a reconnect nack.

After completing a reconnect sequence, the Thin Session resumes the data transfer. If the Thin Session

is sending a segment of data, then the transfer shall be started from the top of the SDU that had its

transfer interrupted during the reconnect sequence.

The reconnect sequence shall use the following steps. The SDU transfer procedure, shown in the

sequence diagram (Figure 5-13), is described in section 5.9 and later.

1) When a bus reset occurs, the Thin Transaction of each node indicates an error (T_Error.ind) to the

Thin Session.

2) After receiving indication of the error, the node that wants to reconnect (Sender node) seeks the

new node_ID of the previously connected node. Then the Thin Session of the Sender node issues

a reconnect request (T_Reconnect.req) to the Thin Transaction within the reconnect timeout

period.6

3) The Thin Transaction of the Sender node transfers a reconnect request packet (Reconnect Req).7

5 A reconnect timer shall be restarted if a second bus reset occurs before a reconnection is established.6 If the previously connected node does not exist in the bus, the Thin Session of the Sender node shall

discard all resources of the connection and issue an error indication of reconnect reject to Application.7 A reconnect request packet and a reconnect response packet should be written to the connection

register using one write transaction.


Page- 27

4) The Thin Transaction of the node, that has received a reconnect request packet, (Receiver node)

issues a reconnect indication (T_Reconnect.ind) to the Thin Session. 8

5) The Thin Session of the Receiver node determines if the reconnection is permitted or not (i.e.

whether the previous resources are available or not). If the reconnection is permitted, the node

issues a reconnect response (T_Reconnect.rsp) containing a reconnect ack to the Thin

Transaction. If not, it issues a reconnect response containing a reconnect nack.

6) The Thin Transaction of the Receiver node transfers a reconnect response packet (Reconnect

Rsp).

7) The Thin Transaction of the Sender node receives a reconnect response packet. If the

reconnection is permitted, it issues a reconnect confirmation (T_Reconnect.cnf) to the Thin

Session9.

8) The Thin Session of the Sender node resumes data transfer from the top of the SDU that had its

transfer interrupted during the reconnect sequence10.

8 If a reconnect request packet is received after issuing a reconnect request packet, or a reconnect

response packet, the Thin Transaction shall return a reconnect ack. If a reconnect request packet is

received after releasing resources, then the Thin Transaction shall return a reconnect nack.9 If a reconnect response is nack, then the Thin Transaction of the Sender node shall release the

resources and issue a reconnect confirmation of reconnect reject to the Thin Session.10 When the Thin Session does not receive a reconnect confirmation from the Thin Transaction, within

a reconnect timeout period (5 seconds), it shall issue an error indication to the Application. (this

sequence is detailed in section 5.10.2.)


Page- 28

Figure 5-13 Reconnect sequence

SDU Transfer

SDU Send(Segment data#2)

S_Command.req

S_CommandID.ind

T_SDUSend.req(Segment data#1) T_SDUSend.ind

(Segment data#1)

2)T_Reconnect.req4)T_Reconnect.ind

7)T_Reconnect.cnf5)T_Reconnect.rsp

3) Reconnect Req

6) Reconnect Rsp

1) T_Error.ind 1) Bus Reset 1) T_Error.ind

SDU Transfer

T_SDUSend.req(Segment data#2)

T_SDUSend.req(Segment data#2) T_SDUSend.ind

(Segment data#2)

Reconnect Sequence

T_SDUSend.rspT_SDUSend.cnf SDU Ready

ThinTransaction

ThinSession

Sender node

ThinSession

ThinTransaction

Receiver node


Page- 29

5.8.3. Disconnect

The Thin Protocol uses this sequence to terminate a connection. In a disconnect sequence, the

resources allocated at the time of establishing a connection shall be released.

The disconnect sequence shall use the following steps.

Note that this sequence shall not expect a response from the Receiver node.

1) The Application of the node that performs the disconnect (Sender node) issues a disconnect

request (S_Disconnect.req).

2) The Thin Session of the Sender node issues a disconnect request (T_Disconnect.req) to the Thin

Transaction.11

3) The Thin Transaction of the Sender node releases resources. At this time, any write transaction to

the SDU register shall be ignored.12 The Thin Transaction of Sender node, then transfers a

disconnect request packet (Disconnect Req). 13

4) The Thin Transaction of the node that has received a disconnect request packet (Receiver node)

releases resources and then issues a disconnect indication (T_Disconnect.ind) to the Thin

Session.14

5) The Thin Session of the Receiver node issues a disconnect indication (S_Disconnect.ind) to the

Application.

11 If the SDU transfer is not completed, then the Thin Session shall stop the transfer by using the abort

sequence (see section 5.9.5) before issuing a disconnect request.12 If the Thin Transaction uses an interruption for receiving a write transaction, then the interruption

shall be ignored.13 A disconnect request packet should be written to the connection register by using one write

transaction.14 If the connection requested to disconnect is not established yet or already terminated, then the

disconnect request shall be ignored.


Page- 30

Figure 5-14 Disconnect sequence

3)Disconnect Req

5)S_Disconnect.ind

1)S_Disconnect.req

4)T_Disconnect.ind

2)T_Disconnect.req

Disconnect

ResourceRelease

ResourceRelease

ThinTransaction

ThinSession

Sender node

ThinSession

ThinTransaction

Receiver node


Page- 31

5.9. Asynchronous Transfer

The Thin Protocol has the capability of segmentation and reassembly for both the Thin Transaction

and Thin Session. Each type of segmentation shall be used for the objectives below.

Thin Session segmentation: Segments Application data into multiple pieces of Segment data in

accordance with the size of the SDU register.

The Thin Session determines if Application data segmentation is needed or not. When

the Application data size is small enough to be transferred all at once using the SDU

register, the Thin Session shall use a single data transfer sequence (described in section

5.9.1.1). When the Application data size is larger than the size of the SDU register, the

Thin Session shall use the segment data transfer sequence (described in section 5.9.1.2).

Thin Transaction segmentation: Segments the data requested by the Thin Session (SDU;

Segment Data Unit), taking advantage of the maximum transfer data size of the

IEEE1394 write transaction. The data transfer sequence of the Thin Transaction is

described in sections 5.9.1.3 and later.

Figure 5-15 Thin Protocol segmentation

Application

data

(e.g. image data)

Segment data

1394 Transaction

…..

1394 Transaction

Segment data

…..

1394Write Transaction

Thin SessionSegmentation

Thin TransactionSegmentation


Page- 32

5.9.1. Thin Protocol Data Transfer

5.9.1.1. Thin Session Single Data Transfer Sequence

If the Application data size is small enough to be transferred all at once using the SDU register, the

Thin Session shall issue an SDU transfer request (T_SDUSend.req) only once to the Thin Transaction.

The SDU transfer procedure of the Thin Transaction is detailed in section 5.9.1.3. In the sequence

diagram (Figure 5-16), the SDU transfer is marked with a bold arrow ( ).

The single data transfer sequence shall use the following steps.

1) The Application of the node that transfers data (Sender node) issues a Thin Session service with

Application data.

2) The Thin Session of the Sender node issues an SDU transfer request (T_SDUSend.req) to the

Thin Transaction.

3) The Thin Transaction of the Sender node transfers an SDU (see section 5.9.1.3.).

4) The Thin Transaction of the node that has received an SDU (Receiver node) issues an SDU

transfer indication (T_SDUSend.ind) to the Thin Session.

5) The Thin Session of the Receiver node issues a Thin Session service with the received

Application data if the SDU is accepted.

6) The Thin Session of the Receiver node issues an SDU transfer response (T_SDUSend.rsp)

describing an SDU ready state, when it becomes possible to write to the SDU register. If the Thin

Session cannot accept the SDU, the Thin Session issues an SDU transfer response describing an

SDU reject.

7) The Thin Transaction of the Receiver node transfers an SDU transfer ready packet (SDU Ready),

if the response from the Thin Session describes an SDU ready state. If not, then it transfers an

SDU transfer reject packet (SDU Reject).

8) The Thin Transaction of the Sender node issues an SDU transfer confirmation (T_SDUSend.cnf)

to the Thin Session. The Thin Session of the Sender node may then send another SDU if

necessary. 15

15 If this confirmation is SDU reject, the Thin Session may retry to send the same data. If the Thin

Session does not retry, it shall issue an error indication to the Application. When an error is indicated,

the Application shall issue an abort request (see section 5.9.5).


Page- 33

Figure 5-16 Thin Session Single data transfer

3) SDU Transfer

1) Application data

5) Application data

2) T_SDUSend.req

4) T_SDUSend.ind

6) T_SDUSend.rsp8) T_SDUSend.cnf 7) SDU Ready

ThinTransaction

ThinSession

Sender node

ThinSession

ThinTransaction

Receiver node


Page- 34

5.9.1.2. Thin Session Segment Data Transfer Sequence

If the Application data cannot be transferred all at once using the SDU register, the Thin Session shall

segment the Application data into segments that are equal to or less than the size of the SDU register.

In the case that Application data is segmented, the Thin Session shall issue an SDU transfer request

(T_SDUSend.req) to the Thin Transaction for each data segment.

The data transfer procedure of the Thin Transaction is detailed in section 5.9.1.3. In the sequence

diagram (Figure 5-17), the SDU Transfer is marked with a bold arrow ( ).

The segment data transfer sequence shall use the following steps.

1) The Application of the node that transfers data (Sender node) issues a Thin Session service with

Application data.

2) The Thin Session of the Sender node segments the Application data into multiple pieces of

Segment data, each having a transferable data size by using the SDU register.


Thin Transaction for each piece of Segment data.

4) The Thin Transaction of the Sender node transfers an SDU (see section 5.9.1.3.).

5) The Thin Transaction of the node that has received an SDU (Receiver node) issues an SDU





SDU reject.

7) The Thin Transaction of the Receiver node transfers an SDU transfer ready packet (SDU Ready)

if the response from the Thin Session is describing an SDU ready state. If not, it transfers an SDU

transfer reject packet (SDU Reject).


to the Thin Session.

9) When the confirmation from the Thin Transaction is describing an SDU ready state, the Thin

Session of the Sender node sends the next SDU up to the last SDU packet of Application data in

order by using the same sequence of steps 3 to 8.16

16 If this confirmation is an SDU reject, the Thin Session may retry to send the same SDU. If the Thin

Session does not retry, it shall issue an error indication to the Application. When an error is indicated,

the Application shall issue an abort request (see section 5.9.5).


Page- 35

10) The Thin Session of the Receiver node reassembles the Application data and issues indications of

received Application data, when all the pieces of SDU have been received and all SDU transfers

are accepted17.

Figure 5-17 Thin Session Segment data transfer

17 Each SDU contains a field of information about its location in the segmented data (first/interim/last).

This allows the Thin Session of the Receiver node to recognize whether all the SDU packets have

arrived or not. Details of the Thin Session format is described in section 5.11.7.

1) Application data

10) Application data

4) SDU Transfer

2)(segmentation)3) T_SDUSend.req(Segment data #1) 5) T_SDUSend.ind

(Segment data #1)


4) SDU Transfer

3) T_SDUSend.req(Segment data #2) 5) T_SDUSend.ind

(Segment data #2)


4) SDU Transfer

3) T_SDUSend.req(Segment data #n) 5) T_SDUSend.ind

(Segment data #n)


ThinTransaction

ThinSession

Sender node

ThinSession

ThinTransaction

Receiver node


Page- 36

5.9.1.3. Thin Transaction Data Transfer Sequence

The Thin Transaction shall segment the data requested by the Thin Session into multiple pieces of data,

taking advantage of the maximum transfer data size of the IEEE 1394 Transaction (max_rec).

The data transfer sequence of the Thin Transaction shall use the following steps.

1) The Thin Session of the node that transfers data (Sender node) issues an SDU transfer request

(T_SDUSend.req).

2) The Thin Transaction of the Sender node segments the data into an SDU, using the maximum

data transfer size of a write transaction (according to the max_rec field of Configuration ROM

described in section 6.1.2)18, and issues multiple write transactions.19

3) When the transfer of the SDU has been completed, the Thin transaction of the Sender node

transfers an SDU transfer completion packet (SDU Comp).

4) The Thin Transaction of the node that has received the data (Receiver node) issues an SDU





SDU reject.

6) The Thin Transaction of the Receiver node transfers an SDU transfer ready packet (SDU Ready)

if the response from the Thin Session is describing an SDU ready state. If not, it transfers an SDU

transfer reject packet (SDU Reject).


to the Thin Session. The Thin Session of the Sender node may then send another SDU if

necessary. 20

18 Write transaction sizes smaller than max_rec should be allowed, but not preferred.19 There are two methods for multiple write transactions to a SDU space, specified in configuration

ROM. (see section 6.1.4.3). The receiver shall be able to receive write transactions in any order.20 If the Receiver node does not want the Sender node to write to the SDU register, it shall not send

SDU Ready. However, if the Receiver node does not send SDU Ready within a data transfer timeout

period, a timeout error shall occur in the Sender node (the timeout sequence is described in section

5.10).


Page- 37

Figure 5-18 Thin Transaction data transfer

In this specification, SDU Send and SDU Comp of this data transfer procedure (Steps 2 and 3) is

described as "SDU Transfer", and marked with a bold arrow ( ) in the sequence diagrams.

3) SDU Comp

6) SDU Ready

2) SDU Send1) T_SDUSend.req

4) T_SDUSend.ind

5) T_SDUSend.rsp7) T_SDUSend.cnf

ThinTransaction

Sender node

ThinTransaction

Receiver node


Page- 38

5.9.1.4. Thin Transaction SDU Transfer Stop Sequence

The Thin Session shall issue an SDU transfer stop to terminate the SDU transfer.

The SDU transfer stop sequence shall use the following steps.

1) The Thin Session of the node that wants to terminate an SDU transfer (Sender node) issues an

SDU transfer stop request (T_SDUStop.req).

2) The Thin Transaction of the Sender node sends an SDU transfer stop packet (SDU Stop).

3) The Thin Transaction of the node that has received the SDU transfer stop packet (Receiver node)

issues an SDU transfer stop indication (T_SDUStop.ind) to the Thin Session.

4) The Thin Session of the Receiver node clears the receiving SDU data, and then issues an SDU

transfer stop response (T_SDUStop.rsp) to the Thin Transaction.

5) The Thin Transaction of the Receiver node sends an SDU transfer ready packet (SDU Ready).

6) The Thin Transaction of the Sender node issues an SDU transfer stop confirmation

(T_SDUStop.cnf) to the Thin Session when it has received an SDU transfer ready packet. The

Thin Session of the Sender node may then send another SDU if necessary.

Figure 5-19 Thin Transaction data transfer stop

2) SDU Stop

5) SDU Ready

SDU Send

6) T_SDUStop.cnf

1) T_SDUStop.req…

3) T_SDUStop.ind

4) T_SDUStop.rsp

ThinTransaction

Sender node

ThinTransaction

Receiver node


Page- 39

5.9.2. Application Command Transfer

For command execution, two transfer sequences are used.

l The node that wants to request command execution (Requester node) issues a command request.

l The node that receives a command request (Executor node) executes the command, and issues a

command response with the result of the command execution.

The command request and command response are each treated as Application data. The Thin Session

and Thin Transaction perform the transfer operation as described in sections 5.9.1.1 through 5.9.1.3.

It is possible to define a command request that does not expect a command response.

When the Application issues a command request, the Thin session shall apply a sequential ID number

(Command ID) for identifying each command. When the Application issues a command response, the

Application shall assign this same Command ID number as the corresponding command request.

One example of the Application command transfer sequence is described below. The procedure is

exemplified by the case in which the Application data size of a command request is so large that it

shall be segmented by the Thin Session, and the Application data size of command response is small

enough to be transferred without segmentation by the Thin Session.

1) The Application of the Requester node issues a command request (S_Command.req) to the Thin

Session.

2) The Thin Session of the Requester node applies a sequential ID number (Command ID) for

identifying each command, and issues an indication of an assigned Command ID

(S_CommandID.ind) to the Application.

3) The Thin Session and Thin Transaction of the Requester node perform the data transfer by using

the sequence described in sections 5.9.1.2 and 5.9.1.3, respectively.

4) The Thin Session of the Executor node issues a command indication (S_Command.ind) to the

Application when the data of the Application command has arrived.

5) The Application of the Executor node executes a received command, and issues the results of the

command execution as a command response (S_Command.rsp).

6) The Thin Session and Thin Transaction of the Executor node perform the data transfer by using

the sequence described in sections 5.9.1.1 and 5.9.1.3, respectively.

7) The Thin Session of the Requester node issues a command confirmation (S_Command.cnf) to the

Application when the data on the results of the command execution has arrived.


Page- 40

Figure 5-20 Application command transfer

1) S_Command.req

SDU Transfer

3) T_SDUSend.req(Segment data #1) T_SDUSend.ind

(Segment data #1)


SDU Transfer

T_SDUSend.req(Segment data #2) T_SDUSend.ind

(Segment data #2)


4) S_Command.ind

SDU Transfer

T_SDUSend.req(Segment data #n) T_SDUSend.ind

(Segment data #n)


2) S_CommandID.ind

7) S_Command.cnf

SDU Transfer 6) T_SDUSend.reqT_SDUSend.ind

T_SDUSend.rsp T_SDUSend.cnfSDU Ready

5) S_Command.rsp

Execute

ThinTransaction

ThinSession

Requester node

ThinSession

ThinTransaction

Executor node


Page- 41

5.9.3. Multiple Data Transfer

The Thin Protocol uses Command IDs to distinguish one application command from another.

Therefore, the Application may issue multiple commands simultaneously. The number of commands

that can be issued is specified by the command set (e.g. DPC specifies that two commands can be

issued simultaneously). The order of each command request is unspecified.

When the node receives a command request, while receiving other command requests, the Thin

Session of the node issues the command indication to the Application, if the node has the capability of

handling the command request. If the node does not have the capability, then the Thin Session of the

node shall issue an SDU transfer response describing an SDU reject.

When the node accepts multiple commands, the order of the command responses of each command is

unspecified. (This means that the command confirmation of the second command may be processed

before the command confirmation of the first command.)

The sequence diagram below shows the case where the Application issues multiple commands.

Figure 5-21 Multiple data transfer

S_Command.ind

S_Command.rsp

S_Command.req

CommandID:1

CommandID:2

CommandID:2

CommandID:2

S_Command.req

S_Command.cnf

ThinSession

ThinTransaction

ThinTransaction

ThinSession

S_CommandID.ind

CommandID:2

S_CommandID.ind

.......

Data transfer of a command request(Command ID: 1 / Segment data#1)

(This sequence is described in section 5.9.2)

Data transfer of a command request(Command ID: 2 / not segmented)


Data transfer of a command response(Command ID: 2 / not segmented)





Page- 42

5.9.4. Bi-directional Data Transfer

The Thin Protocol ensures bi-directional simultaneous transfer of data between two nodes using an

SDU transfer completion (SDUComp) and an SDU transfer ready (SDUReady). Therefore, an

Application may send one command while receiving another command.

When the node receives a command request, while sending another command request, the Thin

Session of the node issues a command indication to the Application if the node has the capability of

handling the command request. If the node does not have the capability, the Thin Session of the node

shall issue an SDU transfer response describing an SDU reject.

The order of a sending command request and a command response of a receiving command request is

unspecified. (This means that the command confirmation may be sent after completing the command

request transfer.)

The sequence diagram below shows the sequence for issuing a command in a bi-directional manner.

Figure 5-22 Bi-directional data transfer

S_Command.req

CommandID:3

ThinSession

ThinTransaction

ThinTransaction

ThinSession

S_CommandID.ind

S_Command.ind

S_Command.rsp

CommandID:1

CommandID:1

CommandID:1

S_Command.req

S_Command.cnf

CommandID:1

S_CommandID.ind

.......



Data transfer of a command request(Command ID: 1 / not segmented)


Data transfer of a command response(Command ID: 1 / not segmented)


Data transfer of a command response(Command ID: 3 / Segment data #2)



Page- 43

5.9.5. Abort

The Application may abort command execution at any time (e.g. by using the Cancel command of

DPC21). Both the node sending a command request and the node receiving a command request may

send this command abort request. The Application shall issue a command abort request with the

Command ID of the Application command that is requested to be aborted. The Thin Session may

issue an SDU transfer stop request if the Thin Transaction is sending an SDU containing Application

data for a command that has been requested to be aborted.

The abort sequence shall use the following steps.

Note that this sequence shall not expect a response from the Receiver node.

1) The Application of the node that wants to abort the command execution (Sender node) issues a

command abort request (S_Abort.req) to the Thin Session.

2) If the Thin Transaction of the Sender node is sending an SDU (e.g. before receiving SDU Ready)

that has the same Command ID as the command abort request, the Thin Session may issue an

SDU transfer stop request (this sequence is described in section 5.9.1.4). Otherwise, the Thin

Session shall wait to receive SDU Ready (or SDU Reject) before sending an SDU transfer

request.


Thin Transaction for transferring a higher layer abort command (This format is described in

section 5.11.8.1) using the sequence described in sections 5.9.1.2 and 5.9.1.3, respectively.

4) If the Thin Transaction of the node, that receives a higher layer abort command, (Receiver node)

is sending an SDU (e.g. before receiving SDU Ready), that has the same Command ID as the

command abort request, then the Thin Session may issue an SDU transfer stop request (this

sequence is described in section 5.9.1.4). Otherwise, the Thin Session shall wait to receive SDU

Ready (or SDU Reject) before issuing a command abort indication.

5) The Thin Session of the Receiver node issues a command abort indication (S_Abort.ind) to the

Application.

21 Note that the Cancel command of DPC shall be issued by using the abort sequence.


Page- 44

Figure 5-23 Abort sequence

5)S_Abort.ind

1) S_Abort.req

(T_SDUStop.req)

(T_SDUStop.cnf)

2) This sequence is usedonly when the Thin Sessionwants to stop SDU transfer.

(T_SDUStop.req)

(T_SDUStop.cnf)

4) This sequence is usedonly when the Thin Sessionwants to stop SDU transfer.

SDU Transfer

3) T_SDUSend.req(abort command) T_SDUSend.ind

(abort command)


Abort

ThinTransaction

ThinSession

Sender node

ThinSession

ThinTransaction

Receiver node


Page- 45

5.10. Timeout Sequence

The Thin Protocol uses several timeout periods for solving abnormal conditions. The Thin Protocol

compliant devices shall implement these timeouts. These timeouts shall be realized in the Thin

Session protocol.

5.10.1. Connect Timeout

Timeout value: 5 seconds.

The connect timeout occurs when the Thin Session issues a connect request and a connect response

service from the Thin Transaction is not issued within the specified period. If this timeout occurs, the

Thin Session shall issue an error indication to the Application, and shall issue a disconnect request to

the Thin Transaction (for releasing the resources of the receiver node). This disconnect request causes

a disconnect sequence described in section 5.8.3.

Figure 5-24 Connect timeout

Connect ReqS_Connect.req T_Connect.req

ConnectTimeout

T_Disconnect.reqS_Error.ind

ThinTransaction

ThinSession

Initiator node

ThinSession

ThinTransaction

Responder node


Page- 46

5.10.2. Reconnect Timeout

Timeout value: 5 seconds

The Thin timeout occurs when a reconnect sequence is not completed within the specified period after

bus reset. If this timeout occurs, the Thin Session shall release the resources, issue an error indication

to the Application, and issue a disconnect request to the Thin Transaction (for releasing the resources

of the receiver node). This disconnect request causes a disconnect sequence described in section 5.8.3.

Figure 5-25 Reconnect timeout

Reconnect Req

T_Reconnect

ReconnectTimeout

T_Disconnect.reqS_Error.ind

T_Error.ind Bus Reset

ThinTransaction

ThinSession

Sender node

ThinSession

ThinTransaction

Receiver node

T_Error.ind

ReconnectTimeout

S_Error.indT_Disconnect.req


Page- 47

5.10.3. Idle Timeout

Timeout value: determined by negotiation when establishing a connection (default: 30 min).

This timeout occurs when the Thin Protocol connection has been established and no service from/to

the Thin Transaction has been issued within the specified period. This timeout shall be restarted when

any services has been issued from/to the Thin Transaction. If this timeout occurs, the Thin Session

shall issue an error indication to the Application. The Application may issue a disconnect request if an

error indication is issued. The sequence is specified by the Application.

Figure 5-26 Idle timeout

SDU Transfer

SDU Transfer

S_Command.rsp

S_Command.reqT_SDUSend.req

T_SDUSend.ind

T_SDUSend.req

T_SDUSend.indS_Command.cnf

IdleTimeout

S_Error.ind

S_Command.indT_SDUSend.rspT_SDUSend.cnf SDU Ready


ThinTransaction

ThinSession

Requester node

ThinSession

ThinTransaction

Executor node

IdleTimeout

S_Error.ind


Page- 48

5.10.4. Data Transfer Timeout

Timeout value: determined by negotiation when establishing a connection (default: 10min).

This timeout occurs when, during the process of data transfer, no service from/to the Thin Transaction

has been issued within the specified period. Specifically, this timeout occurs in the following

situations:

l The Thin Session issues an SDU transfer request, but an SDU transfer confirmation is not issued

by the Thin Transaction.

l The Thin Session receives a segment data and replies with an SDU transfer response, but an SDU

transfer indication of the next segment data is not issued.

If this timeout occurs, the Thin Session shall issue an error indication to the Application. The

Application may issue a disconnect request if an error indication is issued. The sequence is specified

by the Application.


Page- 49

Figure 5-27 Data transfer timeout - 1


SDU Transfer

S_Command.req T_SDUSend.req(Segment #1) T_SDUSend.ind

(Segment #1)

Data transferTimeout

S_Error.ind


ThinTransaction

ThinSession

Executor node

ThinSession

ThinTransaction

Requester node

SDU Transfer


T_SDUSend.ind

Data transferTimeout

S_Error.ind

ThinTransaction

ThinSession

Requester node

ThinSession

ThinTransaction

Executor node


Page- 50

Note that this timeout shall be restarted when any services has been issued from/to the Thin

Transaction. So, when a segment data is received while another SDU is being sent, the timeout shall

be restarted at the time that the last service is received.


SDU TransferS_Command.reqT_SDUSend.req

(Segment #1)


SDU Transfer


T_SDUSend.ind

Data transfer timer start(for an SDU transferconfirmation)

Data transfer timer stop(because indication serviceis issued)

Data transfer timer start(for next segment data)

Data transfer timer stop(because all data has arrived)

SDU Transfer

T_SDUSend.req(Last segment)T_SDUSend.ind

(Last segment)


Data transfer timer restart(because an SDU transferconfirmation is not issued yet.)

ThinTransaction

ThinSession

ThinSession

ThinTransaction

S_Error.ind

T_SDUSend.ind(Segment #1)


Page- 51

5.11. Thin Protocol Format

The Thin Protocol Format is described in this section.

In the Thin Protocol, the Thin Session attaches the Thin Session field to the Application data. The Thin

Transaction transfers the packet with a 1394 write transaction.

The Thin Session field format and Thin Transaction transfer operations are described in the following

sections.

5.11.1. Thin Session Service

The Thin Session provides the following services to the Application:

l Connect establishment < S_Connect (req, ind, rsp, cnf) >

l Disconnect < S_Disconnect (req, ind) >

l Execution of Application command < S_Command (req, ind, rsp, cnf) >

l Abort execution of Application command < S_Abort (req, ind) >

l Indication of CommandID for identifying Application commands < S_CommandID (ind) >

l Indication of errors < S_Error (ind) >

The Thin Session field format for realizing the services above is described below.

The services of indication of CommandID and indication of error have no packet, since they are an

internal process issued by the Thin Session to the Application.

5.11.2. Thin Session Field Format

The Thin Session field is composed of a Session ID, MsgType and one or more information tag(s).

The Session ID is used as the session identifier for distinguishing the connection. The Initiator node

assigns a Session ID when issuing a connect request. If the Thin Protocol version of the Responder

node is 1.0, the Initiator node shall assign 00h as the Session ID. If the Thin Protocol version of the

Responder node is 1.1 or later, the Initiator node shall assign a unique Session ID value per connection

between any two nodes. The version of Thin Protocol is specified by the Unit_SW_Details entry in

the configuration ROM (see section 6.1.4.3)

MsgType is used for representing the kind of message.

Information tag is used for describing various information, and is composed of InfType for discerning

the information, and Information value.

Figure 5-30 Thin Session field format

Session ID MsgType InfType Information InfType


Page- 52

The MsgType and InfType are defined below. All values other than the ones mentioned below are

reserved.

Table 5-2 MsgType defined value

10h Connect request

11h Connect confirmation

12h Connect rejection

20h Data

21h Data abort

30h Disconnect request

40h Reconnect request

41h Reconnect confirmation

42h Reconnect rejection

Table 5-3 InfType defined value

00h Version

40h Connection data

80h Application data


Page- 53

5.11.3. Negotiation Information

There are several types of information, such as timeout values, register address and size exchanged

during the connect sequence (Table 5-4). All devices compliant with the Thin Protocol shall support

all requested values for negotiation information defined in this specification, except the SDU register

size which is determined by the dynamic register allocation algorithm (see section 5.8.1.2).

In the Thin Session format used for connection (Connect Request/Ack/Nack), the negotiation

information field is used for negotiation between nodes. This field format is described below.

5.11.3.1. Negotiation Information Tag

Negotiation information is composed of a negotiation information tag (NegInf Tag) and a negotiation

information value (NegInf Value). NegInf Tag is defined below.

The information marked “M” (Mandatory) shall be contained in the negotiation information field. If

any of this mandatory information is not included, the connection shall not be established.

The information marked “O” (Optional) may be contained in the negotiation information field. If the

information is not included, a default value is used for each related value.

If unrecognized information is specified, the node shall ignore the information.

NOTE:

In the Connect Request Format (described in section 5.11.4.1), the NegInf value for the SDU address

and SDU management address of Responder node shall be filled with a value, though this value may

not be a valid value. The Responder node may ignore this value and allocate addresses on it’s own.

In the Connect Ack Format (described in section 5.11.4.2), the NegInf value for SDU address and

SDU management address of Initiator node shall include the same values of the Connect Request from

the Initiator node.

If the optional negotiation information is used in the Connect Nack Format (described in section

5.11.4.3), all mandatory NegInf tags shall be included.


Page- 54

Table 5-4 NegInf Tag defined value

NegInf Tag Meaning

00h Vendor ID M

01h Command set ID M

02h Transfer Mode M

03h Reserved

04h Idle Timeout (sec) O

05h Data Transfer Timeout (sec) O

06h - 07h Reserved

08h SDU management register address of Initiator node M

09h SDU management register address of Responder node M

0Ah SDU register address of Initiator node M

0Bh SDU register address of Responder node M

0Ch SDU register size of Initiator node M

0Dh SDU register size of Responder node M

0Eh - 0Fh Reserved

10h Page table address of Initiator node O

11h Page table address of Responder node O

12h Page table size of Initiator node O

13h Page table size of Responder node O

14h Page table access capability of Initiator node O

15h Page table access notification of Responder node O

16h - 17h Reserved

18h Vendor unique Command set ID O

19h - 3Fh Reserved

40h - 7Fh Not defined

80h – BFh Vendor Unique Tag

C0h – FFh Not defined


Page- 55

5.11.3.2. Negotiation Information Format

In the negotiation information field, some information may be included. Each information field uses

the format described below. The information format that has a NegInf Tag value within 40h to 7Fh and

C0h to FFh is not defined in this specification. If the node receives such values, the connection shall

not be established.

5.11.3.2.1. Negotiation Information Format

The information for which the NegInf Tag value is 00h to 3Fh or 80h to BFh uses the following format.

Figure 5-31 Negotiation information format - 2

5.11.3.2.2. Vendor ID

Figure 5-32 Vendor ID

Vendor ID: the same value as Module_Vendor_ID of Configuration ROM.

Reserved field shall be set to 0.

5.11.3.2.3. Command Set ID

Figure 5-33 Command set ID

Command set ID: Identifier specified command set. 01h shall be used for DPC. 02h shall be

used for FTC. FFh shall be used for a vendor unique command set. When using a

vendor unique command set, a Vendor unique command set ID shall be present

(see section 5.11.3.2.12). Other values are reserved.

NegInf Value

NegInf Tag Length

Reserved Vendor ID

NegInf Tag (00h) ReservedLength (06h)

NegInf Tag (01h) Command set ID Version numberLength (02h)


Page- 56

Version number: Version number of the command set. The least significant bytes of the tag

represent the version number of the command set. 4 bits will represent a digit in

hexadecimal, with the most significant 4 bits representing the digit above the

decimal point, and the least significant 4 bits representing 1 decimal place below

the decimal point. For example, version 1.0 will be represented as 10h.

5.11.3.2.4. Transfer Mode

Figure 5-34 Transfer mode

Low-level interface: 01h as IEEE1394-1995.

Transfer mode: 00h as Asynchronous PUSH model

5.11.3.2.5. Timeout

The node receiving this tag shall set the timeout value greater than this value (i.e. The node issuing this

tag shall set this value to the minimum timeout value it wants the connecting node to apply.).

If this information is not included, then a default value shall be used as the timeout period. The default

value of each timeout is shown below.

Table 5-5 Default timeout value

Timeout Default value

Idle timeout (04h) 1800 (30 min)

Data transfer timeout (05h) 600 (10 min)

Figure 5-35 Timeout

Timeout value: Timeout value is in seconds.

NegInf Tag (02h) Length (02h) Low-level interface Transfer mode

NegInf Tag (04h-05h) Timeout ValueLength (02h)


Page- 57

5.11.3.2.6. Register Space Address

Figure 5-36 Register space address

Register space address: The address of the register space. The last 2 bits of this field shall be

set to 0 for the quadlet boundary.

5.11.3.2.7. Register Space Size

Figure 5-37 Register space size

Register space size: Register space size in bytes. This value shall be at least 512 bytes. The

last 2 bits of this field shall be set to 0 for the quadlet boundary.


NegInf Tag (0Ch/0Dh) Length (06h) Reserved

Register space size

Register space address

NegInf Tag (08h-0Bh) Length (06h)


Page- 58

5.11.3.2.8. Page table address

Figure 5-38 Page table address

Page table address: The address of the page table. The last 2 bits of this field shall be set to

0 for the quadlet boundary.

5.11.3.2.9. Page table size

Figure 5-39 Page table size

Number of elements: The number of page elements in the page table. The page table size, in

bytes, is equal to (number of elements) * 8.

5.11.3.2.10. Page table access capability of Initiator node

Figure 5-40 Page table access capability of Initiator node

C: Page table access capability. When this bit is set, the Initiator node is capable of using a

page table to send SDU. When this bit is not set, the Initiator node is not capable

of using a page table to send SDU.


Page table address

NegInf Tag (10h,11h) Length (06h)

NegInf Tag (12h,13h) Number of elementsLength (02h)

NegInf Tag (14h) ReservedLength (02h) C


Page- 59

5.11.3.2.11. Page table access notification of Responder node

Figure 5-41 Page table access notification of Responder node

N: Page table access notification. When this bit is set, the Responder node will use a page

table to send SDU. When this bit is not set, the Responder node will not use a

page table to send SDU.


The page table access rules are the following.

Table 5-6 The page table access rules

Initiator node Responder node Result

Set page table address

and size.

Set page table access

notification to 1.

Responder node shall use a page table to send SDU.

(Initiator node receives SDU using a page table.)

Set page table access

capability to 1.

Set page table address

and size.

Initiator node shall use a page table to send SDU.

(Responder node receives SDU using a page table.)

The negotiation information required for a Responder node to use a page table includes a page table

address, size issued from the Initiator node and page table access notification issued from the

Responder node. The Responder node shall not use a page table if either of the above negotiation

information is missing.

The negotiation information required for an Initiator node to use a page table includes a page table

access capability issued from the Initiator node, page table address, and size issued from the

Responder node. The Initiator node shall not use a page table if either of the above negotiation

information is missing.

All mandatory tags shall be added even if the tags related to a page table (10h-15h) are included. When

a page table is used, the page table address and size tags are valid and the SDU register address and

size tags are ignored.

NegInf Tag (15h) ReservedLength (02h) N


Page- 60

5.11.3.2.12. Vendor Unique Command set ID

Figure 5-42 Vendor unique command set

Command set spec ID: The command set spec identifier of the vendor unique command set.

This value shall be the same value as the Command_Set_Spec_ID entry in the

Configuration ROM (see section 6.1.4.4).

Command set: The command set identifier of the vendor unique command set. This value

shall be the same value as the Command_Set_ID entry in the Configuration ROM

(see section 6.1.4.5).

Command set details: The command set details of the vendor unique command set. This

value shall be the same value as the Command_Set_Details entry in the

Configuration ROM (see section 6.1.4.6).

When this information is present, the Command set ID value in the Command set ID information shall

be set to FFh (see section 5.11.3.2.3).

5.11.3.2.13. Vendor Unique Information

Figure 5-43 Vendor unique information

Each Vendor that is specified by Vendor ID (see section 5.11.3.2.2) defines this negotiation

information. The usage and value are not defined in this specification.

Vendor unique value

NegInf Tag (80h-BFh) Length (06h)

NegInf Tag (18h) Length (0Eh) Reserved

Command set spec ID

Command set

Command set details

Reserved

Reserved

Reserved


Page- 61

5.11.4. Format used for Connection

5.11.4.1. Connect Request Format

This format shall be used when S_Connect.req is issued by the Application. The Thin Session shall

create these fields and issue T_Connect.req to the Thin Transaction.

Figure 5-44 Connect request format

SessionID, MsgType, InfType: Described in section 5.11.2.

Version: Version of the Thin Protocol. 11h shall be used for Thin Protocol version 1.1 (11h

represents version 1.1). Upon connection with the Thin Protocol version 1.0 node, this

field shall be set to 10h, to support connection with Thin Protocol version 1.0 nodes and

assure backward compatibility.

Length: Length from the Destination Machine ID field to the last byte of this packet in bytes.

Destination Machine ID: Machine ID of the node which receives a connect request.

Source Machine ID: Machine ID of the node which sends a connect request.

Negotiation Information: Described in section 5.11.3.

Reserved field shall be set to 00h.

Negotiation Information

Source Machine ID

VersionSession ID InfType (00h)

InfType (40h)

MsgType (10h)

Reserved Length

Destination Machine ID


Page- 62

5.11.4.2. Connect Ack Format

This format shall be used when S_Connect.rsp representing a connect confirmation is issued by the

Application. The Thin Session shall create these fields and issue T_Connect.rsp to the Thin

Transaction.

Figure 5-45 Connect ack format

SessionID: Described in section 5.11.2. Use the same Session ID with Connect Request.

MsgType, InfType: Described in section 5.11.2.

Version: Version of the Thin Protocol. This value shall be the same value as the version field in a

connect request22.

NOTE:

When the connection is established as Thin Protocol version 1.0, the enhancements made

from Thin Protocol version 1.0 (see Annex G) shall not be used on the connection (e.g.

multiple connections).


Destination Machine ID: Machine ID of the node which receives a connect ack.

Source Machine ID: Machine ID of the node which sends a connect ack.

Negotiation Information: Described in section 5.11.3.


22 When a connect request specifies an unsupported version, the connection shall not be established

and shall return a connect nack by using a connect nack format (see section 5.11.4.3).


Source Machine ID


InfType (40h)

MsgType (11h)

Reserved Length



Page- 63

5.11.4.3. Connect Nack Format

This format shall be used when S_Connect.rsp representing a connect rejection is issued by the

Application. The Thin Session shall create these fields and issue T_Connect.rsp to the Thin

Transaction.

Figure 5-46 Connect nack format

SessionID: Described in section 5.11.2. Uses the same Session ID with Connect Request.

MsgType, InfType: Described in section 5.11.2.

Version: Version of the Thin Protocol. This value is the same value as the version field in a connect

request. When a connect request specifies an unsupported version, the supported version

of the node (11h for the Thin Protocol version 1.1) shall be set instead of the version in a

connect request.

Result: Result of connect rejection.

Table 5-7 Result of connect rejection

Result Value Meaning

01h Rejected by user

10h Already connected

11h No resource for more connection

12h Illegal negotiation parameter

13h Busy processing connection

FFh Unspecified reason

others Reserved

When a connect nack with the result value 10h (Already connected) is returned, though

the Requester node has not established the connection, there is a possibility that the

register spaces of the Responder node are still allocated. In that case, the Requester node

may issue a disconnect request to release the resource of the Responder node.


Source Machine ID


InfType (40h)

MsgType (12h)

Result Length


Optional


Page- 64

The value 11h (No resources for more connections) shall be returned for Thin Protocol

version 1.0 nodes, instead of 13h, since the result value 13h (Busy processing connection)

is not defined in Thin Protocol version1.0.

Reserved in the table above shall be treated as Unspecified reason.


Destination Machine ID: Machine ID of the node which receives a connect nack.

Source Machine ID: Machine ID of the node which sends a connect nack.

Negotiation Information: Described in section 5.11.3. This field in this format is optional. If the

node attaches Negotiation information, the Negotiation information value shall be set to

an acceptable value of the node. When the node has no acceptable value, all bits in the

Negotiation information value field shall be set to 0.

5.11.5. Format used for Reconnection

5.11.5.1. Reconnect Request Format

This format shall be used when T_Error.ind is indicated from the Thin Transaction and a reconnection

is necessary. The Thin Session shall create these fields and issue T_Reconnect.req to the Thin

Transaction.

Figure 5-47 Reconnect request format


Version: Version of the Thin Protocol (11h for this version).


Destination Machine ID: Machine ID of the node that receives a reconnect request.

Source Machine ID: Machine ID of the node that sends a reconnect request.


Source Machine ID


InfType (40h)

MsgType (40h)

Reserved Length (00 10h)



Page- 65

5.11.5.2. Reconnect Ack Format

This format shall be used when T_Reconnect.ind is indicated from the Thin Transaction and a

reconnection is established. The Thin Session shall create these fields and issue T_Reconnect.rsp to

the Thin Transaction.

Figure 5-48 Reconnect ack format



Length: Length from the Destination Machine ID field to the last byte of this packet, in bytes.

Destination Machine ID: Machine ID of the node that receives a reconnect ack.

Source Machine ID: Machine ID of the node that sends a reconnect ack.



InfType (40h)

MsgType (41h)

Reserved Length (00 10h)

Source Machine ID



Page- 66

5.11.5.3. Reconnect Nack Format

This format shall be used when T_Reconnect.ind is indicated from the Thin Transaction and a

reconnection is rejected. The Thin Session shall create these fields and issue T_Reconnect.rsp to the

Thin Transaction.

Figure 5-49 Reconnect nack format



Result: Result of reconnect rejection.

Table 5-8 Result of reconnect rejection


20h Resource is already discarded


others Reserved



Destination Machine ID: Machine ID of the node that receives a reconnect nack.

Source Machine ID: Machine ID of the node that sends a reconnect nack.


InfType (40h)

MsgType (42h)

Result Length (00 10h)

Source Machine ID



Page- 67

5.11.6. Format used for Disconnection

5.11.6.1. Disconnect Format

This format shall be used when S_Disconnect.req is issued from the Application. The Thin Session

shall create these fields and issue T_Disconnect.req to the Thin Transaction.

Figure 5-50 Disconnect format



Result: Result of disconnect.

Table 5-9 Result of disconnect


01h Disconnected by user

02h 1394 connection is disconnected


others Reserved



Destination Machine ID: Machine ID of the node that receives a disconnect request.

Source Machine ID: Machine ID of the node that sends a disconnect request.

Session ID InfType (00h)MsgType (30h) Version

Length (00 10h)Result

Source Machine ID


InfType (40h)


Page- 68

5.11.7. Format used for Data Transfer

This format shall be used when S_Command.req or S_Command.rsp is issued from the Application.

The Thin Session shall determine whether segmentation is necessary in accordance with the

Application data size and the SDU register size, create these fields, and issue T_SDUSend to the Thin

Transaction.

5.11.7.1. Application Data Segmentation

The Thin Session segmentation sequence shall use the following steps.

i) The Thin Session applies the Application data header (Application data length, Destination

Machine ID, Source Machine ID, Destination PID, and Source PID; the meanings of

these fields are described in sections 5.11.7.2 and later) to the Application data.

ii) It is determined if the data (Application data with the Application data header) can be sent all

at once, or not, by using the SDU register.

iii) If it can not, then the Thin Session segments the data (Application data with the Application

data header). If it can, the data is sent by using the Single data format (described in

section 5.11.7.2).

iv) Each segment data is sent. The location of the segment data (first/interim/last) is described in

the segment flag field.

Figure 5-51 Application data segmentation

First segment data

Application data

…

Interim segment data

…

Last segment data

Application data length

Source PIDDestination PID

Source Machine ID


Application data header

Application data


Page- 69

5.11.7.2. Single Data Format

This format shall be used when the Application data is small enough to be transferred without

segmentation.

Figure 5-52 Single data format


Segment flag: Segmentation Information flag. It shall be set to C0h in this packet.

Length: Length from the Sequence number field to the last byte of the Application data, in bytes.

Sequence number: Sequence number of the segment data. It shall be set to 0000h in this packet.

Remaining number (optional): Remaining number of segment data. If used, then it shall be set to

0001h. If the remaining number field is not used, it shall be set to 0000h.

Segment flag (C0h)

Command ID

Session ID InfType (80h)MsgType (20h)

Length

Reserved

Remaining numberSequence number (0000h)



Source Machine ID

Application data length

Application data

Command type

Applicationdata header


Page- 70

Command type: Command specified field.

Table 5-10 Command type

Command type Meaning

00h Command request

40h Command response (Ack)

80h Command response (Nack)

Command ID: When the Application issues a command request (S_Command.req), the Thin

session applies a unique ID number for identifying the Application command. When the

Application issues a command response, the Application uses the same ID that was used

in the corresponding command request.

NOTE:

If both the Initiator node and the Responder node send commands at the same time, then

the Thin Session of both nodes might apply the same command ID value.

To prevent this, it is recommended that the Initiator node (issuing node of the Connect

request) uses a value from 0000h to 7FFFh, and the Responder node (responding node to

the Connect request) uses a value from 8000h to FFFFh as the command ID.


Application data length: Length from the Destination Machine ID field to the last byte of the

Application data, in bytes.

Destination Machine ID: Machine ID of the node that receives a data transfer request.

Source Machine ID: Machine ID of the node that sends a data transfer request.

Destination PID, Source PID: Identification Number to specify the Application program. The use of

this field is specified by the command set.

NOTE:

The fields from the Application data length field to the Source PID field are treated as the

Application data header.


Page- 71

5.11.7.3. Segment Data Format

This format shall be used for transferring segmented data.

Figure 5-53 Segment data format

The Application data header is included in the first segment data. The Application data header uses

the same format as the header used for the single data format. See section 5.11.7.2.


Segment flag: Segment information is described in this field. 40h is used for the first segment data,

00h is for all interim segment data, 80h is the last segment data.

Table 5-11 Segment flag

Segment flag Meaning

40h First segment data

80h Last segment data

00h Interim segment data

Length: Length from the Sequence number field to the last byte of the Segment data, in bytes.

Sequence number: This field describes the sequence number of the segment data. This number

starts at 0000h and is increased one by one for each segment data. When the number

reaches FFFFh, the next value is started again from 0000h.

Remaining number (optional): This field describes the remaining number of the segment data. This

number includes transferring data, so the value of the last segment data is 0001h. If the

remaining number of the segment data is more than FFFFh or this field is not used, then it

shall be set to 0000h.

Command type: Command specified field. See Table 5-10.

Command ID: This field is the same as the single data format. See section 5.11.7.2.

Segment data (First/Interim/Last)

Segment flagSession ID MsgType (20h) InfType (80h)

Length

Reserved Command ID

Remaining numberSequence number

Command type


Page- 72

5.11.8. Format used for Command Abort

5.11.8.1. Abort Format

This format shall be used when S_Abort.req is issued from the Application. The Thin Session shall

create these fields and issue T_SDUSend.req to the Thin Transaction. If the Thin Transaction is

sending an SDU that has the same Command ID as the command abort request, the Thin Session may

issue an SDU transfer stop request (T_SDUStop.req) to the Thin Transaction. Otherwise, the Thin

Session shall wait to receive SDU Ready (or SDU Reject) before issuing an SDU transfer request.

Figure 5-54 Abort format


Segment flag: Segmentation Information flag. It shall be set to C0h in this packet.

Length: Length from the Sequence number field to the last byte of the Application data in bytes.

Sequence number: Sequence number of the segment data. It shall be set to 0000h in this packet.

Remaining number (optional): Remaining number of segment data. If used, it shall be set to 0001h.

If the remaining number field is not used, it shall be set to 0000h.

Command type: Command specified field. It shall be set to 00h.

Command ID: Command ID of the Application data that is requested to be aborted.

Sequence number (0000h)

Segment flag (C0h)


Remaining number


Source Machine ID

Session ID InfType (80h)MsgType (21h)

Length

Application data Length

Reserved Command ID

Application data (higher layer abort command)

Command type


Page- 73

Application data length: Length from the Destination Machine ID field to the last byte of the

Application data, in bytes.

Destination Machine ID: Machine ID of the node that receives a command abort request.

Source Machine ID: Machine ID of the node that sends a command abort request.

Destination PID, Source PID: Identification Number to specify the Application program. The use of

this field is specified by the command set.

Application data: Higher layer abort command that is sent to another node (e.g. Cancel command of

DPC).


Page- 74

5.11.9. Thin Transaction Service

The Thin Transaction provides the following services to the Thin Session:

l Connection establishment and allocation of resources < T_Connect (req, ind, rsp, cnf) >

l Re-establishment of a connection < T_Reconnect (req, ind, rsp, cnf) >

l Disconnect and release of resources < T_Disconnect (req, ind) >

l Transfer of data < T_SDUSend (req, ind, rsp, cnf) >

l Abort of data transfer < T_SDUStop (req, ind, rsp, cnf) >

l Indication of errors < T_Error (ind) >

The Thin Transaction operation to perform the services above is described below.

The service of indication of errors has no packet, since it is an internal process issued by the Thin

Transaction to the Thin Session.

5.11.10. Register Space

The three Registers mentioned below shall be used in the Thin Transaction.

l Connection register

The Connection register shall be used for the following operations:

Connect Request/Response

Reconnect Request/Response

Disconnect Request

Figure 5-55 Connection register

l SDU register

The SDU register shall be used for the following operation:

SDU Transfer

Figure 5-56 SDU register

SDU register space

Connection register space


Page- 75


The SDU management register contains SDU control space and SDU response space.

SDU control space shall be used for the following operations:

SDU Transfer Completion

SDU Transfer Stop

SDU response space shall be used for following operations:

SDU Transfer Ready

SDU Transfer Reject

Figure 5-57 SDU management register

SDU control space

SDU response space


Page- 76

5.11.11. Data Specification Field

In the Connection register and SDU management register, the kind of data stored shall be described in

the first 4 bytes. This field is called the Data specification field and the format is shown below. All

bits of the Reserved field shall be set to 0.

Figure 5-58 Data specification field

Data Types: The type of data stored.

Table 5-12 Data type defined value

10h Connect Req

11h Connect Ack

12h Connect Nack

30h Disconnect Req

40h Reconnect Req

41h Reconnect Ack

42h Reconnect Nack

E0h SDU Comp

E1h SDU Stop

F0h SDU Ready

F1h SDU Reject

Length: The length of the data (issued by the Thin Session) is described in bytes. This field shall be

used only when accessing the Connection register. For the SDU register and SDU

management register access, this field is reserved.

The machine which has had data written into the Connection register uses this field to

determine if all of the data has arrived.

(Length)Data Type Reserved


Page- 77

5.11.12. Operation used for Connection

5.11.12.1. Connect Request

When T_Connect.req is issued from the Thin Session of the Initiator node, the Thin Transaction shall

attach the data specification field and send this packet to the Connection register of the Responder

node.

Figure 5-59 Connect request

5.11.12.2. Connect Response

When T_Connect.rsp is issued from the Thin Session of the Responder node and it represents a

connection confirmation, the Thin Transaction shall allocate the SDU register and SDU management

register. After allocating the register spaces, the Thin Transaction shall attach the data specification

field and send this packet to the Connection register of the Initiator node.

When T_Connect.rsp represents a connection rejection, the Thin Transaction shall attach the data

specification field and send this packet to the Connection register of the Initiator node, without

allocating register spaces.

Figure 5-60 Connect response

Data Type (10h)

Connection register

Reserved Length

Data from Thin Session (described in section 5.11.4.1)

Connection register

Data from Thin Session (described in section 5.11.4.2 and 5.11.4.3)

Data Type (11h/12h) Reserved Length


Page- 78

5.11.13. Operation used for Reconnection

5.11.13.1. Reconnect Request

When T_Reconnect.req is issued from the Thin Session of the Sender node, the Thin Transaction shall

attach the data specification field and send this packet to the Connection register of the Receiver node.

Figure 5-61 Reconnect request

5.11.13.2. Reconnect Response

When T_Reconnect.rsp is issued from the Thin Session of the Receiver node, the Thin Transaction

shall attach the data specification field and send this packet to the Connection register of the Sender

node.

The data type value in the data specification field shall represent Reconnect ack (in the case of a

reconnect confirmation) or Reconnect nack (in the case of a reconnect rejection).

Figure 5-62 Reconnect response

Connection register


Data Type (40h) Reserved Length

Connection register

Data from Thin Session (described in section 5.11.5.2 and 5.11.5.3)

Data Type (41h/42h) Reserved Length


Page- 79

5.11.14. Operation used for Disconnection

5.11.14.1. Disconnect Request

When T_Disconnect.req is issued from the Thin Session of the Sender node, the Thin Transaction

shall release the allocated register, attach the data specification field and send this packet to the

Connection register of the Receiver node.

Figure 5-63 Disconnect request

5.11.15. Operation used for SDU Transfer

5.11.15.1. SDU Transfer

When T_SDUSend is issued from the Thin Session of the Sender node, the Thin Transaction shall

send the data from the Thin Session as a packet to the SDU register of the Receiver node without

applying any field.

Figure 5-64 SDU transfer

5.11.15.2. SDU Transfer Completion

When the transfer of an SDU is completed, the Thin Transaction shall send the data specification field

representing SDU transfer completion (SDU Comp) to the SDU Control Space in the SDU

management register of the Receiver node.

Figure 5-65 SDU transfer completion

Connection register


Data Type (30h) Reserved Length

SDU register

Data from Thin Session (described in section 5.11.7 and later)

SDU management register (SDU control Space)

Data Type (E0h) Reserved


Page- 80

5.11.15.3. SDU Transfer Stop

When T_SDUStop is issued from the Thin Session of the Sender node, the Thin Transaction shall send

the data specification field representing SDU transfer stop (SDU Stop) to the SDU control space in the

SDU management register of the Receiver node.

Figure 5-66 SDU transfer stop

5.11.15.4. SDU Transfer Ready

When SDU Comp is stored in the SDU control space, the Thin Transaction shall issue an SDU transfer

indication (T_SDUSend.ind) to the Thin Session that the data is stored in. After the Thin Session

stores the data to the buffer and sets the SDU register ready for receiving the next SDU, the Thin

Session issues an SDU transfer response (T_SDUSend.rsp) that indicates the SDU register is available

for writing.

When the Thin Transaction receives the service, the Thin Transaction shall send the data specification

field representing SDU transfer ready (SDU Ready) to the SDU response space in the SDU

management register of the Sender node.

After SDU Ready is stored from the Receiver node, the Thin Transaction of the Sender node shall

issue an SDU transfer confirmation (T_SDUSend.cnf) to the Thin Session. The Thin Session of

Sender node may transfer the next packet at this timing.

Figure 5-67 SDU transfer ready

SDU management register (SDU response space)

Data Type (F0h) Reserved

SDU management Register (SDU control space)

Data Type (E1h) Reserved


Page- 81

5.11.15.5. SDU Transfer Reject

When SDU Comp is stored in the SDU control space, the Thin Transaction shall issue an SDU transfer

indication (T_SDUSend.ind) to the Thin Session that the data is stored in. When the Thin Session

cannot store the data to the buffer, the Thin Session shall make the SDU register ready for receiving

next SDU and issue an SDU transfer response (T_SDUSend.rsp) to the Thin Transaction that indicates

the SDU transfer is rejected.

When the Thin Transaction receives the service, the Thin Transaction shall send the data specification

field representing SDU transfer reject (SDU Reject) to the SDU response space in the SDU

management register of the Sender node.

After SDU Reject is stored from the Receiver node, the Thin Transaction of the Sender shall issue an

SDU transfer confirmation (T_SDUSend.cnf) to the Thin Session that indicates the SDU transfer is

rejected. The Thin Session may retry to send the same SDU. If the Thin Session does not retry, it shall

issue an error indication to the Application. When an error is indicated, the Application shall issue a

command abort request.

Figure 5-68 SDU transfer reject

SDU management register (SDU response space)

Data Type (F1h) Reserved


Page- 82

6. Configuration ROM Definition for Thin Protocol

All nodes that implement the Thin Protocol shall implement the general format configuration ROM in

accordance with ISO/IEC 13213:1994, p1212r (under work), IEEE Std 1394-1995 and this standard.

General format configuration ROM is a self-descriptive structure defined by IEEE1212. The bus

information block and root directory are at fixed locations; all other directories and leaves are

addressed by entries in their parent directory.

Figure 6-1 Configuration ROM hierarchy

The figure above shows the areas of the general ROM format described in this specification.

All nodes that implement the Thin Protocol shall implement the directories described in section 6.1.

All nodes that implement the Thin Protocol shall implement the instance directory described in section

6.2

InstanceDirectory

BusInformation

Block

Root

Directory UnitDirectory

Command Set

Directory

Keyword

Leaf


Page- 83

6.1. Configuration ROM Definition for Thin Protocol

All nodes that implement the Thin Protocol shall implement the general format configuration ROM in

accordance with ISO/IEC 13213:1994, IEEE1212r, IEEE Std 1394-1995 and this standard.

6.1.1. Power reset initialization

During the initialization process that follows a power reset a device may not be able to respond to

Serial Bus request subactions addressed to parts of configuration ROM. When the device has

insufficient information to make more than the first quadlet of configuration ROM accessible, it shall

return a response value of zero for any read request addressed to FFFF F000 040016 or acknowledge

the request subaction with ack_tardy, as specified by draft standard IEEE P1394a.

Devices shall complete initialization within five seconds of a power reset. Once power reset

initialization completes, the device shall make all mandatory configuration ROM entries available.

The device should not initiate a Serial Bus reset solely as a consequence of the completion of power

reset initialization.

Optional configuration ROM information, such as textual descriptor leaves that identify the device

vendor and model, may not be available when power reset initialization completes. The device may

add this information to configuration ROM as it becomes available and may initiate a Serial Bus reset

to alert other nodes to the changed configuration ROM. The device should initiate a Serial Bus reset if

there is no expectation that other nodes would otherwise become aware of changed configuration

ROM.


Page- 84

6.1.2. Bus information block

All devices shall implement a bus information block at a base address of FFFF F000 040416. For

convenience of reference, the format of the bus information block defined by IEEE Std 1394-1995 is

shown below. The most recent version of the referenced standard or its supplements shall be

referenced.

Figure 6-2 Bus information block format

The first quadlet contains the string “1394” in ASCII as the bus_name value required by the CSR

Architecture.

The irmc bit (abbreviated as m in the figure above) shall be one, if the node is isochronous resource

manager capable; otherwise, the irmc value shall be zero.

The cmc bit (abbreviated as c in the figure above) shall be one, if the node is cycle master capable;

otherwise, this value shall be zero.

The isc bit (abbreviated as i in the figure above) shall be one, if the node supports isochronous

operations; otherwise, this value shall be zero.

The bmc bit (abbreviated as b in the figure above) shall be one, if the node is bus manager capable;

otherwise, this value shall be zero.

The cyc_clk_acc field specifies the node’s cycle master clock accuracy in parts per million. If the cmc

bit is one, the value in this field shall be between zero and 100. If the cmc bit is zero, this field shall be

all ones.

Most significant

Least significant

3116 3316

resv Reserved

node_vendor_ID chip_ID_hi

chip_ID_lo

3916 3416

cyc_clk_acc max_recm c i b


Page- 85

The max_rec field defines the maximum data payload size that the node supports. The data payload

size applies to block write requests or asynchronous stream packets addressed to the node and to block

read responses transmitted by the node.

The maximum data payload is equal to 2 max_rec+1 bytes,

The node_vendor_ID shall be the unique identifier for a company or organization obtained from the

IEEE/RAC:

The chip_ID_hi field concatenated with the chip_ID_lo field form a 40-bit chip ID value. The vendor

specified by node_vendor_ID shall administer the chip ID values. When appended to the

node_vendor_ID value, these shall form a unique 64-bit value called the EUI-64 (Extended Unique

Identifier, 64 bits). These EUI-64 values are, by definition, unique from other EUI-64 identifiers

derived from IEEE/RAC-provided company-ID value.


Page- 86

6.1.3. Root directory

Thin Protocol compliant devices shall implement a Configuration ROM with a root directory. The root

directory shall contain Vendor_ID and Node_Capabilities entries.

The root directory shall also contain at least one Unit_Directory entry defined by this standard.

6.1.3.1. Vendor_ID entry

The Vendor_ID entry is an immediate entry in the root directory that provides the company ID of the

vendor that manufactured the module. Figure 6-3 shows the format of this entry.

Figure 6-3 Vendor_ID entry format

0316 is the concatenation of key_type and key_value for the Vendor_ID entry.

The IEEE/RAC uniquely assigns the vendor_ID to each device vendor, as specified by ISO/IEC

13213:1994.

NOTE:

A recommended convention to provide vendor identification in displayable form is to immediately

follow the Vendor_ID entry with a textual descriptor leaf entry. This associates an ASCII string with

the module vendor. See ISO/IEC 13213:1994 for the specification of textual descriptor leaves;

examples are given in Annex D.

6.1.3.2. Node_Capabilities entry

The Node_Capabilities entry is an immediate entry in the root directory that describes node

capabilities.

Figure 6-4 shows the format of this entry.

Figure 6-4 Node_Capabilities entry format

0C16 is the concatenation of key_type and key_value for the Node_Capabilities entry.

Most significant Least significant

0316 vendor_ID


0C16 node_capabilities


Page- 87

The node_capabilities field contains subfields, specified by ISO/IEC 13213:1994. Devices shall

implement the SPLIT_TIMEOUT register, the 64-bit fixed addressing scheme, the

STATE_CLEAR.lost bit and the STATE_CLEAR.dreq bit and indicate this by setting the spt, 64, fix,

lst and drq bits to one. If no other node_capabilities bits are one, then this results in a value of 00

83C016.

6.1.3.3. Unit_Directory entry

The Unit_Directory entry is a directory entry in the root directory that describes the location of a unit

directory within configuration ROM. There may be more than one unit directory; each unit directory

shall be located by a separate Unit_Directory entry. Figure 6-5 shows the format of this entry.

Figure 6-5 Unit_Directory entry format

D116 is the concatenation of key_type and key_value for the Unit_Directory entry.

The indirect_offset field specifies the number of quadlets from the address of the Unit_Directory entry

to the address of the unit directory within configuration ROM.

6.1.4. Unit directory

The root directory shall also contain at least one Unit_Directory entry defined by the Thin Protocol.

The unit directory shall contain Unit_Spec_ID and Unit_SW_Version entries, as specified by ISO/IEC

13213:1994,

The unit directory shall also contain a Command_Set_Spec_ID entry, a Command_Set entry, a

Command_Set_Details entry, and a Connection_Register entry, as specified by this standard.

The unit directory may also contain a Write_Transaction_Interval entry.

Nodes which support more than 1 command set over a single Thin Protocol unit are required to

implement a command set directory for each command set, unless otherwise noted.


D116 indirect_offset


Page- 88

6.1.4.1. Unit_Spec_ID entry

The Unit_Spec_ID entry is an immediate entry in the unit directory that specifies the organization

responsible for the architectural definition of the device. Figure 6-6 shows the format of this entry.

Figure 6-6 Unit_Spec_ID entry format

1216 is the concatenation of key_type and key_value for the Unit_Spec_ID entry.

00A02D16 is the Unit_Spec_ID obtained by 1394TA from the IEEE/RAC. The value indicates that the

1394TA is responsible for the software interface definition.

6.1.4.2. Unit_SW_Version entry

The Unit_SW_Version entry is an immediate entry in the unit directory that, in combination with the

Unit_Spec_ID, specifies the software interface of the device. Figure 6-7 shows the format of this entry.

Figure 6-7 Unit_SW_Version entry format

1316 is the concatenation of key_type and key_value for the Unit_SW_Version entry.

0A6BE216 is the Unit_Sw_Version value that indicates that the device conforms to this standard.

6.1.4.3. Unit_SW_Details entry

The Unit_SW_Details entry is an immediate entry that, when present in the unit directory, specifies the

details, such as version level, of the Thin Protocol implemented by the device. Figure 6-8 shows the

format of this entry.

Figure 6-8 Unit_SW_Details entry format


1216 00A02D16 (1394TA)


1316 0A6BE216


3D16 016 116 116 016 016 (not used) W


Page- 89

3D16 is the concatenation of key_type and key_value for the Unit_SW_Details entry.

The 2 most significant bytes after the key type/value represent the version number of the command set.

4 bits will represent a digit in hexadecimal, with the most significant byte representing the 2 digits

above the decimal point, and the next significant byte representing 2 decimal places below the decimal

point.

For example, version 1.1 will be represented as 0110xh, and version 2.25 will be represented as

0225xh, where x is the least significant byte of the entry.

The least significant bit, SDU_Write_Order, abbreviated W in the figure above specifies the method in

which this node will issue multiple write transactions to the SDU register space of a receiver node.

This information is useful for receiver nodes to determine how the SDU register space will be written

into. Some receiver nodes can utilize special mechanisms to efficiently transfer SDU data into the

internal buffers, depending on the setting of this bit. A node with this bit set to 1 is assumed to always

operate in the following manner :

Write transactions from this node (sender) to the SDU register space of the receiver node shall be

contiguous in ascending order of address, starting from the lowest address of the SDU register space.

When a page table is used, write transactions from this node (sender) to an area of the receiver node

specified by a element in the page table shall be contiguous in ascending order of address, starting

from the lowest address of the area. A node with this bit set to 0 may issue write transactions from this

node to the SDU register space in any order. In this case, multiple write transactions in the same

address are allowed.

Since this is a newly defined entry for Thin Protocol ver.1.1 and has not been defined in Thin Protocol

ver.1.0, nodes that will communicate with devices implementing Thin Protocol ver. 1.0 shall not

expect this entry to appear.

In other words, a thin protocol unit directory without this entry shall be interpreted as a version 1.0

unit.


Page- 90

6.1.4.4. Command_Set_Spec_ID entry

The Command_Set_Spec_ID entry is an immediate entry that, when present in the unit directory,

specifies the organization responsible for the command set definition for the device. Figure 6-9 shows

the format of this entry.

Figure 6-9 Command_Set_Spec_ID entry format

3816 is the concatenation of key_type and key_value for the Command_Set_Spec_ID entry.

The Command_Set_Spec_ID is an organizationally unique identifier obtained from the IEEE/RAC.

The organization to which this 24-bit identifier has been granted is responsible for the definition of the

command set implemented by the device.

6.1.4.5. Command_Set entry

The Command_Set entry is an immediate entry that, when present in the unit directory and in

combination with the Command_Set_Spec_ID, specifies the command set implemented by the device.


Figure 6-10 Command_Set entry format

3916 is the concatenation of key_type and key_value for the Command_Set entry.

The value of Command_Set shall be specified by the owner of Command_Set_Spec_ID.


3816 Command_Set_Spec_ID


3916 Command_Set


Page- 91

6.1.4.6. Command_Set_Details entry

The Command_Set_Details entry is an immediate entry that, when present in the unit directory,

specifies the details, such as version level of the command set implemented by the device. Figure 6-11

shows the format of this entry.

Figure 6-11 Command_Set_Details entry format

3A16 is the concatenation of key_type and key_value for the Command_Set_Details entry.

The value of Command_Set_Details shall be specified by the owner of Command_Set_Spec_ID and

Command_Set

6.1.4.7. Connection_Register entry

The Connection_Register entry is an immediate entry in the unit directory that specifies the base

address of the device’s Connection Register. Figure 6-12 shows the format of this entry.

Figure 6-12 Connection_Register entry format

7B16 is the concatenation of key_type and key_value for the Connection_Register entry.

The Connection_Register field shall contain the offset, in quadlets, from the base address of initial

register space, FFFF F000 000016, to the base address of the Connection Register for the device. All

device CSR’s shall be located at or above address FFFF F001 000016; therefore the value of the

Connection_Register shall not be less than 400016.


3A16 Command_Set_Details


7B16 Connection_Register


Page- 92

6.1.4.8. Write Transaction Interval entry (optional)

The Write_Transaction_Interval entry is an optional immediate entry in the unit directory that

specifies the minimum time required between write transactions, to this node, to avoid write

transaction retries. Nodes that require a considerable amount of time to process write transactions

should implement this register. Figure 6-13 shows the format of this entry.

Figure 6-13 Write_Transaction_Interval entry format

3C16 is the concatenation of key_type and key_value for the Write Transaction Interval entry.

The Write_Transaction_Interval entry shall contain the interval time value in microseconds.

6.1.4.9. Command_Set_Directory entry (optional)

The command_set_directory entry is an optional directory entry in the unit directory that describes the

location of the command set directory.

Nodes that support more than 1 command set over a single Thin Protocol unit are required to implement a

command set directory for each command set, unless otherwise noted. In this case, the following entries

shall be contained in each of the command set directories, instead of the unit directory.

- Command_Set_Spec_ID entry

- Command_Set entry

- Command_Set_Details entry


Figure 6-14 Command_Set_Directory entry format

D416 is the concatenation of key_type and key_value for the Command_Set_Directory entry.


3C16 Write_Transaction_Interval


D416 Command_Set_Directory


Page- 93

6.2. Instance Directory

Devices supporting the Thin Protocol shall implement the Instance directory currently being

discussed in p(IEEE)1212r or equivalent. The following section describes the entries that

comprise the Instance directory structure. Refer to the p1212r documents, or ANNEX D for

details.

A node's configuration ROM may contain zero or more instance directories, each of which

describes the function(s) implemented by a particular device instantiation within a node.

For DPP devices, the mandatory and optional directory entries for an instance directory are

specified by Table 6-1 (the immediate, CSR offset, directory and leaf offset entry types are

abbreviated as I, C, D and L, respectively).

Table 6-1 Instance directory entries

Directory entry

Name

Type Mandatory Description

Keyword_Leaf L M "Keyword" description of the characteristics of the

device.

Feature_Directory D Additional information about the features of the

device.

Instance_Directory D Pointer to a subsidiary instance directory. The

hierarchical organization of instance directories

denotes functional views of the device.

Unit_Directory D M Pointer to a unit directory that specifies a software

interface (unit architecture) for the device instance.

There may be more than one unit architecture for a

single device instance.

An instance directory shall contain at least one Instance_Directory or Unit_Directory entry and

may optionally contain one Keyword_Leaf entry and multiple Feature_Directory,

Instance_Directory and Unit_Directory entries. The presence of multiple Unit_Directory entries

within an instance directory represents multiple software interfaces to the same instance of a

device function.


Page- 94

6.2.1. Root Directory

6.2.1.1. Instance_Directory entry

Optional and permitted in the root or in instance directories.

This entry points to an instance directory which represents an instance of a particular device

implemented by the node.

D8h Instance_Directory

8 24

Figure 6-15 Instance_Directory entry format


Page- 95

6.2.2. Instance Directory

The Instance_Directory is a directory that represents one instance of a device function. Each

instance directory in turn references one or more unit directories that specify the software

interfaces available to control the device. Instance directories may themselves contain additional

Instance_Directory entries. This is appropriate in cases where a device may be represented in

several ways to the user. For example, a multifunction peripheral may be controllable by an

integrated device driver but might additionally be controllable as separate devices such as a

printer, scanner or FAX. The hierarchical structure of configuration ROM guides the order in

which device drivers are loaded and determines the preferred software interface presentation

format. If a device driver is available for a particular instance, then it should be loaded in

preference to device drivers for any of the subsidiary instances. It should not be presented to the

user unless no driver is available for the parent instance.

6.2.2.1. Keyword_Leaf entry

The Keyword_Leaf entry, when present in a directory, shall specify the location of a keyword leaf

in configuration ROM. The 24-bit immediate value of the Keyword_Leaf entry shall contain the

relative offset of the keyword leaf relative to the location of the Keyword_Leaf entry itself.

99h Keyword_Leaf

8 24

Figure 6-16 Keyword_Leaf entry format

6.2.2.2. Unit_Directory entry

This entry provides a pointer to a directory that is used to identify the software interface (unit

architecture) for a device function. The unit directory may provide additional information that

characterizes the unit. This entry, when used in the Instance directory shall point to a unit directory

that is associated with the given instance.

D1h Unit_Directory

8 24

Figure 6-17 Unit_Directory entry format


Page- 96

NOTE : Instances supporting the Thin Protocol shall point to the unit directory representing the

Thin Protocol.

6.2.3. Keyword Leaf

A keyword leaf is a collection of one or more ASCII keywords that pertain to the parent directory

whose Keyword entry referenced the leaf. A keyword leaf may be a child of the root, in which

case it is likely to be a master index of all keywords present in all the keyword leaves in the

device's configuration ROM. Or, a keyword leaf may be a child of an instance directory, in which

case its keywords describe the functions supported by that particular component.

The format of a keyword leaf is illustrated by Figure 6-18.

Figure 6-18 Keyword leaf format

Individual keywords within a keyword leaf shall be zero-terminated ASCII strings. The character

set for keywords is limited to ASCII 'A' through 'Z' (lowercase is not allowed), '0' through '9' and

hyphen '-'. Neither spaces nor any other characters, printing or nonprinting, shall appear in

keywords. This restricted set has been selected to minimize the potential for the creation of

synonymous keywords. The space is disallowed to avoid the formation of compound keywords.

Implementers should form aggregations of individual keywords that describe their devices.


Page- 97

6.2.3.1. Keyword Usage

This specification has listed the following keywords as the standard format for use within the

Keyword Leaf. The listed keywords are divided into 2 categories; function descriptive keywords

and feature descriptive keywords.

6.2.3.1.1. Function Descriptive Keywords

Function descriptive keywords, listed below are used to describe the basic functionality of DPP

instances.

Function Descriptive Keywords

MULTIFUNCTION

CAMERA

PRINTER

SCANNER

DISPLAY

STORAGE

FAX

COPIER

MODEM

DPP Instances that have descriptions matching any of the function-descriptive keywords listed

above (in terms of initial device discovery and possible user interface purposes) shall include the

matching keyword (s) in their keyword leaf and should avoid use of other synonymous keywords.

This provides a common discovery mechanism for functionality.

For DPP instances in which descriptions do not match any of the above keywords, reference to the

standard keyword list maintained by the 1394TA is strongly recommended as an alternative.

NOTE : An instance with the keyword MULTIFUNCTION is used to represent a grouping of

multiple instances that can be controlled simultaneously by a single device driver. This directory

usually includes sub-instance directories representing the individually controllable instances.

For example, if a printer instance and scanner instance, both individually controllable by separate

drivers in a multi-function node, can also be controlled simultaneously by a SCAN/PRINT unified

driver, then a MULTIFUNCTION instance directory should be present, with a unit directory

offset entry pointing to the SCAN/PRINT unified driver unit. The directory will also include 2

subsidiary instance directories which represent the individually controllable printer and scanner,

thus including a unit directory offset entry pointing to the individual driver units.


Page- 98

On the other hand, a node with a scanner instance and printer instance, which can only be

controlled separately, would not have an instance directory with a MULTIFUNCTION keyword.

6.2.3.1.2. Feature Descriptive Keywords

The following feature-descriptive keywords, standard keywords from the list maintained by the

1394TA, as well as vendor unique keywords may be used to describe the DPP instance.

Feature Descriptive Keywords

STILL-IMAGE

BLACK-WHITE

COLOR

IMPACT

INKJET

LASER

THERMAL

DYE

NOTE : The function descriptive keyword CAMERA is intended to represent the generic class of

cameras, covering both cameras that handle motion data and cameras handling still image data.

Thus, it is strongly recommended that digital still camera instances include the feature-descriptive

keyword STILL-IMAGE in addition to CAMERA, to distinguish them from motion cameras,

such as video camcorders.


Page- 99

Part - II

Direct Print Command Set

(DPC)

Version 1.1


Page- 100

7. Direct Print Command set (DPC)

7.1. Overview

7.1.1. Command Model

This command set employs a push model in which the image source device mainly controls the target

device.

Pull models in which the target devices mainly control the image source devices is out of the scope for

this version of the Direct Print Command set.

Figure 7-1 Push model Direct Print

Im ageSourceDevice

l D igital Cam eral Scannerl etc.

Telling target deviceto prepare for printing

Sending print data to targetdevice and executing

TargetDevice

l Printerl etc.


Page- 101

7.1.2. Command Sequence

The direct print command sequence is made up of two main portions.

The basic sequence is performed in the following order:

Step 1: Negotiation (Query parameters, and Set parameters)

Step 2: Send data (Send image data)

The target device may issue a command to trigger the sequence.

Figure 7-2 Push model Direct Print

Query

Queried Item X

Possible Values forQueried Item X

Selected Value xxxfor Item X

Setting Result

Image Data

Printing Result

Select most suitable Valuefrom obtained Values by theQuery Command

Setting Item X as Value xxx

(1) Negotiation

(2) Send Data

Receiving Image Data

ImageSourceDevice

TargetDevice

Set

Send


Page- 102

7.1.3. Negotiation

Since direct print parameters defined in this command set have mandatory default Values, command

level negotiation is not required in case the DPC output sequence uses these default Values.

On the other hand, in order to utilize the full direct-print capabilities of both the image source device

and the target device, command level negotiations will be necessary to determine and set suitable

direct print parameters.

Figure 7-3 Negotiation between image source device and target device

7.2. Requirements

This command set is most suited to be the upper layer of the Thin Protocol, but other transports are

acceptable.

A symmetrical and reliable transport is required as the lower layer of this command set, and at least

one transport connection between the image source device and the target device is required.

Querying possibleprinting parameter

Responding possibleprinting parameter

Setting suitableprinting parameter

ImageSourceDevice

l DigitalCamera

l Scannerl etc.

TargetDevice

l Printerl etc.


Page- 103

7.3. DPC with Thin Protocol

When the Thin Protocol is used as the transport protocol, the following shall be considered:

l The command set ID value of the “Command set ID” NegInf tag shall be set to 01h, and the

version number value shall be set to 11h for the DPC version 1.1.

l Upon connection with a DPC1.0 node, the version number field of the “Command Set ID”

NegInf tag in the connection packet (connect request and connect response) shall be set to 10h, to

support connection with DPC1.0 nodes and assure backward compatibility.

NOTE:

When the connection is established as DPC version 1.0, new commands defined in DPC version

1.1 (see Annex G) shall not be used. (e.g. StartRequest).

l A connection shall not be established upon receipt of a connect request with an unknown version

field in the “Command set ID” NegInf tag (the device shall issue a connect nack).

l Other command sets shall not be used on the connection that is established for DPC.23

l PID (program ID) is unused in DPC and shall be set to 0000h.

7.4. Command Set Categorization

7.4.1. Command Set Components

The components that make up the command set are commands, responses, command parameters, and

response parameters. A command is considered complete when the issuing device receives a response,

unless otherwise noted.

Command issuing device command receiving device

Command issuing device command receiving device

Figure 7-4 Command Set Components

23 If the application uses two command sets at the same time, then two thin connections shall be

established for each command set.

CommandCommand parameter

ResponseResponse parameter


Page- 104

7.4.2. Command Categorization

Defined commands are composed of the following three types.

Table 7-1 Command categorization

command

(1)Generic command: DPC defined commands that are used for purposes other

than negotiation.

Specific parameters are defined for commands and

corresponding responses

(2)Negotiation command: DPC defined commands used for negotiation. Item and

Value are used for the parameters that are common to every

negotiation command and response.

(3)Vendor Unique command: Commands not defined in DPC.

Any command(s) other than the Generic Commands and Negotiation Commands specified in this

specification is (are) regarded as vendor unique Command(s). A DPC device shall respond with an

unsupported command status response to any unsupported command, such as unknown vendor unique

commands. Other unsuccessful command execution shall return an error status response. When an

error status response is received, the receiver of the response shall not retry the command indefinitely.

The following table shows the different packet formats defined in this specification.

Table 7-2 Packet Format categorization

Command Command/Response

packet format

Parameter packet

format

Parameter contents

format

Generic

command:

Generic

Command/Response

Packet format

Generic

Command/Response

Parameter format

Command dependent

Negotiation

command:

Negotiation

Command/Response

Packet format

Item Unit format Value Content Block

format


Page- 105

The packet formats shall be used in the following packet encapsulation hierarchy.

Figure 7-5 Command and Response Packet Encapsulation Hierarchy

Command /Response level

ex: generic/negotiation commands

Parameter level

ex: generic parameters, Item Units

Parameter contents level

ex: generic command parameter values,

Item Unit values

: parameter area for each level

Command/Response

Packet format

Parameter packet

format

Parameter Contents

format


Page- 106

7.4.3. Command List

Table 7-3 shows the list of commands defined in this specification.

Table 7-3 Command list

Category Command Meaning

GetQueryItem Querying the capabilities of the

target device

Negotiation

command

The command used for

negotiation. Parameter

and response of

negotiation command

employ Item and Value.

SetQueryItem Setting the actual capability

condition of the target device

Send24 Sending 1 image data to the target

device

Cancel Canceling the previous command

being executed

GetStatus Obtaining the status of the target

device

Generic

command

Any command excluding

the negotiation command.

Parameter and response of

generic command do not

employ Item and Value.

SendStatus Sending the status of the target

device

StartRequest Issue a request to the image

source device to start negotiation

and data transfer of the DPC

sequence.

24 In the case of a printer implementation, this command may be considered as a basis for print

execution triggering.


Page- 107

7.5. Negotiation Command

The two commands used for negotiation are:

GetQueryItem Command

SetQueryItem Command

The same commands are used for negotiation of all items.

Commands and command parameters used to send and receive Item and Value information in

negotiation commands are designed to use the packet format shown below. The command and

command parameter packet format structures are common between command and responses.

The command/response parameter for negotiation commands is called Query Unit List and consists of

Item and Value information.

Figure 7-6 Negotiation Command and Command Parameters

Negotiation

Command

/Response

Image

Source

Device

Image

Target

Device

Query Unit List

(Item/Value

Information)


Page- 108

Parameters for commands, and return values for responses of negotiation commands employ an Item

and Value structure.

Table 7-4 Item and Value

Item: Category of parameter group negotiable between image source device and target

device.

ex) ImageSize

Value: Each parameter of Item representing a specific capability. Value is a subordinate to

Item.

ex) VGA, XGA, …

In the case of a negotiation command, the image source device and target device play the roles of

command issuing device and command responding device, respectively. Item and Value are defined to

be common to all negotiation commands.

7.5.1. Implementation Level in Negotiation Command

Command, Item and Value of negotiation command has the following implementation levels.

7.5.1.1. Implementation Level of Negotiation Command

DPC devices shall implement DPC defined commands as the following table indicates, according to

whether the device is an image source device or a target device.

Table 7-5 Implementation level of Negotiation Command

Image source device: May select and use the necessary command from the DPC defined

commands

Target device: Shall understand all the DPC defined commands specified in this

specification and shall respond with the actual condition of implemented

capability


Page- 109

7.5.1.2. Implementation Level of Item

All Items specified in this specification are “Basic Items”.

A DPC device shall understand the meaning of Basic Item and shall respond with the actual condition

of implemented capability. An image source device may query a target device about (an) Item(s), and

the target device shall respond to the image source device with the Value(s) representing the capability

of the queried Item(s).

Table 7-6 Implementation level of Item

Image source device : May select and use the necessary command out of the Basic Item.

Target device: Shall understand all the Basic Items specified in this specification and

shall respond with the actual condition of implemented capability of

that Item.

All Items other than the Basic Items specified in this specification are regarded as vendor unique

Items.

A DPC target device shall respond with “Not supported Item” (See 7.5.4.1) to a command which

includes unknown Items such as unknown vendor unique Items.


Page- 110

7.5.1.3. Implementation Level of Value

Value has the following two implementation levels.

Table 7-7 Implementation level of Value

(1) Mandatory Value Every DPC target device shall be capable of supporting Mandatory

Values. DPC target devices shall include the Mandatory Value of the

corresponding Item in the response to the Item query from the image

source device.

The Mandatory Value is a default setting for DPC devices, so the target

device shall use this Value if a specific Value for an Item is not set by the

image source device.

(2) Optional Value Implementation of Optional Values defined in this command set is

optional to the target device.

Target devices shall respond with corresponding Values that are

supported, when responding to a query command.

Vendor unique Value(s) subordinated to Basic Items is (are) available. DPC image source devices shall

ignore any unknown Value such as unknown vendor unique Value. DPC target devices shall respond

with “Not supported Value” (See 7.5.4.2) to a command which includes an unknown Value such as

unknown vendor unique Value.

Vendor unique Values that have the same meanings as Mandatory and/or Optional Values specified in

this specification shall be avoided to ensure interoperability.


Page- 111

7.5.2. Item/Value Listing

The table below shows the Items and Values described in this specification.

Table 7-8 Item/Value list

Item Value

Item Implementation

Level

Meaning Value Implementation

Level

rawRGB Mandatory

D-rawRGB Optional

Exif Optional

JFIF Optional

ImageFormat Basic Image data

format

(-----) Vendor Unique

VGA Mandatory

SVGA Optional

XGA Optional

SXGA960 Optional

SXGA1024 Optional

XY Optional

maxXY Optional

(Get only)

ImageSize Basic Image data

size


Device

Dependent

Mandatory

Portrait Optional

Landscape Optional

Mirrored-

Portrait

Optional

Mirrored-

Landscape

Optional

Output

Orientation

Basic Output

direction


Continued to next page


Page- 112

Continued from previous page

Item Value

Item Implementation

Level

Meaning Value Implementation

Level

Device

Dependent

Mandatory

Small Optional

Medium Optional

Large Optional

Sizing Basic Sizing the

image within

the output

media


Device

Dependent

Mandatory

Left Optional

Center Optional

Right Optional

PosX Basic Position of

image within

the output

media


Device

Dependent

Mandatory

Top Optional

Center Optional

Bottom Optional

PosY Basic Position of

image within

the output

media


1 Mandatory

2-255 Optional

NumPics Basic Number of

images per

output media (-----) Vendor Unique

1 Mandatory

2-65535 Optional

NumCopies Basic Number of

output media


VendorUnique

Item

Basic vendor unique

Item


(Get only)


Page- 113

7.5.3. Negotiation Command/Response Packet Format

All commands and responses share a common packet format, as shown below.

Figure 7-7 Negotiation Command/Response Packet Format

F: Length Format

0b = Short format

The valid packet length for this command/response packet will be shown in

the 8 bit Length field. The Length32 field shall not be present in this case.

1b = Long format


the 32 bit Length32 field. The Length32 field shall be present in this case.

OPT: Optional Attributes

The meaning of this field is different between commands and responses.

For commands, this field acts as a Req field.

Req: Requested (queried) number of Items

0h = Number of Items specified in the Count field.

1h = All Basic Items

2h = All vendor unique Items

3h = All available Items

For responses, this field acts as a Status field.

Status: Status response

0h = No error

1h = Error

21 3

CmdCode Count LengthLDVOPTF

1 1 8 8 8

Length32(present when F=1)

Command Packet Contents


Page- 114

V: Vendor Unique Flag

Negotiation commands shall set this field to 0.

0b = DPC defined Commands

1b = Vendor Unique Commands

D: Direction

0b = Command packet

1b = Response packet

L: Level

0b = Command/Response Level

Commands and Responses shall set this field to 0.

CmdCode: Command code

Values are dependent on each command.

Count: Content count

The number of command packet content blocks following this field.

Length: Packet Length

The length of this Command/Response packet structure beyond this field, in bytes.

The maximum packet length allowed when using this field is 255 bytes.

Command and Response packets with a packet length exceeding 255 bytes shall

set the F field to 1, and use the Length32 field.

Length32: 32 bit Packet Length


The maximum packet length allowed when using this field is 4,294,967,295 bytes.

When this field is used, the value of the Length field is invalid. Command and

Response packets with a packet length less than 255 bytes shall set the F field to 0,

and use the Length field

Command Packet Contents: Contents

The Query Unit List shall be encapsulated in this field.


Page- 115

7.5.4. Query Unit List Format

The information included in the Query Unit List will differ between GetQueryItem, and SetQueryItem

commands, and between the command and response.

* For the GetQueryItem command;

The command Query Unit Lists will consist of Item information to be queried.

The response Query Unit Lists will consist of Item information queried, and Value information

for each Item queried.

* For the SetQueryItem command;

The command Query Unit Lists will consist of Item information to be set, and Value

information for each Item to be set.

The response Query Unit Lists may consist of Item information to be set, and result Value

information for each Item.

A Query Unit List is comprised of 1 or more Item Units.

An Item Unit follows the Item Unit format, and is comprised of Item information, and corresponding

Value Content Blocks (when necessary).

A Value Content Block follows the ValueContent format, and is comprised of Value information.

Figure 7-8 Negotiation Command Parameters – Query Unit List

Item Unit

Value

Content

Block

Negotiation

Command/ Response

Query Unit

List

Command/Response level

Parameter level



Page- 116

Since multiple Item information and multiple Value information blocks are allowed in one Query Unit

List, the Query Unit List may actually be a list consisting of multiple Item Units.

Figure 7-9 Negotiation Command Parameters – Query Unit List

Item Unit 1

Value Content

Block 1

Negotiation

Command / Response

Value Content

Block m

Item Unit n

Value Content

Block 1

Value Content

Block m

Multiple Value Content

Blocks may exist in a

GetQueryList response

Query Unit

List

Command/Response level

Parameter level



Page- 117

7.5.4.1. Item Unit Format

All Item Units share a common packet format, as shown below.

(1) DPC Defined Items (V = 0)

Figure 7-10 Item Unit Format of DPC Defined Items

F: Length Format

0b = Short format

The valid packet length for this Item Unit packet will be shown in the 8 bit

Length field. The Length32 field shall not be present in this case.

1b = Long format

The valid packet length for this Item Unit packet will be shown in the 32 bit

Length32 field. The Length32 field shall be present in this case.



For commands, this field is unused and shall be filled with 0.

For responses, this field acts as a Status field.


0h = No error

1h = Error

2h = Not supported Item


DPC defined Items shall set this field to 0.

0b = DPC defined Items

1b = Vendor unique Items

21 3

ItemCode Count LengthLDVOPTF

1 1 8 8 8


Value Content Block


Page- 118

D: Direction

0b = Command packet


L: Level

1b = Parameter level

Item Units shall set this field to 1.

ItemCode: Item code

This field will specify a Basic Item.

Table 7-9 Item Code

Value Meaning (Item)

1h VendorUniqueItem

2h ImageFormat

3h ImageSize

4h OutputOrientation

5h Sizing

6h PosX

7h PosY

8h NumPics

9h NumCopies


The number of Value Content Blocks that follow this field.


The length of this Item Unit packet structure beyond this field, in bytes. The

maximum packet length allowed when using this field is 255 bytes. Command and

Response packets with a packet length exceeding 255 bytes shall set the F field to

1, and use the Length32 field.


Page- 119

Length32: 32 bit Packet Length

The length of this Item Unit packet structure beyond this field, in bytes. The

maximum packet length allowed when using this field is 4,294,967,295 bytes.



and use the Length field.

Value Contents: Contents

The ValueContent shall be encapsulated in this field.

(2) Vendor unique Items (V = 1)

Figure 7-11 Item Unit Format of Vendor unique Items

ItemCode: Item Code

Vendor unique Item codes shall be specified in byte values

CompanyID: Company ID

This 24 bit company ID value provides the company ID of the vendor defining the

particular vendor unique command/response. The company ID value is uniquely

assigned to each vendor by the IEEE.

CompAttrib: Company Attribute

The definition of this 8 bit value is dependent on the vendor represented by the

company ID field.

Usage of all other fields shall be identical to DPC defined Items.

CompanyID

21 3

ItemCode Count LengthLDVOPTF

1 1 8 8 8

CompAttrib


Value Content Block


Page- 120

7.5.4.2. Value Content Block Format

(1) DPC Defined Values (V = 0)

Figure 7-12 Value Content Block Format of DPC Defined Values

F: Length Format

0b = Short format

The valid packet length for this Value Content Block packet will be shown

in the 8 bit Length field. The Length32 field shall not be present in this case.

1b = Long format

The valid packet length for this Value Content Block packet will be shown

in the 32 bit Length32 field. The Length32 field shall be present in this case.



For a command, this field is unused and shall be filled with 0.

For a response, this field acts as a Status field.


0h = No error

1h = Error

2h = Not supported Value

.


DPC defined Values shall set this field to 0.

0b = DPC defined Values

1b = Vendor unique Values

21 3

ValueCode Count LengthLDVOPTF

1 1 8 8 8


Value Contents


Page- 121

D: Direction

0b = Command packet


L: Level

10b = Parameter contents level

Value Content Blocks shall set this field to 10b.

ValueCode: Value code

The meaning of this field is dependent on the Item.


The number of Value contents following this field.


The length of this Value Content Block packet structure beyond this field, in bytes.




Length32: Packet Length32

The length of this Value Content Block packet structure beyond this field, in bytes.





Value Contents: Contents

The meaning of this field is dependent on the Item.


Page- 122

(2) Vendor unique Values (V = 1)

Figure 7-13 Value Content Block Format of Vendor Unique Values

ValueCode: Value Code

Vendor unique Value codes shall be specified in byte values.







company ID field.

Usage of all other fields shall be identical to DPC defined Items.

CompanyID

21 3

ValueCode Count LengthLDVOPTF

1 1 8 8 8

CompAttrib


Value Contents


Page- 123

7.5.5. Negotiation Command Details

There are two commands that comprise the Negotiation command set. This section will describe

details of each of these commands.

Cmd Code:

Defines the Cmd Code field of the command/response packet.

Function:

Describes the functionality of the command.

Command Parameters:

Defines the Command Packet Contents field of the command packet.

Return Parameters:

Defines the Command Packet Contents field of the response packet.

Command/Response Sequence:

Describes the command/response transaction.


Page- 124

7.5.5.1. GetQueryItem

Cmd Code:

01h

Function:

This command is a request for information on Items specified on a Query unit basis.

Command Parameters:

Query Unit List: The Query Unit List for this command will include Item Units specifying

the Item names subject to the information request.

Return Parameters:

Query Unit List: The Query Unit List for this response will include Item Units of the Items

specified, and Value Content Blocks for corresponding Items in the format specified when

the command was issued.


CMD: GetQueryItem

PARA: Query Unit List

RESP: GetQueryItem Response


Usage:

CASE 1: Query Items specified

The command Query Unit List shall be comprised of one or more Item Units specifying

the Item.

The response Query Unit List shall be comprised of one or more Item Units specifying the

Item, and Value Content Blocks with query result Values.

CASE 2: Query all Items, all basic Items, or all vendor unique Items

The command will not require a Query Unit List and the Req field of the command shall

be 1h, 2h, or 3h.

The response Query Unit List shall be comprised of Item Units for all specified Items with

query result Values.


Page- 125

7.5.5.2. SetQueryItem

Cmd Code:

02h

Function:

This command will set Values of Items (1 Value per Item) which are specified by the

command parameter. Values set by this command shall be valid until they are re-set by this

command, or until the lower layer transport session is disconnected.

Command Parameters:

Query Unit List: The Query Unit List for this command will include Item Units specifying

the Item names and corresponding Values subject to Value setting.

In case the Query Unit List consists of multiple Item Units (setting multiple Items in one

SetQueryItem command), the setting order of the Items shall be prioritized by the order in

which the Items appear in the Query Unit List.

Upon an error, the remaining Items appearing after the error Item are not set.

Return Parameters:

Query Unit List: The Query Unit List for this response will include response information

on the Value setting specified when the command was issued, and shall include Item

Units of Items that were not successfully set.


CMD: SetQueryItem


RESP: SetQueryItem Response



Page- 126

7.5.6. Negotiation Item/Value Details

The following sections describe details of the basic negotiation Items, and their defined Values.

Values for each Item will be set to a default Value when the lower level transport layer initiates and

establishes a connection. The default Value for each Item is the Mandatory Value defined for that Item.

ItemCode:

Defines the ItemCode field of the Item Unit packet.

Item Definition:

Describes the Item.

Value Data:

Explains Mandatory Values for each Item, Optional Values for each Item, and defines the

ValueCode and Value contents field of the Value Content Block packet.

Vendor unique Value Data:

Explains vendor unique Values for this Item.


Page- 127

7.5.6.1. VendorUniqueItem

Item Code:

01h

Item definition:

Vendor unique Item supported by the target device. (Supported vendor unique Item(s)

when used with the GetQueryItem command.)

Value Data:

No Mandatory Value is defined for this Item.

Vendor unique Items shall be defined as byte values. This value concatenated with the

company ID shall address a specific vendor unique Item. The definition and Value

formats of the vendor unique Items are beyond the scope of this specification.

Values represent a supported Vendor unique Item in the case of a GetQueryItem response.

There will be no Values present in the case that there are no vendor unique Items

supported. In this case, the Item Unit status of “not supported” shall be returned. A

SetQueryItem command does not exist for this Item.

Figure 7-14 Value Content Format of VendorUniqueItem

CompanyID : This 24 bit company ID value provides the company ID of the vendor

defining the particular vendor unique Item. The company ID value is uniquely assigned

to each vendor by the IEEE.

CompAttrib : The definition of this 8 bit value is dependent on the vendor

represented by the company ID field.

VendorUniqueItem : Vendor unique Item value in byte code.

Vendor unique Value Data:

No vendor unique Values are defined for this Item.

VendorUniqeItem Reserved

CompAttribCompanyID

24 8


Page- 128

7.5.6.2. ImageFormat

Item Code:

02h

Item definition:

Transfer image data format. (Supported image data format(s) when used with the

GetQueryItem command, and the image data format to be set, when used with the

SetQueryItem command.)

Value Data (v=0, ValueCode=1h):

The rawRGB format is subject to mandatory support by the target device. The

corresponding bit shall always be set in the case of a GetQueryItem response, and the bit

shall be set when specifying this Value in a SetQueryItem command.

When set, the following bits represent supported Values in the case of a GetQueryItem

response, and the bits specify a Value to be set in the case of a SetQueryItem command.

Figure 7-15 Value Content Format of ImageFormat

I0 (mandatory) : rawRGB – RGB raw data with sRGB color space.

I1 : D-rawRGB – RGB raw data with sRGB color space accompanied by

dummy data for quadlet allocation

I2 : Exif

I3 : JFIF

Refer to the ANNEX section for details on data format and requirements for each format.

Vendor unique Value Data (v=1, ValueCode =vendor dependent):

Vendor unique Values concatenated with the company ID shall address a specific vendor

unique Value.

I0 I1 I2 I3 Reserved


Page- 129

7.5.6.3. ImageSize

Item Code:

03h

Item definition:

Transfer image size. (Supported image size(s) when used with the GetQueryItem

command, and the image size to be set, when used with the SetQueryItem command.)

Value Data (v=0, ValueCode depends on data type):

VGA (640*480 pixels) size is subject to mandatory support by the target device. The

corresponding bit shall always be set in the case of a GetQueryItem response, and this bit

shall be set when specifying this Value in a SetQueryItem command.

Fixed size (v=0, ValueCode=1h):



Figure 7-16 Value Content Format of ImageSize (Fixed Size)

V (mandatory) : VGA 640 * 480 pixels

S : SVGA 800 * 600 pixels

X : XGA 1024 * 768 pixels

S1 : SXGA960 1280 * 960 pixels

S2 : SXGA1024 1280 * 1024 pixels

V S X S1 S2 Reserved


Page- 130

Fixed numerical size (v=0,ValueCode=2h):

A fixed numerical size shall be represented in an X*Y pixels format, as a set of word

values representing X immediately followed by Y. Values represent a supported size value

in the case of a GetQueryItem response, and the size values specify values to be set in the

case of a SetQueryItem command.

Figure 7-17 Value Content Format of ImageSize (Fixed Numerical Size)

X Value : X pixels (hex values)…maximum=65,535 pixels

Y Value : Y pixels (hex values)…maximum=65,535 pixels

MaxXY numerical size (v=0,ValueCode=3h):

A MaxXY numerical size will represent the maximum allowable size the target device can

handle, in a maxX * maxY pixels format, as a set of word values representing X

immediately followed by Y. Values represent the supported maximum size value in the

case of a GetQueryItem response. A SetQueryItem command does not exist for this Item.

Figure 7-18 Value Content Format of ImageSize (MaxXY Numerical Size)

maxX Value: maxX pixels (hex values)…maximum=65,535 pixels

maxY Value: maxY pixels (hex values)…maximum=65,535 pixels

Vendor unique Value Data (v=1 ValueCode =vendor dependent):


unique Value.

X Value

16

Y Value

16

maxX Value

16

maxY Value

16


Page- 131

7.5.6.4. OutputOrientation

Item Code:

04h

Item definition:

Output orientation of image. (Supported orientation(s) when used with the GetQueryItem

command, and orientation to be set, when used with the SetQueryItem command.)


DeviceDependent (the output orientation will be decided by the target device) is subject to

mandatory support by the target device. The corresponding bit shall always be set in the

case of a GetQueryItem response, and this bit shall be set when specifying this Value in a

SetQueryItem command.


response, and the bits specify a Value to be set in case of a SetQueryItem command.

Figure 7-19 Value Content Format of OutputOrientation

D (mandatory) : DeviceDependent

P : Portrait

The raster direction of the image data corresponds to the short

dimension of the output media

L : Landscape

The raster direction of the image data corresponds to the long

dimension of the output media

MP : Mirrored-Portrait

The horizontally mirrored image of Portrait

ML : Mirrored-Landscape

The horizontally mirrored image of Landscape

Vendor unique Value Data (v=1,ValueCode =vendor dependent):


unique Value.

D P L MPML Reserved


Page- 132

7.5.6.5. Sizing

Item Code:

05h

Item definition:

Output sizing of the image. (Supported sizing(s) when used with the GetQueryItem

command, and the sizing to be set, when used with the SetQueryItem command.)


DeviceDependent (the sizing will be decided by the target device) is subject to mandatory

support by the target device. The corresponding bit shall always be set in case of a

GetQueryItem response, and this bit shall be set when specifying this Value in a




Figure 7-20 Value Content Format of Sizing


S : Small

The image output will be sized small, relative to the “M” and “L”

sizing within the output media.

M : Medium

The image output will be sized smaller than the “L” sizing and larger

than the “S” sizing within the output media.

L : Large

The image output will be sized to fully fit the output orientation

without changes to aspect ratio of the image.



unique Value.

D S M L Reserved


Page- 133

7.5.6.6. PosX

Item Code:

06h

Item definition:

Output X direction (the shorter dimension of the media) positioning of the image.

(Supported positioning(s) when used with the GetQueryItem command, and position to be

set, when used with the SetQueryItem command.)



support by the target device. The corresponding bit shall always be set in the case of a





Figure 7-21 Value Content Format of PosX


C : Center

The image output will be positioned at the center in the X direction.

L : Left

The image output will be positioned towards the left side in the X

direction.

R : Right

The image output will be positioned towards the right side in the X

direction.

Vendor unique Value Data (v=1, ValueCode =vendor dependent):


unique Value.

D C L R Reserved


Page- 134

7.5.6.7. PosY

Item Code:

07h

Item definition:

Output Y direction (the longer dimension of the media) positioning of the image.

(Supported positioning(s) when used with the GetQueryItem command, and position to be

set, when used with the SetQueryItem command.)



support by the target device. The corresponding bit shall always be set in the case of a





Figure 7-22 Value Content Format of PosY


C : Center

The image output will be positioned at the center in the Y direction.

T : Top

The image output will be positioned towards the top in the Y direction.

B : Bottom

The image output will be positioned towards the bottom in the Y

direction.



unique Value.

D C T B Reserved


Page- 135

7.5.6.8. NumPics

Item Code:

08h

Item definition:

Number of images laid out per output unit (page.) (Supported quantity of images laid out

(number of frames) per output unit when used with the GetQueryItem command, and the

number of images to be laid out (number of frames) per output unit, when used with the

SetQueryItem command.)

NOTE:

The Value of this Item does not represent the number of valid image data sets to be actually

transferred, but is the number of images the target device assumes to lay out in one output

unit.

Image transfer(s) to a target device for one output unit is assumed complete when the

image transfer command Send is issued an equal number of times as the Value set for this

Item, or a Send command with an image data length of zero. For example, when the target

device supports a NumPics Value of 9, and the Value of this Item is set to 9, the target

device will either expect a Send command 9 times, or a Send command with an image data

length of 0, as a completion of the image transfer for the output.


A minimum number of 1 is subject to mandatory support by the target device.

A fixed numerical quantity shall be represented as a byte value. Values represent the

supported quantity of images that can be laid out (number of frames) per output unit in the

case of a GetQueryItem response, and the value specifies the quantity of images laid out

(number of frames) per output unit in the case of a SetQueryItem command. This value

field shall be aligned with a quadlet boundary and filled with zeros.

Figure 7-23 Value Content Format of NumPics

NumPics : Number of images laid out per output unit

1 - 255 images (1 is mandatory)

NumPics(1)

8

0

NumPics(2)

NumPics(n)

8 8 8


Page- 136



unique Value.

7.5.6.9. NumCopies

Item I:

09h

Item definition:

Number of units (pages) of the output. (Supported maximum number of units when used

with the GetQueryItem command, and the specified number of units of the output unit,

when used with the SetQueryItem command.)


A minimum number of 1 is subject to mandatory support by the target device.

A fixed numerical quantity shall be represented as a byte value. Values represent the

supported maximum number of units of the output in the case of a GetQueryItem

response, and the value specifies the number of units of an output unit in the case of a


Figure 7-24 Value Content Format of NumCopies

NumCopies : Number of units (pages) of output.

1 - 65535 units (1 is mandatory)



unique Value.

ReservedNumCopies

16


Page- 137

7.6. Generic Command

The Generic commands defined in this specification are;

Send Command

Cancel Command

GetStatus Command

SendStatus Command

StartRequest Command

Generic commands are designed to use the packet structure shown below, where the parameters are

encapsulated within the command/response packet format. Commands, responses, and their

parameters, all have a common format. All commands are defined with a corresponding response,

unless otherwise noted. Some commands may not require parameters, dependent on the commands.

Figure 7-25 Generic Command and Command Parameters

Figure 7-26 Generic Command Responses and Response Parameters

Command

Issuing

device

Command

Receiving

device

Generic

Commands

Command

Parameters

Command

Issuing

device

Command

Receiving

device

Generic Command

Responses

Response

Parameters


Page- 138

7.6.1. Implementation Level in Generic Command

DPC devices shall implement DPC defined commands as explained in the following table. Whether

the device is a command issuing device or command responding device depends on the meaning of the

command and whether the device is an image source device or target device.

Table 7-10 Implementation level in Generic Command

Command issuing device: May select and use the necessary command out of the DPC

defined commands.

Command responding device: Shall be able to understand and execute all the DPC defined

commands specified in this specification.


Page- 139

7.6.2. Generic Command/Response Packet Format


Figure 7-27 Generic Command/Response Packet Format

F: Length Format

0b = Short format


the 8 bit Length field. The Length32 field shall not be present in this case.

1b = Long format


the 32 bit Length32 field. The Length32 field shall be present in this case.


The meaning of this field is different between commands and responses. For the

generic command (D=0), this field shall be filled with 0.

For a response (D=1), this field acts as a Status field.


0h = No error

1h = Execution Error

2h = Command not supported


DPC defined commands shall set this field to 0.



21 3


1 1 8 8 8




Page- 140

D: Direction

0b = Command packet


L: Level

0b = Command/Response Level

Commands and Responses shall set this field to 0.

CmdCode: Command code



The number of command packet contents following this field.












Command Packet Contents: Contents

Command and Response parameters shall be encapsulated in this field.


Page- 141

7.6.3. Generic Command/Response Parameter Format

All generic command parameters and response parameters share a common packet format shown

below.

The presence and content definition of command and response parameters are dependent on the

command.

Figure 7-28 Generic Command/Response Parameter Format

F: Length Format

0b = Short format

The valid packet length for this Parameter packet will be shown in the 8 bit

Length field. The Length32 field shall not be present in this case.

1b = Long format

The valid packet length for this Parameter packet will be shown in the 32 bit

Length32 field. The Length32 field shall be present in this case.


The meaning of this field is different between commands and responses. In the

case of the generic command (D=0), this field shall be filled with 0.

In the case of a response (D=1), this field acts as a Status field.


0h = No error

2h = Parameter not supported


Parameters defined within DPC defined commands shall set this field to 0.

0b = DPC defined parameters

21 3

ParaCode Count LengthLDVOPTF

1 1 8 8 8


Parameter Contents


Page- 142

D: Direction

0b = Command parameter

1b = Response parameter

L: Level

1b = Parameter Level

Command and Response parameters shall set this field to 1.

ParaCode :Parameter code



The number of parameter contents following this field.


The length of this Parameter packet structure beyond this field, in bytes. The

maximum packet length allowed when using this field is 255 bytes. Parameter

packets with a packet length exceeding 255 bytes shall set the F field to 1, and use

the Length32 field.


The length of this Parameter packet structure beyond this field, in bytes. The

maximum packet length allowed when using this field is 4,294,967,295 bytes.

When this field is used, the value of the Length field is invalid. Parameter packets

with a packet length less than 255 bytes shall set the F field to 0, and use the

Length field.

Parameter Contents: Contents

Contents are dependent on commands

NOTE:

When issuing the Generic Command Send (CmdCode 03h – see section 7.6.4.1) with

image data as the parameter contents (ParaCode 01h), the Length or Length32 value of the

Generic Command/Response Parameter Format shall not include the zero padding (00h,

described in Annex C), but only the valid image data length.

On the other hand, the Length or Length32 field of the Generic Command/Response


Page- 143

Packet Format (see section 7.6.2) includes the number of padding values, because the valid

command packet contents includes the padding area.

The sample of the packet including the "4n+2" size Image Data is shown below.

Figure 7-29 Parameter Contents Length

Length32 = 4(n+1) + 8 (length of area)

OPT CmdCode (Send) CountF ReservedV D L=0

Length32 = 4n+2 (length of area)

OPT ParaCode (Image) CountF ReservedV D L=1

00h 00h

Image Data (4n+2)


Page- 144

7.6.4. Generic Command Details

There are 4 commands that comprise the Generic command set. This section will describe the details

of each of these commands.

Cmd Code:

Defines the CmdCode field of the command/response packet.

Function:

Describes the functionality of the command.

Command Parameters:

Defines the Command Packet Contents field of the command packet.

Return Parameters:

Defines the Command Packet Contents field of the response packet.


Describes the command/response transaction.


Page- 145

7.6.4.1. Send

Cmd Code:

03h

Function:

This command will execute the transmission of data.

Command parameters with a Para Code of 1h will represent image data. A Send command

will execute the transmission of one application image data (See Annex C) within the total

DPC image data transfer sequence. A Send command with an image data length of 0 will

terminate the total image data transfer sequence. Image source devices shall issue this

command in this case. Refer to section 7.8 for a detailed explanation of the total image data

transfer sequence.

Image transfer(s) to a target device for one output unit is assumed complete when the

image transfer command Send is issued an equal number of times as the Value set for

NumPics, or a Send command with an image data length of 0. For example, when the

target device supports a NumPics Value of 9 (9 images (frames) per output unit), and the

Value of this Item is set to 9 using the SetQueryItem command, the target device will either

expect a Send command 9 times, or a Send command with an image data length of 0, as a

completion of the image transfer for the output.

Command Parameters:

Para Code: 1h (Image data)

Image data. Refer to the ANNEX section for data formats of image data.

Response Parameters:

None


CMD: Send

PARA: ImageData

RESP: Send Response

PARA:


Page- 146

7.6.4.2. Cancel

Cmd Code:

04h

Function:

This command will cancel the execution of the previous command issued. Both image

source devices and target devices may issue this command. This command does not have a

corresponding response.

For the Cancel command, the command issuing device should use the higher priority

transfer service than normal application data transfer service, if provided by the lower layer.

In the case of using the Thin Protocol as the lower layer, the command issuing device shall

use the Abort service provided as the Thin Session service (See 5.9.5).

Command Parameters:

None


None. (This command does not have a corresponding response.)


CMD: Cancel

PARA: -

No Response


Page- 147

7.6.4.3. GetStatus

Cmd Code:

05h

Function:

This command will request the status of the target device. Image source devices may issue

this command.

Depending on implementation, there will be cases where the response issuing for the

GetStatus command will be delayed until a node has finished transferring data.

Command Parameters:

None


Para Code: 1h (target device status)

Response Parameter Content

The format of the Parameter Content field of the Response Parameter is shown below.

Figure 7-30 Response Parameter Format of GetStatus Command

E : Output media empty

0b = No error

1b = Empty

L : On-line/Off-line

0b = On line

1b = Off line

F : Fatal error

0b = No error

1b = Error

R : Recoverable error

0b = No error

1b = Error


CMD: GetStatus

PARA: -

RESP: GetStatus Response

PARA: Response Parameter

ReservedE L F R


Page- 148

7.6.4.4. SendStatus

Cmd Code:

06h

Function:

This command will provide the status of the device issuing this command. Image target

devices may issue this command. This command does not have a corresponding response.

Command Parameters:

Para Code: 1h (target device status)

Command Parameter Content

The format of the Command Content field of the Command Parameter is shown below.

Figure 7-31 Command Parameter of SendStatus Command

E : Output media empty

0b = No error

1b = Empty

L : On-line/Off-line

0b = On line

1b = Off line

F : Fatal error

0b = No error

1b = Error

R : Recoverable error

0b = No error

1b = Error


None. (This command does not have a corresponding response.)


CMD: SendStatus

PARA: Command Parameter

ReservedE L F R

No Response


Page- 149

7.6.4.5. StartRequest

Cmd Code:

07h

Function:

This command will issue a request to the image source device to start negotiation and data

transfer of the DPC sequence.

Image target devices may issue this command. This command is used in cases where the

image target device wants to initiate the direct print sequence, and trigger the image source

device to start the negotiation and data transfer process.

When an image source device receives this command, it shall issue a response for this

command before starting the negotiation and data transfer process.

It is recommended that image target devices not issue this command while it is clear that

the image source is initiating or under control of the negotiation process, or the data

transfer process.

Command Parameters:

None


None


CMD: StartRequest

PARA: -

RESP: StartRequest Response

PARA: -


Page- 150

7.7. Vendor Unique Command

Vendor unique commands shall use the packet structure shown below, where the parameters are

encapsulated within the command/response packet format. Command and response definition, and

their parameters, are vendor unique.

7.7.1. Vendor Unique Command/Response Packet Format


Figure 7-32 Vendor Unique Command/Response Packet Format


Vendor unique commands shall set this field to 1.









company ID field.

Usage of all other fields shall be identical to DPC defined Generic commands.

CompanyID

21 3


1 1 8 8 8

CompAttrib




Page- 151

7.8. Command Sequence

7.8.1. Command Sequence Overview

Figure 7-33 shows the basic command sequence using this command set.

The basic flow is performed in the following order.

(1) Negotiation (GetQueryItem command + SetQueryItem command)

(2) Data Transfer (Send command)

The command issuing device that waits for the response of the previous command, that it issued, shall

not issue any commands other than the Cancel command, SendStatus command and GetStatus

command. The GetStatus command shall not be sent if the command issuing device is waiting for

another GetStatus response.

Other commands such as the Cancel command, GetStatus command, and SendStatus command, that

are not used for (1) negotiation nor (2) data transfer, may be issued at any time if necessary by the

image source device and/or target device (depending on the command).

Figure 7-33 Basic Command sequence

GetQueryItem

Queried Item X

Possible Values for Queried ItemX

SetQueryItem

Selected Value xxx for ItemX

Setting Result

Send

Image Data

Printing Result

Select most suitable Valuefrom obtained Values byquery command

Setting Item X as Value xxx

Receiving Image Data

ImageSourceDevice

TargetDevice

(2)Data TransferFor a printer, printing mayalso be triggered by theSend command.

(1)NegotiationNegotiation is dispensablefor the Item used withdefault Value.


Page- 152

7.8.2. Negotiation

7.8.2.1. Commands for Negotiation

The negotiation process is composed of the following commands:

GetQueryItem Command

The Image source device may obtain the possible Value(s) of each Item of the

target device using the GetQueryItem command

SetQueryItem Command

The Image source device may select the most suitable Value for each Item and set

the target device with this Value using the SetQueryItem command

The negotiation order of the Items is not defined. The image source device may query and set Items in

the order according to the priority dependent on the individual image source device.

The GetQueryItem command and/or SetQueryItem command are not required for those Items using a

default Value as shown in Figure 7-34.

Figure 7-34 Omission of GetQueryItem and/or SetQueryItem Command

ImageSourc eDevice

TargetDevic e

Item D

DefaultValue

Item A

NegotiatedValue

Item B

DefaultValue

Item C

NegotiatedValue

GetQueryItem and/or SetQueryItemcommands may be omitted for theItem using the Default Value.

GetQueryItem

SetQueryItem

Command

Response

GetQueryItem

SetQueryItem

GetQueryItem

GetQueryItem

SetQueryItem

SetQueryItem

Item E

DefaultValue

GetQueryItem

SetQueryItem


Page- 153

7.8.2.2. Negotiation Sequence

There are three types of negotiation methods shown below:

(1) Sequential Query and Set

(2) Multiple Query and Set

(3) Negotiation-less

7.8.2.2.1. Sequential Query and Set

It is possible to query and set each Item one by one. Figure 7-35 shows the negotiation sequence of this

case. The GetQueryItem command and SetQueryItem command are issued in pair(s) for each Item.

The image source device may issue a GetQueryItem command for one Item to obtain the possible

Values for the Item. Then, the image source device may select the most suitable Value for this Item and

may issue a SetQueryItem command accompanied with the selected Value for this Item. Other Items in

the target device will be set in a sequential manner.

Figure 7-35 Sequential Query and Set

GetQueryItem Item A

For Item A: Value A1,A2,A3, …

Result of SetQueryItem

SetQueryItem Item A: Value An

Pair

GetQueryItem Item B

For Item B: Value B1,B2,B3, …


SetQueryItem Item B: Value Bn

Pair

GetQueryItem Item Z

For Item Z: Value Z1,Z2,Z3, …


SetQueryItem Item Z: Value Zn

Pair

TargetDevice

ImageSourc eDevice


Page- 154

7.8.2.2.2. Multiple Query and Set

It is possible to query multiple Items before setting multiple Items. Figure 7-36 shows the negotiation

sequence of this case.

The image source device may issue a GetQueryItem command for multiple Items to obtain the

possible Values for each Item. Then, the image source device may select the most suitable Value for

each Item and may issue a SetQueryItem command accompanied with the selected Values for multiple

Items.

Figure 7-36 Multiple Query and Set

In the case of setting Items that are dependent upon each other, for instance OutputOrientation and

ImageSize, using multiple query and set, the possible range of Values of one Item may be narrowed

after another dependent Item is set.

GetQueryItem Item A, Item B,

Item Z

For Item A: Value A1,A2,A3, …For Item B: Value B1,B2,B3, …

For Item Z: Value Z1,Z2,Z3, …


SetQueryItem Item A: Value An Item B: Value Bn

Item Z: Value Zn

ImageSourc eDevice

TargetDevice


Page- 155

7.8.2.2.3. Negotiation-less

In the case of using default Values for all Items, no negotiation command is required as shown in

Figure 7-37.

Figure 7-37 Negotiation-less

GetQueryItem

Possible Values forqueried Item

ImageSourceDevice

TargetDevic e

SetQueryItem

Result of set

Every Item is set to

the default Value in

the target device.

All GetQueryItem commands

and S etQueryItem commands

may be omit ted.


Page- 156

7.8.3. Data Transfer

The Data Transfer process is composed of the Send command. The Send command plays the following

two roles according to the included image data length (see section 7.6.4.1.).

Table 7-11 Send Functionality

Expression Meaning Image Data Length(L)

(1) Send (Image) Transmission of one image data block

within the total DPC image transfer

sequence

L > 0

(2) Send (Termination) Termination of the total DPC image

transfer sequence

L = 0

7.8.3.1. One Picture Per One Output Unit

When the NumPics Item is set to 1 (default Value), the image source device may assume that the image

transfer for one output unit completes after every image transfer and may or may not issue the Send

(Termination) command.

If a target device is a printer, it may start printing automatically after one image data transfer completes.

Figure 7-38 shows the data transfer sequence in the case of one picture (one Application image data)

per one output unit (page).

Figure 7-38 One picture per one output unit

ImageSourc eDevice

TargetDevice

Send (Image)IMG #1

Send (Image)IMG #2

Send (Image)IMG #N

Send (Termination)

IMG #1

IMG #2

IMG #N

Printing IMG #1

Printing IMG #2

Printing IMG #N

In case ofPrinter

IMG #1

IMG #2

IMG #N

Response of each commandis omitted.

Image transfer foreach output unit

Send(Termination)command may ormay not be issued.

Total DPP Image DataTransfer Sequence


Page- 157

7.8.3.2. Multiple Pictures Per One Output Unit

When the NumPics Item is set to N (N > 1), image transfers for each output unit complete in the

following cases:

The number of images transferred from the image source device is equal to a multiple of the NumPics

Value.

The Send (Termination) command is issued by the image source device.

If a target device is a printer, then it may start printing automatically in either of the two cases above.

Figure 7-39 shows that the data transfer sequence in the case of multiple pictures (multiple

Application image data) per one output unit (page)

Figure 7-39 Multiple pictures per one output unit

Send (Image)IMG #1

Send (Image)IMG #2

Send (Image)IMG #N

Printing IMG #1..N

In case ofPrinter

IMG #1 IMG #2

IMG #N

Printing IMG #N+1..2N

IMG #N+1 IMG #N+2

IMG #2N

Send (Image)IMG #mN+1

Send (Image)IMG #mN+2

Send (Termination)

Printing IMG #mN+1,mN+2

IMG #mN+1 IMG #mN+2

Where N : Value data of NumPics Itemm : A natural number

Response of each command is omitted.

IMG #1

IMG #2

IMG #N

Send (Image)IMG #N+1

Send (Image)IMG #N+2

Send (Image)IMG #2N

IMG #N+1

IMG #N+2

IMG #2N

IMG #mN+1

IMG #mN+2

ImageSourc eDevice

TargetDevice

Image transferfor each outputunit

Last page mayhave vacant frameif total number ofimages is notmultiple of N.

Send(Termination) commandshall be issued if total numberof images is not multiple of N.



Page- 158

7.8.4. Others

7.8.4.1. Cancel command

The Cancel command may be issued by the image source device and/or target device at any time, if

necessary (see section 7.6.4.2).

7.8.4.2. GetStatus command

The GetStatus command may be issued by the image source device at any time, if necessary (see

section 7.6.4.3).

7.8.4.3. SendStatus command

The SendStatus command may be issued by the target device at any time, if necessary (see section

7.6.4.4).

7.8.4.4. StartRequest command

The StartRequest command may be issued by the target device at any time, if necessary (see section

7.6.4.5).


Page- 159

8. Configuration ROM Definition for DPC

All nodes that implement the “DIRECT PRINT APPLICATION COMMAND SET” shall implement

the general format configuration ROM in accordance with ISO/IEC 13213:1994, IEEE1212r, IEEE

Std 1394-1995 and this standard.

The following entries shall appear in the unit directory of the configuration ROM, and not in

any sub-directories.

8.1. Command_Set_Spec_ID entry


specifies the organization responsible for the command set definition for the target. Figure 8-1 shows




00A02D16 is the Command_Set_Spec_ID obtained by 1394TA from the IEEE/RAC. The value

indicates that the 1394TA is responsible for this command set definition.

8.2. Command_Set entry

The Command_Set entry is an immediate entry that, when present in the unit directory, in combination

with the Command_Set_Spec_ID specifies the command set implemented by the target. Figure 8-2




B081F216 is the Command_Set obtained by the DPC from the 1394TA. The value indicates this

command set.


3816 00A02D16 (1394TA)


3916 B081F216


Page- 160

8.3. Command_Set_Details entry

The Command_Set_Details entry is an immediate entry that specifies the version number and details

of the DPC implemented. Figure 8-3 shows the format of this entry.



In this field, the 2 least significant bits, S and T specify the DPC device type. The least significant bit

T will use 1 to represent an image target device, and the second significant bit S will use 1 to represent

an image source device.


4 bits will represent a digit in hexadecimal, with the most significant byte representing the 2 digits

above the decimal point, and the next significant byte representing 2 decimal places below the decimal

point.


0225xh, where x is the least significant byte including the S bit and the T bit..


3A16 016 116 116 016 016 (not used) S T


Page- 161

Part - III

File Transfer Command Set

(FTC)

Version 1.0


Page- 162

9. File Transfer Command set (FTC)

9.1. Scope

The File Transfer Command set (FTC) is intended to add file transfer capability over the Thin Protocol.

Though this command set is one of the command sets in the DPP concept, FTC will provide generic

file transfer functionality. It can be used for generic purposes including image browsing, file browsing

and other applications based on files.

9.2. Overview

9.2.1. Command Model

The File Transfer Command set (FTC) provides the application that transfers the files between two

devices. The client device issues a command request, and the server device executes the requested

command.

Figure 9-1 Command Model

9.2.2. Requirements

FTC is most suited to be the upper layer of the Thin Protocol, but other transport protocols are

acceptable. A symmetrical and reliable transport is required as the lower layer of this command set,

and at least one transport connection between the server device and the client device is required.

Client

Device

Server

Device

Dir

File List

Get

File Files


Page- 163

9.2.3. FTC with Thin Protocol

When the Thin Protocol is used as the transport protocol, the following shall be considered:

l The Command set ID value of the “Command set ID” NegInf tag shall be set to 02h.

l The Version number value of the “Command set ID” NegInf tag shall be set to 10h for the FTC

version 1.0.

l A connection shall not be established upon receipt of a connect request with an unknown version

field in the “Command set ID” NegInf tag (the device shall issue a connect nack).

l Other command sets shall not be used on the connection that is established for FTC.25

When there are several applications on the device, the PID (program ID) may be used for

distinguishing each application. There are the following restrictions for using the PID.

l If SrcPID is specified in the command packet, DestPID of the response packet shall use the same

value as the SrcPID of the corresponding command packet.

l If DestPID is specified in the command packet, SrcPID of the response packet shall use the same

value as the DestPID of the corresponding command packet.

The value of the PID field depends on the implementation of the application.

25 If the application uses two command sets at the same time, then two thin connections shall be

established for each command set.


Page- 164

9.3. FTC Format

9.3.1. FTC Structure

The FTC format is composed of the number of attributes and those attributes. Each attribute includes

the attribute name, attribute length, attribute type, attribute flag, and attribute value.

Note that in Figure 9-2, the AttValue field shall be continued just after the AFLG field without any

padding. Similarly, any padding shall not be used for the same description in this specification.

Figure 9-2 FTC Format

AttNum: The number of Attribute fields.

AttName: Attribute field name

AttLength: The length of Attribute

AttType: The type of Attribute value field

00h Binary type

01h Character type

06h Time type

others Reserved

AFLG: Supplementary data flag

00h No supplementary data

others Reserved

AttValue: Attribute data

AttNum

Attribute -1

Attribute -2

Attribute -3

AttName

AttLength

AttType

AttValue

AFLG

4bytes

4bytes

2bytes

1byte / 1byte


Page- 165

9.3.2. Attribute Format

The AttName field represents each Attribute field. The AttName field shall be written in ASCII

characters. The definitions of AttName are shown below.

Table 9-1 Attribute Field Name

AttName AttType AttValue

“CMD0” Binary Command code

“RPL0” Character Reply

“ERR0” Binary Error code

“WHT0” Character What (Query category)

“FIL0” Character File name

“DIR0” Character Directory name

“LFL0” Character Long name of the file or directory

“TIM0” Time Time that the file or directory was created or modified

“SIZ0” Binary File data size

“BDY0” Binary File body data

“SWD0” Character Working directory

others Reserved

9.3.2.1. Command Code

AttName: “CMD0”

This attribute is used for specifying the command code. The AttValue field indicates the command

code, and the length of this field shall be 4 bytes. This attribute shall not be included in the command

response.

Figure 9-3 Command Code Attribute

AttName: “CMD0”

AttLength: 00000006h

T: 00h F: 00h

AttValue: command code


Page- 166

The command codes defined in this specification are shown below.

Table 9-2 Command Code

code Command Meanings

00010040h QUERY Querying the server node capabilities (mandatory)

00000000h PUT Put one file in the root directory (mandatory)

00010200h APUT Put one or more files* in the specified working directory

00010001h GET Get one file from the root directory

00010201h AGET Get one or more files from the specified working directory

00010002h DIR Get file list for the specified working directory

00010006h DELETE Delete one file from the root directory

00010206h ADELETE Delete one or more files* from the specified working directory

others Reserved

* One or more directories may be attached to the APUT and ADELETE commands.

9.3.2.2. Reply

AttName: “RPL0”

This attribute is used for specifying the reply for a command successfully executed. The AttValue field

indicates the stored file or directory name, and the length of this field is of variable length. The stored

name shall be written in a character string of 8.3 format. The character ‘/’ shall not be used. It is

strongly recommended that ASCII character strings are used, lower case ‘a’ through ‘z’, and any

non-printable characters are omitted. (e.g. ‘RPLNAME.EXT’).

Figure 9-4 Reply Attribute

AttName: “RPL0”

AttLength

T: 01h F: 00h

AttValue: stored name


Page- 167

9.3.2.3. Error

AttName: “ERR0”

This attribute is used for specifying an error. The AttValue field indicates the error code, and the length

of this field shall be 2 bytes.

Figure 9-5 Error Attribute

The error codes defined in this specification are shown below. When an unknown error code is

returned, the error shall be treated as an undefined error.

Table 9-3 Error Code

error code Meanings

0000h Undefined error

Transport protocol error

0001h Illegal data received

FTC command set error

0010h Illegal attribute received

0011h Unsupported command received

File system error

0020h File system is full

0021h No corresponding file or directory

0022h Permission denied

Application error

0031h Abort execution of a command

others Reserved

AttName: “ERR0”


T: 00h F: 00h AttValue: error code


Page- 168

9.3.2.4. What (Query Category)

AttName: “WHT0”

This attribute is used for specifying the query category in the QUERY command. The AttValue field

indicates the category name, and the length of this field shall be 4 bytes.

Figure 9-6 What (Query Category) Attribute

In this specification, only “RCMD” is defined as the category name. This category name is used for

requesting the capability of the command execution.

9.3.2.5. File Name

AttName: “FIL0”

This attribute is used for specifying the file name. The AttValue field indicates the file name, and is of

variable length. The file name shall be written in a character string of 8.3 format. The character ‘/’

shall not be used. It is strongly recommended that ASCII character strings are used, lower case ‘a’

through ‘z’, and any non-printable characters are omitted. (e.g. ‘FILENAME.EXT’).

Figure 9-7 File Name Attribute

AttName: “WHT0”


T: 01h F: 00h

AttValue: category name

AttName: “FIL0”

AttLength

T: 01h F: 00h

AttValue: file name


Page- 169

9.3.2.6. Directory Name

AttName: “DIR0”

This attribute is used for specifying the directory name. The AttValue field indicates the directory

name, and is of variable length. The directory name shall be written in a character string of 8.3 format.

The character ‘/’ shall not be used. It is strongly recommended that ASCII character strings are used,

lower case ‘a’ through ‘z’, and any non-printable characters are omitted. (e.g. ‘DIRNAME.EXT’).

Figure 9-8 Directory Name Attribute

9.3.2.7. Long Name Attribute

AttName: “LFL0”

This attribute is used for specifying the long name of a file or directory. The AttValue field indicates

the long name, and is of variable length. The character code and format of the long name is not defined

in this specification.

Figure 9-9 Long Name Attribute

AttName: “DIR0”

AttLength

T: 01h F: 00h

AttValue: directory name

AttName: “LFL0”

AttLength

T: 01h F: 00h

AttValue: long name


Page- 170

9.3.2.8. Time

AttName: “TIM0”

This attribute is used for specifying the time that the file or directory was created or modified. The

AttValue field indicates the time, and the length of this field shall be 14 bytes. The time shall be written

in the following format.

Numeric ASCII character string in ‘YYYYMMDDhhmmss’ format

YYYY Year, A number from 0000 to 9999.

MM Numeric month, A number from 01 to 12.

DD Day, a number from 01 to 31.

hh Hour, a number from 00 to 23.

mm Minutes, a number from 00 to 59.

ss Seconds, a number from 00 to 59

(e.g. ‘Jan 2, 1999 03:40:50’ is described as ‘19990102034050’).

Figure 9-10 Time Attribute

9.3.2.9. File Size

AttName: “SIZ0”

This attribute is used for specifying the file size. The AttValue field indicates the file size, and the

length of this field shall be 4 bytes. The size shall be written in 4 bytes.

Figure 9-11 File Size Attribute

AttName: “TIM0”


T: 06h F: 00h

AttValue: time

AttName: “SIZ0”


T: 00h F: 00h

AttValue: file size


Page- 171

9.3.2.10. File Data

AttName: “BDY0”

This attribute is used for specifying the file data. The AttValue field indicates the file data, and the

length of this field is of variable length.

Figure 9-12 File Data Attribute

9.3.2.11. Working Directory

AttName: “SWD0”

This attribute is used for specifying the working directory with absolute path. The AttValue field

indicates the working directory, and the length of this field is of variable length. Each directory name

shall be written in a character string of 8.3 format and separated with the ‘/’ character. The character ‘/’

shall not be used within each directory name. It is strongly recommended that ASCII character strings

are used, lower case ‘a’ through ‘z’, and any non-printable character are omitted (e.g.

‘/PARENT/CHILD/’).

Figure 9-13 Working Directory Attribute

AttName: “BDY0”

AttLength

T: 00h F: 00h

AttValue: file data

AttName: “SWD0”

AttLength

T: 01h F: 00h

AttValue: working directory


Page- 172

9.3.3. Directory Structure

The directory structure is expressed as the list of attributes shown below. The attributes shall appear in

the order as shown below, but attributes with ‘(optional)’ can be omitted.

Figure 9-14 Directory Structure

File name (mandatory)AttName: “DIR0”

AttLength

T: 01h F: 00h

AttValue: ex.“DIRNAME.EXT”

Long file name (optional)AttName: “LFL0”

AttLength

T: 01h F: 00h

AttValue: ex.“Long dir name.example”

Time (optional)AttName: “TIM0”


T: 06h F: 00h

AttValue: ex.“19990102034050”


Page- 173

9.3.4. File Structure

The file structure is expressed as the list of attributes shown below. The attributes shall appear in the

order as shown below, but attributes with ‘(optional)’ can be omitted.

Figure 9-15 File Structure

File name (mandatory)AttName: “FIL0”

AttLength

T: 01h F: 00h

AttValue: ex.“FILENAME.EXT”

Long file name (optional)AttName: “LFL0”

AttLength

T: 01h F: 00h

AttValue: ex.“Long file name.example”

Time (optional)AttName: “TIM0”


T: 06h F: 00h

AttValue: ex.“19990102034050”

File data size (optional)AttName: “SIZ0”


T: 00h F: 00h

AttValue: length of file body (4byte)

File data body

(mandatory except DIR response,

not included for DIR response)

AttName: “BDY0”

AttLength

T: 00h F: 00h

AttValue: File data


Page- 174

9.4. FTC Command Format

9.4.1. General Rule

9.4.1.1. Working Directory

When the client device specifies the working directory by using the “SWD0” attribute, the server

device shall execute the command on the specified working directory. If the working directory is not

available on the server node, then the server node shall issue the command response with “ERR0”

attributes (see section 9.4.1.2).

When the client device does not specify the working directory, the server device shall execute the

command on the root directory. The actual position of the root directory depends on the

implementation of the server device. There are command requests that cannot include the working

directory attribute such as PUT, GET, and DELETE. These commands shall always be executed on the

root directory.

These rules apply to the same description of the root directory and the working directory in this

specification.

9.4.1.2. Error Response

When the device receives an unsupported attribute, the attribute shall be ignored.

When the server node receives an unsupported command, illegal attribute value or can not execute the

command, the device shall issue the command response with “ERR0” attributes (see section 9.3.2.3).

Figure 9-16 Error Response

Note that when the command is not executed completely, the response packet shall be sent as the nack

response of the lower layer protocol (e.g. Command type of Thin Protocol indicates Command

response nack).

AttNum: 0001h

Command (mandatory)AttName: “ERR0”


T: 00h F: 00h error code


Page- 175

9.4.2. QUERY

9.4.2.1. QUERY Request

This format shall be used for querying the commands supported by the server device. The attributes

shall appear in the order as shown below.

Figure 9-17 QUERY Request

9.4.2.2. QUERY Response

This format shall be used for response to QUERY commands. When an error occurs or unknown

AttValue is included in the “WHT0” attribute, the server device shall send a response of error with an

“ERR0” attribute (see section 9.4.1.2). Otherwise, the server device shall send a response with the

following format.

Figure 9-18 QUERY Response

AttNum: 0002h

Command (mandatory)AttName: “CMD0”


T: 00h F: 00h

AttValue: 00010040h

Category to be queried (mandatory)AttName: “WHT0”


T: 01h F: 00h

AttValue: “RCMD”

AttNum: 0001h

Command (mandatory)AttName: “BDY0”

AttLength

T: 00h F: 00h

Command execution capability tag

Number of files tag

Supported command tag

AttValue


Page- 176

The AttValue field of the QUERY response is composed of some tags. Each tag format is shown

below.

Figure 9-19 Tag Format

Command execution capability tag:

This tag describes a capability of command execution.

tag: 20h

option: 0001h - the server device can execute two or more commands while the Thin connection

is established.

The option length of this tag shall be set to 0002h, since the length of this option is 2 bytes.

When the server device doesn’t have the above capability, this tag shall not be included in the AttValue

field.

Number of files tag:

This tag describes how many file and/or directory structures may be contained in APUT command,

AGET command, and ADELETE command.

tag: 21h

option: Number of files that may be contained in one command (0000h - FFFFh).

The option length of this tag shall be set to 0002h, since the length of this option is 2 bytes.

The default value of this tag is 0001h. When this tag is not included in AttValue field, this value is

treated as 0001h.

Supported command tag:

This tag describes the supported command list.

tag: 22h

option: Enumerate the supported commands.

The Supported command is described with an AttValue of “CMD0” (see Table 9-2 of section 9.3.2.1).

The option length of this tag shall be set to (the number of option)*4, since the length of each option is

4 bytes, which is the same as the command code length.

QUERY and PUT commands are mandatory to support. So even if this tag is not included in the

AttValue field, the client device can issue QUERY and PUT commands.

option length

(2byte)

optiontag

(1byte)

option …


Page- 177

9.4.3. PUT

9.4.3.1. PUT Request

This format shall be used for putting one file in the root directory of the server device (see section

9.4.1.1). The attributes shall appear in the order as shown below.

Figure 9-20 PUT Request

9.4.3.2. PUT Response

This format shall be used for response to PUT commands. When an error occurs, the server device

shall send a response of error with the “ERR0” attribute (see section 9.4.1.2). Otherwise, the server

device shall send a response with the following format.

Figure 9-21 PUT Response

The server device may modify the file name. The created file name shall be written in the AttValue of

the “RPL0” attribute.

AttNum



T: 00h F: 00h

AttValue: 00000000h

File structure (mandatory)File structure

( see section 9.3.4 )

AttNum: 0001h

Reply (mandatory)AttName: “RPL0”

AttLength

T: 01h F: 00h

AttValue: created file name


Page- 178

9.4.4. APUT

9.4.4.1. APUT Request

This format shall be used for putting one or more files and/or directories on the server device. In this

command, the client device may specify the working directory of the server node (see section 9.4.1.1).

The client device may attach the directory structure for requesting to create the sub directory.

The maximum number of structures can be known as the value included in the “number of files tag” of

the QUERY response. The client device may attach some structures before sending a QUERY

command, but in this case the server device may not accept all requested structures. If the processing

needs to be completed safely, a QUERY command will be issued before this command.

The attributes shall appear in the order as shown below, but attributes with ‘(optional)’ can be omitted.

Figure 9-22 APUT Request

AttNum

Command (mandatory)

File or directory structure (mandatory)File or directory structure - A

( see section 9.3.3, 9.3.4 )

AttName: “CMD0”


T: 00h F: 00h

AttValue: 00010200h

File or directory structure - B

( see section 9.3.3, 9.3.4 )

Working directory (optional)AttName: “SWD0”

AttLength

T: 01h F: 00h

AttValue: working directory


Page- 179

9.4.4.2. APUT Response

This format shall be used for response to an APUT command. When an error occurs or the requested

directory cannot be created, the server device shall send a response of error with “ERR0” attribute (see

section 9.4.1.2).

When all of the requested structures are completely accepted, the server device shall send a response

with the following format. Each result corresponds with the file or directory structure.

Figure 9-23 APUT Response (When all files are accepted)

AttNum

Result for structure - AAttName: “RPL0”

AttLength

T: 01h F: 00h

AttValue: Stored name of structure- A

Result for structure - BAttName: “RPL0”

AttLength

T: 01h F: 00h

AttValue: Stored name of structure - B


Page- 180

When some of the requested structures can not be accepted, the server device shall send a response

with the following format. Each result (“RPL0” or “ERR0” attribute) corresponds with the file or

directory structure. This packet shall be sent as the nack response of the lower layer protocol.

Figure 9-24 APUT Response (When some files are accepted)

When an error occurs and the server device can no longer execute, the results of the structures that

were not executed may not be included. A sample of an APUT response is shown below.

Figure 9-25 Sample of APUT Response

AttNum

Result for structure - AAttName: “RPL0”

AttLength

T: 01h F: 00h

AttValue: Stored name of structure - A

Result for structure - B (error)AttName: “ERR0”


T: 00h F: 00h ERRORCODE

Num

“CMD0”: APUT

File structure - A

File structure - B

File structure - C

File structure - D

File structure - E

Num

“RPL0” - A

“RPL0” - B

“RPL0” - C

“RPL0” - D

“RPL0” - E

Num

“RPL0” - A

“ERR0” - B

“RPL0” - C

“RPL0” - D

“ERR0” - E

Num

“RPL0” - A

“RPL0” - B

“ERR0” - C

Request

Succeeded in executingall files.(ack response)

Succeeded in executing1st, 3rd and 4th files.Failed in executing the2nd and 5th files.(nack response)

Succeeded in executing1st and 2nd files.Failed in executing the3rd files.Did not execute the 4thand succeeding files.(nack response)


Page- 181

9.4.5. GET

9.4.5.1. GET Request

This format shall be used for getting one file from the root directory of the server device (see section

9.4.1.1). The attributes shall appear in the order as shown below.

Figure 9-26 GET Request

9.4.5.2. GET Response

This format shall be used for a response to a GET command. When an error occurs, the server device

shall send a response of error with “ERR0” attribute (see section 9.4.1.2). Otherwise, the server device

shall send a response with the following format.

Figure 9-27 GET Response

AttNum



T: 00h F: 00h

AttValue: 00010001h

File name attribute (mandatory)AttName: “FIL0”

AttLength

T: 01h F: 00h

AttValue: File name

AttNum: 0001h

File structure

( see section 9.3.4 )File structure (mandatory)


Page- 182

9.4.6. AGET

9.4.6.1. AGET Request

This format shall be used for getting one or more files from the server device. In this command, the

client device may specify the working directory of the server node (see section 9.4.1.1).

The maximum number of attributes can be known as the value included in the “number of files tag” of

the QUERY response. The client device may attach some attributes before sending a QUERY

command, but in this case the server device may not accept all of the requested attributes. If the

processing needs to be completed safely, the QUERY command will be issued before this command.


Figure 9-28 AGET Request

AttNum



T: 00h F: 00h

AttValue: 00010201h

File name attribute (mandatory)


AttLength

T: 01h F: 00h

AttValue: Working directory

AttName: “FIL0”

AttLength

T: 01h F: 00h

AttValue: File name - A

AttName: “FIL0”

AttLength

T: 01h F: 00h

AttValue: File name - B


Page- 183

9.4.6.2. AGET Response

This format shall be used for a response to an AGET command. When an error occurs, the server

device shall send a response of error with “ERR0” attribute (see section 9.4.1.2).

When all of the requested files exist, the server device shall send a response with the following format.

Each result corresponds with the file name attribute.

Figure 9-29 AGET Response (When all files are accepted)

File structure - A


AttNum

File structure - B


File structure - C


File structure for attribute - A

File structure for attribute - B


Page- 184

When some of the requested files or directories don’t exist, the server device shall send a response

with the following format. Each result (file structure or “ERR0” attribute) corresponds with the file

name attribute. This packet shall be sent as the nack response of the lower layer protocol.

Figure 9-30 AGET Response (When some files are accepted)

When an error occurs and the server device can no longer execute, the results of the attributes that

were not executed may not be included. A sample of an AGET response is shown below.

Figure 9-31 Sample of AGET Response

File structure - A


Num

“CMD0”: AGET

“FIL0” - A

“FIL0” - B

“FIL0” - C

“FIL0” - D

“FIL0” - E

Num

File structure - A

File structure - B

File structure - C

File structure - D

File structure - E

Num

File structure - A

“ERR0” - B

File structure - C

File structure - D

“ERR0” - E

Num

File structure - A

File structure - B

“ERR0” - C

Request

Succeeded in executingall files.(ack response)



AttNum

Result for attribute - B (error)AttName: “ERR0”


T: 00h F: 00h ERRORCODE

File structure for attribute - A


Page- 185

9.4.7. DIR

9.4.7.1. DIR Request

This format shall be used for getting the file or directory information. In this command, the client

device may specify the working directory of the server device (see section 9.4.1.1). The attributes

shall appear in the order as shown below.

Figure 9-32 DIR Request

9.4.7.2. DIR Response

This format shall be used for response to a DIR command. The file structure is used for describing the

included file, and the directory structure is used for describing the included directory.

Note that the file structure shall not include the “BDY0” attribute.

Figure 9-33 DIR Response

AttNum



T: 00h F: 00h

AttValue: 00010002h


AttLength

T: 01h F: 00h

AttValue: Working directory

File or directory structure

( see section 9.3.3, 9.3.4 )

AttNum

File or directory structure

Note that the file structure shall not

include the “BDY0” attribute.File or directory structure

( see section 9.3.3, 9.3.4 )


Page- 186

9.4.8. DELETE

9.4.8.1. DELETE Request

This format shall be used for deleting one file that is put on the root directory of the server device (see

section 9.4.1.1). The attributes shall appear in the order as shown below.

Figure 9-34 DELETE Request

9.4.8.2. DELETE Response

This format shall be used for response to a DELETE command. When an error occurs, the server

device shall send a response of error with “ERR0” attribute (see section 9.4.1.2). Otherwise, the server

device shall send a response with the following format.

Figure 9-35 DELETE Response

AttNum

Command (mandatory)

AttName: “CMD0”


T: 00h F: 00h

AttValue: 00010006h

AttNum: 0001h

File name attribute (mandatory)AttName: “FIL0”

AttLength

T: 01h F: 00h

AttValue: File name

Reply (mandatory)AttName: “RPL0”

AttLength

AttValue: Deleted file name

T: 01h F: 00h


Page- 187

9.4.9. ADELETE

9.4.9.1. ADELETE Request

This format shall be used for deleting one or more files and/or directories that are put on the server

device. In this command, the client device may specify the working directory of the server node (see

section 9.4.1.1). The client device may attach the directory name attributes for requesting to delete the

sub directory.

The maximum number of attributes can be known as the value included in the “number of files tag” of

a QUERY response. The client device may attach some attributes before sending a QUERY command,

but in this case, the server device may not accept all requested attributes. If the processing needs to be

completed safely, a QUERY command will be issued before this command.


Figure 9-36 ADELETE Request

AttNum



T: 00h F: 00h

AttValue: 00010206h

File or directory name attribute

(mandatory)


AttLength

T: 01h F: 00h

AttValue: Directory name

AttName: “FIL0”/ “DIR0”

AttLength

T: 01h F: 00h

AttValue: File or directory name -A

AttName: “FIL0” / “DIR0”

AttLength

T: 01h F: 00h

AttValue: File or directory name -B


Page- 188

9.4.9.2. ADELETE Response

This format shall be used for response to an ADELETE command. When an error occurs, the server

device shall send a response of error with “ERR0” attribute (see section 9.4.1.2).

When all of the requested files and directories are completely deleted, the server device shall send a

response with the following format. Each result corresponds with the file or directory name attribute.

Figure 9-37 ADELETE Response (When all files are accepted)

AttNum

Result for attribute - AAttName: “RPL0”

AttLength

T: 01h F: 00h

AttValue: Deleted name of attribute - A

Result for attribute - BAttName: “RPL0”

AttLength

T: 01h F: 00h

AttValue: Deleted name of attribute - B


Page- 189

When some of the requested files or directories can not be deleted, the server device shall send a

response with the following format. Each result (“RPL0” or “ERR0” attribute) corresponds with the

file or directory name attribute. This packet shall be sent as the nack response of the lower protocol.

Figure 9-38 ADELETE Response (When some files are accepted)

When an error occurs and the server device can no longer execute, the results of the attributes that

were not executed may not be included. The sample of an ADELETE response is shown below.

Figure 9-39 Sample of ADELETE Response

AttNum

Result for attribute - AAttName: “RPL0”

AttLength

T: 01h F: 00h

AttValue: Deleted name of attribute - A

Result for attribute - B (error)

AttName: “ERR0”


T: 00h F: 00h error code

Num

“CMD0”: ADELETE

“FIL0” - A

“FIL0” - B

“FIL0” - C

“FIL0” - D

“FIL0” - E

Num

“RPL0” - A

“RPL0” - B

“RPL0” - C

“RPL0” - D

“RPL0” - E

Num

“RPL0” - A

“ERR0” - B

“RPL0” - C

“RPL0” - D

“ERR0” - E

Num

“RPL0” - A

“RPL0” - B

“ERR0” - C

Request

Succeeded in executingof all files.(ack response)




Page- 190

10. Configuration ROM Definition for FTC

All devices that implement the “FILE TRANSFER COMMAND SET” shall implement the general

format configuration ROM in accordance with ISO/IEC 13213:1994, IEEE1212r, IEEE Std 1394-

1995 and this standard.

10.1. Command_Set_Spec_ID entry


specifies the organization responsible for the command set definition for the target. Figure 10-1 shows




00A02D16 is the Command_Set_Spec_ID obtained by 1394TA from the IEEE/RAC. The value

indicates that the 1394TA is responsible for this command set definition.

10.2. Command_Set entry

The Command_Set entry is an immediate entry that, when present in the unit directory, in combination

with the Command_Set_Spec_ID specifies the command set implemented by the target. Figure 10-2




02000016 is the Command_Set obtained by the FTC from the 1394TA. The value indicates this

command set.


3816 00A02D16 (1394TA)


3916 02000016


Page- 191

10.3. Command_Set_Details entry

The Command_Set_Details entry is an immediate entry that specifies the version number and details

of the FTC implemented. Figure 10-3 shows the format of this entry.



In this field, the 2 least significant bits C and S specify the FTC device type. The least significant bit S

is 1 to represent a server device and the second significant bit C is 1 to represent a client device.


4 bits represent a digit in hexadecimal, with the most significant byte representing the 2 digits above

the decimal point, and the next significant byte represents 2 decimal places below the decimal point.


0225xh, where x is the least significant byte of the entry.


3A16 016 116 016 016 016 (not used) C S


Page- 192

Annex


Page- 193

Annex A. DPP Implementation Examples

Annex A.1..A.4 show examples in which a digital still (DS) camera and a DPP printer execute direct

printing. The following are assumed in A.1..A.4 :

l The DS camera and the DPP printer are connected through a 1394 bus.

l The DS camera supports Thin Protocol and DPC as an image source device.

l The DPP printer supports Thin Protocol and DPC as an image output device.

l Using the configuration ROM (unit directory / instance directory), the DS camera has already

detected the DPP printer supporting Thin Protocol and DPC as a target device (See Annex E.)

A.1. DPP Flow Example

Figure A-1 shows an example of a total DPP flow.

This flow applies to any command set implementation using the Thin Protocol.

(1) The application of the DS camera will establish a connection with the DPP printer using the

connect request of the Thin Protocol Service (See 5.8.1).

(2) The application of the DS camera will execute the negotiation and the data transfer to the DPP

printer using DPC. The detailed examples of this step are shown in Annex A-2 and A-3.

(3) The application of the DS camera will close the connection with the DPP printer using the

disconnect request of the Thin Protocol Service (See 5.8.3)

Figure A-1 DPP Flow Example

DPP Printer(Target Device)

DS Camera(Image Source Device)

(1)Connect Request

(2)Negotiation andData Transfer

(3)Disconnect Request

Thin Protocol Service

DPC


Page- 194

A.2. An Example of DPC Sequential Query and Set

In the following example, negotiation is performed using sequential query and set, and the target

device (printer) starts printing after each application image data transfer completes (NumPics = 1).

Figure A-2 An Example of DPC Sequential Query and Set

IMG #1

Status Good

Send IMG #1

IMG #2

Status Good

Send IMG #2

Waiting

IMG #N

Status Good

Send IMG #N

Waiting

GetQueryItem OutputOrientation

OutputOrientation = DeviceDependentLandscapePortrait

SetQueryItem OutputOrientation = Landscape

Status Good


GetQueryItem ImageFormat

ImageFormat = rawRGB ImageFormat=rawRGB(Default)

GetQueryItem ImageSize

ImageSize = VGA,SVGA,XGAImageSize = XGA

GetQueryItem NumCopies

NumCopies = 1..10

SetQueryItem NumCopies = 2

Status Good

NumCopies = 2

Sizing = DeviceDependent(Default)PosX = DeviceDependent(Default)PosY = DeviceDependent(Default)

(Negotiation for the Items using defaultValues are omitted)

Result of Negotiation


ImageSize

NumCopies

ImageFormat

Other Items

Priority of Itemsin image sourcedevice(Order of settingItems)

(SetQueryItem command is omitted)

SetQueryItem ImageSize = XGA

Status Good

OutputOrientation

OutputOrientation= Landscape

Printing 2 copiesof IMG #1

Printing 2 copiesof IMG #2

Printing 2 copiesof IMG #NWaiting

IMG #1

IMG #2

IMG #N



Page- 195

A.3. An Example of DPC Multiple Query and Set

In the following example, negotiation is performed using multiple query and set commands, and the

target device (printer) starts printing after every four application image data transfers complete

(NumPics = 4). In this case, Send (Termination) shall be issued.

Figure A-3 An Example of DPC Multiple Query and Set

IMG #5Status Good

Send IMG #1

Status Good

Send (Termination)

IMG #1

IMG #2

IMG #4


Status Good

GetQueryItem NumPics, ImageSize, NumCopies

NumPics = 1,4,16

ImageSize = VGA,SVGA,XGA,SXGA960,SXGA1024

NumCopies = 1 to 10

Status IllegalRequest for ImageSize

NumPics = 4

GetQueryItem ImageSize, NumCopies

ImageSize = VGANumCopies = 1 to 10

ImageSize = VGA(Default)

SetQueryItem NumCopies = 3

Status Good

NumCopies = 3

ImageFormat = rawRGB(Default)OutputOrientation = DeviceDependent(Default)Sizing = DeviceDependent(Default)PosX = DeviceDependent(Default)PosY = DeviceDependent(Default)

(Negotiation for the Items using defaultValues are omitted)

Result of Negotiation


IMG #3

Send IMG #1

Status Good

Send IMG #2

Status Good

Send IMG #3

Status Good

Send IMG #4

Printing 3 copiescomposed of IMG #1 to #4

IMG #1 IMG #2

IMG #4IMG #3

ImageSize

NumCopies

NumPics

Other Items

IMG #5

Waiting

SetQueryItem NumPics = 4

ImageSize = SXGA960

NumCopies = 3

ImageSize

NumCopies

Set for IamgeSizeusing Default Valueis omitted

Priority of Itemsin image sourcedevice(Order of settingItems)

Printing 3 copiescomposed of IMG #5

The rela t ionship between

NumPics (pictures per output

unit ) and ImageSize in th is

example

N um Pics 1 4 16

VGA Yes Yes Yes

SVGA Yes No No

XGA Yes No No

SXGA960 Yes No No

SXGA1024 Yes No No



Page- 196

A.4. DPC Packet Format Implementation

(1) Issuing GetQueryItem Command

Figure A-4 shows an example of the GetQueryItem command used to query multiple Items at one

time.

Figure A-4 An Example of GetQueryItem Command

(2) Responding to GetQueryItem Command

Figure A-5 shows an example of the GetQueryItem response to the GetQueryItem command shown in

Figure A-4.

In the case of querying all ten Items defined in DPP in one GetQueryItem command (querying

multiple items at one time), the total response packet size of the GetQueryItem command will be

approximately 50 quadlets (200 bytes).

Figure A-5 An Example of GetQueryItem Response

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

GetQueryItemF=0

(Short)OPT=0h (Specified

in the Count)V=0

(DPP Def.)D=0

(Cmd)L=0

(Cmd)CmdCode =

01h(GetQueryItem )Count = 3 Length = 12

1 ImageFormatF=0

(Short)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=1

(Item)ItemCode = 02h(ImageFormat ) Count = 0 Length = 0

2 ImageSizeF=0

(Short)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=1

(Item)ItemCode = 03h(ImageSize ) Count = 0 Length = 0

3F=0

(Short)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=1

(Item)ItemCode =

04h(OutputOrientation )Count = 0 Length = 0

OutputOrientation

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

GetQueryItemF=0

(Short)OPT=0h (Specified

in the Count)V=0

(DPP Def.)D=1

(Rsp)L=0

(Cmd)CmdCode =

01h(GetQueryItem )Count = 3 Length = 80

1F=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=1(Item)

ItemCode = 02h(ImageFormat ) Count = 2 Length = 24

2 1F=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=2(Value)

ValueCode =01h(FormatSelecion)

Count =1 Length = 4

3 2 11

rawRGB

1D-rawRGB

1Exif

1JFIF

Reserved(000000h)

4 3F=0

(Short)OPT=0h(Good)

V=1(VenderUnique)

D=1(Rsp)

L=2(Value)

ValueCode = 01h(FormatName-

VenderUnique)Count = 2 Length = 12

5 4 1 VenderID(24bit) VUAtrb(8bit)6 5 2 Original YCC Format7 6 3 Original YMCK Format

8F=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=1(Item)

ItemCode = 03h(ImageSize ) Count = 3 Length = 28

9 1F=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=2(Value)

ValueCode =01h(FixedSize-

ImageSizeSelection)Count =1 Length = 4

10 2 11

VGA1

SVGA1

XGA

1SXGA

960

1SXGA1024

11 3 XYF=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=2(Value)

ValueCode =02h(FixedNumericalSize-XY)

Count = 2 Length = 8

12 4 1 X1=320 Y1=24013 5 2 X2=160 Y2=120

14 6 MaxXYF=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=2(Value)

ValueCode = 03h(MaxXYNumericalSize)

Count =1 Length = 4

15 7 1 MaxX=1280 MaxY=1280

16F=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=1(Item)

ItemCode =04h(OutputOrientation )


17 1F=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=2(Value)

ValueCode =01h(OrientationSelection)

Count =1 Length = 4

18 2 11D

1P

1L

0MP

0ML

Reserved(000000h)

19 3F=0

(Short)OPT=0h(Good)

V=1(VenderUnique)

D=1(Rsp)

L=2(Value)

ValueCode = 01h(CCW Rotation Angle by

Integer - VenderUnique)

Count =0 Length = 4

20 4 1 VenderID(24bit) VUAtrb(8bit)

VenderUnique

BitPattern

Reserved(000000h)

OutputOrientation

BitPattern

ImageFormat

BitPattern

VenderUnique

ImageSize


Page- 197

(3) Issuing SetQueryItem Command

Figure A-6 shows an example of the SetQueryItem command according to the results of the

GetQueryItem response shown in Figure A-5.

Figure A-6 An Example of SetQueryItem Command

(4) Responding to SetQueryItem Command

a) Succeeding in Setting Items

Figure A-7 shows an example of the SetQueryItem response to the SetQueryItem command

shown in Figure A-6, in the case that the SetQueryItem has been successful.

Figure A-7 An Example of SetQueryItem Response - 1

b) Failing in Setting Items

Figure A-8 shows an example of a SetQueryItem response to the SetQueryItem command shown

in Figure A-6, in the case that the SetQueryItem has been unsuccessful.

Figure A-8 An Example of SetQueryItem Response – 2

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

SetQueryItemF=0

(Short)OPT = 0h

(Good)V=0

(DPP Def.)D=1

(Rsp)L=0

(Cmd)CmdCode =

02h(SetQueryItem)Count = 0 Length = 0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

SetQueryItemF=0

(Short)OPT = 0h V=0

(DPP Def.)D=0

(Cmd)L=0

(Cmd)CmdCode = 02h(SetQueryItem ) Count = 3 Length = 40

1 ImageFormatF=0

(Short)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=1

(Item)ItemCode = 02h(ImageFormat ) Count = 1 Length = 8

2 1F=0

(Short)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=2

(Value)ValueCode =

01h(FormatSelecion)Count =1 Length = 4

3 2 11

rawRGB

0D-rawRGB

0Exif

0JFIF

Reserved(000000h)

4 ImageSizeF=0

(Short)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=1

(Item)ItemCode = 03h(ImageSize ) Count = 1 Length = 8

5 1F=0

(Short)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=2

(Value)ValueCode =

02h(FixedNumericalSize-XY)Count =1 Length = 4

6 2 1 X = 1280 Y = 1000

7F=0

(Short)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=1

(Item)ItemCode =

04h(OutputOrientation )Count = 1 Length = 12

8 1F=0

(Short)OPT=0h

V=1(VenderUnique)

D=0(Cmd)

L=2(Value)



Count =1 Length = 8

9 2 1 VenderID(24bit) VUAtrb(8bit)10 3 2 45 Don't Care

BitPattern

FixedNumericalSize-XY

OutputOrientation

VenderUnique

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

SetQueryItemF=0

(Short)OPT = 0h

(Good)V=0

(DPP Def.)D=1

(Rsp)L=0

(Cmd)CmdCode = 02h(SetQueryItem ) Count = 2 Length = 28

1 ImageSizeF=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=1(Item)

ItemCode = 03h(ImageSize ) Count = 1 Length = 8

2 1F=0

(Short)OPT=2h

(Not Supported)V=0

(DPP Def.)D=1

(Rsp)L=2

(Value)ValueCode =

02h(FixedNumericalSize-XY)Count =1 Length = 4

3 2 1 X = 1600 Y = 1200

4F=0

(Short)OPT=0h(Good)

V=0(DPP Def.)

D=1(Rsp)

L=1(Item)

ItemCode =04h(OutputOrientation )


5 1F=0

(Short)OPT=0h(Good)

V=1(VenderUnique)

D=1(Rsp)

L=2(Value)



Count =1 Length = 8

6 2 1 VenderID(24bit) VUAtrb(8bit)7 3 2 45 Don't Care

FixedNumericalSize-XY

OutputOrientation

VenderUnique


Page- 198

(5) Issuing Send Command

Figure A-9 shows an example of the Send command.

Figure A-9 An Example of Send Command

(6) Responding to Send Command

a) Succeeding in Image Data Transfer

Figure A-10 shows an example of the Send response to a successful Send command shown in Figure

A-9.

Figure A-10 An Example of Send Response – 1

b) Failing in Image Data Transfer

Figure A-11 shows an example of the Send response to an unsuccessful Send command shown in

Figure A-9.

Figure A-11 An Example of Send Response - 2

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

SendF=1

(Long)OPT = 0h V=0

(DPP Def.)D=0

(Cmd)L=0

(Cmd)CmdCode = 03h(Send ) Count = 1 Reserved = 0

Length = 4*(N+2)

1 ImageDataF=1

(Long)OPT=0h V=0

(DPP Def.)D=0

(Cmd)L=1

(Param.)ParaCode = 01h(Image Data) Count = 1 Reserved = 0

2 Length = 4*N3 14 2 Image Data(rawRGB )

… …N+2 N

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

SendF=0

(Short)OPT = 0h

(Good)V=0

(DPP Def.)D=1

(Rsp)L=0

(Cmd)CmdCode = 03h(Send ) Count = 0 Length = 0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

SendF=0

(Short)OPT = 1h

(Illegal Request)V=0

(DPP Def.)D=1

(Rsp)L=0

(Cmd)CmdCode = 03h(Send ) Count = 0 Length = 0


Page- 199

Annex B. DPC Negotiation

B.1. Steps of DPC Negotiation in Sequential Query and Set

Figure B-1 shows an example of negotiation steps using sequential query and set.

One step of query and set determines the value of one Item.

Figure B-1 Steps of DPC Negotiation in Sequential Query and Set

Item A

Query #1 Result ofNegotiationItem A

Set #1

Default Possible Values

Item B

Query #2

Item B

Set #2

Possible Valuesafter Set #1

Item C

Query #3

Item C

Set #3

Value A1

Good

Value B3

Value C1

Good

Good

Value A1

Value B3

Value C1

Value A1

Value A2

Value A3

Value A5

Value A4

Value B1

Value B2

Value B3

Value B5

Value B4

Value C1

Value C2

Value C3

Value C5

Value C4

Value B3

Value B5

Value B4


Value C1

Value C2

Value C3

Value C5

Value C4

Item A

Item B

Item C




Page- 200

B.2. Steps of DPC Negotiation in Multiple Query and Set

Figure B-2 shows an example of negotiation steps using multiple query and set.

One step of query and set determines the values of several Items, but there is a possibility that some

Items are not set depending on the Items set before.

Figure B-2 Steps of DPC Negotiation in Multiple Query and Set

Item AItem BItem CItem D

Query #1 Result ofNegotiationItem A

Item BItem CItem D

Set #1


Item BItem CItem D

Query #2

Item BItem CItem D

Set #2


Item D

Query #3

Item D

Set #3

Value A1

Value B1

Value C1

Value D1

Good

Bad

Set Suspend

Set Suspend

Value B3

Value C1

Value D3

Good

Good

Bad Possible Valuesafter Set #2

Value D4

Good

Value A1

Value B3

Value C1

Value D4

Value A1

Value A2

Value A3

Value A5

Order ofSetting Item

Value A4

Value B1

Value B2

Value B3

Value B5

Value B4

Value C1

Value C2

Value C3

Value C5

Value C4

Value D1

Value D2

Value D3

Value D5

Value D4

Value B3

Value B5

Value B4


Value D3

Value D5

Value D4

Value C1

Value C2

Value C3

Value C5

Value C4

Value D5

Value D4

Item A

Item B

Item C

Item D






Page- 201

Annex C. Image Data Format Details

C.1. Overview

DPC defines the following four image data formats. Categorization of these formats is shown in

Figure C-1.

Table C-1 DPC defined image data formats

Image data

format

Description Implementation Level

(1) rawRGB RGB chunky data Mandatory

(2) D-rawRGB RGB chunky data with dummy channel

for quadlet (32bit) allocation

Option

(3) Exif Exif-JPEG Option

(4) JFIF JFIF Option

Figure C-1 Categorization of Image Data Format

Image Format Raw Data

Image File

Chunky

Planer

3ch(24bit)

4ch(32bit)

rawRGB

D-rawRGB

Exif-JPEG

JFIF

Undefined

Undefined

Compressed

Uncompressed


Page- 202

C.2. rawRGB

Image Data Arrangement

Figure C-2 shows the image data arrangement of the rawRGB image data format representing RGB

chunky data. One pixel’s data is composed of R(Red), G(Green) and B(Blue) channels and is arranged

in order from the starting pixel to the final pixel of raster scanning.

If the total data size, in bytes, is NOT a multiple of four, then fill with 00h for quadlet allocation.

Where Ri: i th Data for red channel (i=1..N)

Gi: i th Data for green channel (i=1..N)

Bi: i th Data for blue channel (i=1..N)

N: Total number of pixels

(i=1 represents the starting pixel and i=N represents the final pixel of

raster scanning)

Figure C-2 Image Data Arrangement of rawRGB

Bit Depth of Image Data

All channels are composed of 8 bit depth image data.

Color Space

Image data shall be designed to be seen in the viewing environment of sRGB shown below.

Table C-2 Viewing Environment of sRGB

Viewing flare 1.0%

Image surround 20%

Illuminance/Luminance level 80cd/cm2

Adaptive white x=0.3127, y=0.3290 (CIE D65)

R1 G1 B1 R2

G2 B2 R3 G3

B3 R4 G4 B4

RN GN BN 00h

………


Page- 203

C.3. D-rawRGB


Figure C-3 shows the image data arrangement of the D-rawRGB image data format representing RGB

chunky data with dummy data for quadlet allocation. One pixel’s data is composed of D(Dummy),

R(Red), G(Green) and B(Blue) channels and is arranged in order from the starting pixel to the final

pixel of raster scanning.

Where Ri: i th Data for red channel (i=1..N)

Gi: i th Data for green channel (i=1..N)

Bi: i th Data for blue channel (i=1..N)

N: Total number of pixels

(i=1 represents the starting pixel and i=N represents the final pixel of

raster scanning)

Figure C-3 Image Data Arrangement of D-rawRGB

Bit Depth of Image Data

All channels including the dummy channel are composed of 8 bit depth image data.

Color Space

Image data shall be designed to be seen in the viewing environment of sRGB shown in Table C-2.

00h(Dummy) R1 G1 B1

00h(Dummy) R2 G2 B2

00h(Dummy) R3 G3 B3

00h(Dummy) RN GN BN

………


Page- 204

C.4. Exif

Image File Format

The image file format shall conform to Exif Ver.2. See the Exif Ver.2 Specification for details.

Additional Specification

Table C-3 shows additional restrictions to the choices defined in the Exif Ver.2 specification.

The target device supporting Exif as the image data format shall be capable of handling Exif image

files with any variations shown in this figure.

Table C-3 Additional Restrictions

Data Format JPEG Compression

Pixel Sampling YCC 4:2:0 or 4:2:2

Restart Marker May be inserted

Image Width,

Image Length

Shall conform to the negotiated value of ImageSize

Color Space sRGB

Byte Order Little Endian or Big Endian

Exif Tag Handling

Several tags defined in the Exif specification need to use the handling guidelines shown in Table C-4.

Table C-4 Exif Tag handling

Tag

Orientation Tag The target device shall use the negotiated value of the DPC defined Image

Orientation Item instead of the Exif defined Orientation tag included in

the Exif image file.

Xresolution Tag,

Yresolution Tag,

ResolutionUnit Tag

The target device may ignore the Xresolution, Yresolution and

ResolutionUnit tags included in the Exif image file.


Page- 205


Figure C-4 shows the image data arrangement for transmitting an Exif image file.

If the total data size in bytes of the Exif image is NOT a multiple of four, fill with 00h for quadlet

allocation.

Where Di: i th data element of Exif image file (i=1..N)

N: Total data size of Exif image file(bytes)

Figure C-4 Image Data Arrangement of Exif

D1 D2 D3 D4

D5 D6 D7 D8

DN-1 DN 00h 00h

………


Page- 206

C.5. JFIF

Image File Format

The Image File Format shall conform to JFIF v1.02. See the JFIF v1.02 Specification for details.

Additional Specification

Table C-5 shows additional restrictions to the choices defined in the JFIF v1.02 Specification.

The target device supporting JFIF as the image data format shall be capable of handling JFIF image

files with any variations shown in this figure.

Table C-5 Additional Restrictions

Data Format JPEG compression

Pixel Sampling YCC 4:2:2 or 4:2:0

DHT marker up to 4

DQT marker up to 3

DQT tables 1 table per DQT or single DQT defines all tables

DHT tables 1 table per DHT or single DHT defines all tables

X,Y density in APP0 recommended to reflect X and Y density in printing if units

for X and Y density is defined.

Color Space recommended use of sRGB in printing


Figure C-5 shows the image data arrangement for transmitting a JFIF image file.

If the total data size, in bytes, of a JFIF image is NOT a multiple of four, fill with 00h for quadlet

allocation.

Where Di: i th data of JFIF image file (i=1..N)

N: Total data size of JFIF image file(bytes)

Figure C-5 Image Data Arrangement of JFIF

D1 D2 D3 D4

D5 D6 D7 D8

DN-1 DN 00h 00h

………


Page- 207

Annex D. Sample Configuration ROM

The Configuration ROM is located at a base address of FFFF F000 040016 within a node’s initial

memory space. The requirements for the general format configuration ROM for devices are specified

in each section. Please refer to the section for detailed definitions. This annex contains illustrations of

a typical configuration ROM for simple DPP devices.

D.1. Basic device Sample

Figure D-1 below shows the bus information block, root directory, unit directory and instance

directory for a printer for a basic Thin Protocol device with DPC.

4 416 ROM CRC

3133393416 (ASCII “1394”)

Node options

Node vendor ID Chip_id_hi

Chip_id_lo

Directory length Root directory CRC

0316 Module_Vendor_ID

8116 Text leaf offset

0C16 Node_Capabilities (0083C016)

D816 Instance Directory offset(2)

D116 Unit Directory offset(4)

2 Instance Directory CRC

9916 Keyword offset (A16)

D116 Unit Directory offset (1)

7 Unit directory CRC

1216 Unit_Spec_ID (00A02D16)

1316 Unit_SW_Version (0A6BE216)

3D16 Unit_SW_Details

3816 Command_Set_Spec_ID (00A02D16)

3916 Command_Set (B081F216)


7B16 Connection register offset(00400016)

2 Keyword Leaf CRC

5016 (‘P’) 5216 (‘R’) 4916 (‘I’) 4E 16 (‘N’)


Page- 208

5416 (‘T’) 4516 (‘E’) 5216 (‘R’) 0016

(zero padding)

8 8 16

Figure D-1 Configuration ROM Sample of Basic Device

Bus information block

The node_options field represents a collection of bits and fields specified in section 6.1.2. The value

shown, 00FF 200016, represents the basic characteristics of a device that is not isochronous capable.

This value is composed of a cyc_clk_acc field with a value of FF16 and a max_rec value of two. The

max_rec field encodes a maximum payload of eight bytes in block write requests addressed to the

device.

Root directory

The Node_Capabilities entry in the root directory, with a key field of 0C16, has a value in which the spt,

64, fix, lst and drq bits are all one. This is a minimum requirement for devices.

The Module_Vendor_ID entry in the root directory, with a key field of 0316, is immediately followed

by a textual descriptor leaf entry, with a key field of 8116, whose indirect_offset value points to a leaf

that contains an ASCII string that identifies the vendor. Although this textual descriptor leaf is not

shown, if it were placed immediately after the 23 quadlets illustrated, the value of indirect_offset

would be 13. See the IEEE1212 specification for an example of a text leaf.

The Unit_Directory entry in the root directory, with a key field of D116, has an indirect_offset value of

one that points to the unit directory.

The Instance_Directory entry in the root directory, with a key field of D816, represents a functional

instance of the node, and has an indirect_offset value of one that points to the Instance directory.

Unit directory

The Unit_Spec_ID and Unit_SW_Version entries, with a key field of 1216 and 1316, respectively, are

expected to define the unit protocol used by this device, which is the Thin Protocol. The

Unit_Sw_Details entry specify the version of the Thin Potocol.

The Command_Set_Spec_ID and Command_Set entries, with a key field of 3816 and 3916,

respectively, are expected to define the command set used by the device, DPC in this case.

The connection_register entry in the unit directory, with a key field of 7B16, has a csr_offset value of

00 400016 in this example, that indicates that the Connection register has a base address of FFFF F001

000016 within the node’s initial memory space.

Instance directory

The Keyword leaf entry, with the key field value of 9916 represents an offset to a keyword leaf, which

contains keywords describing the functionality of the instance. The keyword leaf in this example has


Page- 209

the ASCII text, “PRINTER”. At least one keyword should be included from the keywords listed in

section 6.2.3.1. Other keywords with standard format are available from the 1394TA. It is

recommended that these keywords are used, and other synonymous keywords are avoided. Other

vendor specific keywords may be used.

The following unit directory offset entry will point to the associated unit directory for this instance.


Page- 210

D.2. Multi-Function device sample

Figure D-2 below shows the bus information block, root directory, unit directory and Instance

directory for a Thin Protocol device with multiple (2, in this example) instances. With different

functionality, the instances share the same Thin Protocol with DPC.

4 416 ROM CRC

3133393416 (ASCII “1394”)

Node options


Chip_id_lo









9916 Keyword leaf offset



9916 Keyword leaf offset



1216 Unit_Spec ID (00A02D16)







8 8 16

Figure D-2 Configuration ROM Sample of Multi-function device


Page- 211

Root directory

There are 2 Instance directory entries present, 1 for each functional instance.

Instance directory

2 Instance directories are present for each physical instance. Each Instance directory has a keyword

leaf offset entry, referencing a keyword leaf describing the functionality of the instance. The keyword

leaf is omitted in this figure.

Each Instance directory has a unit directory offset entry to the unit directory of the software interface

that the instance is accessed by.

Though the unit directory offset entries have different offset values of 4 and 1 respectively, they both

reference the same unit directory.


Page- 212

D.3. Multi-Protocol device sample

Figure D-3 below shows the unit directory and Instance directory for a single function device

compliant with the Thin Protocol/DPC, as well as another protocol.


9916 Keyword Leaf offset










7B16 Connection register offset

Unit directory length Unit directory CRC

1216 Unit_Spec ID

1316 Unit_SW_Version

Contents dependent on protocol

2 6 8 16

Figure D-3 Configuration ROM Sample of Multi-Protocol device

Instance directory

The instance directory has a keyword leaf offset entry, referencing a keyword leaf which is describing

the functionality of the instance. The keyword leaf is omitted in this figure.

The 2 unit directory offset entries represent pointers to the 2 unit directories that this instance is

associated with, the offset entry with the value of 2 representing the Thin Protocol unit directory, and

the entry with the value of 8 representing the other unit directory respectively.


Page- 213

D.4. Multi-Command set device (single Thin session) sample

Figure D-4 below shows the unit directory and Instance directory for a single function device,

compliant with the Thin Protocol, and supports both DPC as well as the File Transfer Command Set.


9916 Keyword Leaf offset






7B16 Connection register offset




D416 Command Set Directory offset (1)

3 Command Set directory CRC


3916 Command_Set (for FTC)


2 6 8 16

Figure D-4 Configuration ROM Sample of Multi-Command Set device

Unit directory

The Command_Set_Spec_ID and Command_Set entries appearing in the unit directory and command

set directory, keys 3816 and 3916, are expected to define the command set(s) used by the device.

In this example, the Command_Set_Spec_ID and Command_Set entry appearing in the unit directory

represents DPC. (Though information on each command set, in a multi-command set environment,

usually requires using a command set directory for each command set. DPC requires command set

information to be in the unit directory. )

The connection_register entry in the unit directory, with a key field of 7B16, has a csr_offset value of

00 400016 in this example, that indicates that the Connection register has a base address of FFFF F001

000016 within the node’s initial memory space.

The Command_Set_Spec_ID and Command_Set entry appearing in the command set directory

represents the File Transfer Command Set.


Page- 214

D.5. Multi-Function device (w.unified driver) sample

Figure D-5 below shows the bus information block, root directory, unit directory and Instance

directory for a Thin Protocol device with multiple (2) instances with different functionality,

specifically a scanner and a printer, but instances sharing the same Thin Protocol with DPC.

The difference from example D-2 is that a unified driver is provided to control the 2 instances

simultaneously.

4 416 ROM CRC

3133393416 (ASCII “1394”)

Node options


Chip_id_lo






D116 Unit Directory offset(D16)



9916 Keyword leaf offset (1A16)















Page- 215













4 Keyword Leaf CRC

4D16 (‘M’) 55 16 (‘U’) 4C 16 (‘L’) 54 16 (‘T’)

4916 (‘I’) 46 16 (‘F’) 5516 (‘U’) 4E16 (‘N’)

4316 (‘C’) 5416 (‘T’) 4916 (‘I’) 4F 16 (‘O’)

4E16 (‘N’) 0016

(zero padding)

0016

(zero padding)

0016

(zero padding)

2 Keyword Leaf CRC

5316 (‘S’) 4316 (‘C’) 4116 (‘A’) 4E16 (‘N’)

4E16 (‘N’) 4516 (‘E’) 5216 (‘R’) 0016

(zero padding)

2 Keyword Leaf CRC

5016 (‘P’) 5216 (‘R’) 4916 (‘I’) 4E 16 (‘N’)

5416 (‘T’) 4516 (‘E’) 5216 (‘R’) 0016

(zero padding)

8 8 16

Figure D-5 Configuration ROM Sample of a Multi-function device

Root directory

There is only 1 instance directory offset in the root directory, that points to the instance directory

representing a multifunction instance (controllable by a unified driver).

Instance directory

3 instance directories are present, one “top” instance directory linked to the root directory and the

other 2 “subsidiary” instance directories linked to the “top” instance directory.


Page- 216

The “top” instance directory represents a multifunction instance controllable by a unified driver, and

the 2 subsidiary instance directories represent a scanner and a printer instance. The top instance

directory includes a pointer to a keyword leaf including the keyword “MULTIFUNCTION”, and the

subsidiary instance directory includes pointers to a keyword leaf containing the keywords

“SCANNER” and “PRINTER” respectively.

The instance directory structure, with parent and subsidiary instance directories represent the instance

hierarchy of the node, an individually controllable scanner and printer instance (subsidiary instance

directories) that can both be controlled simultaneously as a multifunction instance (top instance

directory) with a unified driver

Each Instance directory has a unit directory offset entry to the unit directory of the software interface

that the instance is accessed by.

In this example, the unit directory linked to the top instance is different from the unit directory linked

to the 2 subsidiary instance directories.


Page- 217

Annex E. DPP Device Discovery using Configuration ROM

Compliance to the DPP configuration ROM requirements will provide applications with easy and

efficient discovery of DPP devices, especially in an environment where multiple devices of various

functionality and protocol support are connected together. This annex will give an example of a DPP

device enumeration scheme to explain the utilization of the configuration ROM .

The figure below illustrates an example of a multi-node IEEE1394 topology of devices with various

functionality and protocol support.

Figure E-1 Multiple Device Topology

The following devices are connected together in the topology above:

Device A, which is a VCR supporting the AVC/FCP protocol

Device B, which is a Digital Still Camera (DSC) supporting the DPC/Thin Protocol

Device C, which is a printer supporting the SBP-2 protocol

Device D, which is a printer supporting the DPC/Thin Protocol

And

Device E, which is a disk device supporting the DPC/Thin Protocol

All of the 1394 devices above are required to implement the configuration ROM. In addition, the

protocols that are supported by these devices each have separate value definitions of entries in the unit

directory (Unit_Spec_Id, Unit_Sw_Version) that distinguish each protocol.

In this example, it is assumed that all 1394 devices implement the instance directory to store the

functionality information of the device. (DPP devices are required to implement the instance

directory.)

The following explanation will describe an example of an efficient device discovery scheme where

Device B, the DPP DSC will search for the appropriate device to execute a direct-print task and

Device A

Device BDevice C

Device E

Device D


Page- 218

achieve image output from a printer.

Device B will parse the Instance directory of the configuration ROM of each connected device to

retrieve device functionality information, using basic 1394 read transactions.

Device B will first search the Instance directory to look for a “printer” instance. The figure below will

show that the information in the instance directory describes Device C and Device D as “printer”

devices.

Figure E-2 Step1:Printer Device Discovery

Device B has succeeded in sorting out printing devices from other devices that do not match the needs

for the task. However, there is no information, at this stage in the discovery scheme, to indicate

whether Device C or Device D supports the DPP that Device B supports.

Device B will then parse the unit directories of Device C and Device D to see if either of the 2 devices

support DPC / Thin Protocol. In this case, Device D is the device with a unit directory representing

DPP, whereas Device C supports a different protocol.

Figure E-3 Step2: DPP Printer Device Discovery

Device A

Device BDevice E

Device D

Printer

VCR

DSC

Device C

PrinterDisk

Device A

Device BDevice E

Device D

Printer

DPP

VCR

DSC

DPP

Device C

Printer

SBP2Disk


Page- 219

Device B has now successfully discovered the appropriate device to achieve image output with, and

supports DPP. Device B will further parse the DPP unit directory of Device D to get the entry

information (Connection register address) for DPP.

Device B will utilize DPP to make a connection with Device D.

The figure below shows the 2 types of device information presented in the configuration ROM (i.e.

ROM level device discovery) for each device. Other information contained in the configuration ROM

(such as bus information, node capabilities and vendor information) are omitted to make the

explanation simple.

Figure E-4 Configuration ROM Information for Device Discovery

Though the example given describes the discovery scheme by parsing the instance directories to sort

the device functionality first, there are no rules as to the order in which the ROM should be parsed. If

Device B were to parse the unit directories first and initially sort out devices supporting DPP, it would

first distinguish Device D and Device E, instead of Device C and Device D.

In either case, implementing and parsing both the DPP unit directory and the p1212r Instance directory

will enable an efficient and high level of device discovery and enumeration at the ROM level.

Device A

Device BDevice E

Device D

Printer

DPP

VCR

AV/C

DSC

DPP

Device C

Printer

SBP2Disk

DPP


Page- 220

Annex F. Thin Protocol State Machine (Informative)

Annex F contains the state machines and the state machine notes for the Thin Session and the Thin

Transaction. Note that the descriptions in this annex are informative.

F.1. Thin Session Connect State Machine

C0: Connect Readyall timers stop

initialize all state machines

transaction request ofconnect

session request of connectC0:C1

session confirmationwith connect nack

transaction confirmationwith connect nack

C1:C0a

C2: Connect Response

C1: Connect Requestconnect timer start

C3: Connected

connect timer stopsession confirmation with connect ack

transaction confirmationwith connect ack

C1:C3

session indication of errortransaction request of

disconnect

transaction indicationof error or

connect timeout occurredC1:C0b

session indication ofconnect request

transaction indication ofconnect request

C0:C2

transaction responsewith connect reject

session response withconnect nack

C2:C0a

session indicationof error

transaction request ofdisconnect

transaction indicationof error

C2:C0b

transaction response with connect ack

session response withconnect ack

C2:C3

C4:C3

C4:C0b

C5:C0a

C3:C4

transactionindication of error

transaction request of disconnect

session request of disconnectC3:C0a

session indication of disconnect

transaction indication of disconnectC3:C0b

C4:C0a

C5:C3

C5:C0b

All:C0initialize

C3:C3

idle timeout or datatransfer timeout

occurred

session indication oferror with timeout

Figure F-1 Thin Session connect state machine


Page- 221

C5: Reconnect Response

C4: Reconnect Startreconnect timer start

transactionrequest ofreconnect

transactionindication of

errorC3:C4

session indication of error with reconnect nack

transaction confirmation with reconnect nackC4:C0a

reconnect timer stopinternal event of reconnect complete

transaction confirmation with reconnect ackC4:C3

session indication of error with reconnect timeouttransaction request of disconnect

reconnect timeout occurredC4:C0b

transaction indicationof reconnect

C4:C5reconnect timer stop

transaction response with reconnect ackinternal event of reconnect complete

reconnection is permittedC5:C3

transaction response with reconnect nacksession indication of error with reconnect nack

reconnection is not permittedC5:C0a

session indication of error with reconnect timeouttransaction request of disconnect

C5:C0breconnect timeout occurred

transaction requestof reconnect


C5:C4

transactionrequest ofreconnect

C4:C4

transactionindication of

error

Figure F-2 Thin Session connect state machine (continued)

State C0: Connect Ready. This is the entry point of the Thin Session connect state machine. A node

is ready to send or receive a connect request. All timers are stopped at the entry of this state.

State C1: Connect Request. When a connect request is issued from an application, a node sends a

connect request. In this state, a node is waiting to receive a connect response from the responder node.

State C2: Connect Response. When a connect request is received, a node indicates a connect request

to an application. In this state, a node is waiting to receive a response from an application.

State C3: Connected. At this point, a connection between the initiator node and responder node is

established. A node stays in this state until an internal or external event occurs.

State C4: Reconnect Start. When a bus reset or an unexpected error occurs, a reconnect process is

started. A node sends a reconnect request.

State C5: Reconnect Response. A reconnect request is received from the other node. Even if a

reconnect request was sent, a node sends a reconnect response.


Page- 222

F.2. Thin Session Outbound Data Transfer State Machine

S1: Send DataS0: Send Data Ready

initializeAll:S0

session request of abortS1:S3

transaction request of SDUsend with segment data

transaction confirmation withSDU ready and interim / last

segment data transfer nextS1:S1

session request of commandS0:S1a

session indication of command IDtransaction request of SDU send

with single dataor first segment data

session response of commandS0:S1b

transaction request of SDU sendwith single data

or first segment data

transaction confirmation with SDUready and no data transfer next

S1:S0a

session indication of error withSDU reject

transaction confirmation withSDU reject

S1:S0b

S2: Reconnect Wait


S1:S2


internal event of transfer abortS1:S5

S4:S0

S5:S0

S0:S0

internal event oftransfer abort

sessionindication of abort

S2:S1transaction requestof SDU send with

previous data

internal event ofreconnect complete

transaction confirmation ofSDU ready

S4:S0

S3: Data Transfer Stopfor Abort Request

transaction request ofSDU stop


transaction request ofSDU send with abort

command

transactionconfirmation of

SDU readyS3:S4

S4: Abort Request

transaction request of SDU send with abort command


S5: Data Transfer Stop

transaction request ofSDU stop

internal event of transfer abort

S1:S5 transaction confirmation of SDU readyS5:S0

session indication of abort

Figure F-3 Thin Session outbound data transfer state machine


Page- 223

Note that this state machine is intended for a single command data transfer. To handle a multiple

command data transfer, a node may have an individual state machine for each command, e.g.

State S0: Send Data Ready. This is the entry point of the Thin Session outbound state machine. An

outbound data transfer process is initialized and ready for sending data.

State S1: Send Data. A command request or response is issued from an application. In the case of a

command request, an indication of the applied command ID is provided to an application. A node

stays in this state until the application data is sent completely.

State S2: Reconnect Wait. If a bus reset or an unexpected error is indicated, a node waits to receive

an internal event of reconnect complete. When the reconnect sequence is completed, the previous data

is sent again.

State S3: Data Transfer Stop for Abort Request. An abort request is issued from an application

during a data transfer. A node sends a data transfer stop request and waits to receive a transaction

confirmation.

State S4: Abort Request. An abort request, including a higher layer abort command, is sent. A node

is waiting to receive a transaction confirmation.

State S5: Data Transfer Stop. An internal event of transfer abort has occurred during a data transfer.

A node sends a data transfer stop request and waits to receive a transaction confirmation.


Page- 224

F.3. Thin Session Inbound Data Transfer State Machine

R1: Receive Data

transaction indication ofSDU send

R0:R1

R0: Receive Data Ready

initializeAll:R0

transaction response with SDU readysession indication or confirmation of command

single data/last segment data andSDU register becomes available

R1:R0a

transaction indication of SDU stopAll:R3

R3: Receive Transfer Stop

transaction response with SDU ready

SDU register becomes availableR3:R0

abort command and SDUregister becomes available

R1:R0binternal event of transfer abort

transaction response with SDU ready

SDU can not accept and SDUregister becomes available

R1:R0ctransaction response with SDU reject

session indication of error

transaction responsewith SDU ready

first/interim segment dataand SDU register

becomes availableR1:R2

R2: Wait Next Data

transaction indication ofSDU send

R2:R1

Figure F-4 Thin Session inbound data transfer state machine

Note that this state machine is intended for a single command data transfer. To handle a multiple

command data transfer, a node may use an individual state machine for each command, e.g.

State R0: Receive Data Ready. This is the entry point of the Thin Session inbound state machine. An

inbound data transfer process is initialized and ready for receiving data.

State R1: Receive Data. Application data has been received. A node waits for an SDU register to be

ready, and sends a response.

State R2: Wait Next Data. When a node receives the first or interim segment data, the node waits for

the next segment data in this state.

State R3: Receive Transfer Stop. A data transfer stop request is received during a data transfer. A

node waits for an SDU register to be ready, and sends a response.


Page- 225

F.4. Thin Transaction State Machine

T0: TransactionReady

send packet to the SDU register

transaction request of SDU SendT0:T1

T1: SDU Send

send packet to the SDU register

SDU transfer is not completedT1:T1

send SDU Ready or SDU Reject to the SDU managementregister

transaction response of SDU Send or SDU StopT0:T0c

receive SDU Ready or SDU Reject from SDUmanagement register

T0:T0dtransaction confirmation with SDU Ready or SDU Reject

receive SDU Comp from SDU management registerT0:T0e

transaction indication of SDU Send with received data

send SDU Comp to the SDUmanagement register

SDU transfer is completedT1:T0a

send SDU Stop to the SDUmanagement register

transaction request of SDU StopT1:T0b

receive SDU Stop from SDU management registerT0:T0f

transaction indication of SDU Stop


T1:T2

Bus reset or unspecifiederror occurred


T0:T2

Bus reset or unspecifiederror occurred

T2:T0

internal event ofreconnect complete

T2: Error

T1:T2

All:T0initialize

send packet to the Connection register

transaction request or response about connectionT0:T0a

transaction indication or confirmation about connection

receive packet from the Connection registerT0:T0b

send packet to the Connection register

transaction request or response about connectionT2:T2a

transaction indication or confirmation about connection

receive packet from the Connection registerT2:T2b

Figure F-5 Thin Transaction state machine


Page- 226

Note that this state machine is intended to realize both inbound and outbound data transfers in one

state machine. Therefore, receiving data while data is sending is not supported. To handle this, a node

may have two state machines respectively for inbound and outbound data transfers, e.g.

State T0: Transaction Ready. This is the entry point of the Thin Transaction state machine. A data

transfer process is initialized and ready for sending or receiving data.

State T1: SDU Send. A node is sending SDU. A node stays in this state until the SDU is sent

completely.

State T2: Error. When a bus reset or unspecified error occurs, The Thin Transaction issues an error

indication.


Page- 227

Annex G. DPP ver 1.0 Enhancements in DPP 1.1

This section lists features of the Direct Print Protocol Specification Version1.1 (DPP1.1) that are

enhancements and changes made from the Direct Print Protocol Specification Version1.0 (DPP1.0).

The Direct Print Protocol Specification Version1.0 can be obtained from the 1394 Trade Association.

(TA Document : 1998008 ).

Feature Part Section Mandatory(M)

Multiple connections Thin Protocol 5.8.1.1

Result value 13h –

Connect NACK

Thin Protocol 5.11.4.3

Page table access Thin Protocol 5.8.1.2.2

5.11.3

FTC FTC 9

Start Request DPC 7.6.4.5

Command set directory ROM

(Thin Protocol)

6.1.4.9

Unit_SW_Details ROM

(Thin Protocol)

6.1.4.3 M

Instance directory ROM

(Thin Protocol)

6.2 M

Though backward compatibility with DPP1.0 is considered in DPP1.1, devices compliant with

DPP1.0 do not realize the above enhancements.

As noted in the specification, DPP1.1 devices shall not utilize these functions when connecting to

DPP1.0 devices.

Confirming the version of the Thin Protocol and command sets (i.e. DPC, FTC) by parsing the unit

directory of the configuration ROM is strongly recommended before initiating a connection to a DPP

device.


Page- 228

Annex H. Clarification of DPP 1.0 Specifications

This section clarifies some ambiguities of the Direct Print Protocol Specification Version1.0 (TA

Document : 1998008 ). Section references noted below apply to the Direct Print Protocol

Specification Version1.0 document.

H.1. Negotiation Information ( Thin Protocol )

In the Connect Request Format (described in section 5.11.4.1), the NegInf value for the SDU address

and SDU management address of the Responder node shall be filled with a value, though this value

may not be valid. The Responder node may ignore this value and allocate addresses on it’s own.

In the Connect Ack Format (described in section 5.11.4.2), the NegInf value for the SDU address and

SDU management address of the Initiator node shall include the same values of the Connect Request

from the Initiator node.

If the optional negotiation information is used in the Connect Nack Format (described in section

5.11.4.3), all mandatory NegInf tags shall be included.

H.2. Command ID ( Thin Protocol )

If both the Initiator node and the Responder node send commands at the same time, the Thin Session

of both nodes might apply the same command ID value. (described in section 5.11.7.2/5.11.7.3).

To prevent this, it is recommended that the Initiator node (issuing node of the Connect request) uses a

value from 0000h to 7FFFh, and the Responder node (responding node to the Connect request) uses a

value from 8000h to FFFFh as the command ID.


Page- 229

H.3. Parameter Contents Length ( Direct Print Command Set )

When issuing the Generic Command Send (CmdCode 03h), with image data as the parameter contents

(ParaCode 01h), the Length or Length32 value of the Generic Command/Response Parameter Format

(described in section 6.5.3) shall not include the zero padding (00h, described in Annex C), but only

the valid image data length.

On the other hand, the Length or Length32 field of the Generic Command/Response Packet Format

(described in section 6.5.2) includes the number of padding because the valid command packet

contents includes the padding area.

The sample of the packet including the "4n+2" size Image Data is shown below.

Figure H-1 Parameter Contents Length

Length32 = 4(n+1) + 8 (length of area)

OPT CmdCode (Send) CountF ReservedV D L=0

Length32 = 4n+2 (length of area)

OPT ParaCode (Image) CountF ReservedV D L=1

00h 00h

Image Data (4n+2)

direct print protocol specification1394ta.org/wp-content/uploads/2015/07/1999018.pdf ·...

Documents