idnits 2.17.1 draft-hallambaker-mesh-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2019) is 1848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 911 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft April 4, 2019 4 Intended status: Informational 5 Expires: October 6, 2019 7 Mathematical Mesh Part V: Protocol Reference 8 draft-hallambaker-mesh-protocol-00 10 Abstract 12 The Mathematical Mesh 'The Mesh' is an end-to-end secure 13 infrastructure that facilitates the exchange of configuration and 14 credential data between multiple user devices. The core protocols of 15 the Mesh are described with examples of common use cases and 16 reference data. 18 This document is also available online at 19 http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html 20 [1] . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 6, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 62 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Protocol Transaction . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Connection Establishment . . . . . . . . . . . . . . . . 5 65 4.2. Account Management . . . . . . . . . . . . . . . . . . . 5 66 4.3. Device Connection . . . . . . . . . . . . . . . . . . . . 5 67 4.4. Container Synchronization . . . . . . . . . . . . . . . . 5 68 4.4.1. User Experience Considerations . . . . . . . . . . . 5 69 4.4.2. Status Transaction . . . . . . . . . . . . . . . . . 5 70 4.4.3. Download Transaction . . . . . . . . . . . . . . . . 5 71 4.4.4. Upload Transaction . . . . . . . . . . . . . . . . . 6 72 4.5. Message Exchange . . . . . . . . . . . . . . . . . . . . 6 73 4.5.1. Client-Service (Post Transaction) . . . . . . . . . . 6 74 4.5.2. Service-Service (Post Transaction) . . . . . . . . . 6 75 4.5.3. Service-Client (Synchronization) . . . . . . . . . . 6 76 4.6. Mesh Service . . . . . . . . . . . . . . . . . . . . . . 7 77 4.6.1. Catalogs . . . . . . . . . . . . . . . . . . . . . . 7 78 4.6.2. Spools . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.6.3. Partitioning . . . . . . . . . . . . . . . . . . . . 7 80 4.6.4. Backup . . . . . . . . . . . . . . . . . . . . . . . 7 81 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . 7 82 5.1. HTTPS Presentation . . . . . . . . . . . . . . . . . . . 8 83 5.2. DARE Message Encapsulation . . . . . . . . . . . . . . . 8 84 5.2.1. Device Authentication . . . . . . . . . . . . . . . . 8 85 5.2.2. Profile Authentication . . . . . . . . . . . . . . . 8 86 5.2.3. Ticket Authentication . . . . . . . . . . . . . . . . 8 87 5.3. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 8 88 5.4. JSON-B Encoding . . . . . . . . . . . . . . . . . . . . . 8 89 6. Account Management . . . . . . . . . . . . . . . . . . . . . 8 90 7. Container Operations . . . . . . . . . . . . . . . . . . . . 8 91 7.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 7.2. Download . . . . . . . . . . . . . . . . . . . . . . . . 8 93 7.3. Upload . . . . . . . . . . . . . . . . . . . . . . . . . 8 94 8. Device Connection . . . . . . . . . . . . . . . . . . . . . . 8 95 8.1. Device Authenticated . . . . . . . . . . . . . . . . . . 9 96 8.2. PIN Authenticated . . . . . . . . . . . . . . . . . . . . 9 97 8.3. EARL connection mode . . . . . . . . . . . . . . . . . . 9 98 9. Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . . 9 99 9.1. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 9 100 9.2. Confirm . . . . . . . . . . . . . . . . . . . . . . . . . 9 101 10. Protocol Schema . . . . . . . . . . . . . . . . . . . . . . . 9 102 10.1. Request Messages . . . . . . . . . . . . . . . . . . . . 9 103 10.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 10 104 10.1.2. Message: MeshRequestUser . . . . . . . . . . . . . . 10 105 10.2. Response Messages . . . . . . . . . . . . . . . . . . . 10 106 10.2.1. Message: MeshResponse . . . . . . . . . . . . . . . 10 107 10.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 10 108 10.4. Common Structures . . . . . . . . . . . . . . . . . . . 10 109 10.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . 11 110 10.4.2. Structure: ConstraintsSelect . . . . . . . . . . . . 11 111 10.4.3. Structure: ConstraintsData . . . . . . . . . . . . . 11 112 10.4.4. Structure: PolicyAccount . . . . . . . . . . . . . . 12 113 10.4.5. Structure: ContainerStatus . . . . . . . . . . . . . 12 114 10.4.6. Structure: ContainerUpdate . . . . . . . . . . . . . 12 115 10.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 13 116 10.5.1. Message: MeshHelloResponse . . . . . . . . . . . . . 13 117 10.6. Transaction: Status . . . . . . . . . . . . . . . . . . 13 118 10.6.1. Message: StatusRequest . . . . . . . . . . . . . . . 13 119 10.6.2. Message: StatusResponse . . . . . . . . . . . . . . 14 120 10.7. Transaction: Download . . . . . . . . . . . . . . . . . 14 121 10.7.1. Message: DownloadRequest . . . . . . . . . . . . . . 14 122 10.7.2. Message: DownloadResponse . . . . . . . . . . . . . 15 123 10.8. Transaction: Upload . . . . . . . . . . . . . . . . . . 15 124 10.8.1. Message: UploadRequest . . . . . . . . . . . . . . . 15 125 10.8.2. Message: UploadResponse . . . . . . . . . . . . . . 15 126 10.8.3. Structure: EntryResponse . . . . . . . . . . . . . . 16 127 10.9. Transaction: Post . . . . . . . . . . . . . . . . . . . 16 128 10.9.1. Message: PostRequest . . . . . . . . . . . . . . . . 16 129 10.9.2. Message: PostResponse . . . . . . . . . . . . . . . 17 130 10.10. Transaction: Connect . . . . . . . . . . . . . . . . . . 17 131 10.10.1. Message: ConnectRequest . . . . . . . . . . . . . . 17 132 10.10.2. Message: ConnectResponse . . . . . . . . . . . . . 17 133 10.11. Transaction: CreateAccount . . . . . . . . . . . . . . . 18 134 10.11.1. Message: CreateRequest . . . . . . . . . . . . . . 18 135 10.11.2. Message: CreateResponse . . . . . . . . . . . . . . 18 136 10.12. Transaction: DeleteAccount . . . . . . . . . . . . . . . 19 137 10.12.1. Message: DeleteRequest . . . . . . . . . . . . . . 19 138 10.12.2. Message: DeleteResponse . . . . . . . . . . . . . . 19 139 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 140 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 141 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 142 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 143 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 144 14.2. Informative References . . . . . . . . . . . . . . . . . 20 145 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 146 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 148 1. Introduction 150 This document describes the data structures and network protocols of 151 the Mathematical Mesh illustrated with illustrative examples. For an 152 overview of the Mesh objectives and architecture, consult the 153 accompanying Architecture Guide [draft-hallambaker-mesh-architecture] 155 This document has two main sections. The first section presents 156 examples of using the Mesh to address common use cases. The second 157 section contains the Mesh profile and service schemas. All the 158 material in both sections is generated from the Mesh reference 159 implementation [draft-hallambaker-mesh-developer] . 161 Although some of the services described in this document could be 162 used to replace existing Internet protocols including FTP and SMTP, 163 the principal value of any communication protocol lies in the size of 164 the audience it allows them to communicate with. Thus, while the 165 Mesh Messaging service is designed to support efficient and reliable 166 transfer of messages ranging in size from a few bytes to multiple 167 terabytes, the near term applications of these services will be to 168 applications that are not adequately supported by existing protocols 169 if at all. 171 2. Definitions 173 This section presents the related specifications and standard, the 174 terms that are used as terms of art within the documents and the 175 terms used as requirements language. 177 2.1. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119] . 183 2.2. Defined Terms 185 The terms of art used in this document are described in the Mesh 186 Architecture Guide [draft-hallambaker-mesh-architecture] . 188 2.3. Related Specifications 190 The architecture of the Mathematical Mesh is described in the Mesh 191 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 192 documentation set and related specifications are described in this 193 document. 195 2.4. Implementation Status 197 The implementation status of the reference code base is described in 198 the companion document [draft-hallambaker-mesh-developer] . 200 3. 202 4. Protocol Transaction 204 4.1. Connection Establishment 206 4.2. Account Management 208 4.3. Device Connection 210 4.4. Container Synchronization 212 4.4.1. User Experience Considerations 214 Sync 216 o Status 218 o Upload outbound messages 220 o Download catalog and spool updates 222 o Upload catalog updates 224 Rapid access - only take last 100 messages 226 Limitation on message size ensures that 228 4.4.2. Status Transaction 230 Obtain updated device profile (if it exists) and the status of the 231 set of catalogs the device is authorized 233 4.4.3. Download Transaction 235 Read objects from a catalog or spool owned by the client making the 236 request. 238 Optional filtering criteria MAY be specified to only return objects 239 matching specific criteria and/or only return certain parts of the 240 selected messages. 242 The transaction MAY be performed in one request/response round trip 243 or with separate round trips to confirm that the transaction is 244 accepted by the service before sending large volumes of data. 246 4.4.4. Upload Transaction 248 Upload objects to a catalog or spool owned by Read objects from a 249 catalog or spool owned by the client making the request. 251 Multiple objects MAY be uploaded at once. Object updates MAY be 252 conditional on the successful completion of other upload requests. 254 The transaction MAY be performed in one request/response round trip 255 or with separate round trips to confirm that the transaction is 256 accepted by the service before sending large volumes of data. 258 4.5. Message Exchange 260 Four corner model enforced. 262 Messages are limited to control with very small amounts of data 264 Long messages are exchanged as detachments using separate protocol 265 (HTTP). 267 This ensures that messages are processed quickly and reliably. A 268 server will not be blocked by receipt of a long message. 270 Aggressive controls on services may be enforced to prevent DoS 271 attacks. 273 Post transaction is used for client-service and service-service 274 transactions. 276 4.5.1. Client-Service (Post Transaction) 278 4.5.2. Service-Service (Post Transaction) 280 4.5.3. Service-Client (Synchronization) 281 4.6. Mesh Service 283 Untrusted service, minimize trust to bare minimum 285 Can't read content of any message. 287 Can only read contact catalog entries. 289 4.6.1. Catalogs 291 4.6.1.1. Account 293 Contains the account entries. 295 4.6.2. Spools 297 4.6.2.1. Account 299 Log of all updates to accounts. 301 Synchronization off-host provides backup. 303 4.6.2.2. Incident 305 Reports of potential abuse 307 4.6.3. Partitioning 309 Can split out handling of accounts to separate hosts each handling a 310 subset of accounts. 312 User clients are directed to connect to a specific host in any case 313 by means of redirects. 315 4.6.4. Backup 317 Synchronizing Account spools protects data against loss and provides 318 for fast restart capability. 320 5. Protocol Binding 322 Transactions consist of single request message followed by a single 323 response message. 325 Default binding is HTTPS/DARE/JSON 327 Hello Transaction may be used to determine features supported by the 328 service and the service configuration 329 ```` Example ProtocolHello ```` 331 5.1. HTTPS Presentation 333 5.2. DARE Message Encapsulation 335 5.2.1. Device Authentication 337 ```` Example ProtocolHelloDevice ```` 339 5.2.2. Profile Authentication 341 ```` Example ProtocolHelloProfile ```` 343 5.2.3. Ticket Authentication 345 ```` Example ProtocolHelloTicket ```` 347 5.3. JSON Encoding 349 5.4. JSON-B Encoding 351 6. Account Management 353 ```` Example ProtocolAccountCreate ```` 355 ```` Example ProtocolAccountDelete ```` 357 7. Container Operations 359 7.1. Status 361 ```` Example ProtocolStatus ```` 363 7.2. Download 365 ```` Example ProtocolDownload ```` 367 7.3. Upload 369 ```` Example ProtocolProtocolUploadHello ```` 371 8. Device Connection 372 8.1. Device Authenticated 374 ```` Example ProtocolConnect ```` 376 8.2. PIN Authenticated 378 ```` Example ProtocolConnectPIN ```` 380 8.3. EARL connection mode 382 ```` Example ProtocolConnectEARL ```` 384 9. Mesh Messages 386 All communications between accounts is performed through mesh 387 messages. 389 Four corner model 391 9.1. Contact 393 ```` Example ProtocolContact ```` 395 9.2. Confirm 397 ```` Example ProtocolConfirm ```` 399 10. Protocol Schema 401 HTTP Well Known Service Prefix: /.well-known/mmm 403 Every Mesh Portal Service transaction consists of exactly one request 404 followed by exactly one response. Mesh Service transactions MAY 405 cause modification of the data stored in the Mesh Service or the Mesh 406 itself but do not cause changes to the connection state. The 407 protocol itself is thus idempotent. There is no set sequence in 408 which operations are required to be performed. It is not necessary 409 to perform a Hello transaction prior to any other transaction. 411 10.1. Request Messages 413 A Mesh Portal Service request consists of a payload object that 414 inherits from the MeshRequest class. When using the HTTP binding, 415 the request MUST specify the portal DNS address in the HTTP Host 416 field. 418 10.1.1. Message: MeshRequest 420 Base class for all request messages. 422 [No fields] 424 10.1.2. Message: MeshRequestUser 426 Base class for all request messages made by a user. 428 Inherits: MeshRequest 430 Inherits: MeshRequest 432 Account: String (Optional) The fully qualified account name 433 (including DNS address) to which the request is directed. 435 DeviceProfile: DareMessage (Optional) Device profile of the device 436 making the request. 438 10.2. Response Messages 440 A Mesh Portal Service response consists of a payload object that 441 inherits from the MeshResponse class. When using the HTTP binding, 442 the response SHOULD report the Status response code in the HTTP 443 response message. However the response code returned in the payload 444 object MUST always be considered authoritative. 446 10.2.1. Message: MeshResponse 448 Base class for all response messages. Contains only the status code 449 and status description fields. 451 [No fields] 453 10.3. Imported Objects 455 The Mesh Service protocol makes use of JSON objects defined in the 456 JOSE Signatgure and Encryption specifications and in the DARE Data At 457 Rest Encryption extensions to JOSE. 459 10.4. Common Structures 461 The following common structures are used in the protocol messages: 463 10.4.1. Structure: KeyValue 465 Describes a Key/Value structure used to make queries for records 466 matching one or more selection criteria. 468 Key: String (Optional) The data retrieval key. 470 Value: String (Optional) The data value to match. 472 10.4.2. Structure: ConstraintsSelect 474 Specifies constraints to be applied to a search result. These allow 475 a client to limit the number of records returned, the quantity of 476 data returned, the earliest and latest data returned, etc. 478 Container: String (Optional) The container to be searched. 480 IndexMin: Integer (Optional) Only return objects with an index value 481 that is equal to or higher than the value specified. 483 IndexMax: Integer (Optional) Only return objects with an index value 484 that is equal to or lower than the value specified. 486 NotBefore: DateTime (Optional) Only data published on or after the 487 specified time instant is requested. 489 Before: DateTime (Optional) Only data published before the specified 490 time instant is requested. This excludes data published at the 491 specified time instant. 493 PageKey: String (Optional) Specifies a page key returned in a 494 previous search operation in which the number of responses 495 exceeded the specified bounds. 497 When a page key is specified, all the other search parameters 498 except for MaxEntries and MaxBytes are ignored and the service 499 returns the next set of data responding to the earlier query. 501 10.4.3. Structure: ConstraintsData 503 Specifies constraints on the data to be sent. 505 MaxEntries: Integer (Optional) Maximum number of entries to send. 507 BytesOffset: Integer (Optional) Specifies an offset to be applied to 508 the payload data before it is sent. This allows large payloads to 509 be transferred incrementally. 511 BytesMax: Integer (Optional) Maximum number of payload bytes to 512 send. 514 Header: Boolean (Optional) Return the entry header 516 Payload: Boolean (Optional) Return the entry payload 518 Trailer: Boolean (Optional) Return the entry trailer 520 10.4.4. Structure: PolicyAccount 522 Describes the account creation policy including constraints on 523 account names, whether there is an open account creation policy, etc. 525 Minimum: Integer (Optional) Specifies the minimum length of an 526 account name. 528 Maximum: Integer (Optional) Specifies the maximum length of an 529 account name. 531 InvalidCharacters: String (Optional) A list of characters that the 532 service does not accept in account names. The list of characters 533 MAY not be exhaustive but SHOULD include any illegal characters in 534 the proposed account name. 536 10.4.5. Structure: ContainerStatus 538 Container: String (Optional) 540 Container: String (Optional) 542 Index: Integer (Optional) 544 Index: Integer (Optional) 546 Digest: Binary (Optional) 548 10.4.6. Structure: ContainerUpdate 550 Container: String (Optional) The container to which the entries are 551 to be uploaded. 553 Message: DareMessage [0..Many] The entries to be uploaded. These 554 MAY be either complete messages or redacted messages. In either 555 case, the messages MUST conform to the ConstraintsUpdate specified 556 by the service 558 10.5. Transaction: Hello 560 Request: HelloRequest 562 Request: HelloRequest 564 Response: MeshHelloResponse 566 Report service and version information. 568 The Hello transaction provides a means of determining which protocol 569 versions, message encodings and transport protocols are supported by 570 the service. 572 The PostConstraints field MAY be used to advise senders of a maximum 573 size of payload that MAY be sent in an initial Post request. 575 10.5.1. Message: MeshHelloResponse 577 ConstraintsUpdate: ConstraintsData (Optional) Specifies the default 578 data constraints for updates. 580 ConstraintsPost: ConstraintsData (Optional) Specifies the default 581 data constraints for message senders. 583 PolicyAccount: PolicyAccount (Optional) Specifies the account 584 creation policy 586 10.6. Transaction: Status 588 Request: StatusRequest 590 Request: StatusRequest 592 Response: StatusResponse 594 10.6.1. Message: StatusRequest 596 Inherits: MeshRequestUser 598 Inherits: MeshRequestUser 600 DeviceUDF: String (Optional) 602 DeviceUDF: String (Optional) 604 Catalogs: String [0..Many] 605 Catalogs: String [0..Many] 607 Spools: String [0..Many] 609 10.6.2. Message: StatusResponse 611 Inherits: MeshResponse 613 Inherits: MeshResponse 615 ContainerStatus: ContainerStatus [0..Many] 617 ContainerStatus: ContainerStatus [0..Many] 619 CatalogEntryDevice: DareMessage (Optional) The catalog device entry 621 10.7. Transaction: Download 623 Request: DownloadRequest 625 Request: DownloadRequest 627 Response: DownloadResponse 629 Request objects from the specified container with the specified 630 search criteria. 632 10.7.1. Message: DownloadRequest 634 Inherits: MeshRequestUser 636 Request objects from the specified container(s). 638 A client MAY request only objects matching specified search criteria 639 be returned and MAY request that only specific fields or parts of the 640 payload be returned. 642 Select: ConstraintsSelect [0..Many] Specifies constraints to be 643 applied to a search result. These allow a client to limit the 644 number of records returned, the quantity of data returned, the 645 earliest and latest data returned, etc. 647 ConstraintsPost: ConstraintsData (Optional) Specifies the data 648 constraints to be applied to the responses. 650 10.7.2. Message: DownloadResponse 652 Inherits: MeshResponse 654 Return the set of objects requested. 656 Services SHOULD NOT return a response that is disproportionately 657 large relative to the speed of the network connection without a clear 658 indication from the client that it is relevant. A service MAY limit 659 the number of objects returned. A service MAY limit the scope of 660 each response. 662 Updates: ContainerUpdate [0..Many] The updated data 664 10.8. Transaction: Upload 666 Request: UploadRequest 668 Request: UploadRequest 670 Response: UploadResponse 672 Request objects from the specified container with the specified 673 search criteria. 675 10.8.1. Message: UploadRequest 677 Inherits: MeshRequestUser 679 Upload entries to a container. This request is only valid if it is 680 issued by the owner of the account 682 Updates: ContainerUpdate [0..Many] The data to be updated 684 Self: DareMessage [0..Many] Entries to be added to the inbound spool 685 on the account, e.g. completion messages. 687 10.8.2. Message: UploadResponse 689 Inherits: MeshResponse 691 Response to an upload request. 693 Entries: EntryResponse (Optional) The responses to the entries. 695 ConstraintsData: ConstraintsData (Optional) If the upload request 696 contains redacted entries, specifies constraints that apply to the 697 redacted entries as a group. Thus the total payloads of all the 698 messages must not exceed the specified value. 700 10.8.3. Structure: EntryResponse 702 IndexRequest: Integer (Optional) The index value of the entry in the 703 request. 705 IndexContainer: Integer (Optional) The index value assigned to the 706 entry in the container. 708 Result: String (Optional) Specifies the result of attempting to add 709 the entry to a catalog or spool. Valid values for a message are 710 'Accept', 'Reject'. Valid values for an entry are 'Accept', 711 'Reject' and 'Conflict'. 713 ConstraintsData: ConstraintsData (Optional) If the entry was 714 redacted, specifies constraints that apply to the redacted entries 715 as a group. Thus the total payloads of all the messages must not 716 exceed the specified value. 718 10.9. Transaction: Post 720 Request: PostRequest 722 Request: PostRequest 724 Response: PostResponse 726 Request to post to a spool from an external party. The request and 727 response messages are extensions of the corresponding messages for 728 the Upload transaction. It is expected that additional fields will 729 be added as the need arises. 731 10.9.1. Message: PostRequest 733 Inherits: MeshRequest 735 Inherits: MeshRequest 737 Accounts: String [0..Many] The account(s) to which the request is 738 directed. 740 Message: DareMessage [0..Many] The entries to be uploaded. These 741 MAY be either complete messages or redacted messages. In either 742 case, the messages MUST conform to the ConstraintsUpdate specified 743 by the service 745 Self: DareMessage (Optional) Messages to be appended to the inbound 746 spool of the user's inbound spool. this is typically used to post 747 notifications to the user to mark messages as having been read or 748 responded to. 750 10.9.2. Message: PostResponse 752 Inherits: UploadResponse 754 [No fields] 756 10.10. Transaction: Connect 758 Request: ConnectRequest 760 Request: ConnectRequest 762 Response: ConnectResponse 764 Request information necessary to begin making a connection request. 766 10.10.1. Message: ConnectRequest 768 Inherits: MeshRequest 770 Inherits: MeshRequest 772 Account: String (Optional) 774 Account: String (Optional) 776 DeviceProfile: DareMessage (Optional) Device profile of the device 777 making the request. 779 ClientNonce: Binary (Optional) 781 ClientNonce: Binary (Optional) 783 PinID: String (Optional) Pin identifier used to identify a PIN 784 authenticated request. 786 10.10.2. Message: ConnectResponse 788 Inherits: MeshResponse 790 Inherits: MeshResponse 792 ProfileMesh: DareMessage (Optional) The account profile 793 ServerNonce: Binary (Optional) Server Nonce value used to calculate 794 Witness 796 Witness: String (Optional) Witness value 798 10.11. Transaction: CreateAccount 800 Request: CreateRequest 802 Request: CreateRequest 804 Response: CreateResponse 806 Request creation of a new service account. 808 Attempt 810 10.11.1. Message: CreateRequest 812 Request creation of a new portal account. The request specifies the 813 requested account identifier and the Mesh profile to be associated 814 with the account. 816 Inherits: MeshRequest 818 Inherits: MeshRequest 820 MeshProfile: DareMessage (Optional) The Mesh profile to be 821 registered. 823 CatalogEntryDevices: DareMessage [0..Many] The device profile(s) to 824 be registered in the corresponding device catalog. 826 CatalogEntryContacts: CatalogEntryContact [0..Many] The contact(s) 827 to be registered in the corresponding contact catalog. This 828 should usually be populated with a contact for the user 829 themselves. 831 10.11.2. Message: CreateResponse 833 Inherits: MeshResponse 835 Reports the success or failure of a Create transaction. 837 Reason: String (Optional) Text explaining the status of the creation 838 request. 840 URL: String (Optional) A URL to which the user is directed to 841 complete the account creation request. 843 10.12. Transaction: DeleteAccount 845 Request: DeleteRequest 847 Request: DeleteRequest 849 Response: DeleteResponse 851 Request deletion of a new service account. 853 Attempt 855 10.12.1. Message: DeleteRequest 857 Request creation of a new portal account. The request specifies the 858 requested account identifier and the Mesh profile to be associated 859 with the account. 861 Inherits: MeshRequestUser 863 [No fields] 865 10.12.2. Message: DeleteResponse 867 Inherits: MeshResponse 869 Reports the success or failure of a Delete transaction. 871 [No fields] 873 11. Security Considerations 875 The security considerations for use and implementation of Mesh 876 services and applications are described in the Mesh Security 877 Considerations guide [draft-hallambaker-mesh-security] . 879 12. IANA Considerations 881 All the IANA considerations for the Mesh documents are specified in 882 this document 884 13. Acknowledgements 886 14. References 888 14.1. Normative References 890 [draft-hallambaker-mesh-architecture] 891 Hallam-Baker, P., "Mathematical Mesh Part I: Architecture 892 Guide", draft-hallambaker-mesh-architecture-06 (work in 893 progress), August 2018. 895 [draft-hallambaker-mesh-security] 896 "[Reference Not Found!]". 898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 899 Requirement Levels", BCP 14, RFC 2119, 900 DOI 10.17487/RFC2119, March 1997. 902 14.2. Informative References 904 [draft-hallambaker-mesh-developer] 905 Hallam-Baker, P., "Mathematical Mesh: Reference 906 Implementation", draft-hallambaker-mesh-developer-07 (work 907 in progress), April 2018. 909 14.3. URIs 911 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 912 protocol.html 914 Author's Address 916 Phillip Hallam-Baker 918 Email: phill@hallambaker.com