Internet DRAFT - draft-nihao-discoveryprotocol

draft-nihao-discoveryprotocol



Nihao Protocol Individual Group
Internet-Draft
Expires: March 1, 2012

                      The Nihao Discovery Protocol
                    draft-nihao-discoveryprotocol-00

Abstract
  
  The Nihao Protocol is an open source protocol that uses the
  Extensible Markup Language (XML), and simple UDP datagram 
  exchange. It's designed for quick (and unencrypted by default)     
  discovery and communication with other devices on a local 
  network. This document will show you how the Nihao protocol 
  works internally, allowing you to write wrapper libraries on
  the protocol and implement it in your own applications.

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 
  http://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."

Copyright Notice
  
  Copyright (c) 2011 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.

Headers
  
  The Nihao Protocol requires that you include a simple header 
  in all sent packets that comes before your XML command. The
  header tells receiving devices that you're using the Nihao
  Protocol, and it tells them simple information about you and
  your device. A header is made up of 4 components, plus a line
  break at the end (\r\n) that specifies that start of XML data.
  A header looks like the following:
  
  NIHAO:name,via,client\r\n
  
  As you can see the header starts out with the text NIHAO and
  then a colon which tells the receiving entity right away that
  you're using the Nihao protocol. After that comes your header
  components separated by commas; the contents contains your
  name (SHOULD be the host name of your device or the user's
  name), your via (MUST be either mobile or desktop), and your
  client (SHOULD be the name of the application).

Discovery
  
  The main function of the Nihao Protocol is finding other
  devices that are setup to respond to discovery requests. A
  discovery request is a command that's broadcasted over the
  network (sent to everyone that's connected to the network),
  any device who responds to the message is telling the requesting
  device that they're there; if a device chooses not to respond,
  they become invisible to the requesting entity. To send out a
  discovery request, you broadcast (send packet to the IP address
  255.255.255.255) the following data after your header:
  
  <discover xmlns='com.as.nihao' type='get' />
  
  Any receiving devices SHOULD respond with the following (if
  they don't they will be invisible) by sending directly to the
  requesting IP (as opposed to a broadcast):
  
  <discover xmlns='com.as.nihao' type='result' />
  
  The type GET indicates that you're requesting discovery, the
  type RESULT indicates that you're responding to a discovery
  request. Clients CANNOT randomly generate responses with the
  type RESULT, as it could cause duplicate entries on a requesting
  device list (unless they have measures against it).
	  
  When a client gets a discovery request (with type 'get'), it
  should check it's list of discovered devices to see if it's 
  there, if not, the device probably came online after a previous 
  discovery request and SHOULD be added now.

Information Exchange

  Devices can request information from other devices, this
  information could have an infinite amount of contents 
  possibilities, such as hardware information about a device
  (make, model, etc.) or profile information about a human
  (e.g., for a local social network). To send out an info request,
  you send the following data directly to a device (as opposed
  to broadcasting):

  <info xmlns='com.as.nihao' type='get' />
	
  The receiving device SHOULD respond with their information using 
  the following:
	
  <info xmlns='com.as.nihao' type='result'>
  <key1>key1-value</key1>
  <key2>key2-value</key2>
  </info>
	
  You can name the child nodes whatever you want, and specify any
  type of information in them, such as a child node with the name
  "phone" and your phone number as its inner text. Notice the type
  values GET and RESULT just like in the Discovery section.
  Applications can choose to encrypt this with their own encryption
  methods if they don't want other people to intercept their info
  (e.g., using MITM attacks or radio tapping). Devices will only
  be able to receive encrypted info if they're using the same
  application, or happen to be using the same encryption method.

Chat Message Exchange

  Devices can send chat messages to each other, containing plain
  text that's readable by humans, just like instant messaging on
  Google Talk or Facebook. Applications can choose to encrypt this
  with their own encryption methods if they don't want other people
  to intercept messages (e.g., using MITM attacks or radio tapping).
  Devices will only be able to receive encrypted messages if they're
  using the same app, or happen to be using the same encryption
  method. To send a message, you just send the following directly
  to your chat recipient:

  <chat xmlns='com.as.nihao'>message contents</chat>

  Applications SHOULD NOT broadcast chat messages; if there was 40
  other devices on your network chatting, and the applications being
  used by the devices all decided to broadcast chat messages, you
  would be flooded with messages almost every second. Applications
  should still have a way of filtering this in case others still
  decide to do so, such as only accepting chat messages sent with a
  header that has the same "client" type.

Further Interaction

  If an application needs further interaction, such as transferring
  large amounts of data (like files), it should use TCP (Transmission
  Control Protocol). Unlike UDP, TCP is connection based and is more
  reliable for exchanging large amounts of data with any data loss.

Going Offline

  When a device will no longer be responding to requests and receiving
  chat messages, they should broadcast the offline message. To go
  offline, you broadcast (send the packet to the IP address
  255.255.255.255) the following command:
	
<offline xmlns='com.as.nihao' />
	
  This will tell any devices that have you in their "discovered list"
  to remove you allowing applications to keep a clean and organized
  list of online devices.



Aidan Follestad
Expires: March 1, 2012