Re: Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs)

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Mon, 06 February 2006 20:00 UTC

From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs)
Date: Tue, 07 Feb 2006 05:00:34 +0900
Lines: 29
References: <8E296595B6471A4689555D5D725EBB21012DC25E@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Olaf Kolkman <olaf@nlnetlabs.nl>, Harald Tveit Alvestrand <harald@alvestrand.no>, Mark Andrews <Mark_Andrews@isc.org>, namedroppers@ops.ietf.org, dhcwg <dhcwg@ietf.org>, Stig Venaas <Stig.Venaas@uninett.no>, "Ralph Droms (rdroms)" <rdroms@cisco.com>
X-From: dhcwg-bounces@ietf.org Mon Feb 06 21:03:51 2006
Return-path: <dhcwg-bounces@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
To: "Bernie Volz (volz)" <volz@cisco.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB21012DC25E@xmb-rtp-20a.amer.cisco.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
X-Message-ID:
Message-ID: <20140418072129.2560.97075.ARCHIVE@ietfa.amsl.com>

Bernie Volz (volz) wrote:

> So, I think we want to drop or replace the LAST paragarph in section
> 3.3.1 of draft-ietf-dhc-fqdn-option-11.txt.

Sure.

> Actually, I do now have a suggestion:
> 
>    Clients and servers SHOULD follow the character-set recommendations
>    of RFC 1035 section 2.3.1.  However, implementers SHOULD also
>    be aware that some client software may use other character-sets.
>    This specification does not require support for any other
>    character-sets.
> 
> If you don't like this, PLEASE SUGGEST ALTERNATIVE TEXT.

We should also give reference to section 2.3.3.

We don't have to say anything about "character-sets".

So, the text could be:

>    Clients and servers SHOULD follow the character-set recommendations
>    of RFC 1035 section 2.3.1.  However, implementers SHOULD also
>    be aware that some client software may "use the full binary octet
>    capabilities in names" as described in section 2.3.3 of RFC1035.

						Masataka Ohta