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
“private”?
- *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
such.
- *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
printer?
- *Answer:* Using /printer/createjob API.
Thanks for your feedback.
Kelly
kdLucas
--
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>