Kelly,
Some feedback below...
On 2013-02-27, at 12:04 AM, kdLucas <kdlucas at google.com> wrote:
> 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).
FWIW, CUPS originally advertised the printer-state value in the TXT record, but we ended up removing it because of performance issues with updating TXT records (remember, every client querying for TXT records will get a copy transmitted to them) and because the clients really didn't care about the printer-state value, but more printer-state-reasons and the job-state/-reasons of any jobs that have been queued. In reality, once the printer is discovered it is more efficient and useful for the client to query the printer directly and not use the discovery protocol as a primitive form of IPC/event notification.
(if you get the impression I don't like the idea of the "ds" key, you'd be right! :)
> 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.
Keep in mind that doing multiple DNS-SD SRV queries for subtypes is much more efficient than a single SRV query for all service types followed by multiple TXT queries in order to do the filtering.
> 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. _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
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/20130227/f32114a0/attachment-0002.html>