idnits 2.17.1 draft-mst-lgapi-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2364 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Stubbig 3 Internet-Draft Independent 4 Intended status: Informational October 30, 2017 5 Expires: May 3, 2018 7 Looking Glass API 8 draft-mst-lgapi-07 10 Abstract 12 This document introduces an application programming interface (API) 13 to the web-based "Network Looking Glass" software. Its purpose is to 14 provide application programmers uniform access to the Looking Glass 15 service and to analyze standardized response. 17 The API interface is supposed to provide the same level of 18 information as web-based interfaces, but in a computer-readable 19 format. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 3, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 3 59 1.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Query Parameters . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Response . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. API functions . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1. Diagnostic commands . . . . . . . . . . . . . . . . . . . 8 66 3.2. Informational commands . . . . . . . . . . . . . . . . . 9 67 3.3. Administrative commands . . . . . . . . . . . . . . . . . 10 68 3.4. Extensible commands . . . . . . . . . . . . . . . . . . . 13 69 4. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 13 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 6. Security Consideration . . . . . . . . . . . . . . . . . . . 13 72 6.1. Abuse Potential . . . . . . . . . . . . . . . . . . . . . 13 73 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 14 74 6.3. Minimal information . . . . . . . . . . . . . . . . . . . 14 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 7.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Appendix A. JSend . . . . . . . . . . . . . . . . . . . . . . . 15 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Many Internet service providers (ISPs) and Internet exchange points 84 (IXPs) offer a complimentary web page to the general public, which 85 gives insights to the backbone routing table, BGP neighbor 86 information, or offered routes. 88 The visitor may also execute a ping or traceroute command to a random 89 target address. Some ISPs even offer information about their 90 multicast routing table including the mtrace command. The amount and 91 type of offered information is not limited. 93 The service is mostly used for the purpose of troubleshooting and is 94 known under the term of "Looking Glass". The development of various 95 Looking Glass software has led to different systems in usage, syntax, 96 style, and in offered information. The difference is of minor 97 interest to human users, but accessing a Looking Glass web page by 98 script is complicated, inefficient, and error-prone. 100 Accessing a Looking Glass service by script is required for repeating 101 tasks. It could be a monitoring system which validates link 102 availability or bandwidth usage. 104 This leads to the requirement of a unified access method to the 105 information provided by a Looking Glass. This document is a proposal 106 of an application programmers interface (API), which provides a 107 common schema, list of arguments, and options when accessing a 108 Looking Glass service. 110 The transport protocol of choice is encrypted HTTP, the style of 111 operation is REST, and the response format is JSON [RFC7159]. 113 The Looking Glass API is described as a language-independent concept. 114 Consequently, any programming language, which satisfies API commands 115 listed in the following chapters, is acceptable. 117 1.1. Background 119 The requirement of a uniform access to a Looking Glass service 120 becomes important when multiple Looking Glasses are part of a 121 monitoring system. Implementing a web client and HTTP-parser for 122 every kind of web-based Looking Glass is a time consuming workaround, 123 however, the Looking Glass API is a much more viable, compatible, and 124 scalable solution. 126 1.2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 1.3. Syntax Notation 134 This specification uses the JavaScript Object Notation (JSON) of 135 [RFC7159] arranged as JSend [JSend] compliant response. 137 1.4. Examples 139 All URLs in this documentation use the reserved sample domain of 140 "example.net" as defined in [RFC6761] section 6.5. 142 IPv4 addresses use the documenational block of 192.0.2.0/24 [RFC5737] 143 and IPv6 addresses reside in the reserved prefix of 2001:DB8::/32 145 [RFC3849]. BGP Autonomous System numbers are chosen from the private 146 AS range defined in [RFC6996]. 148 The printed examples skip some required parameters for reasons of 149 simplicity. 151 2. Operation 153 An API client issues a query using the HTTP GET method to request a 154 specific resources from the API server. The resource is a URI and 155 can be informational or a command execution. The client must present 156 all necessary parameters for the API server to execute the command on 157 the selected router. Every API call is stateless and independent of 158 the previous one. 160 The "API call" is a request from the client, which specifies a pre- 161 defined operation ("API function") that the server will execute on a 162 selected router. The "command" is a task executed on the router and 163 initiated by the server on behalf of the client. The type and scope 164 of all commands is defined and limited by the server. The client 165 MUST NOT be able to execute random commands on the targeting router. 166 There MUST NOT be any direct communication between the client and the 167 router. 169 After the execution of the command on the selected router has 170 finished, the server replies to the client if the operation has 171 either succeeded, failed or timed out. The response is sent to the 172 API client in JSON format. The communication protocol used between 173 the server and router is not specified by this document; any method 174 (e.g. Telnet, SSH, NETCONF, YANG, serial console) is acceptable. 176 All parameters and its values are case insensitive. 178 2.1. Method Parameters 180 Method parameters are mandatory components of the URI and placed in 181 the "path" section in terms of [RFC7320]. Basically, the method 182 parameters specify the API call and determine which command the 183 client wants executed on the selected router. 185 2.2. Query Parameters 187 Query parameters are optional components of the URI and placed in the 188 "query" section in terms of [RFC7320]. Generally, the query 189 parameters are additional instructions for the requested command. 191 protocol 192 Restrict the command and method parameters to use the specified 193 protocol and version. Protocol is selected as "Address Family 194 Identifier" [IANA-AFN] [RFC2858] and optional "Subsequent Address 195 Family Identifier" [IANA-SAFI] separated by comma. 196 Default value is 1,1 (IP version 4, unicast). 197 JSON data type is String. 198 Examples: 200 * protocol=2,1 (IP version 6, unicast) 202 * protocol=26 (MPLS, no SAFI used) 204 router 205 Run the command on the router identified by its name. This is not 206 necessarily the routers hostname as long as the Looking Glass 207 software recognizes it. 208 Default value is the first router in the list of available 209 routers. 210 JSON data type is String. 211 Example: router=rbgn06.example.net 213 routerid 214 Run the command on this router identified by its position in the 215 list of available routers. 216 Default value is "0". 217 JSON data type is Number. 218 Example: routerid=8 220 random 221 Append a random string to prevent the client (or an intermediate 222 proxy) from caching the response. The API server must ignore its 223 value. 224 No default value. 225 JSON data type is String. 226 Example: random=517A93B50 228 runtime 229 Stop executing the command after the runtime limit (in seconds) is 230 exceeded. A value of 0 disables the limit. 231 Default value is "30". 232 JSON data type is Number. 233 Example: runtime=60 235 format 236 Request the server to provide the output (if any) in the selected 237 format. Specify multiple formats separated by comma in descending 238 order of preference. See Section 3.3.2 for more details. 239 Default value is "text/plain" (raw/unformatted output). 241 JSON data type is String. 242 Example: format=application/yang,text/plain 244 2.3. Response 246 The HTTP response header SHOULD set an appropriate HTTP status code 247 as defined in [RFC7231] and MUST set the Content-Type to 248 "application/json". 250 The HTTP body contains details and error descriptions. The response 251 text MUST comply with the JSON syntax specification JSend [JSend], 252 which is briefly explained in appendix JSend. Consequently every 253 response MUST contain a "status" field of either "success", "fail", 254 or "error", that are explained in the following sections. 256 2.3.1. Success 258 A successful response MUST set the "status" field to "success". It 259 MUST also contain a "data" object including the following 260 information: 262 performed_at 263 combined date and time in UTC ISO 8601 [iso8601] indicating when 264 the operation finished. This information MUST be present. 266 runtime 267 amount of seconds (wallclock) used to run the command. This 268 information MUST be present. 270 router 271 the name of the router, that executed the command. This 272 information MAY be present. 274 output 275 output of the command in a format that was requested by the client 276 or defaults to raw output as it appeared on the routers command 277 line interface (CLI). It might even be blank if the command did 278 not produce any output. This information SHOULD be present. 280 format 281 selected output format by the server. The client might request 282 multiple formats, so that the "Looking Glass" server has to choose 283 the best option and tell the client which format was selected. 284 This information SHOULD be present (or defaults to "text/plain" if 285 missing). 287 Adding more information to the response is permitted and MUST be 288 placed inside the "data" object. 290 The HTTP status code SHOULD be 200. 292 Example: 294 HTTP/1.1 200 OK 295 Content-Type: application/json 296 { 297 "status" : "success", 298 "data" : { 299 "router" : "route-server.lookingglass.example.net" 300 "performed_at" : "2014-10-15T17:15:34Z", 301 "runtime" : 2.63, 302 "output" : [ 303 "full raw output from the observing router..." 304 ], 305 "format" : "text/plain" 306 } 307 } 309 2.3.2. Fail 311 A status of "fail" indicates that the selected command was executed 312 on the router but failed to succeed. The response message MUST set 313 the "status" field to "fail" and MUST contain the "data" object with 314 command-specific content, that is listed in Section 2.3.1. 316 The HTTP status code SHOULD be 200. 318 Example: 320 HTTP/2.0 200 OK 321 { 322 "status" : "fail", 323 "data" : { 324 "performed_at" : "2014-10-18T20:04:37Z", 325 "runtime" : 10.37, 326 "output" : [ 327 "Sending 5, 100-byte ICMP Echos to 192.0.2.5", 328 ".....", 329 "Success rate is 0 percent (0/5)" 330 ], 331 "format" : "text/plain", 332 "router" : "route-server.lookingglass.example.net" 333 } 334 } 336 2.3.3. Error 338 The status "error" represents an error which occurred in processing 339 the request or the command timed out. The response message MUST set 340 the "status" field to "error" and MUST contain the "message" key, 341 that keeps a meaningful message, explaining what went wrong. 343 The response MAY contain the "data" key, with required values listed 344 in Section 2.3.1. It MAY also include a "code" field, that carries a 345 numeric code corresponding to the error. 347 The HTTP status code SHOULD be 400 in case of a client-side error, 348 500 in case of a server-side error or 502 for errors occurring on the 349 target router. Code 504 SHOULD be used when a command timed out. 351 Example: 353 HTTP/1.1 400 Bad Request 354 { 355 "status" : "error", 356 "message" : "Unrecognized host or address." 357 } 359 3. API functions 361 The Looking Glass API provides functions that are either mandatory or 362 optional to implement. The same principle applies to the web-based 363 Looking Glass. 365 It is not possible for any API function to modify the server's state. 366 Therefore, all HTTP methods are GET operations. 368 Variables are templated and expanded in harmony of [RFC6570]. 370 3.1. Diagnostic commands 372 3.1.1. Ping 374 Send echo messages to validate the reachability of a remote host and 375 measure round-trip time. The "ping" command MAY use the ICMP 376 protocol, but any protocol that satisfies the requirement is 377 acceptable. 379 Implementation of the ping command is mandatory. 381 Syntax: https://lg.example.net/api/v1/ping/{addr} 382 Example: 384 https://lg.example.net/api/v1/ping/2001:DB8::35?protocol=2,1 386 3.1.2. Traceroute 388 Trace path from the executing router to the destination host and list 389 all intermediate hops. 391 Implementation of the traceroute command is optional. 393 Syntax: https://lg.example.net/api/v1/traceroute/{addr} 395 Example: 397 https://lg.example.net/api/v1/traceroute/192.0.2.1?routerid=5 399 3.2. Informational commands 401 3.2.1. show route 403 Retrieve information about a specific subnet from the routing table. 405 Implementation of the "show route" command is mandatory. 407 Syntax: https://lg.example.net/api/v1/show/route/{addr} 409 Example: 411 https://lg.example.net/api/v1/show/route/2001:DB8::/48?protocol=2,1 413 3.2.2. show bgp 415 Display matching record from BGP routing table. This SHOULD include 416 networks, next hop and MAY include metric, local preference, path 417 list, weight, etc. 419 Implementation of the "show bgp" command is optional. 421 Syntax: https://lg.example.net/api/v1/show/bgp/{addr} 423 Example: 425 https://lg.example.net/api/v1/show/bgp/192.0.2.0/24 427 3.2.3. show bgp summary 429 Print a summary of BGP neighbor status. This MAY include neighbor 430 BGP ID, autonomous system number, duration of peering, number of 431 received prefixes, etc. 433 Implementation of the "show bgp summary" command is optional. 435 Syntax: https://lg.example.net/api/v1/show/bgp/summary 437 Example: 439 https://example.net/api/v1/show/bgp/summary?protocol=2&routerid=3 441 3.2.4. show bgp neighbors 443 Provide detailed information on BGP neighbor connections. Available 444 details MAY include neighbor BGP ID, advertised networks, learned 445 networks, autonomous system number, capabilities, protocol, 446 statistics, etc. 448 Implementation of the "show bgp neighbors" command is optional. 450 Syntax: https://lg.example.net/api/v1/show/bgp/neighbors/{addr} 452 Example: 454 https://lg.example.net/api/v1/show/bgp/neighbors/192.0.2.226 456 3.3. Administrative commands 458 The following administrative commands MUST be included in the 459 implementation. 461 3.3.1. router list 463 The command provides a full list of routers that are available for 464 command execution. This list includes the router ID and its name. 465 It is equivalent to the common "router" HTML drop-down form element 466 and contains the same information. 468 Syntax: https://lg.example.net/api/v1/routers 469 Example response: 471 { 472 "status" : "success", 473 "data" : { 474 "routers" : [ 475 "route-server.lookingglass.example.net", 476 "customer-edge.lookingglass.example.net", 477 "provider-edge.lookingglass.example.net" 478 ], 479 "performed_at" : "2014-10-19T20:07:01Z", 480 "runtime" : 0.73 481 } 482 } 484 3.3.2. router details 486 List additional information about the selected router, specified by 487 its router ID. The response MUST contain the routers hostname and 488 router ID. The response MAY contain more details like output format, 489 country code, city, administrative contact, vendor and model. 491 Available output formats are specified by Internet media type as of 492 [RFC6838] and listed in [IANA-MT]. If the routers supports multiple 493 formats, they are separated by comma. 495 The router might provide output formats, that are not yet registered 496 or listed in [IANA-MT]. RFC6838 [RFC6838] provides a tree for 497 unregistered subtypes. For example, output in NETCONF format could 498 use "text/x.netconf". 500 Missing output format defaults to "text/plain", which is a copy of 501 the raw command-line output. 503 Syntax: https://lg.example.net/api/v1/routers/{number} 505 Example query: 507 https://lg.example.net/api/v1/routers/1 508 Example response: 510 { 511 "status" : "success", 512 "data" : { 513 "id" : 1, 514 "name" : "customer-edge.lookingglass.example.net", 515 "format" : "text/plain,text/x.netconf", 516 "country" : "de", 517 "autonomous_system" : 64512 518 } 519 } 521 3.3.3. commands 523 This function provides a full list of commands that are available for 524 execution. The list includes mandatory, optional, and additional 525 (Section 3.4) commands. It is equivalent to the "command" HTML drop- 526 down or radio-button form element and contains the same information. 528 The list is formatted as "commands" array containing one object per 529 command. This object contains informative strings about the current 530 command: href, arguments, description and command. 532 Syntax: https://lg.example.net/api/v1/commands 534 Example response: 536 { 537 "status" : "success", 538 "data" : { 539 "commands" : [ 540 { 541 "href" : "https://lg.example.net/api/v1/show/route", 542 "arguments" : "{addr}", 543 "description" : "Print records from IP routing table", 544 "command" : "show route" 545 }, 546 { 547 "href" : "https://lg.example.net/api/v1/traceroute", 548 "arguments" : "{addr}", 549 "description" : "Trace route to destination host", 550 "command" : "traceroute" 551 } 552 ] 553 } 554 } 556 3.4. Extensible commands 558 The list of commands MAY be expanded as long as the principles of 559 this document are observed. 561 For example, a Looking Glass provider may not be offering BGP-related 562 commands because of an OSPF-based network. 564 The sample command might be: 566 https://lg.example.net/api/v1/show/ospf/database 568 4. Miscellaneous 570 The network traffic sent by a "Looking Glass" is not appropriate when 571 measuring Service Level Agreements or validating Quality of Service 572 setting. 574 If a monitoring system uses the Looking Glass API for reachability 575 checks, it SHOULD NOT rely on the HTTP status codes but on the 576 "status" message field inside the HTTP body. 578 5. IANA Considerations 580 none 582 6. Security Consideration 584 The use of HTTPS is REQUIRED to ensure a high level of security, 585 privacy, and confidentiality during transit. 587 6.1. Abuse Potential 589 The main goal of the Looking Glass API is the automated usage of the 590 Looking Glass service. This allows the scripting of API calls, which 591 could be used as a distributed Denial of Service (DDoS) attack. 592 Interestingly, the attacked system recognizes the attack originating 593 from various ISPs core network. 595 It is RECOMMENDED that implementers of the Looking Glass API take 596 steps to mitigate the above described abuse. The strategy can 597 include blocking or rate-limiting by client IP address or target IP 598 network. 600 6.2. Authentication 602 Authentication is not a requirement because the current Looking Glass 603 web services are usable without authentication. Requests to the 604 proposed API service MAY be authenticated by any method. The 605 decision is up to the implementers security requirements. 607 6.3. Minimal information 609 Some of the described commands provide a detailed insight into the 610 providers network. It is therefore up to the implementer's security 611 policy to dismiss commands that are marked as "optional" or restrict 612 commands that are marked as "mandatory". 614 7. References 616 7.1. Normative References 618 [IANA-AFN] 619 IANA, "Address Family Numbers", 2015, 620 . 623 [IANA-MT] IANA, "Media Types", 2015, 624 . 627 [IANA-SAFI] 628 IANA, "Subsequent Address Family Identifier (SAFI) 629 Parameters", 2015, 630 . 632 [JSend] OmniTI Labs, "JSend", 2013, 633 . 635 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 636 "Multiprotocol Extensions for BGP-4", RFC 2858, 637 DOI 10.17487/RFC2858, June 2000, 638 . 640 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 641 and D. Orchard, "URI Template", RFC 6570, 642 DOI 10.17487/RFC6570, March 2012, 643 . 645 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 646 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 647 2014, . 649 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 650 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 651 DOI 10.17487/RFC7231, June 2014, 652 . 654 7.2. Informative References 656 [iso8601] International Organization for Standardization, "Date and 657 time format--ISO 8601", 2006, 658 . 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, 662 DOI 10.17487/RFC2119, March 1997, 663 . 665 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 666 Reserved for Documentation", RFC 3849, 667 DOI 10.17487/RFC3849, July 2004, 668 . 670 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 671 Reserved for Documentation", RFC 5737, 672 DOI 10.17487/RFC5737, January 2010, 673 . 675 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 676 RFC 6761, DOI 10.17487/RFC6761, February 2013, 677 . 679 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 680 Specifications and Registration Procedures", BCP 13, 681 RFC 6838, DOI 10.17487/RFC6838, January 2013, 682 . 684 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 685 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 686 2013, . 688 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 689 RFC 7320, DOI 10.17487/RFC7320, July 2014, 690 . 692 Appendix A. JSend 694 According to [JSend], "JSend is a specification that lays down some 695 rules for how JSON responses from web servers should be formatted. 696 JSend focuses on application-level (as opposed to protocol- or 697 transport-level) messaging which makes it ideal for use in REST-style 698 applications and APIs." 700 A basic JSend-compliant response MUST contain a "status" key and 701 SHOULD contain "data", "message" and "code" keys dependent on the 702 status value. The following table lists the required and optional 703 keys. 705 +---------+-----------------+---------------+ 706 | Type | Required keys | Optional keys | 707 +---------+-----------------+---------------+ 708 | success | status, data | | 709 | fail | status, data | | 710 | error | status, message | code, data | 711 +---------+-----------------+---------------+ 713 Table 1: Type and keys in JSend response 715 Author's Address 717 Markus Stubbig 718 Independent 719 Germany 721 Email: stubbig.ietf@gmail.com