| Internet-Draft | 103K v1.0 | January 2022 |
| Ocen & katerega | Expires 24 July 2022 | [Page] |
1.0
Abstract
The Internet Core needs to be expandable to allow it to be usable on low-end devices with poor connectivity to be able to access internet resources in a seamless way on the application layer. this concept suggests that one way of how that can happen is through the stacking and unstacking of bits on the physical and datalink layers. Bycntainerising the input bytes into a bundle of 103bits and unstaking them on the other end of the communication layer using a different way f arrangement and encoding that can be interpreted by another protocol on the network layer. this can run parallel to the existing internet protocols and frameworks on the physical ,datalink and network layers¶
Status of This Memo
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 24 July 2022.¶
Copyright Notice
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. Introduction
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].¶
This document is being discussed on the xyz@example.org mailing list.¶
Add some text here. You will need to use these references somewhere within the text: [RFC2026] [RFC3802] [RFC1377]¶
5. References
5.1. Normative References
- [RFC1377]
- Katz, D., "The PPP OSI Network Layer Control Protocol (OSINLCP)", RFC 1377, DOI 10.17487/RFC1377, , <https://www.rfc-editor.org/info/rfc1377>.
- [RFC2026]
- Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, , <https://www.rfc-editor.org/info/rfc2026>.
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC3802]
- Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, DOI 10.17487/RFC3802, , <https://www.rfc-editor.org/info/rfc3802>.