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
should always be /info API (in case client misses the announcement).
- 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
- *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
- *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
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
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"
- *Answer:* Added state "not-configured" to the spec. Right now it
does not make much sense ("offline" can server the same
if we use something like WiFi Direct, indicating that Internet connection
has not been set up yet makes perfect sense.
- 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...