attachment-0002
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Kelly,<div><br></div><div>Some feedback below...</div><div><br></div><div><br><div><div>On 2013-02-27, at 12:04 AM, kdLucas <<a href="mailto:kdlucas@google.com">kdlucas@google.com</a>> wrote:</div><blockquote type="cite">Here is our response to the feedback some of you provided to our Local Discovery specification (Privet):<div><br></div><div><ul><li><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><b>DS Key</b></span></li>
<ul><li><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">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.</span></li>
<li><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">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.</span></li>
<li><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><b>Answer:</b> </span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">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).</span></li></ul></ul></div></blockquote><div>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.</div><div><br></div><div>(if you get the impression I don't like the idea of the "ds" key, you'd be right! :)</div><div><br></div><blockquote type="cite"><div><ul><ul>
</ul><li><span style="font-size:13px;background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif"><b>Privet</b> </span></li><ul><li><font face="arial, sans-serif" style="font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif">A lot of places it says “privet”, like “_printer._sub._privet._tcp.local” or “X-Privet-Token”. Should that be “private”?</font></li>
<li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px"><b>Answer:</b> "Privet" is the name of the protocol.</span></li></ul><li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px"><b>Secure Printing</b></span></li>
<ul><li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px">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.</span></li>
<li><font face="arial, sans-serif" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><b>Answer:</b> </font><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">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.</span></li>
</ul><li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px"><b>Key name base_url</b></span></li><ul><li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px">I'm not happy with the name of the "base_url" key; "server", "base", "url"? Shorter is better for TXT records.</span></li>
<li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px"><b>Answer:</b> Good point. Key name is "url" now.</span></li></ul><li><font color="#222222" face="arial, sans-serif"><b>type key in TXT record</b></font></li>
<ul><li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px">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.</span></li>
<li><font face="arial, sans-serif" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><b>Answer:</b> </font><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">"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.</span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">local, </span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">*._scanner._sub._</span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">privet._tcp.local, </span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">*._tv._sub.</span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">_privet._tcp.local, etc.</span></li></ul></ul></div></blockquote><div>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.</div><blockquote type="cite"><div><ul><li><span style="background-color: rgb(255, 255, 255); font-size: 13px; font-family: arial, sans-serif; color: rgb(34, 34, 34); "><b>Id --> UUID</b></span></li><ul><li><font face="arial, sans-serif" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">The "id" key looks like a UUID. If so, it should be documented as such.</font></li>
<li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px"><b>Answer:</b> "id" is currently <i>can</i> 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)</span></li>
</ul><li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px"><b>cs key</b></span></li><ul><li><span style="font-family:arial,sans-serif;background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:13px">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?</span></li>
<li><font face="arial, sans-serif" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><b>Answer:</b> Added state "</font><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">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.</span></li>
</ul><li><font color="#222222" face="arial, sans-serif"><b>IPv4/v6</b></font></li><ul><li><font face="arial, sans-serif" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">You specifically mention IPv4 link-local, but you also want IPv6 link-local, too, right?</font></li>
<li><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><b>Answer:</b> Correct.</span></li></ul><li><font color="#222222" face="arial, sans-serif"><b>Direct printing job ticket</b></font></li>
<ul><li><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">How does one provide a job ticket when printing directly to the printer?</span></li><li><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><b>Answer:</b> Using /printer/createjob API.</span></li>
</ul></ul><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Thanks for your feedback.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></div><div><div>Kelly</div>kdLucas</div>
</div>
<br>--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br>believed to be clean.
_______________________________________________<br>cloud mailing list<br><a href="mailto:cloud@pwg.org">cloud@pwg.org</a><br>https://www.pwg.org/mailman/listinfo/cloud<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>