[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                    P. Hallam-Baker
Internet-Draft                                             April 4, 2019
Intended status: Informational
Expires: October 6, 2019


              Mathematical Mesh Part V: Protocol Reference
                   draft-hallambaker-mesh-protocol-00

Abstract

   The Mathematical Mesh 'The Mesh' is an end-to-end secure
   infrastructure that facilitates the exchange of configuration and
   credential data between multiple user devices.  The core protocols of
   the Mesh are described with examples of common use cases and
   reference data.

   This document is also available online at
   http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html
   [1] .

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 6, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Hallam-Baker             Expires October 6, 2019                [Page 1]


Internet-Draft           Mesh Protocol Reference              April 2019


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.2.  Defined Terms . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Related Specifications  . . . . . . . . . . . . . . . . .   4
     2.4.  Implementation Status . . . . . . . . . . . . . . . . . .   5
   3.  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Protocol Transaction  . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Connection Establishment  . . . . . . . . . . . . . . . .   5
     4.2.  Account Management  . . . . . . . . . . . . . . . . . . .   5
     4.3.  Device Connection . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Container Synchronization . . . . . . . . . . . . . . . .   5
       4.4.1.  User Experience Considerations  . . . . . . . . . . .   5
       4.4.2.  Status Transaction  . . . . . . . . . . . . . . . . .   5
       4.4.3.  Download Transaction  . . . . . . . . . . . . . . . .   5
       4.4.4.  Upload Transaction  . . . . . . . . . . . . . . . . .   6
     4.5.  Message Exchange  . . . . . . . . . . . . . . . . . . . .   6
       4.5.1.  Client-Service (Post Transaction) . . . . . . . . . .   6
       4.5.2.  Service-Service (Post Transaction)  . . . . . . . . .   6
       4.5.3.  Service-Client (Synchronization)  . . . . . . . . . .   6
     4.6.  Mesh Service  . . . . . . . . . . . . . . . . . . . . . .   7
       4.6.1.  Catalogs  . . . . . . . . . . . . . . . . . . . . . .   7
       4.6.2.  Spools  . . . . . . . . . . . . . . . . . . . . . . .   7
       4.6.3.  Partitioning  . . . . . . . . . . . . . . . . . . . .   7
       4.6.4.  Backup  . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Protocol Binding  . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  HTTPS Presentation  . . . . . . . . . . . . . . . . . . .   8
     5.2.  DARE Message Encapsulation  . . . . . . . . . . . . . . .   8
       5.2.1.  Device Authentication . . . . . . . . . . . . . . . .   8
       5.2.2.  Profile Authentication  . . . . . . . . . . . . . . .   8
       5.2.3.  Ticket Authentication . . . . . . . . . . . . . . . .   8
     5.3.  JSON Encoding . . . . . . . . . . . . . . . . . . . . . .   8
     5.4.  JSON-B Encoding . . . . . . . . . . . . . . . . . . . . .   8
   6.  Account Management  . . . . . . . . . . . . . . . . . . . . .   8
   7.  Container Operations  . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Status  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.2.  Download  . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.3.  Upload  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Device Connection . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Device Authenticated  . . . . . . . . . . . . . . . . . .   9
     8.2.  PIN Authenticated . . . . . . . . . . . . . . . . . . . .   9



Hallam-Baker             Expires October 6, 2019                [Page 2]


Internet-Draft           Mesh Protocol Reference              April 2019


     8.3.  EARL connection mode  . . . . . . . . . . . . . . . . . .   9
   9.  Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Contact . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.2.  Confirm . . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Protocol Schema . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Request Messages . . . . . . . . . . . . . . . . . . . .   9
       10.1.1.  Message: MeshRequest . . . . . . . . . . . . . . . .  10
       10.1.2.  Message: MeshRequestUser . . . . . . . . . . . . . .  10
     10.2.  Response Messages  . . . . . . . . . . . . . . . . . . .  10
       10.2.1.  Message: MeshResponse  . . . . . . . . . . . . . . .  10
     10.3.  Imported Objects . . . . . . . . . . . . . . . . . . . .  10
     10.4.  Common Structures  . . . . . . . . . . . . . . . . . . .  10
       10.4.1.  Structure: KeyValue  . . . . . . . . . . . . . . . .  11
       10.4.2.  Structure: ConstraintsSelect . . . . . . . . . . . .  11
       10.4.3.  Structure: ConstraintsData . . . . . . . . . . . . .  11
       10.4.4.  Structure: PolicyAccount . . . . . . . . . . . . . .  12
       10.4.5.  Structure: ContainerStatus . . . . . . . . . . . . .  12
       10.4.6.  Structure: ContainerUpdate . . . . . . . . . . . . .  12
     10.5.  Transaction: Hello . . . . . . . . . . . . . . . . . . .  13
       10.5.1.  Message: MeshHelloResponse . . . . . . . . . . . . .  13
     10.6.  Transaction: Status  . . . . . . . . . . . . . . . . . .  13
       10.6.1.  Message: StatusRequest . . . . . . . . . . . . . . .  13
       10.6.2.  Message: StatusResponse  . . . . . . . . . . . . . .  14
     10.7.  Transaction: Download  . . . . . . . . . . . . . . . . .  14
       10.7.1.  Message: DownloadRequest . . . . . . . . . . . . . .  14
       10.7.2.  Message: DownloadResponse  . . . . . . . . . . . . .  15
     10.8.  Transaction: Upload  . . . . . . . . . . . . . . . . . .  15
       10.8.1.  Message: UploadRequest . . . . . . . . . . . . . . .  15
       10.8.2.  Message: UploadResponse  . . . . . . . . . . . . . .  15
       10.8.3.  Structure: EntryResponse . . . . . . . . . . . . . .  16
     10.9.  Transaction: Post  . . . . . . . . . . . . . . . . . . .  16
       10.9.1.  Message: PostRequest . . . . . . . . . . . . . . . .  16
       10.9.2.  Message: PostResponse  . . . . . . . . . . . . . . .  17
     10.10. Transaction: Connect . . . . . . . . . . . . . . . . . .  17
       10.10.1.  Message: ConnectRequest . . . . . . . . . . . . . .  17
       10.10.2.  Message: ConnectResponse  . . . . . . . . . . . . .  17
     10.11. Transaction: CreateAccount . . . . . . . . . . . . . . .  18
       10.11.1.  Message: CreateRequest  . . . . . . . . . . . . . .  18
       10.11.2.  Message: CreateResponse . . . . . . . . . . . . . .  18
     10.12. Transaction: DeleteAccount . . . . . . . . . . . . . . .  19
       10.12.1.  Message: DeleteRequest  . . . . . . . . . . . . . .  19
       10.12.2.  Message: DeleteResponse . . . . . . . . . . . . . .  19
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     14.2.  Informative References . . . . . . . . . . . . . . . . .  20



Hallam-Baker             Expires October 6, 2019                [Page 3]


Internet-Draft           Mesh Protocol Reference              April 2019


     14.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   This document describes the data structures and network protocols of
   the Mathematical Mesh illustrated with illustrative examples.  For an
   overview of the Mesh objectives and architecture, consult the
   accompanying Architecture Guide [draft-hallambaker-mesh-architecture]

   This document has two main sections.  The first section presents
   examples of using the Mesh to address common use cases.  The second
   section contains the Mesh profile and service schemas.  All the
   material in both sections is generated from the Mesh reference
   implementation [draft-hallambaker-mesh-developer] .

   Although some of the services described in this document could be
   used to replace existing Internet protocols including FTP and SMTP,
   the principal value of any communication protocol lies in the size of
   the audience it allows them to communicate with.  Thus, while the
   Mesh Messaging service is designed to support efficient and reliable
   transfer of messages ranging in size from a few bytes to multiple
   terabytes, the near term applications of these services will be to
   applications that are not adequately supported by existing protocols
   if at all.

2.  Definitions

   This section presents the related specifications and standard, the
   terms that are used as terms of art within the documents and the
   terms used as requirements language.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .

2.2.  Defined Terms

   The terms of art used in this document are described in the Mesh
   Architecture Guide [draft-hallambaker-mesh-architecture] .

2.3.  Related Specifications

   The architecture of the Mathematical Mesh is described in the Mesh
   Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh




Hallam-Baker             Expires October 6, 2019                [Page 4]


Internet-Draft           Mesh Protocol Reference              April 2019


   documentation set and related specifications are described in this
   document.

2.4.  Implementation Status

   The implementation status of the reference code base is described in
   the companion document [draft-hallambaker-mesh-developer] .

3.

4.  Protocol Transaction

4.1.  Connection Establishment

4.2.  Account Management

4.3.  Device Connection

4.4.  Container Synchronization

4.4.1.  User Experience Considerations

   Sync

   o  Status

   o  Upload outbound messages

   o  Download catalog and spool updates

   o  Upload catalog updates

   Rapid access - only take last 100 messages

   Limitation on message size ensures that

4.4.2.  Status Transaction

   Obtain updated device profile (if it exists) and the status of the
   set of catalogs the device is authorized

4.4.3.  Download Transaction

   Read objects from a catalog or spool owned by the client making the
   request.






Hallam-Baker             Expires October 6, 2019                [Page 5]


Internet-Draft           Mesh Protocol Reference              April 2019


   Optional filtering criteria MAY be specified to only return objects
   matching specific criteria and/or only return certain parts of the
   selected messages.

   The transaction MAY be performed in one request/response round trip
   or with separate round trips to confirm that the transaction is
   accepted by the service before sending large volumes of data.

4.4.4.  Upload Transaction

   Upload objects to a catalog or spool owned by Read objects from a
   catalog or spool owned by the client making the request.

   Multiple objects MAY be uploaded at once.  Object updates MAY be
   conditional on the successful completion of other upload requests.

   The transaction MAY be performed in one request/response round trip
   or with separate round trips to confirm that the transaction is
   accepted by the service before sending large volumes of data.

4.5.  Message Exchange

   Four corner model enforced.

   Messages are limited to control with very small amounts of data

   Long messages are exchanged as detachments using separate protocol
   (HTTP).

   This ensures that messages are processed quickly and reliably.  A
   server will not be blocked by receipt of a long message.

   Aggressive controls on services may be enforced to prevent DoS
   attacks.

   Post transaction is used for client-service and service-service
   transactions.

4.5.1.  Client-Service (Post Transaction)

4.5.2.  Service-Service (Post Transaction)

4.5.3.  Service-Client (Synchronization)








Hallam-Baker             Expires October 6, 2019                [Page 6]


Internet-Draft           Mesh Protocol Reference              April 2019


4.6.  Mesh Service

   Untrusted service, minimize trust to bare minimum

   Can't read content of any message.

   Can only read contact catalog entries.

4.6.1.  Catalogs

4.6.1.1.  Account

   Contains the account entries.

4.6.2.  Spools

4.6.2.1.  Account

   Log of all updates to accounts.

   Synchronization off-host provides backup.

4.6.2.2.  Incident

   Reports of potential abuse

4.6.3.  Partitioning

   Can split out handling of accounts to separate hosts each handling a
   subset of accounts.

   User clients are directed to connect to a specific host in any case
   by means of redirects.

4.6.4.  Backup

   Synchronizing Account spools protects data against loss and provides
   for fast restart capability.

5.  Protocol Binding

   Transactions consist of single request message followed by a single
   response message.

   Default binding is HTTPS/DARE/JSON

   Hello Transaction may be used to determine features supported by the
   service and the service configuration



Hallam-Baker             Expires October 6, 2019                [Page 7]


Internet-Draft           Mesh Protocol Reference              April 2019


   ```` Example ProtocolHello ````

5.1.  HTTPS Presentation

5.2.  DARE Message Encapsulation

5.2.1.  Device Authentication

   ```` Example ProtocolHelloDevice ````

5.2.2.  Profile Authentication

   ```` Example ProtocolHelloProfile ````

5.2.3.  Ticket Authentication

   ```` Example ProtocolHelloTicket ````

5.3.  JSON Encoding

5.4.  JSON-B Encoding

6.  Account Management

   ```` Example ProtocolAccountCreate ````

   ```` Example ProtocolAccountDelete ````

7.  Container Operations

7.1.  Status

   ```` Example ProtocolStatus ````

7.2.  Download

   ```` Example ProtocolDownload ````

7.3.  Upload

   ```` Example ProtocolProtocolUploadHello ````

8.  Device Connection








Hallam-Baker             Expires October 6, 2019                [Page 8]


Internet-Draft           Mesh Protocol Reference              April 2019


8.1.  Device Authenticated

   ```` Example ProtocolConnect ````

8.2.  PIN Authenticated

   ```` Example ProtocolConnectPIN ````

8.3.  EARL connection mode

   ```` Example ProtocolConnectEARL ````

9.  Mesh Messages

   All communications between accounts is performed through mesh
   messages.

   Four corner model

9.1.  Contact

   ```` Example ProtocolContact ````

9.2.  Confirm

   ```` Example ProtocolConfirm ````

10.  Protocol Schema

   HTTP Well Known Service Prefix: /.well-known/mmm

   Every Mesh Portal Service transaction consists of exactly one request
   followed by exactly one response.  Mesh Service transactions MAY
   cause modification of the data stored in the Mesh Service or the Mesh
   itself but do not cause changes to the connection state.  The
   protocol itself is thus idempotent.  There is no set sequence in
   which operations are required to be performed.  It is not necessary
   to perform a Hello transaction prior to any other transaction.

10.1.  Request Messages

   A Mesh Portal Service request consists of a payload object that
   inherits from the MeshRequest class.  When using the HTTP binding,
   the request MUST specify the portal DNS address in the HTTP Host
   field.






Hallam-Baker             Expires October 6, 2019                [Page 9]


Internet-Draft           Mesh Protocol Reference              April 2019


10.1.1.  Message: MeshRequest

   Base class for all request messages.

   [No fields]

10.1.2.  Message: MeshRequestUser

   Base class for all request messages made by a user.

   Inherits: MeshRequest

   Inherits: MeshRequest

   Account: String (Optional)  The fully qualified account name
      (including DNS address) to which the request is directed.

   DeviceProfile: DareMessage (Optional)  Device profile of the device
      making the request.

10.2.  Response Messages

   A Mesh Portal Service response consists of a payload object that
   inherits from the MeshResponse class.  When using the HTTP binding,
   the response SHOULD report the Status response code in the HTTP
   response message.  However the response code returned in the payload
   object MUST always be considered authoritative.

10.2.1.  Message: MeshResponse

   Base class for all response messages.  Contains only the status code
   and status description fields.

   [No fields]

10.3.  Imported Objects

   The Mesh Service protocol makes use of JSON objects defined in the
   JOSE Signatgure and Encryption specifications and in the DARE Data At
   Rest Encryption extensions to JOSE.

10.4.  Common Structures

   The following common structures are used in the protocol messages:







Hallam-Baker             Expires October 6, 2019               [Page 10]


Internet-Draft           Mesh Protocol Reference              April 2019


10.4.1.  Structure: KeyValue

   Describes a Key/Value structure used to make queries for records
   matching one or more selection criteria.

   Key: String (Optional)  The data retrieval key.

   Value: String (Optional)  The data value to match.

10.4.2.  Structure: ConstraintsSelect

   Specifies constraints to be applied to a search result.  These allow
   a client to limit the number of records returned, the quantity of
   data returned, the earliest and latest data returned, etc.

   Container: String (Optional)  The container to be searched.

   IndexMin: Integer (Optional)  Only return objects with an index value
      that is equal to or higher than the value specified.

   IndexMax: Integer (Optional)  Only return objects with an index value
      that is equal to or lower than the value specified.

   NotBefore: DateTime (Optional)  Only data published on or after the
      specified time instant is requested.

   Before: DateTime (Optional)  Only data published before the specified
      time instant is requested.  This excludes data published at the
      specified time instant.

   PageKey: String (Optional)  Specifies a page key returned in a
      previous search operation in which the number of responses
      exceeded the specified bounds.

      When a page key is specified, all the other search parameters
      except for MaxEntries and MaxBytes are ignored and the service
      returns the next set of data responding to the earlier query.

10.4.3.  Structure: ConstraintsData

   Specifies constraints on the data to be sent.

   MaxEntries: Integer (Optional)  Maximum number of entries to send.

   BytesOffset: Integer (Optional)  Specifies an offset to be applied to
      the payload data before it is sent.  This allows large payloads to
      be transferred incrementally.




Hallam-Baker             Expires October 6, 2019               [Page 11]


Internet-Draft           Mesh Protocol Reference              April 2019


   BytesMax: Integer (Optional)  Maximum number of payload bytes to
      send.

   Header: Boolean (Optional)  Return the entry header

   Payload: Boolean (Optional)  Return the entry payload

   Trailer: Boolean (Optional)  Return the entry trailer

10.4.4.  Structure: PolicyAccount

   Describes the account creation policy including constraints on
   account names, whether there is an open account creation policy, etc.

   Minimum: Integer (Optional)  Specifies the minimum length of an
      account name.

   Maximum: Integer (Optional)  Specifies the maximum length of an
      account name.

   InvalidCharacters: String (Optional)  A list of characters that the
      service does not accept in account names.  The list of characters
      MAY not be exhaustive but SHOULD include any illegal characters in
      the proposed account name.

10.4.5.  Structure: ContainerStatus

   Container: String (Optional)

   Container: String (Optional)

   Index: Integer (Optional)

   Index: Integer (Optional)

   Digest: Binary (Optional)

10.4.6.  Structure: ContainerUpdate

   Container: String (Optional)  The container to which the entries are
      to be uploaded.

   Message: DareMessage [0..Many]  The entries to be uploaded.  These
      MAY be either complete messages or redacted messages.  In either
      case, the messages MUST conform to the ConstraintsUpdate specified
      by the service





Hallam-Baker             Expires October 6, 2019               [Page 12]


Internet-Draft           Mesh Protocol Reference              April 2019


10.5.  Transaction: Hello

   Request: HelloRequest

   Request: HelloRequest

   Response: MeshHelloResponse

   Report service and version information.

   The Hello transaction provides a means of determining which protocol
   versions, message encodings and transport protocols are supported by
   the service.

   The PostConstraints field MAY be used to advise senders of a maximum
   size of payload that MAY be sent in an initial Post request.

10.5.1.  Message: MeshHelloResponse

   ConstraintsUpdate: ConstraintsData (Optional)  Specifies the default
      data constraints for updates.

   ConstraintsPost: ConstraintsData (Optional)  Specifies the default
      data constraints for message senders.

   PolicyAccount: PolicyAccount (Optional)  Specifies the account
      creation policy

10.6.  Transaction: Status

   Request: StatusRequest

   Request: StatusRequest

   Response: StatusResponse

10.6.1.  Message: StatusRequest

   Inherits: MeshRequestUser

   Inherits: MeshRequestUser

   DeviceUDF: String (Optional)

   DeviceUDF: String (Optional)

   Catalogs: String [0..Many]




Hallam-Baker             Expires October 6, 2019               [Page 13]


Internet-Draft           Mesh Protocol Reference              April 2019


   Catalogs: String [0..Many]

   Spools: String [0..Many]

10.6.2.  Message: StatusResponse

   Inherits: MeshResponse

   Inherits: MeshResponse

   ContainerStatus: ContainerStatus [0..Many]

   ContainerStatus: ContainerStatus [0..Many]

   CatalogEntryDevice: DareMessage (Optional)  The catalog device entry

10.7.  Transaction: Download

   Request: DownloadRequest

   Request: DownloadRequest

   Response: DownloadResponse

   Request objects from the specified container with the specified
   search criteria.

10.7.1.  Message: DownloadRequest

   Inherits: MeshRequestUser

   Request objects from the specified container(s).

   A client MAY request only objects matching specified search criteria
   be returned and MAY request that only specific fields or parts of the
   payload be returned.

   Select: ConstraintsSelect [0..Many]  Specifies constraints to be
      applied to a search result.  These allow a client to limit the
      number of records returned, the quantity of data returned, the
      earliest and latest data returned, etc.

   ConstraintsPost: ConstraintsData (Optional)  Specifies the data
      constraints to be applied to the responses.







Hallam-Baker             Expires October 6, 2019               [Page 14]


Internet-Draft           Mesh Protocol Reference              April 2019


10.7.2.  Message: DownloadResponse

   Inherits: MeshResponse

   Return the set of objects requested.

   Services SHOULD NOT return a response that is disproportionately
   large relative to the speed of the network connection without a clear
   indication from the client that it is relevant.  A service MAY limit
   the number of objects returned.  A service MAY limit the scope of
   each response.

   Updates: ContainerUpdate [0..Many]  The updated data

10.8.  Transaction: Upload

   Request: UploadRequest

   Request: UploadRequest

   Response: UploadResponse

   Request objects from the specified container with the specified
   search criteria.

10.8.1.  Message: UploadRequest

   Inherits: MeshRequestUser

   Upload entries to a container.  This request is only valid if it is
   issued by the owner of the account

   Updates: ContainerUpdate [0..Many]  The data to be updated

   Self: DareMessage [0..Many]  Entries to be added to the inbound spool
      on the account, e.g. completion messages.

10.8.2.  Message: UploadResponse

   Inherits: MeshResponse

   Response to an upload request.

   Entries: EntryResponse (Optional)  The responses to the entries.

   ConstraintsData: ConstraintsData (Optional)  If the upload request
      contains redacted entries, specifies constraints that apply to the




Hallam-Baker             Expires October 6, 2019               [Page 15]


Internet-Draft           Mesh Protocol Reference              April 2019


      redacted entries as a group.  Thus the total payloads of all the
      messages must not exceed the specified value.

10.8.3.  Structure: EntryResponse

   IndexRequest: Integer (Optional)  The index value of the entry in the
      request.

   IndexContainer: Integer (Optional)  The index value assigned to the
      entry in the container.

   Result: String (Optional)  Specifies the result of attempting to add
      the entry to a catalog or spool.  Valid values for a message are
      'Accept', 'Reject'.  Valid values for an entry are 'Accept',
      'Reject' and 'Conflict'.

   ConstraintsData: ConstraintsData (Optional)  If the entry was
      redacted, specifies constraints that apply to the redacted entries
      as a group.  Thus the total payloads of all the messages must not
      exceed the specified value.

10.9.  Transaction: Post

   Request: PostRequest

   Request: PostRequest

   Response: PostResponse

   Request to post to a spool from an external party.  The request and
   response messages are extensions of the corresponding messages for
   the Upload transaction.  It is expected that additional fields will
   be added as the need arises.

10.9.1.  Message: PostRequest

   Inherits: MeshRequest

   Inherits: MeshRequest

   Accounts: String [0..Many]  The account(s) to which the request is
      directed.

   Message: DareMessage [0..Many]  The entries to be uploaded.  These
      MAY be either complete messages or redacted messages.  In either
      case, the messages MUST conform to the ConstraintsUpdate specified
      by the service




Hallam-Baker             Expires October 6, 2019               [Page 16]


Internet-Draft           Mesh Protocol Reference              April 2019


   Self: DareMessage (Optional)  Messages to be appended to the inbound
      spool of the user's inbound spool. this is typically used to post
      notifications to the user to mark messages as having been read or
      responded to.

10.9.2.  Message: PostResponse

   Inherits: UploadResponse

   [No fields]

10.10.  Transaction: Connect

   Request: ConnectRequest

   Request: ConnectRequest

   Response: ConnectResponse

   Request information necessary to begin making a connection request.

10.10.1.  Message: ConnectRequest

   Inherits: MeshRequest

   Inherits: MeshRequest

   Account: String (Optional)

   Account: String (Optional)

   DeviceProfile: DareMessage (Optional)  Device profile of the device
      making the request.

   ClientNonce: Binary (Optional)

   ClientNonce: Binary (Optional)

   PinID: String (Optional)  Pin identifier used to identify a PIN
      authenticated request.

10.10.2.  Message: ConnectResponse

   Inherits: MeshResponse

   Inherits: MeshResponse

   ProfileMesh: DareMessage (Optional)  The account profile



Hallam-Baker             Expires October 6, 2019               [Page 17]


Internet-Draft           Mesh Protocol Reference              April 2019


   ServerNonce: Binary (Optional)  Server Nonce value used to calculate
      Witness

   Witness: String (Optional)  Witness value

10.11.  Transaction: CreateAccount

   Request: CreateRequest

   Request: CreateRequest

   Response: CreateResponse

   Request creation of a new service account.

   Attempt

10.11.1.  Message: CreateRequest

   Request creation of a new portal account.  The request specifies the
   requested account identifier and the Mesh profile to be associated
   with the account.

   Inherits: MeshRequest

   Inherits: MeshRequest

   MeshProfile: DareMessage (Optional)  The Mesh profile to be
      registered.

   CatalogEntryDevices: DareMessage [0..Many]  The device profile(s) to
      be registered in the corresponding device catalog.

   CatalogEntryContacts: CatalogEntryContact [0..Many]  The contact(s)
      to be registered in the corresponding contact catalog.  This
      should usually be populated with a contact for the user
      themselves.

10.11.2.  Message: CreateResponse

   Inherits: MeshResponse

   Reports the success or failure of a Create transaction.

   Reason: String (Optional)  Text explaining the status of the creation
      request.





Hallam-Baker             Expires October 6, 2019               [Page 18]


Internet-Draft           Mesh Protocol Reference              April 2019


   URL: String (Optional)  A URL to which the user is directed to
      complete the account creation request.

10.12.  Transaction: DeleteAccount

   Request: DeleteRequest

   Request: DeleteRequest

   Response: DeleteResponse

   Request deletion of a new service account.

   Attempt

10.12.1.  Message: DeleteRequest

   Request creation of a new portal account.  The request specifies the
   requested account identifier and the Mesh profile to be associated
   with the account.

   Inherits: MeshRequestUser

   [No fields]

10.12.2.  Message: DeleteResponse

   Inherits: MeshResponse

   Reports the success or failure of a Delete transaction.

   [No fields]

11.  Security Considerations

   The security considerations for use and implementation of Mesh
   services and applications are described in the Mesh Security
   Considerations guide [draft-hallambaker-mesh-security] .

12.  IANA Considerations

   All the IANA considerations for the Mesh documents are specified in
   this document








Hallam-Baker             Expires October 6, 2019               [Page 19]


Internet-Draft           Mesh Protocol Reference              April 2019


13.  Acknowledgements

14.  References

14.1.  Normative References

   [draft-hallambaker-mesh-architecture]
              Hallam-Baker, P., "Mathematical Mesh Part I: Architecture
              Guide", draft-hallambaker-mesh-architecture-06 (work in
              progress), August 2018.

   [draft-hallambaker-mesh-security]
              "[Reference Not Found!]".

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997.

14.2.  Informative References

   [draft-hallambaker-mesh-developer]
              Hallam-Baker, P., "Mathematical Mesh: Reference
              Implementation", draft-hallambaker-mesh-developer-07 (work
              in progress), April 2018.

14.3.  URIs

   [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-
       protocol.html

Author's Address

   Phillip Hallam-Baker

   Email: phill@hallambaker.com
















Hallam-Baker             Expires October 6, 2019               [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/