<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc docindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-pardue-quic-siduck-00" category="exp">

  <front>
    <title abbrev="SiDUCK">Simple Datagram Usability and Connectivity Kata</title>

    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization></organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
      </address>
    </author>

    <date year="2019" month="November" day="18"/>

    <area>Transport</area>
    <workgroup>QUIC</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes a simple application protocol for testing
implementations of the QUIC DATAGRAM frame. SiDUCK (Simple Datagram Usability
and Connectivity Kata) defines a new ALPN ID, “siduck-00”, along with a basic
offer and acknowledgement interaction using datagram payload data.</t>



    </abstract>


<note title="Note to Readers">
<t>Discussion of this document takes place on the
  QUIC Working Group mailing list (quic@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/quic/">https://mailarchive.ietf.org/arch/browse/quic/</eref>.</t>
<t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/lpardue/draft-pardue-quic-siduck">https://github.com/lpardue/draft-pardue-quic-siduck</eref>.</t>
</note>
  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The DATAGRAM frame <xref target="I-D.pauly-quic-datagram"/> for QUIC
<xref target="I-D.ietf-quic-transport"/> is an extension for the unreliable delivery of
datagrams. Applications using DATAGRAM negotiate it using Transport Parameters
but the application-specific contents are left for a higher-level mechanism.</t>

<t>HTTP/3 DATAGRAM <xref target="I-D.schinazi-quic-h3-datagram"/> defines the usage of QUIC
DATAGRAM frames when the application protocol running over QUIC is HTTP/3
<xref target="I-D.ietf-quic-http"/>, which is negotiated using ALPN <xref target="RFC7301"/> with an
identifier such as “h3-24”. The HTTP/3 DATAGRAM frame is transmitted as the QUIC
DATAGRAM frame Datagram Data field. It contains a flow identifier field that can
be used for demultiplexing applications, and an HTTP/3 Datagram Payload field
whose semantics are defined by individual applications.</t>

<t>Since the QUIC DATAGRAM and HTTP/3 DATAGRAM specifications leave the semantic
higher-order behaviour undefined, it is difficult to prove the interoperability
of implementations. This document defines SiDUCK (Simple Datagram Usability and
Connectivity Kata), a new application that maps directly to QUIC DATAGRAM and
uses the Datagram Data field directly to support a simple client-server echo
service.</t>

<t>Using QUIC DATAGRAM directly provides the benefit of avoiding complexity of
HTTP/3 session establishment and flow identifier allocation and demultiplxing.
SiDUCK’s simpler application semantics allow implementers to exercise the
interoperability of foundational layers of DATAGRAM, building progressive
assurance that benefits the design and robustness of other DATAGRAM-using
applications.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>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 <xref target="RFC2119"/>.</t>

<t>The terms sh-token and sh-boolean are imported from
<xref target="STRUCTURED-HEADERS"/>.</t>

<t>Example HTTP requests and responses use the HTTP/2-style formatting from
<xref target="RFC7540"/>.</t>

<t>This document uses the variable-length integer encoding from
<xref target="I-D.ietf-quic-transport"/>.</t>

</section>
</section>
<section anchor="negotiating-siduck" title="Negotiating SiDUCK">

<t>SiDUCK is an application protocol that runs atop QUIC. The token “siduck” is
used to identify SiDUCK in ALPN, used during QUIC connection establishment. Only implementations of the final, published RFC can identify themselves as “siduck”. Until such an RFC exists, implementations MUST NOT identify themselves using this string.</t>

<t><list style='empty'>
  <t><spanx style="strong">RFC Editor’s Note:</spanx>  Please remove the following prior to publication of a
final version of this document.</t>
</list></t>

<t>Implementations of draft versions of the protocol MUST add the string “-“ and
the corresponding draft number to the identifier. For example,
draft-pardue-quic-siduck-00 is identified using the string “siduck-00”.</t>

<t>Non-compatible experiments that are based on these draft versions MUST append
the string “-“ and an experiment name to the identifier. For example, an
experimental implementation based on draft-pardue-quic-siduck-09 which extends
the permitted message types to include “honk” might identify itself as “siduck-09-goose”. Note
that any label MUST conform to the “token” syntax defined in Section 3.2.6 of
<xref target="RFC7230"/>.</t>

</section>
<section anchor="protocol-behaviour" title="Protocol Behaviour">

<t>A SiDUCK session consists of a client and server. Once a SiDUCK session is
established, the client SHOULD send a QUIC DATAGRAM frame with the Datagram Data
field containing “quack”. A server that receives a quack, MUST respond with a
QUIC DATAGRAM frame with the Datagram Data field containing “quack-ack”.</t>

<t>A client MUST NOT send any other message than “quack”. A server that receives a non-quack message MUST close the connection with an error of type SIDUCK_ONLY_QUACKS_ECHO.</t>

</section>
<section anchor="the-siduckonlyquacksecho-error-code" title="The SIDUCK_ONLY_QUACKS_ECHO error code">

<t>This document defines the SIDUCK_ONLY_QUACKS_ECHO QUIC Application error code. It has the value 0x101.</t>

</section>
<section anchor="known-issues-problems" title="Known Issues / Problems">

<t><list style="symbols">
  <t>The design does not permit large DATAGRAM frames. Sending these in a simple
application protocol would be beneficial and within the scope of SiDUCK’s
goals.</t>
  <t>The design does not specify requirements on Transport Parameters. For example,
since streams are not used, the spec could require that endpoints send
max_streams_{bidi|uni} with the value 0.</t>
</list></t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>There are not believed to be any further security considerations beyond those
presented in <xref target="I-D.ietf-quic-transport"/>.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>TBD</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor="I-D.pauly-quic-datagram">
<front>
<title>An Unreliable Datagram Extension to QUIC</title>

<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
    <organization />
</author>

<author initials='E' surname='Kinnear' fullname='Eric Kinnear'>
    <organization />
</author>

<author initials='D' surname='Schinazi' fullname='David Schinazi'>
    <organization />
</author>

<date month='October' day='22' year='2019' />

<abstract><t>This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-pauly-quic-datagram-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-04.txt' />
</reference>



<reference anchor="I-D.ietf-quic-transport">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>

<author initials='J' surname='Iyengar' fullname='Jana Iyengar'>
    <organization />
</author>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='September' day='11' year='2019' />

<abstract><t>This document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation.  Note to Readers  Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at &lt;https://mailarchive.ietf.org/arch/search/?email_list=quic>.  Working Group information can be found at &lt;https://github.com/ quicwg>; source code and issues list for this draft can be found at &lt;https://github.com/quicwg/base-drafts/labels/-transport>.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-quic-transport-23' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-quic-transport-23.txt' />
</reference>



<reference  anchor="RFC7301" target='https://www.rfc-editor.org/info/rfc7301'>
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
<author initials='S.' surname='Friedl' fullname='S. Friedl'><organization /></author>
<author initials='A.' surname='Popov' fullname='A. Popov'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></author>
<date year='2014' month='July' />
<abstract><t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t></abstract>
</front>
<seriesInfo name='RFC' value='7301'/>
<seriesInfo name='DOI' value='10.17487/RFC7301'/>
</reference>



<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference anchor="STRUCTURED-HEADERS">
<front>
<title>Structured Headers for HTTP</title>

<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
    <organization />
</author>

<author initials='P' surname='Kamp' fullname='Poul-Henning Kamp'>
    <organization />
</author>

<date month='October' day='31' year='2019' />

<abstract><t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header fields.  It is intended for use by specifications of new HTTP header fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-header-structure-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-structure-14.txt' />
</reference>



<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.schinazi-quic-h3-datagram">
<front>
<title>Using QUIC Datagrams with HTTP/3</title>

<author initials='D' surname='Schinazi' fullname='David Schinazi'>
    <organization />
</author>

<date month='October' day='21' year='2019' />

<abstract><t>The QUIC DATAGRAM extension provides application protocols running over QUIC with a mechanism to send unreliable data while leveraging the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document defines how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3 by adding an identifier at the start of the frame payload.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-schinazi-quic-h3-datagram-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-schinazi-quic-h3-datagram-01.txt' />
</reference>



<reference anchor="I-D.ietf-quic-http">
<front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>

<author initials='M' surname='Bishop' fullname='Mike Bishop'>
    <organization />
</author>

<date month='September' day='12' year='2019' />

<abstract><t>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-quic-http-23' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-quic-http-23.txt' />
</reference>



<reference  anchor="RFC7540" target='https://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>




    </references>


<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to Andy Stitzer who achieved interop of an unpublished early SiDUCK
specification during the IETF 106 Hackathon.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAIDv0V0AA41Y227kNhJ951dwPQ+7O2h1fJkkmAZ2sx3bEzfGYztu+yFY
LAxKYncTlkgNSbXdmTWQD8n+XL5kT5GU+mI7yYNhWSKLdTl16tBZljGvfCVH
fKrqppL8RHgxt6Lmt07kqlJ+xYUu+bHRWhZeLenFR6xhIs+tXNK+k9vjj6w0
hRY17JRWzHzWCFu2MvvcqiJzqmyL+2x/nxXCy7mxqxGXjw1jqrEj7m3r/OH+
/vv9QyasFCN+Y4V2jbGePRh7P7embUb8x9vJMbuXK7wqR3yivbRa+uyETmPM
eTh5Jyqj4cFKOtaoEf+3N8WAwzGlS6n9gDvYtHLm8LSq04O3qsCnwtSNSA81
FuOT0pXS8j+MidYvjB0xzjP8cHxwI34+5FchxvAqhn7eFsJtvpa1UNWIV/Q+
ZmR4+G747b/m9H6IoxjTxtYCeZUj5EPPNv7KsoyLHA7CL8ZuFspRLC15x0vp
Cqty6bjgLhZONE2lkGBlNG+sQeym4rDHvXRe6TkLy2h3WOO4mXG/kCGx/GR8
M/7hevyJz1B6OUxF5X97FRTsRVD8HY7NkDRyS8sHPj6/uuCTkwHf6zGwN+BU
pjl/UH6BZblwqmBmNpM2AE0U99o8VLKcB1+RbFQaGaCwWoc4eNk504hVZUQZ
XgxjvmpVlpVk7A0hxBqcSRspe3InRv7ly18m2cmwEW21ijjtDD89hbwFxKVV
SvpZXOQ7cGIVKiI0oOylduRfyDZOarWVlRI5MlfiYSntCtlmnX035ON1sVwK
q3dPo0W8Qqdw5dO3viMIXHAeKXEsb304baPwmWtkoWaqAIyRN8CYo6V4JWc+
OCf4Qs0X0maVXMqK17JYCK1cjeyd3dxcfXW09uLLl+8ocFcslBY/qxj84mgz
SV2tQ8hOzCVBKmRtO9WOPyyk3vV1DVLbak1RGiQqwhGJjf6w5MY6/wvvm6en
AUyqYkEL+3SVKVkBdKjb9Yfjb4/2D+BohJpmimgA6cExrsVuNOseQjp8tzfk
hJDdHESg4IxQ9Fp5OkS4vm124ly3CT1wnFOVQz7xoRgCrIH8zyrzwDf8CItg
UGAVPMwpkziEilXKuq28Qv89UlgbqQM5hVbRvcfdwVepJYJZ9rAwTnIHFsJx
RcRCLFrJ8xVaq0Trlq2otowDDFOlC/kCO9Cpu0nqIJfAXEmxjFu7c1nCHIgb
AedyIZbKtBZdknwZENCJ3dQMdhAz94bQkewEBjANWCBRD1C2w2VUvm16jMj8
QxqjiNhzGhsk/tqEa6hRLRry02J5tSI3n+WHoX4RIS+gYWura5vQ0j2DF5WC
85mTlhoBvWkYPatCoiS3Advbx/XWKFkAVTw3lxrhe2pGsTSqpH003ghHPhBR
KiEcDbSF+QCuUm4Rckc13kWpqCqT0kCfe2QSMIcsZvmvLsVht9K2gb4qWO0q
BwqjLMhHaQvlQqnZbqkphpkBUIIt4LQSK9qH110SBjxvVRWCRBbmlmJaSiac
a9G0AcWoW8pJTBASpeYxEmtyqA9AJdg0+Gp7y1mgE7bTGm/e8AvjO38AnSVl
Cd/ikIFC4SRRwCyfbqc3mHbhN7+4DM/Xp6jg9ekJPU/Pxufn/UO3Ynp2eXuO
7yw9rXceX376dHpxEjd/Gv+0F1lg7/LqZnJ5MT7fQ6cgvs0+oIZHjvOU2cbK
xGCdfihpT+TKw4OD909PwxgGFteo5yLz5l7GVOGP3Bi0tw5mUUeAl6jKQsbA
xPTm+vb45hbBZWen45PT6+k/euYm0s6VyxZSgAMyaBoM5tbKcN7powjwJ1Ry
Kz+3wKOL1ZEYepr6qY0AieRzCAMrbIhiibRN58R3xPlfv9tPcWymom/LpbBh
NGMG6jnmAmVmTv2mC1Nu2Hp97sM2BMZFmju0JWng1AlJF7w46wIaMfCwwpsm
9HOcPTHRSSehlI6FQYDqpT5cdWyGitGIG8RJUba2J4YiEdluTw/5pQZLvCIA
QZWiGvCmDethEkmkYbQ+GKtqJ6sl6TrX+zjkt/hcpVGqwzZQjAvaeeeorgde
tBnHdkAuyXGiFPZP/vYtGTwtlTcW3IKmk6O3bzm/AgSBBivrbkDMDDFLZABF
EszEYFLuiQdhL4TJwawuvdxqFRw5eZ6ecJfp9vQJ64sZohJlGcddcJ3/9suv
GX7CKKDXhbERxgFb0aBu61wGP8N863l2yD/AfRn7YcB+5yZFEOv3lX0GN73o
1/72y/8Q3QXUYbjkeEW6FPcvaVW46URMUk9Di8NYmHUSKd6JPkbbNDJF9jzg
qIY7w+FS9EdBkixbb0GBtpGzdun1ZLxPWjDo8NIF32AwyTXIzyBN/aqRYeBA
2lRtKaH8jEaj1RAnfg1LzAhZzQjmGyl8n80NlBQlMuCQxYzpFeZRLhMO0HxE
SF3A2B5aGptw20Q4j730QgNPU5seDQ+H39BITnr18Chy1xt+1YHs+04wMTbu
KKCb3DjTUcMFjCf9EMk6aAjqe0xAsbsN5NLzA8mvgNO4OQ0dJ6maL90No5h+
pm9Y1DdJ6RIu9j63IrDEOHmTuE8WUgUm4WHBIGYv9UiS6uzPH8xfOTgLh1PO
UmQ9BcXYULw47nuA4Cr0J5zW6KOwqN8Yq1+ZNKI2SDjdO7i0FpAn9gAI+XRC
xbi7vDj/6e7H2/Hxx+nd6fHZZag6TYJXvicrGFLy+X8D1hex13aHjG5cOzfM
hTvKQnTjsWol33882D8IHn3EbVzzCeQUDviKYAn6qKF23gZnk5YqDb5q41Pj
oS/sfPfGDZU+lZEGI7+gDzrty/jL4/LBtChu3onaQtFdJcFExSulKyAYKbmd
DIWtuREVxNrLLsYLyypIDQjoyIE49KVL9g4jc7hLHQXqk7jHB9IkkzSJYxuR
cSSVvE72I4IQeGMUnUTwg6FaPN4lM3dfcqj0/7ZaPa1BnuoQtQboAmMeeviY
Gh4SSqwlJ07o3AAXKVzsy6j5AsZnrQ0od52FYssClq2o7TzdFBn0oSNl3qnC
31NAb/hkfDF+7tD3J/E/MTlahFaNt/+fE3wW+j5Q8ViXUDVe+Z/hIS6rXBSL
GEC6CARe07gprsWJFLbqpBDbunt2UoiyNzm9+cAP9r/hZ3BDIDo9ZP8HdmTG
hOwUAAA=

-->

</rfc>

