RFC 7472

Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme

📅 published March 2015, from ietf

Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme 🎀

okay bestie, this is RFC 7472 ✨ and it's giving official IETF Standards Track energy. It was published in March 2015 as Request for Comments 7472, with ISSN 2070-1721. The two authors are I. McDonald from High North, Inc. and M. Sweet from Apple, Inc. 💅 It updates RFC 2910 and RFC 2911, but it doesn't obsolete anything, so nothing gets replaced 🙈

Abstract ✨

so the big idea here is an IPP over HTTPS transport binding plus a matching 'ipps' URI scheme 🔐 The scheme is how you point at the network location of a secure IPP print service, or at a network resource that one of those services manages. 🖨️

this doc sets up an alternate IPP transport binding compared to the one in the original IPP URL Scheme (RFC 3510). BUT it does not update or obsolete RFC 3510, so that one's still around and totally fine 💜

it also updates RFCs 2910 and 2911 🌸

Status of This Memo 🌈

this one is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the whole IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want the deets on Internet Standards, check out Section 2 of RFC 5741 📚

you can find the current status, any errata, and where to send feedback at http://www.rfc-editor.org/info/rfc7472 💌

the copyright is held by the IETF Trust and the people listed as the document authors, 2015, all rights reserved ⭐

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 🫶

any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes 🔥

this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍

Table of Contents 📖

   1. Introduction ....................................................3
      1.1. Structure of This Document .................................4
      1.2. Rationale for This Document ................................5
   2. Conventions Used in This Document ...............................5
      2.1. Requirements Language ......................................5
      2.2. Printing Terminology .......................................5
      2.3. Abbreviations ..............................................6
   3. IPP over HTTPS Transport Binding ................................7
   4. Definition of 'ipps' URI Scheme .................................8
      4.1. Applicability of 'ipps' URI Scheme .........................8
      4.2. Syntax of 'ipps' URI Scheme ................................8
      4.3. Associated Port for 'ipps' URI Scheme .....................10
      4.4. Character Encoding of 'ipps' URI Scheme ...................10
      4.5. Examples of 'ipps' URIs ...................................11
      4.6. Comparisons of 'ipps' URIs ................................12
   5. IANA Considerations ............................................12
   6. Security Considerations ........................................13
      6.1. Problem Statement .........................................13
           6.1.1. Targets of Attacks .................................14
           6.1.2. Layers of Attacks ..................................14
      6.2. Attacks and Defenses ......................................14
           6.2.1. Faked 'ipps' URI ...................................15
           6.2.2. Unauthorized Access by IPP Client ..................15
           6.2.3. Compromise at Application Layer Gateway ............15
           6.2.4. No Client Authentication for 'ipps' URI ............15
      6.3. TLS Version Requirements ..................................16
   7. References .....................................................16
      7.1. Normative References ......................................16
      7.2. Informative References ....................................17
   Acknowledgments ...................................................19
   Authors' Addresses ................................................19

1. Introduction 🎀

so this doc defines the IPP over HTTPS transport binding and the 'ipps' URI scheme, which is used to designate access to the network location of a secure IPP print service (or a network resource managed by one) 🖨️✨

it was submitted to the IETF by the Internet Printing Protocol Working Group (WG) of the IEEE-ISTO Printer Working Group. It's part of their PWG "IPP Everywhere" (PWG 5100.14) project, which is all about secure mobile printing with vendor-neutral Client software 📱💜

again, this is an alternate transport binding to the one in the original IPP URL Scheme [RFC3510], and it does not update or obsolete [RFC3510] 🦋

this doc updates two things:

a) "Internet Printing Protocol/1.1: Encoding and Transport" [RFC2910]. It extends Section 4 ("Encoding of Transport Layer"), Section 5 ("IPP URL Scheme"), and Section 8.2 ("Using IPP with TLS") to add the brand new standard URI scheme of 'ipps' for IPP Printers 🔐

b) "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911]. It extends Section 4.1.6 ("uriScheme") and Section 4.4.1 ("printer-uri-supported") to add that same 'ipps' URI scheme for IPP Printers 🌸

these are the IPP versions currently defined:

  • a) 1.0 in [RFC2566] (obsolete) 🫠
  • b) 1.1 in [RFC2911] 💅
  • c) 2.0 in [PWG5100.12] 🔥
  • d) 2.1 in [PWG5100.12] ⭐
  • e) 2.2 in [PWG5100.12] 👑

if you want IPP overviews, check out Section 1 of [RFC2911], Section 1 of [RFC3196], and Section 1 of PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12] 📚

1.1. Structure of This Document 🧚

here's how the doc is laid out, bestie:

Section 2 covers the conventions and terms used throughout the document 💖

Section 3 defines the IPP over HTTPS transport binding 🔐

Section 4 defines the 'ipps' URI scheme 🦋

Sections 5 and 6 are the IANA and security considerations, respectively 🛡️

Section 7 has the references 📚

1.2. Rationale for This Document 🙈

so why does the 'ipps' URI scheme even exist? Three reasons, and they're kind of messy 😭

  1. Some existing IPP Client and IPP Printer implementations of "Upgrading to TLS Within HTTP/1.1" [RFC2817] are flawed and unreliable. This is NOT because of spec defects in [RFC2817] itself, so no blame there 💀
  2. Some existing IPP Client and IPP Printer implementations of HTTP upgrade [RFC2817] don't do the upgrade at the beginning of every HTTP [RFC7230] connection. Instead they only switch to secure IPP for selected IPP operations. Honestly that's inherently dangerous behavior on the same underlying TCP [RFC793] connection 😬
  3. An IPP Printer server-mandated HTTP upgrade [RFC2817] can still leak IPP Client data if the Expect request header isn't used. Basically, the IPP Client can send its whole Print-Job request before the IPP Printer even gets a chance to respond and say, "Wait! You need to encrypt first!" 🫣

2. Conventions Used in This Document 💜

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. Printing Terminology 🖨️

you need to be familiar with the printing terms defined in "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911], plus the ones below 📖

  • IPP Client: the software (on some hardware platform) that submits IPP Job creation and IPP Printer and IPP Job management operations to an IPP Printer. It does this via the IPP over HTTP transport binding defined in the IPP/1.1 Encoding and Transport document [RFC2910] and/or the IPP over HTTPS transport binding defined in Section 3 of this specification. The IPP Printer can be a print spooler, a print gateway, or a physical printing device 🧑‍💻
  • IPP Job: the set of attributes and documents for one print job, instantiated in an IPP Printer 📄
  • IPP Job object: a synonym for IPP Job 🔁
  • IPP Printer: the software (on some hardware platform) that receives IPP Job creation and IPP Printer and IPP Job management operations from an IPP Client. It gets them via the IPP over HTTP transport binding defined in the IPP/1.1 Encoding and Transport document [RFC2910] and/or the IPP over HTTPS transport binding defined in Section 3 of this specification 🖨️
  • IPP Printer object: a synonym for IPP Printer 🔁
  • 'ipps' URI: a URI using the 'ipps' URI scheme defined in Section 4 of this specification 🦋

2.3. Abbreviations 🔤

this doc uses the following abbreviations. They're listed with their expanded forms and references, in case you want to go deeper 🤓

3. IPP over HTTPS Transport Binding 🎀

okay so this section defines an alternate IPP over HTTPS transport binding 💖 for the abstract protocol from "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] and IEEE-ISTO PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12]. clean layering, no notes ✨

when you see an 'ipps' URI, an IPP Client MUST establish an IPP application-layer connection by going through these steps in order 💅:

  1. the IPP Client picks an 'ipps' URI value from a "printer-uri-supported" Printer attribute [RFC2911], a directory entry, discovery info, a web page, etc.;
  2. the IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230] (swapping 'ipps' for 'https' and adding the port number from the URI, or port 631 if the URI doesn't have an explicit port number) 🦋;
  3. the IPP Client sets up an HTTPS [RFC7230] secure session layer connection to the target endpoint; and
  4. the IPP Client sends requests to and gets responses from the target IPP application-layer resource over that HTTPS [RFC7230] secure session layer connection, using the POST method defined in [RFC7231] 🫶.

4. Definition of 'ipps' URI Scheme 🧚

4.1. Applicability of 'ipps' URI Scheme

ok so per PWG "IPP Everywhere" [PWG5100.14], in IPP exchanges the 'ipps' URI scheme MUST only be used:

  • a) to specify an absolute URI for IPP secure print services and their associated network resources;
  • b) to specify the use of the abstract protocol defined in "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] and IEEE-ISTO PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12]; and
  • c) to specify the use of the transport binding defined in this document.

the 'ipps' scheme lets an IPP Client pick an appropriate IPP secure print service, for example from a directory 📂. the client can open an HTTPS connection to that service, then send IPP requests (like Print-Job requests) and get IPP responses back over that same connection 💜.

👀 See: Section 4.2 ("Syntax of 'ipps' URI Scheme") of this document.

👀 See: Section 4.4.1 ("printer-uri-supported") in [RFC2911].

👀 See: Section 5 ("IPP URL Scheme") in [RFC2910].

👀 See: Section 4 ("IPP Standards") of IEEE-ISTO PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12].

4.2. Syntax of 'ipps' URI Scheme

the abstract protocol defined in [RFC2911] puts a limit of 1023 octets (NOT characters) on URI length 🙈.

👀 See: "Uniform Resource Identifier (URI): Generic Syntax" [STD66].

per PWG "IPP Everywhere" [PWG5100.14], for compatibility with existing IPP implementations, IPP Printers SHOULD NOT generate 'ipp' [RFC3510] or 'ipps' URIs (or let administrators configure them) with lengths above 255 octets, because lots of older IPP Client implementations don't properly support those lengths 💀.

per PWG "IPP Everywhere" [PWG5100.14], in IPP exchanges, 'ipps' URIs MUST be represented in absolute form. Absolute URIs always begin with a scheme name followed by a colon. for the official word on URI syntax and semantics, check "Uniform Resource Identifier (URI): Generic Syntax and Semantics" [STD66]. this spec borrows the definitions of "host", "port", and "query" from [STD66], and the definition of "absolute-path" from [RFC7230] ✨.

the 'ipps' URI scheme syntax in ABNF [STD68] looks like this:

ipps-uri =
    "ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]]

per [RFC2910], if the port is empty or not given, then port 631 MUST be used.

👀 See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this document.

the semantics are that the identified resource (see [RFC7230]) lives at the IPP secure print service listening for HTTPS connections on that port of that host, and the Request-URI for the identified resource is 'absolute-path' 🌸.

Note: the higher-level "authority" production is not imported from [STD66], because it includes an optional "userinfo" component that cannot be used in 'ipps' URIs.

Note: the "query" production does not have defined semantics in IPP, and it was never used in examples in the IPP/1.1 Encoding and Transport document [RFC2910] or the original IPP URL Scheme [RFC3510]. the "query" is kept here for consistency, but IPP Clients SHOULD avoid its use (because the semantics would be implementation defined) 🤷‍♀️.

Note: per PWG "IPP Everywhere" [PWG5100.14], literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' URIs, because:

  • a) IP addresses are often changed after network device installation (for example, based on DHCP reassignment after a power cycle);
  • b) IP addresses often don't map simply to security domains;
  • c) IP addresses are difficult to validate with X.509 server certificates (because they do not map to common name or alternate name attributes); and
  • d) IP link local addresses are not "portable" due to link identity.

per [RFC2910], if the 'absolute-path' is not present in an IPP URI, it MUST be given as "/" when used as a Request-URI for a resource (see [RFC7230]). an 'ipps' URI becomes an 'https' URI by replacing "ipps:" with "https:" and inserting port 631 (if there isn't an explicit 'port' in the original 'ipps' URI) 🦋.

👀 See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this document.

4.3. Associated Port for 'ipps' URI Scheme

per [RFC2910], all 'ipps' URIs that do NOT explicitly specify a port MUST be resolved to IANA-assigned well-known port 631, which is already registered in [PORTREG] by [RFC2910] 🔥.

Note: per direction of the IESG, as described in [RFC2910], port 631 is used for all IPP connections (with or without TLS [RFC5246]). So port 631 is used for both 'ipp' [RFC3510] and 'ipps' URIs, which both refer to an IPP Printer or a network resource managed by an IPP Printer. IPP Printer implementors can look at the CUPS [CUPS] source code for an example of incoming connection handling for the dual use of port 631 👑.

👀 See: IANA Port Numbers Registry [PORTREG].

👀 See: [RFC2910].

4.4. Character Encoding of 'ipps' URI Scheme

per PWG "IPP Everywhere" [PWG5100.14], 'ipps' URIs MUST:

  • a) Use the UTF-8 [STD63] charset for all components; and
  • b) Use [STD66] rules for percent encoding data octets outside the US-ASCII-coded character set [ASCII].

4.5. Examples of 'ipps' URIs

here are some well-formed 'ipps' URIs for IPP Printers (for example, to be used as protocol elements in 'printer-uri' operation attributes of Print-Job request messages) 🍓:

    ipps://example.com/
    ipps://example.com/ipp
    ipps://example.com/ipp/faxout
    ipps://example.com/ipp/print
    ipps://example.com/ipp/scan
    ipps://example.com/ipp/print/bob
    ipps://example.com/ipp/print/ira

Note: using an explicit 'ipp' path component followed by an explicit 'print', 'faxout', 'scan', or other standard or vendor service component is best practice per [PWG5100.14], [PWG5100.15], and [PWG5100.17] 💅.

each of the URIs above is a well-formed URI for an IPP Printer, and each one would reference a logically different IPP Printer, even though some of those IPP Printers might share the same host system 🌈. note that 'print' might represent some grouping of IPP Printers (for example, a load-balancing spooler), while the 'bob' or 'ira' last path components might represent two different physical printer devices. or 'bob' and 'ira' might represent separate human recipients on the same physical printer device (for example, a physical printer supporting two job queues). either way, both 'bob' and 'ira' would behave as different and independent IPP Printers 🧚.

here are some well-formed 'ipps' URIs for IPP Printers with (optional) ports and paths:

    ipps://example.com/
    ipps://example.com/ipp/print
    ipps://example.com:631/ipp/print

the first and second 'ipps' URIs above will be resolved to port 631 (the IANA-assigned well-known port for IPP). the second and third 'ipps' URIs above are equivalent (see Section 4.6) 🫶.

👀 See: Sections 4.2 ("Syntax of 'ipps' URI Scheme") and 4.3 ("Associated Port for 'ipps' URI Scheme") in this document.

4.6. Comparisons of 'ipps' URIs

per PWG "IPP Everywhere" [PWG5100.14], when comparing two 'ipps' URIs to decide whether or not they match, an IPP Client MUST use the same rules as those defined for 'http' and 'https' URI comparisons in [RFC7230], with the following single exception:

  • A port that is empty or not given MUST be treated as equivalent to the well-known port for that 'ipps' URI (port 631).

👀 See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this document.

👀 See: Section 2.7.3 ("http and https URI Normalization and Comparison") in [RFC7230].

5. IANA Considerations 🌸

IANA has registered the new keyword value 'ipps' for the IPP Printer "printer-uri-supported" attribute in the IANA IPP Registry [IPPREG], per Section 6.2 ("Attribute Extensibility") of [RFC2911], as follows.

IANA has registered the 'ipps' URI scheme using the following template, which conforms to [BCP35]:

  • URI scheme name: ipps
  • Status: Permanent
  • URI scheme syntax: See Section 4.2 of RFC 7472.
  • URI scheme semantics: the 'ipps' URI scheme is used to designate secure IPP Printer objects (print spoolers, print gateways, print devices, etc.) on Internet hosts accessible using the IPP enhanced to support guaranteed data integrity and negotiable data privacy using TLS [RFC5246] as specified in HTTP/1.1 [RFC7230].
  • Encoding Considerations: See Section 4.4 of RFC 7472.
  • Applications/protocols that use this URI scheme name: the 'ipps' URI scheme is intended to be used by applications that need to access secure IPP Printers using the IPP enhanced to support guaranteed data integrity and negotiable data privacy using TLS [RFC5246] as specified in HTTP/1.1 [RFC7230]. Such applications may include (but are not limited to) IPP-capable web browsers, IPP Clients that wish to print a file, and servers (for example, print spoolers) wishing to forward a Job for processing.
  • Interoperability Considerations: the widely deployed, open source IPP print service CUPS [CUPS] (on most UNIX, Linux, and Apple OS X systems) has supported 'ipps' URI for several years before the publication of this document. PWG "IPP Everywhere" [PWG5100.14] (IPP secure, mobile printing extensions) requires the use of 'ipps' URI for mandatory data integrity and negotiable data confidentiality.
  • Security Considerations: See Section 6 of RFC 7472.
  • Contact: Ira McDonald <blueroofmusic@gmail.com>, Michael Sweet <msweet@apple.com>
  • Author/Change controller: IESG
  • References: RFCs 2910, 2911, and 7472; IEEE-ISTO PWG 5100.12.

6. Security Considerations 🔥

6.1. Problem Statement 🖨️✨

okay so, powerful mobile devices (laptops, tablets, smartphones, etc.) are literally everywhere now, and people use them to reach enterprise and Cloud print services across the public Internet 💻📱 This is the main use case for the PWG "IPP Everywhere" [PWG5100.14], which has already been adopted by operating system and printer vendors and several other public standards bodies 🙌 End-user and enterprise documents, plus privacy-sensitive user info, are at greater risk than ever before 😭 So this IPP-over-HTTPS transport binding and 'ipps' URI scheme spec was defined to give us high availability and secure operation in this dynamic environment, like wireless hotspots in hotels, airports, and restaurants 🌸

  • See: Section 1 ("Introduction") of [PWG5100.14].
  • See: Section 3.1 ("Rationale") of [PWG5100.14].

6.1.1. Targets of Attacks 🎯

A network print spooler (logical printer) or print device (physical printer) can be a target for attacks, and those attacks may go after:

  • a) The network (to compromise the routing infrastructure, for example, by creating congestion) 🚦
  • b) The Internet Printing Protocol (IPP) [RFC2911] (for example, to compromise the normal behavior of IPP) 🤨
  • c) The print job metadata (for example, to extract privacy-sensitive information from the job submission request or via query of the job on the IPP Printer); or 🕵️‍♀️
  • d) The print document content itself (for example, to steal the data or to corrupt the documents being transferred) 💀

6.1.2. Layers of Attacks 🧅

Attacks against print services can be launched:

  • a) Against the network infrastructure (for example, TCP [RFC793] congestion control) 🛰️
  • b) Against the IPP data flow itself (for example, by sending forged packets or forcing TLS [RFC5246] version downgrade); or 🙈
  • c) Against the IPP operation parameters (for example, by corrupting requested document processing attributes) 🍓

6.2. Attacks and Defenses 🛡️

This 'ipps' URI Scheme spec adds the following security considerations on top of the ones described in [RFC7230], [RFC2910], [RFC2911], [RFC5246], [RFC7230], [PWG5100.12], and [STD66] 💜

  • See: Section 8 ("Security Considerations") in [RFC2910].
  • See: Section 8 ("Security Considerations") in [RFC2911].
  • See: Appendix D ("Implementation Notes"), Appendix E ("Backward Compatibility"), and Appendix F ("Security Analysis") of [RFC5246].
  • See: Section 10 ("Security Considerations") in [PWG5100.12].
  • See: Section 7 ("Security Considerations") in [STD66].

6.2.1. Faked 'ipps' URI 🎭

An 'ipps' URI might be faked so it points to a rogue IPP secure print service, which would then quietly collect confidential job metadata or document contents from IPP Clients 😱

Because of administrator reconfiguration or physical relocation of an IPP Printer, a former literal IPv4 or IPv6 address might not be valid anymore 🚚 See Section 4.2 ("Syntax of 'ipps' URI Scheme") for the recommendation against using literal IP addresses in 'ipps' URIs 🙅‍♀️

Server authentication mechanisms and security mechanisms specified in IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and TLS/1.2 [RFC5246] can be used to address this threat 🔐

6.2.2. Unauthorized Access by IPP Client 🚪

An 'ipps' URI might be used by an unauthorized IPP Client to get into an IPP secure print service, for example to pull privacy-sensitive info like the "job-originating-user-name" job metadata defined in [RFC2911] 👀

Client authentication mechanisms and security mechanisms specified in IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and TLS/1.2 [RFC5246] can be used to address this threat 🔑

6.2.3. Compromise at Application Layer Gateway 🌉

An 'ipps' URI might be used to reach an IPP secure print service through a print protocol application layer gateway (for example, an IPP to LPD [RFC1179] gateway [RFC2569]), which could cause a silent compromise of IPP security mechanisms 🫠

There is no general defense against this threat by an IPP Client. System administrators SHOULD avoid such configurations. ⚠️

6.2.4. No Client Authentication for 'ipps' URI 🫥

An 'ipps' URI doesn't define parameters for specifying the required IPP Client authentication mechanism (for example, 'certificate' as defined in Section 4.4.2 ("uri-authentication-supported") of [RFC2911]) 🤷‍♀️

An IPP Client SHOULD first use service discovery or directory protocols (e.g., the "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services" [RFC3712]) or directly send an IPP Get-Printer-Attributes operation to the target IPP Printer. That lets it read the "printer-uri-supported", "uri-authentication-supported", and "uri-security-supported" attributes, so it can figure out the required IPP Client authentication and security mechanisms for each supported URI 🔍

6.3. TLS Version Requirements 🔒

Per PWG "IPP Everywhere" [PWG5100.14] (and in line with security best practices and all existing deployments of the 'ipps' URI scheme), IPP Clients and IPP Printers that support this specification MUST use TLS/1.2 [RFC5246] or a higher version for all 'ipps' secure transport layer connections 💅✨

Implementors will find useful advice in the "Recommendations for Secure Use of TLS and DTLS" [TLSBCP] 📖

7. References 📚

7.1. Normative References 💖

7.2. Informative References 🌷

Acknowledgments 🫶

This document was submitted to the IETF by the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group, as part of their PWG IPP Everywhere [PWG5100.14] project for secure mobile printing with vendor-neutral Client software 🎀

This document defines an alternate IPP transport binding to the one defined in the original IPP URL Scheme [RFC3510], but this document does not update or obsolete [RFC3510] 🦋

Thanks to Claudio Allochio, Jari Arrko, Spencer Dawkins, Adrian Farrel, Tom Hastings, Bjoern Hoerhmann, Smith Kennedy, Graham Klyne, Barry Leiba, S. Moonesamy, Kathleen Moriarty, Sandra Murphy, Tom Petch, Pete Resnick, Benson Schliesser, Robert Sparks, Jerry Thrasher, Mykyta Yevstifeyev, Pete Zehler, and the members of the IEEE-ISTO PWG IPP WG 🌈💜

Authors' Addresses ✨

Okay bestie, last stop! 🧚 Here's where you can find the two people who wrote this spec. 🫶

Ira McDonald 💜

Ira McDonald
High North, Inc.
221 Ridge Ave
Grand Marais, MI 49839
United States

Phone: +1 906-494-2434
EMail: blueroofmusic@gmail.com

Michael Sweet 🌸

Michael Sweet
Apple, Inc.
1 Infinite Loop, M/S 111-HOMC
Cupertino, CA 95014
United States

EMail: msweet@apple.com

Literally the people behind the whole thing, so if you're ever stuck on a detail, you know who to ask. 💅🎀

📦 where this page comes from