RFC 5616
Streaming Internet Messaging Attachments
RFC 5616: Streaming Internet Messaging Attachments ✨
okay bestie, let's get into it 🎀
Here's the title block, so you know what you're looking at:
- Series: Network Working Group
- RFC number: 5616
- Author: N. Cook, Cloudmark
- Category: Informational
- Date: August 2009
- Obsoletes / Updates: the title block has no Obsoletes or Updates lines, so this RFC doesn't list any
Abstract 🌸
Okay so this doc is about streaming multimedia attachments to a device that's short on storage space or network bandwidth, like a phone. The attachment is pulled from an IMAP server while it plays, so the client can play video and audio emails without downloading the whole thing first. It's giving "stream it, don't hoard it" 💅
The document describes a profile that uses URLAUTH-authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). So many acronyms, I know 😭
Status of This Memo 🦋
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 💜
Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, 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, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview of Mechanism . . . . . . . . . . . . . . . . . . 3
3.2. Media Server Discovery . . . . . . . . . . . . . . . . . . 5
3.3. Client Use of GENURLAUTH Command . . . . . . . . . . . . . 7
3.4. Client Determination of Media Server Capabilities . . . . 9
3.5. Client Use of the Media Server Announcement Service . . . 10
3.6. Media Negotiation and Transcoding . . . . . . . . . . . . 11
3.7. Client Use of the Media Server MSCML IVR Service . . . . . 13
3.8. Media Server Use of IMAP Server . . . . . . . . . . . . . 17
3.9. Protocol Diagrams . . . . . . . . . . . . . . . . . . . . 18
3.9.1. Announcement Service Protocol Diagram . . . . . . . . 18
3.9.2. IVR Service Protocol Diagram . . . . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Digital Rights Management (DRM) Issues . . . . . . . . . . . . 24
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 24
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 281. Introduction ✨
Okay, picture this: you're on a phone with a wonky connection, and you tap a voicemail attachment. Email clients on resource- and/or network-constrained devices, such as mobile phones, can struggle to retrieve and/or store large attachments in a message. On a poor network link, the latency needed to download the entire attachment before showing any of it may not be acceptable to the user. And even on a fast network, the device may not have enough storage space to keep the attachment once it's retrieved. Rough 😩
Here's the good news for audio and video: you don't have to download it at all. The media can be streamed to the device using protocols such as RTP [RTP]. Streaming can be started and controlled using protocols such as SIP [SIP], and particularly the media server profiles specified in RFC 4240 [NETANN] or MSCML [MSCML]. Streaming fixes both problems: the latency problem, since the client can start playing relatively quickly, and the storage problem, since the client doesn't need to save the media locally. The tradeoff is that the media can't be viewed or played when the device is offline. Nothing's free, babe 🫶
Here are some types of media that would benefit from streaming to the device:
- Voice or video mail messages received as an attachment
- Audio clips such as ring tones received as an attachment
- Video clips, such as movie trailers, received as an attachment
The client may want to give the user simple "VCR-style" controls such as pause, fast-forward, and rewind. With that in mind, this document presents two options for streaming media. The first is a simple mechanism that uses the announcement service of RFC 4240. The second is a more complex mechanism that allows VCR controls, based on MSCML (RFC 5022) [MSCML]. Which one to use is up to the client. For example, the choice may depend on the limitations of the client or on the configured media server. This document also offers suggestions for working out which of these streaming services are available 🎬
2. Conventions Used in This Document 🎀
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 RFC 2119 [KEYWORDS].
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then some of the line breaks between those lines are for editorial clarity only and may not be part of the actual protocol exchange. So don't panic if the line breaks look weird, it's just for readability 🙈
3. Mechanism 🧚♀️
3.1. Overview of Mechanism 🦋
The proposed mechanism for streaming media to messaging clients is a profile that makes use of several existing mechanisms, namely:
- IMAP URLAUTH Extension [URLAUTH]: provides the ability to generate an IMAP URL that allows access by external entities to specific message parts, e.g., an audio clip.
- URLFETCH Binary Extension [URLFETCH_BINARY]: provides the ability to specify BINARY and BODYPARTSTRUCTURE arguments to the URLFETCH command.
- Media Server Announcement Service (RFC 4240) [NETANN]: provides the ability for a media server to stream media using a reference provided by the media server client in a URL.
- Media Server Interactive Voice Response (IVR) Service (RFC 5022) [MSCML]: provides the ability to stream media as above, but with VCR-style controls.
Here's the picture of how it all fits together 👇
+--------------+
| |
| Email Client |^
| | \
+--------------+ \
^ ^ \
| \ \ (5)
| (1), \ \
| (2) \ \
| (3),\ \
| (6) \ \
| \ \
v v v
+--------------+ +----------------+
| | (4) | |
| IMAP Server |<----->| Media Server |
| | | |
+--------------+ +----------------+
Figure 1: Proposed MechanismHere's how the proposed mechanism works, step by step:
(1) The client works out from the MIME headers of a particular message that a particular message part (attachment) should be streamed to the user. No assumptions are made about how, when, or whether the client contacts the user about this decision. User input may be required to start the proposed mechanism, so the client might need to ask first 💁♀️
(2) The client builds an IMAP URL that references the message part, then uses the GENURLAUTH [URLAUTH] command to generate a URLAUTH-authorized IMAP URL.
(3) The client connects to a SIP Media Server using the announcement service specified in RFC 4240 [NETANN], or the IVR service specified in RFC 5022 [MSCML], and passes the URLAUTH-authorized URL to the media server.
(4) The media server connects to the IMAP server named in the referenced URL, and uses the IMAP URLFETCH [URLAUTH] command to retrieve the message part.
(5) The media server streams the retrieved message part to the client using RTP [RTP].
(6) The media server or the client terminates the media streaming, or the streaming ends naturally. Either the client or the server can terminate the SIP session.
It should be noted that the proposed mechanism makes several assumptions about the mobile device and the network services available to it, namely:
- The mobile device is provisioned with, or obtains through some dynamic mechanism (see Section 3.2), the location of a media server that supports RFC 4240 [NETANN] and/or RFC 5022 [MSCML].
- The media server(s) used by the mobile device support the IMAP URL [IMAPURL] scheme for the announcement and/or IVR services.
- The IMAP server used by the mobile device supports generating anonymous IMAP URLs using the URLAUTH mechanism, as well as the IMAP URLFETCH BINARY [URLFETCH_BINARY] extension.
3.2. Media Server Discovery ✨
okay so this section is all about how a client can find a suitable media server for streaming, and it gives us a way to do that using the IMAP METADATA [METADATA] extension 🫶
there are two options for how a client figures out the hostname and port number of a good media server 👀
- no discovery needed! clients just get suitable media server info configured out-of-band 🎀
- discovery IS needed: clients use a discovery mechanism to find a suitable media server that will handle streaming the multimedia message parts 🔍
there are a couple of scenarios where discovery is a must for streaming to actually work 💀
- the client isn't configured with the address of any media servers at all 😭
- the client has the address of one or more media servers, but the IMAP server only accepts URLFETCH requests from certain media servers (for security or site policy reasons). so streaming fails, because the media server can't grab the media from the IMAP server 🚫
discovery also levels up security for streaming 🔐 by letting the client avoid completely anonymous URLs. say the client finds a media server that's an authorized user of the IMAP server for streaming. then it can make a URL that can only be accessed by an entity the IMAP server trusts to retrieve content. we go deeper into trust in media servers in Section 4 🧐
this document uses the IMAP METADATA [METADATA] extension, through a server entry that holds the contact info for suitable media servers to use with the IMAP server 🦋 media server discovery is optional, though! clients can use pre-configured media server info, or fall back to it if they run into IMAP servers that don't support the METADATA extension or the proposed entry, or that don't give a value for the entry 💅
a METADATA entry named "/shared/mediaServers" stores the locations of suitable media servers known to the IMAP server 📦 the entry is formatted according to the formalSyntax specified in Section 8. it's a tuple of a URI and an optional "stream" string. the URI is wrapped in <> symbols, the URI and "stream" are separated by a colon ":", and tuples are separated by a ";" 🌸
the "stream" string (c.f. the "stream" access identifier from [ACCESSID]) identifies media servers that can connect to the IMAP server as users authorized to retrieve URLs built with the "stream" access identifier 🧚 it means the client MUST create the content URI using the "stream" access identifier. see Section 3.3 for how the client should use the access identifier when generating IMAP URLs.) ✨
example values of the /shared/mediaServers METADATA entry (N.B. any line-wrapping below is just for clarity):
"<sip:ivr@ms.example.net:5060>:stream;<sip:annc@
ms1.example.net:5060>;<sips:ivr@ms2.example.net:5061>"
"<sip:ivr@192.0.2.40:5060>;<sip:192.0.2.41:5060>;<sips:annc@
192.0.2.42:5060>:stream"ok, real talk: the URI in the ABNF (Section 8) is generic, so it's not limited to SIP URIs 🙈 but this document only specifies how to use SIP URIs, so that's the only thing we cover. also, the "userinfo" component (known as the "service indicator" in RFC 4240 and RFC 4722) is optional. if it's there, it gives the client extra info about the media server's capabilities 💜 for example, a "userinfo" of "annc" means the media server supports RFC 4240, and "ivr" means it supports RFC 4722. Section 3.4 explains how clients should behave when the "userinfo" component isn't there 🎀
clients SHOULD parse the value of the /shared/mediaServers entry and contact a media server using one of the returned URIs. the servers come back in order of preference as the server suggests, BUT the client gets to decide if a different order makes more sense when picking the media server(s) to contact, and when picking alternates if something fails 👑
administrators setting up the /shared/mediaServers entry who don't know the capabilities of the media servers they're configuring SHOULD NOT include a "userinfo" component in the URI. in that case, the client decides which service to use, as described in Section 3.4. also, if a media server supports multiple services, a URI with the matching userinfo component SHOULD be configured for each service 🍓
even though the media server address can be discovered dynamically, it's assumed the necessary security arrangements between the client and the media server already exist 🔒 for example, the media server could use SIP digest authentication to give access only to authenticated clients. in that case, the username and password are assumed to already be set up. same goes for the client wanting to authenticate the media server with TLS and certificates, like, e.g., TLS and certificates: the necessary arrangements (trust anchors and so on) are assumed to exist already. some deployments might even trust the security of the underlying network and skip authentication between the client and the media server entirely 🌈 see Section 4 for more details ✨
3.3. Client Use of GENURLAUTH Command 🎀
the decision to use streaming services for a message part usually depends on that part's content type 💖 using the capabilities of the IMAP FETCH command, clients figure out the MIME [MIME] Content-Type of particular message parts. then, based on local policies or heuristics, they decide whether streaming will be attempted for that part 🔥
once the client decides a message part needs streaming, it generates an IMAP URL that refers to that part, following the method in RFC 5092 [IMAPURL]. then it starts generating an URLAUTH URL by appending ";EXPIRE=<datetime>" and ";URLAUTH=<access>" to the initial URL 🧚
the ";EXPIRE=<datetime>" parameter is optional, however it SHOULD be used. anonymous URLAUTH-authorized URLs are a security risk (see Section 4), and EXPIRE makes sure that at some point in the future, permission to access that URL stops 🙈 IMAP server implementors may choose to reject anonymous URLs they consider insecure (for example, ones with an EXPIRE date too far in the future), as a matter of local security policy. to keep this from causing interoperability problems, IMAP servers that implement this profile MUST NOT reject GENURLAUTH commands for anonymous URLs based on the EXPIRE time, if that time is equal to, or less than, 1 hour in the future 🦋
the <access> portion of the URLAUTH URL MUST be 'stream' (see [ACCESSID]) if an out-of-band mechanism or the media server discovery mechanism from Section 3.2 says the media server is an authorized user of the IMAP server for retrieving content via URLFETCH 🌸 without specific prior knowledge of that setup (from the discovery mechanism in this document, or from an out-of-band mechanism), the client SHOULD use the 'stream' access identifier. that way, streaming fails if the media server isn't an authorized user of the IMAP server for streaming 💅
BUT, if the client wants to take the risk of generating a URL that any media server can use (see Section 4), it MAY use 'anonymous' as the <access> portion of the URLAUTH URL passed to the GENURLAUTH command 😈 for example, the client might be pre-configured with the addresses of media servers in the local administrative domain (which implies some trust in those servers), without knowing whether they have a pre-existing trust relationship with the IMAP server being used (which may be in a different administrative domain). see Section 4 for the full security discussion 🔐
the client passes the URL it generated as a parameter to the GENURLAUTH command, using the INTERNAL authorization mechanism. the URL returned by a successful response to this command is then passed to the media server. if no successful response to the GENURLAUTH command comes back, then nothing else can happen with respect to streaming media to the client 🥲
examples 🎀
C: a122 UID FETCH 24356 (BODYSTRUCTURE)
S: * 26 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("VIDEO" "MPEG"
NIL NIL "BASE64" 655350)) UID 24356)
S: a122 OK FETCH completed.
C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;
urlauth=anonymous" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;
urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"
S: a123 OK GENURLAUTH completed
C: a122 UID FETCH 24359 (BODYSTRUCTURE)
S: * 27 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("AUDIO" "G729"
NIL NIL "BASE64" 87256)) UID 24359)
S: a122 OK FETCH completed.
C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-19T16:39:57-08:00;
urlauth=stream" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-20T18:31:45-08:00;
urlauth=stream:
internal:098230923409284092384092840293480239482"
S: a123 OK GENURLAUTH completed3.4. Client Determination of Media Server Capabilities ✨
okay so once you've made an authorized IMAP URL, it's up to the client to hand that URL to a suitable media server 🎀. That server has to be able to grab the content over IMAP and stream it to the client using the RTP [RTP] protocol 🦋.
this section covers clients that haven't figured out the media server's capabilities yet 🙈. Maybe they never got it through configuration, and they didn't find out through a discovery process like the one in Section 3.2 either. What we're checking is which services (that's RFC 4240 or 5022) the media server supports 💜. Clients that already know those capabilities should use the mechanisms in Sections 3.5 or 3.7, as appropriate 💅.
if the client supports the MSCML IVR service, it SHOULD try to reach the media server with the MSCML protocol by sending a SIP INVITE with the service indicator "ivr" 🧚.
if the media server answers the INVITE without an error, the client can keep going with the MSCML IVR service as laid out in Section 3.7 🔥. but if the media server replies with an error saying the "ivr" service isn't supported, then (assuming the client supports it) the client SHOULD try the announcement service instead, as described in Section 3.5 🫶.
here's an example SIP INVITE that uses the "ivr" service indicator 👑:
C: INVITE sip:ivr@ms2.example.com SIP/2.0
< SIP Header fields omitted for reasons of brevity >3.5. Client Use of the Media Server Announcement Service 🌸
so if the client or media server doesn't support MSCML, the media server announcement service is the move, as described in RFC 4240 [NETANN] 🦋. The client sends a SIP INVITE to a special username ('annc') at the media server (that's the "announcement" user), and it hands over the URL it got from Section 3.3 💖.
the INVITE gets built like the examples below show. Heads up: as per RFC 4240, the play parameter is mandatory and says which authorized IMAP URL gets played 🙈.
Examples of valid SIP INVITE URIs sent to the media server announcement service:
C: sip:annc@ms2.example.net;
play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3Bsection
%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3Danonymous:
internal:238234982398239898a9898998798b987s87920
C: sip:annc@ms1.example.net;
play=imap:%2F%2Ffred@
example.com%2FINBOX%2F%3Buid%3D24359%2F%3Bsection
%3D1.3%3Bexpire%3D2006-12-20T18:31:45-08:00%3Burlauth%3Dstream:
internal:098230923409284092384092840293480239482notice how a bunch of the characters in the IMAP URI are escaped 🔐. Without that, they'd mess with the meaning of the enclosing SIP URI, because they'd get read as SIP URI parameters instead of IMAP URL parameters. not ideal, bestie 💀.
if the client gets a 200 (OK) response, the media server has successfully pulled the content from the IMAP server and the negotiated RTP stream will start up shortly 🎉.
there are loads of possible response codes 🌈, but a 404 from the media server means the content couldn't be found or couldn't be retrieved for some reason. for example, the media server might not support IMAP URLs at all 😭. at that point the client has a few options, like trying a different media server or just giving up on streaming that message part 🥀.
3.6. Media Negotiation and Transcoding 🎀
this document pulls from two areas that have historically been totally separate: Mobile Email (mainly IMAP) and Internet Telephony/Streaming (think SIP/RTP) 🦋. Since this document is mostly about upgrading mobile email, it's worth showing some simple SIP/SDP exchanges and talking through things like media negotiation (using SDP) and media transcoding 💜.
in the example below, the client uses the SIP INVITE command to reach the announcement service (see Section 3.5), and it advertises support for a bunch of audio and video codecs (using SDP [SDP]). In response, the media server only advertises a set of audio codecs 🎶. This works the same way for the IVR service, except the IVR service doesn't use the SIP Request-URI to say what content to play. Instead, that info comes in a later SIP INFO request ✨.
from the SDP session descriptions that both client and server advertise, they both know that communication has to use the subset of audio codecs that both sides support. (In the example SDP below, it's obvious the server doesn't support any video codecs 🙈.) The media server may transcode (that's converting between codecs) the media it gets from the IMAP server so it matches what the client supports. For example, the media server may downgrade the video from the IMAP server to just the audio component 🔄.
for clients using the announcement service, the media server MUST return an error to the INVITE if it can't find a codec that's common to the client, the server, and the media, or if it can't transcode to a suitable codec 🚫. Same deal for clients using the MSCML IVR service: the media server MUST return a suitable error response to the <playcollect> request 💅.
Example SIP INVITE and SDP Media Negotiation 🦋
C: INVITE sip:annc@ms2.example.com;
play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3B
section%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3D
anonymous:internal:238234982398239898a9898998798b987s87920 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: NetAnn <sip:annc@ms2.example.com>
C: Call-ID: 8204589102@example.com
C: CSeq: 1 INVITE
C: Contact: <sip:UAA@192.0.2.40>
C: Content-Type: application/sdp
C: Content-Length: 481
C:
C: v=0
C: o=UserA 2890844526 2890844526 IN IP4 192.0.2.40
C: s=Session SDP
C: c=IN IP4 192.0.2.40
C: t=3034423619 0
C: m=audio 9224 RTP/AVP 0 8 3 98 101
C: a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224
C: a=fmtp:101 0-15
C: a=rtpmap:98 ilbc/8000
C: a=rtpmap:101 telephone-event/8000
C: a=recvonly
C: m=video 9226 RTP/AVP 105 34 120
C: a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226
C: a=fmtp:105 profile=3;level=20
C: a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120
C: a=rtpmap:105 h263-2000/90000
C: a=rtpmap:120 h263/90000
C: a=recvonly
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: NetAnn <sip:annc@ms2.example.com>
S: Call-ID: 8204589102@example.com
S: CSeq: 1 INVITE
S: Contact: <sip:netann@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: 317
S:
S: v=0
S: o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41
S: s=Session SDP
S: c=IN IP4 192.0.2.41
S: t=3034423619 0
S: m=audio 17684 RTP/AVP 0 8 3 18 98 101
S: a=rtpmap:0 PCMU/8000
S: a=rtpmap:8 PCMA/8000
S: a=rtpmap:3 GSM/8000
S: a=rtpmap:18 G729/8000
S: a=fmtp:18 annexb=no
S: a=rtpmap:98 iLBC/8000
S: a=rtpmap:101 telephone-event/8000
S: a=fmtp:101 0-16
C: ACK sip:netann@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: NetAnn <sip:annc@ms2.example.com>
C: Call-ID: 8204589102@example.com
C: CSeq: 1 ACK
C: Content-Length: 03.7. Client Use of the Media Server MSCML IVR Service 📞✨
Okay bestie, once the client has figured out that the media server supports the IVR service, it's totally on the client to whip up a suitable MSCML request to start streaming the media it needs 💅
With the IVR service, the first SIP INVITE only does two jobs 🎀: confirming that the media server supports the MSCML IVR service, and negotiating which media codecs to use. Once that INVITE and its response have both wrapped up successfully, the client must generate a SIP INFO request with MSCML in the body to kick off the streaming 🦋
The <playcollect> request is the one we use, because it lets people use dual tone multi-frequency (DTMF) digits to control playback, like fast-forward or rewind ⏩⏪
Since <playcollect> is only being used for its VCR-like powers 📼, the media server doesn't need to do any DTMF collection. So the firstdigittimer, interdigittimer, and extradigittimer attributes SHOULD all be set to "0ms" 🍓. That makes digit collection stop right after the media finishes playing. Iconic 💜
The ffkey and rwkey attributes of <playcollect> control fast-forward and rewind, and the skipinterval attribute controls how big a 'speed' jump those actions take 🌸
The <prompt> tag is where you specify the media to play 🎬. It SHOULD have a single <audio> tag that gives the URL of the media, as per Section 3.3. Yes, the name says "audio," but it's historical, and the tag works for video too 🙈 The stoponerror attribute SHOULD be set to "yes" so that the media server sends back meaningful error messages when something goes wrong, like failing to grab the media from the IMAP server 🚨
Here's an example SIP INFO request using <playcollect>, shown at the end of this section 🧚
It's worth knowing that under normal conditions (no errors, no drama), the response to the <playcollect> request is a SIP 200 (OK) response ✅. Then the media server streams the media. Only once the media has finished playing, whether it ended naturally or the user asked to stop, does the media server send a <playcollect> response 🎉. That response includes details about the media that was played, like its length and any digits that were collected.
The client can pause playback at any time, either by sending the DTMF escape key (which is set as an attribute on the <playcollect> request) or by sending a <stop> request to the media server in a SIP INFO request 🛑. When the media server gets that, it acknowledges it, stops streaming the media, and then sends a SIP INFO request containing the <playcollect> response 💅
If the media server can't play the media for any reason (for example, if it can't retrieve the media from the IMAP server) 😬, streaming just won't happen. The <playcollect> response still gets sent, usually with helpful values in the <error_info> element 🫶
Here's an example dialog between a client and media server 🌈. It includes a rewind request and ends the playback with the escape key. To keep things short, some parts of the SIP dialog, like the full SIP header fields and SDP, are left out. (The protocol diagram in Section 3.9.2 shows the high-level message flow between all the components, including the IMAP server 🦋)
C: INVITE sip:ivr@ms.example.com SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 1 INVITE
C: Contact: <sip:UAA@192.0.2.40>
C: Content-Type: application/sdp
C: Content-Length: XXX
C:
C: <SDP Here>
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 1 INVITE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: XXX
S:
S: <SDP Here>
C: ACK sip:ivr@ms.example.com SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms2.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 1 ACK
C: Content-Length: 0
C: INFO sip:ivr@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 2 INFO
C: Content-Type: application/mediaservercontrol+xml
C: Content-Length: 423
C:
C: <?xml version="1.0"?>
C: <MediaServerControl version="1.0">
C: <request>
C: <playcollect id="332985001"
C: firstdigittimer="0ms" interdigittimer="0ms" extradigittimer="0ms"
C: skipinterval="6s" ffkey="6" rwkey="4" escape="*">
C: <prompt stoponerror="yes"
C: locale="en_US" offset="0" gain="0" rate="0"
C: delay="0" duration="infinite" repeat="0">
C: <audio url="imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"/>
C: </prompt>
C: </playcollect>
C: </request>
C: </MediaServerControl>
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 2 INFO
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Length: 0
S: <Media server retrieves media from IMAP server and streams to
client>
C: <Client streams 6 key>
S: <Media Server fast forwards media by 6 seconds>
C: <Client streams * key>
S: <Media Server stops streaming>
S: INFO sip:UAA@192.0.2.40 SIP/2.0
S: From: IVR <sip:ivr@ms.example.com>
S: To: UserA <sip:UAA@example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 5 INFO
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/mediaservercontrol+xml
S: Content-Length: XXX
S:
S: <?xml version="1.0"?>
S: <MediaServerControl version="1.0">
S: <response id="332985001" request="playcollect" code="200"
S: reason="escapekey" playduration="34s"
S: playoffset="34s" digits="" />
S: </MediaServerControl>
C: SIP/2.0 200 OK
C: From: IVR <sip:ivr@ms.example.com>
C: To: UserA <sip:UAA@example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 5 INFO
C: Content-Length: 0
C: BYE sip:ivr@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 6 BYE
C: Content-Length: 0
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 6 BYE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Length: 03.8. Media Server Use of IMAP Server 📬🔥
This section is all about how the media server turns the IMAP URL it got through the announcement or IVR service into the right IMAP commands to grab the content 🧚♀️
First things first, the media server connects to the IMAP server named in the URL 🔌. Once it's connected, the media server SHOULD use TLS [TLS] to encrypt the communication path 🔐
If the media server has its own user identity on the IMAP server, it SHOULD authenticate itself using that identity 🪪
If the media server isn't set up as an authorized user of the IMAP server, then the behavior in the IMAP URL [IMAPURL] spec MUST be followed 📜 Basically, if the server advertises the AUTH=ANONYMOUS IMAP capability, the media server MUST use the AUTHENTICATE command with the ANONYMOUS [ANONYMOUS] SASL mechanism 🙌 If SASL ANONYMOUS isn't available, then the username "anonymous" gets used with the LOGIN command, and the password is the Internet email address of the media server's administrative contact 💌
Once it's authenticated 🎉, the media server issues the URLFETCH command. It uses the URL from the 'play' parameter of the SIP INVITE (or the audio tag of the MSCML). If the IMAP server doesn't advertise URLAUTH=BINARY in its post-authentication capability string, then the media server returns a suitable error code to the client 😬
The extra parameters for the URLFETCH command, which are specified in (URLFETCH BINARY) [URLFETCH_BINARY], are what the media server uses to tell the IMAP server to strip out any transfer encoding and hand back the content type of the media 🎀 (Content-type info isn't part of the IMAP URL, so this is how it gets there.)
A successful URLFETCH command returns the message part that contains the media to be streamed 🎬. If the URLFETCH doesn't work out, the media server MUST return an appropriate error response to the client 🚨
Assuming the content comes back successfully, the media server sends a 200 (OK) response code to the client ✅. After it gets an ACK, an RTP stream is delivered to the client using the parameters that were negotiated in the SDP 🦋
If it makes sense, the media server MAY choose to do connection caching 💫. In that case, connecting to and disconnecting from the IMAP server are handled however the media server's algorithm decides. For example, the media server might know ahead of time that it will always hit the same IMAP server with the same login credentials, and that the access pattern would benefit from caching without putting a strain on server resources 🌸
Examples 🍭:
C: a001 LOGIN anonymous null
S: a001 OK LOGIN completed.
C: a002 URLFETCH
("imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920" BODYPARTSTRUCTURE
BINARY)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"
(BODYPARTSTRUCTURE ("VIDEO" "MPEG" () NIL NIL "BINARY" 655350))
(BINARY ~{655350}
S: [ ~655350 octets of binary data, containing NUL octets ])
S: a002 OK URLFETCH completed.
C: a003 LOGOUT
S: a003 OK LOGOUT completed.3.9. Protocol Diagrams 🗺️💖
This section has examples of the mechanism in this document in action 🎀. They show a media server streaming media to a client, with the content fetched from an IMAP server. In all of the examples, the IMAP, SIP, and RTP protocols use the line styles "-", "=", and "+", respectively 🌈
3.9.1. Announcement Service Protocol Diagram ✨
okay so this diagram is the whole announcement service story in one picture 🎬 it shows the email client, the IMAP server, and the media server all chatting when the client uses the announcement service. read it top to bottom like a group chat, bestie 🫶
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| BYE |
|<===========================================================|
| 200 OK |
|===========================================================>|3.9.2. IVR Service Protocol Diagram 🎀
this one is a simplified view (so no need to panic 💅) of how the email client, the IMAP server, and the media server talk to each other when the client uses the MSCML IVR service. it's giving choose-your-own-adventure vibes, with DTMF and playcollect doing the heavy lifting 📞
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| SIP INFO (playcollect) |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++================|
| | |
| SIP INFO (e.g., DTMF ff) |
|===========================================================>|
| 200 OK |
|<===========================================================|
| | |
| Continue streaming (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| (Streaming Ends or is terminated) |
| | |
| SIP INFO (playcollect response) |
|<===========================================================|
| BYE |
|===========================================================>|
| 200 OK |
|<===========================================================|4. Security Considerations 🔐
okay bestie, this section is SERIOUS but also kinda iconic. This doc proposes using URLAUTH [URLAUTH] "pawn tickets" 🎫, sent over IMAP [IMAP] and passed along over SIP [SIP], maybe tucked inside the MSCML payload from RFC 5022 [MSCML], so the media gets streamed from messages. So all the security stuff in those docs applies here too. No escaping it 💅
Here's the tea on IMAP URLs. These authorized URLs can grant access to data, so implementors need to think about these things:
- Using an anonymous pawn ticket gives access to any client of the IMAP server, and you don't need any credentials at all 😭. The security mechanisms referenced above (with the caveats below) SHOULD be used to stop unauthorized folks from getting their hands on the pawn ticket.
- Pawn tickets with the "stream" access identifier only let in entities that are authorized users of the IMAP server for streaming retrieved content. These are the safer ones 🦋 so implementors should check out Section 3.3, which explains when to use them.
- If the announcement service is used to set up streaming, RFC 4240 [NETANN] says the pawn ticket goes in the Request-URI. So untrusted third parties might be able to snoop on it 👀. The SIP communication channel MAY be secured with SIPS URIs [SIP], which gives you hop-by-hop TLS encryption 🔒.
- If the IVR service (RFC 5022 [MSCML]) is used to set up and control streaming, MSCML carries the pawn ticket in the body of the request. Same deal: untrusted third parties might intercept it. This MAY be secured with SIPS URIs [SIP], which gives hop-by-hop TLS encryption 🎀.
- Using SIPS URIs in these situations keeps third parties away from the pawn ticket. BUT it still lets proxies see it, and that could lead to misuse by malicious proxies 💀. See the note below.
This document describes a mechanism that uses two separate servers to get the content to the client. The big deal here is that the media server and IMAP server may well be in separate administrative domains 🧚. That means we have to think about the security of a three-way protocol exchange and the trust model that comes with that tripartite relationship. The security of each individual protocol was already covered, so this section is about the security stuff specific to the three-way data exchange:
- The client grants the media server full access to the potentially private media content specified by the IMAP URL. So the client is responsible for checking that the media server is authentic enough for the content (we can call this figuring out the "trust" the client has in a particular media server) 🫶. The security mechanisms from SIP [SIP] and RTP [RTP] may be used for this, along with out-of-band stuff like pre-configuration.
- The media server grabs content from an IMAP server for the user, so the security between the IMAP server and the media server matters too 👑. A client has no way of checking (programatically at least) how secure the exchanges between the media server and the IMAP server are. BUT it can tell, using the "stream" token that's part of the media server discovery mechanism in Section 3.2, that the media server already has an authentication relationship with the IMAP server for retrieving content with IMAP URLs ✨. The IMAP server administrator may put prerequisites on the media server administrator before this relationship gets set up, for example to guarantee the security of the communication between the two servers.
- Those two security considerations above affect what the client decides about generating the pawn ticket that gets passed to the media server. This document mandates using URLs protected with the "stream" access identifier when the client knows in advance that the "stream" authentication relationship between the media server and IMAP server exists 🌈. BUT it does allow anonymous pawn tickets when using "stream" might make streaming fail.
- There's a chance of several kinds of attacks from a malicious media server, SIP proxy, or other network elements, even against pawn tickets protected with the "stream" access identifier 😱. All of these attacks give access to the RTP stream, if not the original content. They include:
- The client contacts a malicious media server, MS1, which then proxies the streaming request to a second media server, MS2, that it has determined or guessed has "stream" authorization credentials with the IMAP server named in the pawn ticket. The media server can then redirect the streamed RTP traffic somewhere else.
- Any proxy on the path between the client and the media server can read the client's message in cleartext. A malicious proxy could do a man-in-the-middle attack and change the message to redirect RTP traffic elsewhere.
- Any network element that can "see" the traffic between the client and the media server (or between any two proxies) can capture the pawn ticket, then reissue a request with that pawn ticket to the same media server. Again, the streamed traffic can be redirected to any location the attacker wants.
Media servers handling streaming requests use pawn-ticket URLs only for as long as they need to process the streaming request, and then the URL gets forgotten 🫠. BUT media servers may log the URLs they get from clients. In that case, the private data in the IMAP server could be accessed by a malicious or curious media server administrator. Even URLs protected with EXPIRE may be accessed during the expiry period. So media servers SHOULD remove or anonymize the internal portion of the IMAP URL when logging that URL 🙈.
Also, lots of the security considerations in the Message Submission BURL Extension apply to this document too, especially around pawn tickets and prearranged trust relationships like the ones above 🍓.
Message parts encrypted with mechanisms like S/MIME [SMIME] are designed to keep third parties from accessing the data. So media servers won't be able to fulfill streaming requests for encrypted message parts. Iykyk 🔐.
5. IANA Considerations 📋
IANA has registered the following [METADATA] server entry for media server discovery, using the [METADATA] registry 🎀.
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /shared/mediaServers
Description: Defines a set of URIs containing the locations of
suitable media servers for streaming multimedia content
Content-type: text/plain; charset=utf-8
Contact: neil.cook@noware.co.uk6. Digital Rights Management (DRM) Issues 🎬
This document does NOT specify any Digital Rights Management (DRM) mechanisms for controlling access to and copying of the media to be streamed. This is intentional 💅. A reference to a piece of media content is created using the URLAUTH [URLAUTH] command. So any DRM that's needed should be built into the media itself, because adding checks inside URLAUTH could affect any use of the URLAUTH command, like the BURL [BURL] command for message submission.
The use of URLAUTH in this specification is believed to be pursuant with, and used only for, the rights you'd expect when media is sent over traditional internet messaging. It doesn't duplicate media content beyond what the act of sending the message already provides 🌸. In other words, the sender of the message is implicitly granting the right to download and view the content, as far as the sender actually has the right to grant that 🫶.
The document author believes that if DRM is a requirement for Internet messaging, a suitable DRM mechanism should be created. How that mechanism would work is outside the scope of this document 🧚.
7. Deployment Considerations 🚀
This document assumes an Internet deployment with no network restrictions between the different components 🌐. It doesn't address issues that can happen when network policies restrict communication between components, especially between the media server and the IMAP server, and between the client and the media server. RFC 5022 says, "It is unlikely, but not prohibited, for end-user SIP UACs to have a direct signaling relationship with a media server". So firewalls and other network security mechanisms will probably be set up to block direct end-user access to media servers 🙅♀️.
For either of the streaming mechanisms in this document to work, local administrators MUST relax firewall policies so that appropriate SIP UACs (user agent clients) running on mobile devices can access the media servers directly using the SIP protocol 📱✨. How the restrictions get relaxed (for example, only allowing clients connecting from the network space owned or maintained by the operator of the media server) is a matter of local policy, so it's outside the scope of this document 💜.
8. Formal Syntax ✨
okay so this part is the grammar bit, and it's giving precision 💅 The mediaServers METADATA entry value is written in Augmented Backus-Naur Form (ABNF), which is defined in RFC 5234 [ABNF], and it borrows the "absolute-URI" definition from RFC 3986 [RFC3986].
Unless it says otherwise, alphabetic characters are case-insensitive 🌸 Using upper or lower case for token strings is just for editorial clarity, not a rule. Implementations MUST accept these strings in a case-insensitive fashion 🫶
media-servers = ms-tuple *(";" ms-tuple)
ms-tuple = "<" absolute-URI ">" [":" "stream"]Here's the license stuff, bestie. It's a copyright notice, so it has to stay complete 🦋
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
9. Contributors 🎀
shoutout to the people who made this happen 🥹 Eric Burger (eburger@standardstrack.com) gave the initial inspiration for this document, plus advice and support on the media server IVR and announcement services, and help with the IETF process. literally iconic 👑
Lots of people also left helpful comments on the document, including Alexey Melnikov, Dave Cridland, Martijn Koster, and a bunch of folks in the LEMONADE and SIPPING WGs 💜
10. References 🌈
10.1. Normative References
[ABNF]Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.[ACCESSID]Cook, N., "Internet Message Access Protocol (IMAP) - URL Access Identifier Extension", RFC 5593, June 2009.[ANONYMOUS]Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006.[IMAP]Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.[IMAPURL]Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme", RFC 5092, October 2007.[KEYWORDS]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[METADATA]Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.[MIME]Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME)", RFC 2045, November 1996. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.[MSCML]Van Dyke, J., Burger, E., Ed., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.[NETANN]Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.[RTP]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.[SDP]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.[SIP]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.[TLS]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.[URLAUTH]Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.[URLFETCH_BINARY]Cridland, D., "Extended URLFETCH for Binary and Converted Parts", RFC 5524, May 2009.
10.2. Informative References
[BURL]Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.[SMIME]Ramsdell, B., Ed., ""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"", RFC 3851, July 2004.
Author's Address 🦋
Neil L Cook Cloudmark
EMail: neil.cook@noware.co.uk
📦 where this page comes from
- ietf: rfc5616 2009-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms