Christoph,
WRT #3, most places I've seen that implement this in a number of ways:
1. Limit discovery to authorized devices by disabling mDNS and using managed directories (traditional DNS, LDAP, etc.)
2. Configure the clients to only accept specific certs or certs signed by specific CAs.
3. Configure the printer and client to use the same trusted authorization server (e.g. Kerberos/ActiveDirectory).
So while you might not authenticate the printer, you can lock down access to the printer to achieve much the same thing.
On 2013-02-20, at 1:47 AM, "Lindemann, Christoph" <Christoph.Lindemann at nuance.com> wrote:
> 1) Having the ”ds” key in the TXT record, might also create unnecessary network traffic, as the an update announcement MUST be send for any changes to the TXT record.
> 2) A lot of places it says “privet”, like “_printer._sub._privet._tcp.local” or “X-Privet-Token”. Should that be “private”?
> 3) 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 send to the wrong printer.
>> Christoph Lindemann
> Senior Software Developer, Imaging
> Nuance Communications, Inc.
>> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of Michael Sweet
> Sent: 18. februar 2013 02:53
> To: kdlucas at google.com> Cc: cloud at pwg.org> Subject: Re: [Cloud] Google's Local Discovery Draft Specification
>> Kelly,
>> Comments below...
>>> On 2013-02-15, at 9:58 PM, kdLucas <kdlucas at google.com> wrote:
> Google has drafted a local discovery specification that is based loosely on mDNS. You may recall we asked for input on this while we were researching which protocol to use.
>> Here is our draft, and we'd appreciate any feedback you may have. We hope to implement this over the next few months so it would help if you provided comments within the next few weeks.
>> OK, so some specific feedback:
>> 0. Are you also aware of the work in the IETF to extend mDNS beyond subnets?
>> (http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-01)
>> 1. I'm not happy with the name of the "base_url" key; "server", "base", "url"? Shorter is better for TXT records.
>> 2. 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.
>> 3. The "id" key looks like a UUID. If so, it should be documented as such.
>> 4. 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.
>> 5. 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?
>> 6. You specifically mention IPv4 link-local, but you also want IPv6 link-local, too, right?
>> 7. How does one provide a job ticket when printing directly to the printer?
>> _________________________________________________________
> 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.
>> --
> 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/20130220/3fa58394/attachment-0002.html>