GaySexOverIP (GSoIP) Problem Statement and Requirements [nsfw]

Drastic Times Require Drastic Measures

M. Thomas

Mtcc

P. Rank

Grindr

April 2021

Abstract

The global pandemic of 2020-2021 has caused entire countries to shelter in place. The side effect is that millions of gay men who don't succumb to Covid-19, will succumb to the DSBU's (Dangerous Semen Build Up's). This draft defines the problem space, and lays out a standards based architecture for gay sex over IP in an interoperable fashion for various pieces of remote sex equipment (RSE). While the straight sex equivalent is obviously desirable as well for those who partake in it, the authors' lack of practical experience requires limiting the scope of this draft to only the gay sex problem space. Likewise, since the entirety of gay sex is vast, this draft will focus on gay penetrative sex. It is expected that if taken up as a working group item, this draft can serve as a basis for further collaboration in both the entirety of common sexual activity, but also the specifics of Penis in Vagina (PiV) sex as well. Also out of scope are the actual rendezvous mechanisms which are likely in the SIP [RFC3461] bailiwick.

Status of This Memo

This document is not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF).  It represents the consensus of the IETF community.  It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG).  Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7340.


Copyright Notice
Copyright (c) 2020 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Terminology

• GSoIP -- Gay Sex over IP protocol
• PBE -- Precious Bodily Fluids such as ejaculate, chiffon and dish
• DSBU -- a condition in which a male explodes due to insufficient release of PBE
• RSE -- equipment which is required to partake in GSoIP sessions
• TOP-R  -- the insertion module
• TOP -- the physical manifestation of the insertion device
• BOTTOM-R -- the receiving module
• BOTTOM -- the physical manifestation of the receiving device
• GSoIP-TRAPEZOID -- the architectural element of TOP->BOTTOM-R->TOP-R-> BOTTOM control flow

Problem Statement

High bandwidth sexual encounters have been sharply curtailed with gay sex due to the Covid-19 pandemic requirement's to socially distance. This can lead to severe consequences of the men in confinement due to DSBU's. However it can be observed that with a wire there is a way for almost all human endeavors. The simulation of gay sex, however, is possible with the proper use of RSE and controls and parameters to specify the various physical aspects of the sexual event. Ideally RSE from different vendors should be able to interoperate, such that vendors who specialize in one experience to be able to interoperate with vendors that specialize in others. For example, some vendors may specially in bottoming and users may have preferred brands. Tops may prefer brands that implement the BALLGAG protocol. All should interoperate with each other while preserving a diverse and personalized experience. 

The exact means of making the rendezvous is out of scope but it is imagined that Grindr or other apps can be used, as well as IETF standards such as SIP. Also out of scope is straight sex of any kind since it is specifically excluded from the charter and is all around nasty. For actual sessions the protocol is free to reuse other protocols such as MGCP or SIP for media setup, but it need not reuse other protocols for the GSoIP control and monitoring channel.

General Requirements

1. The protocol MUST allow for a variety of devices, and be extensible for future additions
2. The working group MUST determine how media streaming fits into the architecture, as well as the larger architecture with rendezvous protocols and their media setup capabilities
3. Existing media transport protocols MUST be used as applicable with liaison to the MMUSIC working group as needed for sorting through the expected crush of new codecs (eg, a codec for causing physical movements on remote device as captured by local sensors), etc.
4. All of the normal positions of anal sex MUST be accommodated
5. STD transmission MUST be supported
6. The protocol MUST be able exchange size and various other measurements so as to simulate choking and small dicks banging around a loose bottom
7. The protocol MUST be able to accommodate more that 2 participants
8. Oral sex MUST be supported
9. Frotting and other non-penetrative sex MAY be supported in future versions
   
10. The protocol MUST support real time exchange of telemetry information on both sides including stroke rate, depth, attack angle and the like
11. The protocol MUST support communicating the swelling of cocks before orgasm
12. The protocol MUST support other indications of imminent orgasm
13. The protocol MAY support lighting a cigarette after orgasm
14. The protocol MUST support exchanging turgidity measurement as well as gap analysis for bottoms
15. The protocol SHOULD be able to exchange whether the bottom is laying there like a wet burlap sack
16. The protocol SHOULD be able to relay whether the top is actually looking at the bottom or is disinterest in the bottom's needs
17. The protocol MUST be able to relay the bottom's position if any at the beginning of the session. 
18. The protocol MUST be able to relay the weight of the bottom's legs, and the lengths of both tops and bottoms
19. The protocol MAY relay bottoms filing their nails or eating bon-bons
20. The protocol SHOULD support updating HIV status to match the desires of other participants
21. The protocol MUST be able to relay the "pass" of a messy pass around party bottom
22. The protocol SHOULD support double penetration
23. The protocol SHOULD support "centipede" configurations with feedback for harmonizing motion
24. The protocol MUST support the basic mechanism for start/stop/pause and fast forward. RTSP MAY be used in its stead. Rewind MAY be supported
25. The protocol MAY support exchange of the risks of STD's in a terminated session
    

Security Requirements

Since this draft deals with intimate relationships, security is of utmost concern

1. The protocol MUST protect the privacy of the participants
2. The protocol MUST provide authentication of the participants as needed
   
3. The protocol MUST be able provide anonymous participants from the standpoint of one or more of the participants
   
4. The protocol MUST be able provide knowledge that participants are of a legal age
5. The protocol MUST provide safe-words, with the defaults being 'no' and 'stop'
6. The protocol MUST be able to report messy bottoms
7. The protocol MUST be able to relay bottom hysteria and immediately terminate the session
8. The protocol MUST facilitate ghosting after the session terminates
9. The protocol MUST support top theft avoidance measures including mammal eyes and clinginess detection
10. The protocol MUST support prolapse avoidance and relay any impending events; tops falling in is unacceptable
    

Acknowledgements

The authors would like to thank the useful input from r/askgaybros and all of their hysterical queens which inform many of the security requirements

Informative References

None at this time.