The QR code protocol builds upon the work by [SQRL
]. That protocol is very briefly described in Section 3.1
. Then, the list of needed Data Records to be filled in is explained.
] documents an octet protocol that can be efficiently encoded into QR codes using a sequence of US-ASCII bytes, plus six control codes (see Section 3.1 of [SQRL
<RS> Record Separator (US-ASCII 30)
<EoT> End of Transmission (US-ASCII 4)
<FS> Field Separator (US-ASCII 28)
<GS> Group Separator (US-ASCII 29)
<US> Unit Separator (US-ASCII 31)
Concatenation Operator (US-ASCII 43: "+")
Section 7.2 of [SQRL
] gives the details, which can be summarized as:
The QR code header starts with:
"[)>" <RS> "06" <GS> "12N"
Include one or more Data Records. This consists of a four-letter Field Identifier, followed by US-ASCII characters terminated with a <Unit Separator>.
Additionally, there are optional flags that may be present in every Data Record, as described in Section 7.4 of [SQRL
]. These flags have no bearing on MUD processing. A parser that is only collecting MUD URLs will not need to parse those flags. A general-purpose SQRL parser will need more complexity.
Field Separator characters are used in SQRL to signify the beginning of a new unit of data. A MUD-specific parser that encounters a Field Separator and has not yet collected the right MUD information MUST
ignore the characters collected so far and then restart.
Environment records, as described in Section 7.4 of [SQRL
], look and act exactly as fields, with a special Field Identifier. They serve no purpose when looking for MUD information and MAY
The B000 Data Record is mandatory in [SQRL
]. It MUST
be in US-ASCII representation. It should be a representation of the company or brand name. It SHOULD
match the ietf-mud/mud/mfg-name in the MUD file; however, the MUD file can contain arbitrary UTF-8 for this name, while the SQRL files are expected to be 7-bit US-ASCII.
The B001 Data Record is optional in [SQRL
]. It is the Product Name in US-ASCII. Its presence is RECOMMENDED
. Some third parties that create QR code stickers might not know the product name with 100% certainty and MAY
prefer to omit this rather than create further confusion.
The B002 Data Record is optional in [SQRL
] but is MANDATORY in this profile. It is the Model Name in US-ASCII. It SHOULD
match the optional ietf-mud/mud/model-name in the MUD file if that entry is present in the MUD file. MUD files can contain arbitrary UTF-8 for the model-name, while the SQRL files are expected to be 7-bit US-ASCII.
If a third party that is creating QR codes cannot locate an official model number when creating their MUD file and QR code, then the third party SHOULD
make one up.
A new Field Identifier has been assigned by the Reverse Logistics Association, which is "M180". This record MUST
be filled with the MUD URL.
Short URLs are easier to encode into a QR code because they require fewer pixels of QR code. More content in the QR code requires a bigger image.
Use of URL shortening services (see [URLshorten
]) can be useful, provided that the service is stable throughout the lifetime of the device and QR code and that the privacy stance of the service is well understood. The Security Considerations section of [RFC 3986
] applies, particularly Section 7.1
Section 8.1 of [SQRL
] also has some good advice on longevity concerns with URLs.
The URL provided MUST NOT
have a query (?) portion present. If one is present, the query portion MUST
be removed before processing.
If a Media Access Control (MAC) address is used as a unique device identifier (which is RECOMMENDED
if possible), then it MUST
be included in this Data Record.
Section 9.10 of [SQRL
] defines the Data Record "M06C" as the MAC address. No format for the MAC address is provided in that document.
In this document, it is RECOMMENDED
that 12 (or 16) hex octets are used with no spaces or punctuation. (16 octets are used in the IEEE 64-bit Extended Unique Identifier (EUI-64) format used in [IEEE.802.15.4
] and some next generation Ethernet proposals). In this document, it is RECOMMENDED
that uppercase hexadecimal letters be used.
Parsers that find punctuation (such as colons (":"), dashes ("-"), US-ASCII Space (32), US-ASCII TAB (0), US-ASCII linefeed (10), or US-ASCII carriage return (13)) MUST
skip over the punctuation. Parsers MUST
tolerate hexadecimal in uppercase, lowercase, and even mixed case. Systems SHOULD
canonicalize it to uppercase.