Subject: [babel] NetJSON DNS-SD service name

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 18 Apr 2016 11:36:26 +0000

Changed the subject header to differentiate this thread.

> > That IANA registry is a multi-purpose list. In addition to being home to all
> the traditional service/port number assignments, it also has the DNS-SD
> service name assignments. For example, look at the entry for xul-http. Scroll
> to the far right of that entry and read the description.
> 
> Are you referring to:
> 
> "Defined TXT keys: u=<username> p=<password> path=<path to
> document> (Same as for _http._tcp)"
> 
> > The idea is that a device inside the LAN could send a multicast DNS (mDNS)
> query (e.g., mDNS query for _netjson._tcp.local.) to discover devices with
> NetJSON-formatted info exposed by a HTTP API. A router inside the LAN that
> is exposing NetJSON info by a HTTP API would respond to such a mDNS query
> with the DNS SRV + TXT records that supply the URL of the info. This has
> nothing directly to do with NetJSON or the formatting. It's about automating
> advertisement and discovery, just like printers get discovered today.
> 
> In relation to "u=<username> p=<password> path=<path to document>",
> does it mean sending a TCP packet to that specific port with those
> parameters will return the requested information?

Sort of. Except there is no port number defined, and it's not just TCP; it's specifically HTTP/TCP. Client HTTP stack determines which destination port is used in the TCP header (port 80), with the expectation that the HTTP server is listening on port 80.

> > I think this would be as simple as getting "netjson" included in this IANA
> registry per RFC 6335. See Section 5.2 of that RFC for special DNS-SD
> instructions.
> 
> This would open up many interesting possibilities!
> 
> Probably a generic mechanism to specify the protocol used would be
> necessary: it's common to send NetJSON via HTTP, telnet and websocket.

This would specify a standardized mechanism for providing NetJSON data, but wouldn't mandate it or preclude others. It may be that this mechanism would be mandated in certain contexts. For example, IETF homenet might choose to mandate it in the context of a homenet architecture, or Broadband Forum might choose to mandate it in the context of ISP-provided residential gateways. But that would be external to defining the actual mechanism.

Barbara

---

From: Nemesis <[email-masked]>
Date: Tue, 19 Apr 2016 18:29:11 +0200

> Sort of. Except there is no port number defined, and it's not just TCP; it's specifically HTTP/TCP. Client HTTP stack determines which destination port is used in the TCP header (port 80), with the…

Ok thanks.

> This would specify a standardized mechanism for providing NetJSON data, but wouldn't mandate it or preclude others. It may be that this mechanism would be mandated in certain contexts. For example,…

It sounds like the right thing to do.
There's a crucial question I have for you, Barbara: when do you think
it's the right time to start this process? After draft 0 is published to
the IETF? Before? On subsequent drafts (like draft 1 or 2)?

Thank you for your feedback
Federico