From discuss-bounces@apps.ietf.org Thu Nov 02 13:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhQC-0000py-DH; Thu, 02 Nov 2006 13:36:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhN4-0006uf-E8 for discuss@apps.ietf.org; Thu, 02 Nov 2006 13:32:58 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfh9w-0007nL-Dr for discuss@apps.ietf.org; Thu, 02 Nov 2006 13:19:30 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B59B51422A9; Thu, 2 Nov 2006 10:19:19 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02679-08; Thu, 2 Nov 2006 10:19:16 -0800 (PST) Received: from [192.168.1.102] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DB62E1422A0; Thu, 2 Nov 2006 10:19:15 -0800 (PST) In-Reply-To: <42F3BE57026C6E49B09E267EEF639D560124680A@ms-dt01thalia.tsn.tno.nl> References: <42F3BE57026C6E49B09E267EEF639D560124680A@ms-dt01thalia.tsn.tno.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-10--499239281 Message-Id: <07AE8F7D-B976-4B0B-A63D-CCE3B506D96D@osafoundation.org> From: Lisa Dusseault Subject: Re: I-D on Registry for tv:URIs Date: Thu, 2 Nov 2006 10:19:14 -0800 To: "Deventer, M.O. (Oskar) van" X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: discuss@apps.ietf.org, "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-10--499239281 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed IANA runs a number of IETF registries at no charge to registrants, provided that the registration process is sufficiently low-cost and well-defined. You should try to meet with the IANA people in San Diego at their "office hours" desk, and get more specifics. Lisa On Oct 23, 2006, at 8:15 AM, Deventer, M.O. (Oskar) van wrote: > Who will be paying for the tv:URI registry? > > We contacted the people behind Showview.com (VCRplus in the USA) > and asked them about their business model. Showview maintains lists > of channel numbers for the programming of video recorders. It is > publications companies, TV listing companies and broadcasters that > pay annual fees for participation in the Showview system. They > inform Showview of any changes. The maintenance of channel lists is > done by a single person in part-time, triggered by request from > publishers. > > Perhaps a registry for tv:URIs could follow a similar business model. > > Oskar > > From: Keesmaat, N.W. (Iko) [mailto:iko.keesmaat@tno.nl] > Sent: maandag 9 oktober 2006 10:39 > To: discuss@apps.ietf.org > Cc: Zigmond, Dan > Subject: I-D on Registry for tv:URIs > > All, > > Please note that an internet-draft "Registry for tv:URIs" is > available from the repository: > > https://datatracker.ietf.org/public/idindex.cgi? > command=id_detail&id=15222; > > http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-00.txt > > > This draft describes the registry for tv:URIs that we feel is > needed as has been discusses on this list before. > > We welcome your responses. > > Iko Keesmaat (and Oskar van Deventer). > > =============================== > Iko Keesmaat > TNO Information and Communication Technology > Room BA201b > Brassersplein 2 > P.O. Box 5050 > 2600 GB Delft > The Netherlands > Tel: +31 15 2857159 > Mob: +31 6 51916191 > Fax: +31 15 2857349 > E-mail: iko.keesmaat@tno.nl > > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html --Apple-Mail-10--499239281 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 IANA runs a number of IETF = registries at no charge to registrants, provided that the registration = process is sufficiently low-cost and well-defined.=A0 You should try to = meet with the IANA people in San Diego at their "office hours" desk, and = get more specifics.

Lisa

= On Oct 23, 2006, at 8:15 AM, Deventer, M.O. (Oskar) van wrote:

Who will be paying for the tv:URI = registry?
=A0
We contacted the people behind Showview.com = (VCRplus in the USA)=A0and asked them about their business model. = Showview maintains lists of channel numbers for the programming of video = recorders. It is publications companies, TV listing companies and = broadcasters=A0that pay annual fees for participation in the Showview = system. They inform Showview of any changes.=A0The maintenance of channel lists is done = by a single person in part-time, triggered by request from = publishers.
=A0
Perhaps a registry for tv:URIs could follow = a similar business model.
=A0
Oskar

=
From: = Keesmaat, N.W. (Iko) [mailto:iko.keesmaat@tno.nl] =
Sent: maandag 9 oktober 2006 10:39
To: discuss@apps.ietf.org
Cc:<= /B> Zigmond, Dan
Subject: I-D on Registry for = tv:URIs

All,

Please = note that an internet-draft "Registry for tv:URIs" is available from the = repository:

https://datatracker.ietf.org/public/idindex.cgi?command=3Did_de= tail&id=3D15222; =

<= U>http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-00.txt=


This draft = describes the registry for tv:URIs that we feel is needed as has been = discusses on this list before.

We welcome your responses.

Iko Keesmaat (and Oskar van Deventer).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Iko Keesmaat
TNO Information and = Communication Technology
Room BA201b
Brassersplein = 2
P.O.= Box 5050
2600 GB Delft
The Netherlands
Tel: +31 15 = 2857159
Mob: +31 6 51916191
Fax: +31 15 = 2857349
E-mail: iko.keesmaat@tno.nl =


This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclai= mer/email.html

This e-mail and its contents are subject to = the DISCLAIMER at http://www.tno.nl/disclai= mer/email.html

= --Apple-Mail-10--499239281-- From discuss-bounces@apps.ietf.org Thu Nov 02 16:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfk1X-0000oR-D8; Thu, 02 Nov 2006 16:22:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfjLX-0001mQ-5a for discuss@apps.ietf.org; Thu, 02 Nov 2006 15:39:31 -0500 Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfjLR-0001y1-81 for discuss@apps.ietf.org; Thu, 02 Nov 2006 15:39:31 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 770EE170C; Thu, 2 Nov 2006 20:39:20 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.32M); Thu, 02 Nov 2006 20:39:20 GMT X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID051kkBunu1234Xo1 Received: from [192.168.1.102] ([69.181.78.47]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 13:39:18 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <5D7C52E7-2F9C-48AF-B7C1-D3B8EA822D58@commerce.net> Content-Type: multipart/alternative; boundary=Apple-Mail-14--490836708 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's October Apps Area Activity From: Lisa Dusseault Date: Thu, 2 Nov 2006 12:39:16 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Nov 2006 20:39:18.0540 (UTC) FILETIME=[F80BC4C0:01C6FEBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 X-Mailman-Approved-At: Thu, 02 Nov 2006 16:22:54 -0500 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-14--490836708 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Planning for San Diego: - Apps Area meeting agenda posted, with several tech topics - No Apps area BoFs - WG meetings in San Diego: SIEVE, CALSIFY, WIDEX, IMAPEXT. Document Status and progress PUBLISHED documents this month: - RFC4708: CellML Media Type, a registration of a MIME type for documents in the CellML mathematical modelling language (see www.cellml.org) - RFC4709: Mounting WebDAV Servers, a document type and format for providing information on WebDAV file shares - Note NNTPEXT WG products RFC3977, RFC4642, RFC4643 and RFC4644 (all shepherded by Scott) - Note RFC4648 on Base16, Base32 and Base64 Data Encodings --> Obsoletes RFC3548, which XMPP, DKIM, SDP, Atom, SASL and other documents reference APPROVED documents this month: - draft-newman-i18n-comparator-14 -- defines a registry for comparators and collators, which unblocks important IMAP i18n related work. - draft-ietf-imapext-list-extensions-18 - draft-dusseault-caldav-15 -- Ok, Ted shepherded this one but I did help write it :) - draft-jennings-impp-vcard-08 -- describes how to put IM addresses in VCards Documents in IESG Evaluation: - draft-ietf-imapext-sort: Double-checking if changes needed, now that comparator is approved. - draft-ietf-imapext-annotate-16: Assumed to still be going for Experimental status; if so it'll be discussed Nov 16 by IESG. Documents in IETF Last Call: none Documents in AD Evaluation or otherwise waiting on me: - draft-ietf-usefor-usefor-10, Usenet article format revision: waiting to confirm to send this version for IESG Eval. - draft-ietf-atompub-protocol: Sent my AD evaluation questions and comments to the AtomPub list; haven't finished reviewing discussion progress there. - draft-nottingham-atompub-feed-history: need to do AD evaluation - draft-snell-atompub-feed-license-09.txt : need to review new version to see if the scope of the license is useful according to consensus that arose in last call. Documents needing new versions: - draft-ietf-sieve-3028bis-09: need to deal with ABNF issues, nits, and long thread on escaping non-UTF8 data. - draft-melnikov-imap-expunged-02.txt: Although this draft has been revised since IETF Last Call, dealing with some issues, Alexey is considering merging with a resynch proposal instead of progressing as is. Even if the merge doesn't happen, another draft would still be required to deal with some open issues. Discussion to ensue next week. - draft-ietf-imapext-i18n-06.txt: Probably should be resurrected now that comparator is nearly out the door - draft-kunze-rfc2413bis (Informational, RFC Ed Submission): Author decided to do another revision. Working Group Activity AtomPub: list discussion of AD Evaluation of atompub protocol, also a number of side discussions including several extensions UseFor: Quietly awaiting document approval IMAPExt: Discussing Expunge document and annotate Sieve: Discussing UTF8 escaping issues. Calsify: Steadily resolving issues for revision of RFC2445. Widex: Meeting in San Diego. Other Activity Apps Architecture Review Team : Thomas Roessler reviewed AtomPub protocol document Apps Discuss list: More discussion of TV URIs. W3C related activity: Interest in HTTP revision activity -- Yves Lafon engaged already. HTTP: Significant activity on ietf-http-wg@w3.org (NOT a currently active WG) Lisa --Apple-Mail-14--490836708 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Planning = for San Diego:=A0
- Apps = Area meeting agenda posted, with several tech topics
- No Apps area BoFs
- WG meetings in San Diego: = SIEVE, CALSIFY, WIDEX, IMAPEXT.

Document Status and progress

PUBLISHED = documents this month:=A0
- = RFC4708: CellML Media Type, a registration of a MIME type for documents = in the CellML mathematical modelling language (see www.cellml.org)
- RFC4709: Mounting WebDAV = Servers, a document type and format for providing information on WebDAV = file shares
- Note NNTPEXT WG products = RFC3977, RFC4642, RFC4643 and RFC4644 (all shepherded by = Scott)
- Note RFC4648 on Base16, Base32 = and Base64 Data Encodings
= -->=A0 Obsoletes RFC3548, which XMPP, DKIM, SDP, Atom, SASL = and other documents reference

APPROVED documents this month:
-=A0draft-newman-i18n-comparator-14= -- defines a registry for comparators and collators, which unblocks = important IMAP i18n related work.
- = draft-ietf-imapext-list-extensions-18
- = draft-dusseault-caldav-15 -- Ok, Ted shepherded this one but I did help = write it :)
- draft-jennings-impp-vcard-08 -- = describes how to put IM addresses in VCards
Documents in IESG = Evaluation:
- draft-ietf-imapext-sort: = Double-checking if changes needed, now that comparator is = approved.
- draft-ietf-imapext-annotate-16: = Assumed to still be going for Experimental status; if so it'll be = discussed Nov 16 by IESG.

Documents in = IETF Last Call: none

Documents in = AD Evaluation or otherwise waiting on me:
= -=A0draft-ietf-usefor-usefor-10, Usenet article format revision: = waiting to confirm to send this version for IESG Eval.
- draft-ietf-atompub-protocol: = Sent my AD evaluation questions and comments=A0 to the AtomPub list; = haven't finished reviewing discussion progress there.
- = draft-nottingham-atompub-feed-history: need to do AD = evaluation
= -=A0draft-snell-atompub-feed-license-09.txt=A0: need to review = new version to see if the scope of the license is useful according to = consensus that arose in last call.

Documents needing new versions:
- draft-ietf-sieve-3028bis-09: = need to deal with ABNF issues, nits, and long thread on escaping = non-UTF8 data.
= -=A0draft-melnikov-imap-expunged-02.txt: Although this draft has = been revised since IETF Last Call, dealing with some issues, Alexey is = considering merging with a resynch proposal instead of progressing as = is.=A0 Even if the merge doesn't happen, another draft would still be = required to deal with some open issues.=A0 Discussion to ensue next = week.
-=A0draft-ietf-imapext-i18n-06.txt:= Probably should be resurrected now that comparator is nearly out the = door
-=A0draft-kunze-rfc2413bis = (Informational, RFC Ed Submission): Author decided to do another = revision.

Working Group Activity=A0

AtomPub:=A0 = list discussion of AD Evaluation of atompub protocol, also a number of = side discussions including several extensions
UseFor: Quietly awaiting document approval
IMAPExt: Discussing Expunge document and = annotate
Sieve: Discussing UTF8 escaping = issues.
Calsify: Steadily resolving = issues for revision of RFC2445.
Widex:=A0 = Meeting in San Diego.

Other Activity
Apps Architecture Review Team : = Thomas Roessler reviewed AtomPub protocol document
Apps Discuss list: More discussion of TV = URIs.
W3C related activity: Interest = in HTTP revision activity -- Yves Lafon engaged already.
HTTP: Significant activity on ietf-http-wg@w3.org (NOT a = currently active WG)

In-Reply-To: <454F8701.20302@dcrocker.net> References: <454F8701.20302@dcrocker.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 6 Nov 2006 13:53:35 -0800 To: dcrocker@bbiw.net, discuss@apps.ietf.org From: Randall Gellens Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Dave Crocker X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 11:03 AM -0800 11/6/06, Dave Crocker wrote: > SRV clearly serves as a more generalized and long-term mechanism > for defining a service (and, gosh, doesn't that make the choice of > the RR's name particularly nice?) > > As Eliot notes, however, this builds a dependency on the DNS into > the underlying construct of IP-to-IP rendezvous. While most of the > Internet use today already has that dependency as a pragmatic > realtion, for other reasons, it is not built into the basics of > Internet infrastructure as a formal requirement. > > So changing our model to focus on SRV has some interesting implications. The implications may depend on who is included in "our" (in "changing our model"). A lot of application-level protocols already do, as you note, depend on DNS. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I distrust those people who know so well what God wants them to do, because I notice it always coincides with their own desires. --Susan B. Anthony From discuss-bounces@apps.ietf.org Mon Nov 06 17:00:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCVE-0004hZ-T3; Mon, 06 Nov 2006 16:59:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCVE-0004hS-80 for discuss@apps.ietf.org; Mon, 06 Nov 2006 16:59:36 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCVA-0001Uv-V6 for discuss@apps.ietf.org; Mon, 06 Nov 2006 16:59:36 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M98T146BDS00X708@mauve.mrochek.com> for discuss@apps.ietf.org; Mon, 6 Nov 2006 13:59:03 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M98REL25PC00UHS2@mauve.mrochek.com>; Mon, 06 Nov 2006 13:59:02 -0800 (PST) Message-id: <01M98T13EPQG00UHS2@mauve.mrochek.com> Date: Mon, 06 Nov 2006 13:53:27 -0800 (PST) From: Ned Freed Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) In-reply-to: "Your message dated Mon, 06 Nov 2006 11:03:29 -0800" <454F8701.20302@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <454F8701.20302@dcrocker.net> To: Dave Crocker X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Folks, > This is in response to Eliot's presentation this morning, in the AppsArea and it > is merely intended to solicit comment: > I have always understood the construct of Well-Known Ports as being a means of > standardizing an efficient rendezvous mechanism, for clients to find servers. -- > without quibbling about the terminology that might better cover use in > peer-to-peer scenarios. I think you're talking past each other here. You're referring to our practice of saying things like "SMTP servers listen on port 25 by default" or "HTTP servers normally listen on port 80". Eliot is talking about ports with numeric values less than 1024 being handled distinctly from those above 1024. I am complete agree with Eliot that the "below 1024 are special" notion's time has long since past. It made sense back in the mainframe era, but it was over the minute we started putting machines directly under the control of random users. I certainly don't want to abandon the practice of defining ports associated with specific services and I don't think Eliot is saying that either. > ... > SRV clearly serves as a more generalized and long-term mechanism for defining a > service (and, gosh, doesn't that make the choice of the RR's name particularly > nice?) > As Eliot notes, however, this builds a dependency on the DNS into the underlying > construct of IP-to-IP rendezvous. While most of the Internet use today already > has that dependency as a pragmatic realtion, for other reasons, it is not built > into the basics of Internet infrastructure as a formal requirement. > So changing our model to focus on SRV has some interesting implications. I wasn't entirely clear on what Eliot was trying to say about SRV records. Perhaps someone could recap that here? Ned From discuss-bounces@apps.ietf.org Mon Nov 06 17:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCod-00042G-HY; Mon, 06 Nov 2006 17:19:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCod-00042A-0e for discuss@apps.ietf.org; Mon, 06 Nov 2006 17:19:39 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCoZ-0004ZC-LC for discuss@apps.ietf.org; Mon, 06 Nov 2006 17:19:38 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M98TPZV2B400WWXJ@mauve.mrochek.com> for discuss@apps.ietf.org; Mon, 6 Nov 2006 14:19:08 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M98REL25PC00UHS2@mauve.mrochek.com>; Mon, 06 Nov 2006 14:19:05 -0800 (PST) Message-id: <01M98TPYN9MO00UHS2@mauve.mrochek.com> Date: Mon, 06 Nov 2006 14:16:55 -0800 (PST) From: Ned Freed Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) In-reply-to: "Your message dated Mon, 06 Nov 2006 14:15:26 -0800" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> To: Philip Guenther X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: discuss@apps.ietf.org, Dave Crocker , Ned Freed X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > On Mon, 6 Nov 2006, Ned Freed wrote: > >> This is in response to Eliot's presentation this morning, in the > >> AppsArea and it is merely intended to solicit comment: > > > >> I have always understood the construct of Well-Known Ports as being a > >> means of standardizing an efficient rendezvous mechanism, for clients > >> to find servers. -- without quibbling about the terminology that might > >> better cover use in peer-to-peer scenarios. > > > > I think you're talking past each other here. You're referring to our > > practice of saying things like "SMTP servers listen on port 25 by > > default" or "HTTP servers normally listen on port 80". Eliot is talking > > about ports with numeric values less than 1024 being handled distinctly > > from those above 1024. > Elliot was talking about both in his presentation. The first bit was this > whole thing involving ports 0 to 1023 (which the registry calls "Well > Known Ports"). The second bit was the recommendation that new protocols > should consider using SRV instead of having a particular port number. > > I am complete agree with Eliot that the "below 1024 are special" > > notion's time has long since past. It made sense back in the mainframe > > era, but it was over the minute we started putting machines directly > > under the control of random users. > I agree. > > I certainly don't want to abandon the practice of defining ports > > associated with specific services and I don't think Eliot is saying that > > either. > He didn't suggest that, as it's impossible for protocols below DNS or that > cannot afford to depend on DNS. > > I wasn't entirely clear on what Eliot was trying to say about SRV records. > > Perhaps someone could recap that here? > SRV records good: > - provides fallback/load-balance location mechanism > - avoids tight port # binding > - namespace of assignments is strings (that can be a DNS label) instead > of 16bit numbers > SRV records bad: > - add dependency on DNS > - add latency on first connect, maybe later > - complexity I agree with all of this. On balance I don't think we use SRV records often enough, but I also think there's a point past which they'd be overused. Ned From discuss-bounces@apps.ietf.org Mon Nov 06 17:32:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD05-0004DO-En; Mon, 06 Nov 2006 17:31:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD03-00048W-Gl for discuss@apps.ietf.org; Mon, 06 Nov 2006 17:31:27 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhD00-0006dH-C8 for discuss@apps.ietf.org; Mon, 06 Nov 2006 17:31:27 -0500 Received: from [130.129.71.122] (dhcp71-122.ietf67.org [130.129.71.122]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kA6MVUQd007367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Nov 2006 14:31:31 -0800 Message-ID: <454FB7B2.5090607@dcrocker.net> Date: Mon, 06 Nov 2006 14:31:14 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Randall Gellens wrote: >> So changing our model to focus on SRV has some interesting implications. > > The implications may depend on who is included in "our" (in "changing our > model"). A lot of application-level protocols already do, as you note, > depend on DNS. sorry for being fuzzy. i mean 'out model' as in 'our transport/ip' model, which currently does not rely on the DNS. I believe that re-targeting service selection to be in terms of SRV records changes this. (I'm not offering an opinion about whether to do this, but am merely noting the import -- and I am merely echoing what others have said before.) Ned Freed wrote: > I think you're talking past each other here. You're referring to our practice > of saying things like "SMTP servers listen on port 25 by default" or "HTTP > servers normally listen on port 80". Eliot is talking about ports with > numeric values less than 1024 being handled distinctly from those above 1024. I heard him make comments that seemed to clearly indicate that *some* infrastructure service almost certainly need to stay with port numbers. He cited examples. > I am complete agree with Eliot that the "below 1024 are special" notion's > time has long since past. I too heard the reference, but didn't hear any of the rest of his comments seeming to be related to the security function that the 1024 block was initially used for. So I decided the 1024-is-special reference was useful mostly as an introduction to the discussion rather than intended to be a technical focus on what followed. Might not be what Eliot meant, but it worked for me... > I certainly don't want to abandon the practice of defining ports associated > with specific services and I don't think Eliot is saying that either. Actually, I heard a suggestion that we move to using SRV *instead of reserved port numbers* as a long-term model. That the model might apply in some cases and not others (as per the infrastructure services point, above) seemed like an issue for further discussion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Mon Nov 06 17:33:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD1W-0004sn-6M; Mon, 06 Nov 2006 17:32:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD1U-0004sg-Es for discuss@apps.ietf.org; Mon, 06 Nov 2006 17:32:56 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhD1T-0006pX-38 for discuss@apps.ietf.org; Mon, 06 Nov 2006 17:32:56 -0500 Received: from [130.129.71.122] (dhcp71-122.ietf67.org [130.129.71.122]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kA6MWueO007719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Nov 2006 14:32:57 -0800 Message-ID: <454FB809.8060408@dcrocker.net> Date: Mon, 06 Nov 2006 14:32:41 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ned Freed Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> <01M98TPYN9MO00UHS2@mauve.mrochek.com> In-Reply-To: <01M98TPYN9MO00UHS2@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned Freed wrote: > ..., but I also think there's a point past which they'd be overused. Can you characterize that limit in some technical or administrative terms? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Mon Nov 06 18:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhE2A-0002hJ-0K; Mon, 06 Nov 2006 18:37:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhE28-0002gz-Q5 for discuss@apps.ietf.org; Mon, 06 Nov 2006 18:37:40 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhE25-0006s4-H2 for discuss@apps.ietf.org; Mon, 06 Nov 2006 18:37:40 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M98WGPV3CW00WNY8@mauve.mrochek.com> for discuss@apps.ietf.org; Mon, 6 Nov 2006 15:37:09 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M98REL25PC00UHS2@mauve.mrochek.com>; Mon, 06 Nov 2006 15:37:07 -0800 (PST) Message-id: <01M98WGORFJG00UHS2@mauve.mrochek.com> Date: Mon, 06 Nov 2006 14:50:42 -0800 (PST) From: Ned Freed Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) In-reply-to: "Your message dated Mon, 06 Nov 2006 14:32:41 -0800" <454FB809.8060408@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> <01M98TPYN9MO00UHS2@mauve.mrochek.com> <454FB809.8060408@dcrocker.net> To: Dave Crocker X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: discuss@apps.ietf.org, Ned Freed X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Ned Freed wrote: > > ..., but I also think there's a point past which they'd be overused. > Can you characterize that limit in some technical or administrative terms? I think Phillip's pro and con lists are a start at expressing the criteria for making a selection between the two mechanisms. There are some clear cases at the edges, e.g. services that run "below" DNS or which have real time response requirement cannot use SRV, and services that need lots of redundant servers with fallback and prioritization should use SRV instead of a bunch of A records. We specified use of SRV records in the MSGTRK work and it seems entirely appropriate to use them in that case. I don't have a candidate protocol currently being developed in mind where I'd like to see SRV records used, but sooner or later there will be one. Ned From discuss-bounces@apps.ietf.org Tue Nov 07 12:23:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUeR-0002Xe-6A; Tue, 07 Nov 2006 12:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCkr-0000dd-64 for discuss@apps.ietf.org; Mon, 06 Nov 2006 17:15:45 -0500 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCko-0003l8-Jb for discuss@apps.ietf.org; Mon, 06 Nov 2006 17:15:45 -0500 Received: from dhcp71-132.ietf67.org (dhcp71-132.ietf67.org [130.129.71.132]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id kA6MFRUW010588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Nov 2006 14:15:31 -0800 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com kA6MFRUW010588 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1162851332; bh=Xgl1k1R9v0e7hz14M1X6/84scj8=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=b2Z5ap+53OMb1bib j6y8FlQCZhiXKc+jBRSPMEqDdoEgJDz5OcQVuQpdhKLB7TfwtOMi6vwEp07nbjbOdkx mV2cEF4ItrvTzyRH+nDeNLo6ZDZ7UlTAe4BrxL7K4V46WJxiGwocCiZbus7oP22fg5K G2uizILOEtFvtxxvSUSoU= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com kA6MFRUW010588 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=r9jOBPtNFAi25dZ9Lrpe0Pyoj3pXzGEUmrxIZ0iwYqEhRNPN5iuABCj4j8QIfzdfk pFhWcwc+FIUIHy0i482Mechnhj/ZFQ7TeKtG3Txcs4X7RuOSIBJkmPOr9vHb1yg9UTw KNysoDBvCF0aipJx35YHpr/82MY+H3eJ7VPBd9w= Date: Mon, 6 Nov 2006 14:15:26 -0800 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Ned Freed Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) In-Reply-To: <01M98T13EPQG00UHS2@mauve.mrochek.com> Message-ID: References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-Mailman-Approved-At: Tue, 07 Nov 2006 12:22:17 -0500 Cc: discuss@apps.ietf.org, Dave Crocker X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 6 Nov 2006, Ned Freed wrote: >> This is in response to Eliot's presentation this morning, in the >> AppsArea and it is merely intended to solicit comment: > >> I have always understood the construct of Well-Known Ports as being a >> means of standardizing an efficient rendezvous mechanism, for clients >> to find servers. -- without quibbling about the terminology that might >> better cover use in peer-to-peer scenarios. > > I think you're talking past each other here. You're referring to our > practice of saying things like "SMTP servers listen on port 25 by > default" or "HTTP servers normally listen on port 80". Eliot is talking > about ports with numeric values less than 1024 being handled distinctly > from those above 1024. Elliot was talking about both in his presentation. The first bit was this whole thing involving ports 0 to 1023 (which the registry calls "Well Known Ports"). The second bit was the recommendation that new protocols should consider using SRV instead of having a particular port number. > I am complete agree with Eliot that the "below 1024 are special" > notion's time has long since past. It made sense back in the mainframe > era, but it was over the minute we started putting machines directly > under the control of random users. I agree. > I certainly don't want to abandon the practice of defining ports > associated with specific services and I don't think Eliot is saying that > either. He didn't suggest that, as it's impossible for protocols below DNS or that cannot afford to depend on DNS. > I wasn't entirely clear on what Eliot was trying to say about SRV records. > Perhaps someone could recap that here? SRV records good: - provides fallback/load-balance location mechanism - avoids tight port # binding - namespace of assignments is strings (that can be a DNS label) instead of 16bit numbers SRV records bad: - add dependency on DNS - add latency on first connect, maybe later - complexity Philip Guenther From discuss-bounces@apps.ietf.org Tue Nov 07 12:29:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUkV-0006WI-MZ; Tue, 07 Nov 2006 12:28:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUkU-0006Vb-9n for discuss@apps.ietf.org; Tue, 07 Nov 2006 12:28:34 -0500 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhUkR-0008FP-P9 for discuss@apps.ietf.org; Tue, 07 Nov 2006 12:28:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 6A0BD87C06 for ; Tue, 7 Nov 2006 18:28:14 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20702-01-3 for ; Tue, 7 Nov 2006 18:28:14 +0100 (CET) Received: from [130.129.67.92] (dhcp67-92.ietf67.org [130.129.67.92]) by tyholt.uninett.no (Postfix) with ESMTP id 835B387BFB for ; Tue, 7 Nov 2006 18:28:13 +0100 (CET) Message-ID: <45509AFC.6080103@uninett.no> Date: Tue, 07 Nov 2006 15:41:00 +0100 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Philip Guenther wrote: > On Mon, 6 Nov 2006, Ned Freed wrote: >> I wasn't entirely clear on what Eliot was trying to say about SRV >> records. >> Perhaps someone could recap that here? > > > SRV records good: > - provides fallback/load-balance location mechanism > - avoids tight port # binding > - namespace of assignments is strings (that can be a DNS label) instead > of 16bit numbers > > SRV records bad: > - add dependency on DNS > - add latency on first connect, maybe later > - complexity Another issue is that there is no standardised API (AFAIK) for retrieving SRV records. It would be good to have some standard API to make it easier to write portable applications using SRV. Not sure if IETF is the right place, but we have done things like getaddrinfo()... Stig > > > Philip Guenther > From discuss-bounces@apps.ietf.org Wed Nov 08 14:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtJE-0002TD-2Z; Wed, 08 Nov 2006 14:42:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtJC-0002QT-Lr for discuss@apps.ietf.org; Wed, 08 Nov 2006 14:42:02 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhtJB-0007IH-Ey for discuss@apps.ietf.org; Wed, 08 Nov 2006 14:42:02 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 418A12F22A; Wed, 8 Nov 2006 14:42:59 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2Hzf9zpMZ0W; Wed, 8 Nov 2006 14:42:53 -0500 (EST) Received: from [192.168.1.132] (c-68-48-208-49.hsd1.dc.comcast.net [68.48.208.49]) by ka.cs.utk.edu (Postfix) with ESMTP id 2A4052F22C; Wed, 8 Nov 2006 14:42:49 -0500 (EST) Message-ID: <455232FC.1010005@cs.utk.edu> Date: Wed, 08 Nov 2006 14:41:48 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> In-Reply-To: <454F8701.20302@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > So changing our model to focus on SRV has some interesting implications. for instance, SRV puts more fine-grained control in the hands of a DNS administrator - even in cases where the host owner and DNS admin aren't part of the same entity. (do you really want your ISP dictating which ports you run services on, or being able to vector traffic intended for your host to other hosts?) SRV slows down connection establishment. we already have a lot of overhead in DNS lookups (A + AAAA records and sometimes PTR records), TCP setup, SSL/TLS setup, etc. SRV has the potential to create problems if retroactively applied to existing apps as the behavior of a SRV-aware client will differ from that of a non-SRV-aware client. the design of getaddrinfo() is such that it could be used to do SRV lookup, but (if not done carefully) this would break that aren't defined to use SRV. From discuss-bounces@apps.ietf.org Wed Nov 08 14:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtMQ-0003BW-KW; Wed, 08 Nov 2006 14:45:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtMP-0003BR-Os for discuss@apps.ietf.org; Wed, 08 Nov 2006 14:45:21 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhtMO-0007Vb-6s for discuss@apps.ietf.org; Wed, 08 Nov 2006 14:45:21 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 3CAD52F21E; Wed, 8 Nov 2006 14:46:20 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB-8V89NA-OO; Wed, 8 Nov 2006 14:46:15 -0500 (EST) Received: from [192.168.1.132] (c-68-48-208-49.hsd1.dc.comcast.net [68.48.208.49]) by ka.cs.utk.edu (Postfix) with ESMTP id 1F9262F22A; Wed, 8 Nov 2006 14:46:01 -0500 (EST) Message-ID: <455233BC.1010200@cs.utk.edu> Date: Wed, 08 Nov 2006 14:45:00 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Dave Crocker Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> <454FB7B2.5090607@dcrocker.net> In-Reply-To: <454FB7B2.5090607@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > sorry for being fuzzy. i mean 'out model' as in 'our transport/ip' > model, which currently does not rely on the DNS. I believe that > re-targeting service selection to be in terms of SRV records changes > this. I think it moves us further down a slippery slope. DNS isn't nearly as robust as IP, and every additional DNS query not only slows things down but also decreases the reliability of the application. Keith From discuss-bounces@apps.ietf.org Wed Nov 08 15:40:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuD4-0003Cw-Mg; Wed, 08 Nov 2006 15:39:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuD2-0003Ck-SG for discuss@apps.ietf.org; Wed, 08 Nov 2006 15:39:44 -0500 Received: from tyholt.uninett.no ([158.38.62.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhuD0-0007Q8-My for discuss@apps.ietf.org; Wed, 08 Nov 2006 15:39:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id C6D8587BD3; Wed, 8 Nov 2006 21:34:30 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02982-01-54; Wed, 8 Nov 2006 21:34:30 +0100 (CET) Received: from [IPv6?2001?df8?0?64?213?2ff?fe0e?7215] (unknown [IPv6:2001:df8:0:64:213:2ff:fe0e:7215]) by tyholt.uninett.no (Postfix) with ESMTP id 7EF1887BD2; Wed, 8 Nov 2006 21:34:29 +0100 (CET) Message-ID: <4552133B.8030701@uninett.no> Date: Wed, 08 Nov 2006 18:26:19 +0100 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> <455232FC.1010005@cs.utk.edu> In-Reply-To: <455232FC.1010005@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: discuss@apps.ietf.org, dcrocker@bbiw.net X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore wrote: [...] > the design of getaddrinfo() is such that it could be used to do SRV > lookup, but (if not done carefully) this would break that aren't defined > to use SRV. > As I wrote earlier, I believe some standard API for SRV lookups is needed. getaddrinfo() would be okay for that, but one should probably add a new flag (e.g. AI_SRV), where apps specifically set this flag if they want to do SRV lookups. I would be happy to discuss a possible API if that is appropriate. I've personally written SRV lookup code for different platforms, and I think it's bad to require every application writer to go through this exercise. Stig From discuss-bounces@apps.ietf.org Wed Nov 08 16:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghuiv-0002YY-HI; Wed, 08 Nov 2006 16:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghuiu-0002Xu-79 for discuss@apps.ietf.org; Wed, 08 Nov 2006 16:12:40 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghuik-00022j-Eo for discuss@apps.ietf.org; Wed, 08 Nov 2006 16:12:40 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 327C756466; Wed, 8 Nov 2006 16:11:14 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTxkLJRzFGIP; Wed, 8 Nov 2006 16:11:05 -0500 (EST) Received: from [192.168.1.132] (c-68-48-208-49.hsd1.dc.comcast.net [68.48.208.49]) by shu.cs.utk.edu (Postfix) with ESMTP id 9B8B756492; Wed, 8 Nov 2006 16:11:04 -0500 (EST) Message-ID: <4552482A.20303@cs.utk.edu> Date: Wed, 08 Nov 2006 16:12:10 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Stig Venaas Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> <455232FC.1010005@cs.utk.edu> <4552133B.8030701@uninett.no> In-Reply-To: <4552133B.8030701@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: discuss@apps.ietf.org, dcrocker@bbiw.net X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org -------- Original Message -------- > Keith Moore wrote: > [...] >> the design of getaddrinfo() is such that it could be used to do SRV >> lookup, but (if not done carefully) this would break that aren't >> defined to use SRV. >> > > As I wrote earlier, I believe some standard API for SRV lookups is > needed. getaddrinfo() would be okay for that, but one should probably > add a new flag (e.g. AI_SRV), where apps specifically set this flag if > they want to do SRV lookups. I would be happy to discuss a possible > API if that is appropriate. > > I've personally written SRV lookup code for different platforms, and > I think it's bad to require every application writer to go through > this exercise. in general I think DNS APIs need a lot of work. one problem with getaddrinfo() is that it isn't specific to DNS - you don't know where it's getting its information. it might be DNS, it might be a hosts file, it might be LLMNR, it might be NIS, it might be something else. how can you write apps that perform reliably with such an interface? that, and getaddrinfo() is a pretty bizarre interface, and I've seen it fail in strange ways on various platforms because it encourages the caller to include irrelevant information in the call - for instance, there's really no reason to include the service name in a DNS lookup query _unless_ it's to do a SRV lookup. (why in the world we think it's a good idea to make a program depend on a function that maps one constant to another is beyond me. hard coding "smtp" is no better than hard coding "25". not that there's anything wrong with hard coding a constant that is a defined element of the protocol.) Keith From discuss-bounces@apps.ietf.org Wed Nov 08 20:35:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyoK-0001JA-68; Wed, 08 Nov 2006 20:34:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyoJ-0001J5-7P for discuss@apps.ietf.org; Wed, 08 Nov 2006 20:34:31 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhyoH-0007K6-VF for discuss@apps.ietf.org; Wed, 08 Nov 2006 20:34:31 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2006 17:34:30 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="350996928:sNHT46141020" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA91YTjs022309; Wed, 8 Nov 2006 17:34:29 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA91YSin014055; Wed, 8 Nov 2006 17:34:29 -0800 (PST) Received: from [130.129.69.48] (sjc-vpn5-475.cisco.com [10.21.89.219]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA91L7TD027685; Wed, 8 Nov 2006 17:21:09 -0800 Message-ID: <455285A8.5080109@cisco.com> Date: Wed, 08 Nov 2006 17:34:32 -0800 From: Eliot Lear User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Ned Freed Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> In-Reply-To: <01M98T13EPQG00UHS2@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=637; t=1163036069; x=1163900069; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20Service=20vs.=20Port=20vs.=20SRV=20(following=20Eliot's=20presen tation); X=v=3Dcisco.com=3B=20h=3DYwa7799AC8wRLwykKSeCVghivIA=3D; b=BfdQSndlA3tGIhWcHUHUpBU+axI2WSXXElpTA6cW5OLeWevFZpNbTRItxvhi6NHnPuisMVJZ t3SjibxvBpAOPpJhn2VAvmkKMzRXg+7/i2ypRLFwyjGledgYA9neXEpP; X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: discuss@apps.ietf.org, Dave Crocker X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned Freed wrote: >> So changing our model to focus on SRV has some interesting implications. > > I wasn't entirely clear on what Eliot was trying to say about SRV > records. > Perhaps someone could recap that here? I guess that someone should be me ;-) There are three goals of my draft: 1. Get rid of the notion that < 1024 is special; 2. Encourage documentation of port number usage; and 3. Have developers consider the use of SRV records. SRV records may be appropriate in some circumstances and not in others. For instance, I wouldn't recommend SRV records for an IGP or for BGP ;-) Eliot From discuss-bounces@apps.ietf.org Thu Nov 09 13:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEzp-00083M-Ed; Thu, 09 Nov 2006 13:51:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEzo-00083C-Ik for discuss@apps.ietf.org; Thu, 09 Nov 2006 13:51:28 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEzk-0005QL-AB for discuss@apps.ietf.org; Thu, 09 Nov 2006 13:51:28 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M9CTBJAGN400U24E@mauve.mrochek.com> for discuss@apps.ietf.org; Thu, 9 Nov 2006 10:50:38 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163098238; h=Date: From:Subject:MIME-version:Content-type; b=nQs22Va5tzWFICcboQ5d26duw x1wBiF8zkgj3umlIlrtE5TZcqKDdNy4A22Ax0BTcLUg7bdUB3Yp85A/y4K1bA== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M9CLSGH1WG00UHS2@mauve.mrochek.com>; Thu, 09 Nov 2006 10:50:07 -0800 (PST) Message-id: <01M9CTAWS6QY00UHS2@mauve.mrochek.com> Date: Thu, 09 Nov 2006 10:49:43 -0800 (PST) From: Ned Freed Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) In-reply-to: "Your message dated Wed, 08 Nov 2006 17:34:32 -0800" <455285A8.5080109@cisco.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> <455285A8.5080109@cisco.com> To: Eliot Lear X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: discuss@apps.ietf.org, Dave Crocker , Ned Freed X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Ned Freed wrote: > >> So changing our model to focus on SRV has some interesting implications. > > > > I wasn't entirely clear on what Eliot was trying to say about SRV > > records. > > Perhaps someone could recap that here? > I guess that someone should be me ;-) > There are three goals of my draft: > 1. Get rid of the notion that < 1024 is special; > 2. Encourage documentation of port number usage; and > 3. Have developers consider the use of SRV records. SRV records may > be appropriate in some circumstances and not in others. For > instance, I wouldn't recommend SRV records for an IGP or for BGP ;-) I fully support all of these goals. Ned From discuss-bounces@apps.ietf.org Thu Nov 09 14:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFIW-0003le-Bp; Thu, 09 Nov 2006 14:10:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFIU-0003lX-MB for discuss@apps.ietf.org; Thu, 09 Nov 2006 14:10:46 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiFIS-0008Eb-9n for discuss@apps.ietf.org; Thu, 09 Nov 2006 14:10:46 -0500 Received: from [130.129.67.56] (dhcp67-56.ietf67.org [130.129.67.56]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kA9JAn3W002600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Nov 2006 11:10:49 -0800 Message-ID: <45537D29.1080004@dcrocker.net> Date: Thu, 09 Nov 2006 11:10:33 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ned Freed Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> <455285A8.5080109@cisco.com> <01M9CTAWS6QY00UHS2@mauve.mrochek.com> In-Reply-To: <01M9CTAWS6QY00UHS2@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: discuss@apps.ietf.org, Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned Freed wrote: >> There are three goals of my draft: > >> 1. Get rid of the notion that < 1024 is special; >> 2. Encourage documentation of port number usage; and >> 3. Have developers consider the use of SRV records. SRV records may >> be appropriate in some circumstances and not in others. For >> instance, I wouldn't recommend SRV records for an IGP or for BGP > > I fully support all of these goals. +1 -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu Nov 09 18:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIwP-0000w2-S1; Thu, 09 Nov 2006 18:04:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIwO-0000vp-78 for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:04:12 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiIwM-0002CK-TW for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:04:12 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GiIwM-000GLN-6B; Thu, 09 Nov 2006 18:04:10 -0500 Date: Thu, 09 Nov 2006 18:04:08 -0500 From: John C Klensin To: Apps Discuss Subject: Escaping Unicode characters Message-ID: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi. In looking through protocols approved in the IETF or being worked on, we find two different methods of encoding/ escaping Unicode characters. One, used in URIs and the IRI->URI transition, among others, uses a %NN-style mechanism on a UTF-8 string. The other, used in DHCP and elsewhere, uses a \uNNNN-style mechanism to identify the Unicode character, rather than capturing its encoding. In most cases that we have kept protocols and protocol elements in ASCII, rather than going to some "binary" form (such as ASN.1), a significant part of our motivation was to keep things readable and understandable by people. If that is our intent, then the \uNNNN form, or its close relative, U+NNNN, are far preferable to %-forms on the UTF-8. \uNNNN can be easily looked up in tables; encoded UTF-8 requires either a computer program (however trivial) or some fussing around to decode, after which one needs to get to U+nnnn form to do the lookup. But, in any event, we are in need of some architectural guidance as to when to use which one -- arbitrary choices on a per-protocol basis do no one any good. john From discuss-bounces@apps.ietf.org Thu Nov 09 18:31:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJMA-00082P-6k; Thu, 09 Nov 2006 18:30:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJM8-00082C-PF for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:30:48 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJM5-0005ZW-Dc for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:30:48 -0500 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA9NUfqg027978 for ; Thu, 9 Nov 2006 16:30:41 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J8H00K01KXFEP00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Thu, 09 Nov 2006 16:30:41 -0700 (MST) Received: from dhcp71-109.ietf67.org (dhcp71-109.ietf67.org [130.129.71.109]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J8H00MI9LB2KN40@mail-amer.sun.com>; Thu, 09 Nov 2006 16:30:41 -0700 (MST) Date: Thu, 09 Nov 2006 15:33:56 -0800 From: Chris Newman Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) In-reply-to: <01M9CTAWS6QY00UHS2@mauve.mrochek.com> To: Ned Freed , Eliot Lear Message-id: <93E6A7D2324ED3CC8C86EF81@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <454F8701.20302@dcrocker.net> <01M98T13EPQG00UHS2@mauve.mrochek.com> <455285A8.5080109@cisco.com> <01M9CTAWS6QY00UHS2@mauve.mrochek.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: discuss@apps.ietf.org, Dave Crocker X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned Freed wrote on 11/9/06 10:49 -0800: >> Ned Freed wrote: >> >> So changing our model to focus on SRV has some interesting implications. >> > >> > I wasn't entirely clear on what Eliot was trying to say about SRV >> > records. >> > Perhaps someone could recap that here? >> I guess that someone should be me ;-) > >> There are three goals of my draft: > >> 1. Get rid of the notion that < 1024 is special; >> 2. Encourage documentation of port number usage; and >> 3. Have developers consider the use of SRV records. SRV records may >> be appropriate in some circumstances and not in others. For >> instance, I wouldn't recommend SRV records for an IGP or for BGP ;-) > > I fully support all of these goals. Port numbers < 1000 are special in that they have fewer characters and are simpler to remember. Reserving them for IETF standards track protocols is not necessarily a bad thing. But pretending < 1024 have any real security characteristics other than being inconvenient to implement on most Unix variants would be foolish. - Chris From discuss-bounces@apps.ietf.org Thu Nov 09 18:34:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJOe-00030D-Ot; Thu, 09 Nov 2006 18:33:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJOd-0002ts-DA for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:33:23 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJOc-0005q2-1k for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:33:23 -0500 Received: from [12.105.246.138] (dhcp66-169.ietf67.org [130.129.66.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9NXIif054696; Thu, 9 Nov 2006 16:33:20 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> Date: Thu, 9 Nov 2006 15:33:09 -0800 To: John C Klensin , Apps Discuss From: Paul Hoffman Subject: Re: Escaping Unicode characters Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 6:04 PM -0500 11/9/06, John C Klensin wrote: >Hi. > >In looking through protocols approved in the IETF or being worked >on, we find two different methods of encoding/ escaping Unicode >characters. One, used in URIs and the IRI->URI transition, among >others, uses a %NN-style mechanism on a UTF-8 string. The other, >used in DHCP and elsewhere, uses a \uNNNN-style mechanism to >identify the Unicode character, rather than capturing its encoding. > >In most cases that we have kept protocols and protocol elements in >ASCII, rather than going to some "binary" form (such as ASN.1), a >significant part of our motivation was to keep things readable and >understandable by people. If that is our intent, then the \uNNNN >form, or its close relative, U+NNNN, are far preferable to %-forms >on the UTF-8. \uNNNN can be easily looked up in tables; encoded >UTF-8 requires either a computer program (however trivial) or some >fussing around to decode, after which one needs to get to U+nnnn >form to do the lookup. > >But, in any event, we are in need of some architectural guidance as >to when to use which one -- arbitrary choices on a per-protocol >basis do no one any good. +1 to U+nnnn From discuss-bounces@apps.ietf.org Thu Nov 09 18:49:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJdZ-0002bk-Nc; Thu, 09 Nov 2006 18:48:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJdY-0002bZ-Eq for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:48:48 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJdV-0007Go-6E for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:48:48 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M9D3PCFIM800ZR5M@mauve.mrochek.com> for discuss@apps.ietf.org; Thu, 9 Nov 2006 15:48:06 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163116085; h=Date: From:Subject:MIME-version:Content-type; b=duzEE4z/UDaCBhMcyeA2UkNsa 4rsq4biyGLc2lCSjBg498mBhjnKB8c1a5oBF8X5kChRsHEPotP3OkFjk2iGEg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M9CZXGSHKG00UHS2@mauve.mrochek.com>; Thu, 09 Nov 2006 15:48:04 -0800 (PST) Message-id: <01M9D3PBQCKI00UHS2@mauve.mrochek.com> Date: Thu, 09 Nov 2006 15:47:55 -0800 (PST) From: Ned Freed Subject: Re: Escaping Unicode characters In-reply-to: "Your message dated Thu, 09 Nov 2006 15:33:09 -0800" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> To: Paul Hoffman X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Apps Discuss , iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > At 6:04 PM -0500 11/9/06, John C Klensin wrote: > >Hi. > > > >In looking through protocols approved in the IETF or being worked > >on, we find two different methods of encoding/ escaping Unicode > >characters. One, used in URIs and the IRI->URI transition, among > >others, uses a %NN-style mechanism on a UTF-8 string. The other, > >used in DHCP and elsewhere, uses a \uNNNN-style mechanism to > >identify the Unicode character, rather than capturing its encoding. > > > >In most cases that we have kept protocols and protocol elements in > >ASCII, rather than going to some "binary" form (such as ASN.1), a > >significant part of our motivation was to keep things readable and > >understandable by people. If that is our intent, then the \uNNNN > >form, or its close relative, U+NNNN, are far preferable to %-forms > >on the UTF-8. \uNNNN can be easily looked up in tables; encoded > >UTF-8 requires either a computer program (however trivial) or some > >fussing around to decode, after which one needs to get to U+nnnn > >form to do the lookup. > > > >But, in any event, we are in need of some architectural guidance as > >to when to use which one -- arbitrary choices on a per-protocol > >basis do no one any good. > +1 to U+nnnn +1 Ned From discuss-bounces@apps.ietf.org Thu Nov 09 18:56:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJkS-0002GR-Jb; Thu, 09 Nov 2006 18:55:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJkQ-0002Fn-If for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:55:54 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJk8-0008WO-NW for discuss@apps.ietf.org; Thu, 09 Nov 2006 18:55:54 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0417F14231A; Thu, 9 Nov 2006 15:55:32 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19441-09; Thu, 9 Nov 2006 15:55:30 -0800 (PST) Received: from [130.129.70.115] (dhcp70-115.ietf67.org [130.129.70.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 97012142319; Thu, 9 Nov 2006 15:55:30 -0800 (PST) In-Reply-To: <01M9D3PBQCKI00UHS2@mauve.mrochek.com> References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> <01M9D3PBQCKI00UHS2@mauve.mrochek.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <037D307E-8DA7-40C8-802C-42B090766F69@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Escaping Unicode characters Date: Thu, 9 Nov 2006 15:55:29 -0800 To: John C Klensin X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Apps Discuss , iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Sounds like a 1 page RFC to me... Lisa On Nov 9, 2006, at 3:47 PM, Ned Freed wrote: >> At 6:04 PM -0500 11/9/06, John C Klensin wrote: >> >> >But, in any event, we are in need of some architectural guidance as >> >to when to use which one -- arbitrary choices on a per-protocol >> >basis do no one any good. > >> +1 to U+nnnn > > +1 > > Ned > From discuss-bounces@apps.ietf.org Thu Nov 09 19:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJs6-00011N-KG; Thu, 09 Nov 2006 19:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJs5-00011D-De for discuss@apps.ietf.org; Thu, 09 Nov 2006 19:03:49 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiJrs-0001TN-E3 for discuss@apps.ietf.org; Thu, 09 Nov 2006 19:03:49 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1163117014!15562897!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 5879 invoked from network); 10 Nov 2006 00:03:34 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-7.tower-120.messagelabs.com with SMTP; 10 Nov 2006 00:03:34 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA9NuuOu025937 for ; Thu, 9 Nov 2006 18:56:56 -0500 (EST) Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA9NukjR025898 for ; Thu, 9 Nov 2006 18:56:50 -0500 (EST) Received: from [135.210.84.196] (unknown[135.210.84.196](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20061110000323gw100re3a0e> (Authid: tony); Fri, 10 Nov 2006 00:03:24 +0000 Message-ID: <4553C1CB.7050105@att.com> Date: Thu, 09 Nov 2006 19:03:23 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 CC: Apps Discuss Subject: Re: Escaping Unicode characters References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> <01M9D3PBQCKI00UHS2@mauve.mrochek.com> <037D307E-8DA7-40C8-802C-42B090766F69@osafoundation.org> In-Reply-To: <037D307E-8DA7-40C8-802C-42B090766F69@osafoundation.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org with 3 pages of boiler plate :-) Lisa Dusseault wrote: > Sounds like a 1 page RFC to me... From discuss-bounces@apps.ietf.org Thu Nov 09 19:12:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJzR-0005pX-1U; Thu, 09 Nov 2006 19:11:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJzQ-0005pJ-6S for discuss@apps.ietf.org; Thu, 09 Nov 2006 19:11:24 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJzO-0002pk-LL for discuss@apps.ietf.org; Thu, 09 Nov 2006 19:11:24 -0500 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAA0BMS7007013 for ; Thu, 9 Nov 2006 17:11:22 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J8H00401MESZR00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Thu, 09 Nov 2006 17:11:22 -0700 (MST) Received: from dhcp71-109.ietf67.org (dhcp71-109.ietf67.org [130.129.71.109]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J8H00AHCN6V0040@mail-amer.sun.com>; Thu, 09 Nov 2006 17:11:22 -0700 (MST) Date: Thu, 09 Nov 2006 16:14:37 -0800 From: Chris Newman Subject: Re: Escaping Unicode characters In-reply-to: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> To: John C Klensin , Apps Discuss Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Does the proposed more readable syntax have a model for characters outside Plane 0? U+NNNNNN? Regardless, I agree we should think about this issue and have guidance. - Chris John C Klensin wrote on 11/9/06 18:04 -0500: > Hi. > > In looking through protocols approved in the IETF or being worked on, we find > two different methods of encoding/ escaping Unicode characters. One, used in > URIs and the IRI->URI transition, among others, uses a %NN-style mechanism on > a UTF-8 string. The other, used in DHCP and elsewhere, uses a \uNNNN-style > mechanism to identify the Unicode character, rather than capturing its > encoding. > > In most cases that we have kept protocols and protocol elements in ASCII, > rather than going to some "binary" form (such as ASN.1), a significant part > of our motivation was to keep things readable and understandable by people. > If that is our intent, then the \uNNNN form, or its close relative, U+NNNN, > are far preferable to %-forms on the UTF-8. \uNNNN can be easily looked up > in tables; encoded UTF-8 requires either a computer program (however trivial) > or some fussing around to decode, after which one needs to get to U+nnnn form > to do the lookup. > > But, in any event, we are in need of some architectural guidance as to when > to use which one -- arbitrary choices on a per-protocol basis do no one any > good. > > john > > > From discuss-bounces@apps.ietf.org Thu Nov 09 20:42:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLOS-0002RQ-Qk; Thu, 09 Nov 2006 20:41:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLOR-0002RB-PQ for discuss@apps.ietf.org; Thu, 09 Nov 2006 20:41:19 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLOQ-0005nW-Ft for discuss@apps.ietf.org; Thu, 09 Nov 2006 20:41:19 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GiLOP-000HRs-UO; Thu, 09 Nov 2006 20:41:18 -0500 Date: Thu, 09 Nov 2006 20:41:16 -0500 From: John C Klensin To: Chris Newman , Apps Discuss Subject: Re: Escaping Unicode characters Message-ID: In-Reply-To: References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Thursday, November 09, 2006 16:14 -0800 Chris Newman wrote: > Does the proposed more readable syntax have a model for > characters outside Plane 0? > > U+NNNNNN? yes. and yes. And, yes, that is what is already specified in a few protocols. > Regardless, I agree we should think about this issue and have > guidance. thanks john From discuss-bounces@apps.ietf.org Thu Nov 09 20:44:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLQw-0003GS-Qh; Thu, 09 Nov 2006 20:43:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLQv-0003Ft-PS for discuss@apps.ietf.org; Thu, 09 Nov 2006 20:43:53 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLQu-00069O-Gn for discuss@apps.ietf.org; Thu, 09 Nov 2006 20:43:53 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GiLQt-000HSd-VY; Thu, 09 Nov 2006 20:43:52 -0500 Date: Thu, 09 Nov 2006 20:43:50 -0500 From: John C Klensin To: Lisa Dusseault Subject: Re: Escaping Unicode characters Message-ID: <7128879561DA49803FB2FA84@as-s2n.ietf67.org> In-Reply-To: <037D307E-8DA7-40C8-802C-42B090766F69@osafoundation.org> References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> <01M9D3PBQCKI00UHS2@mauve.mrochek.com> <037D307E-8DA7-40C8-802C-42B090766F69@osafoundation.org> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Apps Discuss , iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Thursday, November 09, 2006 15:55 -0800 Lisa Dusseault wrote: > Sounds like a 1 page RFC to me... If the responses continue in today's vein, I'll take the action to write it. thanks, john > On Nov 9, 2006, at 3:47 PM, Ned Freed wrote: > >>> At 6:04 PM -0500 11/9/06, John C Klensin wrote: >>> >>> > But, in any event, we are in need of some architectural >>> > guidance as to when to use which one -- arbitrary choices >>> > on a per-protocol basis do no one any good. >> >>> +1 to U+nnnn >> >> +1 >> >> Ned >> > From discuss-bounces@apps.ietf.org Fri Nov 10 01:11:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiPb3-0003Fp-2H; Fri, 10 Nov 2006 01:10:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiPb2-0003Ff-6F for discuss@apps.ietf.org; Fri, 10 Nov 2006 01:10:36 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiPaz-0004oE-9I for discuss@apps.ietf.org; Fri, 10 Nov 2006 01:10:36 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kAA6AG0M023293 for ; Fri, 10 Nov 2006 15:10:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 6f61_22b66aa6_7082_11db_88b3_0014221fa3c9; Fri, 10 Nov 2006 15:10:16 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56303) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 10 Nov 2006 15:09:47 +0900 Message-Id: <6.0.0.20.2.20061110134200.19e62140@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 10 Nov 2006 14:08:26 +0900 To: John C Klensin , Apps Discuss From: Martin Duerst Subject: Re: Escaping Unicode characters In-Reply-To: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 08:04 06/11/10, John C Klensin wrote: >Hi. > >In looking through protocols approved in the IETF or being worked on, we find two different methods of encoding/ escaping Unicode characters. One, used in URIs and the IRI->URI transition, among others, uses a %NN-style mechanism on a UTF-8 string. The other, used in DHCP and elsewhere, uses a \uNNNN-style mechanism to identify the Unicode character, rather than capturing its encoding. Hello John, others, In general, I agree with \uHHHH being better than %hh. The choice of UTF-8 based %hh in URIs/IRIs (I don't know of any other place it is used) was not because this is considered the a-priori best option, but because it was the best way to make sure we would be backwards-compatible. I strongly suggest everybody have a look at http://www.w3.org/TR/charmod/, and for the issue of escaping in particular http://www.w3.org/TR/charmod/#sec-Escaping. Of special importance, or maybe potentially controversial in an IETF context, in that section are C044 and C046 (http://www.w3.org/TR/charmod/#C044 and http://www.w3.org/TR/charmod/#C046). C044 says: Escape syntax SHOULD require either explicit end delimiters or a fixed number of characters in each character escape. Escape syntaxes where the end is determined by any character outside the set of characters admissible in the character escape itself SHOULD be avoided. Thus having \uHHHH (\u followed by four hex characters) and \Uhhhhhh (\U followed by six hex characters) is okay, but allowing \u followed by a variable number of characters (similar to e.g. what CSS does) is a bad idea. C046 says: Escaped characters SHOULD be acceptable wherever their unescaped forms are; this does not preclude that syntax-significant characters, when escaped, lose their significance in the syntax. In particular, if a character is acceptable in identifiers and comments, then its escaped form should also be acceptable. The main reason for this is that in XML, it doesn't work that way. You can write Dürst, but not or (well, the later is possible, but in there, 'ü' doesn't mean u-umlaut, it just means this sequence of characters. This means that when converting something from one encoding to another, you sometimes escape and sometimes have to fail, and you need to parse the content to know when to do what. For IETF protocols, that's maybe not that much of an issue, because you usually don't have identifiers with non-ASCII characters. But in case you do have that, and for comments, it's important. >In most cases that we have kept protocols and protocol elements in ASCII, rather than going to some "binary" form (such as ASN.1), a significant part of our motivation was to keep things readable and understandable by people. If that is our intent, then the \uNNNN form, or its close relative, U+NNNN, are far preferable to %-forms on the UTF-8. \uNNNN can be easily looked up in tables; encoded UTF-8 requires either a computer program (however trivial) or some fussing around to decode, after which one needs to get to U+nnnn form to do the lookup. Yes indeed. >But, in any event, we are in need of some architectural guidance as to when to use which one -- arbitrary choices on a per-protocol basis do no one any good. I think guidance would be a good thing. But I'm not sure a one-page (with three pages of boilerplate) RFC is the right thing. Not that this topic needs more space, but the problem is that if we write a one-page RFC on escaping, then a one-page RFC e.g. on private use codepoints, and so on, we will end up with an awfully long list of RFCs that poor spec writers have to go through and reed in order to do the right thing (or just only in order to find out that they are not affected). So at least in the long term, we should aim for longer documents cosolidating related topics. Also, while I think very much about character encoding is very fundamental and architectural, the choice between %hh and \uhhhh, while being important and being helped by guidance, is not at all something architectural. The way John has explained it, and the way I see it, it's mostly a usability issue for human users. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Fri Nov 10 02:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQOm-0004mT-JD; Fri, 10 Nov 2006 02:02:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQOl-0004m4-Jc for discuss@apps.ietf.org; Fri, 10 Nov 2006 02:01:59 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiQOh-0003j6-6I for discuss@apps.ietf.org; Fri, 10 Nov 2006 02:01:59 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id kAA71plM017608Fri, 10 Nov 2006 07:01:51 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1GiQOd-000OAb-00; Fri, 10 Nov 2006 07:01:51 +0000 Date: Fri, 10 Nov 2006 07:01:51 +0000 From: "Clive D.W. Feather" To: Ned Freed Subject: Re: Escaping Unicode characters Message-ID: <20061110070151.GD90180@finch-staff-1.thus.net> References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> <01M9D3PBQCKI00UHS2@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01M9D3PBQCKI00UHS2@mauve.mrochek.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Paul Hoffman , Apps Discuss , iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned Freed said: >>>In most cases that we have kept protocols and protocol elements in >>>ASCII, rather than going to some "binary" form (such as ASN.1), a >>>significant part of our motivation was to keep things readable and >>>understandable by people. If that is our intent, then the \uNNNN >>>form, or its close relative, U+NNNN, are far preferable to %-forms >>>on the UTF-8. \uNNNN can be easily looked up in tables; encoded >>>UTF-8 requires either a computer program (however trivial) or some >>>fussing around to decode, after which one needs to get to U+nnnn >>>form to do the lookup. >> +1 to U+nnnn > > +1 -1 What's the delimiter with U+NNNN? How do I distinguish that from those six characters in plain text? How many hex digits are expected? This sort of notation works in running text read by humans, but not machine-readable text. \u is at least a clear escape code, though it still has the length problem. ISO C and C++ use \uNNNN and \UNNNNNNNN, but I've never been that happy with the only distinction being case. Particularly where the next character is also a hex digit. Human readability of long strings of \uNNNN leaves something to be desired. It strikes me (and has struck me in the past in other contexts) that a notation that allows multiple characters to be included would be worthwhile. So how about: \u+(NNNN,NNNN,NNNNNNNN,NN) e.g. \u+(00C9,2144,1FF21,B7) (possibly using [] or {} or <> instead of () as delimiters)? This also leaves room for extensions such as: \u+('e acute') though I wouldn't want to require implementations to accept that. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Fri Nov 10 10:09:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXzG-0003Bh-IA; Fri, 10 Nov 2006 10:08:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXzF-0003Bc-Uf for discuss@apps.ietf.org; Fri, 10 Nov 2006 10:08:09 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiXzE-0000pC-Gm for discuss@apps.ietf.org; Fri, 10 Nov 2006 10:08:09 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GiXz9-000Mp2-GT; Fri, 10 Nov 2006 10:08:04 -0500 Date: Fri, 10 Nov 2006 10:07:58 -0500 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: Escaping Unicode characters Message-ID: <9C7FCBA5D53CD4C11671DA6E@as-s2n.ip3networks.com> In-Reply-To: <20061110070151.GD90180@finch-staff-1.thus.net> References: <4C485CB0A5C5EBC8F36D2EAB@as-s2n.ietf67.org> <01M9D3PBQCKI00UHS2@mauve.mrochek.com> <20061110070151.GD90180@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Apps Discuss , iab@iab.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, November 10, 2006 07:01 +0000 "Clive D.W. Feather" wrote: > What's the delimiter with U+NNNN? How do I distinguish that > from those six characters in plain text? How many hex digits > are expected? This sort of notation works in running text read > by humans, but not machine-readable text. > > \u is at least a clear escape code, though it still has the > length problem. ISO C and C++ use \uNNNN and \UNNNNNNNN, but > I've never been that happy with the only distinction being > case. Particularly where the next character is also a hex > digit. > > Human readability of long strings of \uNNNN leaves something > to be desired. It strikes me (and has struck me in the past in > other contexts) that a notation that allows multiple > characters to be included would be worthwhile. So how about: > > \u+(NNNN,NNNN,NNNNNNNN,NN) > > e.g. > > \u+(00C9,2144,1FF21,B7) > > (possibly using [] or {} or <> instead of () as delimiters)? > > This also leaves room for extensions such as: > > \u+('e acute') > > though I wouldn't want to require implementations to accept > that. Clive, I think there are really two questions here. I didn't separate them in my initial note because I didn't want to make it a lot longer and didn't really want to have this discussion until the first question was settled. Question 1: Do we want to prefer (a) Some escaped form of the UTF-8 string or (b) Some representation of the Unicode table location/ character number. And, if not universally, under which circumstances do we prefer which one? This question is really philosophical, even if not deeply architectural, and relates to general principles of protocol design (albeit not profound ones). Question 2: Given the answer to Question 1, what is the best syntax for presentation and input? This is a human interface question and is the one addressed in your note. I have opinions about it (like you, I prefer explicit starting and ending delimiters of some sort), but I don't think the question is even interesting until we arrive at an answer to Question 1. Please see Martin Duerst's note, with which I am in complete agreement, for more on this topic. john p.s. IAB: One of the reasons you were copied on this is that, while I expect to produce Lisa's 'One page' RFC, it will update RFC2277 which, in turn, was effectively an output of RFC2130. I increasingly believe that the issues addressed in 2130 --well over a decade ago in an area where I think we have learned a great deal, mostly the hard way-- need to be reopened and reviewed. From discuss-bounces@apps.ietf.org Mon Nov 13 20:32:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjn90-0003oU-0w; Mon, 13 Nov 2006 20:31:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjn8x-0003k5-R6 for discuss@apps.ietf.org; Mon, 13 Nov 2006 20:31:19 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjn8t-0004Kv-TR for discuss@apps.ietf.org; Mon, 13 Nov 2006 20:31:19 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3E09A14229D; Mon, 13 Nov 2006 17:31:11 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01973-06; Mon, 13 Nov 2006 17:31:08 -0800 (PST) Received: from [10.1.1.209] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F10D414229C; Mon, 13 Nov 2006 17:31:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <74A39CAD-D696-42DB-B864-77A16E73177B@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-4-477066802 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's IETF meeting week summary From: Lisa Dusseault Date: Mon, 13 Nov 2006 17:31:00 -0800 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-4-477066802 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This email is an overview of the activity in the meetings I attended last week at the 67th IETF in San Diego. To catch up more, there are many sources of information online: the minutes and presentations (which will be uploaded over the next month or two by the chairs), jabber logs which typically have the equivalent of complete minutes, and audio recordings. There's also the relevant mailing list for each WG, which often reprises the in-person discussion particularly after minutes are posted to the list. - https://datatracker.ietf.org/public/meeting_materials.cgi? meeting_num=67 - http://www3.ietf.org/meetings/ietf-logs/ - http://videolab.uoregon.edu/events/ietf/ App Area Open Meeting - Future of email work: Alexey summarized "Generation 3" of email work as currently going on in several email WGs. Harald filled in EAI pieces and Barry summarized DKIM status. Recommendations: Do cross-WG review, start implementing, think now if we're missing key pieces of the overall picture. - Presentations on ongoing work: IDNA (John Klensin), - Calls for participation/action: Registry for TV URIs (Iko Keesmat), ORCHIDs (Ted Hardie for Jari Arkko) -- ORCHIDs are about allocating some IPv6 address space for experiments. - How to do Application protocols without registering for ports under 1024 (Eliot Lear). CALSIFY and calendaring lunch - Plugging away on issues! Go CALSIFY - Expecting to publish new RFC2445-bis draft very shortly. SIEVE - Normal progress on SIEVE issues. - Agreed to drop REGEX draft from charter. - Brief discussion on how upgrading RFC2821 (SMTP) to Proposed Standard would be good, provided we can make do with very little explicit, new interoperability testing and reporting as we don't have volunteers for that. I'm following up to discuss with volunteers. WIDEX - Discussed possibility of closing WG, in order to have more flexibility to publish individual Experimental Drafts, and revisit possibility of standards track once we see some uptake. Lemonade - Presentation and discussion on notification, with many well- thought out issues about the overall problem and how disjoint the current piecework solutions are, from Ray Cromwell. - Saw consensus to take the Expunged draft (which I had agreed to shepherd as an individual submission) and roll it into the next version of draft-ietf-lemonade-reconnect-client. Thus, this work becomes a WG deliverable rather than something for me to shepherd as individual. Notifications lunch - Initiating plans to write a charter and propose a BoF scoped very carefully and solidly to put in the final missing pieces to allow email server events to be delivered to a wide variety of clients over existing transports (XMPP, SIP, mail and SMS or some subset). - Volunteer BoF cat-herders: Philip, Barry --> will create mail list and send announcements. EAI - Attended to try to keep up with fast-paced email work in this group. Various decisions made on how to represent i18n addresses. - Risk identified: how DKIM will fail to effectively sign email when it may have to be downgraded to be sent into non-i18n systems at some point in transit. Obviously the best place to sign email is after transformations such as downgrades, when that's possible. IMAPEXT - Realized that IMAPEXT i18n and SORT documents need one more piece before they can finish! The comparator registry was a pre-requisite, but so is a specific comparator that can work for searching within free-text fields that might contain accented characters or other glyphs that can be constructed more than one way in Unicode. Arnt to work on a new comparator for the new registry, like the "i-basic" comparator that was pulled from the original comparator doc. Plenaries, tutorials, IESG meetings - ICE Tutorial: http://www.jdrosen.net/papers/ice-ietf-tutorial.pdf -- great tutorial on how (and why) to do p2p NAT traversal for real- time applications. Overall ICE proposal pulls together several different RAI area technologies including STUN and TURN. - IAB Plenary: Network transparency talk, unwanted traffic workshop outcomes, and Routing workshop outcomes. Imminent death of the Internet predicted in several interesting ways. - IESG meetings: Discussed next steps in experiments in early external review -- outside-WG document review before WG last call See for Barry's notes on many of the same meetings. --Lisa --Apple-Mail-4-477066802 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

This email is an overview = of the activity in the meetings I attended last week at the 67th IETF in = San Diego.=A0 To catch up more, there are many sources of information = online: the minutes and presentations (which will be uploaded over the = next month or two by the chairs), jabber logs which typically have the = equivalent of complete minutes, and audio recordings.=A0 There's also = the relevant mailing list for each WG, which often reprises the = in-person discussion particularly after minutes are posted to the = list.

App Area Open = Meeting=A0
- Future of email work: Alexey = summarized "Generation 3" of email work as currently going on in several = email WGs.=A0 Harald filled in EAI pieces and Barry summarized DKIM = status.=A0=A0Recommendations: Do cross-WG review, start implementing, = think now if we're missing key pieces of the overall = picture.=A0=A0
- Presentations on ongoing work: = IDNA (John Klensin),=A0
- Calls for participation/action: = Registry for TV URIs (Iko Keesmat), ORCHIDs (Ted Hardie for Jari Arkko) = -- ORCHIDs are about allocating some IPv6 address space for = experiments.=A0
- How to do Application protocols = without registering for ports under 1024 (Eliot Lear).=A0

CALSIFY and calendaring = lunch
- Plugging away on issues!=A0 Go = CALSIFY
- Expecting to publish new = RFC2445-bis draft very shortly.

SIEVE
- Normal = progress on SIEVE issues.
- Agreed to drop REGEX draft from = charter.
- Brief discussion on how = upgrading RFC2821 (SMTP) to Proposed Standard would be good, provided we = can make do with very little explicit, new interoperability testing and = reporting as we don't have volunteers for that.=A0 I'm following up to = discuss with volunteers.

WIDEX
- = Discussed possibility of closing WG, in order to have more flexibility = to publish individual Experimental Drafts, and revisit possibility of = standards track once we see some uptake.

Lemonade=A0
- Presentation and discussion on = notification, with many well-thought out issues about the overall = problem and how disjoint the current piecework solutions are, from Ray = Cromwell.
- Saw consensus to take the = Expunged draft (which I had agreed to shepherd as an individual = submission) and roll it into the next version = of=A0draft-ietf-lemonade-reconnect-client.=A0 =A0Thus, this work becomes = a WG deliverable rather than something for me to shepherd as = individual.

Notifications = lunch
- Initiating plans to write a = charter and propose a BoF scoped very carefully and solidly to put in = the final missing pieces to allow email server events to be delivered to = a wide variety of clients over existing transports (XMPP, SIP, mail and = SMS or some subset).=A0
- Volunteer BoF cat-herders: = Philip, Barry --> will create mail list and send = announcements.

EAI
- = Attended to try to keep up with fast-paced email work in this group.=A0 = Various decisions made on how to represent i18n = addresses.=A0
- Risk identified: how DKIM will = fail to effectively sign email when it may have to be downgraded to be = sent into non-i18n systems at some point in transit.=A0 Obviously the = best place to sign email is after transformations such as downgrades, = when that's possible.=A0

IMAPEXT
- = Realized that IMAPEXT i18n and SORT documents need one more piece before = they can finish!=A0 The comparator registry was a pre-requisite, but so = is a specific comparator that can work for searching within free-text = fields that might contain accented characters or other glyphs that can = be constructed more than one way in Unicode.=A0 Arnt to work on a new = comparator for the new registry, like the "i-basic" comparator that was = pulled from the original comparator doc.

Plenaries, tutorials, = IESG meetings
-=A0ICE Tutorial:=A0http://www.jd= rosen.net/papers/ice-ietf-tutorial.pdf=A0 -- great tutorial on how = (and why) to do p2p NAT traversal for real-time applications.=A0 Overall = ICE proposal pulls together several different RAI area technologies = including STUN and TURN.
- IAB Plenary: Network = transparency talk, unwanted traffic workshop outcomes, and Routing = workshop outcomes.=A0 Imminent death of the Internet predicted in = several interesting ways.
- IESG meetings: Discussed next = steps in experiments in early external review -- outside-WG document = review before WG last call=A0

See <http://staringatemptypages.blogspot.com/2006/11/ietf-67-san-diego.ht= ml> for Barry's notes on many of the same meetings.

--Lisa
= --Apple-Mail-4-477066802-- From discuss-bounces@apps.ietf.org Thu Nov 16 11:12:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkjp0-0005RQ-Mz; Thu, 16 Nov 2006 11:10:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkjoz-0005R6-OU for discuss@apps.ietf.org; Thu, 16 Nov 2006 11:10:37 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkjoy-0008MH-EI for discuss@apps.ietf.org; Thu, 16 Nov 2006 11:10:37 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id A5BC1FDB0; Thu, 16 Nov 2006 11:10:35 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyxLA6Y+X1F5; Thu, 16 Nov 2006 11:10:20 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id D96B6FD8D; Thu, 16 Nov 2006 11:10:09 -0500 (EST) Message-ID: <455C8D6B.50705@cs.utk.edu> Date: Thu, 16 Nov 2006 11:10:19 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Simon Josefsson Subject: Re: Service vs. Port vs. SRV (following Eliot's presentation) References: <454F8701.20302@dcrocker.net> <455232FC.1010005@cs.utk.edu> <4552133B.8030701@uninett.no> <4552482A.20303@cs.utk.edu> <87fycjwfl8.fsf@latte.josefsson.org> In-Reply-To: <87fycjwfl8.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: discuss@apps.ietf.org, Stig Venaas , dcrocker@bbiw.net X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> that, and getaddrinfo() is a pretty bizarre interface, and I've seen >> it fail in strange ways on various platforms because it encourages the >> caller to include irrelevant information in the call - for instance, >> there's really no reason to include the service name in a DNS lookup >> query _unless_ it's to do a SRV lookup. (why in the world we think >> it's a good idea to make a program depend on a function that maps one >> constant to another is beyond me. hard coding "smtp" is no better >> than hard coding "25". not that there's anything wrong with hard >> coding a constant that is a defined element of the protocol.) > > Some implementations of getaddrinfo look up "smtp" from a local > database (i.e., /etc/services), so presumably it serves a purpose > without SRV's if someone which to change the port used for SMTP on a > system. Not in the case of SMTP, because 25 is a defined constant that is inherently part of the protocol. Even if you wanted to run SMTP over a port other than 25, it wouldn't change the fact that the way you send mail to domain foo (in the absence of explicit agreement) is to talk to port 25 on one of the MX servers for domain foo. You wouldn't want to change the definition of "smtp" to do that, you'd want to override use of port 25 for that specific case. For some reason there's a temptation to believe that somehow "smtp" is more meaningful than 25, that we should write our code in terms of a string constant that isn't part of the protocol we're implementing rather than in terms of a numeric constant that is carried on the wire. I think this comes from the practice of using symbolic constants when writing computer programs, where port = htons(SMTP); is more readable than port = htons(25); But it's a leap to assume that port = getsrvbyname ("smtp", "tcp"); or having getaddrinfo() do the lookup, are improvements over either of the above. the SMTP protocol is not likely to change, so there's no benefit and much to lose from the late binding. > However, I agree that we need better DNS API's. It would be nice to > have a standardized API to query for any DNS type in C. There are > various libraries out there (e.g., GNU adns, > ) but none that in my > experience that have been widely used. Other programming languages > seem better in this regard, alas -- e.g., there are good API's in > Perl. I'm not sure the IETF is the best place for that kind of work, > though.. It's hard to imagine a better place. DNS is an IETF protocol, and nobody understands DNS as well as IETF people. Keith