Re: Bonjour-dev Digest, Vol 10, Issue 19
Sabahattin Gucukoglu <listsebby@me.com> Thu, 21 February 2013 20:55 UTC
Return-Path: <listsebby@me.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36AB21F8F41 for <ietf@ietfa.amsl.com>; Thu, 21 Feb 2013 12:55:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUusMWUsLLxH for <ietf@ietfa.amsl.com>; Thu, 21 Feb 2013 12:55:41 -0800 (PST)
Received: from nk11p04mm-asmtp001.mac.com (nk11p04mm-asmtp001.mac.com [17.158.236.236]) by ietfa.amsl.com (Postfix) with ESMTP id 024CD21F8F40 for <ietf@ietf.org>; Thu, 21 Feb 2013 12:55:40 -0800 (PST)
Received: from [192.168.1.5] (natbox.sabahattin-gucukoglu.com [213.123.192.30]) by nk11p04mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MIL0048V8SP35B0@nk11p04mm-asmtp001.mac.com> for ietf@ietf.org; Thu, 21 Feb 2013 20:55:39 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-21_08:2013-02-21, 2013-02-21, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1302210211
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Bonjour-dev Digest, Vol 10, Issue 19
From: Sabahattin Gucukoglu <listsebby@me.com>
In-reply-to: <607A7C4F-2FBC-4DCD-853E-8E8735394991@latencyzero.com>
Date: Thu, 21 Feb 2013 20:55:36 +0000
Content-transfer-encoding: quoted-printable
Message-id: <3E07105E-58DC-4E08-AC9F-D259A0A4B16F@me.com>
References: <mailman.9.1361476805.17107.bonjour-dev@lists.apple.com> <5126829A.7090509@oracle.com> <607A7C4F-2FBC-4DCD-853E-8E8735394991@latencyzero.com>
To: Rick Mann <rmann@latencyzero.com>
X-Mailer: Apple Mail (2.1499)
Cc: bonjour-dev@lists.apple.com, David Brower <david.brower@oracle.com>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 20:55:42 -0000
(Because this was brought up very, very recently.) On 21 Feb 2013, at 20:28, Rick Mann <rmann@latencyzero.com> wrote: > On Feb 21, 2013, at 12:24 , David Brower <david.brower@oracle.com> wrote: >> It depends on the records. If you phrase it like you that, you will probably get the blank stare answer. When you start talking about the PTR, SRV and TXT records specifically, then you'll have a case -- but it isn't really Bonjour that is the proximate force, because those were issues against interpretations of the previous RFCs. >> >> Now, the legalistic point I'm debating at the moment is whether it is proper and/or legal to have the SRV record use as the target name the string version of an ip4 address, eg: "192.169.0.145". That's a perfectly legal and representable set of characters for a hostname, so maybe OK. How about for an ip6 address with colons, which aren't allowed in hostnames? > > All I know is that a couple years ago, I tried and failed with both DynDNS and DNSMadeEasy to get them to allow me to put spaces in TXT records. I cited all relevant material I could find, but they kept going back to the original DNS specifications saying those didn't allow spaces. RFC 1035, 2.3.1, wisely advises the use of compatible constraints on labels in host names. I am aware that DNS is binary transparent, and mDNS/DNS-SD make use of that feature to be useful, but I can well understand the scepticism of your DNS hosts. Perhaps this is a legitimate call to relax the restrictions, *if* the operator/user is aware of the potential consequences. Cheers, Sabahattin
- Re: Bonjour-dev Digest, Vol 10, Issue 19 Sabahattin Gucukoglu
- Re: Bonjour-dev Digest, Vol 10, Issue 19 Mark Andrews