[Cloud] Local Discovery Feedback responses

[Cloud] Local Discovery Feedback responses

[Cloud] Local Discovery Feedback responses

kdLucas kdlucas at google.com
Wed Feb 27 05:04:43 UTC 2013

Here is our response to the feedback some of you provided to our Local
Discovery specification (Privet):

   - *DS Key*
      - Having the ”ds” key in the TXT record, might also create
      unnecessary network traffic, as an update announcement must be
sent for any
      changes to the TXT record.
      - The "ds" key doesn't really belong here - TXT records don't
      generally get updated that frequently and typically have a TTL
value of at
      least several minutes.
      - *Answer:* That is done on purpose. Values of ds are limited to
      ("idle", "processing", "stopped"). We do want to send
announcement (in this
      case TXT record) when device has moved from one state to another. (For
      example during printing, it will move "idle"->"processing"->"idle"). We
      don't expect too much traffic generated in this case. Normally, just 2
      additional announcements per print job. The source of truth for
the client
      should always be /info API (in case client misses the announcement).
   - *Privet*
      - A lot of places it says “privet”, like
      “_printer._sub._privet._tcp.local” or “X-Privet-Token”. Should that be
      - *Answer:* "Privet" is the name of the protocol.
   - *Secure Printing*
      - In section 6.2 “Secure printing over local network” you might
      consider, how the client can authenticate the printer.
Encryption does not
      help much, if your job gets sent to the wrong printer.
      - *Answer:* Good point. We are receiving more feedback about secure
      printing and should accommodate it in v2. In v1 we are not planning for
      secure printing, and this item contains just a high level overview of a
      possible implementation.
   - *Key name base_url*
      - I'm not happy with the name of the "base_url" key; "server",
      "base", "url"? Shorter is better for TXT records.
      - *Answer:* Good point. Key name is "url" now.
   - *type key in TXT record*
      - The "type" key in the TXT record is unnecessary; clients can simply
      browse for the subtypes they are interested in and correlate using the
      service name.
      - *Answer:* "type" is used to search for Privet-compatible devices
      and detect their type. For example, it should be enough to search for all
      *._privet._tcp.local devices to see their types instead of searching for
      *._printer._sub._privet._tcp.local, *._scanner._sub._
      privet._tcp.local, *._tv._sub._privet._tcp.local, etc.
   - *Id --> UUID*
      - The "id" key looks like a UUID.  If so, it should be documented as
      - *Answer:* "id" is currently *can* be UUID or another alpha-numeric
      string less then 36 chars. In the final spec we will confirm the
format and
      the length of the cloud id. (should be no more then 64 chars)
   - *cs key*
      - The "cs" key is probably ok since the connection state won't change
      that often, but I think having an explicit "cs=not-configured"
value might
      be useful?
      - *Answer:* Added state "not-configured" to the spec. Right now it
      does not make much sense ("offline" can server the same
purpose), however,
      if we use something like WiFi Direct, indicating that Internet connection
      has not been set up yet makes perfect sense.
   - *IPv4/v6*
      - You specifically mention IPv4 link-local, but you also want IPv6
      link-local, too, right?
      - *Answer:* Correct.
   - *Direct printing job ticket*
      - How does one provide a job ticket when printing directly to the
      - *Answer:* Using /printer/createjob API.

Thanks for your feedback.


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20130226/1112e5cc/attachment-0002.html>

More information about the cloud mailing list