Re: [mdnsext] Discussion of BoF during Berlin IETF

Michael Sweet <msweet@apple.com> Mon, 03 June 2013 13:40 UTC

Return-Path: <msweet@apple.com>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACF721F9811 for <mdnsext@ietfa.amsl.com>; Mon, 3 Jun 2013 06:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.109
X-Spam-Level:
X-Spam-Status: No, score=-9.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+yuSZri3F+Q for <mdnsext@ietfa.amsl.com>; Mon, 3 Jun 2013 06:40:25 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7CB21F8B21 for <mdnsext@ietf.org>; Mon, 3 Jun 2013 06:40:25 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_06Pvn+asLqtbrLKfBHyPJg)"
Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNT00HPMKN8JML1@mail-out.apple.com> for mdnsext@ietf.org; Mon, 03 Jun 2013 06:40:24 -0700 (PDT)
X-AuditID: 11807157-b7f706d0000006c6-ad-51ac9cc62578
Received: from [17.153.103.39] (Unknown_Domain [17.153.103.39]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id D2.2E.01734.7CC9CA15; Mon, 03 Jun 2013 06:40:24 -0700 (PDT)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <CABOxzu3TCqL5JXi+UMSA66oRuzo5uWYUaDp-bQbmz-eaOxbG1w@mail.gmail.com>
Date: Mon, 03 Jun 2013 09:40:28 -0400
Message-id: <3140166B-9D64-4E52-81F7-AE5A14101766@apple.com>
References: <BD87928F6BFAEF4EBEB883E1C4F58772342AC64A@PACDCEXMB01.cable.comcast.com> <3f9e642cbdc6f8bb1a996f786bc61b09@xs4all.nl> <CABOxzu3TCqL5JXi+UMSA66oRuzo5uWYUaDp-bQbmz-eaOxbG1w@mail.gmail.com>
To: Kerry Lynn <kerlyn@ieee.org>
X-Mailer: Apple Mail (2.1503)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUiODNdXffEnDWBBic7BS0e7V/FZnF5/Spm i5NLTjFZHPkW68DisfXkDzaPpxMOMnksWfKTyeNEw3b2AJYoLpuU1JzMstQifbsEroyPE/0L /jhXTHi1j6mB8ZJFFyMnh4SAicT7O8cYIWwxiQv31rN1MXJxCAn0Mkn0N89hAUkIC1hLrDz+ EayIV0BP4tq3r+wgNrNAgsS0uyuZQGw2ATWJ35P6WEFsToFAiY3XjoD1sgioSFxqbmKBqDeS mHr6OdQcG4nvj2YwQSw7xijxrP872CARAQWJT4v2MEFcJCvx+vkblgmMfLOQ7J6FZDeErS2x bOFrZghbT+Jl0zt2THFdiYvrJjEuYGRbxShQlJqTWGmil1hQkJOql5yfu4kRFMoNheE7GP8t szrEKMDBqMTD+8N1TaAQa2JZcWXuIUYJDmYlEd4rgUAh3pTEyqrUovz4otKc1OJDjNIcLEri vEY2SwOFBNITS1KzU1MLUotgskwcnFINjFYP1r9xLlr+XCvm8P2bcqkNHUqPd1RtStLyWvFt WVNYg97E9buWFDk7q5f/YtPvLJ4Y+/+I0rWJxtLPCx7l/DWdaXGIaf9u8+mdevM1Pk9V595n skVwLsu/laGq338fuWr2fE7Pa69/b3/8vhwSnnB7+va/3/2OLj/0nf95wwvu3I2p19atyl+i xFKckWioxVxUnAgAjfXCHmECAAA=
Cc: mdnsext@ietf.org, consultancy@vanderstok.org
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 13:40:38 -0000

Kerry,

On 2013-06-03, at 8:42 AM, Kerry Lynn <kerlyn@ieee.org> wrote:
> On Mon, Jun 3, 2013 at 4:20 AM, peter van der Stok <stokcons@xs4all.nl> wrote:
> Hi John,
> 
> Very few, naive wishes about autonomous SD data access.
> 
> IMO, "autonomous" is a worthy goal but probably not attainable.  Nevertheless, any
> required configuration MUST be kept to a minimum.
> 
> As an example, under DNS-SD/mDNS the user has always had the option of choosing
> a meaningful <Instance> label for a given service.  If the scope in which this label must
> be unique is too large, the task of name conflict resolution becomes more complex.  This
> may be mitigated by autonomously choosing names with a very low probability of collision,
> but these are user unfriendly.  We need to strike a balance.

One of the things we did for the latest Bonjour Printing specification (and I'm hoping that will actually get published to developer.apple.com soon) is to clarify the default instance naming for printers - by default, use a "make and model" string, e.g., "Acme Laser Printer", and if there is a collision either do the normal numbering stuff ("Acme Laser Printer N") or just add a unique identifier that is affixed to the printer - typically a serial number or the last 6 digits of the MAC address, e.g., "Acme Laser Printer (12:34:56)". Not super user-friendly, but at least something a customer can look for on the printer should they actually own two of the same printer.

In addition to showing the printer name in our UI, we also show the location (if set) or serial number (if we have it) under the name - something like the following feeble ASCII art:

    +-----------------------+
    | ACME LASER PRINTER    |     (actual name is "Acme Laser Printer (12:34:56)")
    |   (12;34:56)          |     (no location string, so we show the serial number)
    +-----------------------+
    | ACME LASER PRINTER    |     (actual name is "Acme Laser Printer (78:9A:BC)")
    |   (78:9A:BC)          |     (no location string, so we show the serial number)
    +-----------------------+
    | ACME LASER PRINTER    |     (actual name is "Acme Laser Printer (FE:DC:BA)")
    |   coffee mess         |     (location string set)
    +-----------------------+
    | ACME INKJET PRINTER   |     (actual name, no location or serial)
    +-----------------------+
    | ACME INKJET PRINTER 2 |     (actual name using numbered method)
    |   mike's desk         |     (location string set)
    +-----------------------+

And of course the customer can change the name and location strings if they wish, typically through the printer's web interface.

(Perhaps including a location key in TXT record should be encouraged/required for usability?)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair