From rdroms@cisco.com Fri Dec 6 07:18:03 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4A11ADFD0 for ; Fri, 6 Dec 2013 07:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.603 X-Spam-Level: X-Spam-Status: No, score=-7.603 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmwQMN8NquUy for ; Fri, 6 Dec 2013 07:17:59 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3361AE001 for ; Fri, 6 Dec 2013 07:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10368; q=dns/txt; s=iport; t=1386343075; x=1387552675; h=from:to:subject:date:message-id:mime-version; bh=DTngqIGEonfXo7PnB2nozQrzOdzwSwZGLgptYHofMeo=; b=XDpSgY5Q8r1mBnlTTt3oV6w8LnrPBfWtwh1gLol7slzm0ClAbCjz0nvg fsOSXwXGiElDllrIUO9jge/KEan03Yt52eCjvoTWlGqBEilk+ddW/fhkm tBRK84TD429k0HEH5+Wsqmc7Kbezj/7RXE8sKsnPVliAJR8ac8rqq3igX I=; X-Files: dnssd-ietf88-minutes.txt : 6864 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFAObpoVKtJV2Y/2dsb2JhbABZgwc4U7ohFm0HgioCSR4kARo2MBcQBBwFDYdnDaIMnnAXji2ECoETA5AxhACDY5ITgymCKg X-IronPort-AV: E=Sophos;i="4.93,841,1378857600"; d="txt'?scan'208";a="4847832" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 06 Dec 2013 15:17:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB6FHs8k006126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Dec 2013 15:17:54 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.103]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 09:17:54 -0600 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Minutes from Vancouver WG meeting Thread-Index: AQHO8pZVTGOGpgjVXkeAyQ8L4tXDBg== Date: Fri, 6 Dec 2013 15:17:54 +0000 Message-ID: <292B1EF9-0FB0-41C0-ADDD-6944E3A39207@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [161.44.68.185] Content-Type: multipart/mixed; boundary="_002_292B1EF90FB041C0ADDD6944E3A39207ciscocom_" MIME-Version: 1.0 Subject: [dnssd] Minutes from Vancouver WG meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 15:18:03 -0000 --_002_292B1EF90FB041C0ADDD6944E3A39207ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-ID: <61E487F4BCC52C4D8A93366F38B4844E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Draft minutes are attached. Your co-chairs, tardy in preparing the minutes= , now ask you to review the minutes and respond with any addition or correc= tions today so we can submit them by the deadline (which is today). Apologies for the slackitude... - Ralph --_002_292B1EF90FB041C0ADDD6944E3A39207ciscocom_ Content-Type: text/plain; name="dnssd-ietf88-minutes.txt" Content-Description: dnssd-ietf88-minutes.txt Content-Disposition: attachment; filename="dnssd-ietf88-minutes.txt"; size=6864; creation-date="Fri, 06 Dec 2013 15:17:53 GMT"; modification-date="Fri, 06 Dec 2013 15:17:53 GMT" Content-ID: <2C5546FCF5500A47A172BF64509CF926@emea.cisco.com> Content-Transfer-Encoding: base64 ZG5zc2QgV0cgbWVldGluZyBtaW51dGVzDQpJRVRGIDg4LCBWYW5jb3V2ZXIsIEJDDQpOb3ZlbWJl ciA4LCAyMDEzDQoNClRoZSBjby1jaGFpcnMsIFRpbSBDaG93biBhbmQgUmFscGggRHJvbXMsIGNh bGxlZCB0aGUgbWVldGluZyB0byBvcmRlcg0KYXQgMTEyMCBhbmQga2lja2VkIG9mZiB0aGUgbWVl dGluZyB3aXRoIHJlbWluZGVyIGFib3V0IHRoZSBOb3RlV2VsbC4NCg0KVGhlIGNvLWNoYWlycyBh bm5vdW5jZWQgdGhhdCB0aGUgZG5zc2QgV0cgaGFkIGJlZW4gZm9ybWFsbHkgY2hhcnRlcmVkDQph bmQgYnJpZWZseSByZXZpZXdlZCB0aGUgY2hhcnRlci4NCg0KDQpJbnRlcmFjdGlvbiB3aXRoIGhv bWVuZXQgV0cNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGUgY28tY2hhaXJzIG5v dGVkIHRoYXQgdGhlIGRuc3NkIGFuZCBob21lbmV0IFdHcyB3aWxsIG5lZWQgdG8NCmNvb3JkaW5h dGUgd29yayBvbiBuYW1pbmcgYW5kIHNlcnZpY2UgZGlzY292ZXJ5IGluIGhvbWUgbmV0d29ya3Mu DQpJdCBpcyBleHBlY3QgdGhhdCBkbnNzZCBjYW4gZHJhdyBvbiByZXF1aXJlbWVudHMgYWxyZWFk eSBkZXRlcm1pbmVkDQpmcm9tIGhvbWVuZXQgZm9yIHRoZWlyIHNjZW5hcmlvLCBmb2N1c2luZyBv biB0aGUgc2VydmljZSBkaXNjb3ZlcnkNCnJlcXVpcmVtZW50Lg0KDQpSZXF1ZXN0aW5nIGEgVExE IGZvciBzY2FsYWJsZSBETlMgKFJhbHBoKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KRG8gd2Uga25vdyBlbm91Z2ggdG8gZGV0ZXJtaW5lIHdoZXRoZXIgd2Ug d2FudCB0byBhc2sgSUNBTk4gZm9yIGEgVExEIA0KZm9yIHdpZGVyIGFyZWEgU0QgYXMgZW52aXNh Z2VkIGJ5IHRoaXMgV0c/ICBJZiBzbywgd2hhdCBUTEQ/DQoNClE6IFdoeSBub3QgLmxvY2FsPw0K QTogLmxvY2FsIGlzIHJlc2VydmVkIGFzIGEgc3dpdGNoIGZvciBpbnZva2luZyBhIGRpZmZlcmVu dCByZXNvbHV0aW9uIA0KICBtZWNoYW5pc20NClN0dWFydDogcmV2aWV3aW5nIGFyZ3VtZW50IGZy b20gUkZDIDY3NjE7IHNjb3BlIG9mIElDQU5OLCB3ZSBuZWVkIGEgDQogIG5hbWUgZm9yIHZlbmRv cnMgdG8gdXNlIG91dCBvZiB0aGUgYm94DQoNCk1pY2hhZWwgUmljaGFyZHNvbjogRE5TU0VDPyAN CiAgQWxzbywgd2UgZG9uJ3QgbmVlZCB0byBhc2sgSUNBTk4gZm9yIGFueXRoaW5nLCBqdXN0IHRl bGwgdGhlbSB3aGF0IA0KICB3ZSdyZSB1c2luZyANClJhbHBoOiB3ZSdyZSB0cnlpbmcgdG8gd29y ayB0b2dldGhlciB3aXRoIElDQU5OIG9uIGEgbmFtZQ0KDQpSdXNzIE11bmR5OiBjYXV0aW9uIHJl OiBzZXR0aW5nIHVwIGEgVExEIGFzIHN1Y2gsIHdpdGggRE5TU0VDIGV0Yy4NCg0KRnJhbmNpc2Nv IEFyaWFzOiBJJ20gZnJvbSBJQ0FOTiBhbmQgSSdtIGhlcmUgdG8gaGVscA0KDQpSYWxwaDogd2hh dCBmdXJ0aGVyIHJlcXVpcmVtZW50cyBhcmUgdGhlcmUgb24gYSBUTEQ/DQoNCkRJU0NVU1MNCg0K T2xhZiBLb2xrbWFuOiBkbyB3ZSByZWFsbHkgbmVlZCBhIFRMRD8gc3Vic3RpdHV0ZSAic3BlY2lh bCB1c2UgZG9tYWluDQogIG5hbWUiIGFuZCB0aGVuIGRlY2lkZSB3aGV0aGVyIGl0J3MgZW5vdWdo IA0KDQpQZXRlciBLb2NoOiBEb2Vzbid0IG5lZWQgdG8gYmUgVExELiBTb21ldGhpbmcgdW5kZXIg YXJwYSBUTEQgY291bGQgDQogIGFsc28gd29yay4NCg0KT2xhZiBLb2xrbWFuOiBBZ3JlZSB3aXRo IFBldGVyLiBEb2VzbuKAmXQgbmVlZCB0byBiZSBUTEQuDQoNClRpbTogQWdyZWUgdGhlIHRlcm0g dG8gdXNlIGhlcmUgaXMgc3BlY2lhbCB1c2UgZG9tYWluIG5hbWUgcmF0aGVyIA0KICB0aGFuIFRM RCwgYXMgcGVyIFJGQyA2NzYxLiAgU2VjdGlvbiA1IG9mIHRoYXQgUkZDIGlzIHRoZW4gcmVsZXZh bnQgDQogIHJlZ2FyZGluZyBtYWtpbmcgYSBuZXcgcmVzZXJ2YXRpb24uDQoNCk1hcmMgQmxhbmNo ZXQ6IElBQiBoYXMgbm8gY29uY2x1c2lvbiBvbiB0aGlzLiBBbHNvLCBpcyB0aGVyZSBhIFdHDQog IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHJlcXVpcmVtZW50cyBmb3IgdGhpcyBiZWZvcmUgZGVj aWRpbmcgdGhlDQogIHByb2Nlc3MgZm9yIGdldHRpbmcgaXQ/ICBXZSdyZSBwdXR0aW5nIHRoZSBj YXJyaWFnZSBiZWZvcmUgdGhlIGhvcnNlLiANCiAgV2UgbmVlZCBhIGRvY3VtZW50IGRlc2NyaWJp bmcgdGhlIHRlY2huaWNhbCByZXF1aXJlbWVudHMuDQoNCkRhbmllbCBNaWdhdWx0OiBXZSBzaG91 bGQgbm90IGFzayBJQ0FOTiB0byByZXNlcnZlIGEgbmFtZTsgd2Ugc2hvdWxkIA0KICBhc2sgSUNB Tk4gdG8gbm90IGFsbG9jYXRlIGEgbmFtZS4NCg0KR2VvZmYgSHVzdG9uOiBFbmdsaXNoL0FTQ0lJ IGlzIHRoZSBtaW5vcml0eTsgYW55ICJ1c2VyLWZyaWVuZGx5IG5hbWUiIA0KICBjb25zdHJhaW50 IGlzIHVuZGVmaW5hYmxlIGFuZCBzaWxseQ0KIA0KRGF2ZSBUaGFsZXI6IHplcm8vZGVmYXVsdCBy ZXF1aXJlbWVudCBtaXNzaW5nPyBBbmQgY2FuIHlvdSBoYXZlDQogIGh1bWFuLWZyaWVuZGx5LCB1 bmlxdWUtbG9jYWwsIGFuZCB6ZXJvIGNvbmYgYWxsIGF0IG9uY2U/DQogIEh1bWFuLWZyaWVuZGx5 IG5vdCBhIHN0cmljdCByZXF1aXJlbWVudDsgIm5vdCBidXJuZWQgaW4iIGNvbXBhdGlibGUNCiAg d2l0aCAiemVybyBjb25mIj8gKFN0dWFydCBhbmQgUmFscGg6IGNhbiBiZSBjb21wYXRpYmxlLCBk ZXBlbmRzIG9uDQogIHdoZXJlIGJ1cm5lZCBpbi4pIERhdmU6IG1heSBiZSBvdGhlcnMgdG8gZGVz aWduYXRlLCBpbmNsdWRpbmcNCiAgcG9zc2libGUgMkxEIA0KDQpLZXJyeSBMeW5uOiBpcyB0aGlz IGlzc3VlIG91cnMgb3IgaG9tZW5ldCdzPyB3ZSdyZSBub3QgZGVhbGluZyB3aXRoDQogIG5hbWlu ZyBpc3N1ZXMgYnkgY2hhcnRlci4gIA0KDQpEYXZlOiByZXF1aXJlbWVudHMgaW4gdGhlIGNoYXJ0 ZXIgdGhhdCB3ZSBkZWZpbmUgdGhpcyBwcm9ibGVtLCBub3QNCiAgc29sdmUgaXQgKHNpZGUgbm90 ZTogZG5zc2QgKmlzKiBjaGFydGVyZWQgdG8gZG9jdW1lbnQgcHJvYmxlbXMgb3INCiAgaXNzdWVz IGFyaXNpbmcgZnJvbSBTRCBzb2x1dGlvbnMgdGhhdCBhZmZlY3QgbmFtaW5nKQ0KDQpSYWxwaDog d2UgbWF5IGhhdmUgcmVxdWlyZW1lbnRzIG1vc3RseSBjb29rZWQgYnV0IGRvZXMgYW55b25lIHRo aW5rIHdlDQogIG5lZWQgdG8gbW92ZSBxdWlja2x5IG5vdyA/DQpXRyBjb25zZW5zdXM6IE5PDQoN Cg0KZG5zc2QgcmVxdWlyZW1lbnRzIGRvY3VtZW50DQpkcmFmdC1seW5uLWRuc3NkLXJlcXVpcmVt ZW50cy0wMC50eHQNCnd3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84OC9zbGlkZXMvc2xpZGVzLTg4 LWRuc3NkLTAucGRmDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpIYXMgbm90IGNoYW5nZWQgZHJhbWF0aWNhbGx5IGluIGEgeWVhciBv ciBzbw0KVHVzc2xlIHNwYWNlOiBVc2FiaWxpdHksIFNjYWxhYmlsaXR5LCBEZXBsb3lhYmlsaXR5 DQpTdHVhcnQgbW9kZXJhdGVzIGRpc2N1c3Npb24NCg0Kc3BlYWtlcjogc2NhbGFiaWxpdHkgb2Yg Y2xpZW50czsNClN0dWFydDogbWFrZXMgc2Vuc2UgdG8gbm90ZSBzY2FsYWJpbGl0eSBjb21wYXJh YmxlIHRvIEROUyBpcyBkZXNpcmFibGUNCg0KU2FtaXRhIENoYWtyYWJhcnRpOiBzcGVjaWZpYyBy ZXF1aXJlbWVudHMgZm9yIElvVD8NClN0dWFydDogd29ydGggYWRkaW5nIGEgZmV3IHdvcmRzIHRv IHRoYXQgZWZmZWN0LCBkb24ndCBzZWUgaXQgYXMgbWFqb3INCiAgZGlmZmVyZW5jZTsNCktlcnJ5 OiBwcmV2aW91c2x5IGJyb3VnaHQgdXAgTTJNIGFzIGV4cGxpY2l0IHJlcXVpcmVtZW50LCBtYXkg bm90IGJlDQogIGluIHNjb3BlIA0KKENvLWNoYWlycycgb2JzZXJ2YXRpb24gLSBpdCBzaG91bGQg YmUgaW4gc2NvcGUpDQoNClBldGUgUmVzbmljazogaW50ZXJhY3Rpb24gb2YgUkVRMiBhbmQgUkVR Mz8gDQpEaXNjdXNzaW9uOiB5ZXMgaW4gc2NvcGUgaGVyZSwgeWVzIGltcGxpZXMgemVybyBjb25m IGJ5IGRlZmF1bHQgYnV0DQogIGFsc28gY29uZmlndXJhYmlsaXR5IGFzIGRlc2lyZWQgDQoNCkRh dmUgVGhhbGVyOiBSRVE2IGV4cGFuZCBhIGxpdHRsZSB0byAiZW51bWVyYXRlIHN0dWZmIG5vdCBp biBzY29wZS4uLiINCiAgcGVyIGNoYXJ0ZXIgbGFuZ3VhZ2UgDQoNCkRJU0NVU1NJT04NCg0KRGF2 ZSBUaGFsZXI6IHNvbWUgY2xhcmlmaWNhdGlvbiBvbiByZXF1aXJlbWVudHMgZm9yIGF0dHJpYnV0 ZXMgbGlrZQ0KICByZWxpYWJpbGl0eSwgYXZhaWxhYmlsaXR5LCBhbmQgbGl2ZW5lc3MuICANCg0K RGlzY3Vzc2lvbjogdGhlcmUncyBzb21lIHR1c3NsZSBhYm91dCB3aGF0IHRoaXMgbWVhbnMsIGJ1 dCBzaG91bGQgYmUNCiAgaW5jbHVkZWQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQpNSUYgcHJvZmlsZSBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg4 L3NsaWRlcy9zbGlkZXMtODgtZG5zc2QtNS5wZGYNCiAgZHJhZnQgaXMgb3V0IG9mIHNjb3BlIGJl Y2F1c2UgaXQgcHJlc2VudHMgYSBzb2x1dGlvbiwgYnV0IHByb2JsZW0NCiAgZGVzY3JpcHRpb24g cHJvYmFibHkgdXNlZnVsIA0KDQpTdHVhcnQ6IGNhbid0IHN1cHBvcnQgYXJiaXRyYXJ5IHVuaWNv ZGUgaW4gRE5TIGJ5IGNvbnZlbnRpb24sIG5vdA0KICBpbmJhbmQ7IG1ETlMgbGFiZWxzIGdldCBp bnRvIEROUyBhcyBvcGFxdWUgYmxvYnMsIHJlYWQvd3JpdGUgYXMgVVRGLTggDQoNCkFuZHJldzog dGhpcyBoYXMgYmVlbiB0cnVlIHVudGlsIG5vdywgYnV0IHdlJ3JlIG5vdyBwcm9wb3NpbmcgdG8g dXNlDQogIHRoZXNlIGxhYmVscyBvbiB0aGUgSW50ZXJuZXQsIGkuZS4gdGhlIEROUy4gU29tZSBj b21wYXRpYmlsaXR5IHdpbGwNCiAgYmUgcmVxdWlyZWQuIA0KDQpNYXJjIEJsYW5jaGV0OiBhZGQg dG8gcmVxdWlyZW1lbnRzIGRvY3VtZW50OiBkaWZmZXJlbnRpYXRlIDINCiAgbmFtZXNwYWNlcyBv ciBzaW1pbGFyIA0KDQpLZWl0aCBNb29yZTogRE5TIG5hbWVzIHZzLiBvdGhlciBuYW1pbmcgcnVs ZXM6IGFwcGxpY2F0aW9ucyBuZWVkIHRvDQogIGtub3cgd2hhdCB0aGluZ3MgbWVhbiANCg0KRGF2 ZSBUaGFsZXI6IGNsYXJpZnkgaW50ZXJwcmV0YXRpb24gcnVsZXMgcGVyIGxhYmVsOiBBLSwgVS0s IG9yICJibG9iIiANCg0KU3R1YXJ0OiBSRkMgNjc2Mywgb3B0aW1pemF0aW9uIGJ1dCB0aGUgcHJv Y2VzcyB0ZXJtaW5hdGVzIHdpdGhvdXQgaXQNCg0KQW5kcmV3OiBjb25jZXJuIGFib3V0IHNjYWxh YmlsaXR5IG9mIHRoaXMsIHdhbGtzIHRoZSB0cmVlIGxvdHMNCg0KS2VpdGg6ICJETlMgaXMgc2Fj cm9zYW5jdCINCg0KRElTQ1VTU0lPTjogSUROQSBpbnN0ZWFkIG9mIFVURjggaW4gdGhlIHB1Ymxp YyBpbnRlcm5ldCBmb3IgaTE4bjsNCiAgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtLCBuZWVkIHRv IGNsYXJpZnkgd2hpY2ggYXJlIEEtbGFiZWxzIGFuZA0KICB3aGljaCBhcmUgVS1sYWJlbHMgYW5k IHdoaWNoIGFyZSBvcGFxdWUgYmxvYnMgZm9yIGNsaWVudCBwYXJzaW5nDQogIHB1cnBvc2VzLiBU aW06IHdlIGhhdmUgYSBjaGFydGVyIGl0ZW0gdG8gY2xhcmlmeSB0aGVzZSBpc3N1ZXMgYW5kIA0K ICBkb2N1bWVudCB0aGVtOyBzb2x2aW5nIHRoZW0gaXMgZWxzZXdoZXJlLiBBbmRyZXc6IHByb2Js ZW0gc3RhdGVtZW50IA0KICBkb2N1bWVudCBpcyBlYXN5IHRvIHdyaXRlIHNlcGFyYXRlbHkgDQoN Ck9VVENPTUU6IHJlcXVpcmVtZW50cyBjYXV0aW9uIHJlOiAiZG9uJ3QgYnJlYWsgc3R1ZmYiIG5l ZWRzIHNvbWUgDQogIHJlZmluZW1lbnQ7IG1vcmUgYXBwbGljYXRpb25zIGluc2lnaHQ7IGRyYWZ0 IHByb2JsZW0gc3RhdGVtZW50IA0KICBwb3J0aW9uIHRvIGJlIHNlcGFyYXRlZC4NCg0KDQpJbml0 aWFsIEROUy1TRCBBcmNoaXRlY3R1cmUgVGhvdWdodHMNCnd3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy84OC9zbGlkZXMvc2xpZGVzLTg4LWRuc3NkLTIucGRmDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpESVNDVVNTSU9OOg0KDQpEYXZl IFRoYWxlcjogU2hvdWxkIGluY2x1ZGUgZGlzY3Vzc2lvbiBvZiBob3cgY2xpZW50cyBhcmUgDQog IGF1dG8tY29uZmlndXJlZA0KDQpLZXJyeTogTmV3IGRvY3VtZW50LCBhZGRpdGlvbmFsIG5hbWlu ZyByZXF1aXJlbWVudHMgZnJvbSBTRVAyLjANCg0KQW5kcmV3OiBDbGFyaWZpY2F0aW9uIG9mIGNv bmNlcm5zIGFib3V0IGNvbGxpZGluZyBuYW1lc3BhY2VzLA0KICBlc3AuIHNlY3VyaXR5DQoNCkVy aWsgTm9yZG1hcms6IFdoYXQgYWJvdXQgYSBwcmludGVyIHRoYXTigJlzIHNoYXJlZCBiZXR3ZWVu IHRoZSBhcnQgDQogIGRlcGFydG1lbnQgYW5kIHRoZSBoaXN0b3J5IGRlcGFydG1lbnQ/DQoob2Jz ZXJ2YXRpb246IHN1Y2ggYSBkZXZpY2UgY291bGQgaGF2ZSBhbiBlbnRyeSBpbiBib3RoIHRoZSBy ZWxldmFudCANCiAgc3ViZG9tYWlucykNCg0KQnVydG9uIEthbGlza2k6IFF1ZXJpZXMgbWF5IGxl YWsgb3V0IGFjY2lkZW50YWxseQ0KKG9ic2VydmF0aW9uOiBzbyB3ZSBzaG91bGQgc3BlY2lmeSBj b3JyZWN0IGJlaGF2aW91ciB0byBhdm9pZCB0aGlzKQ0KDQoNCk9yZ2FuaXphdGlvbiBhbmQgcmVz cG9uc2liaWxpdHkgZm9yIGRvY3VtZW50cw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCmRlbGl2ZXJhYmxlcyBhcyBjaGFydGVyZWQsIHByaW1hcmlseSBy ZXF1aXJlbWVudHMNCg0KRG91ZyBPdGlzOiBpc3N1ZXMgdHJhY2tlci9pc3N1ZXMgZG9jdW1lbnQN Cg0KYWRvcHQgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGFzIFdHIGl0ZW0/IEh1bTogeWVzDQoNCk1l ZXRpbmcgZW5kZWQgb24gdGltZS4NCg0K --_002_292B1EF90FB041C0ADDD6944E3A39207ciscocom_-- From rdroms@cisco.com Sun Dec 8 18:59:30 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE371AE072 for ; Sun, 8 Dec 2013 18:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkwq2hMMBEgE for ; Sun, 8 Dec 2013 18:59:29 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB211A1DFA for ; Sun, 8 Dec 2013 18:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=372; q=dns/txt; s=iport; t=1386557965; x=1387767565; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=kWW8WsUd1ng3ZWDfAzAxqIQBoITPrhF53BpGPo3WVkA=; b=FFk15xmFMpoD7YO8Ie+BGbewhL8q6vihLws/FkWZx7j+WfRLUv/1sPxr u75rMSjHKE78FBvhox+g7StbdniZU4cH0UTWzQbhLX+Jwfz0UDlw1kxm9 I/qSHK1ZyZhmRp9p2+6521iBximIenVtW8XRWRkbHFbm3iL6RJid2c4V/ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FANAwpVKtJXG+/2dsb2JhbABZgweBC7oyFm0Hgiw6NB0BPkInBIgVomCeBheSN4ETA5gUkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,854,1378857600"; d="scan'208";a="5266907" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 09 Dec 2013 02:59:24 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB92xOkR014661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 02:59:24 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.103]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Sun, 8 Dec 2013 20:59:24 -0600 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Adopt draft-lynn-dnssd-requirements as a WG document Thread-Index: AQHO9IqpEXR4xfLGRU2ftfcsDKQ9/w== Date: Mon, 9 Dec 2013 02:59:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.221] Content-Type: text/plain; charset="us-ascii" Content-ID: <881781EB7D6093428AF86EB2A9B33E3A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dnssd] Adopt draft-lynn-dnssd-requirements as a WG document X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 02:59:30 -0000 Adoption of draft-lynn-dnssd-requirements as a WG document was discussed at= the WG meeting in Vancouver. There was unanimous support at the meeting f= or adoption. So we can assess consensus of the WG to adopt the document as a WG document= , if you have an objection to adoption, please reply to the mailing list by= 0000 UTC, Tuesday, 12/16/2013. - Ralph From kulakov.ilya@gmail.com Sat Dec 14 13:38:43 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450C81AD8E3 for ; Sat, 14 Dec 2013 13:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQY9TRNjOaZR for ; Sat, 14 Dec 2013 13:38:34 -0800 (PST) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2B1AD73E for ; Sat, 14 Dec 2013 13:38:25 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id d49so1491232eek.19 for ; Sat, 14 Dec 2013 13:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=pOQae9EqWJ2rXUay52XLOB5IoOL2+712DkWLLpfNSVM=; b=P7CdrAjAkvjjm3Mz9Jaj1wRZrqoqoby89BV4Oip14rdCb5scHw14AmAob3VQll3l/F 8ZyOT3G814CO4uFuz1DCXzzA7N5rDYgWi9YZJObi3xc1C1MX5Nn8pFEC63e4RoSbXhNz VdwD3C1ncewiTM42L4iQ2xJ+vqYzqwIHi0C2/EckhwYU2vpSTRAWxJKFWqFQwbLoQ0/w 7vEW88739p6KmM4BQNkdFTZf27svvr2dY50HlKOrWwAU/NVW6JnmgJAy1oJj9snncEJ1 3oM+XblsR8HqKLjb2Nlf7FAq3aIbxPo1IcVbEPxiwskSZxgo4qrS5HvN8QsWRC5/JJ8V LCAA== X-Received: by 10.14.150.5 with SMTP id y5mr9280091eej.73.1387057098225; Sat, 14 Dec 2013 13:38:18 -0800 (PST) Received: from [192.168.1.102] ([95.87.206.43]) by mx.google.com with ESMTPSA id g47sm22794664eeo.19.2013.12.14.13.38.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Dec 2013 13:38:17 -0800 (PST) From: Ilya Kulakov Content-Type: multipart/alternative; boundary="Apple-Mail=_0D216766-E1AE-4286-99FD-B09AEC23DAD4" Message-Id: <0C617632-5E53-45CE-859F-33F708B110A4@gmail.com> Date: Sat, 14 Dec 2013 23:38:18 +0200 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [dnssd] Encoding limitations of the portion of the Service Instance Name X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 21:46:32 -0000 --Apple-Mail=_0D216766-E1AE-4286-99FD-B09AEC23DAD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 RFC 6763 states the following regarding the portion: In addition, because Service Instance Names are not constrained by the limitations of host names, this document recommends that they be stored in the DNS, and communicated over the wire, encoded as straightforward canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. Which looks almost exactly as the portion: The portion of the Service Instance Name is a user- friendly name consisting of arbitrary Net-Unicode text [RFC5198]. It MUST NOT contain ASCII control characters (byte values 0x00-0x1F and 0x7F) [RFC20]=85 Except that the portion does not allow ASCII control = characters. My question is whether such limitation is not set on the = and it indeed allows ASCII control characters? Best regards,=20 Ilya Kulakov --Apple-Mail=_0D216766-E1AE-4286-99FD-B09AEC23DAD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 RFC = 6763 states the following regarding the <Domain> = portion:
In addition, because Service Instance Names are not = constrained by
the limitations of host names, this = document recommends that they be
stored in the DNS, = and communicated over the wire, encoded = as
straightforward canonical precomposed UTF-8 = [RFC3629] "Net-Unicode"
(Unicode Normalization Form = C) [RFC5198] text.

Which looks = almost exactly as the = <Instance> portion:
The <Instance> portion of the Service Instance = Name is a user-
friendly name consisting of arbitrary Net-Unicode text = [RFC5198].  It
MUST NOT contain ASCII control characters (byte values = 0x00-0x1F and
0x7F) = [RFC20]=85

Except = that the <Instance> portion does not allow ASCII control = characters. My question is whether such limitation is not set on the = <Domain> and it indeed allows ASCII control = characters?


Best regards, 
Ilya = Kulakov

= --Apple-Mail=_0D216766-E1AE-4286-99FD-B09AEC23DAD4-- From kulakov.ilya@gmail.com Sun Dec 15 04:15:34 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FDE1ADF96 for ; Sun, 15 Dec 2013 04:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gowbrtSgIzDr for ; Sun, 15 Dec 2013 04:15:26 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE981ADF8E for ; Sun, 15 Dec 2013 04:15:26 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id z10so1680344ead.20 for ; Sun, 15 Dec 2013 04:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=Ku5bNM16ce7MqyobjWLTXCImoxh3eRky+gXCBCM78tg=; b=Kv4SAEYAO0kOzOMLId38W3vwcwBCcESvuN7PoVstaMVHgY9Jrl5QFQp8iDKOwQQ+il P/ltLwWycEQjzfytdciEKJcxQDjB9ZmJoCj09QJzzLBdOdfAtiyaveMcOp+voyGbA/oH waxhZppNQFrkvaKpWVW6mhG4u+FznRv9EwVOB5Ls61Jz74jt1rGqLt4Um8XdS71xI9uV 7TENTyqp1MOOoZmhgZjRGRlwsF+GxVK3maSMHUXUzNZnS+RMlUGlbwFpSKHdbIT5jGa/ HLtRVWDfNebrAGbCERGORfGFWNtw+WtmFPplpW6c6DlfOABKL4d2QOer0uCyVtT55TvD QRzQ== X-Received: by 10.15.44.4 with SMTP id y4mr11505111eev.71.1387109718696; Sun, 15 Dec 2013 04:15:18 -0800 (PST) Received: from [192.168.1.102] ([95.87.206.43]) by mx.google.com with ESMTPSA id n1sm29498021eep.20.2013.12.15.04.15.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Dec 2013 04:15:16 -0800 (PST) From: Ilya Kulakov Content-Type: multipart/alternative; boundary="Apple-Mail=_37882AF3-7B07-406B-AF66-FEB01D2819DE" Message-Id: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> Date: Sun, 15 Dec 2013 14:15:15 +0200 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [dnssd] A concrete example of the Punycode fallback variants for the portion X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 12:15:34 -0000 --Apple-Mail=_37882AF3-7B07-406B-AF66-FEB01D2819DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m trying to implement the algorithm suggested by the RFC = #6763: In cases where the DNS server returns a negative response for the name in question, client software MAY choose to retry the query using the "Punycode" algorithm [RFC3492] to convert the UTF-8 name to an IDNA "A-label" [RFC5890], beginning with the top-level label, then issuing the query repeatedly, with successively more labels translated to IDNA A-labels each time, and giving up if it has converted all labels to IDNA A-labels and the query still fails. But unfortunately there is no concrete example. If I have domain is =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84= .=E2=80=99 what are the fallback variants? Should I try every = combination: =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99 =E2=80=98my.xn--d1acufc.=D1=80=D1=84.=E2=80=99 ''my.xn--d1acufc.xn--p1ai.=E2=80=99 Or I should avoid =E2=80=9Cgaps=E2=80=9D: =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99 ''my.xn--d1acufc.xn--p1ai.=E2=80=99 ? --Apple-Mail=_37882AF3-7B07-406B-AF66-FEB01D2819DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99= m trying to implement the algorithm suggested by the RFC = #6763:
In cases where the
DNS server = returns a negative response for the name in = question,
client software MAY choose to retry the = query using the "Punycode"
algorithm [RFC3492] to = convert the UTF-8 name to an IDNA = "A-label"
[RFC5890], beginning with the top-level = label, then issuing the query
repeatedly, with = successively more labels translated to IDNA = A-labels
each time, and giving up if it has = converted all labels to IDNA
A-labels and the query = still fails.

But unfortunately there is = no concrete example.

If I have domain is =E2=80=98= my.=D0=B4= =D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 what are the = fallback variants? Should I try every combination:
=E2=80=98my.=D0=B4=D0= =BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99
=E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99
=E2=80=98my.xn--d1acufc.=D1=80=D1=84.=E2=80=99
''my.xn--d1acufc.xn--p1ai.=E2=80=99
Or I = should avoid =E2=80=9Cgaps=E2=80=9D:
=E2=80=98<= a = href=3D"http://my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84">my.=D0=B4=D0= =BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99
=E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99
''my.xn--d1acufc.xn--p1ai.=E2=80=99
?

= --Apple-Mail=_37882AF3-7B07-406B-AF66-FEB01D2819DE-- From ajs@anvilwalrusden.com Sun Dec 15 07:59:08 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429DD1AE05C for ; Sun, 15 Dec 2013 07:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.759 X-Spam-Level: * X-Spam-Status: No, score=1.759 tagged_above=-999 required=5 tests=[HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x1qck9noPDh for ; Sun, 15 Dec 2013 07:59:07 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 26A4E1ADF26 for ; Sun, 15 Dec 2013 07:59:06 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DA1A68A031 for ; Sun, 15 Dec 2013 15:53:52 +0000 (UTC) Date: Sun, 15 Dec 2013 10:53:48 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20131215155347.GA65994@mx1.yitter.info> References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the portion X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 15:59:08 -0000 On Sun, Dec 15, 2013 at 02:15:15PM +0200, Ilya Kulakov wrote: > > If I have domain is ‘my.домен.рф.’ what are the fallback variants? Should I try every combination: > ‘my.домен.рф.’ > ‘my.домен.xn--p1ai.’ > ‘my.xn--d1acufc.рф.’ > ''my.xn--d1acufc.xn--p1ai.’ This is the only correct answer. You have to cover all possible combinations. However, the text doesn't read that way. It reads as though you start label by label: > Or I should avoid “gaps”: > ‘my.домен.рф.’ > ‘my.домен.xn--p1ai.’ > ''my.xn--d1acufc.xn--p1ai.’ I suspect this is because the authors figured there'd be no way anyone would have an A-label inside a pure UTF-8 label. I think this is a serious underestimation of the inconsistencies actually found on the Internet. If I were doing it, I'd use your strategy 2 first on the grounds of optimism, but I'd fall back to 1 if I got Name Error for everything. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From bmanning@isi.edu Mon Dec 16 08:50:16 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC52C1AE368 for ; Mon, 16 Dec 2013 08:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9Xo1XD5gpGp for ; Mon, 16 Dec 2013 08:50:15 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 49D661AE35E for ; Mon, 16 Dec 2013 08:50:15 -0800 (PST) Received: from [128.9.184.89] ([128.9.184.89]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rBGGnTnE021495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Dec 2013 08:49:37 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=utf-8 From: manning bill In-Reply-To: <20131215155347.GA65994@mx1.yitter.info> Date: Mon, 16 Dec 2013 08:49:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> <20131215155347.GA65994@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1816) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: dnssd@ietf.org Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the portion X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:50:17 -0000 ah the naive authors=E2=80=A6. not only have mixed labels been = considered and tested, there was an initial exploration of mixed = encoding within a label=E2=80=A6 testing -every- combination has to be bound in some way - otherwise = this,in practice creates a condition that we are unable to observe in a = finite time. /bill Neca eos omnes. Deus suos agnoscet. On 15December2013Sunday, at 7:53, Andrew Sullivan = wrote: > On Sun, Dec 15, 2013 at 02:15:15PM +0200, Ilya Kulakov wrote: >>=20 >> If I have domain is =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1= =84.=E2=80=99 what are the fallback variants? Should I try every = combination: >> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 >> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99 >> =E2=80=98my.xn--d1acufc.=D1=80=D1=84.=E2=80=99 >> ''my.xn--d1acufc.xn--p1ai.=E2=80=99 >=20 > This is the only correct answer. You have to cover all possible > combinations. However, the text doesn't read that way. It reads as > though you start label by label: >=20 >> Or I should avoid =E2=80=9Cgaps=E2=80=9D: >> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 >> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99 >> ''my.xn--d1acufc.xn--p1ai.=E2=80=99 >=20 > I suspect this is because the authors figured there'd be no way anyone > would have an A-label inside a pure UTF-8 label. I think this is a > serious underestimation of the inconsistencies actually found on the > Internet. >=20 > If I were doing it, I'd use your strategy 2 first on the grounds of > optimism, but I'd fall back to 1 if I got Name Error for everything. >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From ajs@anvilwalrusden.com Mon Dec 16 09:03:36 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2692A1AE08A for ; Mon, 16 Dec 2013 09:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.459 X-Spam-Level: X-Spam-Status: No, score=0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_42=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyF6vNolB_Vm for ; Mon, 16 Dec 2013 09:03:35 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 167271AE087 for ; Mon, 16 Dec 2013 09:03:34 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E540F8A031 for ; Mon, 16 Dec 2013 17:03:33 +0000 (UTC) Date: Mon, 16 Dec 2013 12:03:28 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20131216170328.GC1828@mx1.yitter.info> References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> <20131215155347.GA65994@mx1.yitter.info> <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the portion X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:03:36 -0000 On Mon, Dec 16, 2013 at 08:49:31AM -0800, manning bill wrote: > ah the naive authors…. not only have mixed labels been considered and tested, there was an initial exploration of mixed encoding within a label… > testing -every- combination has to be bound in some way - otherwise this,in practice creates a condition that we are unable to observe in a finite time. Yes, of course. The problem, however, is the distributed nature of the DNS. A parent cannot control what a child's administration policy will be once the namespace is delegated. Similarly, a child cannot control the parent's administrative policies. So in fact names could end up in either state. The basic problem here is that we have top-level and second-level domains with a policy that still requires LDH in the DNS. The rationale for not using IDNA is made clear in 6763, but it's an obvious fact that, if DNS-SD is going to be generally useful on the wider Internet, it's going to have to accommodate itself to the way internationalization is handled in the DNS. One can make lots of arguments why IDNA sucks. But it's the way this has been handled, and so there's no hope that we're going to get away from mixed labels. The only alternative, of course, is to duplicate the IDNA U-labels with the plain UTF-8 data. This seems at least error prone. It also has the problem of potentially inconsistent caches when a change is introduces and one of the label "forms" has previously been queried but not the other. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From doug.mtview@gmail.com Mon Dec 16 09:07:32 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826251AE073 for ; Mon, 16 Dec 2013 09:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcM-lo3h0F2d for ; Mon, 16 Dec 2013 09:07:30 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B58851AE08A for ; Mon, 16 Dec 2013 09:07:30 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so6860096iec.16 for ; Mon, 16 Dec 2013 09:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CqtZ/F1LFgkWYbokgBVDPjaMTd+jjNW+88NfULbWqzc=; b=c6yayY2b2rf3o/Flxg3Pf2RiHNy/vtbcAOfisf13r2maoIQOlcxHQ74wCgE7ckk+3f uOkzlFqQSDpcreQcC4XnCEN3R9OtV6AmTul0Z+wSvSv5y4IJqEbNmPIUGz/2MVrufpr0 O5wVv3hhXr8PGxKZzWXVWWlk5GW2reguWr9TBvYBSR/GdJ7wnVL6i02VsHfVoXBLNrp1 o2+vYCGAr6X6O9Mb8/VHg6K3UX99IGi1vRaGEwM1heWGmitwA66Rzq2Sy545njuT5Z+D NvSwUc8StojFLMWl96DJKzaFmCEWu+0f00awZqR/tICESIBcgGUDqZ4r5T3WHOiJz9yX zLbQ== X-Received: by 10.50.152.39 with SMTP id uv7mr16414414igb.13.1387213649949; Mon, 16 Dec 2013 09:07:29 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id da14sm17187674igc.1.2013.12.16.09.07.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 09:07:28 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Douglas Otis In-Reply-To: <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> Date: Mon, 16 Dec 2013 09:07:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2831E050-956E-4A8F-832B-EA75A5165BCF@gmail.com> References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> <20131215155347.GA65994@mx1.yitter.info> <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> To: manning bill X-Mailer: Apple Mail (2.1822) Cc: dnssd@ietf.org, Andrew Sullivan Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the portion X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:07:33 -0000 Dear Andrew, This might not be as bad as you might think. 1) Hostnames should be subjected to the same canonicalization to = establish valid UTF-8 strings prior to conversion. Bonjour already = supports a means to override naming conflicts often seen as a prefixed = number value (n). Once proper canonicalization is applied, users may be = required to adjust the hostname if unhappy with the results.=20 2) There are two processes normally involved. One is discovering = services after selecting from a list of domains, and resolving services = after selecting from a list of hostnames. In each case, both of these = presentations can be done using UTF-8 (provided proper canonicalization = is applied. Whether the label gets converted to an A-Label will depend = on the selection of the domain. Regards, Douglas Otis On Dec 16, 2013, at 8:49 AM, manning bill wrote: > ah the naive authors=E2=80=A6. not only have mixed labels been = considered and tested, there was an initial exploration of mixed = encoding within a label=E2=80=A6 > testing -every- combination has to be bound in some way - otherwise = this,in practice creates a condition that we are unable to observe in a = finite time. > /bill > Neca eos omnes. Deus suos agnoscet. >=20 > On 15December2013Sunday, at 7:53, Andrew Sullivan = wrote: >=20 >> On Sun, Dec 15, 2013 at 02:15:15PM +0200, Ilya Kulakov wrote: >>>=20 >>> If I have domain is =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1= =84.=E2=80=99 what are the fallback variants? Should I try every = combination: >>> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 >>> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99 >>> =E2=80=98my.xn--d1acufc.=D1=80=D1=84.=E2=80=99 >>> ''my.xn--d1acufc.xn--p1ai.=E2=80=99 >>=20 >> This is the only correct answer. You have to cover all possible >> combinations. However, the text doesn't read that way. It reads as >> though you start label by label: >>=20 >>> Or I should avoid =E2=80=9Cgaps=E2=80=9D: >>> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 >>> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99 >>> ''my.xn--d1acufc.xn--p1ai.=E2=80=99 >>=20 >> I suspect this is because the authors figured there'd be no way = anyone >> would have an A-label inside a pure UTF-8 label. I think this is a >> serious underestimation of the inconsistencies actually found on the >> Internet. >>=20 >> If I were doing it, I'd use your strategy 2 first on the grounds of >> optimism, but I'd fall back to 1 if I got Name Error for everything. >>=20 >> Best, >>=20 >> A >>=20 >> --=20 >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From ajs@anvilwalrusden.com Mon Dec 16 09:45:41 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3521AE0B9 for ; Mon, 16 Dec 2013 09:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL4Uwj7NXhK5 for ; Mon, 16 Dec 2013 09:45:40 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F19171AE0B5 for ; Mon, 16 Dec 2013 09:45:39 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 084D88A031 for ; Mon, 16 Dec 2013 17:45:38 +0000 (UTC) Date: Mon, 16 Dec 2013 12:45:33 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20131216174533.GD1828@mx1.yitter.info> References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> <20131215155347.GA65994@mx1.yitter.info> <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> <2831E050-956E-4A8F-832B-EA75A5165BCF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2831E050-956E-4A8F-832B-EA75A5165BCF@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the portion X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:45:41 -0000 Hi, I'm not sure I entirely understand your message. But. . . On Mon, Dec 16, 2013 at 09:07:31AM -0800, Douglas Otis wrote: > > 1) Hostnames should be subjected to the same canonicalization to > establish valid UTF-8 strings prior to conversion. Bonjour already > supports a means to override naming conflicts often seen as a > prefixed number value (n). Once proper canonicalization is applied, > users may be required to adjust the hostname if unhappy with the > results. When you say "the same canonicalization", what do you mean? The DNS owner names that result from RFC 6763 are in Net-Unicode (RFC 5198); this entails NFC, but not much more. The U-label portions of any owner name arising from IDNA2008 have more restrictions -- most punctuation is disallowed, upper case characters are not permitted because they're not stable under case folding and NFKC, spaces are disallowed, and so on. This difference is why I suggested a common interoperable profile (see draft-sullivan-dnssd-label-miprofile-00. Stuart had some quibbles about the recommendations in there, but in any case the recommendations are outside our charter. I'm supposed to pull out the problem statement part, which I guess I could be doing rather than writing this mail). > 2) There are two processes normally involved. One is discovering > services after selecting from a list of domains, and resolving > services after selecting from a list of hostnames. In each case, > both of these presentations can be done using UTF-8 (provided proper > canonicalization is applied. Whether the label gets converted to an > A-Label will depend on the selection of the domain. If I understand the above, you're suggesting that the user will know how to cope with the issue. Frankly, I think that is just naïve. Users do not have a theory of operation of IDNA vs. plain UTF-8 labels in the DNS, and subtle inconsistencies between them are going to be at least mystifying and at worst opportunities for bad behaviour. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From doug.mtview@gmail.com Mon Dec 16 12:00:57 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44A11ADEB7 for ; Mon, 16 Dec 2013 12:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVqQgJh8idW5 for ; Mon, 16 Dec 2013 12:00:54 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C59781AD739 for ; Mon, 16 Dec 2013 12:00:53 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so7193576iec.13 for ; Mon, 16 Dec 2013 12:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oPlG0HmnWGLQfhX68V5jkRGZjhN671AFxtwVPSt+EpE=; b=Rs6EJI8xkXSwh2gRWziZXtIrhjaB0Nn7EM4bNRbC3ecQUHsRdYfA0/xWwiVEGp1tFv jl2Js/gaQDv89BuRBTQ2xfx1lwxyF+6rQyS/lapWzApGcJKRtJxbwb4HUdBAaYV7FQnt fzBEMrzbfejnNsUl34pAbBcnLfQ7aTp2Ik7pFlUT2TcWTjqc9UQnwqWdzd0hKx5l7QoS haXz0L08DtA3J1lw/PW8eX9JaIA2Ifvik4hMQBfjyR28/IQWktU1saaSyDD/RuPJGxap TJLcxzTlYOG0pjSLuVRl+CiAzICPbAHclviOdnvcJ5hVOcR3P+DW2zfCdvXHsPQX37l2 txRg== X-Received: by 10.50.61.232 with SMTP id t8mr16461467igr.32.1387224052876; Mon, 16 Dec 2013 12:00:52 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id j3sm11654873igj.9.2013.12.16.12.00.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 12:00:52 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Douglas Otis In-Reply-To: <20131216174533.GD1828@mx1.yitter.info> Date: Mon, 16 Dec 2013 12:00:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> <20131215155347.GA65994@mx1.yitter.info> <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> <2831E050-956E-4A8F-832B-EA75A5165BCF@gmail.com> <20131216174533.GD1828@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1822) Cc: dnssd@ietf.org Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the portion X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 20:00:58 -0000 On Dec 16, 2013, at 9:45 AM, Andrew Sullivan = wrote: > Hi, >=20 > I'm not sure I entirely understand your message. But. . . >=20 > On Mon, Dec 16, 2013 at 09:07:31AM -0800, Douglas Otis wrote: >>=20 >> 1) Hostnames should be subjected to the same canonicalization to >> establish valid UTF-8 strings prior to conversion. Bonjour already >> supports a means to override naming conflicts often seen as a >> prefixed number value (n). Once proper canonicalization is applied, >> users may be required to adjust the hostname if unhappy with the >> results.=20 >=20 > When you say "the same canonicalization", what do you mean? The DNS > owner names that result from RFC 6763 are in Net-Unicode (RFC 5198); > this entails NFC, but not much more. The U-label portions of any > owner name arising from IDNA2008 have more restrictions -- most > punctuation is disallowed, upper case characters are not permitted > because they're not stable under case folding and NFKC, spaces are > disallowed, and so on. This difference is why I suggested a common > interoperable profile (see draft-sullivan-dnssd-label-miprofile-00. > Stuart had some quibbles about the recommendations in there, but in > any case the recommendations are outside our charter. I'm supposed to > pull out the problem statement part, which I guess I could be doing > rather than writing this mail). Dear Andrew, I hope to create a write-up better describing this situation. Bonjour = should not be considered equivalent to DNS, although DNS plays a role. = Once resolving services beyond link local are in scope, a type of = canonicalization which includes RFC5198 normalization is required in = checks for hostname conflicts. Bonjour hostnames are not constrained to = what is legal for registered domains, but this freedom is for a single = left-most label when resolving the hostname. Labels that do not = represent hostnames should fall within the constraints imposed by DNS. =20= >> 2) There are two processes normally involved. One is discovering >> services after selecting from a list of domains, and resolving >> services after selecting from a list of hostnames. In each case, >> both of these presentations can be done using UTF-8 (provided proper >> canonicalization is applied. Whether the label gets converted to an >> A-Label will depend on the selection of the domain. =20 >=20 > If I understand the above, you're suggesting that the user will know > how to cope with the issue. Frankly, I think that is just na=EFve. > Users do not have a theory of operation of IDNA vs. plain UTF-8 labels > in the DNS, and subtle inconsistencies between them are going to be at > least mystifying and at worst opportunities for bad behaviour. Users should only see UTF-8 strings, not A-Labels. A resolution process = must apply rules needed to satisfy Bonjour and DNS separately as a two = or three step process, Domain/Service/Hostname or Service/Hostname. Of = course DNS will require registered domains expressed as A-labels, but = hidden from users. Don't expect users to recognize A-label domains.=20 Combining domain selection with hostname selection will not scale well = when scope goes beyond link local. Use of search domains must be = handled carefully and may even require confirmation by users. =20 Regards, Douglas Otis From tom.deseyn@gmail.com Sat Dec 14 05:03:19 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8D91ADFB5 for ; Sat, 14 Dec 2013 05:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soaQ8pxXQk0Z for ; Sat, 14 Dec 2013 05:03:15 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5B31AD66E for ; Sat, 14 Dec 2013 05:03:15 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so2120211veb.5 for ; Sat, 14 Dec 2013 05:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ul24oPdKiNfMFpW2KZoTfjld6GSr0pXLFWDnr4xkQSQ=; b=y6DWOirZK0qwBgdcItrrLb7jhaMxwPWi+7dsAVMjLayiuPMIkP4uHHLvfF5OSuYOaL 2MV0OPtvV2D5QRIeVzFoIhbUUQDz/MB/wdvuqeneQT38kweQg0lD0V/82g2hx0NQ5+SG //dvPBqN/b9+os8T0/icBWsNu8U81KGFlR78DvF6b33RFmhLdw5B/DNxxJ9GuOINHzRc lQ2N+tttQge2dRtwOXyqi+u0zqufVzgV8HC7V/+bD7ekhdgAy7mCPUZ0gt1pvPGdk5+C 5OGDwAOpvM3GykuZmcQAJfu+b1BpfZVbXWqQo+a8tc+fjhG42BqImdR6njT4FN75vIFd vgQQ== MIME-Version: 1.0 X-Received: by 10.220.99.72 with SMTP id t8mr3729616vcn.10.1387026188519; Sat, 14 Dec 2013 05:03:08 -0800 (PST) Received: by 10.52.230.72 with HTTP; Sat, 14 Dec 2013 05:03:08 -0800 (PST) Date: Sat, 14 Dec 2013 14:03:08 +0100 Message-ID: From: Tom Deseyn To: dnssd@ietf.org Content-Type: multipart/alternative; boundary=001a11c1d71c42cdb904ed7e3300 X-Mailman-Approved-At: Mon, 16 Dec 2013 12:02:40 -0800 Subject: [dnssd] rfc6762 Multicast DNS A/AAAA additional records X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 14:04:42 -0000 --001a11c1d71c42cdb904ed7e3300 Content-Type: text/plain; charset=ISO-8859-1 Hi all, RFC6762 states that a response on a query for an A record should include AAAA answers and vice versa. Would it makes sense to generalize this to requiring that additional A/AAAA records should be added to any message which contains an A/AAAA record? For example if a machine drops an IPv6 address this results in a message with an AAAA record with ttl 0. The previous paragraph would mean that other addresses still valid for this machine (IPv4 and IPv6) are included in the message. Wkr, Tom --001a11c1d71c42cdb904ed7e3300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

RFC6762 states that a response = on a query for an A record should include AAAA answers and vice versa.

Would it makes sense to generalize this to requiring t= hat additional A/AAAA records should be added to any message which contains= an A/AAAA record?

For example if a machine drops an IPv6 address this res= ults in a message with an AAAA record with ttl 0. The previous paragraph wo= uld mean that other addresses still valid for this machine (IPv4 and IPv6) = are included in the message.

Wkr,

Tom
--001a11c1d71c42cdb904ed7e3300-- From ajs@anvilwalrusden.com Mon Dec 16 12:41:00 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E31C1AC4C1 for ; Mon, 16 Dec 2013 12:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc9HOK_vejcR for ; Mon, 16 Dec 2013 12:40:59 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F355A1A1F33 for ; Mon, 16 Dec 2013 12:40:58 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0FA768A031 for ; Mon, 16 Dec 2013 20:40:58 +0000 (UTC) Date: Mon, 16 Dec 2013 15:40:56 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20131216204056.GG1828@mx1.yitter.info> References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> <20131215155347.GA65994@mx1.yitter.info> <81AD729F-6FA1-4290-8EEF-6F6333AA6638@isi.edu> <2831E050-956E-4A8F-832B-EA75A5165BCF@gmail.com> <20131216174533.GD1828@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the portion X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 20:41:00 -0000 On Mon, Dec 16, 2013 at 12:00:45PM -0800, Douglas Otis wrote: > > I hope to create a write-up better describing this situation. > Bonjour should not be considered equivalent to DNS, although DNS > plays a role. I don't think of Bonjour as equivalent to the DNS. We're talking about DNS-SD, however, not Bonjour (which uses DNS-SD but is more than that). > normalization is required in checks for hostname conflicts. Bonjour > hostnames are not constrained to what is legal for registered > domains, but this freedom is for a single left-most label when > resolving the hostname. What exactly do you mean by "legal for registered domains"? If what you're saying is that Bonjour names are not constrained to LDH, then I agree with you. The point is -- and DNS-SD relies on this -- that nameservers themselves are in fact not constrained to LDH, and can happily serve labels that are any combination of octets, including labels that are valid UTF-8. > Labels that do not represent hostnames > should fall within the constraints imposed by DNS. The constraints on labels imposed by DNS as a protocol are minimal. The problem is that there is a preferred syntax that led us to develop IDNA. And so now there are two ways to "spell" the same string in the DNS. DNS-SD assumes a label will be in the form "σόλος", and IDNA assumes the label will be in the form "xn--wxaikc6b" (which has a U-label "σόλος"). Once we have several levels of internationalized label in the name, we have to expect that we'll get a mix of U-label/A-label pairs and plain UTF-8 in the DNS. Now, the problem that I've been trying to talk about is that DNS-SD does not impose a number of restrictions on the labels that IDNA does. For example, under IDNA2008 Σόλος is not a valid U-label. That's a perfectly acceptable label under DNS-SD, however; and indeed RFC 6763 goes out of its way to recommend mixed case, spaces, and so on. There's nothing wrong with that, but if we're going to expect users to be able to cope with this mechanism without needing to know when they're looking at an IDNA label and when they're not, then the rules are going to have to be consistent enough not to be surprising. > Users should only see UTF-8 strings, not A-Labels. But what I am trying to say is that there are two classes of UTF-8 string here: the ones that DNS-SD permits and the subset of that which constitutes protocol-valid labels under IDNA. These two classes have different properties, and I think you may be conflating them. > Use of search domains must be handled carefully and may even require > confirmation by users. Again, I want to emphasise that if our answer is "confirmation or selection by users" for any parts of the machinery, we will have failed completely. The whole point of this work is that people have asked for a do-what-I-mean solution. The answer can't be "get confirmation from the user". Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From pusateri@bangj.com Mon Dec 16 13:24:51 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F341AD8EC for ; Mon, 16 Dec 2013 13:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKpiIsQ6F1Xi for ; Mon, 16 Dec 2013 13:24:49 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) by ietfa.amsl.com (Postfix) with ESMTP id 036081AD8E3 for ; Mon, 16 Dec 2013 13:24:47 -0800 (PST) Received: from [172.16.10.151] (cpe-071-070-131-186.nc.res.rr.com [71.70.131.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EE504DB1 for ; Mon, 16 Dec 2013 16:24:46 -0500 (EST) From: Tom Pusateri Content-Type: multipart/signed; boundary="Apple-Mail=_3191EE96-82C6-4839-A773-2B3900F319D8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Date: Mon, 16 Dec 2013 16:24:46 -0500 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) X-Mailer: Apple Mail (2.1812) Subject: [dnssd] service instance names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 21:24:51 -0000 --Apple-Mail=_3191EE96-82C6-4839-A773-2B3900F319D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Quick question about service names: RFC 6763 describes the general format of service instance names in = Section 4.1: Service Instance Name =3D . . In looking at an example from an iPhone, I see: 934406fa._sub._apple-mobdev2._tcp.local. Is the service _apple-mobdev2 and the instance 934406fa._sub? Or is the service _sub._apple-mobdev2 and the instance 934406fa? Are there any restrictions on service names like they can't contain a = '.'? Thanks, Tom --Apple-Mail=_3191EE96-82C6-4839-A773-2B3900F319D8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSr2+eAAoJEPk0GMVmUuYMUAkH+wTxM65Tnh3fkiC2HIyVSyOe A6jb2AW5xRKcvlJtPTVnlCGioYF2HHtNOZNzURvE/P+HNkmrvYXZVqz7swyT5vtj crxWDAWGhVdyLoQ0xU2LQtWnNdincfMKuh5ORNVQP4ITJ6oZcCu02gRh8SRBOhK4 M1puz7cCJ/oj6AHCJUDsbe4Jn+OqruYN9goKIwqFgkoKL7R5Tas5ewAQg0kPsm1A T92lJAAMGtZr9r6B6JFb7redDOdTigIcMmYY694VUzUaZqUE0qUC4izFQu2fqpt9 0DYVb+Ylx0EXBKYgD4ydN0efRHDADBNAarnH5MNmRxDYl+9ZcwTclgeVHth0xnc= =UYfZ -----END PGP SIGNATURE----- --Apple-Mail=_3191EE96-82C6-4839-A773-2B3900F319D8-- From pusateri@bangj.com Mon Dec 16 13:38:47 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641CB1A82E2 for ; Mon, 16 Dec 2013 13:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtf--ShlIJ4N for ; Mon, 16 Dec 2013 13:38:46 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) by ietfa.amsl.com (Postfix) with ESMTP id 61C4C1A1F1B for ; Mon, 16 Dec 2013 13:38:46 -0800 (PST) Received: from [172.16.10.151] (cpe-071-070-131-186.nc.res.rr.com [71.70.131.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 7A403DB5 for ; Mon, 16 Dec 2013 16:38:45 -0500 (EST) From: Tom Pusateri Content-Type: multipart/signed; boundary="Apple-Mail=_6AE7B0BE-CC90-45FC-91E4-3B7FEE45BD5A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <2AA6D6FD-FDEE-450B-8CD3-F237176F9E45@bangj.com> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Date: Mon, 16 Dec 2013 16:38:44 -0500 References: To: dnssd@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1812) Subject: Re: [dnssd] service instance names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 21:38:47 -0000 --Apple-Mail=_6AE7B0BE-CC90-45FC-91E4-3B7FEE45BD5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Reading further it looks like RFC 6763 answers my question for me. Instance names can contain '.'. Service names must only have two labels = with the 2nd label being either _udp or _tcp. So in my case, the instance name is 934406fa._sub and the service name = is _apple-mobdev2._tcp Thanks, Tom On Dec 16, 2013, at 4:24 PM, Tom Pusateri wrote: > Quick question about service names: >=20 > RFC 6763 describes the general format of service instance names in = Section 4.1: >=20 > Service Instance Name =3D . . >=20 > In looking at an example from an iPhone, I see: >=20 > 934406fa._sub._apple-mobdev2._tcp.local. >=20 > Is the service _apple-mobdev2 and the instance 934406fa._sub? >=20 > Or is the service _sub._apple-mobdev2 and the instance 934406fa? >=20 > Are there any restrictions on service names like they can't contain a = '.'? >=20 > Thanks, > Tom > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_6AE7B0BE-CC90-45FC-91E4-3B7FEE45BD5A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSr3LkAAoJEPk0GMVmUuYMzNQIAIQskh8IT1QOecptQTr/b/Yj Ga7xqu6NboLYhIaAMGtBk15UEP7Jq1Y0ln9NZDloMqQJ1vnLboRUTXqqZ2CGSx7w tLvxMI214bqy0kPCy2VQLaACgIsPEQ2IWP49dkJioYpn7nB9sWrMrTZFXR3H6r8h VwKeu4jmW0wKlOyZ+5H5bHtKLZijjNo5zEef26Q73v3KL46hc1XkUXLrIH9F/Lbg 9fPnmYFBRd3UoD1/zvo7T9zPR8evgZk8fqE/gxJAIIfCVET/XZqhpRjwXlDn8HTJ rJ86YIqzqs2wW+cwjtQSCtJi5xGwxK7jY0mIzzIW2A5gBwYnwVFcV+EsL5UNbIQ= =3Utz -----END PGP SIGNATURE----- --Apple-Mail=_6AE7B0BE-CC90-45FC-91E4-3B7FEE45BD5A-- From ajs@anvilwalrusden.com Mon Dec 16 13:42:57 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391641ACCD8 for ; Mon, 16 Dec 2013 13:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwloVUU5bMos for ; Mon, 16 Dec 2013 13:42:55 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 72CE31ADBCD for ; Mon, 16 Dec 2013 13:42:55 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6ED138A031 for ; Mon, 16 Dec 2013 21:42:54 +0000 (UTC) Date: Mon, 16 Dec 2013 16:42:53 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20131216214252.GI1828@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] service instance names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 21:42:57 -0000 On Mon, Dec 16, 2013 at 04:24:46PM -0500, Tom Pusateri wrote: > In looking at an example from an iPhone, I see: > > 934406fa._sub._apple-mobdev2._tcp.local. > > Is the service _apple-mobdev2 and the instance 934406fa._sub? My reading is that it's this one. The _sub label is an indication of subtyping of the service. See section 7.1. > Are there any restrictions on service names like they can't contain a '.'? Well, they _won't_ contain a '.', except in the presentation format where they always appear with a '.' (because the service name is two labels long). The labels in the service names are constructed out of IANA-registered names for protocols and services, so I believe they'll all be ASCII and will generally follow LDH+underscore rules. The end of Section 7.1 is quite clear that the subtype string can include any UTF-8 at all, which means that things like "_Andrew's ∆. printers" are allowed. The document isn't perfectly clear, but presumably it wants the dot to be escaped in the same way that it would be for Instances, documented in section 4.3. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From kerlyn2001@gmail.com Mon Dec 16 19:13:24 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156091AE063 for ; Mon, 16 Dec 2013 19:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.487 X-Spam-Level: X-Spam-Status: No, score=0.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqWLTwDH1p6B for ; Mon, 16 Dec 2013 19:13:20 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2702F1ADFDF for ; Mon, 16 Dec 2013 19:13:20 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so5975981oag.37 for ; Mon, 16 Dec 2013 19:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iB7Sla6MOzbN+kbH0IKLPNoCYfYjgddLOwsDUI2zAk4=; b=IXheakjiMAuPoIveagCxLaammbSuLfjNN0/dgOxxkibjNQ+z2R5kTXtak20cPviXzC l3kE1/ZLR4hpS/Yxyanc+n1fzE9o+CKhJ0y54G/6JwyENbDD9g8A0T+XfeTnSxQ/yggN WantBlMWJbmFJdJgZnn8p6xOfkhbwSIoW51SSvInUgTKKxQXb8WWRm2ONSEeUGWkgA7l pNau+HWJ1yn4W+gApcikCQX4VmO7uGN3dx9qzkfU0J8S1LWT409MsiTJDTFsPcuG7/Pi AliaXO8kvaRMzmbtA6A7BoLdXXhc5kKTc9CisG2v0e/4I5kESunzKWRkUMbKKWcf80Qz UUOw== MIME-Version: 1.0 X-Received: by 10.60.124.138 with SMTP id mi10mr9197652oeb.57.1387249999140; Mon, 16 Dec 2013 19:13:19 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Mon, 16 Dec 2013 19:13:19 -0800 (PST) In-Reply-To: <20131216214252.GI1828@mx1.yitter.info> References: <20131216214252.GI1828@mx1.yitter.info> Date: Mon, 16 Dec 2013 22:13:19 -0500 X-Google-Sender-Auth: o5C6o6NFkSWT7lhVdkFDWHCG7fQ Message-ID: From: Kerry Lynn To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7b5d5fba69df9904edb24f06 Cc: dnssd@ietf.org Subject: Re: [dnssd] service instance names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 03:13:24 -0000 --047d7b5d5fba69df9904edb24f06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 16, 2013 at 4:42 PM, Andrew Sullivan wr= ote: > On Mon, Dec 16, 2013 at 04:24:46PM -0500, Tom Pusateri wrote: > > In looking at an example from an iPhone, I see: > > > > 934406fa._sub._apple-mobdev2._tcp.local. > > > > Is the service _apple-mobdev2 and the instance 934406fa._sub? > > My reading is that it's this one. The _sub label is an indication of > subtyping of the service. See section 7.1. > > Tom, I'm guessing this is the name (left side) of a PTR record. The enti= re substring "934406fa._sub._apple-mobdev2._tcp" is the part. "934406fa" is a subtype of the "_apple-mobdev2" service type. The part will be the value (right side) of the PTR record. To summarize, PTR records are identified by . names while SRV and TXT records are identified by .. names. > Are there any restrictions on service names like they can't contain a '.'= ? > > Well, they _won't_ contain a '.', except in the presentation format > where they always appear with a '.' (because the service name is two > labels long). The labels in the service names are constructed out of > IANA-registered names for protocols and services, so I believe they'll > all be ASCII and will generally follow LDH+underscore rules. > > Right. Service name format is discussed in RFC 2782. The end of Section 7.1 is quite clear that the subtype string can > include any UTF-8 at all, which means that things like "_Andrew's =E2=88= =86. > printers" are allowed. To quote RFC 6763 section 7.1: "Subtype strings are not required to begin with an underscore, though they often do." > The document isn't perfectly clear, but > presumably it wants the dot to be escaped in the same way that it > would be for Instances, documented in section 4.3. > > I agree. Regards, -K- > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --047d7b5d5fba69df9904edb24f06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 16, 2013 at 4:42 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
On Mon,= Dec 16, 2013 at 04:24:46PM -0500, Tom Pusateri wrote:
> In looking at an example from an iPhone, I see:
>
> 934406fa._sub._apple-mobdev2._tcp.local.
>
> Is the service _apple-mobdev2 and the instance 934406fa._sub?

My reading is that it's this one. =C2=A0The _sub label is an indi= cation of
subtyping of the service. =C2=A0See section 7.1.

Tom, I'm guessing this is= the name (left side) of a PTR record.=C2=A0 The entire
substring "= 934406fa._sub._apple-mobdev2._tcp" is the <Service> part.
&qu= ot;934406fa" is a subtype of the "_apple-mobdev2" service ty= pe.=C2=A0 The
<Instance> part will be the value (right side) of the PTR = record.=C2=A0 To
summarize, PTR records are identified by <Service>= ;.<Domain> names
while SRV and TXT records are identifi= ed by <Instance>.<Service>.<Domain>
names.

> Are there any restrictions on service names like they can't contai= n a '.'?

Well, they _won't_ contain a '.', except in the presentat= ion format
where they always appear with a '.' (because the service name is tw= o
labels long). =C2=A0The labels in the service names are constructed out of<= br> IANA-registered names for protocols and services, so I believe they'll<= br> all be ASCII and will generally follow LDH+underscore rules.

Right.=C2=A0 Service name format is discussed in RFC = 2782.

The end of Section 7.1 is quite clear that the subtype string can
include any UTF-8 at all, which means that things like "_Andrew's = =E2=88=86.
printers" are allowed.

To quote RFC 6763 se= ction 7.1: "Subtype strings are not required to
begin with an underscore, though they often do."
=C2=A0
The document isn't perfectly clear, but presumably it wants the dot to be escaped in the same way that it
would be for Instances, documented in section 4.3.

I agree.

Regards, -K-
=C2=A0
=
Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
___________________________= ____________________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd

--047d7b5d5fba69df9904edb24f06-- From kulakov.ilya@gmail.com Wed Dec 18 13:58:35 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381E91AE1FE for ; Wed, 18 Dec 2013 13:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snqWX2xUo0xo for ; Wed, 18 Dec 2013 13:58:33 -0800 (PST) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D131E1AE212 for ; Wed, 18 Dec 2013 13:58:32 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id d49so103231eek.32 for ; Wed, 18 Dec 2013 13:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=NOteylJERtL4iE4R0svUiZoKBP654HMRSA0rNm/sqFo=; b=epGTJ7669mbzwXZYNcafhtsoTyioerKQL8B2zsYiF8oqH06/MeROdXLaadG7dVlM64 GY8xRivW4fZn0bg9efDmgcpy0Sqc0USNE1m44CSXYWNg+ThfEgu5RoR1FBM+rg5MFqGN zg3O+x6AOk3KQEQzVEH+cjWRWTQZ+derSdK5HclQGdh28FSiWTiKhBagyGN/YZwU47QN 3YTh8/4rRBr1aLfkUH152ugc9YElBQzDw8raG83oDfpWkeCxHf6BEqu5l0kxvsFX07u4 NunqUF7+OvVOTVyV18RuEjdsQI0NCOeojw7OAkTTDWWqEOP5tNSr/rEWImDQzNkHjfRE tvFQ== X-Received: by 10.14.109.5 with SMTP id r5mr151400eeg.110.1387403910898; Wed, 18 Dec 2013 13:58:30 -0800 (PST) Received: from [192.168.2.98] ([2.238.193.50]) by mx.google.com with ESMTPSA id n1sm3724635eep.20.2013.12.18.13.58.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Dec 2013 13:58:29 -0800 (PST) From: Ilya Kulakov Content-Type: multipart/signed; boundary="Apple-Mail=_C21DB80C-FA3C-4FAD-BE98-9B7CD4D9EE01"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <558DE89C-4EBA-44E9-A691-A7FCE23E5C25@gmail.com> Date: Wed, 18 Dec 2013 22:58:27 +0100 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [dnssd] Comparison of DNS names with subtype X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 21:58:35 -0000 --Apple-Mail=_C21DB80C-FA3C-4FAD-BE98-9B7CD4D9EE01 Content-Type: multipart/alternative; boundary="Apple-Mail=_A3363B21-9F9B-40AE-A78E-A9187D9A211F" --Apple-Mail=_A3363B21-9F9B-40AE-A78E-A9187D9A211F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 According to RFC 6763, subtypes have absolutely no constraints and can = be expressed using arbitrary 8-bit data. However, there is the note about comparison: Note, however, that even when using arbitrary 8-bit data for subtype strings, DNS name comparisons are still case-insensitive, so (for example) the byte values 0x41 and 0x61 will be considered equivalent for subtype comparison purposes. But as all we know, =93lowering=94 is locale-dependant operation. I = believe that authors meant very specific translation map for lowering = subtype strings, but I cannot find it. Could you either point me to an RFC that defines such map or clarify the = process of lowering subtype strings?= --Apple-Mail=_A3363B21-9F9B-40AE-A78E-A9187D9A211F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 According to RFC 6763, subtypes have absolutely no = constraints and can be expressed using arbitrary 8-bit = data.
However, there is the note about comparison:
Note, however, that even when using arbitrary 8-bit data = for
subtype strings, DNS name comparisons are still = case-insensitive, so
(for example) the byte values = 0x41 and 0x61 will be considered
equivalent for = subtype comparison purposes.
But as all we know, = =93lowering=94 is locale-dependant operation. I believe that authors = meant very specific translation map for lowering subtype strings, but I = cannot find it.

Could you either point me to an RFC = that defines such map or clarify the process of lowering subtype = strings?
= --Apple-Mail=_A3363B21-9F9B-40AE-A78E-A9187D9A211F-- --Apple-Mail=_C21DB80C-FA3C-4FAD-BE98-9B7CD4D9EE01 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPMTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBS4wggQWoAMC AQICEQD9NXZ96VAYv8SqMHcSmTCUMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTAyMzAwMDAwMFoXDTE0MTAyMzIzNTk1OVowJzElMCMGCSqG SIb3DQEJARYWa3VsYWtvdi5pbHlhQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMLjQCCI48sfUfJCdA5U7nd0MsOwgoHWjb37vasvM0Xa64t1Jq/qhNi47z00toLjgKK eVAf7Fw8MmEIbo+DXmvcapSEa1gA4ArEPgTdXa4SGY2GGVtii0mCSwVMGKxnChpHGAc2jFOKuxDM touy+lzjOjKIQzLjXoOkqi/IfscSxMP0+LGpAzDR7zdyBKplzfs00zV3gR9k7bAHmFavFFXclZLd uNTkb1xUxCHNrUID771eHDy/3sWDDjjo9htRXdXc6UrYiKu6PGWOhhrLI2PoX97BCqadm8LprrYV UrJKx/3fhrZ8kRy89qkddgKLsgKkhbhdVKqTZH0/vH1qVLsCAwEAAaOCAeYwggHiMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBRf7g8/dUk4BzmkNmF4+YfvrfGnLjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiG Rmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCEGA1UdEQQaMBiBFmt1bGFr b3YuaWx5YUBnbWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggEBAH5wnPoVJC731904P5Tr7fcpRgsq hN9pgs0GJpj/WiGCwd2hv5FEF9C9i2IpJqAT8Ekk9/7pk43MR4AtxVC7mok95yblKlOTb6z+ykYw BpL1rBoiFm9jYHbXaKx7MGaiVDAT8nHFWuDXL/isg39VsbaYjxMMkLsypxubdpvoRf8VVzjB+Xqw Qoli8hDNHrjPQVjNYn+iHKWhmRQLOB+gOm9YV5tgzh74gzEHAOQPvigXSppDnW9C/+G7T1BSxS1l m+KWSv6l58kojQr19yzK7Y+nxVirBuAvu45Jl1GUgBftkr/HUJhYM+UpKSeCE5Gi0mN6eeh5hgyB 09N6M1P7pOUxggOuMIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAP01dn3pUBi/xKowdxKZMJQwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMjE4MjE1ODI4WjAjBgkqhkiG9w0BCQQxFgQU5RK144cF ymUYfolf7Ptwv1E/hi8wgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIRAP01dn3pUBi/xKowdxKZMJQwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGT MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA/TV2felQGL/EqjB3EpkwlDANBgkq hkiG9w0BAQEFAASCAQABSH3C4bHUjtvNXCFxqklPXHRSzUDKwfA7ToI9AdEKM0mwnrHSAdgfPwNm kRhV4CHoxf/raK0Hdw3ssWCjkhsVUutIJFY2/D78ogzu42FnDOhoDcL9GyOSw1GSAfgCpQgd/1YH byhEYR47O61fecLx2AK9xWnz2Lq0DEqNYTjf/ClmFMTcV05ziyXppMmXDy6cYYl6ERfUN6+2Z+Eb 7XFOkNYH+gA9JcoE5GMcIpyc3YVXfLHBn4mP6b7mh2Ywhl6PO0aRjamDcO1T5NnguJcEjxsVUHsw 2wSO8BogdigbtYpOMiENe9VCLkLfQmIm8QqpwcSP06KNdPZrYl9sAR/BAAAAAAAA --Apple-Mail=_C21DB80C-FA3C-4FAD-BE98-9B7CD4D9EE01-- From ajs@anvilwalrusden.com Wed Dec 18 14:16:19 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6811AE197 for ; Wed, 18 Dec 2013 14:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOYgj2xpeYbR for ; Wed, 18 Dec 2013 14:16:15 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A90B81AE035 for ; Wed, 18 Dec 2013 14:16:15 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C56A28A031 for ; Wed, 18 Dec 2013 22:16:13 +0000 (UTC) Date: Wed, 18 Dec 2013 17:16:12 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20131218221612.GW6418@mx1.yitter.info> References: <558DE89C-4EBA-44E9-A691-A7FCE23E5C25@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <558DE89C-4EBA-44E9-A691-A7FCE23E5C25@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] Comparison of DNS names with subtype X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 22:16:19 -0000 On Wed, Dec 18, 2013 at 10:58:27PM +0100, Ilya Kulakov wrote: > According to RFC 6763, subtypes have absolutely no constraints and can be expressed using arbitrary 8-bit data. Yes. > However, there is the note about comparison: > Note, however, that even when using arbitrary 8-bit data for > subtype strings, DNS name comparisons are still case-insensitive, so > (for example) the byte values 0x41 and 0x61 will be considered > equivalent for subtype comparison purposes. Ugh. This clearly should have been "still case-insensitive for comparison of ASCII-range characters" or something like that. The DNS RFCs are quite clear that the case insensitivity is for comparison of ASCII characters only, because when they were written there was no way to know what the eventual internationalization story would be. The bizarre effect of this, actually, is that E and e match for the purposes of the DNS _even if_ the rest of the string isn't all ASCII characters. The upshot of this is that école, éCole, écOLE, and so on all match; but école and École (and Ecole) do not. Note that I, at least, consider this matching rule a bug (or rather, a mistake in the design) in STD13. > But as all we know, “lowering” is locale-dependant operation. I believe that authors meant very specific translation map for lowering subtype strings, but I cannot find it. > This isn't case fold. It's just case folding for the ASCII range, so the locale doesn't enter into it. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From cheshire@apple.com Fri Dec 20 11:25:46 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2186C1ADFAB for ; Fri, 20 Dec 2013 11:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.44 X-Spam-Level: X-Spam-Status: No, score=-107.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK53aeBg_YQ5 for ; Fri, 20 Dec 2013 11:25:44 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 86A081ADF99 for ; Fri, 20 Dec 2013 11:25:44 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) 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 <0MY4007OQDXGLSB0@mail-out.apple.com> for dnssd@ietf.org; Fri, 20 Dec 2013 11:25:26 -0800 (PST) X-AuditID: 11807153-b7f396d00000722b-09-52b499a544e5 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id A7.0E.29227.6A994B25; Fri, 20 Dec 2013 11:25:26 -0800 (PST) Received: from [10.0.1.2] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MY4002QSDYDFN70@koseret.apple.com> for dnssd@ietf.org; Fri, 20 Dec 2013 11:25:25 -0800 (PST) From: Stuart Cheshire In-reply-to: Date: Fri, 20 Dec 2013 11:25:24 -0800 Message-id: References: To: Tom Deseyn X-Mailer: Apple Mail (2.1827) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiON1OXXfZzC1BBi13WSzeL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOOHpjEWzOSpOPOjj62B8RBnFyMnh4SAicTlWXfZIGwxiQv3 1gPZXBxCAi1MEsdffGWHcA4ySTQ9vAlWxSygI9H7/RsziM0roCexcd5sMFtYwEXi9PxfYDVs AloSLz5fAbM5BYIlnr69wQhiswioShz/8pgRYo6QxIJrW9ghbG2JJ+8usELMtJFoO/oRrFdI IECi4+s8sPkiQL0NJxcydTFyAF0qKzH/dOkERoFZSC6aheSiWUimLmBkXsUoUJSak1hprJdY UJCTqpecn7uJERR4DYXBOxj/LLM6xCjAwajEwysRuSVIiDWxrLgy9xCjBAezkgjvvAlAId6U xMqq1KL8+KLSnNTiQ4zSHCxK4ryHu4FSAumJJanZqakFqUUwWSYOTqkGxm770k+7n7TM0hZc /q/qkIdx/v/tG4/41rce3WtTZy4pskMsnsnNO+aNpEXgp841k94+zPQq415RlsnVfLjz1881 kR0stq9adPdWveG7zVH9ceKzXytfrL9VeHF/Oncv7xSlQB2TJutJ4YX37Q98EHq/aGrJJZF2 taYij6s/7s99bHgzTTl3mxJLcUaioRZzUXEiAARvdIo4AgAA Cc: dnssd@ietf.org Subject: Re: [dnssd] rfc6762 Multicast DNS A/AAAA additional records X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 19:25:46 -0000 On 14 Dec, 2013, at 05:03, Tom Deseyn wrote: > Hi all, > > RFC6762 states that a response on a query for an A record should include AAAA answers and vice versa. > > Would it makes sense to generalize this to requiring that additional A/AAAA records should be added to any message which contains an A/AAAA record? > > For example if a machine drops an IPv6 address this results in a message with an AAAA record with ttl 0. The previous paragraph would mean that other addresses still valid for this machine (IPv4 and IPv6) are included in the message. Yes, this makes perfect sense. RFC 6762 says: When a Multicast DNS responder places an IPv4 or IPv6 address record (rrtype "A" or "AAAA") into a response message, it SHOULD also place any records of the other address type with the same name into the additional section, if there is space in the message. This is to provide fate sharing, so that all a device's addresses are delivered atomically in a single message, to reduce the risk that packet loss could cause a querier to receive only the IPv4 addresses and not the IPv6 addresses, or vice versa. So, I think this correctly covers the case of a AAAA record with zero TTL. An interesting question would be if we should apply this more generally: If a device sends a response message containing an NSEC asserting the non-existence of a AAAA record, should it also volunteer any A records that do exist for that name? Stuart Cheshire From ajs@anvilwalrusden.com Fri Dec 20 12:11:38 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179281AE112 for ; Fri, 20 Dec 2013 12:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsxTqNQrB2dP for ; Fri, 20 Dec 2013 12:11:31 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 26E851AE0A0 for ; Fri, 20 Dec 2013 12:11:31 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B1D298A031 for ; Fri, 20 Dec 2013 20:11:28 +0000 (UTC) Date: Fri, 20 Dec 2013 15:11:27 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20131220201127.GB1369@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] rfc6762 Multicast DNS A/AAAA additional records X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 20:11:38 -0000 On Fri, Dec 20, 2013 at 11:25:24AM -0800, Stuart Cheshire wrote: > > An interesting question would be if we should apply this more generally: If a device sends a response message containing an NSEC asserting the non-existence of a AAAA record, should it also volunteer any A records that do exist for that name? > In the old-fashioned DNS, of course, such a record would be ignored as probable poison. If you expect to re-use resolution libraries, then the answer to the above is therefore "probably not", but if you expect the libraries to be completely different them I can't see any harm. A -- Andrew Sullivan ajs@anvilwalrusden.com From rdroms.ietf@gmail.com Sat Dec 21 11:49:07 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D291AE022 for ; Sat, 21 Dec 2013 11:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtJLsBN9MOV6 for ; Sat, 21 Dec 2013 11:49:06 -0800 (PST) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id CFE7B1AE01F for ; Sat, 21 Dec 2013 11:49:05 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id j5so3847327qaq.5 for ; Sat, 21 Dec 2013 11:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pM1Mlykioq4bjW35EOdW0Bf2nOF0Wb5OMedJSHYbXm4=; b=wi+rLFQTm9fEP2T4VoXWxMrw6GoG2pN4m4XWDrAu1K0edneodpHe1pZvMJYK7LmOKd +DMgccHu2qYshVD1jrvOpzhRAseKn9Q0c/30SgVj3mlK6XZpPcUOiGy72m8PQGnTux8u k4WkTPHnNvnXWz2CQxrJDSFaDAv2a6vAzY+JPxykvsdxpE5A2DfUCfCTxydHRsij6Bz2 sBTJANXRu6FV07prTQAy7HZq7l+D9aMfX62j3ys7zumtcJqr9GtsoOdp/hPEH8n1PO9W mIxXSRM8k+zHlC6OG9ogiY+FMXN3vShPjf6OdQ/EzbKOfB1p+j348hEwfhiXAkUrF7dP B42A== X-Received: by 10.49.28.166 with SMTP id c6mr25835321qeh.80.1387655343059; Sat, 21 Dec 2013 11:49:03 -0800 (PST) Received: from ?IPv6:2001:4830:16b1:1:69f3:bec6:e0fd:51bb? ([2001:4830:16b1:1:69f3:bec6:e0fd:51bb]) by mx.google.com with ESMTPSA id r5sm22182873qan.4.2013.12.21.11.49.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Dec 2013 11:49:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: Date: Sat, 21 Dec 2013 08:58:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1045C118-F3F3-4909-8CC0-4BD386102757@gmail.com> References: To: "dnssd@ietf.org" X-Mailer: Apple Mail (2.1510) Cc: cheshire@apple.com, "Kerry kerlyn@ieee.org" Subject: Re: [dnssd] Adopt draft-lynn-dnssd-requirements as a WG document X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2013 19:49:07 -0000 Hearing no objections, adoption of draft-lynn-dnssd-requirements as a WG = document has been confirmed. Authors, please republish draft-lynn-dnssd-requirements as = draft-ietf-dnssd-requirements. - Ralph