Hi Guys,
In theory, RFC 2136 would allow a client to update any RRset in a zone in DNS -- however, no one implements just RFC 2136 by itself, since the security implications would be enormous.
RFC 2136 would require a vendor to allocate a fair amount of development resources for implementation and testing.
In addition, early recommendations strongly suggested any implementation of RFC 2136 to also include an implementation of RFC 2137, which would require a bit more development and testing time.
However, RFC 2137 has been obsoleted through the introduction of DNSSEC mechanisms (RFC 4033, 4034, and 4035), which require a bit more development. It would also require the site to move their DNS servers to use DNSSEC.
Even with these pre-conditions, I'm still trying to determine if DNS server policies would allow arbitrary RRset updates (other than A/AAAA RR types)
Of course, MDNS (DNS-SD, ZeroConf, etc.) only requires mechanisms on the client (as everyone probably knows), and many imaging devices already support this technology, so I don't see any problem (at least for now) with making a "MUST" for MDNS records that assist IPP everywhere.
For server-based DNS, I would recommend against making this a "MUST", because the implications on vendors and sites may be too high -- I recommend making this requirement a "SHOULD" or "MAY".
I'll follow up some suggested wording for section 4.2.2, taking into account the above information.
Randy
On Apr 9, 2012, at 1:00 PM, Randy Turner wrote:
>> Yes, I understand that DNS-SD allows "self-publication" and I'm fine with that.
>> I guess it's the DNS server case that still (I believe) requires administrative assistance.
>> R.
>>> On Apr 9, 2012, at 11:44 AM, Ira McDonald wrote:
>>> Hi Randy,
>>>> Printers already commonly publish themselves in SLP (if servers are
>> present) and LDAP/Active Directory automatically.
>>>> Adding the IPP Everywhere MDNS requirement for DNS-SD publish
>> of LOC and TXT records is a matter of parity in discovery protocols.
>>>> Cheers,
>> - Ira
>>>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Secretary - IEEE-ISTO Printer Working Group
>> Co-Chair - IEEE-ISTO PWG IPP WG
>> Co-Chair - TCG Trusted Mobility Solutions WG
>> Chair - TCG Embedded Systems Hardcopy SG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music/High North Inc
>>http://sites.google.com/site/blueroofmusic>>http://sites.google.com/site/highnorthinc>> mailto:blueroofmusic at gmail.com>> Winter 579 Park Place Saline, MI 48176 734-944-0094
>> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
>>>>>>>> On Mon, Apr 9, 2012 at 2:05 PM, Randy Turner <rturner at amalfisystems.com> wrote:
>>>> Hi Mike,
>>>> You're right about multicast DNS not requiring site administration, but dynamic DNS is only designed to update A/AAAA records in a zone. I'm not aware of anyone using dynamic DNS to update TXT, SRV, or other resource records. I haven't seen this done.
>>>> Randy
>>>> On Apr 9, 2012, at 10:59 AM, Michael Sweet wrote:
>>>> > Randy,
>> >
>> > Thanks for the text. Comments below.
>> >
>> > On Apr 9, 2012, at 10:24 AM, Randy Turner wrote:
>> >>
>> >> Hi Guys,
>> >>
>> >> Proposed mods for wd-ippeve10-20120201:
>> >>
>> >> 4.2.2 Geo-Location (LOC)
>> >>
>> >> Site administrators MUST (should this be a "SHOULD" ?) publish LOC records (RFC 1876) to provide the physical location of a printer.
>> >>
>> >> 4.2.3 Service Information (TXT)
>> >> Site administrators MUST publish ("SHOULD" ?)….
>> >>
>> >>
>> >> This document is placing requirements on devices for future compliance with an IPP everywhere standard -- however, DNS requirements are NOT requirements placed on a device, but rather administrative requirements for the site DNS -- so I'm not sure that 4.2.2 and 4.2.3 belong in this document.
>> >
>> > Multicast DNS (part of Bonjour, and a perennial draft awaiting love from the IETF DNS WG) is not managed by site administrators and is part of IPP Everywhere.
>> >
>> > Also, printers *can* register their own DNS records with traditional DNS infrastructure using dynamic DNS updates (RFC 2136) and many already have support for this...
>> >
>> > Anyways, I am happy to note that these are requirements for Multicast DNS and recommendations for traditional DNS.
>> >
>> > ________________________________________________________________________
>> > 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.
>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>>>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
--
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/ipp/attachments/20120410/c705a5c8/attachment-0001.html>