The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. In the 6lowapp Bar BOF discussion at IETF 75 in Stockholm, five areas of work were identified. (Section references point to the problem statement document, http://tools.ietf.org/html/6lowapp-problem .) a -- Security (section 6). b -- Transport (section 3). TCP is often considered relatively heavyweight while UDP lacks the necessary reliability and ordering services. Results of 6LowApp-related activities might include a "profiling" of TCP that just includes the necessary elements without losing compatibility, and/or a set of "building blocks" that could be used in a specific application protocol to enhance UDP by just the functions actually required. c -- Data Representation, both for the application data and for the protocols themselves. This is often referred to as "binary encoding"; the main benefits come less from being binary than from being efficient, easily processable and in particular predictable (reducing code size). W3C EXI was one of the schemes mentioned. d -- Base Application Protocols. HTTP and SNMP were mentioned; there is a strong relationship to the Transport problem on one side and the data representation problem on the other side. A related area is the choice of *Namespaces*, e.g., HTTP has URIs, SNMP has Object Identifiers. e -- Service Discovery (section 4). The BOF will focus on the last three items (c to e), with a clear emphasis on application (d) and service discovery (e) protocols. (Rationale: a and b probably require longer time frames and may fan out to different IETF areas. This does not mean we should ignore them.) The goal of the BOF is to build up the content for a WG charter proposal for one initial working group in the APP area.