| Internet Engineering Task Force | L. Donnerhacke |
| Internet-Draft | Fitug e.V. |
| Intended status: Experimental | March 7, 2019 |
| Expires: September 8, 2019 |
Rights for restricted content
draft-donnerhacke-linktax-03
Links are omnipresent in the Internet to provide access to other resources. There is no mechanism to express differences in law systems, access limitations, or arbitrary rules defined by the owner of the linked resource. Therefore links do depend on and enforce a communist sharing ideology, which ignores the content owner rights.
Links may point to resources far away from the originating page, hiding this fact from the customer. It takes the data transport services for free, internet transit providers on the way from the content source to the customers are not extra payed for this effort. In many cases, the remote company generates huge amount of money from the customers worldwide not shared with the transit providers.
In order to get the rights of all involved parties balanced, a new type of connection initiation is proposed: The Right.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2019.
Copyright (c) 2019 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 (https://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.
The current Internet is best described by the famous quote "From each according to his ability, to each according to his needs" by Karl Marx. In the Internet everybody provides its resources for the use by anybody else. This is the basic concept behind the hyperlink.
On the other hand the concept of intellectual property requires to have a contractual relationship before use of the requested resource. In order to fulfil the needs of the intellectual property industry, additional elements needs to be implemented in the Internet.
Using the mechanisms defined in this memo, content owners can decide the model of access to their property. They are free to choose new mechanisms and monetize their content, or to keep in line with open and free Internet by using the already existing mechanisms.
On the other hand Internet access providers seek for methods to participate on such monetization. They want to offer higher level of service quality to specific content providers. This memo allowes access providers to offer QoS for monetized content and get paid if the offer was accepted by the content provider.
German publishers tries to establish a right on news and other aggregated information for more than one century. The latest spin was to promote the idea of a link tax by the German publisher "Axel Springer". They simply claim, that "Links" can't be free and that the Internet is a "Rechts-freier Raum" (lawless space). To overcome this situation, they invented the "Leistungsschutzrecht", which in turn is the founding of the EU proposal.
Implementing this memo will satisfy all those claims:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in RFC 2119.
This memo specifies an experiment. It tries to make a political offer to those parties, which constantly want to change the Internet in favor of their own needs. By defining a technical solution for the announced problems, the political decision process has another alternative to accepting or denying the requested laws. This memo allows to acknowledge the needs of the interested parties without harming the existing Internet.
Now the political decision process has to choose one from the following possibilities:
In order to be successful, this memo needs to match the following technical criteria:
Given this list of preconditions, the server side processing of RIGHTs is only a subject of local application progamming.
References to remote content are currently done using "links". The only relevant environment for the purposes of this memo is the World Wide Web. There the "link" is represented by the <LINK> element or the <A> element.
The new <RIGHT> element is a modification of the existing <LINK> element. It differs from the former by the retrieval method used by the client browser, and two additional attributes.
When accessing the referenced resource of the RIGHT element, the browser SHOULD initiate the connection using the TCP options described in Section 3.
Wenn referencing a resource one of the following monetization methods MUST be used. The methods are mutually exclusive.
The RIGHT element MAY have an attribute named "prepaid", which contains an opaque token. The token SHOULD be a Base64 string. The attribute MUST not processed, if the token does exceed the Base64 charset. It MAY even check, if the token is really a Base64 encoding.
Any valid token MUST be copied to a new HTTP header line "Right: prepaid=token" when requesting the referenced resource. If the attribute does not exist or is invalid, the line SHOULD be omitted.
The resource provider MAY use this token to validate, that the resource was legally requested. If the token is invalid, it MAY respond with the error code 402. It MUST NOT respond with error code 451.
The resource provider MUST provide an API, where new tokens can be obtained. Access to the API SHOULD be limited to paying contractors and SHOULD offer tokens which are valid for a larger amount of requests and MAY time out.
This is the prefered method for link aggregators and search engines, which make money from referencing third party content. It can also be used, if the referencing page owner want to avoid payment hussle for the customer.
The RIGHT element MAY have a couple of attributes, which instruct the browser to process the necessary payment before accessing the resource.
The attribute "payment" contains a URI denoting the clearing point for the transaction and the destination of the payment. This memo does not define any methods, but it might look like "microico:123456..def" or "https://micro.pay.me.example/@company/AxelS". The payment API MUST return a proof of payment (PoP) value on success. The PoP value MUST NOT exceed the Base64 charset.
The attribute "currency" contains a string to be used by the payment API. It SHOULD donate a well defined abbreviation for the currency.
The attribute "view" contains a numerical value. The browser MUST NOT render the RIGHT element, without successfully paying the denoted amount of currency via the payment API. It SHOULD cache this result for later use to avoid multiple spendings for the same content.
The attribute "click" contains a numerical value. The browser MUST add the a header line "Right: click=PoP" when requesting the referenced resource. The PoP is the proof of payment value from payment of the denoted amount of currency. The resource provider MAY use this value to validate, that the resource was payed. If the token is invalid, it MAY respond with the error code 402. It MUST NOT respond with error code 451.
At least one of the attributes "view" or "click", as well as the attributes "payment" and "currency" MUST be present for this method.
This is the prefered method for referencing restricted content from pages providing own content.
The RIGHT element MAY have an attribute named "drm", which contains an opaque token. The token SHOULD be a Base64 string. The attribute MUST NOT processed, if the token exceeds the Base64 charset. It MAY even check, that the token is really a Base64 encoding.
Any valid token MUST be handed over to the local DRM software used to process the content of the resource. The details of the API and the processing inside the DRM software is out of the scope of this memo.
Traffic from the resource provider to the client (and back) travels through the Internet by passing from one internet carrier to the next one until it reaches the destination. The internet carriers are interconnected by each other through dedicated peerings. At such a peering, the networks of the carriers talk directly to each other. The network of a carrier itself are summarized by an Autonomous System Number.
There is no guarantee, that the packets travel the same way all the time. Traffic in one direction may touch completely different providers, than on the way back. The traffic can be rerouted if necessary, even if the TCP session is still up. So it is difficult to compensate the intermediate carriers, simply because they may change at any time.
In order to track the route of carriers involved, a new TCP option is defined. It contains an arbitrary amount of 32 bit ASN / Payload pairs.
0 1 2 3 01234567 89012345 67890123 45678901 +--------+--------+--------+--------+ | Kind | Length | ExID | +--------+--------+--------+--------+ | ASN-1 | +--------+--------+--------+--------+ | Payload-1 | +--------+--------+--------+--------+ ... | ASN-n | +--------+--------+--------+--------+ | Payload-n | +--------+--------+--------+--------+
Figure 1: Autonomous System Compensation Option
The option space in the TCP header is limited to eleven 32 bit words [1]. So no more than five ASN / Payload pairs can be included. The number might be lower, if other TCP options are present.
The option is defined to exist only in packets with the SYN flag set. It SHOULD NOT occur in data only packets, hence the MSS is not changed. For TCP fast open, the size of the initial segment needs to be adjusted.
In order request a resource according to Section 2.1, the client opens a new TCP connection with the SYN flag set and the ACK flag cleared and SHOULD add an empty ASN option as defined in Section 3.2.
Any ASN MAY offer a special service to the content provider by appending its own ASN to the end. The payload contains a contractually defined value, i.e. a challenge with nonce bits, which will be processed by the content provider. The list of offers MUST NOT be deleted or reordered.
If there is no contract between the carrier and the content provider, the special payload "0" MAY be used. This means, that the carrier want to negotiate a contract. If this negotiation fails after a reasonable period of time, the carrier SHOULD pass the packets untouched.
A carrier MUST NOT add an offer to the list, if it can not guarantee, that all packets of the flow will run through its infrastructure. Normally only the Internet access provider is able to do so. Transit providers need to take extra actions to bypass the normal Internet routing, before adding an offer. Adding an offer includes the promise to keep the routing decision stable and always route the following packets of this flow to the same ASN as the initial packet. Furthermore it MUST route all the response packets of this flow to the ASN which was last one in the list.
If the option space is full, the carrier MUST NOT add an offer to the list. This way the access providers have a first opportunity to place an offer, fulfilling their request to compensate the broadband access costs.
Any new connection containing this ASN option, SHOULD be signalled to the application level. Processing of any of the payment headers as defined in Section 2.2 SHOULD be suppressed unless the application got this signal. This way normal "links" are processed as usual, while "rights" can be handled correctly.
On receiving the initial packet at the final destination, the option values are examined. For each offer the payload MUST be replaced by the contractually defined, computed response. The list MUST NOT be reordered. If an offer is rejected, the payload is set to "0". So the TCP syn/ack packet contains a ASN option with all the acceptance values.
On the way back each ASN, which put in an offer, MUST examine the option, and MUST remove the last item from the list, if AS number matches. Depending on the response to the offer, the TCP flow SHOULD be handled accordingly to the contractual requirements.
Finally the carrier SHOULD route toward the next ASN in the option.
This memo is influenced by the legislative process in the EU. Special thanks go to Julia Reda for keeping the public updated. The basic idea was contributed by Bernd Paysan. Very valuable input came from many discussions over the IETF lists.
This memo adds an TCP ExID into the IANA registry <https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exids> according the the rules of RFC 6994.
| Value | Description |
|---|---|
| 0x0a0d | Autonomous System Compensation |
Filtering the TCP option on intermediate devices might render the resource in question unreachable.
The TCP option is designed to implement a challenge response mechanism, which should withstand a MITM attack. All details of such a mechanism are out of the scope of this memo.
Attribute values might be copied from a document and reused elsewhere. This might result in theft of access rights and should be prevented by appropriate actions (i.e. checking Referer, Cookies).
| [1] | Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981. |
| [2] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005. |
| [3] | Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006. |
| [4] | Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006. |
| [5] | Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013. |
| [6] | Cheng, Y., Chu, J., Radhakrishnan, S. and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014. |
| [7] | Bray, T., "An HTTP Status Code to Report Legal Obstacles", RFC 7725, DOI 10.17487/RFC7725, February 2016. |
| [8] | World Wide Web Consortium, "The link element", 2018. |
| [9] | World Wide Web Consortium, "The a element", 2018. |
| [10] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [11] | EUROPEAN COMMISSION, "Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on copyright in the Digital Single Market", 2016. |
| [12] | Reda, J., "Homepage" |
| [13] | Helgadóttir, A., "German press track record" |
| [14] | Marx, K., "Kritik des Gothaer Programms", 1875. |