Ok, so you're surfacing an issue that is pretty common in a client-server scenario: a "service" should always advertise a contact point that is resolvable(name) and reachable(address) by any and all potential clients of the service. Which, to your point, is an important concept.
Given the ubiquity of this requirement in client/server scenarios, there's probably language that we can borrow that describes this requirement. OR we could keep it abstract, similar to the way I have described it above.
By the way, in your earlier #2 proposal, there was text that said "...SHOULD NOT transfer/provide URI values using numeric addresses obtained via DHCP or other auto-configuration protocols."
I don't think is correct -- we want to be able to use IPv6 literal addresses that are global in scope, or it would seem like we would want to -- and global-scope IPv6 addresses can be autoconfigured via DHCP or SLAAC.
Comments?
R.
On May 10, 2012, at 9:58 PM, Mike Sweet wrote:
> Randy,
>> The main issue is link local, but when you start getting a mix of traditional and multicast host names being used (common for today's network printers) with a new reliance on the information supplied by the printer, it is really important that the client be able to use it... If the printer reports a .local name the the resource won't be accessible from outside the subnet. Similarly, if you get foo.example.com a client might not be able to resolve that if it doesn't have a proper dns server configured...
>>> Sent from my iPad
>> On May 10, 2012, at 8:48 PM, Randy Turner <rturner at amalfisystems.com> wrote:
>>>>>>> Hi Mike,
>>>> Can you just simplify 1-3 below by saying implementations MUST NOT use literal link-local addresses in URI values?
>>>> Everything else is ok, right?
>>>> Randy
>>>>>> On May 10, 2012, at 10:59 AM, Michael Sweet wrote:
>>>>> All,
>>>>>> Another issue that has come to light recently is the use of link-local addresses by printers that haven't gotten an IP address from a DHCP server.
>>>>>> To summarize the issue: RFC 3986 does not address how to represent link-local addresses in URIs. Two separate (and incompatible) methods have been proposed for IPv6 addresses:
>>>>>>http://tools.ietf.org/id/draft-fenner-literal-zone-02.txt (expired)
>>>http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-01>>>>>> However, even if one of these methods is eventually adopted it is still impossible for a Printer to advertise the correct URI with a link-local address because zoneid strings are system-specific - they are basically the name of the network interface on the client.
>>>>>> What I'd like to do in IPP Everywhere is:
>>>>>> 1. Add rationale of not using link-local numeric addresses in printer-uri-supported and other URI values: Link-local numeric addresses cannot be represented by the Printer because the zone identifier is specific to the Client and not the Printer.
>>>>>> 2. Add normative requirement: Printers MUST NOT transfer/provide URI values using link-local addresses, SHOULD transfer/provide URIs values using the Host supplied in the Client HTTP request, SHOULD transfer/provide URI values using fully qualified domain names (FQDNs) in preference to numeric addresses, and SHOULD NOT transfer/provide URI values using numeric addresses obtained via DHCP or other auto-configuration protocols. Printers MAY advertise multiple printer-uri-supported values to cover all of the configured FQDNs and non-link-local numeric addresses.
>>>>>> 3. Add implementation discussion where the printer can tailor the addresses reported to the Host: value supplied in the client HTTP request; printer-icons, printer-supply-info-uri, printer-more-info are not as flexible as printer-uri-supported, so using the value supplied in the Host HTTP request header is important.
>>>>>> 4. Add security considerations text talking about DNS rebinding attacks - Printers SHOULD NOT allow requests with unknown or invalid Host values, including "localhost".
>>>>>> 5. Add security considerations text referencing security consideration in current mDNS draft.
>>>>>> Thoughts?
>>>>>> __________________________________________________
>>> 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/20120510/c6c3bbcc/attachment-0001.html>