From nobody Tue Apr 1 09:43:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D171A088B for ; Tue, 1 Apr 2014 09:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.738 X-Spam-Level: X-Spam-Status: No, score=-99.738 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MdQzYNagMqs for ; Tue, 1 Apr 2014 09:43:43 -0700 (PDT) Received: from mail.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0D67E1A0564 for ; Tue, 1 Apr 2014 09:43:42 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5619; t=1396370615; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=yyqm4jp9HllwncQ978d3rLiofWg=; b=wNhYxJmlSc/fHF1FxIGu d8UcsqJXakKKgdCCMnyea6bicmiMcSJOFmqvQEFPbhaB1i8lVs9o2o4EqhhXHoZc fJT7Zg33ukLWF0uMCJYnZTbYnEP+evnMk3WzWyEzC17OxGeCJaARPZ1ej8ntfdgZ JHAOFBElpBsJsJIUS3IKs90= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 01 Apr 2014 11:43:35 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1358074435.14532.4120; Tue, 01 Apr 2014 11:43:34 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5619; t=1396370574; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XY9RGbR w55LUAIyVkNayTiiV9ufbq+1vUs+A/4NF1Jo=; b=M/94NMlqddX8V+vY9yWWyWi NtpOEybDB5NwLiL/RHZxn7mUCViz7M1xpdHOHoHDNWyc43TMFGwGo7KSvQz8Jt7D clJWILhPexPfqGlnnTqmC1kP3LV4WYJA7qikcwrOay96oXtp+LJ3WB8P2mfviRzf jSUD2sVvYmNotdEjAGYs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 01 Apr 2014 12:42:54 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 804330194.9.15176; Tue, 01 Apr 2014 12:42:53 -0400 Message-ID: <533AECB7.6080505@isdg.net> Date: Tue, 01 Apr 2014 12:43:35 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Barry Leiba References: <20140330033009.4839.qmail@joyce.lan> <5337998C.3080403@dcrocker.net> <53388D3C.7090105@dcrocker.net> <533893C3.1070903@dcrocker.net> <533897F3.5050005@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cYmj_xJ7bURLCaLnIl-Tz2RKyns Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 16:43:46 -0000 If I may add some points...... I don't think it it a good idea to inject a S/MIME complexity into this solution. I don't see how it can help the adoption of either. But the fact it is being considered supports my feeling this is still all an experimental concept. IMO, Yahoo made an critical, strategic operational decision to begin to expire old accounts a lot quicker than perhaps in the past. While it is an old issue for many hosting systems with their maintenance tools of user accounts, just because YAHOO is cracking open this door doesn't mean the potential millions of public and private hosting sites, especially private businesses are going to buy into the idea of its suddenly OK to begin reusing old email addresses. Just because YAHOO has decided to accelerate expirations and begin making email addresses a premium item to own, doesn't remove the idea its a very risky proposition for a much more wider set of operations. I believe there needs to be a more solid client/server protocol negotiated understanding of its main purposes and limits. I believe it hasn't been all worked out and the development investment into this can be costly and foremost wasteful. We are talking changes at all components of a complete mail system: Receiver Router Gateways Senders The draft needs to be more clear on its purpose. It shouldn't be open-ended. In the abstract it says: The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications. That last stated open ended potential purpose should be removed or the whole statement should be written to be more specific towards SMTP outcomes; positive/negative determination of an (RCPT) user account acceptability at a mail hosting domain. The communication is done via SMTP reply codes. This means that it can done at the SMTP RCPT and/or DATA state machine points. IOW, it should not be delayed (accept and then processed afterwards, routed and/or bounced. But whether its an SMTP command extension or payload header solution, delayed or otherwise at the backend, it MUST be a single consistent functional logic. The header solution is a time shifted, time delayed method that could be complex in its queuing, meta data framework and exposed to additional pervasive monitoring/security related concerns. Nonetheless, there could not be any difference in overall logic otherwise we have a potential security loophole. Related to the security, it makes me wonder how well its going to go at LC. After all these security and privacy discussions, the recent related I-Ds and RFC work, we are considering something that seems to thumb its nose at those concerns. Thanks -- HLS On 3/31/2014 6:56 PM, Barry Leiba wrote: >>> Could you do me a big favor and stop attempting to rephrase what I said? >>> You're not very good at it. > ... >> Also, I didn't "rephrase" what you said. I offered an assessment of it. >> The difference is fundamental. > > I find this discussion between the two of you tr�s bizarre, because > you're working against each other, when what John brought up seems to > support what Dave wants. > > Here, let me try to bring it around to a resolution of a significant issue: > > What started this was a contention that the SMTP extension is "better" > (latitude here, for the moment) than the header field. No one really > disputes that. And then, that because it's better, the two should be > defined separately, with the extension set up as Standards Track, and > the header field not. That's where the dispute is. > > One basis for the dispute is that the extension is not *sufficiently* > better to make a real difference: neither is a guarantee, so does it > really matter whether we have a very loose non-guarantee, or a > somewhat, but not completely better non-guarantee? Senders might be > willing to get failures bounced, but are senders really willing to get > non-support bounced? If they try, it's likely that people will sign > up with their banks and *never* get any transactional mail because > they happen to be on a mail system that doesn't support the RRVS > extension. > > So John points out something that's worth discussing in the document, > and that might address Pete's concerns: The guaranteed way to do this > is with S/MIME mail encrypted to the recipient's key. No intermediary > support is needed for this -- it's only that the recipient's email > system has to support S/MIME (not a huge problem today, though I'll > note that Gmail doesn't), and that the recipient has to have certs set > up (Oy!). > > I still think it's better to split out the header-field version and > make it Informational. But the argument above makes it less of an > issue. Perhaps the RRVS document should have a section that talks > about the advantages of the extension over the header field, the > realities of the header field over the extension, and the real > security limitations of both. Perhaps that section should say that if > guarantees are needed, neither of these does it, and senders should > consider S/MIME. But if a "do your best" request suffices, these > mechanism are useful. > > We could now ask what Pete would think about that. > > Barry > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- HLS From nobody Tue Apr 1 10:33:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4A91A09AE; Tue, 1 Apr 2014 10:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XNl-yJfrM8c; Tue, 1 Apr 2014 10:33:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 749BB1A0895; Tue, 1 Apr 2014 10:33:16 -0700 (PDT) Received: from DM2PR03MB414.namprd03.prod.outlook.com (10.141.84.145) by DM2PR03MB415.namprd03.prod.outlook.com (10.141.84.146) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 1 Apr 2014 17:33:11 +0000 Received: from DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) by DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) with mapi id 15.00.0898.005; Tue, 1 Apr 2014 17:33:12 +0000 From: Dave Thaler To: Alexey Melnikov Thread-Topic: [Uri-review] Registration request for smtp:// and submit:// URI schemes (draft-melnikov-smime-msa-to-mda-04) Thread-Index: AQHPTYXcWMrRJiaW+EOqSpXNNPtHTZr9BNyg Date: Tue, 1 Apr 2014 17:33:11 +0000 Message-ID: <63b3c4fad07742529b5ac4dfc0a0f306@DM2PR03MB414.namprd03.prod.outlook.com> References: <5336F686.7060308@isode.com> <451cd52e77fb4baf9f736e063eb872ad@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-forefront-prvs: 016885DD9B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(24454002)(51704005)(4396001)(47736001)(49866001)(46102001)(95666003)(98676001)(83072002)(74706001)(81342001)(87936001)(74502001)(74876001)(50986001)(56816005)(99286001)(74366001)(95416001)(81816001)(86362001)(65816001)(93516002)(81542001)(81686001)(97186001)(74316001)(63696002)(74662001)(93136001)(56776001)(54316002)(33646001)(54356001)(51856001)(87266001)(90146001)(59766001)(79102001)(76796001)(53806001)(86612001)(69226001)(47976001)(76576001)(2656002)(85306002)(77982001)(76786001)(47446002)(31966008)(97336001)(20776003)(80022001)(83322001)(94316002)(80976001)(92566001)(85852003)(94946001)(76482001)(99396002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR03MB415; H:DM2PR03MB414.namprd03.prod.outlook.com; FPR:9286CB24.86B754C9.31EF91BF.44EDAD73.201EC; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/h41xWfWwOaLWE5BvkqLMAC9Xtco Cc: "uri-review@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] Registration request for smtp:// and submit:// URI schemes (draft-melnikov-smime-msa-to-mda-04) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 17:33:18 -0000 Alexey Melnikov wrote: > > My feedback is that the name "submit" is not a good name for the propos= ed > use. > > Specifically, RFC 4395 states: > >> Avoid using names that are either very general purpose or associated > >> in the community with some other application or protocol. > > > > There are many types of things you can "submit" (HTTP forms, etc.) and > > since the proposed use here is specific to specific to SMTP, it should > > not use a general purpose word like "submit" along. > > > > "smtpsubmit" or similar would be much more appropriate. >=20 > I would rather use the same label as used by DNS SRV for the same service= : > "submission". (I think keeping them different would be a bad thing.). Tho= ughts? I didn't know about the SRV service type before this, but yes that sounds l= ike a reasonable goal. =20 I'm thinking it would be good to add a sentence about this case (service names and URI scheme names SHOULD be the same, when there exists a 1:1 correspondence) to draft-ietf-appsawg-uri-scheme-reg. Does that sound reasonable? -Dave From nobody Tue Apr 1 11:08:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DED1A09C6 for ; Tue, 1 Apr 2014 11:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUIjckAPOPSA for ; Tue, 1 Apr 2014 11:08:24 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id 074DD1A09BA for ; Tue, 1 Apr 2014 11:08:23 -0700 (PDT) Received: from BF1-EX10-CAHT04.y.corp.yahoo.com (bf1-ex10-caht04.corp.bf1.yahoo.com [10.74.209.59]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s31I7ngC032829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Apr 2014 11:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1396375670; bh=Ej5HiVf5Kf/CrgnJcgrz0MFG2txJC+4BylsSywJ+sJM=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=EEhKz3/UPKWyefiwTG+TV5tUrGwJwgemoH9FPGNA6nRSEIQH0Do4f0Z4WYupQuGJK Mgq3X5gdQDdfNrYuj1QH0JTpyWU3v8MMbktDdFCsr3z02cc5R0L/9CKRMmpMmrmdAu AsoVV+c+H6NvfT/mGSherZdeuMSW21ucPVuYAUIc= Received: from omp1023.mail.ne1.yahoo.com (98.138.89.167) by BF1-EX10-CAHT04.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 1 Apr 2014 14:07:48 -0400 Received: (qmail 86970 invoked by uid 1000); 1 Apr 2014 18:07:47 -0000 Received: (qmail 15534 invoked by uid 60001); 1 Apr 2014 18:07:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1396375667; bh=xWzSmkVFpTtNTe+0+X8VSpR6TbCMee36VcKHE0CcoFo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Zoyl7pzjCnhkajmZq6k59lNTBXAJn2uet7VfkthN9b5+nRhvJzB5jAV9pw0SJuNqZpWW1ai6Xr2ySAbJNujtrNLXvGTwuVClxaqEn9M3t57+Hxb1iRndOb3z6eJMPMLDX2CL1ETbgeCvkASfCODvZxHQBLxUPk175jeYcLTeZhQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GCWeUoDYJoR2ae02kWuSxA9u3h+I7uavDJAidzPfjnMzAgDvWg0UYQri2t6eLWxaDUqG6E5gopEMoE66djIcy+JRpm12iEXXjVENFusyiYqI5UsQvj3eGh1ZjuXuvqJdMU3GMISMOcrxqu8klXpfb1zdB/mm5tWpyqiOIcVBJtI=; X-YMail-OSG: ke_tt9QVM1lpue.PEeMAyObIfqi3nFcLW78Pw3UdzYPWyqj xpjL2xdTwxQ1ok6ctYgtJyFcDMY.VN6YX_biFEAT3dhqqiQWgnZ7iflsA_YM v5kOUjUFRSyyiPYNAkKgR5o2.CiOuhClrsjhixORfxNzufX0fVAAzrqQyvzK TUuriQt_58i_eS6Zv3Ky5qpOOFmJ_JfS5W1HQkEjSsdkUysx7uGDjL.pWK_w euDql3SKwLfxNtFvpsJJ24FqhQM1LUu709SUIHKXPaV1V5bfrL_ewDthNJfW uZZRSKCiKcctonTMVIepHPcdw Received: from [66.228.162.56] by web125603.mail.ne1.yahoo.com via HTTP; Tue, 01 Apr 2014 11:07:47 PDT X-Rocket-MIMEInfo: 002.001, WWFob28gYW5kIG90aGVycyBoYXZlIGJlZW4gcmVjeWNsaW5nIGFjY291bnRzIGluIHZvbHVtZSBmb3IgbWFueSBtYW55IHllYXJzLCB0aGlzIGlzbid0IG5ldy7CoCAKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBNVVggWWFob28hCgoKCgoKT24gVHVlc2RheSwgQXByaWwgMSwgMjAxNCA5OjQ0IEFNLCBIZWN0b3IgU2FudG9zIDxoc2FudG9zQGlzZGcubmV0PiB3cm90ZToKIApJZiBJIG1heSBhZGQgc29tZSBwb2ludHMuLi4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <20140330033009.4839.qmail@joyce.lan> <5337998C.3080403@dcrocker.net> <53388D3C.7090105@dcrocker.net> <533893C3.1070903@dcrocker.net> <533897F3.5050005@dcrocker.net> <533AECB7.6080505@isdg.net> Message-ID: <1396375667.93541.YahooMailNeo@web125603.mail.ne1.yahoo.com> Date: Tue, 1 Apr 2014 11:07:47 -0700 From: Bill Mills To: Hector Santos , Barry Leiba In-Reply-To: <533AECB7.6080505@isdg.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="933233344-256298943-1396375667=:93541" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 375670005 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3Phey3tlKC1L-di3HvqTT6DUGRc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 18:08:28 -0000 --933233344-256298943-1396375667=:93541 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yahoo and others have been recycling accounts in volume for many many years= , this isn't new.=C2=A0 =0A=0A=C2=A0=0A-bill=0A=0A=0A=0A-------------------= -------------=0AWilliam J. Mills=0A"Paranoid" MUX Yahoo!=0A=0A=0A=0A=0A=0AO= n Tuesday, April 1, 2014 9:44 AM, Hector Santos wrote:= =0A =0AIf I may add some points......=0A=0AI don't think it it a good idea = to inject a S/MIME complexity into =0Athis solution. I don't see how it can= help the adoption of either. =0ABut the fact it is being considered suppor= ts my feeling this is still =0Aall an experimental concept.=0A=0AIMO, Yahoo= made an critical, strategic operational decision to begin =0Ato expire old= accounts a lot quicker than perhaps in the past.=C2=A0 While =0Ait is an o= ld issue for many hosting systems with their maintenance =0Atools of user a= ccounts, just because YAHOO is cracking open this door =0Adoesn't mean the = potential millions of public and private hosting =0Asites, especially priva= te businesses are going to buy into the idea of =0Aits suddenly OK to begin= reusing old email addresses. Just because =0AYAHOO has decided to accelera= te expirations and begin making email =0Aaddresses a premium item to own, d= oesn't remove the idea its a very =0Arisky proposition for a much more wide= r set of operations. I believe =0Athere needs to be a more solid client/ser= ver protocol negotiated =0Aunderstanding of its main purposes and limits.= =C2=A0 I believe it hasn't =0Abeen all worked out and the development inves= tment into this can be =0Acostly and foremost wasteful.=C2=A0 We are talkin= g changes at all =0Acomponents of a complete mail system:=0A=0A=C2=A0 =C2= =A0 Receiver=0A=C2=A0 =C2=A0 Router=0A=C2=A0 =C2=A0 Gateways=0A=C2=A0 =C2= =A0 Senders=0A=0AThe draft needs to be more clear on its purpose. It should= n't be =0Aopen-ended.=C2=A0 In the abstract it says:=0A=0A=C2=A0 =C2=A0 The= intended use of these facilities is on automatically generated=0A=C2=A0 = =C2=A0 messages, such as account statements or password change instructions= ,=0A=C2=A0 =C2=A0 that might contain sensitive information, though it may a= lso be=0A=C2=A0 =C2=A0 useful in other applications.=0A=0AThat last stated = open ended potential purpose should be removed or the =0Awhole statement sh= ould be written to be more specific towards SMTP =0Aoutcomes; positive/nega= tive determination of an (RCPT) user account =0Aacceptability at a mail hos= ting domain.=C2=A0 The communication is done via =0ASMTP reply codes.=C2=A0= This means that it can done at the SMTP=C2=A0 RCPT =0Aand/or DATA state ma= chine points. IOW, it should not be delayed =0A(accept and then processed a= fterwards, routed and/or bounced.=0A=0A=0ABut whether its an SMTP command e= xtension or payload header solution, =0Adelayed or otherwise at the backend= , it MUST be a single consistent =0Afunctional logic.=C2=A0 The header solu= tion is a time shifted, time delayed =0Amethod that could be complex in its= queuing, meta data framework and =0Aexposed to additional pervasive monito= ring/security related concerns. =0ANonetheless, there could not be any diff= erence in overall logic =0Aotherwise we have a potential security loophole.= =0A=0ARelated to the security, it makes me wonder how well its going to go = =0Aat LC.=C2=A0 After all these security and privacy discussions, the recen= t =0Arelated I-Ds and RFC work,=C2=A0 we are considering something that see= ms to =0Athumb its nose at those concerns.=0A=0AThanks=0A=0A--=0AHLS=0A=0A= =0A=0AOn 3/31/2014 6:56 PM, Barry Leiba wrote:=0A>>> Could you do me a big = favor and stop attempting to rephrase what I said?=0A>>> You're not very go= od at it.=0A> ...=0A>> Also, I didn't "rephrase" what you said.=C2=A0 I off= ered an assessment of it.=0A>> The difference is fundamental.=0A>=0A> I fin= d this discussion between the two of you tr=EF=BF=BDs bizarre, because=0A> = you're working against each other, when what John brought up seems to=0A> s= upport what Dave wants.=0A>=0A> Here, let me try to bring it around to a re= solution of a significant issue:=0A>=0A> What started this was a contention= that the SMTP extension is "better"=0A> (latitude here, for the moment) th= an the header field.=C2=A0 No one really=0A> disputes that.=C2=A0 And then,= that because it's better, the two should be=0A> defined separately, with t= he extension set up as Standards Track, and=0A> the header field not.=C2=A0= That's where the dispute is.=0A>=0A> One basis for the dispute is that the= extension is not *sufficiently*=0A> better to make a real difference: neit= her is a guarantee, so does it=0A> really matter whether we have a very loo= se non-guarantee, or a=0A> somewhat, but not completely better non-guarante= e?=C2=A0 Senders might be=0A> willing to get failures bounced, but are send= ers really willing to get=0A> non-support bounced?=C2=A0 If they try, it's = likely that people will sign=0A> up with their banks and *never* get any tr= ansactional mail because=0A> they happen to be on a mail system that doesn'= t support the RRVS=0A> extension.=0A>=0A> So John points out something that= 's worth discussing in the document,=0A> and that might address Pete's conc= erns:=C2=A0 The guaranteed way to do this=0A> is with S/MIME mail encrypted= to the recipient's key.=C2=A0 No intermediary=0A> support is needed for th= is -- it's only that the recipient's email=0A> system has to support S/MIME= (not a huge problem today, though I'll=0A> note that Gmail doesn't), and t= hat the recipient has to have certs set=0A> up (Oy!).=0A>=0A> I still think= it's better to split out the header-field version and=0A> make it Informat= ional.=C2=A0 But the argument above makes it less of an=0A> issue.=C2=A0 Pe= rhaps the RRVS document should have a section that talks=0A> about the adva= ntages of the extension over the header field, the=0A> realities of the hea= der field over the extension, and the real=0A> security limitations of both= .=C2=A0 Perhaps that section should say that if=0A> guarantees are needed, = neither of these does it, and senders should=0A> consider S/MIME.=C2=A0 But= if a "do your best" request suffices, these=0A> mechanism are useful.=0A>= =0A> We could now ask what Pete would think about that.=0A>=0A> Barry=0A>= =0A> _______________________________________________=0A> apps-discuss maili= ng list=0A> apps-discuss@ietf.org=0A> https://www.ietf.org/mailman/listinfo= /apps-discuss=0A>=0A>=0A=0A-- =0AHLS=0A=0A=0A=0A___________________________= ____________________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0A= https://www.ietf.org/mailman/listinfo/apps-discuss --933233344-256298943-1396375667=:93541 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Yahoo and= others have been recycling accounts in volume for many many years, this is= n't new. 
 
-bill


---------------= -----------------
William J. Mills
"Paranoid" MUX Yahoo!


On Tuesday, April 1, 2014 = 9:44 AM, Hector Santos <hsantos@isdg.net> wrote:
=
If I may add some points......

I don't think it it a good idea to inject a S/MIME comp= lexity into
this solution. I don't see how it can help t= he adoption of either.
But the fact it is being consider= ed supports my feeling this is still
all an experimental= concept.

IMO, Yahoo made an critical,= strategic operational decision to begin
to expire old a= ccounts a lot quicker than perhaps in the past.  While
it is an old issue for many hosting systems with their maintenance
tools of user accounts, just because YAHOO is cracking open = this door
doesn't mean the potential millions of public = and private hosting
sites, especially private businesses= are going to buy into the idea of
its suddenly OK to be= gin reusing old email addresses. Just because
YAHOO has decided to accelerate= expirations and begin making email
addresses a premium = item to own, doesn't remove the idea its a very
risky pr= oposition for a much more wider set of operations. I believe
there needs to be a more solid client/server protocol negotiated
understanding of its main purposes and limits.  I believ= e it hasn't
been all worked out and the development inve= stment into this can be
costly and foremost wasteful.&nb= sp; We are talking changes at all
components of a comple= te mail system:

    Receiver=
    Router
    Gat= eways
    Senders

The draft needs to be more clear on its purpose. It shouldn't be =
open-ended.  In the abstract it says:

    The intended use of these facilities is = on automatically generated
    messages, such a= s account statements or password change instructions,
&nb= sp;   that might contain sensitive information, though it may also be<= br clear=3D"none">    useful in other applications.

That last stated open ended potential purpose shoul= d be removed or the
whole statement should be written to= be more specific towards SMTP
outcomes; positive/negati= ve determination of an (RCPT) user account
acceptability= at a mail hosting domain.  The communication is done via
SMTP reply codes.  This means that it can done at the SMTP = ; RCPT
and/or DATA state machine points. IOW, it should = not be delayed
(accept and then processed afterwards, routed and/or bounce= d.


But whether its = an SMTP command extension or payload header solution,
de= layed or otherwise at the backend, it MUST be a single consistent
functional logic.  The header solution is a time shifted, ti= me delayed
method that could be complex in its queuing, = meta data framework and
exposed to additional pervasive = monitoring/security related concerns.
Nonetheless, there= could not be any difference in overall logic
otherwise = we have a potential security loophole.

Related to the security, it makes me wonder how well its going to go
at LC.  After all these security and privacy discussions= , the recent
related I-Ds and RFC work,  we are con= sidering something that seems to
thumb its nose at those concerns.

Thanks

-= -
HLS



On 3/31/2014 6:56 PM, Barry Leiba wrote:
>>> Could you do me a big favor and stop attempting to r= ephrase what I said?
>>> You're not very good at= it.
> ...
>> Also, I didn't "= rephrase" what you said.  I offered an assessment of it.
>> The difference is fundamental.
>
> I find this discussion between the two of you tr=EF=BF=BDs = bizarre, because
> you're working against each other, = when what John brought up seems to
> support what Dave= wants.
>
> Here, let me try to b= ring it around to a resolution of a significant issue:
>
> What star= ted this was a contention that the SMTP extension is "better"
> (latitude here, for the moment) than the header field.  No o= ne really
> disputes that.  And then, that becaus= e it's better, the two should be
> defined separately,= with the extension set up as Standards Track, and
> t= he header field not.  That's where the dispute is.
&= gt;
> One basis for the dispute is that the extension = is not *sufficiently*
> better to make a real differen= ce: neither is a guarantee, so does it
> really matter= whether we have a very loose non-guarantee, or a
> so= mewhat, but not completely better non-guarantee?  Senders might be
> willing to get failures bounced, but are senders really= willing to get
> non-support bounced?  If they try, it's li= kely that people will sign
> up with their banks and *= never* get any transactional mail because
> they happe= n to be on a mail system that doesn't support the RRVS
&g= t; extension.
>
> So John points = out something that's worth discussing in the document,
&g= t; and that might address Pete's concerns:  The guaranteed way to do t= his
> is with S/MIME mail encrypted to the recipient's= key.  No intermediary
> support is needed for th= is -- it's only that the recipient's email
> system ha= s to support S/MIME (not a huge problem today, though I'll
> note that Gmail doesn't), and that the recipient has to have certs s= et
> up (Oy!).
>
> I still think it's better to split out the header-field version and
&g= t; make it Informational.  But the argument above makes it less of an<= br clear=3D"none">> issue.  Perhaps the RRVS document should have a= section that talks
> about the advantages of the exte= nsion over the header field, the
> realities of the he= ader field over the extension, and the real
> security= limitations of both.  Perhaps that section should say that if
> guarantees are needed, neither of these does it, and sender= s should
> consider S/MIME.  But if a "do your be= st" request suffices, these
> mechanism are useful.>
> We could now ask what Pete woul= d think about that.
>
> Barry
>
> ________________________________= _______________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--
HLS


____________________= ___________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discu= ss


=20
--933233344-256298943-1396375667=:93541-- From nobody Tue Apr 1 11:38:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CAE1A08AC for ; Tue, 1 Apr 2014 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO0Htm25nFEc for ; Tue, 1 Apr 2014 11:38:48 -0700 (PDT) Received: from pop3.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E411A1A0505 for ; Tue, 1 Apr 2014 11:38:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8452; t=1396377515; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=N0vTm+2onOPw4/sTdcYCXEyZkCw=; b=p2t4yMb0EJaPJ4kwkf50 Ovnh1tBGzyD59Rdc5p91jO59MlxunzOyT1yDfFADmfDlOQMJViooU9l4nzjeffJ/ IUtYDgOraANzV3GsVb6R9OrlqCRsGqDTl22RgFtf6Z/bB2ahYoU4kuoybl/+S+9Z uAnyD1Ppq7NFwXl6CLpNwKg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 01 Apr 2014 13:38:35 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1364974812.14532.4816; Tue, 01 Apr 2014 13:38:35 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8452; t=1396377473; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/gB1C6P YxplC0YxTgA6IpJmSOGeytma8gPrJWZAtVJ8=; b=X9k5cKmveU56deGOZjHbYat ZGAgujf6SmHqZ8ZeP+QsxDVggj7pNrZE9fMx9gZ+yyKTkWJzFyb0QZEKrCmiFV/8 U1d/0dxGgjMiI3O5owr5Ke8gIxgLmQholSOGgQnm4cfKYKuUqQMVhzhGzg1PiEvY obS0Q/ynBXla9+ucgLpw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 01 Apr 2014 14:37:53 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 811229241.9.18044; Tue, 01 Apr 2014 14:37:52 -0400 Message-ID: <533B07AA.6000603@isdg.net> Date: Tue, 01 Apr 2014 14:38:34 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bill Mills , Barry Leiba References: <20140330033009.4839.qmail@joyce.lan> <5337998C.3080403@dcrocker.net> <53388D3C.7090105@dcrocker.net> <533893C3.1070903@dcrocker.net> <533897F3.5050005@dcrocker.net> <533AECB7.6080505@isdg.net> <1396375667.93541.YahooMailNeo@web125603.mail.ne1.yahoo.com> In-Reply-To: <1396375667.93541.YahooMailNeo@web125603.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CGX28Zx2LeD_ya0trRDH2ivlx18 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 18:38:51 -0000 Yes, I understand that but so has everyone else since the annal of computerized mail/user hosting applications including network versions such as BBSes with UUCP/SLIP and then replaced with SMTP transports. Every commercial system, including ours, had tools or means to provide operators the ability to expire and/or delete user accounts since the 80s. So why the RRVS now? How does it resolve the old problem? I would like to know what is different today than yesterdays that resolve the problem we had then and also remove, or perhaps just lowers the risk. Obviously Yahoo made the decision that its OK to do this. I should note, that I saw a developer's article/blog saying that it should only be applied to YAHOO accounts. Why? If there is a statistical spread of risk, we should see that information. Look, I am not opposing it, I just don't think it has been completely worked out. I would love to sell this to my customers: "Hey, look, you can now expire/delete accounts and ALMOST SAFELY secure clobbering of email accounts allow you to offer reusability of the accounts." Maybe for YAHOO purposes it works ok because of sheer volume. I should note there is some commoditization going too with the reusability (a charge). Which is not an issue, but if thats the case, then the proposal should be very specific in its application need, not leave it open-ended as probable reason to appease the IETF community of its wider purpose and thus justification for standardization. Side issue: The IETF lacks a category for a new form of proposals, which I like to called Internet Methods or IM. I would like to see interop and personal operational reports. Some statistics. I would like to time to test it to see how we need to fit it. What has Yahoo learned for software design changes needed at the router, receiver, sender and also gateway side? etc. These are rhetorical questions expressing my level of concerns and perhaps resistance to endorse, adopt and implement the proposed solution as it is written. Thanks Bill -- HLS On 4/1/2014 2:07 PM, Bill Mills wrote: > Yahoo and others have been recycling accounts in volume for many many > years, this isn't new. > -bill > > > -------------------------------- > William J. Mills > "Paranoid" MUX Yahoo! > > > > On Tuesday, April 1, 2014 9:44 AM, Hector Santos wrote: > If I may add some points...... > > I don't think it it a good idea to inject a S/MIME complexity into > this solution. I don't see how it can help the adoption of either. > But the fact it is being considered supports my feeling this is still > all an experimental concept. > > IMO, Yahoo made an critical, strategic operational decision to begin > to expire old accounts a lot quicker than perhaps in the past. While > it is an old issue for many hosting systems with their maintenance > tools of user accounts, just because YAHOO is cracking open this door > doesn't mean the potential millions of public and private hosting > sites, especially private businesses are going to buy into the idea of > its suddenly OK to begin reusing old email addresses. Just because > YAHOO has decided to accelerate expirations and begin making email > addresses a premium item to own, doesn't remove the idea its a very > risky proposition for a much more wider set of operations. I believe > there needs to be a more solid client/server protocol negotiated > understanding of its main purposes and limits. I believe it hasn't > been all worked out and the development investment into this can be > costly and foremost wasteful. We are talking changes at all > components of a complete mail system: > > Receiver > Router > Gateways > Senders > > The draft needs to be more clear on its purpose. It shouldn't be > open-ended. In the abstract it says: > > The intended use of these facilities is on automatically generated > messages, such as account statements or password change instructions, > that might contain sensitive information, though it may also be > useful in other applications. > > That last stated open ended potential purpose should be removed or the > whole statement should be written to be more specific towards SMTP > outcomes; positive/negative determination of an (RCPT) user account > acceptability at a mail hosting domain. The communication is done via > SMTP reply codes. This means that it can done at the SMTP RCPT > and/or DATA state machine points. IOW, it should not be delayed > (accept and then processed afterwards, routed and/or bounced. > > > But whether its an SMTP command extension or payload header solution, > delayed or otherwise at the backend, it MUST be a single consistent > functional logic. The header solution is a time shifted, time delayed > method that could be complex in its queuing, meta data framework and > exposed to additional pervasive monitoring/security related concerns. > Nonetheless, there could not be any difference in overall logic > otherwise we have a potential security loophole. > > Related to the security, it makes me wonder how well its going to go > at LC. After all these security and privacy discussions, the recent > related I-Ds and RFC work, we are considering something that seems to > thumb its nose at those concerns. > > Thanks > > -- > HLS > > > > On 3/31/2014 6:56 PM, Barry Leiba wrote: >>>> Could you do me a big favor and stop attempting to rephrase what I said? >>>> You're not very good at it. >> ... >>> Also, I didn't "rephrase" what you said. I offered an assessment of it. >>> The difference is fundamental. >> >> I find this discussion between the two of you tr�s bizarre, because >> you're working against each other, when what John brought up seems to >> support what Dave wants. >> >> Here, let me try to bring it around to a resolution of a significant issue: >> >> What started this was a contention that the SMTP extension is "better" >> (latitude here, for the moment) than the header field. No one really >> disputes that. And then, that because it's better, the two should be >> defined separately, with the extension set up as Standards Track, and >> the header field not. That's where the dispute is. >> >> One basis for the dispute is that the extension is not *sufficiently* >> better to make a real difference: neither is a guarantee, so does it >> really matter whether we have a very loose non-guarantee, or a >> somewhat, but not completely better non-guarantee? Senders might be >> willing to get failures bounced, but are senders really willing to get >> non-support bounced? If they try, it's likely that people will sign >> up with their banks and *never* get any transactional mail because >> they happen to be on a mail system that doesn't support the RRVS >> extension. >> >> So John points out something that's worth discussing in the document, >> and that might address Pete's concerns: The guaranteed way to do this >> is with S/MIME mail encrypted to the recipient's key. No intermediary >> support is needed for this -- it's only that the recipient's email >> system has to support S/MIME (not a huge problem today, though I'll >> note that Gmail doesn't), and that the recipient has to have certs set >> up (Oy!). >> >> I still think it's better to split out the header-field version and >> make it Informational. But the argument above makes it less of an >> issue. Perhaps the RRVS document should have a section that talks >> about the advantages of the extension over the header field, the >> realities of the header field over the extension, and the real >> security limitations of both. Perhaps that section should say that if >> guarantees are needed, neither of these does it, and senders should >> consider S/MIME. But if a "do your best" request suffices, these >> mechanism are useful. >> >> We could now ask what Pete would think about that. >> >> Barry >> >> _______________________________________________ >> apps-discuss mailing list >>apps-discuss@ietf.org >>https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > -- > HLS > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- HLS From nobody Tue Apr 1 11:57:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C281A09E5 for ; Tue, 1 Apr 2014 11:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9MylwffWgmZ for ; Tue, 1 Apr 2014 11:57:07 -0700 (PDT) Received: from pop3.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AFAE31A09E7 for ; Tue, 1 Apr 2014 11:57:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=9513; t=1396378617; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VJ97FvB9ClII+RW+xBpElIT1fR4=; b=jZWntDerJ0P2k8L6vUkF JV+YNT1mSWUh8sxx/PwhOWO7eCcEsqzATzaXRmGyvn7y+5XbJskJfZQyqTiqE1Gy QX4nnUBw2jpSfzjX7aw+WVtlhRBWYziS5E08wCFfS19DVclOBUfI6E8p2N3aDl0u 9gJTUM6iSquNxUT4thVdTOI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 01 Apr 2014 13:56:57 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1366075227.14532.3204; Tue, 01 Apr 2014 13:56:55 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=9513; t=1396378570; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vF+dRX7 OcGCFrNwb1hemb/EtmI2ELA4oJcV6LR02pTE=; b=RM76BomS3I9f08HG6tVMh1x HjQ4oqDqAl0L60lYtOsNzrdwRx5iiZPxT5CJAXDEPsbDp5OQ3neK4fGFAhwvTe0Q s0JM4fTVzoFVMmbwIOZC3gX4B/G3txzSgo1tdB65Gc8zxsdYF235AAGODQmcDFC7 kgBdNfJcFvj0MfCLtlGM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 01 Apr 2014 14:56:10 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 812326194.9.17940; Tue, 01 Apr 2014 14:56:09 -0400 Message-ID: <533B0BF3.9090700@isdg.net> Date: Tue, 01 Apr 2014 14:56:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bill Mills , Barry Leiba References: <20140330033009.4839.qmail@joyce.lan> <5337998C.3080403@dcrocker.net> <53388D3C.7090105@dcrocker.net> <533893C3.1070903@dcrocker.net> <533897F3.5050005@dcrocker.net> <533AECB7.6080505@isdg.net> <1396375667.93541.YahooMailNeo@web125603.mail.ne1.yahoo.com> <533B07AA.6000603@isdg.net> In-Reply-To: <533B07AA.6000603@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_F2ayygK39QERCR7NDZTRmeCPE4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 18:57:10 -0000 Bill, one way that an implementation can add this, is to do so only for ACCOUNTS that not has received any transaction attempts for X periods, for example 2 years. Today, at our specific support site, over 60% of RCPT attempts are rejects for non-existing accounts, existing but expired accounts and/or valid accounts but does not have SMTP/POP3/IMAP (internet email) access. It is common for a security group profile to have online mail access only. Just not with IETF RFC-based store and forward methods. Overall, the proposal is suggesting that it might be OK today to begin reassigning many of these currently rejected accounts. I can see a lowered risk if there was a strong emphasis on the length of non-usage. -- HLS On 4/1/2014 2:38 PM, Hector Santos wrote: > Yes, I understand that but so has everyone else since the annal of > computerized mail/user hosting applications including network versions > such as BBSes with UUCP/SLIP and then replaced with SMTP transports. > Every commercial system, including ours, had tools or means to provide > operators the ability to expire and/or delete user accounts since the > 80s. > > So why the RRVS now? How does it resolve the old problem? > > I would like to know what is different today than yesterdays that > resolve the problem we had then and also remove, or perhaps just > lowers the risk. Obviously Yahoo made the decision that its OK to do > this. I should note, that I saw a developer's article/blog saying > that it should only be applied to YAHOO accounts. Why? If there is a > statistical spread of risk, we should see that information. > > Look, I am not opposing it, I just don't think it has been completely > worked out. I would love to sell this to my customers: > > "Hey, look, you can now expire/delete accounts and ALMOST SAFELY > secure > clobbering of email accounts allow you to offer reusability of the > accounts." > > Maybe for YAHOO purposes it works ok because of sheer volume. I should > note there is some commoditization going too with the reusability (a > charge). Which is not an issue, but if thats the case, then the > proposal should be very specific in its application need, not leave it > open-ended as probable reason to appease the IETF community of its > wider purpose and thus justification for standardization. > > Side issue: The IETF lacks a category for a new form of > proposals, which > I like to called Internet Methods or IM. > > I would like to see interop and personal operational reports. Some > statistics. I would like to time to test it to see how we need to fit > it. What has Yahoo learned for software design changes needed at the > router, receiver, sender and also gateway side? etc. These are > rhetorical questions expressing my level of concerns and perhaps > resistance to endorse, adopt and implement the proposed solution as it > is written. > > Thanks Bill > > -- > HLS > > > On 4/1/2014 2:07 PM, Bill Mills wrote: >> Yahoo and others have been recycling accounts in volume for many many >> years, this isn't new. >> -bill >> >> >> -------------------------------- >> William J. Mills >> "Paranoid" MUX Yahoo! >> >> >> >> On Tuesday, April 1, 2014 9:44 AM, Hector Santos >> wrote: >> If I may add some points...... >> >> I don't think it it a good idea to inject a S/MIME complexity into >> this solution. I don't see how it can help the adoption of either. >> But the fact it is being considered supports my feeling this is still >> all an experimental concept. >> >> IMO, Yahoo made an critical, strategic operational decision to begin >> to expire old accounts a lot quicker than perhaps in the past. While >> it is an old issue for many hosting systems with their maintenance >> tools of user accounts, just because YAHOO is cracking open this door >> doesn't mean the potential millions of public and private hosting >> sites, especially private businesses are going to buy into the idea of >> its suddenly OK to begin reusing old email addresses. Just because >> YAHOO has decided to accelerate expirations and begin making email >> addresses a premium item to own, doesn't remove the idea its a very >> risky proposition for a much more wider set of operations. I believe >> there needs to be a more solid client/server protocol negotiated >> understanding of its main purposes and limits. I believe it hasn't >> been all worked out and the development investment into this can be >> costly and foremost wasteful. We are talking changes at all >> components of a complete mail system: >> >> Receiver >> Router >> Gateways >> Senders >> >> The draft needs to be more clear on its purpose. It shouldn't be >> open-ended. In the abstract it says: >> >> The intended use of these facilities is on automatically generated >> messages, such as account statements or password change >> instructions, >> that might contain sensitive information, though it may also be >> useful in other applications. >> >> That last stated open ended potential purpose should be removed or the >> whole statement should be written to be more specific towards SMTP >> outcomes; positive/negative determination of an (RCPT) user account >> acceptability at a mail hosting domain. The communication is done via >> SMTP reply codes. This means that it can done at the SMTP RCPT >> and/or DATA state machine points. IOW, it should not be delayed >> (accept and then processed afterwards, routed and/or bounced. >> >> >> But whether its an SMTP command extension or payload header solution, >> delayed or otherwise at the backend, it MUST be a single consistent >> functional logic. The header solution is a time shifted, time delayed >> method that could be complex in its queuing, meta data framework and >> exposed to additional pervasive monitoring/security related concerns. >> Nonetheless, there could not be any difference in overall logic >> otherwise we have a potential security loophole. >> >> Related to the security, it makes me wonder how well its going to go >> at LC. After all these security and privacy discussions, the recent >> related I-Ds and RFC work, we are considering something that seems to >> thumb its nose at those concerns. >> >> Thanks >> >> -- >> HLS >> >> >> >> On 3/31/2014 6:56 PM, Barry Leiba wrote: >>>>> Could you do me a big favor and stop attempting to rephrase what >>>>> I said? >>>>> You're not very good at it. >>> ... >>>> Also, I didn't "rephrase" what you said. I offered an assessment >>>> of it. >>>> The difference is fundamental. >>> >>> I find this discussion between the two of you tr�s bizarre, because >>> you're working against each other, when what John brought up seems to >>> support what Dave wants. >>> >>> Here, let me try to bring it around to a resolution of a >>> significant issue: >>> >>> What started this was a contention that the SMTP extension is "better" >>> (latitude here, for the moment) than the header field. No one really >>> disputes that. And then, that because it's better, the two should be >>> defined separately, with the extension set up as Standards Track, and >>> the header field not. That's where the dispute is. >>> >>> One basis for the dispute is that the extension is not *sufficiently* >>> better to make a real difference: neither is a guarantee, so does it >>> really matter whether we have a very loose non-guarantee, or a >>> somewhat, but not completely better non-guarantee? Senders might be >>> willing to get failures bounced, but are senders really willing to >>> get >>> non-support bounced? If they try, it's likely that people will sign >>> up with their banks and *never* get any transactional mail because >>> they happen to be on a mail system that doesn't support the RRVS >>> extension. >>> >>> So John points out something that's worth discussing in the document, >>> and that might address Pete's concerns: The guaranteed way to do this >>> is with S/MIME mail encrypted to the recipient's key. No intermediary >>> support is needed for this -- it's only that the recipient's email >>> system has to support S/MIME (not a huge problem today, though I'll >>> note that Gmail doesn't), and that the recipient has to have certs set >>> up (Oy!). >>> >>> I still think it's better to split out the header-field version and >>> make it Informational. But the argument above makes it less of an >>> issue. Perhaps the RRVS document should have a section that talks >>> about the advantages of the extension over the header field, the >>> realities of the header field over the extension, and the real >>> security limitations of both. Perhaps that section should say that if >>> guarantees are needed, neither of these does it, and senders should >>> consider S/MIME. But if a "do your best" request suffices, these >>> mechanism are useful. >>> >>> We could now ask what Pete would think about that. >>> >>> Barry >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >> >> -- >> HLS >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > -- HLS From nobody Tue Apr 1 11:57:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189FD1A09C8; Tue, 1 Apr 2014 11:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi7lOmtOE690; Tue, 1 Apr 2014 11:57:21 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 45C081A09F3; Tue, 1 Apr 2014 11:57:16 -0700 (PDT) Received: from [10.172.16.65] (gw.kingston.awtg.busi.ask4.co.uk [78.109.179.245]) by waldorf.isode.com (smtp internal) via TCP with ESMTPA id ; Tue, 1 Apr 2014 19:57:11 +0100 References: <5336F686.7060308@isode.com> <451cd52e77fb4baf9f736e063eb872ad@BY2PR03MB412.namprd03.prod.outlook.com> <63b3c4fad07742529b5ac4dfc0a0f306@DM2PR03MB414.namprd03.prod.outlook.com> In-Reply-To: <63b3c4fad07742529b5ac4dfc0a0f306@DM2PR03MB414.namprd03.prod.outlook.com> Message-Id: <5AC08C33-B2F3-462F-A93C-211362FA1B86@isode.com> X-Mailer: iPhone Mail (11B651) From: Alexey Melnikov Date: Tue, 1 Apr 2014 19:57:37 +0100 To: Dave Thaler MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1FbgjBncBYc1US5hCGaasmsEppk Cc: "uri-review@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] Registration request for smtp:// and submit:// URI schemes (draft-melnikov-smime-msa-to-mda-04) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 18:57:24 -0000 > On 1 Apr 2014, at 18:33, Dave Thaler wrote: > > I'm thinking it would be good to add a sentence about this case > (service names and URI scheme names SHOULD be the same, when there exists > a 1:1 correspondence) to draft-ietf-appsawg-uri-scheme-reg. Does that > sound reasonable? It sounds reasonable to me. From nobody Tue Apr 1 12:09:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7EB1A09CD for ; Tue, 1 Apr 2014 12:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM_0Mos9M_A1 for ; Tue, 1 Apr 2014 12:09:03 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CB9D71A09C8 for ; Tue, 1 Apr 2014 12:09:02 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so4345706wib.11 for ; Tue, 01 Apr 2014 12:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fhCwXB/l2ueBaVqT6BWLQGrj3i53nWE69yOEbFjAIk4=; b=zYe4VCoLj2dkrLM6SDKK9yGfuoDsijMIcE7yqZKUOuCrwJ0Sah5nCNOvWcWWUKvvtC lufwXAdxyrra6bWN6yR73I+ODNrnSlgIdiB34yZHkx2a4gwWOeEk7XOlWFcK/Fy+i2fX QySD/VUTHoS8Psf3JK9k04vccuxokDFEauJbHjzcdwiSvs5dZDT2UN6LD46NwOS1atO3 umkJ5ZONjfQv1R26hy36Ycw7NdNb/eBkQs2SY30dkoujanmWIL54VElzY5ql7aUOz135 eCZ2UJnq2ClNJ6dMgkqPOci0QoSvaguwVjO/1q5+hC5XDm0wOUOJNNBnYVqzkfV2UJhz P7Hg== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr14981704wjb.73.1396379338696; Tue, 01 Apr 2014 12:08:58 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Tue, 1 Apr 2014 12:08:58 -0700 (PDT) In-Reply-To: References: <018101cf4aa3$c8e7e8c0$4001a8c0@gateway.2wire.net> Date: Tue, 1 Apr 2014 12:08:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=047d7bf10a1c746eb304f5ffe6a2 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LyGSBpJRtXVthzgFZ0ZhIR_THs8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF89 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 19:09:04 -0000 --047d7bf10a1c746eb304f5ffe6a2 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, The Secretariat has informed me that the audio archives for our meeting at IETF 89 have been deleted with no chance of recovery. My normal process is to take the minutes prepared by the minute taker ( http://tools.ietf.org/wg/appsawg/minutes) and augment them with any important details from the audio feed. That won't be possible this time. I plan to upload the minutes visible at the URI above as the official ones for inclusion in the proceedings, but there's still a small time window during which changes can be included. If you have any to suggest, please email appsawg-chairs@tools.ietf.org. -MSK, APPSAWG co-chair On Fri, Mar 28, 2014 at 10:17 AM, Murray S. Kucherawy wrote: > They'll be posted this weekend. > > > On Fri, Mar 28, 2014 at 9:34 AM, t.petch wrote: > >> It would be good to see minutes from IETF89 before April 4th. >> >> Tom Petch >> > > --047d7bf10a1c746eb304f5ffe6a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

The Secretariat ha= s informed me that the audio archives for our meeting at IETF 89 have been = deleted with no chance of recovery.

My normal process is to take the= minutes prepared by the minute taker (http://tools.ietf.org/wg/appsawg/minutes) and augment = them with any important details from the audio feed.=A0 That won't be p= ossible this time.

I plan to upload the minutes visible at the URI above as the offi= cial ones for inclusion in the proceedings, but there's still a small t= ime window during which changes can be included.=A0 If you have any to sugg= est, please email appsawg-= chairs@tools.ietf.org.

-MSK, APPSAWG co-chair



On Fri, Mar 28, 2014 at 10:17 A= M, Murray S. Kucherawy <superuser@gmail.com> wrote:
They'll be posted this = weekend.


On Fri, Mar 28, 2014 at 9:34 AM, t.petch= <ietfc@btconnect.com> wrote:
It would be good to see minutes from IETF89 = before April 4th.

Tom Petch


--047d7bf10a1c746eb304f5ffe6a2-- From nobody Tue Apr 1 13:08:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A291A09CA for ; Tue, 1 Apr 2014 13:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCcs_D5E5csh for ; Tue, 1 Apr 2014 13:08:29 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF0B1A09A8 for ; Tue, 1 Apr 2014 13:08:29 -0700 (PDT) Received: from BF1-EX10-CAHT17.y.corp.yahoo.com (bf1-ex10-caht17.corp.bf1.yahoo.com [10.74.226.61]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s31K7tV1086029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Apr 2014 13:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1396382876; bh=PyKEqsQ/Z1ws6UllzpJ0F6J6Fa5x+X/ipYDn2J+crrw=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=fSuTs/588xDf2bAp+bpt71wxiYcEFezoUDHR0g6KnaDtP6C2ssLi7866KHklEEBeS H1kkmgwF9DPmYiUvhUi4Pnw21omDAS1tKNE4TOS3Gs0zIWYUYysi/lS54iQiFrj5IC g2QE+ma2mlgMRhoZCRdZ8tZcU+RsI0/yotnVA4Gk= Received: from omp1028.mail.ne1.yahoo.com (98.138.89.172) by BF1-EX10-CAHT17.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 1 Apr 2014 16:07:54 -0400 Received: (qmail 43066 invoked by uid 1000); 1 Apr 2014 20:07:53 -0000 Received: (qmail 56658 invoked by uid 60001); 1 Apr 2014 20:07:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1396382873; bh=ElHrIYQRzcEtbW+/qGVvHYEnPtfg4qEWKLbdfQJ5lmg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ca995ZLc7PmqgjGpuJ+0q95Z68W03OhUOyU/ZDseelyUgrZYg5pT/lvmsPTA4SsDYynD/IOCwBG39BnSHNAj/vWPrGMfXVRU/ST5RBunxGAtnRQrVA92BbhcrlwJOYkfRDt09vqh4JCcRVN4A8cXyNqPdYXlNsLfC4H7AqOaqn8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OSVRtquxNgKzi+XNUPVAk3qy3cqhIJqZ0T6a+0X3Tkus9ZPJVlnGYaaWUuBt9dnxzPkWKjhadhcOkIAzYVoBwuhkNpZyWjGpfqdIHAZVztgRCJT7zJh9ZiwB+is7sN7ZKeUP137W2vYLAA2CWaClKkMI7ZHRyHZ9DCI10ZOBfrs=; X-YMail-OSG: iHaKu_EVM1krUsgWX4drsvnROfEQMaCsWRhfspP9T2AoZwi 6CsyyelWgf_Zov4s2W5kW990l_YZrTKE9By7TObeYSlz31j4HwjfIXNCY91D XTfwUK9Q5LqrOMhHZiNvNqdWbBA98f2O.xv52y2KkaGraGxUPi_5sipZ4ZYs ikQKYiE0bk6zQQAuZNHMWBfPV9CSqjryusdaZ6AYKqWkcDFN_gyu4SbDvcoa 3XJA7p9bi9PB3YjnQ2bj_Y.SdSiSEykbRE3OqXXi9h989UB5PeI1B8UFiYGy 2O9bw14hk6J63v4RZYVEElocl Received: from [66.228.162.56] by web125604.mail.ne1.yahoo.com via HTTP; Tue, 01 Apr 2014 13:07:53 PDT X-Rocket-MIMEInfo: 002.001, V2UncmUgZ29pbmcgb3ZlciBvbGQgZ3JvdW5kIGhlcmUuwqAgQXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGFkIG5hdXNldW0gb24gdGhlIGJsb2dvc3BoZXJlIChhIHdvcmQgd2hpY2ggc3RpbGwgbWFrZXMgbWUgdGhpbmsgb2Ygc29tZXRoaW5nIHlvdSBjb3VnaCB1cCB3aGVuIHlvdSdyZSBzaWNrKSB0aGlzIGlzIGV4YWN0bHkgd2hhdCBZYWhvbyBkb2VzLgoKVGhlIGltcGV0dXMgZm9yIFJSVlMgd2FzIHRoZSBGVUQgYW5kIGNvbW1vdGlvbiBhcm91bmQgYSBwdWJsaWMgYW5ub3VuY2VtZW50IG9uIGFjY291bnQgcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <20140330033009.4839.qmail@joyce.lan> <5337998C.3080403@dcrocker.net> <53388D3C.7090105@dcrocker.net> <533893C3.1070903@dcrocker.net> <533897F3.5050005@dcrocker.net> <533AECB7.6080505@isdg.net> <1396375667.93541.YahooMailNeo@web125603.mail.ne1.yahoo.com> <533B07AA.6000603@isdg.net> <533B0BF3.9090700@isdg.net> Message-ID: <1396382873.82601.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Tue, 1 Apr 2014 13:07:53 -0700 From: Bill Mills To: Hector Santos , Barry Leiba In-Reply-To: <533B0BF3.9090700@isdg.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-1718526140-1396382873=:82601" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zg73sTzi6M9G3Tt_bCkJa2YMlgU Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:08:33 -0000 ---685807438-1718526140-1396382873=:82601 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable We're going over old ground here.=C2=A0 As has been discussed ad nauseum on= the blogosphere (a word which still makes me think of something you cough = up when you're sick) this is exactly what Yahoo does.=0A=0AThe impetus for = RRVS was the FUD and commotion around a public announcement on account recy= cling for more desirable names.=0A=0AYes, it's an old old problem that no o= ne had been forced to solve previously.=C2=A0 It's a problem that has chang= ed in scope and user impact as accounts and identities become more linked a= nd valuable.=0A=0A=C2=A0=0A-bill=0A=0A=0A=0A-------------------------------= -=0AWilliam J. Mills=0A"Paranoid" MUX Yahoo!=0A=0A=0AOn Tuesday, April 1, 2= 014 11:57 AM, Hector Santos wrote:=0A =0ABill, one way t= hat an implementation can add this, is to do so only =0Afor ACCOUNTS that n= ot has received any transaction attempts for X =0Aperiods, for example 2 ye= ars.=0A=0AToday, at our specific support site, over 60% of RCPT attempts ar= e =0Arejects for non-existing accounts, existing but expired accounts =0Aan= d/or valid accounts but does not have SMTP/POP3/IMAP (internet =0Aemail) ac= cess. It is common for a security group profile to have =0Aonline mail acce= ss only. Just not with IETF RFC-based store and =0Aforward methods.=0A=0AOv= erall, the proposal is suggesting that it might be OK today to begin =0Area= ssigning many of these currently rejected accounts.=0A=0AI can see a lowere= d risk if there was a strong emphasis on the length =0Aof non-usage.=0A=0A-= -=0AHLS=0A=0A=0A=0AOn 4/1/2014 2:38 PM, Hector Santos wrote:=0A> Yes, I und= erstand that but so has everyone else since the annal of=0A> computerized m= ail/user hosting applications including network versions=0A> such as BBSes = with UUCP/SLIP and then replaced with SMTP transports.=0A> Every commercial= system, including ours, had tools or means to provide=0A> operators the ab= ility to expire and/or delete user accounts since the=0A> 80s.=0A>=0A> So w= hy the RRVS now?=C2=A0 How does it resolve the old problem?=0A>=0A> I would= like to know what is different today than yesterdays that=0A> resolve the = problem we had then and also remove, or perhaps just=0A> lowers the risk.= =C2=A0 Obviously Yahoo made the decision that its OK to do=0A> this.=C2=A0 = I should note, that I saw a developer's article/blog saying=0A> that it sho= uld only be applied to YAHOO accounts.=C2=A0 Why?=C2=A0 If there is a=0A> s= tatistical spread of risk, we should see that information.=0A>=0A> Look, I = am not opposing it, I just don't think it has been completely=0A> worked ou= t.=C2=A0 I would love to sell this to my customers:=0A>=0A>=C2=A0 =C2=A0 = =C2=A0 "Hey, look, you can now expire/delete accounts and ALMOST SAFELY=0A>= secure=0A>=C2=A0 =C2=A0 =C2=A0 clobbering of email accounts allow you to = offer reusability of the=0A>=C2=A0 =C2=A0 =C2=A0 accounts."=0A>=0A> Maybe = for YAHOO purposes it works ok because of sheer volume. I should=0A> note t= here is some commoditization going too with the reusability (a=0A> charge).= Which is not an issue, but if thats the case, then the=0A> proposal should= be very specific in its application need, not leave it=0A> open-ended as p= robable reason to appease the IETF community of its=0A> wider purpose and t= hus justification for standardization.=0A>=0A>=C2=A0 =C2=A0 =C2=A0 Side iss= ue: The IETF lacks a category for a new form of=0A> proposals, which=0A>=C2= =A0 =C2=A0 =C2=A0 I like to called Internet Methods or IM.=0A>=0A> I would = like to see interop and personal operational reports. Some=0A> statistics. = I would like to time to test it to see how we need to fit=0A> it.=C2=A0 Wha= t has Yahoo learned for software design changes needed at the=0A> router, r= eceiver, sender and also gateway side? etc.=C2=A0 These are=0A> rhetorical = questions expressing my level of concerns and perhaps=0A> resistance to end= orse, adopt and implement the proposed solution as it=0A> is written.=0A>= =0A> Thanks Bill=0A>=0A> --=0A> HLS=0A>=0A>=0A> On 4/1/2014 2:07 PM, Bill M= ills wrote:=0A>> Yahoo and others have been recycling accounts in volume fo= r many many=0A>> years, this isn't new.=0A>> -bill=0A>>=0A>>=0A>> ---------= -----------------------=0A>> William J. Mills=0A>> "Paranoid" MUX Yahoo!=0A= >>=0A>>=0A>>=0A>> On Tuesday, April 1, 2014 9:44 AM, Hector Santos =0A>> wrote:=0A>> If I may add some points......=0A>>=0A>> I don'= t think it it a good idea to inject a S/MIME complexity into=0A>> this solu= tion. I don't see how it can help the adoption of either.=0A>> But the fact= it is being considered supports my feeling this is still=0A>> all an exper= imental concept.=0A>>=0A>> IMO, Yahoo made an critical, strategic operation= al decision to begin=0A>> to expire old accounts a lot quicker than perhaps= in the past.=C2=A0 While=0A>> it is an old issue for many hosting systems = with their maintenance=0A>> tools of user accounts, just because YAHOO is c= racking open this door=0A>> doesn't mean the potential millions of public a= nd private hosting=0A>> sites, especially private businesses are going to b= uy into the idea of=0A>> its suddenly OK to begin reusing old email address= es. Just because=0A>> YAHOO has decided to accelerate expirations and begin= making email=0A>> addresses a premium item to own, doesn't remove the idea= its a very=0A>> risky proposition for a much more wider set of operations.= I believe=0A>> there needs to be a more solid client/server protocol negot= iated=0A>> understanding of its main purposes and limits.=C2=A0 I believe i= t hasn't=0A>> been all worked out and the development investment into this = can be=0A>> costly and foremost wasteful.=C2=A0 We are talking changes at a= ll=0A>> components of a complete mail system:=0A>>=0A>>=C2=A0 =C2=A0 =C2=A0= Receiver=0A>>=C2=A0 =C2=A0 =C2=A0 Router=0A>>=C2=A0 =C2=A0 =C2=A0 Gateways= =0A>>=C2=A0 =C2=A0 =C2=A0 Senders=0A>>=0A>> The draft needs to be more clea= r on its purpose. It shouldn't be=0A>> open-ended.=C2=A0 In the abstract it= says:=0A>>=0A>>=C2=A0 =C2=A0 =C2=A0 The intended use of these facilities i= s on automatically generated=0A>>=C2=A0 =C2=A0 =C2=A0 messages, such as acc= ount statements or password change=0A>> instructions,=0A>>=C2=A0 =C2=A0 =C2= =A0 that might contain sensitive information, though it may also be=0A>>=C2= =A0 =C2=A0 =C2=A0 useful in other applications.=0A>>=0A>> That last stated = open ended potential purpose should be removed or the=0A>> whole statement = should be written to be more specific towards SMTP=0A>> outcomes; positive/= negative determination of an (RCPT) user account=0A>> acceptability at a ma= il hosting domain.=C2=A0 The communication is done via=0A>> SMTP reply code= s.=C2=A0 This means that it can done at the SMTP=C2=A0 RCPT=0A>> and/or DAT= A state machine points. IOW, it should not be delayed=0A>> (accept and then= processed afterwards, routed and/or bounced.=0A>>=0A>>=0A>> But whether it= s an SMTP command extension or payload header solution,=0A>> delayed or oth= erwise at the backend, it MUST be a single consistent=0A>> functional logic= .=C2=A0 The header solution is a time shifted, time delayed=0A>> method tha= t could be complex in its queuing, meta data framework and=0A>> exposed to = additional pervasive monitoring/security related concerns.=0A>> Nonetheless= , there could not be any difference in overall logic=0A>> otherwise we have= a potential security loophole.=0A>>=0A>> Related to the security, it makes= me wonder how well its going to go=0A>> at LC.=C2=A0 After all these secur= ity and privacy discussions, the recent=0A>> related I-Ds and RFC work,=C2= =A0 we are considering something that seems to=0A>> thumb its nose at those= concerns.=0A>>=0A>> Thanks=0A>>=0A>> --=0A>> HLS=0A>>=0A>>=0A>>=0A>> On 3/= 31/2014 6:56 PM, Barry Leiba wrote:=0A>>>>> Could you do me a big favor and= stop attempting to rephrase what=0A>>>>> I said?=0A>>>>> You're not very g= ood at it.=0A>>> ...=0A>>>> Also, I didn't "rephrase" what you said.=C2=A0 = I offered an assessment=0A>>>> of it.=0A>>>> The difference is fundamental.= =0A>>>=0A>>> I find this discussion between the two of you tr=EF=BF=BDs biz= arre, because=0A>>> you're working against each other, when what John broug= ht up seems to=0A>>> support what Dave wants.=0A>>>=0A>>> Here, let me try = to bring it around to a resolution of a=0A>>> significant issue:=0A>>>=0A>>= > What started this was a contention that the SMTP extension is "better"=0A= >>> (latitude here, for the moment) than the header field.=C2=A0 No one rea= lly=0A>>> disputes that.=C2=A0 And then, that because it's better, the two = should be=0A>>> defined separately, with the extension set up as Standards = Track, and=0A>>> the header field not.=C2=A0 That's where the dispute is.= =0A>>>=0A>>> One basis for the dispute is that the extension is not *suffic= iently*=0A>>> better to make a real difference: neither is a guarantee, so = does it=0A>>> really matter whether we have a very loose non-guarantee, or = a=0A>>> somewhat, but not completely better non-guarantee?=C2=A0 Senders mi= ght be=0A>>> willing to get failures bounced, but are senders really willin= g to=0A>>> get=0A>>> non-support bounced?=C2=A0 If they try, it's likely th= at people will sign=0A>>> up with their banks and *never* get any transacti= onal mail because=0A>>> they happen to be on a mail system that doesn't sup= port the RRVS=0A>>> extension.=0A>>>=0A>>> So John points out something tha= t's worth discussing in the document,=0A>>> and that might address Pete's c= oncerns:=C2=A0 The guaranteed way to do this=0A>>> is with S/MIME mail encr= ypted to the recipient's key.=C2=A0 No intermediary=0A>>> support is needed= for this -- it's only that the recipient's email=0A>>> system has to suppo= rt S/MIME (not a huge problem today, though I'll=0A>>> note that Gmail does= n't), and that the recipient has to have certs set=0A>>> up (Oy!).=0A>>>=0A= >>> I still think=C2=A0 it's better to split out the header-field version a= nd=0A>>> make it Informational.=C2=A0 But the argument above makes it less = of an=0A>>> issue.=C2=A0 Perhaps the RRVS document should have a section th= at talks=0A>>> about the advantages of the extension over the header field,= the=0A>>> realities of the header field over the extension, and the real= =0A>>> security limitations of both.=C2=A0 Perhaps that section should say = that if=0A>>> guarantees are needed, neither of these does it, and senders = should=0A>>> consider S/MIME.=C2=A0 But if a "do your best" request suffice= s, these=0A>>> mechanism are useful.=0A>>>=0A>>> We could now ask what Pete= would think about that.=0A>>>=0A>>> Barry=0A>>>=0A>>> ____________________= ___________________________=0A>>> apps-discuss mailing list=0A>>> apps-disc= uss@ietf.org =0A>>> https://www.ietf.org/mail= man/listinfo/apps-discuss=0A>>>=0A>>>=0A>>=0A>> --=0A>> HLS=0A>>=0A>>=0A>>= =0A>> _______________________________________________=0A>> apps-discuss mai= ling list=0A>> apps-discuss@ietf.org =0A>> ht= tps://www.ietf.org/mailman/listinfo/apps-discuss=0A>>=0A>>=0A>=0A=0A-- =0AH= LS ---685807438-1718526140-1396382873=:82601 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
We're goi= ng over old ground here.  As has been discussed ad nauseum on the blog= osphere (a word which still makes me think of something you cough up when y= ou're sick) this is exactly what Yahoo does.

The impetus for RRVS wa= s the FUD and commotion around a public announcement on account recycling f= or more desirable names.

Yes, it's an old old problem that no one ha= d been forced to solve previously.  It's a problem that has changed in= scope and user impact as accounts and identities become more linked and va= luable.
 
-bill


------------------------= --------
William J. Mills
"Paranoid" MUX Yahoo!

On Tuesday, Apri= l 1, 2014 11:57 AM, Hector Santos <hsantos@isdg.net> wrote:
Bill, one way that an implementat= ion can add this, is to do so only
for ACCOUNTS that not= has received any transaction attempts for X
periods, fo= r example 2 years.

Today, at our speci= fic support site, over 60% of RCPT attempts are
rejects = for non-existing accounts, existing but expired accounts
and/or valid accounts but does not have SMTP/POP3/IMAP (internet
email) access. It is common for a security group profile to have
online mail access only. Just not with IETF RFC-based store and
forward methods.

Overall, t= he proposal is suggesting that it might be OK today to begin
reassigning many of these currently rejected accounts.

I can see a lowered risk if there was a strong emphas= is on the length
of non-usage.

--
HLS

<= div class=3D"yqt5798676591" id=3D"yqtfd43320">
On 4/1/201= 4 2:38 PM, Hector Santos wrote:
> Yes, I understand th= at but so has everyone else since the annal of
> compu= terized mail/user hosting applications including network versions
> such as BBSes with UUCP/SLIP and then replaced with SMTP tra= nsports.
> Every commercial system, including ours, had tools or means to provide
> operators the ability to expire and/or delete user acco= unts since the
> 80s.
>
> So why the RRVS now?  How does it resolve the old probl= em?
>
> I would like to know what= is different today than yesterdays that
> resolve the= problem we had then and also remove, or perhaps just
>= ; lowers the risk.  Obviously Yahoo made the decision that its OK to d= o
> this.  I should note, that I saw a developer'= s article/blog saying
> that it should only be applied= to YAHOO accounts.  Why?  If there is a
> s= tatistical spread of risk, we should see that information.
>
> Look, I am not opposing it, I just don't thin= k it has been completely
> worked out.  I would love to sell = this to my customers:
>
>  &= nbsp;   "Hey, look, you can now expire/delete accounts and ALMOST SAFE= LY
> secure
>     = clobbering of email accounts allow you to offer reusability of the
>      accounts."
>
> Maybe for YAHOO purposes it works ok because of sheer v= olume. I should
> note there is some commoditization g= oing too with the reusability (a
> charge). Which is n= ot an issue, but if thats the case, then the
> proposa= l should be very specific in its application need, not leave it
> open-ended as probable reason to appease the IETF community of = its
> wider purpose and thus justification for standar= dization.
>
>      Side issue:= The IETF lacks a category for a new form of
> proposa= ls, which
>      I like to called Inter= net Methods or IM.
>
> I would li= ke to see interop and personal operational reports. Some
= > statistics. I would like to time to test it to see how we need to fit<= br clear=3D"none">> it.  What has Yahoo learned for software design= changes needed at the
> router, receiver, sender and = also gateway side? etc.  These are
> rhetorical q= uestions expressing my level of concerns and perhaps
>= resistance to endorse, adopt and implement the proposed solution as it
> is written.
>
&g= t; Thanks Bill
>
> --
> HLS
>
>
> On 4/1/2= 014 2:07 PM, Bill Mills wrote:
>> Yahoo and others = have been recycling accounts in volume for many many
>= > years, this isn't new.
>> -bill
>>
>>
>> --------= ------------------------
>> William J. Mills
>> "Paranoid" MUX Yahoo!
>>
>>
>>
>>= On Tuesday, April 1, 2014 9:44 AM, Hector Santos <hsantos@i= sdg.net>
>> wrote:
>>= ; If I may add some points......
>>
>> I don't think it it a good idea to inject a S/MIME complexity i= nto
>> this solution. I don't see how it can help the adoption of either.
>> But the fact it is being considered supports my feeling this= is still
>> all an experimental concept.
>>
>> IMO, Yahoo made an critical, = strategic operational decision to begin
>> to expir= e old accounts a lot quicker than perhaps in the past.  While
>> it is an old issue for many hosting systems with their m= aintenance
>> tools of user accounts, just because = YAHOO is cracking open this door
>> doesn't mean th= e potential millions of public and private hosting
>&g= t; sites, especially private businesses are going to buy into the idea of>> its suddenly OK to begin reusing old email addres= ses. Just because
>> YAHOO has decided to accelerat= e expirations and begin making email
>> addresses a premium item= to own, doesn't remove the idea its a very
>> risk= y proposition for a much more wider set of operations. I believe
>> there needs to be a more solid client/server protocol ne= gotiated
>> understanding of its main purposes and = limits.  I believe it hasn't
>> been all worke= d out and the development investment into this can be
>= ;> costly and foremost wasteful.  We are talking changes at all
>> components of a complete mail system:
>>
>>      Receiver
>>      Router
>>=       Gateways
>>     = ; Senders
>>
>> The draft n= eeds to be more clear on its purpose. It shouldn't be
>> open-ended.&nbs= p; In the abstract it says:
>>
&g= t;>      The intended use of these facilities is on autom= atically generated
>>      messages,= such as account statements or password change
>> i= nstructions,
>>      that might cont= ain sensitive information, though it may also be
>>=       useful in other applications.
>&g= t;
>> That last stated open ended potential purpose= should be removed or the
>> whole statement should= be written to be more specific towards SMTP
>> out= comes; positive/negative determination of an (RCPT) user account
>> acceptability at a mail hosting domain.  The commun= ication is done via
>> SMTP reply codes.  This means that it = can done at the SMTP  RCPT
>> and/or DATA stat= e machine points. IOW, it should not be delayed
>> = (accept and then processed afterwards, routed and/or bounced.
>>
>>
>> But whe= ther its an SMTP command extension or payload header solution,
>> delayed or otherwise at the backend, it MUST be a single con= sistent
>> functional logic.  The header solut= ion is a time shifted, time delayed
>> method that = could be complex in its queuing, meta data framework and
= >> exposed to additional pervasive monitoring/security related concer= ns.
>> Nonetheless, there could not be any differen= ce in overall logic
>> otherwise we have a potentia= l security loophole.
>>
>> Related to= the security, it makes me wonder how well its going to go
>> at LC.  After all these security and privacy discussions, t= he recent
>> related I-Ds and RFC work,  we ar= e considering something that seems to
>> thumb its = nose at those concerns.
>>
>&g= t; Thanks
>>
>> --
>> HLS
>>
>>= ;
>>
>> On 3/31/2014 6:56 P= M, Barry Leiba wrote:
>>>>> Could you do m= e a big favor and stop attempting to rephrase what
>&g= t;>>> I said?
>>>>> You're not ve= ry good at it.
>>> ...
>>= ;>> Also, I didn't "rephrase" what you said.  I offered an assessment
= >>>> of it.
>>>> The difference i= s fundamental.
>>>
>>>= ; I find this discussion between the two of you tr=EF=BF=BDs bizarre, becau= se
>>> you're working against each other, when w= hat John brought up seems to
>>> support what Da= ve wants.
>>>
>>> Her= e, let me try to bring it around to a resolution of a
>= ;>> significant issue:
>>>
>>> What started this was a contention that the SMTP extension = is "better"
>>> (latitude here, for the moment) = than the header field.  No one really
>>> d= isputes that.  And then, that because it's better, the two should be>>> defined separately, with the extension set up = as Standards Track, and
>>> the header field not= .  That's where the dispute is.
>>>
>>> One basis for the dispute is that the extension is = not *sufficiently*
>>> better to make a real dif= ference: neither is a guarantee, so does it
>>> = really matter whether we have a very loose non-guarantee, or a
>>> somewhat, but not completely better non-guarantee? = Senders might be
>>> willing to get failures bo= unced, but are senders really willing to
>>> get=
>>> non-support bounced?  If they try, it'= s likely that people will sign
>>> up with their= banks and *never* get any transactional mail because
>= ;>> they happen to be on a mail system that doesn't support the RRVS
>>> extension.
>>>
>>> So John points out something that's worth discussing in the = document,
>>> and that might address Pete's conc= erns:  The guaranteed way to do this
>>> is= with S/MIME mail encrypted to the recipient's key.  No intermediary>>> support is needed for this -- it's only that = the recipient's email
>>> system has to support = S/MIME (not a huge problem today, though I'll
>>>= ; note that Gmail doesn't), and that the recipient has to have certs set>>> up (Oy!).
>>>
>>> I still think  it's better to split out the = header-field version and
>>> make it Information= al.  But the argument above makes it less of an
>>> issue.&n= bsp; Perhaps the RRVS document should have a section that talks
>>> about the advantages of the extension over the header f= ield, the
>>> realities of the header field over= the extension, and the real
>>> security limita= tions of both.  Perhaps that section should say that if
>>> guarantees are needed, neither of these does it, and sende= rs should
>>> consider S/MIME.  But if a "d= o your best" request suffices, these
>>> mechani= sm are useful.
>>>
>>>= ; We could now ask what Pete would think about that.
>= >>
>>> Barry
>>>= ;
>>> __________________________________________= _____
>>> apps-discuss mailing list
&g= t;>> apps-discuss@ietf.org <mailto:apps-discuss@ietf.org>
>>&= gt; https://www.ietf.org/mailman/listinfo/apps-discuss=
>>>
>>>
>>
>> --
>>= HLS
>>
>>
>>
>> _____________________________________= __________
>> apps-discuss mailing list
>> apps-discuss@ietf.org <mailto= :apps-discuss@ietf.org>
>= > https://www.ietf.org/mailman/listinfo/apps-discus= s
>>
>>
>

--
HLS




<= /div>
---685807438-1718526140-1396382873=:82601-- From nobody Tue Apr 1 13:13:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A521A08C1 for ; Tue, 1 Apr 2014 13:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqLll_lGXWxJ for ; Tue, 1 Apr 2014 13:13:44 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id B48651A09D1 for ; Tue, 1 Apr 2014 13:13:43 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4D01BFA0043; Tue, 1 Apr 2014 20:13:39 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1396383218-751-751/11/15; Tue, 1 Apr 2014 20:13:38 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Tue, 1 Apr 2014 22:13:37 +0200 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <5cdc1d31-dd00-466f-949c-ccc5d17bf573@gulbrandsen.priv.no> In-Reply-To: <1396382873.82601.YahooMailNeo@web125604.mail.ne1.yahoo.com> References: <20140330033009.4839.qmail@joyce.lan> <5337998C.3080403@dcrocker.net> <53388D3C.7090105@dcrocker.net> <533893C3.1070903@dcrocker.net> <533897F3.5050005@dcrocker.net> <533AECB7.6080505@isdg.net> <1396375667.93541.YahooMailNeo@web125603.mail.ne1.yahoo.com> <533B07AA.6000603@isdg.net> <533B0BF3.9090700@isdg.net> <1396382873.82601.YahooMailNeo@web125604.mail.ne1.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vH3pK4TUZnqGMWBfauZRjyWDvDo Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:13:47 -0000 These days an unspeakably large fraction of of all mail is to/from/cc/bcc gmail. (I bet this mail goes to at least one gmail address.) Hotmail didn't have that immense presence in 1994, so the need for RRVS has increased. Arnt From nobody Tue Apr 1 13:20:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83261A0A0E for ; Tue, 1 Apr 2014 13:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbwj6sp9JmrC for ; Tue, 1 Apr 2014 13:20:11 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 70B4A1A08C2 for ; Tue, 1 Apr 2014 13:20:11 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so11426962qcy.0 for ; Tue, 01 Apr 2014 13:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9KW/D3u1cFotnpUv/+TmaiSHurTv8FDCoH8GB4tB7X0=; b=XhjA3zgKXJSNyr3Uo2iG5n/RBROzH2/E46eeh1mvXIauGcBPaQNFMc1wwDPjQGfYJ3 0fzRCabd22li+XLjVVF2/BtVLK4yCOrAjVRPju+hb0BUuh5gHhklGPwxlgW7j+xRIRyS j8ZxV3kU5kDoVnWa4bHFzS79AHJIlrIF+HS0bo52XgISTiPfWJTGN3rDb+QiP68+34h/ T/cNqAVcWAzACcJWRtKRYPuW/R8CyND3tTBDmxQJdJgqejMsNZ0R8PPpBD1qdGVg6mR4 7cjcvRYAhQOZNnowr2jfbiBdhYujbdGPEQcfGTEywL1xwjt4D/lm/Nohf/XHLDpB8PdZ guzg== MIME-Version: 1.0 X-Received: by 10.140.83.232 with SMTP id j95mr36000598qgd.42.1396383607485; Tue, 01 Apr 2014 13:20:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.136.134 with HTTP; Tue, 1 Apr 2014 13:20:07 -0700 (PDT) In-Reply-To: <1396382873.82601.YahooMailNeo@web125604.mail.ne1.yahoo.com> References: <20140330033009.4839.qmail@joyce.lan> <5337998C.3080403@dcrocker.net> <53388D3C.7090105@dcrocker.net> <533893C3.1070903@dcrocker.net> <533897F3.5050005@dcrocker.net> <533AECB7.6080505@isdg.net> <1396375667.93541.YahooMailNeo@web125603.mail.ne1.yahoo.com> <533B07AA.6000603@isdg.net> <533B0BF3.9090700@isdg.net> <1396382873.82601.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Tue, 1 Apr 2014 16:20:07 -0400 X-Google-Sender-Auth: zJBrGwGjWuT7q2n71mP65l2XKnA Message-ID: From: Barry Leiba To: Bill Mills Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V4TXwGc9eUILg-6VXcm4AA13ZHY Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:20:12 -0000 > The impetus for RRVS was the FUD and commotion around a public > announcement on account recycling for more desirable names. > > Yes, it's an old old problem that no one had been forced to solve > previously. It's a problem that has changed in scope and user impact as > accounts and identities become more linked and valuable. Indeed, but here: This is exactly why Pete and I are pushing on this. Read what you say above and think about where it might go in the future, as awareness of risks and exposures becomes greater, and fear (whether it's real or FUD) increases. It's easy to say that all we need *today* is a best-effort solution, something that's better than nothing. What happens when the problem continues to change in scope and user impact, and accounts and identities become even more linked and more valuable? When we need something more robust than "please try, but it's not a big deal". Wouldn't it be best to (1) document what's better than nothing, and (2) prepare a more robust standard? Barry From nobody Tue Apr 1 14:37:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059071A0A0A for ; Tue, 1 Apr 2014 14:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHJ6QmUmZO1n for ; Tue, 1 Apr 2014 14:37:21 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9A1A0A03 for ; Tue, 1 Apr 2014 14:37:21 -0700 (PDT) Received: from GQ1-EX10-CAHT18.y.corp.yahoo.com (gq1-ex10-caht18.corp.gq1.yahoo.com [10.73.119.199]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s31LaVIG068639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Apr 2014 14:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1396388193; bh=R/2bq0qGokQOX4oWcl51gchf7oMvJlhoEIttvKtOrPk=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=AcEXh+XLGwCqanpOxeNGH/Y/0hQQjMsr3nL+FC9ug1AfIW4oU6Z1YHToQSR4KeuUk 6sI6cJjCPpnOBuLjlLGIOuAOQWvZKjwYYDAlzyjzgmY2MMLkh+yTKKaMMbAgJ8+1IN 0Q4+CpPB9V1HpSrfYhx5FxgImT1ucbw9UFS/alP8= Received: from omp1050.mail.ne1.yahoo.com (98.138.89.192) by GQ1-EX10-CAHT18.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 1 Apr 2014 14:36:31 -0700 Received: (qmail 32255 invoked by uid 1000); 1 Apr 2014 21:36:30 -0000 Received: (qmail 77803 invoked by uid 60001); 1 Apr 2014 21:36:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1396388190; bh=Oc7NHKQWS//TWkWi2HGVkfW8szydy6MkONz+n5yH1pM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mqCRoytJZ5xRZ73k9EPHF+iJcfRm8qWZi42Eb3zJRdISBxe0Mc54/MnIrwRZtY7SqOCwUybqjxf99W12M0fNjP2DyQitofG+g3CrAG/u6TKfmnbuTumguVL6y8CtnnNm4ZaDRJrx4VpeiIf9WHTg0fZwVLfVLh7krbsKWkOIeuk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Gsx61miGBLAdo0JwXnvgZKsmawze/e+YHnLkiq1gZ+o9bQ7aO69lduHZq6yevujZRLaAE6gJUiYUbTEQ0uhNj1m/BagWlyEKexd7PpqqFSGhoc4eu9mFN92muYhHL/NWbc9rD+8RHzSjNx8lW68WEtU/lqiNRC8XxhHRASquUWg=; X-YMail-OSG: mLKoacUVM1l9LM8zLOfurl0rf_eOiW9TErQfmw9SxBWD0xT 7Ajegf9EEcJ4t6zKemapIurRsYbgiFJ8mMjMvr6IUlQ5vXoMa.OEXHdIODev rlgmHBRFbeIwnAPnsaQa6HmCfb6rjKHeZE5Fz8DzqsOlkBZc53coXnRBMuDt djpBplS5akbjnD9.ZZGB1leYbTqzUhxxiOflDM7oi3KgxsdZel4LknjGdKoW t4PPXmezc_0JGcx1RNXWmLwfBDWXPtIAOue1fzLWFbZVgdX5bJwBy3oSIVr5 cj0pjaJYgNAUT1Od3JR0- Received: from [66.228.162.56] by web125602.mail.ne1.yahoo.com via HTTP; Tue, 01 Apr 2014 14:36:30 PDT X-Rocket-MIMEInfo: 002.001, CgpBcyBJIGhhdmUgc2FpZCwgbXkgb25seSBvYmplY3Rpb24gdG8gc3BsaXR0aW5nIHRoZSBkcmFmdCB3b3VsZCBiZSBpZiB0aGUgY3VycmVudCBSUlZTIGhlYWRlciBzcGVjaWZpY2F0aW9uIGJlY29tZXMgb3RoZXIgdGhhbiBzdGFuZGFyZHMgdHJhY2suCgoKSWYgdGhpcyBpcyBzcGxpdCB3aWxsIGJvdGggZHJhZnRzIGJlIHN0YW5kYXJkcyB0cmFjaz8KwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW5vaWQiIE1VWCBZYWhvbyEKCgpPbiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <20140330033009.4839.qmail@joyce.lan> <5337998C.3080403@dcrocker.net> <53388D3C.7090105@dcrocker.net> <533893C3.1070903@dcrocker.net> <533897F3.5050005@dcrocker.net> <533AECB7.6080505@isdg.net> <1396375667.93541.YahooMailNeo@web125603.mail.ne1.yahoo.com> <533B07AA.6000603@isdg.net> <533B0BF3.9090700@isdg.net> <1396382873.82601.YahooMailNeo@web125604.mail.ne1.yahoo.com> Message-ID: <1396388190.7485.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Tue, 1 Apr 2014 14:36:30 -0700 From: Bill Mills To: Barry Leiba In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-1881523314-1396388190=:7485" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 388193000 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VTup33OJy2RPPCsCnTLysh5xMHI Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:37:23 -0000 ---1088529044-1881523314-1396388190=:7485 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=0AAs I have said, my only objection to splitting the draft would be if = the current RRVS header specification becomes other than standards track.= =0A=0A=0AIf this is split will both drafts be standards track?=0A=A0=0A-bil= l=0A=0A=0A=0A--------------------------------=0AWilliam J. Mills=0A"Paranoi= d" MUX Yahoo!=0A=0A=0AOn Tuesday, April 1, 2014 1:20 PM, Barry Leiba wrote:=0A =0A> The impetus for RRVS was the FUD and com= motion around a public=0A> announcement on account recycling for more desir= able names.=0A>=0A> Yes, it's an old old problem that no one had been force= d to solve=0A> previously.=A0 It's a problem that has changed in scope and = user impact as=0A> accounts and identities become more linked and valuable.= =0A=0AIndeed, but here:=0AThis is exactly why Pete and I are pushing on thi= s.=A0 Read what you say=0Aabove and think about where it might go in the fu= ture, as awareness of=0Arisks and exposures becomes greater, and fear (whet= her it's real or=0AFUD) increases.=0A=0AIt's easy to say that all we need *= today* is a best-effort solution,=0Asomething that's better than nothing.= =A0 What happens when the problem=0Acontinues to change in scope and user i= mpact, and accounts and=0Aidentities become even more linked and more valua= ble?=A0 When we need=0Asomething more robust than "please try, but it's not= a big deal".=0A=0AWouldn't it be best to (1) document what's better than n= othing, and=0A(2) prepare a more robust standard?=0A=0A=0ABarry ---1088529044-1881523314-1396388190=:7485 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As I have said, my only objection to spl= itting the draft would be if the current RRVS header specification becomes = other than standards track.

If this is split will = both drafts be standards track?
 
-bill


=
-----= ---------------------------
William J. Mills
"Paranoid" MUX Yahoo!

On Tuesday, April 1,= 2014 1:20 PM, Barry Leiba <barryleiba@computer.org> wrote:
> The impetus for RRVS was the= FUD and commotion around a public
> announcement on a= ccount recycling for more desirable names.
>
> Yes, it's an old old problem that no one had been forced to = solve
> previously.  It's a problem that has chan= ged in scope and user impact as
> accounts and identit= ies become more linked and valuable.

I= ndeed, but here:
This is exactly why Pete and I are pushi= ng on this.  Read what you say
above and think about= where it might go in the future, as awareness of
risks and exposures becomes = greater, and fear (whether it's real or
FUD) increases.
It's easy to say that all we need *toda= y* is a best-effort solution,
something that's better tha= n nothing.  What happens when the problem
continues = to change in scope and user impact, and accounts and
iden= tities become even more linked and more valuable?  When we need
something more robust than "please try, but it's not a big deal= ".

Wouldn't it be best to (1) document= what's better than nothing, and
(2) prepare a more robus= t standard?


Barry


<= /div>
---1088529044-1881523314-1396388190=:7485-- From nobody Tue Apr 1 14:39:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D141A0A27 for ; Tue, 1 Apr 2014 14:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XQVRiuW6GO6 for ; Tue, 1 Apr 2014 14:39:27 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5B11A0A1E for ; Tue, 1 Apr 2014 14:39:27 -0700 (PDT) Received: (qmail 38196 invoked from network); 1 Apr 2014 21:39:23 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Apr 2014 21:39:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=533b320b.xn--btvx9d.k1404; i=johnl@user.iecc.com; bh=QOoylMlo47hW9k0QpCcg5dgjf63BNb9mmG8tGb+uXmU=; b=Ix/KJjYXhGGP4DMxbkdZxRxKLmgBRheij8krrAC++aIkquHqn04XJwnl1BTS/2cJrq4wpA9521/JE2yYSYHFP+F45kWJknR318V0f9aAxwzwt4rtT1/Odg6r+xz50940tPDqhNSE7j+ho09ZItA8Fssp6BO/vStZvHDcS4LEOtdvNRX/G9OrXmY1ppMxC/04HVi+fyCEMLcApZ5EKC0/CK/qgVyIGbvCroe/TKtbqNs4WGNfa4Zm5vur1NS4RE27 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=533b320b.xn--btvx9d.k1404; bh=QOoylMlo47hW9k0QpCcg5dgjf63BNb9mmG8tGb+uXmU=; b=JP/mgGixxCHqM60JjLygYJyTQ1BG6LOnkgG7V0U7RHNamhX8JimcRcblJkSpKxNoDt28qpYvYVTrnCqbfcbK+RJ9VPdQMdrfoEHDyxt4iSp+FXY7hacMcy7JeWYDCwWrHj/hcAG2iaYhZuUXrwAV0ixHo5Pv3BHl03DklZ3S2EUD40y7bmcUCgTA97uC+soM1Z2isE07SZVJVfuo9DLLFwhWwbFi0AK1BvB4UfE0X2OX8zz4YruiDCXndyC3JpsO Date: 1 Apr 2014 21:39:01 -0000 Message-ID: <20140401213901.22203.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JhxMiaJMaH4x-KcFGT7HDUU3Yt0 Cc: barryleiba@computer.org Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:39:28 -0000 >Wouldn't it be best to (1) document what's better than nothing, and >(2) prepare a more robust standard? Yes, although I don't see the SMTP extension as interestingly more robust than the header. Account reuse is only one of many reasons that mail goes to someone other than the intended recipient. I still think we should do one standards track document with both the header and the SMTP extension, put in reasonable warnings about the limitations of both, and worry about the hopeless swamp of reliably identifying mail recipients later. R's, John From nobody Tue Apr 1 14:43:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6D81A0A20 for ; Tue, 1 Apr 2014 14:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izTpsHiE0Ubo for ; Tue, 1 Apr 2014 14:43:26 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id C6DE91A0A24 for ; Tue, 1 Apr 2014 14:43:25 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id a108so6265799qge.27 for ; Tue, 01 Apr 2014 14:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4KB5SrapVzxUNYeIW9wgu/9VEISiuwv9NUB1Xvznf4M=; b=CFP1Hw+WFq5SeJqeAJb1dTNhhyjMstzGmwXyXaF1gso3cD1hWmXpApscCnfmZvnAeG mRp07RYQc90kee8QTmFwsbWf4AthBgYf64QwvsnFd6mgMuBNrpCOxNFXk0wlg1B+mevA Z9TUDFGonfyaRAXHInGZH4iWfRGAgl6uPxXcfnN1Ig8XtoGuISYz5rpyXHS3Z46BRHiW 0nbki3GB9HWyW+oCOEezmksbuGD2+sKtdjuOQdfruojNBjkz5KACLlmh4KncLW4A87Hv qvgu5e9qLqGrO5NfH8724RjVW8wYgBCi9jrX8lP16q7uu7ySH8gwrDRkm9dHkrRbFo7k NVMQ== MIME-Version: 1.0 X-Received: by 10.224.30.147 with SMTP id u19mr19795066qac.49.1396388602027; Tue, 01 Apr 2014 14:43:22 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.140.94.165 with HTTP; Tue, 1 Apr 2014 14:43:21 -0700 (PDT) In-Reply-To: <20140401213901.22203.qmail@joyce.lan> References: <20140401213901.22203.qmail@joyce.lan> Date: Tue, 1 Apr 2014 17:43:21 -0400 X-Google-Sender-Auth: X8qQILa1G-FSE5i5ic1I6tqRq9w Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/I8YDZYOQfJt1U1Ko4APTfrpTNgk Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:43:27 -0000 On Tue, Apr 1, 2014 at 5:39 PM, John Levine wrote: > I still think we should do one standards track document with both the > header and the SMTP extension, put in reasonable warnings about the > limitations of both, and worry about the hopeless swamp of reliably > identifying mail recipients later. Which is my proposal, if not my first preference, from my other message: > Perhaps the RRVS document should have a section that talks > about the advantages of the extension over the header field, the > realities of the header field over the extension, and the real > security limitations of both. Perhaps that section should say that if > guarantees are needed, neither of these does it, and senders should > consider S/MIME. But if a "do your best" request suffices, these > mechanism are useful. > > We could now ask what Pete would think about that. And so, putting Pete explicitly on the "to" line for this. (Pete, if you haven't already, you need to read at least the key messages in the thread to fully follow this.) Barry From nobody Tue Apr 1 15:12:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B648A1A0A29 for ; Tue, 1 Apr 2014 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_XsQLq9-9sI for ; Tue, 1 Apr 2014 15:12:34 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97C1A0A25 for ; Tue, 1 Apr 2014 15:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1396390350; x=1427926350; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OlXTyHYJuWIcbQMv+iklblWrP9ENLa1bS7lP4BF0mTI=; b=OE9BiLE9sJJqjk1J+MlMyc5BoSoIQOk//KSeJv4+HGbFxJue1MUvDxdG YDJ52z0iWi1mJNiMevbNCe16XwT1p21H/0OVDSLcTReX4Ko8esH4oAwhI S5Ags+kQXVu6zRptkNfbNudUkXdM07hcGxUgZ8a3GPxSFJ35fUh9eLLxN w=; X-IronPort-AV: E=McAfee;i="5400,1158,7395"; a="61326012" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 01 Apr 2014 15:12:30 -0700 X-IronPort-AV: E=Sophos;i="4.97,775,1389772800"; d="scan'208";a="708931835" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Apr 2014 15:12:27 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 15:12:25 -0700 Message-ID: <533B39C7.4090401@qti.qualcomm.com> Date: Tue, 1 Apr 2014 17:12:23 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20140401213901.22203.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/82dYI4kuGile4P8oqfJUZ3veFqg Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 22:12:36 -0000 Thanks for the heads-up. I don't follow apps-discuss on a daily basis and I have not read *any* of the thread so far. I will catch up, and respond as needed. pr On 4/1/14 4:43 PM, Barry Leiba wrote: > On Tue, Apr 1, 2014 at 5:39 PM, John Levine wrote: > >> I still think we should do one standards track document with both the >> header and the SMTP extension, put in reasonable warnings about the >> limitations of both, and worry about the hopeless swamp of reliably >> identifying mail recipients later. >> > Which is my proposal, if not my first preference, from my other message: > > >> Perhaps the RRVS document should have a section that talks >> about the advantages of the extension over the header field, the >> realities of the header field over the extension, and the real >> security limitations of both. Perhaps that section should say that if >> guarantees are needed, neither of these does it, and senders should >> consider S/MIME. But if a "do your best" request suffices, these >> mechanism are useful. >> >> We could now ask what Pete would think about that. >> > And so, putting Pete explicitly on the "to" line for this. (Pete, if > you haven't already, you need to read at least the key messages in the > thread to fully follow this.) > > Barry > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Apr 1 18:15:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1221F1A004A; Tue, 1 Apr 2014 18:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_GENERIC=0.25, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kipqe2017PdE; Tue, 1 Apr 2014 18:15:03 -0700 (PDT) Received: from scspool01-14.scbb.aoyama.ac.jp (scspool01-14.scbb.aoyama.ac.jp [133.2.253.9]) by ietfa.amsl.com (Postfix) with ESMTP id A8B241A0051; Tue, 1 Apr 2014 18:15:02 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by scspool01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 49BBA32E768; Wed, 2 Apr 2014 10:14:57 +0900 (JST) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with SMTP id BDFBE32E557; Wed, 2 Apr 2014 10:14:56 +0900 (JST) Received: from (unknown [133.2.206.134]) by scmse01.scbb.aoyama.ac.jp with smtp id 4531_1fcb_3411907c_ba04_11e3_ac2e_001d096c566a; Wed, 02 Apr 2014 10:14:55 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 58007BF545; Wed, 2 Apr 2014 10:14:56 +0900 (JST) Message-ID: <533B6487.10700@it.aoyama.ac.jp> Date: Wed, 02 Apr 2014 10:14:47 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dave Thaler , Alexey Melnikov References: <5336F686.7060308@isode.com> <451cd52e77fb4baf9f736e063eb872ad@BY2PR03MB412.namprd03.prod.outlook.com> <63b3c4fad07742529b5ac4dfc0a0f306@DM2PR03MB414.namprd03.prod.outlook.com> In-Reply-To: <63b3c4fad07742529b5ac4dfc0a0f306@DM2PR03MB414.namprd03.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GnOs2hlwigSOBTAmQVHg9kTE4wo Cc: "uri-review@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] Registration request for smtp:// and submit:// URI schemes (draft-melnikov-smime-msa-to-mda-04) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 01:15:05 -0000 On 2014/04/02 02:33, Dave Thaler wrote: > Alexey Melnikov wrote: >>> My feedback is that the name "submit" is not a good name for the proposed >>> "smtpsubmit" or similar would be much more appropriate. >> >> I would rather use the same label as used by DNS SRV for the same service: >> "submission". (I think keeping them different would be a bad thing.). Thoughts? If the SRV service name is "submission", and the proposed scheme name is "submit", aren't these two *different* labels? > I didn't know about the SRV service type before this, but yes that sounds like a > reasonable goal. > > I'm thinking it would be good to add a sentence about this case > (service names and URI scheme names SHOULD be the same, when there exists > a 1:1 correspondence) to draft-ietf-appsawg-uri-scheme-reg. Does that > sound reasonable? Yes. I'm not sure it needs to be a SHOULD, something like "consider to make this the same as...". Regards, Martin. From nobody Tue Apr 1 19:12:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B041A007B for ; Tue, 1 Apr 2014 19:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.079 X-Spam-Level: X-Spam-Status: No, score=-101.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCqYS2DNlfMT for ; Tue, 1 Apr 2014 19:12:35 -0700 (PDT) Received: from ftp.catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4017B1A007A for ; Tue, 1 Apr 2014 19:12:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1479; t=1396404742; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=mmMYmVYypbnGvUrNbDqeh3L35uk=; b=P1wfOvGH9/ccsxg2pTZm clj9dDJA1u144xYM4VScEqeIAaqBrD66puoyYbeQ3NxT9RCATL8d9yaYeEok3PEF sgtTGvzRq6CJ20IQ43g0Xgu5WPB4z2tBlFzp+SNRkCTeA/UvxX3T/tN1QSrILbnS XD5RP8svn/jdDid0D1yGdG0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 01 Apr 2014 21:12:22 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1392200605.3.5824; Tue, 01 Apr 2014 21:12:21 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1479; t=1396404699; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ukMl/sD +x7FglhbYM1SSE3Tixd3qQaL4zPR8ulx4dFE=; b=fFetq0cHlwRMhaVbSwJ71dS ErnHALBrg4/WDlqDnDd8aVOPMd5KxeV+gjLtewb3hLJSVCoz2SipMJQ6OaaR5F2x arsNnrvIbLg7BwDjLhFFAyfIa1gCtp4vhqZ3pbh039pZLD8IYhHwZnYEY1Cgyc5M Wa1gXAzMtLFTVBt2Lobg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 01 Apr 2014 22:11:39 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 838455475.9.19736; Tue, 01 Apr 2014 22:11:38 -0400 Message-ID: <533B7205.5070806@isdg.net> Date: Tue, 01 Apr 2014 22:12:21 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Pete Resnick , Barry Leiba References: <20140401213901.22203.qmail@joyce.lan> <533B39C7.4090401@qti.qualcomm.com> In-Reply-To: <533B39C7.4090401@qti.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/s27sqUXOZzIR2JfjV2zz16ttHb8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 02:12:38 -0000 I can only hope you read other messages besides the so called "Key" ones. On 4/1/2014 6:12 PM, Pete Resnick wrote: > Thanks for the heads-up. I don't follow apps-discuss on a daily basis > and I have not read *any* of the thread so far. I will catch up, and > respond as needed. > > pr > > On 4/1/14 4:43 PM, Barry Leiba wrote: >> On Tue, Apr 1, 2014 at 5:39 PM, John Levine wrote: >>> I still think we should do one standards track document with both the >>> header and the SMTP extension, put in reasonable warnings about the >>> limitations of both, and worry about the hopeless swamp of reliably >>> identifying mail recipients later. >> Which is my proposal, if not my first preference, from my other >> message: >> >>> Perhaps the RRVS document should have a section that talks >>> about the advantages of the extension over the header field, the >>> realities of the header field over the extension, and the real >>> security limitations of both. Perhaps that section should say that if >>> guarantees are needed, neither of these does it, and senders should >>> consider S/MIME. But if a "do your best" request suffices, these >>> mechanism are useful. >>> >>> We could now ask what Pete would think about that. >> And so, putting Pete explicitly on the "to" line for this. (Pete, if >> you haven't already, you need to read at least the key messages in the >> thread to fully follow this.) >> >> Barry > -- HLS From nobody Tue Apr 1 21:13:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2B41A0109 for ; Tue, 1 Apr 2014 21:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE3CbU63xthB for ; Tue, 1 Apr 2014 21:13:36 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B85811A0108 for ; Tue, 1 Apr 2014 21:13:36 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.87.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AEDA422E200; Wed, 2 Apr 2014 00:13:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <69983fe672df44bdae174e1ec02059aa@BY2PR03MB412.namprd03.prod.outlook.com> Date: Wed, 2 Apr 2014 15:13:34 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <84C57FC1-8371-4F8A-85D5-B1EAFDA858A8@mnot.net> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> <9108BBA8-5FA3-4E52-816D-56E22BA3CA41@mnot.net> <69983fe672df44bdae174e1ec02059aa@BY2PR03MB412.namprd03.prod.outlook.com> To: Dave Thaler X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yzvKUmnozfCIdNOw1WTQxHEMc40 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 04:13:40 -0000 On 1 Apr 2014, at 7:36 am, Dave Thaler wrote: >>>> * Definition of Operations - I'd like to see us encourage (but >>>> probably not >>>> require) schemes to define a *default* operation for locators; the >>>> AWWW calls this "dereferencing" >>>> and it would be = nice >>>> to align the worldviews between the W3C and IETF here. It would = also >>>> be good if we encouraged such default methods to be "safe" -- that = is, not >> having surprising or undesired side effects, from the client's = standpoint. >>>=20 >>> Agreed, though I'm not sure what to say about "safe" (text = suggestions >> welcome). >>>=20 >>> Added this sentence: >>> Scheme definitions SHOULD define a "default" operation for when a = URI is >>> invoked (or "dereferenced") by an application. >>=20 >> See: >> = >=20 > I read that but am still having a hard time coming up with any generic = text, > since URIs may not apply to an "origin server" as in that reference. >=20 > As noted in the problem statement document, one of the most common = default > operations is essentially "launch the app associated with the scheme = name,=20 > and let it use the rest of the URI as arguments to do something". I think that can be accommodated by limiting the suggestion to URLs that = are for networked information. E.g., """ When a scheme can be used as a locator for information on a network, its = definition is encouraged to define a default operation for use when = "dereferencing" URLs that use that scheme, as per [AWWW]. When such a = default operation is defined, it SHOULD be safe; i.e., the client does = not request, and does not expect, any state change origin server as a = result of dereferencing the URI. """ -- Mark Nottingham http://www.mnot.net/ From nobody Tue Apr 1 23:05:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063F91A0140; Tue, 1 Apr 2014 23:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXhk2lLNvLkZ; Tue, 1 Apr 2014 23:05:06 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6681A0137; Tue, 1 Apr 2014 23:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1396418702; d=isode.com; s=selector; i=@isode.com; bh=Z/qqz05MavdacZXkFDe8jpJgfeqfx1jeUl4as3Vg/Ko=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=f5mzEtvbldX9O7Bh0VxfAoRTekgihQJ15VtmfkYbE4x3R2BH0h2smkFBjxCKJ2Ks9z431F xvbCxz1bk84vLq1n8OVAD8Le/A2vDB3QULP31TsMTeANaBjnvqE/SnnVfX0N81wFz8s+7P Kmb395dmtVtNJNp5EIYGI/ipBrp5atQ=; Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 2 Apr 2014 07:05:01 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (11B651) In-Reply-To: <533B6487.10700@it.aoyama.ac.jp> Date: Wed, 2 Apr 2014 07:10:10 +0100 Message-Id: <9D657332-EF6C-4B51-AF3F-899449EF7700@isode.com> References: <5336F686.7060308@isode.com> <451cd52e77fb4baf9f736e063eb872ad@BY2PR03MB412.namprd03.prod.outlook.com> <63b3c4fad07742529b5ac4dfc0a0f306@DM2PR03MB414.namprd03.prod.outlook.com> <533B6487.10700@it.aoyama.ac.jp> To: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/TNMtbTS6RNLLWFXkeNzyzCXpwr4 Cc: "uri-review@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] Registration request for smtp:// and submit:// URI schemes (draft-melnikov-smime-msa-to-mda-04) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 06:05:10 -0000 Hi Martin, > On 2 Apr 2014, at 02:14, "Martin J. D=C3=BCrst" w= rote: >=20 >> On 2014/04/02 02:33, Dave Thaler wrote: >> Alexey Melnikov wrote: >>>> My feedback is that the name "submit" is not a good name for the propos= ed >=20 >>>> "smtpsubmit" or similar would be much more appropriate. >>>=20 >>> I would rather use the same label as used by DNS SRV for the same servic= e: >>> "submission". (I think keeping them different would be a bad thing.). Th= oughts? >=20 > If the SRV service name is "submission", and the proposed scheme name is "= submit", aren't these two *different* labels? I am suggesting of making them the same. I thought they were... >=20 >> I didn't know about the SRV service type before this, but yes that sounds= like a >> reasonable goal. >>=20 >> I'm thinking it would be good to add a sentence about this case >> (service names and URI scheme names SHOULD be the same, when there exists= >> a 1:1 correspondence) to draft-ietf-appsawg-uri-scheme-reg. Does that >> sound reasonable? >=20 > Yes. I'm not sure it needs to be a SHOULD, something like "consider to mak= e this the same as...". From nobody Wed Apr 2 12:01:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A841A043C for ; Wed, 2 Apr 2014 12:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZDWIRrtB2Ty for ; Wed, 2 Apr 2014 12:00:54 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id B93DD1A03E4 for ; Wed, 2 Apr 2014 12:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1396465241; x=1428001241; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=dp3IxlurBXpj63asS925LigPNW21gYWZU8mYx8MD5fI=; b=XuiLLgKrRltjMUkWO7OIfFB4VGi6zDccbJNuyS9ngmJTOf95twJpErb2 0EHPUhTzw8J+r0lL0rsoBbNe60eO84nks6N2sb0aCmof+hCfPgicOhYmp sXer+aiRNxdgCFPCshI5FbEEZsQVbv4KnaQ9OYvnov3zsA7BtknSsGIyQ k=; X-IronPort-AV: E=McAfee;i="5400,1158,7396"; a="26201132" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 02 Apr 2014 12:00:40 -0700 X-IronPort-AV: E=Sophos;i="4.97,781,1389772800"; d="scan'208";a="642621964" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Apr 2014 12:00:24 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 12:00:24 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 12:00:24 -0700 Message-ID: <533C5E46.7040105@qti.qualcomm.com> Date: Wed, 2 Apr 2014 14:00:22 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <20140401213901.22203.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eVKEnIL-g4olTsuEkBAdSbPj3cA Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 19:01:00 -0000 So, I've read through the entire thread. Barry's reflected most of what I would have said. To summarize: - Yes, the document split and status change was just a suggestion of how to cleanly separate out the problems with the header, but there are plenty of other ways for the WG to choose to address my concerns. - That something happens to be deployed is not a reason in and of itself to standardize it. Document it, sure, if that's helpful to the world, but deployed *and* interoperable *and* it fulfills design goals are what you'd want for standardization. On that latter bit, as Barry said in response to Dave's comment: > 1. If it must not be delivered unless there is confirmation that it is > the 'correct' user of the address, then of course, use the SMTP > extension and reject the message if the extension fails or is not > implemented along the path. - If the current document actually specified rejection on failure, or gave a mechanism whereby the sender could request it, that would be peachy. It currently does not. It gives the receiving implementation the option to silently downgrade to the header and never again report whether the header was acted on or not. That seems problematic. - The above points to a lack of specificity in the document about what problem either mechanism intends to address. It *seems* like the SMTP mechanism, if it actually had the constraint above, addresses the *sender* wanting to not deliver the message if the addressee has changed. But the header mechanism seems to be addressing the *receiving site* not wanting to deliver the message if it gets additional information that the addressee has changed. Those seem like two very different models. If the document described: 1. the SMTP extension as a way to request that the message not get delivered if the addressee has changed and (optionally) bounce it if you can't tell, along with its security and privacy implications; and then described: 2. the header mechanism as something to use (a) to tunnel when you have knowledge that an intermediary or the receiving MDA is going to do something with; it or (b) when you just want to use a best-effort mechanism to not deliver messages when someone along the line cares to check it, and described the security and privacy implications of that (which are very different) that would be fine. But the current state of the document doesn't clearly state the very different uses and security/privacy considerations for the two mechanisms, and indeed seems to imply that the header mechanism is actually addressing the same issue that the SMTP mechanism is addressing, of the sender not wanting delivery if the address has changed. It does not interoperably do that. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Apr 2 12:13:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70FE1A03A4 for ; Wed, 2 Apr 2014 12:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5UhanDx-NJb for ; Wed, 2 Apr 2014 12:13:49 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 645131A0389 for ; Wed, 2 Apr 2014 12:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1396466025; x=1428002025; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=A/IZZglL9B56x+wfZ9E+EjTVRl/jxPk6umr0I4yVFxI=; b=KYrSpooAzXw0QqYzxCwZYxhHcpiK6nBuxFCo59GiJ7NflSJ1Mzaf46ys x4PN1zqPej2+ZyGJMDj2g4BdwSbCpxNO8ooc6cOnrc13jSIjDqRNOQMK4 LylCetJ2SS4trQjZ9objWSkY4w82VQDaYyJf3k3ckg+fK3EG2wyOQU6jG 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7396"; a="61380849" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 02 Apr 2014 12:13:45 -0700 X-IronPort-AV: E=Sophos;i="4.97,781,1389772800"; d="scan'208";a="28908503" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Apr 2014 12:13:45 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 12:13:44 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 12:13:44 -0700 Message-ID: <533C6167.4020004@qti.qualcomm.com> Date: Wed, 2 Apr 2014 14:13:43 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <5334A6C2.70500@dcrocker.net> <53359DA4.1080000@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/D0cEljq47bJNMAxCI5J2mP7Vvos Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] Splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 19:13:54 -0000 On 3/28/14 12:16 PM, Murray S. Kucherawy wrote: > The disparity between operational reality and architectural purity > leaves these decisions with a distinct Ivory Tower feeling. We appear > to be telling email operators, the folks in the trenches, that they've > been doing it wrong all these years, they can't have what they want, > they need go back and do it right. On this particular point: If a header field gets you what you want, that's great, and you should use it, and we should standardize it. However, if the header field has downsides, or doesn't fix the problem you think you're fixing, we should be honest about that in our documentation of it. If we're uninclined to document those downsides and misperceptions about what it might do, or they are pervasive enough that people will think they're getting something that they're not (cf. "DNT:"), we shouldn't call it a standard. I am not in the least interested in architectural purity. MIME was never architecturally pure and I'm a big fan of it. All I want is for us to be clear and honest about what we do and don't get out of a mechanism that we intend to standardize and write it all down. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Apr 2 16:48:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CD81A000F for ; Wed, 2 Apr 2014 16:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF2Z2a_3EgMH for ; Wed, 2 Apr 2014 16:48:27 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B80E31A0429 for ; Wed, 2 Apr 2014 16:48:26 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so998825wgh.28 for ; Wed, 02 Apr 2014 16:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ezIIDvzP9hfY812yowGskl5XAWkmleLP0QGP9RGMl8c=; b=xigtQ5CztCfaAGp95BHg2h1lOwPyO+d/tQ64qjNWZrM4klfb7pdKazDbJltip57dLY aIeusGl7zNrCRsrCh+i22abwMez8Bv202kFeowsDiEk4hR+IFevNZT3GcO+7lGcq+bnu 9qdHpquomLFq9LWtRkw/wEFMW5OPoq2YRgAujVKqSVWU8j7rPFwvs4H2McFb1S6F0MSP XdxLLEluXlhkzzvvci149wu0q4AnuKakhS0qpTqMs5s1kc4LNvq/VhA2QkBnhgEjWaIC fbN+WCHvN3VM4gtmqd6D/zE2dcUoMYzqrvJZXSdBMeX4yIzMdXSuXq9UT7GmaeQrWf3C LvoQ== MIME-Version: 1.0 X-Received: by 10.180.12.233 with SMTP id b9mr31961678wic.8.1396482502101; Wed, 02 Apr 2014 16:48:22 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Wed, 2 Apr 2014 16:48:21 -0700 (PDT) In-Reply-To: <533C5E46.7040105@qti.qualcomm.com> References: <20140401213901.22203.qmail@joyce.lan> <533C5E46.7040105@qti.qualcomm.com> Date: Wed, 2 Apr 2014 16:48:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c2411479139104f617eb3e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QgFDQm22piTWOtywARNxCCkudXg Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 23:48:32 -0000 --001a11c2411479139104f617eb3e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 2, 2014 at 12:00 PM, Pete Resnick wrote: > - If the current document actually specified rejection on failure, or gave > a mechanism whereby the sender could request it, that would be peachy. It > currently does not. It gives the receiving implementation the option to > silently downgrade to the header and never again report whether the header > was acted on or not. That seems problematic. > I suspect the prose that's there is predicated on various other policy-style extensions we've seen over the years (SPF, DKIM, ADSP, on and on) that are adamant about the fact that the sender cannot reasonably make a demand upon the receiver in terms of specifying a handling action. Perhaps this is one case where there really can't be a choice; if you're a receiver and you're implementing this, you're explicitly buying in to the notion that the sender knows what it's doing and it's willing to deal with the consequences of rejection, so you reject. If that's the case, I'm certainly happy to be more specific on the text in terms of what a receiver is supposed to do where the continuous ownership test fails. > > - The above points to a lack of specificity in the document about what > problem either mechanism intends to address. It *seems* like the SMTP > mechanism, if it actually had the constraint above, addresses the *sender* > wanting to not deliver the message if the addressee has changed. But the > header mechanism seems to be addressing the *receiving site* not wanting to > deliver the message if it gets additional information that the addressee > has changed. Those seem like two very different models. > No they definitely have the same intent, but simply have a different way to go about it. If there's ambiguity there, then that needs to be cleaned up. If the document described: > > 1. the SMTP extension as a way to request that the message not get > delivered if the addressee has changed and (optionally) bounce it if you > can't tell, along with its security and privacy implications; > Given the discussion, should we really have an ESMTP parameter that allows the sender to assert that the message should {continue, bounce} when a non-participating relay is encountered, perhaps defaulting to bounce, or should the action be normatively fixed? > and then described: > > 2. the header mechanism as something to use (a) to tunnel when you have > knowledge that an intermediary or the receiving MDA is going to do > something with; it or (b) when you just want to use a best-effort mechanism > to not deliver messages when someone along the line cares to check it, and > described the security and privacy implications of that (which are very > different) > I'm fine with that. I thought we were at least there with (a), and had implied (b), but being more explicit is fine with me too. > that would be fine. But the current state of the document doesn't clearly > state the very different uses and security/privacy considerations for the > two mechanisms, and indeed seems to imply that the header mechanism is > actually addressing the same issue that the SMTP mechanism is addressing, > of the sender not wanting delivery if the address has changed. It does not > interoperably do that. > What of your MUST NOT point about multiple recipients? It seems to me that if, in the header case, you're OK with allowing best-effort, then SHOULD NOT is adequate. Did you have any other specific issues? -MSK --001a11c2411479139104f617eb3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 2, 2014 at 12:00 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
- If the current document actually specified= rejection on failure, or gave a mechanism whereby the sender could request= it, that would be peachy. It currently does not. It gives the receiving im= plementation the option to silently downgrade to the header and never again= report whether the header was acted on or not. That seems problematic.

I suspect the prose that's there is pr= edicated on various other policy-style extensions we've seen over the y= ears (SPF, DKIM, ADSP, on and on) that are adamant about the fact that the = sender cannot reasonably make a demand upon the receiver in terms of specif= ying a handling action.=A0 Perhaps this is one case where there really can&= #39;t be a choice; if you're a receiver and you're implementing thi= s, you're explicitly buying in to the notion that the sender knows what= it's doing and it's willing to deal with the consequences of rejec= tion, so you reject.=A0 If that's the case, I'm certainly happy to = be more specific on the text in terms of what a receiver is supposed to do = where the continuous ownership test fails.
=A0

- The above points to a lack of specificity in the document about what prob= lem either mechanism intends to address. It *seems* like the SMTP mechanism= , if it actually had the constraint above, addresses the *sender* wanting t= o not deliver the message if the addressee has changed. But the header mech= anism seems to be addressing the *receiving site* not wanting to deliver th= e message if it gets additional information that the addressee has changed.= Those seem like two very different models.

No they definitely have the same intent, b= ut simply have a different way to go about it.=A0 If there's ambiguity = there, then that needs to be cleaned up.

If the document described:

1. the SMTP extension as a way to request that the message not get delivere= d if the addressee has changed and (optionally) bounce it if you can't = tell, along with its security and privacy implications;

Given the discussion, should we really have an ESMTP pa= rameter that allows the sender to assert that the message should {continue,= bounce} when a non-participating relay is encountered, perhaps defaulting = to bounce, or should the action be normatively fixed?
=A0
and then described:

2. the header mechanism as something to use (a) to tunnel when you have kno= wledge that an intermediary or the receiving MDA is going to do something w= ith; it or (b) when you just want to use a best-effort mechanism to not del= iver messages when someone along the line cares to check it, and described = the security and privacy implications of that (which are very different)

I'm fine with that.=A0 I thought we we= re at least there with (a), and had implied (b), but being more explicit is= fine with me too.
=A0
that would be fine. But the current state of the document doesn't clear= ly state the very different uses and security/privacy considerations for th= e two mechanisms, and indeed seems to imply that the header mechanism is ac= tually addressing the same issue that the SMTP mechanism is addressing, of = the sender not wanting delivery if the address has changed. It does not int= eroperably do that.

What of your MUST NOT point about multiple= recipients?=A0 It seems to me that if, in the header case, you're OK w= ith allowing best-effort, then SHOULD NOT is adequate.

Did you have any other specific issues?

-MSK

--001a11c2411479139104f617eb3e-- From nobody Wed Apr 2 19:24:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB6C1A0078 for ; Wed, 2 Apr 2014 19:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOwmLne2sZF7 for ; Wed, 2 Apr 2014 19:23:56 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA941A044F for ; Wed, 2 Apr 2014 19:23:56 -0700 (PDT) Received: (qmail 51032 invoked from network); 3 Apr 2014 02:23:50 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Apr 2014 02:23:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=533cc636.xn--yuvv84g.k1404; i=johnl@user.iecc.com; bh=MVQE7QGxVG6RZRlAI1R8jEQRg4RmaLm1STjVSIK3lt4=; b=YyainTJZmEIcP0dxM3ZuB1+V7cmrAboDyPjcM1KCfUo3NtDrQZ7eeOLBes2B4h2S/+B4ywnoVnLnC28wGENcJlDip+0X8X7kuHSg9ySXyrn1eqyZlXhBkh4WbJ4Ttfr2xummgppSJP9On7rNC7FD4C0xO5Qma1L5g/OGKUadAs4jqn5bBEMoF582tonwnUZpX/cwArbx2dywk/Twx5VdssyR2PWUPbBncinWCXmlgCPBO63Q+t8b3gum/OWumq0v DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=533cc636.xn--yuvv84g.k1404; bh=MVQE7QGxVG6RZRlAI1R8jEQRg4RmaLm1STjVSIK3lt4=; b=E9VuOU+ZSM06l/Swytkhztuz5xPlxoS6xhki4+k3Z7TB133PnXDezu6l0iw0zpROlBde0Lg94HeUA0ZnrCQv8ckE2ZHByEajowfxyOftYkLWE7GOpcrt7Wjy3uYU3zttYaGE9YfJnQJlHf7qdwcv1/CroWb9nbqOz8Xub+CIXHBxRuekWL6ejVt7TqXKee5cBPnqmtFfTNuuYu0sbFEtBm3n6UKrlsg6dsIXyBokHFlFYX5Bk564BYQNZwuo5exD Date: 3 Apr 2014 02:23:26 -0000 Message-ID: <20140403022326.67246.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7ZT5Ma-BUdLLYOJkK_Rra9Kbrjk Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 02:24:00 -0000 >Perhaps this is one case where there really can't be a choice; if you're a >receiver and you're implementing this, you're explicitly buying in to the >notion that the sender knows what it's doing and it's willing to deal with >the consequences of rejection, so you reject. Seems to me that it's in the tradition of SPF -all and ADSP discardable and DMARC p=reject. It's a little different in that it is hard to think of a plausible scenario in which RRVS would say to discard a good message, but I can still imagine a certain kind of mail system would accept the message anyway and display it with a warning "this message may not be for you." As I've been saying, my main concern about RRVS is that it only addresses one of a gazillion reasons that a message might be sent to the wrong person and I wouldn't want people to think of it as more than it is. It's a useful hack primarily for a small set of large public mail systems, so I think we should write it up along with its limitations, e.g., if you care about data leakage from the header, send separate copies of mail to separate recipients, and publish it as standards track, since people are using it, and we can help them to interoperate as best a limited hack like this can. R's, John From nobody Wed Apr 2 21:21:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836EC1A000B; Wed, 2 Apr 2014 21:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brJKwVx5EDjl; Wed, 2 Apr 2014 21:20:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6411A0020; Wed, 2 Apr 2014 21:20:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140403042055.12263.38029.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 21:20:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0Ol8Jvedfajm-9HBaPdF1mTW9bc Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 04:21:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : URI Design and Ownership Author : Mark Nottingham Filename : draft-ietf-appsawg-uri-get-off-my-lawn-02.txt Pages : 8 Date : 2014-04-02 Abstract: RFC3986 Section 3.1 defines URI syntax as "a federated and extensible naming system my further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing standards that mandate particular forms of URI substructure is inappropriate, because the effectively usurps ownership. This document is intended to prevent this practice (sometimes called "URI Squatting") in standards, but updating RFC3986 to indicate where it is acceptable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-get-off-my-lawn-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 3 02:22:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BD21A00DB for ; Thu, 3 Apr 2014 02:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9atdVwvUGd92 for ; Thu, 3 Apr 2014 02:22:09 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 806C31A0116 for ; Thu, 3 Apr 2014 02:22:09 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WVdqW-0000uS-gI; Thu, 03 Apr 2014 10:22:04 +0100 Received: from oerc-dynamic-219.oerc.ox.ac.uk ([129.67.194.219]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WVdqV-0003bF-6O; Thu, 03 Apr 2014 10:22:04 +0100 Message-ID: <533D27B1.3000708@ninebynine.org> Date: Thu, 03 Apr 2014 10:19:45 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <20140403042055.12263.38029.idtracker@ietfa.amsl.com> In-Reply-To: <20140403042055.12263.38029.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GjAbYytxfbMJM66nrFd8T_hrZ28 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 09:22:13 -0000 Hi, The abstract quote appears to be garbled. Section 2.2 "all other specifications MUST NOT constrain, define structure or semantics for URI authorities" appears to be at odds with section 1.,1 final para. This appears to prohibit a specification that assigns a part of, say, iana.org space form use as a registry, something allowed at 1.1. Maybe just add something like "except as allowed by section 1.1" or "except to the extent that a specification allocates elements of a URI space owned by the specification owner or publisher"? Hmmm... reading ahead, I see this might be a recurring issue. It's the "all other specifications" that tweaked by antennae here. The term "Applications" used in section 1.1 is one I find I can read in two different ways: - a specification for a general type of application, which is what I think you mean (e.g. webfinger). - a specification for a particular instance or limited deployment of some application, such as was previously specified for the use of HTTP in WEIRDS. (That in particular seems to be a boundary case whose status would usefully be clear in this proposal.) #g -- On 03/04/2014 05:20, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : URI Design and Ownership > Author : Mark Nottingham > Filename : draft-ietf-appsawg-uri-get-off-my-lawn-02.txt > Pages : 8 > Date : 2014-04-02 > > Abstract: > RFC3986 Section 3.1 defines URI syntax as "a federated and extensible > naming system my further restrict the syntax and semantics of > identifiers using that scheme." In other words, the structure of a > URI is defined by its scheme. While it is common for schemes to > further delegate their substructure to the URI's owner, publishing > standards that mandate particular forms of URI substructure is > inappropriate, because the effectively usurps ownership. > > This document is intended to prevent this practice (sometimes called > "URI Squatting") in standards, but updating RFC3986 to indicate where > it is acceptable. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-get-off-my-lawn-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Thu Apr 3 05:20:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E611A01F0 for ; Thu, 3 Apr 2014 05:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wpwau9HVPN7 for ; Thu, 3 Apr 2014 05:20:14 -0700 (PDT) Received: from ftp.catinthebox.net (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 64D071A01F6 for ; Thu, 3 Apr 2014 05:20:11 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4891; t=1396527605; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=HlDH1aa6AHzyO5dCUzQa1c7TMtk=; b=p5ElLse0yDY6iPSd47eK 5O8OkNUvCqQwcerKL0r8HkkwqbxctFcExK4aMmLMtFXkgnf1SxA5OxhmHGwt08gS T2rvGKfBhTarCKuw1OQdXpjZQp64PL7ld0nUBehYUCcJLVUrHlzICZt5ojzg5cKT FiChskqkrEDbUW73vVzxWzQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 03 Apr 2014 07:20:05 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1515062032.2604.664; Thu, 03 Apr 2014 07:20:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4891; t=1396527557; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=BIOcPvM U5S+O1q7yhPOfModZeY/8l+8d6oO06k/jnZ4=; b=IQj/fdRZqda9r3rr6r/4j4C y8r2H38ExGejcaUIMeelgdJwiN7k+i2TMswae7ppsKY8hTdJXig3p5k6i62uKeje 9CU6ymM96R2wAcCc01kBEcKr4KOxtURGz26Nx1G1yTihhzavBfGQGc4ysdF1PQO9 /ibwZr+JwjanTDmyvkiM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 03 Apr 2014 08:19:16 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 961312741.9.16948; Thu, 03 Apr 2014 08:19:16 -0400 Message-ID: <533D51F3.2030200@isdg.net> Date: Thu, 03 Apr 2014 08:20:03 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Pete Resnick , "apps-discuss@ietf.org" References: <20140401213901.22203.qmail@joyce.lan> <533C5E46.7040105@qti.qualcomm.com> In-Reply-To: <533C5E46.7040105@qti.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xHUcHuzO5C9cXOZ9hzOcLJoc0HA Subject: Re: [apps-discuss] Not splitting RRVS X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 12:20:19 -0000 Pete, This proposal is not just about rejection, but also about changing a Rejection into an Acceptance. Today, most of these potential applicable accounts are REJECTS because they are expired or just no longer used for some reason or another. It is proposing a method that would claims to allow some form of reactivation protection. It doesn't address the full repercussions that can come with reactivation. The new "owner" is now open to getting slammed with spam and unwanted mail. Many old accounts are so polluted with age, they get turned off or are highly filtered. It could introduce a new concept or solution where a system will add an option that would reactivate an email address WITH a RRVS only requirement. [X] Only Accept Mail from RRVS attributes as part of the target address. Or could also add logic such as: [X] Accounts MUST NOT get mail for 2 years before RRVS can apply. This is all part of what I am saying that it is still all half-baked. It is still an experiment and that application is wide, wide enough that it wouldn't be covered by the few big sites, specifically the two promoters; YAHOO and FACEBOOK. Their sheer public site size could mean it could apply to them with an acceptable risk, but this risk may not be acceptable across the board for most of the domain hosting applications. In principle, we are trying to "kludge" in a way to get a new identifier for users where the reactivated accounts would have a new assigned "user-id" bit/component to it, otherwise its the OLD account by default. In theory, although complex, it could allow for both old and new account users and persons to concurrently exist: user1@domain.com ---> mapped to old user: "Mary Jones" user1@domain.com RRVS=xxx ---> mapped to new new: "Bill Smith" All mail is accepted and moved to the specific user mail bins based on the RRVS identifier. This is still all an experiment to me. -- HLS On 4/2/2014 3:00 PM, Pete Resnick wrote: > So, I've read through the entire thread. Barry's reflected most of > what I would have said. To summarize: > > - Yes, the document split and status change was just a suggestion of > how to cleanly separate out the problems with the header, but there > are plenty of other ways for the WG to choose to address my concerns. > > - That something happens to be deployed is not a reason in and of > itself to standardize it. Document it, sure, if that's helpful to the > world, but deployed *and* interoperable *and* it fulfills design goals > are what you'd want for standardization. > > On that latter bit, as Barry said in response to Dave's comment: > >> 1. If it must not be delivered unless there is confirmation that it >> is the 'correct' user of the address, then of course, use the SMTP >> extension and reject the message if the extension fails or is not >> implemented along the path. > > - If the current document actually specified rejection on failure, or > gave a mechanism whereby the sender could request it, that would be > peachy. It currently does not. It gives the receiving implementation > the option to silently downgrade to the header and never again report > whether the header was acted on or not. That seems problematic. > > - The above points to a lack of specificity in the document about what > problem either mechanism intends to address. It *seems* like the SMTP > mechanism, if it actually had the constraint above, addresses the > *sender* wanting to not deliver the message if the addressee has > changed. But the header mechanism seems to be addressing the > *receiving site* not wanting to deliver the message if it gets > additional information that the addressee has changed. Those seem like > two very different models. > > If the document described: > > 1. the SMTP extension as a way to request that the message not get > delivered if the addressee has changed and (optionally) bounce it if > you can't tell, along with its security and privacy implications; > > and then described: > > 2. the header mechanism as something to use (a) to tunnel when you > have knowledge that an intermediary or the receiving MDA is going to > do something with; it or (b) when you just want to use a best-effort > mechanism to not deliver messages when someone along the line cares to > check it, and described the security and privacy implications of that > (which are very different) > > that would be fine. But the current state of the document doesn't > clearly state the very different uses and security/privacy > considerations for the two mechanisms, and indeed seems to imply that > the header mechanism is actually addressing the same issue that the > SMTP mechanism is addressing, of the sender not wanting delivery if > the address has changed. It does not interoperably do that. > > pr > From nobody Fri Apr 4 16:34:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265711A018A for ; Fri, 4 Apr 2014 16:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbmpG2qq-gMk for ; Fri, 4 Apr 2014 16:34:22 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 145B11A0184 for ; Fri, 4 Apr 2014 16:34:21 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so3832549qaq.10 for ; Fri, 04 Apr 2014 16:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=NJFj/hHevn4MrXzjOrXSG97Cy8VFwXts1CGiRGyJQzM=; b=kAEv9WftZsi6D7srIS9SIXQZCu0x2m+IgQGQZeZOPxPpluelsKWgosIr1dx3uHl4bv HwrFtCKUkqhi00ReJlLaq9UXfPxu5jZKtT1Fi2tU/476/lFz630+fnd2/0MQpnXkTcD8 11dny/S2lowYda/vTFZJ3Y0gHTIcTNe+qhVHjsEoGuQKZmoZ65k0F3R4Vy1X9gXr0tjI lLwMcwOHHgPJ2Vm2FjgL2iBnpLSElwXJejzpN416Tz6QOYfD8mbkqCs3f7HOlREXTyYP ZtWlaagC+YBsoYmSxSbi61RO4FQG2Vv0K9hK5pFNCT0Hvh0L87UzKhBcr2U3NLkek1Mn 0+7A== MIME-Version: 1.0 X-Received: by 10.229.112.5 with SMTP id u5mr17964501qcp.3.1396654457203; Fri, 04 Apr 2014 16:34:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.136.134 with HTTP; Fri, 4 Apr 2014 16:34:17 -0700 (PDT) In-Reply-To: <533F1EF4.40202@piuha.net> References: <533F1EF4.40202@piuha.net> Date: Fri, 4 Apr 2014 19:34:17 -0400 X-Google-Sender-Auth: BlaMr476cPSYHpQTuQogF1aGBz8 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tFsPY52_taiX4mGDVpnUYJ-nPm8 Subject: [apps-discuss] Fwd: New TLDs and software X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 23:34:26 -0000 I worked on Jari's recent IETF Chair blog post with him. The topic is particularly relevant to the Applications area, so I wanted to bring it to the attention of folks here. See Jari's note to the IETF list, below. Barry ---------- Forwarded message ---------- From: Jari Arkko Date: Fri, Apr 4, 2014 at 5:07 PM Subject: New TLDs and software To: ietf@ietf.org This is another blog post, a continuation of topics that came up in the ICANN meeting. The previous blog post was about the IANA discussions. But of course that was not the only topic that we talked about. The biggest project in the last couple of years at ICANN has been the introduction of new TLDs. Those are new finally coming online, and include both new ASCII-based names as well as many internationalized domain names. The latter are, of course, very important for the worldwide users of the Internet. But adding new TLDs is not just an administrative matter. In this blog article Barry and I wanted to highlight that there are some cases where software updates may be needed: http://www.ietf.org/blog/2014/04/new-tlds/ Jari & Barry From nobody Sat Apr 5 17:43:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F8B1A030F; Fri, 4 Apr 2014 18:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrB_3a9yPmz7; Fri, 4 Apr 2014 18:10:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BC7B61A0035; Fri, 4 Apr 2014 18:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1284; q=dns/txt; s=iport; t=1396660226; x=1397869826; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kPcPWBMaYgkSSdUg+qa1uLmg6YtaMkFKqIjtAWmxbKk=; b=k02OD54QsgQY+JSJtZsn4VQLYyaOwru3WzLk28gvifAMvvOp3xjzh1ic WEPRBadrCTp5fFCP45vvivJQhbf8kgS4+oDcPwIha/6qcX7Gy3RPCxDRv NU2YKD7Hq2oECmeKvOsC/0aEEkV06UAmwQInm/mBk/scUy7ia6oMbo1qA Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAP5WP1OtJV2Z/2dsb2JhbABPCoMGgRLEEIEjFnSCJQEBAQMBeQULAgEIRjIlAgQOBQ6HYwjQJReOFVwHgySBFAEDkF+BNYZHkj+DMIIr X-IronPort-AV: E=Sophos;i="4.97,798,1389744000"; d="asc'?scan'208";a="315215420" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 05 Apr 2014 01:10:25 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s351APYv031584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Apr 2014 01:10:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 20:10:25 -0500 From: "Fred Baker (fred)" To: "Eggert, Lars" Thread-Topic: AD sponsoring draft-masotta-tftpexts-windowsize-opt-09 Thread-Index: AQHPUGvSyTebJDq+aE+hBuuPkglZLw== Date: Sat, 5 Apr 2014 01:10:24 +0000 Message-ID: References: <53222FC1.7040009@bogus.com> <769950FD-3E19-41E8-8698-B31A45F57657@netapp.com> In-Reply-To: <769950FD-3E19-41E8-8698-B31A45F57657@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_FBF46E44-B49A-4CE6-8EF7-F9FF18F71838"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5dJcB0mDTnIui6SPBkzgQ7Zg_MY X-Mailman-Approved-At: Sat, 05 Apr 2014 17:43:18 -0700 Cc: "tsv-area@ietf.org" , "apps-discuss@ietf.org" , Martin Stiemerling Subject: Re: [apps-discuss] AD sponsoring draft-masotta-tftpexts-windowsize-opt-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 01:10:35 -0000 --Apple-Mail=_FBF46E44-B49A-4CE6-8EF7-F9FF18F71838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 13, 2014, at 11:50 PM, Eggert, Lars wrote: > have there been any substantive changes addressing the lack of = congestion control? If I recall correctly, that was the critical issue = in the past. (The diff at the URL below doesn't seem to do that.) The draft refers to RFC 5405, and indicates that while the specification = doesn=92t identify an upper bound on loss, any given implementation = should. For a single-packet-outstanding protocol, what would you like to see in = congestion control? At most, I could imagine a comment on exponential = backoff... --Apple-Mail=_FBF46E44-B49A-4CE6-8EF7-F9FF18F71838 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTP1f+bjEdbHIsm0MRArwcAJ9T7Ax56+oAFP7X9OGLR3kikXFw8gCg7w1t izBr0BT5oUmJR0sP8ERLmhA= =0r4W -----END PGP SIGNATURE----- --Apple-Mail=_FBF46E44-B49A-4CE6-8EF7-F9FF18F71838-- From nobody Sat Apr 5 17:43:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C151A038C; Sat, 5 Apr 2014 01:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYVorR1LlBco; Sat, 5 Apr 2014 01:25:30 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B148A1A0384; Sat, 5 Apr 2014 01:25:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,799,1389772800"; d="asc'?scan'208";a="81050361" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx2-out.netapp.com with ESMTP; 05 Apr 2014 01:25:25 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Sat, 5 Apr 2014 01:25:24 -0700 From: "Eggert, Lars" To: "Fred Baker (fred)" Thread-Topic: AD sponsoring draft-masotta-tftpexts-windowsize-opt-09 Thread-Index: AQHPPwrgG9TCO+0oCkqdjEnmNpnX/5rgmrEAgCI0NgCAAHmJgA== Date: Sat, 5 Apr 2014 08:25:23 +0000 Message-ID: <06D7466E-D63A-4630-8A35-3621DD16710C@netapp.com> References: <53222FC1.7040009@bogus.com> <769950FD-3E19-41E8-8698-B31A45F57657@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.21] Content-Type: multipart/signed; boundary="Apple-Mail=_35B1F886-0E05-46EA-8540-D5648EEBCFC5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fTijfah7UihZ9gRHGCpavmPUM1k X-Mailman-Approved-At: Sat, 05 Apr 2014 17:43:33 -0700 Cc: "tsv-area@ietf.org" , "apps-discuss@ietf.org" , Martin Stiemerling Subject: Re: [apps-discuss] AD sponsoring draft-masotta-tftpexts-windowsize-opt-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 08:25:35 -0000 --Apple-Mail=_35B1F886-0E05-46EA-8540-D5648EEBCFC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2014-4-5, at 3:10, Fred Baker (fred) wrote: > For a single-packet-outstanding protocol, what would you like to see = in congestion control? At most, I could imagine a comment on exponential = backoff... This extension takes TFTP way beyond "single-packet outstanding". That's = what all the concern is about. Lars --Apple-Mail=_35B1F886-0E05-46EA-8540-D5648EEBCFC5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUz+989ZcnpRveo1xAQJkEAP/S7Tfv0Bcy3HBcb535Iu162CWWylFOEHi lRU0maPlB9/uc2cghgUr4kmzMSLOcIz6VCXiMUcMRmC6kn4QrhnKky7xzMquU2iU JjSf2EJJ4MbuycxpG1Qbms+htn+Vok+cVbUx6tRNn4MBB9f7XOt5W3trpWFAqXEk 29/9loDNXmU= =1AUZ -----END PGP SIGNATURE----- --Apple-Mail=_35B1F886-0E05-46EA-8540-D5648EEBCFC5-- From nobody Sun Apr 6 22:20:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0DF1A03A8; Sun, 6 Apr 2014 22:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz630P-qX42T; Sun, 6 Apr 2014 22:20:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA341A0674; Sun, 6 Apr 2014 22:20:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407052012.24449.89366.idtracker@ietfa.amsl.com> Date: Sun, 06 Apr 2014 22:20:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GzGynwR9azfkDCooUNULjkeo0C4 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 05:20:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : URI Design and Ownership Author : Mark Nottingham Filename : draft-ietf-appsawg-uri-get-off-my-lawn-03.txt Pages : 8 Date : 2014-04-06 Abstract: RFC3986 Section 1.1.1 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because the essentially usurps ownership. This document clarifies both this problematic practice and some acceptable alternatives in standards. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-get-off-my-lawn-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 6 22:21:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221D61A0676 for ; Sun, 6 Apr 2014 22:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvDN_fEK0TsH for ; Sun, 6 Apr 2014 22:21:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) by ietfa.amsl.com (Postfix) with ESMTP id 71E8F1A0679 for ; Sun, 6 Apr 2014 22:21:17 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 05:21:11 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0908.008; Mon, 7 Apr 2014 05:21:11 +0000 From: Larry Masinter To: Dave Thaler , Mark Nottingham Thread-Topic: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt Thread-Index: AQHPKcExH9lH0aNS6EezCpeO9l6TLJq1S01ggAAFZJCAA6o7gIA+iciAgAH5QICAAnBfgIAJ+ayw Date: Mon, 7 Apr 2014 05:21:10 +0000 Message-ID: <5e700f14493842f1b4ced06a430cc09e@BL2PR02MB307.namprd02.prod.outlook.com> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> <9108BBA8-5FA3-4E52-816D-56E22BA3CA41@mnot.net> <69983fe672df44bdae174e1ec02059aa@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: <69983fe672df44bdae174e1ec02059aa@BY2PR03MB412.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 0174BD4BDA x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(51704005)(81686001)(81816001)(80976001)(74502001)(46102001)(2656002)(98676001)(69226001)(97336001)(53806001)(74876001)(85306002)(31966008)(83322001)(74662001)(87936001)(4396001)(47736001)(47976001)(87266001)(83072002)(99396002)(85852003)(81342001)(93136001)(90146001)(95666003)(56816005)(95416001)(80022001)(94316002)(33646001)(54356001)(74366001)(76796001)(76786001)(77982001)(76576001)(65816001)(47446002)(86362001)(50986001)(76482001)(74316001)(49866001)(56776001)(66066001)(63696002)(94946001)(20776003)(93516002)(54316002)(79102001)(92566001)(81542001)(59766001)(74706001)(97186001)(1511001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:F83FF1E4.87F790D1.69F1994B.8AE9F181.2037C; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8dzXxdQOGCV9OMkdm86MQRlvog0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 05:21:23 -0000 Mark and Dave changed ""discourage use of the same scheme name for differen= t purposes" to "Discourage use of the same scheme name for different mechanis= ms (often, but not always, protocols)." But personally, I think the old text is better. The whole sentence is in th= e context of just explaining why the rules are the way they are, and whethe= r or not two uses are "the same" is a matter of judgment, and the fact that= scheme names aren't exactly protocol names is irrelevant. If you want to = note the relation between scheme names and protocols, put it in a separate = paragraph. "...the first part of a URI is not an artistic indicator..." suggested drop= ping "artistic". But I think dropping "artistic" weakens the intent, which = is to discourage use of "://" as a design pattern "URL's should have colon-= slash-slash so people will recognize it as a URL". You could change "artis= tic" to "stylistic". URLs are both protocol elements and presentational el= ements, but the syntax should be functional. > > This is straight from RFC 4395. It says they [non-hierarchical scheme= s] SHOULD avoid both "/" and dot-segments. > > So if you avoid dot-segments, you don't need to tell what delimits them= from other stuff. > Right. I just find it odd that we SHOULD-prohibit the string ".." in a UR= I scheme > where it can't be mistaken for a relative reference (because there are no= "/"). >=20 > I.e., avoiding one of them, not both, is sufficient to prevent being mist= aken for a > relative reference, so why are we overly restrictive here? > Added this as an open issue (added cref into doc, and filed ticket #26). =20 If the scheme isn't actually hierarchical, but gets set as a "base" (as can= happen), then you can get nonsense out of relative processing in a way th= at might be confusing. =20 # As noted in the problem statement document, one of the most common defaul= t # operations is essentially "launch the app associated with the scheme name= ,=20 # and let it use the rest of the URI as arguments to do something". This is a good way of saying it. You might also note "Consider defining a MIME type instead" in such cases. > Actually, Section 3 should probably be entitled "Requirements for ..." no= t > "Guidelines for..." since its second. sentence says they're REQUIRED. They're guidelines that include requirements as well as other advice.=20 From nobody Sun Apr 6 23:24:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF901A02DD for ; Sun, 6 Apr 2014 23:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ED1HVWF7g-9 for ; Sun, 6 Apr 2014 23:23:55 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2FB1A02CC for ; Sun, 6 Apr 2014 23:23:55 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.14.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7AC64509B5; Mon, 7 Apr 2014 02:23:47 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <533D27B1.3000708@ninebynine.org> Date: Mon, 7 Apr 2014 16:23:54 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <52B8B2A5-F6BE-442C-875E-BEBAE7062D16@mnot.net> References: <20140403042055.12263.38029.idtracker@ietfa.amsl.com> <533D27B1.3000708@ninebynine.org> To: Graham Klyne X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DOWTZZpleHgPx9bV1QjuBydlbE4 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 06:24:00 -0000 On 3 Apr 2014, at 8:19 pm, Graham Klyne wrote: > Section 2.2 >=20 > "all other specifications MUST NOT constrain, define structure or = semantics for URI authorities" appears to be at odds with section 1.,1 = final para. This appears to prohibit a specification that assigns a = part of, say, iana.org space form use as a registry, something allowed = at 1.1. Yes. The IANA loophole is a very small one; IANA effectively delegates = control of portions of its URI space to IETF specifications. That is not = common, obviously (and may be unique?). > Maybe just add something like "except as allowed by section 1.1" or = "except to the extent that a specification allocates elements of a URI = space owned by the specification owner or publisher"? I think that will cause more confusion than it resolves; the second = proposal in particular could be misunderstood. > Hmmm... reading ahead, I see this might be a recurring issue. It's = the "all other specifications" that tweaked by antennae here. >=20 > The term "Applications" used in section 1.1 is one I find I can read = in two different ways: > - a specification for a general type of application, which is what I = think you mean (e.g. webfinger). > - a specification for a particular instance or limited deployment of = some application, such as was previously specified for the use of HTTP = in WEIRDS. (That in particular seems to be a boundary case whose status = would usefully be clear in this proposal.) Both are in-scope here. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 7 03:49:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204841A0130; Mon, 7 Apr 2014 03:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hu0VQdpsBSTQ; Mon, 7 Apr 2014 03:49:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DF21A0668; Mon, 7 Apr 2014 03:48:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407104858.22932.45111.idtracker@ietfa.amsl.com> Date: Mon, 07 Apr 2014 03:48:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YWWwuOJc8jDuXeFPyXq3geGksfc Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 10:49:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : XML Media Types Authors : Henry S. Thompson Chris Lilley Filename : draft-ietf-appsawg-xml-mediatypes-10.txt Pages : 34 Date : 2014-04-07 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-xml-mediatypes-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 7 03:57:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098641A0668; Mon, 7 Apr 2014 03:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFkSjXL2kKoe; Mon, 7 Apr 2014 03:57:32 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id A06AA1A03B7; Mon, 7 Apr 2014 03:57:32 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s37AvPuS015611; Mon, 7 Apr 2014 11:57:25 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s37AvNfI028871; Mon, 7 Apr 2014 11:57:23 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s37AvP34001361; Mon, 7 Apr 2014 11:57:25 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s37AvPOh001357; Mon, 7 Apr 2014 11:57:25 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: internet-drafts@ietf.org References: <20140407104858.22932.45111.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 07 Apr 2014 11:57:24 +0100 In-Reply-To: <20140407104858.22932.45111.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon\, 07 Apr 2014 03\:48\:58 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/K7MJNdva3jAqraDO3q-9I_YBocY Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 10:57:37 -0000 internet-drafts writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area > Working Group Working Group of the IETF. > > Title : XML Media Types > Authors : Henry S. Thompson > Chris Lilley > Filename : draft-ietf-appsawg-xml-mediatypes-10.txt This draft responds to IESG feedback, none of which required substantive changes. It is, I hope, very nearly the finished article. As usual, a clean diff is available at http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-10_diff.html and a Disposition of Comments, which shows all the comments received and explains what I did about them: http://www.w3.org/XML/2012/10/3023bis/iesg-comments.html ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Tue Apr 8 03:12:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F06D1A01CD for ; Tue, 8 Apr 2014 03:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzDdBh5tIgm6 for ; Tue, 8 Apr 2014 03:12:16 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id E87A61A01C8 for ; Tue, 8 Apr 2014 03:12:15 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WXT0g-0001zu-a3; Tue, 08 Apr 2014 11:12:06 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WXT0f-0008Nt-2f; Tue, 08 Apr 2014 11:12:06 +0100 Message-ID: <5343C547.3050204@ninebynine.org> Date: Tue, 08 Apr 2014 10:45:43 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V18GOhftTbIPl9QocN3oK7dAeaE Cc: drafts-expert-review-comment@iana.org, Nevil Brownlee Subject: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 10:12:20 -0000 All, TL;DR: should a permanent message header field registration be allowed through an ISE RFC publication, which does not require IETF review? ... An issue has come up concerning permanent registration of a message header field through an RFC independent stream editor (ISE) submission (https://tools.ietf.org/html/rfc6548). RFC 3864 says: [[ A Permanent Message Header Field Registry, intended for headers defined in IETF standards-track documents, those that have achieved a comparable level of community review, or are generally recognized to be in widespread use. ]] -- http://tools.ietf.org/html/rfc3864#section-2.1 But also: [[ A header registered in the Permanent Message Header Field Registry MUST be published as an RFC or as an "Open Standard" in the sense described by RFC 2026, section 7 [1], ]] -- http://tools.ietf.org/html/rfc3864#section-4.2.1 The latter quote appears to allow permanent registration following *any* RFC publication. Specifically, it appears to allow permanent registration following RFC publication through the RFC ISE stream, which does not require review within the IETF. As one of the original drafters of the registration specification, I claim this was not intended. At the time, (I think) I believed that independent submission RFCs were still subject to IETF,. or at least IESG, review. (I'm not sure if this is also true of my co-editors, so I'm speaking for myself here.) My expectation was that a permanent header field registration could be achieved through an IETF-reviewed informational RFC, as well as a standards-track RFC. This flexibility was used, for example, to grandfather entries into the permanent registry in http://tools.ietf.org/html/rfc4229. (In my role as reviewer for IANA) I have received a request to accept a permanent registration from an ISE RFC submission that has not been reviewed in the IETF, and have pushed back. But the requester makes the reasonable point that the section 4.2.1 text noted above provides no explicit grounds for refusal of such a permanent registration. In the current case, I would like to see the registration request submitted for review on the designated mailing list (ietf-message-headers@lists.ietf.org) (per http://tools.ietf.org/html/rfc3864#section-4.3) and see what feedback it garners. Under the circumstances, I think I should ask you, the IETF community, whether it is reasonable to push back in circumstances which have come about due to what is effectively a drafting error. And, more generally, does this community feel that it should be allowable to create permanent header field registry entries without undergoing IETF review? RFC3864 also says: [[ The IESG is the final arbiter of any objection. ]] -- http://tools.ietf.org/html/rfc3864#section-4.4 So there is process scope to refuse a permanent registration, even if other conditions are met, if the IESG opines it should not be made. (For the avoidance of doubt, I accept ISE submissions are perfectly suitable mechanism for creating provisional registrations, it's just permanent registration I'm questioning here.) I welcome any thoughts and feedback. #g -- From nobody Tue Apr 8 05:43:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227291A0393 for ; Tue, 8 Apr 2014 05:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp6KudL2fnXD for ; Tue, 8 Apr 2014 05:42:58 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id EA3E41A038D for ; Tue, 8 Apr 2014 05:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1396960912; d=isode.com; s=selector; i=@isode.com; bh=MOiK2o6uKb3F3kUixOIfrWrSTrHyAIq/4K/YV6S6Z+U=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=pOX6nVQeLDdPr955UJTv2EbPNic4RiiRcSoSAZufcVxfDnaE7WwOVkV3Wchek3nMGz+5Vm 6l2Rk2olnmVaopD+N+zjDlzkY07FGyLiqtHcQmbOrKL5BXBe6UPp4+1Rxj/TDoI3CV4Ysr qknEcwCD0aX6+jo+qkGkUjzs0t2mxcE=; Received: from pagan.boolean.net ((unknown) [75.141.217.19]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 8 Apr 2014 13:41:51 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Kurt Zeilenga In-Reply-To: <5343C547.3050204@ninebynine.org> Date: Tue, 8 Apr 2014 05:41:42 -0700 Message-Id: <56A9E343-A29B-484A-BB4B-AFCD56CC7B9D@isode.com> References: <5343C547.3050204@ninebynine.org> To: Graham Klyne X-Mailer: Apple Mail (2.1877.7) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Apple-Mail=_611B2B2B-6581-489B-BCDA-8A7908B6BE04" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nyS4YHi71scj6kzPOQBFuzg0Noo Cc: drafts-expert-review-comment@iana.org, Nevil Brownlee , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 12:43:03 -0000 --Apple-Mail=_611B2B2B-6581-489B-BCDA-8A7908B6BE04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 8, 2014, at 2:45 AM, Graham Klyne wrote: > All, >=20 > TL;DR: should a permanent message header field registration be = allowed through an ISE RFC publication, which does not require IETF = review? >=20 > ... >=20 > An issue has come up concerning permanent registration of a message = header field through an RFC independent stream editor (ISE) submission = (https://tools.ietf.org/html/rfc6548). >=20 > RFC 3864 says: > [[ > A Permanent Message Header Field Registry, intended for headers > defined in IETF standards-track documents, those that have > achieved a comparable level of community review, or are generally > recognized to be in widespread use. > ]] > -- http://tools.ietf.org/html/rfc3864#section-2.1 >=20 > But also: > [[ > A header registered in the Permanent Message Header Field Registry > MUST be published as an RFC or as an "Open Standard" in the sense > described by RFC 2026, section 7 [1], > ]] > -- http://tools.ietf.org/html/rfc3864#section-4.2.1 I note as well that BCP 90 says: Publication in an RFC or other form of Open Standard document (per RFC 2026 [1], section 7) is sufficient grounds for publication in the permanent registry. This text was changed by the IESG when it approved BCP 90. Namely the = IESG changed "IESG-approved RFC" to "RFC". See = . >=20 > The latter quote appears to allow permanent registration following = *any* RFC publication. Specifically, it appears to allow permanent = registration following RFC publication through the RFC ISE stream, which = does not require review within the IETF. As one of the original = drafters of the registration specification, I claim this was not = intended. At the time, (I think) I believed that independent submission = RFCs were still subject to IETF,. or at least IESG, review. (I'm not = sure if this is also true of my co-editors, so I'm speaking for myself = here.) Yes, what did the IETF or the IESG believe at the time the draft was = considered? One has to assume IETF participants and IESG members = reviewed the text as draft And I argue that it must be assumed that = specific changes they request the RFC Editor to make are made based upon = their consideration and deliberate action which, I think, effectively = moots drafting errors in the text submitted to them. > My expectation was that a permanent header field registration could be = achieved through an IETF-reviewed informational RFC, as well as a = standards-track RFC. > This flexibility was used, for example, to grandfather entries into = the permanent registry in http://tools.ietf.org/html/rfc4229. RFC 4229 being an independent submission is not an IETF-reviewed RFC = [BCP 26]: IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored (or WG) documents with an IETF Last Call. Examples: IPSECKEY Algorithm Types [RFC4025], Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake Hello Extensions [RFC4366]. If it is your intent to allow registrations specified in some = independent submissions but not others, some clear and concise = acceptance/non-acceptance criteria should be published in an update to = BCP 90. Can you propose clear and concise changes to BCP 90 which reflect what = you think the criteria should be? Please use BCP 26 terminology to the = extent possible. > Under the circumstances, I think I should ask you, the IETF community, = whether it is reasonable to push back in circumstances which have come = about due to what is effectively a drafting error. I note above, I think the so-called drafting error is moot. > And, more generally, does this community feel that it should be = allowable to create permanent header field registry entries without = undergoing IETF review? What about "open standards"? They aren't subject to IETF review = either. I think the criteria for acceptance/non-acceptance into any registry = should be made a clear as possible. While I think the term "IETF = review" (as defined by BCP 26) is reasonably clear, this is not what BCP = 90 says, nor would use of the term be consistent with what you seem to = want. I note also that IETF Review also allows IETF reviewed experimental RFC. I see the main problem here is that BCP 90 creates an "IETF endorsed" vs = "non-IETF endorsed" issue through this 4.2.2 text: Registration as a Provisional Message Header Field does not imply any kind of endorsement by the IETF, IANA or any other body. The problem is that same should, if open standards and ISEs are to be = allowed, ought to said for Permanent Registry as well. Consider RFC = 4229's registration. Given that RFC 4229 is an ISE, no IETF endorsement = is implied by the publication of the RFC. But BCP 90 text (in the = provisional registry) implies that it is endorsed by the IETF, and = that's simply not the case. If the indent of the registration split is "Endorsed" vs. = "Non-Endorsed", then the registries should be renamed, registration = policy should be IETF Review for "endorsed", and items not having IETF = Review (including non-IETF standards and ISEs) should be moved out of = the "endorsed" registry. But I argue that such a split serves little purpose and even = couter-productive. Those who care about the status of a spec should = not be looking at an IANA registry to tell them the status. I argue = that if any change to BCP 90 is to be made, we should do away with the = registry split. >=20 > RFC3864 also says: > [[ > The IESG is the final arbiter of any objection. > ]] > -- http://tools.ietf.org/html/rfc3864#section-4.4 >=20 > So there is process scope to refuse a permanent registration, even if = other conditions are met, if the IESG opines it should not be made. This text doesn't say anything about conditions for rejections. This = text simply means that the requestor has the right to appeal any = registration action to the IESG. Regards, Kurt= --Apple-Mail=_611B2B2B-6581-489B-BCDA-8A7908B6BE04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 8, 2014, at 2:45 AM, Graham = Klyne <GK@ninebynine.org> = wrote:

All,

TL;DR:  should a permanent message header = field registration be allowed through an ISE RFC publication, which does = not require IETF review?

...

An issue has come up = concerning permanent registration of a message header field through an = RFC independent stream editor (ISE) submission (https://tools.ietf.org/html/r= fc6548).

RFC 3864 says:
[[
A Permanent Message Header = Field Registry, intended for headers
defined in IETF standards-track = documents, those that have
achieved a comparable level of community = review, or are generally
recognized to be in widespread = use.
]]
-- http://tools.ietf.= org/html/rfc3864#section-2.1

But also:
[[
A header = registered in the Permanent Message Header Field Registry
MUST be = published as an RFC or as an "Open Standard" in the sense
described = by RFC 2026, section 7 [1],
]]
-- http://tools.iet= f.org/html/rfc3864#section-4.2.1

I = note as well that BCP 90 says:
   Publication in an RFC or other form of =
Open Standard document (per
   RFC 2026 [1], section 7) is =
sufficient grounds for publication in the
   permanent registry.

This text was changed by = the IESG when it approved BCP 90.  Namely the IESG changed = "IESG-approved RFC" to "RFC".   See  <https://datatra= cker.ietf.org/doc/rfc3864/writeup/>.


The latter quote appears to allow permanent = registration following *any* RFC publication.  Specifically, it = appears to allow permanent registration following RFC publication = through the RFC ISE stream, which does not require review within the = IETF.  As one of the original drafters of the registration = specification, I claim this was not intended.  At the time, (I = think) I believed that independent submission RFCs were still subject to = IETF,. or at least IESG, review.  (I'm not sure if this is also = true of my co-editors, so I'm speaking for myself = here.)

Yes, what did the IETF or the = IESG believe at the time the draft was considered?   One has to = assume IETF participants and IESG members reviewed the text as draft =  And I argue that it must be assumed that specific changes they = request the RFC Editor to make are made based upon their consideration = and deliberate action which, I think, effectively moots drafting errors = in the text submitted to them.

My expectation was that a permanent header field = registration could be achieved through an IETF-reviewed informational = RFC, as well as a standards-track = RFC.
This flexibility = was used, for example, to grandfather entries into the permanent = registry in http://tools.ietf.org/html/rfc= 4229.

RFC 4229 being an independent = submission is not an IETF-reviewed RFC [BCP = 26]:

      IETF Review - =
(Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only =
through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

            To ensure adequate community review, such documents are
            shepherded through the IESG as AD-sponsored (or WG)
            documents with an IETF Last Call.

            Examples: IPSECKEY Algorithm Types [RFC4025],
            Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
            Handshake Hello Extensions [RFC4366].

If it is your =
intent to allow registrations specified in some independent submissions =
but not others, some clear and concise acceptance/non-acceptance =
criteria should be published in an update to BCP =
90.

Can you propose clear and concise changes =
to BCP 90 which reflect what you think the criteria should be?  Please =
use BCP 26 terminology to the extent =
possible.


Under the circumstances, I think I should ask you, the = IETF community, whether it is reasonable to push back in circumstances = which have come about due to what is effectively a drafting = error.

I note above, I think the = so-called drafting error is = moot.

=  And, more generally, does this community feel that it should be = allowable to create permanent header field registry entries without = undergoing IETF review?

What about "open = standards"?   They aren't subject to IETF review = either.

I think the criteria for = acceptance/non-acceptance into any registry should be made a clear as = possible.  While I think the term "IETF review" (as defined by BCP = 26) is reasonably clear, this is not what BCP 90 says, nor would use of = the term be consistent with what you seem to = want.

I note also that IETF Review also allows = IETF reviewed experimental RFC.

I see the main = problem here is that BCP 90 creates an "IETF endorsed" vs "non-IETF = endorsed" issue through this 4.2.2 text:
  Registration as a Provisional Message = Header Field does not imply any
   kind of endorsement by the IETF, IANA or =
any other body.

The problem is that same = should, if open standards and ISEs are to be allowed, ought to said for = Permanent Registry as well.  Consider RFC 4229's registration. =  Given that RFC 4229 is an ISE, no IETF endorsement is implied by = the publication of the RFC.  But BCP 90 text (in the provisional = registry) implies that it is endorsed by the IETF, and that's simply not = the case.

If the indent of the registration = split is "Endorsed" vs. "Non-Endorsed", then the registries should be = renamed, registration policy should be IETF Review for "endorsed", and = items not having IETF Review (including non-IETF standards and ISEs) = should be moved out of the "endorsed" = registry.

But I argue that such a split serves = little purpose and even couter-productive.   Those who care about = the status of a spec should not be looking at an IANA registry to tell = them the status.  I argue that if any change to BCP 90 is to be = made, we should do away with the registry = split.


RFC3864 = also says:
[[
The IESG is the final arbiter of any = objection.
]]
-- http://tools.ietf.= org/html/rfc3864#section-4.4

So there is process scope to = refuse a permanent registration, even if other conditions are met, if = the IESG opines it should not be = made.

This text doesn't say anything = about conditions for rejections. This text simply means that the = requestor has the right to appeal any registration action to the = IESG.

Regards, Kurt
= --Apple-Mail=_611B2B2B-6581-489B-BCDA-8A7908B6BE04-- From nobody Tue Apr 8 05:51:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4528C1A03A0 for ; Tue, 8 Apr 2014 05:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSSvFtILF4Q5 for ; Tue, 8 Apr 2014 05:51:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id C5BEC1A03A4 for ; Tue, 8 Apr 2014 05:51:06 -0700 (PDT) Received: from netb ([178.14.117.65]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LhSfM-1XJiKY1YLQ-00mY4a; Tue, 08 Apr 2014 14:50:58 +0200 From: Bjoern Hoehrmann To: Graham Klyne Date: Tue, 08 Apr 2014 14:50:58 +0200 Message-ID: References: <5343C547.3050204@ninebynine.org> In-Reply-To: <5343C547.3050204@ninebynine.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:q7qJb6X2UHrR29d9jXKM74/mpwCwM5ayQwsWkSD74T3w/O6MmSY +meKDHvuaz66VXEuTiO0m7xvGPtgG+pB6Ld3/nwkbDh597KDKEEJ834SwMXgv/dlqCwDtTb lQ4K+MrBG9PMeoutm0t273NYLdd/fNMo0jXhispe2aqX5OBPiP/ifuMLXYWnkaZFUJTV4rJ 1GDmAGcWTJGeUO+e7Ut5w== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q_pdL3U-8MkYG2pGQwwctt5fT3Y Cc: drafts-expert-review-comment@iana.org, Nevil Brownlee , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 12:51:14 -0000 * Graham Klyne wrote: >TL;DR: should a permanent message header field registration be allowed through >an ISE RFC publication, which does not require IETF review? >The latter quote appears to allow permanent registration following *any* RFC >publication. Specifically, it appears to allow permanent registration following >RFC publication through the RFC ISE stream, which does not require review within >the IETF. As one of the original drafters of the registration specification, I >claim this was not intended. At the time, (I think) I believed that independent >submission RFCs were still subject to IETF,. or at least IESG, review. (I'm not >sure if this is also true of my co-editors, so I'm speaking for myself here.) I noticed this at the time and think it's quite plausible to require an RFC but not require IETF consensus, considering how low the bar is for "Open Standards" more generally. If there are problems with individual registrations I would expect the Designated Expert to push back on an individual basis; for instance, if someone tried to register all single letter HTTP header names, I would expect insistence on review by the HTTPBis Working Group and denial of the registration request if they're unhappy with the proposal, even if the registration procedures do not address such a case in detail; there is a reason a human is in charge. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Tue Apr 8 22:21:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5781A00C2 for ; Tue, 8 Apr 2014 22:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Egbeqq9nkXZJ for ; Tue, 8 Apr 2014 22:20:56 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 855491A00D8 for ; Tue, 8 Apr 2014 22:20:56 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so2551953wiv.0 for ; Tue, 08 Apr 2014 22:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UWjixsTTnsGxn9ep9UaxkVvMHAIyYjWm2qYM+5lwuLs=; b=KAV7V4KFQa8sjXrjsQW5+SU0782V4dPwr94YbxgvGOb3+3dhoVLrDMO8ll4Dd+Fqc1 v0kj8riJNLt7ZpgKCVg9ALEoL2UeAonSFaYfaaSNHD9/V8Et84YxNb+h6S+bpTXEiqKN S5U3rAmI7F8vB4SztaQ35gTRVFwsx1wZx/Mdmr5hYdwVp/xW0ntLe+rwyTN45vEFB3nv tora4UezsH9LNeEKCyf/klJ3CbsDX5mYz4lOUdEh0S12deZrhZHfPcss+/wP1A9QvCtE EjpDGQJB4KkW5RCN8qPt4vxh+H8BL5tJxRCBRsFT6rZvO9dgDb0hAWX5xRWkbCgaI5IR aBgA== MIME-Version: 1.0 X-Received: by 10.180.187.16 with SMTP id fo16mr35401901wic.26.1397020855788; Tue, 08 Apr 2014 22:20:55 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Tue, 8 Apr 2014 22:20:55 -0700 (PDT) Date: Tue, 8 Apr 2014 22:20:55 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c266c4da695a04f69543c9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/02kASWjXrNWFS4kEu3OkE2R1Uyc Subject: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 05:21:01 -0000 --001a11c266c4da695a04f69543c9 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, The IESG evaluation of the RRVS draft drew one major DISCUSS position from Pete Resnick. Bill and I have been talking to him about how to resolve them, and we have developed a number of edits as a result. These are largely editorial but still somewhat significant, and we also believe they are true to the original intent, so we don't imagine the working group will object to any of it. The proposed revision is at: http://www.blackops.org/~msk/draft-ietf-appsawg-rrvs-header-field.txt A diff to the last published version can be found at: http://www.blackops.org/~msk/rrvs-diff.html. Given that there are no protocol changes, we'll assume the WG is fine with them unless there's consensus otherwise. One point did come up upon which we are currently split, and we'd like the working group's opinion on how to proceed. Barry points out that we do not specify what a receiver should do in the case where RRVS is used by a client that hands a message to an MDA, but the MDA is unable to determine the result of the continuous ownership test. This is not a transient failure, mind you, but rather one where, for example, the receiving ADMD simply never recorded the mailbox creation date. It thus cannot ever answer the question. Should the receiver reject this message, or deliver it, or leave this to receiver discretion? Bill argues that the receiver MUST reject in this case; the goal is to protect the message against misdelivery, and it's not definitely safe to deliver it here. I'm not so sure; if we do that, then no RRVS-protected message will ever be delivered to that mailbox, and the protocol itself includes no means of notifying the receiving user that there's a problem. There's no way for this to get fixed unless the MDA's ADMD invents a creation time, which also isn't safe. What are the WG's thoughts here? -MSK --001a11c266c4da695a04f69543c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

The IESG eval= uation of the RRVS draft drew one major DISCUSS position from Pete Resnick.= =A0 Bill and I have been talking to him about how to resolve them, and we h= ave developed a number of edits as a result.=A0 These are largely editorial= but still somewhat significant, and we also believe they are true to the o= riginal intent, so we don't imagine the working group will object to an= y of it.

The proposed revision is at:
http://www.blackops.o= rg/~msk/draft-ietf-appsawg-rrvs-header-field.txt

A diff to the l= ast published version can be found at:
http://www.blackops= .org/~msk/rrvs-diff.html.

Given that there are no pro= tocol changes, we'll assume the WG is fine with them unless there's= consensus otherwise.

One point did come up upon which we are currently split, and we&#= 39;d like the working group's opinion on how to proceed.=A0 Barry point= s out that we do not specify what a receiver should do in the case where RR= VS is used by a client that hands a message to an MDA, but the MDA is unabl= e to determine the result of the continuous ownership test.=A0 This is not = a transient failure, mind you, but rather one where, for example, the recei= ving ADMD simply never recorded the mailbox creation date.=A0 It thus canno= t ever answer the question.=A0 Should the receiver reject this message, or = deliver it, or leave this to receiver discretion?

Bill argues that the receiver MUST reject in this case; the goal is to = protect the message against misdelivery, and it's not definitely safe t= o deliver it here.=A0 I'm not so sure; if we do that, then no RRVS-prot= ected message will ever be delivered to that mailbox, and the protocol itse= lf includes no means of notifying the receiving user that there's a pro= blem.=A0 There's no way for this to get fixed unless the MDA's ADMD= invents a creation time, which also isn't safe.

What are the WG's thoughts here?

-MSK
--001a11c266c4da695a04f69543c9-- From nobody Wed Apr 9 01:09:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BBA1A015F for ; Wed, 9 Apr 2014 01:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.914 X-Spam-Level: ** X-Spam-Status: No, score=2.914 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ANGI9En50O8 for ; Wed, 9 Apr 2014 01:09:18 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C97361A013F for ; Wed, 9 Apr 2014 01:09:18 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uy5so2310306obc.34 for ; Wed, 09 Apr 2014 01:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dbLrDOt49SCb33pKBDN/phjO3UNav4QKGqAFxha+qV4=; b=AROUh4wCgNWR19a5gf5GjKlRCw9SCxazH7BhAwqkdlkPC6on7QcJtwctsm3Ocq55EI BpXs8zOMg9pkbnkr8XQ7nuER73k01zc741VNQXzX8ccRvZ7ka3OLhveXlJPKKIHxsK8l KYnUaj1LMPwJmeOojppvT+CDhAPHoPWSrhML8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dbLrDOt49SCb33pKBDN/phjO3UNav4QKGqAFxha+qV4=; b=QgjOMaX8p/WCDUvpPRi/6Kj3/1uywDsqCoMy1q214Cndvw/88JXSm8G6l+3WQMhPRL IYfbKtxm37QJ75+IBB9VKH4h6jyIqInPz13wiuI8IbpYs2ScK81b7jTtMbxcn5i+1f54 hxi3hyKjgwWrCafByzyewPiuJ+DY1DNs9H9GW1sudCwhEqsF2m0TYpGK8pl87Z0raif7 SPGScgMLCg6eD9rBPtjPSkRr6AyXbaG+ybQJzL+IsQ4ooee3r2qBwqxSLMrdxohIsnWx 3Q9FAFDziWzs4NmY33Dzjl5jDX2iDtCSgV+/02JaFeLsZEhOY568duskXTFQl8RK0hAX MkeQ== X-Gm-Message-State: ALoCoQm7gfQ1NoeBx5C/Ja3WFebQiCofVlGfuQmPvwKJGKGimFH37LkdbjL9AwGFb3oPs8y4CPUr MIME-Version: 1.0 X-Received: by 10.60.142.229 with SMTP id rz5mr7496683oeb.1.1397030958306; Wed, 09 Apr 2014 01:09:18 -0700 (PDT) Received: by 10.60.93.6 with HTTP; Wed, 9 Apr 2014 01:09:18 -0700 (PDT) Received: by 10.60.93.6 with HTTP; Wed, 9 Apr 2014 01:09:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 09:09:18 +0100 Message-ID: From: Dave Cridland To: Murray Kucherawy Content-Type: multipart/alternative; boundary=047d7b414e6002ffb104f6979ede Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Lx8p1yFTF4k6TEffEn9ulNVhDrw Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 08:09:20 -0000 --047d7b414e6002ffb104f6979ede Content-Type: text/plain; charset=ISO-8859-1 On 9 Apr 2014 06:21, "Murray S. Kucherawy" wrote: > There's no way for this to get fixed unless the MDA's ADMD invents a creation time, which also isn't safe. Really? If you default the creation time to the earliest point in time that account creations were recorded, that's certainly safe. Any earlier is increasingly unsafe. Bill's suggestion is equivalent to the default creation time of now, but that has no advantage over setting it to the earliest time of recording. The problem for me is that if I send an email to an old contact, marking it with rrvs on my client, I'd want to know if the rejection were absolute, because an account is known to have been replaced, or by default because the time simply isn't known. Also, it means the best time to use is the latest. I'm on my mobile, so haven't checked if this is already the case in the draft. Dave. --047d7b414e6002ffb104f6979ede Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 9 Apr 2014 06:21, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>=A0 There's no way for this to get fixed unless the MDA's ADMD = invents a creation time, which also isn't safe.

Really? If you default the creation time to the earliest poi= nt in time that account creations were recorded, that's certainly safe.=

Any earlier is increasingly unsafe.

Bill's suggestion is equivalent to the default creation = time of now, but that has no advantage over setting it to the earliest time= of recording.

The problem for me is that if I send an email to an old cont= act, marking it with rrvs on my client, I'd want to know if the rejecti= on were absolute, because an account is known to have been replaced, or by = default because the time simply isn't known.

Also, it means the best time to use is the latest. I'm o= n my mobile, so haven't checked if this is already the case in the draf= t.

Dave.

--047d7b414e6002ffb104f6979ede-- From nobody Wed Apr 9 09:21:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206401A03A0 for ; Wed, 9 Apr 2014 09:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.827 X-Spam-Level: X-Spam-Status: No, score=-11.827 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, TVD_PH_BODY_ACCOUNTS_PRE=2.393, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oha-vKyjLZcc for ; Wed, 9 Apr 2014 09:21:20 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id 470041A0380 for ; Wed, 9 Apr 2014 09:21:20 -0700 (PDT) Received: from GQ1-EX10-CAHT13.y.corp.yahoo.com (gq1-ex10-caht13.corp.gq1.yahoo.com [10.73.119.194]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s39GKZpu074523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Apr 2014 09:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1397060435; bh=q1L92e8INM75ECn8FW8DSKDJ2HFwl2STjegglUxWdAA=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=oC7edYwkRMAyemwEg6m5NH+LMBxXv28ShcP/cIY2sdDWrGtZFEVft4u5S4dapQJWB L/iWhu3TPLKWmJIY9u3j9sjb0ldNywmb/EAL64YiM6BS8CUMIlHOoxT7TeQXkuRJrc KOUGize47VMhj4qIAGUj37rd4TLjY/fDfftyofa4= Received: from omp1088.mail.ne1.yahoo.com (98.138.101.177) by GQ1-EX10-CAHT13.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 9 Apr 2014 09:20:34 -0700 Received: (qmail 50632 invoked by uid 1000); 9 Apr 2014 16:20:33 -0000 Received: (qmail 22819 invoked by uid 60001); 9 Apr 2014 16:20:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1397060433; bh=zEXv8TrccWDnS+1PARwzwNB8U3wY11r8nxyHA80qqeA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LOKV4S7vqDFdMpPdd5ELSR4V4PDtXy2RMUJz0wQ6BvwWB05Gsk/tXFkZIgpS67idhTunR03TptksSZYX0c/62Z8iSLyJkrw6AiV21VffJkLNXP3LpDj2PN/gG3gTi+mUmlA3OCIIzMSxGAD0KvV2sjEehC3BbJk+9n/YedEtQIg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UiK/qSSZ3aKIiiJaLNFLCcO+8QMQRQdLdtTy6SrDzdnHJz2/tTflWQPdaC9eRIPQiRmVAKulelcbbg7pypSwoSxn6ewlEXwSkWQlKZvAdF8a2w448XDdcjmwy7GTR1t1EofO73MhSGwcYuH4/thJ8tAsqhcYg79/iQaAddZo3qY=; X-YMail-OSG: BHxzuZcVM1n5sTSMy8411QgBgcddI0si1o1ty1kzlNaEalF F7L9oLUbuXy5J92uMIwXiU09IFywGl5hbdNTYj.pv_OWOPelZdCiliirQQc7 tTeOWA.YmwdopOUJvO51pMhqgEZ8opygp7DO_mkyeOJ8hn3mytnkN4PQuZJN 3JciCtGGs4fvnNIUJBD_8hU3DLL4pKZCn1pQeL9VRO8QnMeRu3e_hKbqLDxj xCQo9fGhfQ9t1j9Do3MmQ0haPKcYB5JreK_8gm923KBNvzUXifZb1bNboxjc .oS9ozQln.V_FZo1SsOI- Received: from [66.228.162.56] by web125603.mail.ne1.yahoo.com via HTTP; Wed, 09 Apr 2014 09:20:33 PDT X-Rocket-MIMEInfo: 002.001, SW4gdGhlIGVuZCB0aGUgbG9jYWwgc2l0ZSBtYWtlcyB0aGUgZGVjaXNpb24sIHdoYXQgd2UncmUgZG9pbmcgaGVyZSBpcyBnaXZpbmcgZ3VpZGFuY2Ugd2hhdCB0aGUgc2l0ZSBzaG91bGQgZG8gaW4gbG9jYWwgcG9saWN5LsKgIAoKV2UgY291bGQgYWRkIGFuIGVycm9yIGNhc2UgYXMgd2VsbC7CoCBJJ2QgYmUgZmluZSB3aXRoIHRoYXQuwqAgSXQgZXhwb3NlcyB0aGF0IHRoZSBzaXRlIGRvZXNuJ3Qga25vdyB0aGUgYWdlIG9mIHRoZSBhY2NvdW50LCB3aGljaCBJIGNvbnNpZGVyIG1vcmUgdG8gYmUgYWJvdXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: Message-ID: <1397060433.18346.YahooMailNeo@web125603.mail.ne1.yahoo.com> Date: Wed, 9 Apr 2014 09:20:33 -0700 From: Bill Mills To: Dave Cridland , Murray Kucherawy In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="933233344-911171965-1397060433=:18346" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 060435003 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5d6uOApBhLPs0gZyLkQfZhT4JHk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:21:24 -0000 --933233344-911171965-1397060433=:18346 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the end the local site makes the decision, what we're doing here is givi= ng guidance what the site should do in local policy.=A0 =0A=0AWe could add = an error case as well.=A0 I'd be fine with that.=A0 It exposes that the sit= e doesn't know the age of the account, which I consider more to be about th= e site than the account.=A0 The sender then has the option to resend withou= t RRVS.=A0 =0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------=0A= William J. Mills=0A"Paranoid" MUX Yahoo!=0A=0A=0AOn Wednesday, April 9, 201= 4 1:09 AM, Dave Cridland wrote:=0A =0A=0AOn 9 Apr 2014 = 06:21, "Murray S. Kucherawy" wrote:=0A>=A0 There's no= way for this to get fixed unless the MDA's ADMD invents a creation time, w= hich also isn't safe.=0AReally? If you default the creation time to the ear= liest point in time that account creations were recorded, that's certainly = safe.=0AAny earlier is increasingly unsafe.=0ABill's suggestion is equivale= nt to the default creation time of now, but that has no advantage over sett= ing it to the earliest time of recording.=0AThe problem for me is that if I= send an email to an old contact, marking it with rrvs on my client, I'd wa= nt to know if the rejection were absolute, because an account is known to h= ave been replaced, or by default because the time simply isn't known.=0AAls= o, it means the best time to use is the latest. I'm on my mobile, so haven'= t checked if this is already the case in the draft.=0ADave.=0A=0A__________= _____________________________________=0Aapps-discuss mailing list=0Aapps-di= scuss@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/apps-discuss --933233344-911171965-1397060433=:18346 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In the en= d the local site makes the decision, what we're doing here is giving guidan= ce what the site should do in local policy. 

We could add an e= rror case as well.  I'd be fine with that.  It exposes that the s= ite doesn't know the age of the account, which I consider more to be about = the site than the account.  The sender then has the option to resend w= ithout RRVS. 
 
-bill


------------= --------------------
William J. Mills
"Paranoid" MUX Yahoo!
=

On Wednesday, April 9, 2014 1:09= AM, Dave Cridland <dave@cridland.net> wrote:

=0AOn 9 Apr 2014 06:21, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
=0A>  There's no way for this to get fixed unless the MDA's = ADMD invents a creation time, which also isn't safe.
=0A
Really? If you default the creation time to the earliest point in time t= hat account creations were recorded, that's certainly safe.
=0A
Any earlier is increasingly unsafe.
=0A
Bill= 's suggestion is equivalent to the default creation time of now, but that h= as no advantage over setting it to the earliest time of recording.
=0A=
The problem for me is that if I send an email to an old co= ntact, marking it with rrvs on my client, I'd want to know if the rejection= were absolute, because an account is known to have been replaced, or by de= fault because the time simply isn't known.
=0A=0A
Also= , it means the best time to use is the latest. I'm on my mobile, so haven't= checked if this is already the case in the draft.
=0A
Dave.

= _______________________________________________
apps-disc= uss mailing list
apps-discuss@ietf.= org
https://www.ietf.org/mailman= /listinfo/apps-discuss


<= /div>
--933233344-911171965-1397060433=:18346-- From nobody Wed Apr 9 09:53:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844681A03D8 for ; Wed, 9 Apr 2014 09:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwMluDCoRW4l for ; Wed, 9 Apr 2014 09:53:36 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A58291A032E for ; Wed, 9 Apr 2014 09:53:35 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so2793634wes.32 for ; Wed, 09 Apr 2014 09:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eexazq1joDML4U2t5VWo4YRg07K2E3oLwI9TzxqVE1k=; b=B5WbBaSUijDjY0vAORY4oNbanhZHMQxmfsgazkGouICStUjurF7AXoFsODKbqG4K70 mUmoJTdttZfpag+5RuG8sld1HVb267x7OhCd4bDHfODJWo4s/tosQ0QKqGZvMxUWImUY QB7+0gA0tDo6qSL8dWqXK6snRTUijDLHJkspTno2Tv6crOdMX6eRls/7ggVTGdMgjpq1 uZbXfxNUnWoBxU5tfgbMSwq+APGGU23a5VC4q6Om+hrW7/kM5NtFqxC4Hl9RI3gNDnNi P4MzttQHzqJUI2OCDuIKVv9GjWuCw4vGr3jZ4Kh+qi7GI/ehj5kD/IrRgzuCZJHtrpFC bxOQ== MIME-Version: 1.0 X-Received: by 10.180.12.233 with SMTP id b9mr37901518wic.8.1397062414707; Wed, 09 Apr 2014 09:53:34 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Wed, 9 Apr 2014 09:53:34 -0700 (PDT) In-Reply-To: <1397060433.18346.YahooMailNeo@web125603.mail.ne1.yahoo.com> References: <1397060433.18346.YahooMailNeo@web125603.mail.ne1.yahoo.com> Date: Wed, 9 Apr 2014 09:53:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: Bill Mills Content-Type: multipart/alternative; boundary=001a11c24114f531bb04f69ef009 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/z_iNqTXVeUu6a1PeROPxvHngDVY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:53:37 -0000 --001a11c24114f531bb04f69ef009 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 9, 2014 at 9:20 AM, Bill Mills wrote: > In the end the local site makes the decision, what we're doing here is > giving guidance what the site should do in local policy. > > But it's a local policy decision about the security of content they didn't create. Unlike things like DKIM and such, the protection is aimed at the sender, not the recipient. > We could add an error case as well. I'd be fine with that. It exposes > that the site doesn't know the age of the account, which I consider more to > be about the site than the account. The sender then has the option to > resend without RRVS. > > That's a possibility. What do others think? -MSK --001a11c24114f531bb04f69ef009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 9, 2014 at 9:20 AM, Bill Mills <wmills@yah= oo-inc.com> wrote:
In the end the local sit= e makes the decision, what we're doing here is giving guidance what the= site should do in local policy.=A0


But it's a local polic= y decision about the security of content they didn't create.=A0 Unlike = things like DKIM and such, the protection is aimed at the sender, not the r= ecipient.

=A0
We coul= d add an error case as well.=A0 I'd be fine with that.=A0 It exposes th= at the site doesn't know the age of the account, which I consider more = to be about the site than the account.=A0 The sender then has the option to= resend without RRVS.=A0
=A0

That's a pos= sibility.=A0 What do others think?

-MSK
--001a11c24114f531bb04f69ef009-- From nobody Wed Apr 9 09:56:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960981A03F7 for ; Wed, 9 Apr 2014 09:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.293 X-Spam-Level: ** X-Spam-Status: No, score=2.293 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YN0u-evLELJ for ; Wed, 9 Apr 2014 09:56:37 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB01A03F3 for ; Wed, 9 Apr 2014 09:56:36 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so9283830wiv.13 for ; Wed, 09 Apr 2014 09:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hDHrUwbqJ+uSf9sKpJOU3pEuNleaD3g0MaxhUjXGQs4=; b=MQ31o34ipnKiXGhNP/6360MR1f6QHelepKAHNmHFQByvfbXf1qSoAahpH8nPmZ7kDz YY3nvzY+z1n/aswpq3H91CP7HPSE7efAlNFd2Rc7OpFhYO6zc/AYt/GuyAG9woHXspds pPnIJCd7gsyqJ9IXrV8PO/cynvxXnK89x+73DPZAWStVyR+maNNDsJ7sRhV+61YSabPx KkVIZnqYymhKfKfpNT9beBYDqWD5NclsFLidlFWaksoM7tC7PseoGIa35frb3KLWCvf2 8VDJKQx/18bA4fnpu3s+B9flNnitOYnabyR2tacgEvGbHVZAoFw+36yOKZIeJ75pBgNK HsAw== MIME-Version: 1.0 X-Received: by 10.194.92.177 with SMTP id cn17mr10809633wjb.18.1397062595351; Wed, 09 Apr 2014 09:56:35 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Wed, 9 Apr 2014 09:56:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 09:56:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Cridland Content-Type: multipart/alternative; boundary=047d7beb91aab99e5404f69efbdb Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/egmbuvH9Vgin6oqCCcPwRNtcfhM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:56:41 -0000 --047d7beb91aab99e5404f69efbdb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 9, 2014 at 1:09 AM, Dave Cridland wrote: > > On 9 Apr 2014 06:21, "Murray S. Kucherawy" wrote: > > There's no way for this to get fixed unless the MDA's ADMD invents a > creation time, which also isn't safe. > > Really? If you default the creation time to the earliest point in time > that account creations were recorded, that's certainly safe. > Sure, that's possible. But what if you don't know what that timestamp was either? > Any earlier is increasingly unsafe. > > Bill's suggestion is equivalent to the default creation time of now, but > that has no advantage over setting it to the earliest time of recording. > > The problem for me is that if I send an email to an old contact, marking > it with rrvs on my client, I'd want to know if the rejection were absolute, > because an account is known to have been replaced, or by default because > the time simply isn't known. > So just to be clear, you're talking about two response codes for a mailbox, one that indicates "no" and one that indicates "not known"? > Also, it means the best time to use is the latest. I'm on my mobile, so > haven't checked if this is already the case in the draft. > It's not yet. This is the only outstanding issue. -MSK --047d7beb91aab99e5404f69efbdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 9, 2014 at 1:09 AM, Dave Cridland <dave@cridl= and.net> wrote:


On 9 Apr 2014 06:21, "Murray S. Kucherawy" <superuser@gmail.com> wrote: >=A0 There's no way for this to get fixed unless the MDA's ADMD = invents a creation time, which also isn't safe.

Really? If you default the creation time to the earlie= st point in time that account creations were recorded, that's certainly= safe.


Sure, that's possible.=A0 Bu= t what if you don't know what that timestamp was either?
=A0

Any earlier is increasingly unsafe.

Bill's suggestion is equivalent to the default creation = time of now, but that has no advantage over setting it to the earliest time= of recording.

The problem for me is that if I send an email to an old cont= act, marking it with rrvs on my client, I'd want to know if the rejecti= on were absolute, because an account is known to have been replaced, or by = default because the time simply isn't known.

So just to be clear, you're talking about two respons= e codes for a mailbox, one that indicates "no" and one that indic= ates "not known"?
=A0

Also, it means the best time to use is the latest. I'm o= n my mobile, so haven't checked if this is already the case in the draf= t.

It's not yet.=A0 This is the only outs= tanding issue.

-MSK
--047d7beb91aab99e5404f69efbdb-- From nobody Wed Apr 9 12:02:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714C51A0457 for ; Wed, 9 Apr 2014 12:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCps4FnMQoGr for ; Wed, 9 Apr 2014 12:02:35 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 656401A0446 for ; Wed, 9 Apr 2014 12:02:35 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 58B28FA006C; Wed, 9 Apr 2014 19:02:33 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1397070152-23383-23383/11/27; Wed, 9 Apr 2014 19:02:32 +0000 From: Arnt Gulbrandsen To: "Murray S. Kucherawy" Date: Wed, 9 Apr 2014 21:02:30 +0200 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/D4hlTvUbXBEbp6b7GCwPNkMoMWo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:02:45 -0000 You do know that. Maybe you don't know when the RRVS-capable software was first deployed at the relevant site, but you certainly know when it was written. Arnt From nobody Wed Apr 9 12:44:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6211A0457 for ; Wed, 9 Apr 2014 12:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k28Zkpnxqqx for ; Wed, 9 Apr 2014 12:44:33 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46C1A0265 for ; Wed, 9 Apr 2014 12:44:33 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so2974940wes.9 for ; Wed, 09 Apr 2014 12:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wHWtohdkno7yh5Ileet30AxC90dkrhnUmSVHbkt37eQ=; b=XVjVD/ytAV9mddjbUUOMnFfr+7ZGyssUIaq7MR17M88bxMK+QlmAecyJJczzyk8K3Z G9vb1EpWwdHNCzRIsxI+6juHi5guGEwdbIXpBy1UIRHCt3uJVYk8mgTl5S6m74uf9LK2 JrIcu0qzSNPTQt7Cjff1VjFtmCB0H4ZQgtCGhxLACBfKaInmHPd9/jbdM976z8P1frOZ c6QULgFEtwTsj1apmRVUG+/Ep0rlASS1UBeds+d3ifWt8EoILEyUUB2fvtIMFbO7jgXg SFPt+zI5abf9ewOk1orvfNfcWmBgwLap1SdvH64lDTVzB7R7uY22u+33ZrJ546qWLGXa mRKw== MIME-Version: 1.0 X-Received: by 10.194.110.100 with SMTP id hz4mr11338267wjb.50.1397072672398; Wed, 09 Apr 2014 12:44:32 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Wed, 9 Apr 2014 12:44:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 12:44:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=047d7bf1987e5d23f504f6a154c2 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jT9jqsQXpLsAnywOGK_dpzjoi58 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:44:38 -0000 --047d7bf1987e5d23f504f6a154c2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 9, 2014 at 12:02 PM, Arnt Gulbrandsen wrote: > You do know that. Maybe you don't know when the RRVS-capable software was > first deployed at the relevant site, but you certainly know when it was > written. > > I'm not sure what you mean by that. Are you saying that if you don't have an explicit date recorded for a given mailbox, you select some locally obvious couldn't-possibly-have-been-earlier-than-this date, and use that? -MSK --047d7bf1987e5d23f504f6a154c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 9, 2014 at 12:02 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
You do know that. Maybe you don't know w= hen the RRVS-capable software was first deployed at the relevant site, but = you certainly know when it was written.


I'm not sure what yo= u mean by that.=A0 Are you saying that if you don't have an explicit da= te recorded for a given mailbox, you select some locally obvious couldn'= ;t-possibly-have-been-earlier-than-this date, and use that?

-MSK

--047d7bf1987e5d23f504f6a154c2-- From nobody Wed Apr 9 12:51:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918741A023D for ; Wed, 9 Apr 2014 12:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.343 X-Spam-Level: ** X-Spam-Status: No, score=2.343 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCLhFSoqH6Wd for ; Wed, 9 Apr 2014 12:51:21 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 52EB31A0232 for ; Wed, 9 Apr 2014 12:51:21 -0700 (PDT) Received: (qmail 39812 invoked from network); 9 Apr 2014 19:51:19 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Apr 2014 19:51:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ca9.5345a4b8.k1404; i=johnl@user.iecc.com; bh=F8Lt4KUKojUoHs4Mj839yzskbG15QIJEJKYfZL4GKlQ=; b=EY1NaUlasJH40hxqLPaSvYFxjGvDDccNu/epvXvrr57z++XHLoNHoOR27PZJlbykr6cOtYkotFUdZEQSjCp3FDwXi/g1gRt6wlOExDcKRs06wvDWrN8rtuxrdDq/YwvqBRooWP/knb5XnRFqxnuJXI+W0Ab/i96uoguuqm8nnA0nbQ++JOTYqGKnJTEna7NUjIMcSi5/7Oc55PpNAR4Vo2hHGH+LxXDCgt5HAr+9+35eTZtVqm15LG3XwatGhfWI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ca9.5345a4b8.k1404; olt=johnl@user.iecc.com; bh=F8Lt4KUKojUoHs4Mj839yzskbG15QIJEJKYfZL4GKlQ=; b=aitjzKh+EIx2fMF1smRM8KacSMDtQpBEUvNmUzuxqR4rLQl482UVUZzoPxxgsLKDVN0yL9wdQ5aL+UQv/+Ost31H+yWuF54QjKHL3ir+9v+pO3v9J5SIaHL0CNTiIYwdt1YixCTTtP2QTD2tJOadXwsScC9IqokFAgLi1feClr6nR7FeKjcGpJnHwkZl1/Nx5OElrnQ6RMPJtX2BHb4LJ1VV2gej0IE4rR81UhtUSyRbHAZK7QP2S6ubo4IsubQe Date: 9 Apr 2014 19:50:58 -0000 Message-ID: <20140409195058.3240.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_lMNsROzCc4VJ89MXPQOj4RMGFs Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:51:25 -0000 > Barry points out that we do not >specify what a receiver should do in the case where RRVS is used by a >client that hands a message to an MDA, but the MDA is unable to determine >the result of the continuous ownership test. There's two failure modes here, one where the wrong user gets someone else's message, another where the right user loses his own message. Which is th worse problem depends on what the message is about. For example: * Your account at Foo Bank needs attention, check the web site * The recovery password for your Foo Bank account is swordfish In the first case, the amount of info leaked to the wrong recipient is low, and the potential value to the right recipient is high (e.g., move money from savings to checking today or we'll charge you four $35 bounce fees.) In the second case, it's better to lose it and wait for the customer to call or something. I have no idea which will be more typical of RRVS traffic, and I don't think anyone else does either. I'd document it as a security issue and leave it as an implementation decision. R's, John From nobody Wed Apr 9 13:03:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009E51A01E7 for ; Wed, 9 Apr 2014 13:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htW7ItpM7EBW for ; Wed, 9 Apr 2014 13:03:10 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AAF1A01B3 for ; Wed, 9 Apr 2014 13:03:10 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6259EFA00D7; Wed, 9 Apr 2014 20:03:08 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1397073787-23383-23383/11/28; Wed, 9 Apr 2014 20:03:07 +0000 From: Arnt Gulbrandsen To: "Murray S. Kucherawy" Date: Wed, 9 Apr 2014 22:03:06 +0200 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <596d909b-fd6d-4214-beed-e3ccb615f18b@gulbrandsen.priv.no> In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-YwdDTNINK1GCYcR_UdoJgq-qD0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:03:13 -0000 On Wednesday, April 9, 2014 9:44:32 PM CEST, Murray S. Kucherawy wrote: > I'm not sure what you mean by that. Are you saying that if you > don't have an explicit date recorded for a given mailbox, you > select some locally obvious > couldn't-possibly-have-been-earlier-than-this date, and use > that? More or less. I am assuming (based on someone's argument) that if you don't know the actual date, then the date must be from before you started recording, and you can use the start of recording as a reasonable proxy. Arnt From nobody Wed Apr 9 13:12:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9AD1A02B3 for ; Wed, 9 Apr 2014 13:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.015 X-Spam-Level: * X-Spam-Status: No, score=1.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPTThIt3AyJJ for ; Wed, 9 Apr 2014 13:12:34 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 493DA1A02C6 for ; Wed, 9 Apr 2014 13:12:34 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uy5so3280595obc.6 for ; Wed, 09 Apr 2014 13:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KLVdXj9vFdrytPUjYdqsvtA2rvwPynUO5ERXr+YjrqA=; b=gojSt9v3Tev4S6+M3DTuT4H4os/g48W7lsch32SflQOBTjxKzuvos0ielucxPbAYqu wh9ACjRl928O1yh6cTbYnnDoNYqCJgtmnb0HZgePjoerEhsO65ZC57zjBQYlsSABxOBG HWpltK5/iuLzhWcgLFuUUGcO2yQrJ1yP9OoRo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KLVdXj9vFdrytPUjYdqsvtA2rvwPynUO5ERXr+YjrqA=; b=Vw/F0OsefZBvY6/nVNLT1/YV4Isasnko9JdrmoT+Ku2jOHBJB2ytSTWHytrwSJzr9L 0zFIQlESgVpoUT79AmkDfXsT8kvNu13mNbT4fHSET209FOTSvdGiRT0E8aZPyEGYyoBy mz33dHnM0P2R7789Da12YtBnS6H3bGNvazQ2YiVko+JVqZgNOkxLNUvY9S+JObrp95BE YCqd4MM4DttyC0no2RnZrpbZba3Cl3lj2qGjYB05+mMKSeZy0dnlo/Xc1ZDv8mthsPwA VIeVYaqes2A4EyXzwSCGC6D/eWtHKsvnXch/qI1AcYHBPsurifZJfUfjRMsebrsdYDcd ralQ== X-Gm-Message-State: ALoCoQmN6wwjSAHkr8HhZPrwUDzqWCf2JphWoRlzO2T+YT81+dbPQ1C+U4twpU7sEd6cROEDWWcT MIME-Version: 1.0 X-Received: by 10.182.120.40 with SMTP id kz8mr10522332obb.6.1397074353603; Wed, 09 Apr 2014 13:12:33 -0700 (PDT) Received: by 10.60.93.6 with HTTP; Wed, 9 Apr 2014 13:12:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 21:12:33 +0100 Message-ID: From: Dave Cridland To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e0139fc3a929f5904f6a1b8be Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tnXi6_JxP6FYueMCulTumSZ2PZM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:12:37 -0000 --089e0139fc3a929f5904f6a1b8be Content-Type: text/plain; charset=ISO-8859-1 On 9 April 2014 20:44, Murray S. Kucherawy wrote: > On Wed, Apr 9, 2014 at 12:02 PM, Arnt Gulbrandsen < > arnt@gulbrandsen.priv.no> wrote: > >> You do know that. Maybe you don't know when the RRVS-capable software was >> first deployed at the relevant site, but you certainly know when it was >> written. >> >> > I'm not sure what you mean by that. Are you saying that if you don't have > an explicit date recorded for a given mailbox, you select some locally > obvious couldn't-possibly-have-been-earlier-than-this date, and use that? > It's actually the earliest possible couldn't-possibly-have-been-*later*-than-this date. So for the "when we started recording account creation", this is the earliest date for which we know an account was not created afterward unless explicitly recorded. Dave. --089e0139fc3a929f5904f6a1b8be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 9= April 2014 20:44, Murray S. Kucherawy <superuser@gmail.com> wrote:

--089e0139fc3a929f5904f6a1b8be-- From nobody Wed Apr 9 14:10:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CCB1A021A for ; Wed, 9 Apr 2014 14:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_iEm0cIfaj4 for ; Wed, 9 Apr 2014 14:10:25 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 58D981A0232 for ; Wed, 9 Apr 2014 14:10:25 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so3004738wes.23 for ; Wed, 09 Apr 2014 14:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fgXyF86HAictoivQYKSlrb6ixG+84l8z4pBUVMK3G0A=; b=Cx5UHclQtkUR5caMttToC2w0o1AmYfugoetPFYF+GROCyLym/mxZcVIoZiSEQ7Xq/Z Pkor27VnSJtv+pEs9NwPsPCX99CC1O31Y2xwgMiUC8f2An+ZEKRvbQebwN+MHEE+TV3Z voQ7r5N53/sLtEFRAZWrauS7GDVUC0z22fTuYa4dQLZ+edtFvSf+E/+zHqVUKXVG5h2q XBBH0XRiUAbwXHOuQM843Eb1zGJCYXndHCVcYL/NtyeOye+M/Gwi//QKtcub+WbNEN57 5/fqnMIofG19wR7tRun1XC/C5a67Yilk8qA/cXmEMEXjOPbYK392vtqJTC8EQffaJLfY Z+6A== MIME-Version: 1.0 X-Received: by 10.194.6.106 with SMTP id z10mr11444693wjz.1.1397077824286; Wed, 09 Apr 2014 14:10:24 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Wed, 9 Apr 2014 14:10:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 14:10:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Cridland Content-Type: multipart/alternative; boundary=047d7b3a8b5470b6ab04f6a287e8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dqv2ZCQW_fWgWfMTpgXKX61nacc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:10:29 -0000 --047d7b3a8b5470b6ab04f6a287e8 Content-Type: text/plain; charset=ISO-8859-1 Could you phrase that in prose fit for a draft? :-) I think I get what you're suggesting but I'm not certain. I feel as though we'll ultimately need to accommodate the case where the answer is "I don't know" to all forms of the question, even the case you're talking about (e.g., where the operator has no idea how to figure out what an earliest possible couldn't-possibly-have-been-*later*-than-this date might be). Something like this is what I have in mind so far: (1) use the account creation/reassignment date, if you know it; OTHERWISE (2) use the earliest possible couldn't-possibly-have-been-*later*-than-this date, if you know it; OTHERWISE (3) return a bounce with an enhanced status code indicating the MDA is unable to comply with the query, so either give up or try again without RRVS. -MSK On Wed, Apr 9, 2014 at 1:12 PM, Dave Cridland wrote: > On 9 April 2014 20:44, Murray S. Kucherawy wrote: > >> On Wed, Apr 9, 2014 at 12:02 PM, Arnt Gulbrandsen < >> arnt@gulbrandsen.priv.no> wrote: >> >>> You do know that. Maybe you don't know when the RRVS-capable software >>> was first deployed at the relevant site, but you certainly know when it was >>> written. >>> >>> >> I'm not sure what you mean by that. Are you saying that if you don't >> have an explicit date recorded for a given mailbox, you select some locally >> obvious couldn't-possibly-have-been-earlier-than-this date, and use that? >> > > It's actually the earliest possible > couldn't-possibly-have-been-*later*-than-this date. > > So for the "when we started recording account creation", this is the > earliest date for which we know an account was not created afterward unless > explicitly recorded. > > Dave. > --047d7b3a8b5470b6ab04f6a287e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Could you phrase that in prose fit for= a draft?=A0 :-)=A0 I think I get what you're suggesting but I'm no= t certain.

I feel as though we'll ultimately need to accommodate= the case where the answer is "I don't know" to all forms of = the question, even the case you're talking about (e.g., where the opera= tor has no idea how to figure out what an earliest possible couldn't-po= ssibly-have-been-*later*-than-this date might be).=A0 Something like this i= s what I have in mind so far:

(1) use the account creation/reassignment date, if you know it; O= THERWISE
(2) use the earliest possible couldn't-possibly-have-= been-*later*-than-this date, if you know it; OTHERWISE
(3) return = a bounce with an enhanced status code indicating the MDA is unable to compl= y with the query, so either give up or try again without RRVS.

-MSK



On Wed, Apr 9, 2014 at 1:12 PM, Dave C= ridland <dave@cridland.net> wrote:
=
On 9 April 2014 20:44, Mu= rray S. Kucherawy <superuser@gmail.com> wrote:
On Wed, Apr 9, 2014 at= 12:02 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
You do know that. Maybe you don't know w= hen the RRVS-capable software was first deployed at the relevant site, but = you certainly know when it was written.


I'm not sure w= hat you mean by that.=A0 Are you saying that if you don't have an expli= cit date recorded for a given mailbox, you select some locally obvious coul= dn't-possibly-have-been-earlier-than-this date, and use that?

It's act= ually the earliest possible couldn't-possibly-have-been-*later*-than-th= is date.

So for the "when we started recordin= g account creation", this is the earliest date for which we know an ac= count was not created afterward unless explicitly recorded.

Dave.

--047d7b3a8b5470b6ab04f6a287e8-- From nobody Thu Apr 10 08:51:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E491A0281 for ; Thu, 10 Apr 2014 08:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.775 X-Spam-Level: *** X-Spam-Status: No, score=3.775 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERhGldFnlILS for ; Thu, 10 Apr 2014 08:51:15 -0700 (PDT) Received: from ephesus.webhostserver.biz (unknown [75.98.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id BE8471A027C for ; Thu, 10 Apr 2014 08:51:15 -0700 (PDT) Received: from [24.130.84.109] (port=50276 helo=[192.168.253.8]) by ephesus.webhostserver.biz with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WYHFy-0007o1-IN for apps-discuss@ietf.org; Thu, 10 Apr 2014 08:51:14 -0700 From: "Mark W. Foster" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <49B91FB6-BBF3-4C4D-A6AF-CF1448B9E277@fosrias.com> Date: Thu, 10 Apr 2014 08:51:13 -0700 To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ephesus.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - fosrias.com X-Get-Message-Sender-Via: ephesus.webhostserver.biz: authenticated_id: mwf@fosrias.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kSsuCx8pTHR-kRP8Pgb8aAAv2iU Subject: [apps-discuss] Question on json-home status and future of Resource Hints X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 15:51:16 -0000 I notice there are a number of TBDs in the draft and it has been a while = since there has been an update. Any information on a forthcoming = revision? Also, it would be useful for there to be a =91name=92 property on = Resource Objects that would allow clients to select a Resource by name = vs. using the (resolvable) link relation. Has this been discussed? = Further, would that be considered a =93Resource Hint=94 per TBD section = 5 or just an attribute of a Resource Object. Thanks, Mark= From nobody Thu Apr 10 09:41:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20871A01FF for ; Thu, 10 Apr 2014 09:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtc4ioHk2zTk for ; Thu, 10 Apr 2014 09:41:15 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5C20A1A01DC for ; Thu, 10 Apr 2014 09:41:15 -0700 (PDT) Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66] helo=[192.168.1.76]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1WYI2K-0002Ek-6N; Thu, 10 Apr 2014 09:41:14 -0700 Message-ID: <5346C9A6.1070204@berkeley.edu> Date: Thu, 10 Apr 2014 09:41:10 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <49B91FB6-BBF3-4C4D-A6AF-CF1448B9E277@fosrias.com> In-Reply-To: <49B91FB6-BBF3-4C4D-A6AF-CF1448B9E277@fosrias.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zHJUNHQz0RvEaIvRwTU7V_ybwt0 Cc: "Mark W. Foster" Subject: Re: [apps-discuss] Question on json-home status and future of Resource Hints X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 16:41:20 -0000 hello mark. On 2014-04-10, 8:51 , Mark W. Foster wrote: > I notice there are a number of TBDs in the draft and it has been a while since there has been an update. Any information on a forthcoming revision? very true. please notice that the draft is expired, and that mark has published http://tools.ietf.org/html/draft-nottingham-link-hint in the meantime, which eventually should be synced with the home document draft. adding support for URI templates, there's something similar and a bit more ambitious at http://tools.ietf.org/html/draft-wilde-link-desc and i also wrote a brief blog post to put all these things in perspective (from my point of view, of course): http://dret.typepad.com/dretblog/2013/10/link-information-design-time-runtime-and-on-demand.html > Also, it would be useful for there to be a ‘name’ property on Resource Objects that would allow clients to select a Resource by name vs. using the (resolvable) link relation. Has this been discussed? Further, would that be considered a “Resource Hint” per TBD section 5 or just an attribute of a Resource Object. what would you consider such a name to be? ideally, everything should resolve around URI-based identifiers, right? as i understand the model, resource hints are intended to be something that helps to drive interactions with a resource, not a general model of all kinds of metadata about a resource. but maybe i am misunderstanding what you are proposing here. what's an example for how this 'name' would be used? thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Fri Apr 11 02:59:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32DF1A01BF for ; Fri, 11 Apr 2014 02:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.337 X-Spam-Level: *** X-Spam-Status: No, score=3.337 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxEhaXFF626r for ; Fri, 11 Apr 2014 02:59:30 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id ACFC31A03B6 for ; Fri, 11 Apr 2014 02:59:29 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 668F632E4B7; Fri, 11 Apr 2014 18:59:27 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3cf3_3ce0_348e506c_8f1b_4798_aecc_01be061d79c7; Fri, 11 Apr 2014 18:59:26 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 8F612C036C; Fri, 11 Apr 2014 18:59:26 +0900 (JST) Message-ID: <5347BCF1.7000504@it.aoyama.ac.jp> Date: Fri, 11 Apr 2014 18:59:13 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Graham Klyne , "apps-discuss@ietf.org" References: <5343C547.3050204@ninebynine.org> In-Reply-To: <5343C547.3050204@ninebynine.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/g7EBwpx6EpC6oQqNZPUoL9yzB2w Cc: drafts-expert-review-comment@iana.org, Nevil Brownlee Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 09:59:32 -0000 Hello Graham, It is my understanding that RFCs in the independent stream go through an IETF conflict review. I think that would be one way to deal with registration proposals that would be considered harmful. Regards, Martin. On 2014/04/08 18:45, Graham Klyne wrote: > All, > > TL;DR: should a permanent message header field registration be allowed > through an ISE RFC publication, which does not require IETF review? > > ... > > An issue has come up concerning permanent registration of a message > header field through an RFC independent stream editor (ISE) submission > (https://tools.ietf.org/html/rfc6548). > > RFC 3864 says: > [[ > A Permanent Message Header Field Registry, intended for headers > defined in IETF standards-track documents, those that have > achieved a comparable level of community review, or are generally > recognized to be in widespread use. > ]] > -- http://tools.ietf.org/html/rfc3864#section-2.1 > > But also: > [[ > A header registered in the Permanent Message Header Field Registry > MUST be published as an RFC or as an "Open Standard" in the sense > described by RFC 2026, section 7 [1], > ]] > -- http://tools.ietf.org/html/rfc3864#section-4.2.1 > > The latter quote appears to allow permanent registration following *any* > RFC publication. Specifically, it appears to allow permanent > registration following RFC publication through the RFC ISE stream, which > does not require review within the IETF. As one of the original > drafters of the registration specification, I claim this was not > intended. At the time, (I think) I believed that independent submission > RFCs were still subject to IETF,. or at least IESG, review. (I'm not > sure if this is also true of my co-editors, so I'm speaking for myself > here.) > > My expectation was that a permanent header field registration could be > achieved through an IETF-reviewed informational RFC, as well as a > standards-track RFC. This flexibility was used, for example, to > grandfather entries into the permanent registry in > http://tools.ietf.org/html/rfc4229. > > (In my role as reviewer for IANA) I have received a request to accept a > permanent registration from an ISE RFC submission that has not been > reviewed in the IETF, and have pushed back. But the requester makes the > reasonable point that the section 4.2.1 text noted above provides no > explicit grounds for refusal of such a permanent registration. > > In the current case, I would like to see the registration request > submitted for review on the designated mailing list > (ietf-message-headers@lists.ietf.org) (per > http://tools.ietf.org/html/rfc3864#section-4.3) and see what feedback it > garners. > > Under the circumstances, I think I should ask you, the IETF community, > whether it is reasonable to push back in circumstances which have come > about due to what is effectively a drafting error. And, more generally, > does this community feel that it should be allowable to create permanent > header field registry entries without undergoing IETF review? > > RFC3864 also says: > [[ > The IESG is the final arbiter of any objection. > ]] > -- http://tools.ietf.org/html/rfc3864#section-4.4 > > So there is process scope to refuse a permanent registration, even if > other conditions are met, if the IESG opines it should not be made. > > (For the avoidance of doubt, I accept ISE submissions are perfectly > suitable mechanism for creating provisional registrations, it's just > permanent registration I'm questioning here.) > > I welcome any thoughts and feedback. > > #g > -- > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Apr 11 06:12:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966701A025C for ; Fri, 11 Apr 2014 06:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd5RMTbfpUxE for ; Fri, 11 Apr 2014 06:11:55 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id C88041A0246 for ; Fri, 11 Apr 2014 06:11:54 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WYbFE-0003Wc-gi; Fri, 11 Apr 2014 14:11:48 +0100 Received: from oerc-dynamic-219.oerc.ox.ac.uk ([129.67.194.219]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WYbFE-0002SN-3f; Fri, 11 Apr 2014 14:11:48 +0100 Message-ID: <5347E830.7070208@ninebynine.org> Date: Fri, 11 Apr 2014 14:03:44 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <5343C547.3050204@ninebynine.org> <5347BCF1.7000504@it.aoyama.ac.jp> In-Reply-To: <5347BCF1.7000504@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ws3gDweNyNPYzEkPP9q8rwBljPg Cc: drafts-expert-review-comment@iana.org, Nevil Brownlee , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:12:03 -0000 On 11/04/2014 10:59, "Martin J. Drst" wrote: > Hello Graham, > > It is my understanding that RFCs in the independent stream go through an IETF > conflict review. I think that would be one way to deal with registration > proposals that would be considered harmful. Hi Martin, Thanks for the comment. I agree that the conflict review may be a way to deal with this. But I might also suggest that it lacks clarity for both submitter and reviewers. It's not clear to me if an IESG conflict review would regard an unreviewed permanent header registration as a conflict. From from the submitter's viewpoint, it would be better if the registration document itself were clearer on this point (which it currently is not). I'm currently asking myself if the current confusion can be clarified through a document erratum (I see this as a problem of drafting), but a change here might be seen as substantive and requiring new review. But before attacking any of that I'm hoping to get a sense of what a consensus about permanent registration requirements might look like. (My own inclination would be to clarify the RFC requirement to be an "IETF stream RFC" per http://tools.ietf.org/html/rfc4844#section-5.1.1) #g -- > > Regards, Martin. > > On 2014/04/08 18:45, Graham Klyne wrote: >> All, >> >> TL;DR: should a permanent message header field registration be allowed >> through an ISE RFC publication, which does not require IETF review? >> >> ... >> >> An issue has come up concerning permanent registration of a message >> header field through an RFC independent stream editor (ISE) submission >> (https://tools.ietf.org/html/rfc6548). >> >> RFC 3864 says: >> [[ >> A Permanent Message Header Field Registry, intended for headers >> defined in IETF standards-track documents, those that have >> achieved a comparable level of community review, or are generally >> recognized to be in widespread use. >> ]] >> -- http://tools.ietf.org/html/rfc3864#section-2.1 >> >> But also: >> [[ >> A header registered in the Permanent Message Header Field Registry >> MUST be published as an RFC or as an "Open Standard" in the sense >> described by RFC 2026, section 7 [1], >> ]] >> -- http://tools.ietf.org/html/rfc3864#section-4.2.1 >> >> The latter quote appears to allow permanent registration following *any* >> RFC publication. Specifically, it appears to allow permanent >> registration following RFC publication through the RFC ISE stream, which >> does not require review within the IETF. As one of the original >> drafters of the registration specification, I claim this was not >> intended. At the time, (I think) I believed that independent submission >> RFCs were still subject to IETF,. or at least IESG, review. (I'm not >> sure if this is also true of my co-editors, so I'm speaking for myself >> here.) >> >> My expectation was that a permanent header field registration could be >> achieved through an IETF-reviewed informational RFC, as well as a >> standards-track RFC. This flexibility was used, for example, to >> grandfather entries into the permanent registry in >> http://tools.ietf.org/html/rfc4229. >> >> (In my role as reviewer for IANA) I have received a request to accept a >> permanent registration from an ISE RFC submission that has not been >> reviewed in the IETF, and have pushed back. But the requester makes the >> reasonable point that the section 4.2.1 text noted above provides no >> explicit grounds for refusal of such a permanent registration. >> >> In the current case, I would like to see the registration request >> submitted for review on the designated mailing list >> (ietf-message-headers@lists.ietf.org) (per >> http://tools.ietf.org/html/rfc3864#section-4.3) and see what feedback it >> garners. >> >> Under the circumstances, I think I should ask you, the IETF community, >> whether it is reasonable to push back in circumstances which have come >> about due to what is effectively a drafting error. And, more generally, >> does this community feel that it should be allowable to create permanent >> header field registry entries without undergoing IETF review? >> >> RFC3864 also says: >> [[ >> The IESG is the final arbiter of any objection. >> ]] >> -- http://tools.ietf.org/html/rfc3864#section-4.4 >> >> So there is process scope to refuse a permanent registration, even if >> other conditions are met, if the IESG opines it should not be made. >> >> (For the avoidance of doubt, I accept ISE submissions are perfectly >> suitable mechanism for creating provisional registrations, it's just >> permanent registration I'm questioning here.) >> >> I welcome any thoughts and feedback. >> >> #g >> -- >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Sat Apr 12 06:09:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD11A0118 for ; Sat, 12 Apr 2014 06:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.38 X-Spam-Level: X-Spam-Status: No, score=-98.38 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80FuVkPrMmv2 for ; Sat, 12 Apr 2014 06:08:55 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 101A41A012B for ; Sat, 12 Apr 2014 06:08:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3205; t=1397308128; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1FZChhlaTfq0U1AI/IoKRtF5sDQ=; b=lN25kkIqoWMWohC+T5ar iY8M6K9neORzcqWiSxIKYRkBrs55p+R1MNddASsDVEly0QOtglVPio/tfef6aznX 7Eex41HAEmF3ZFXsbqS7MgCpxkXHq6KJehwXa+M6XelByW/W8NLZIaf6D5XiBTtZ 2D9PY/iSMLWOOfNZp1MPhI8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 12 Apr 2014 09:08:48 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 416707983.9010.2944; Sat, 12 Apr 2014 09:08:47 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3205; t=1397308064; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bcyBxA+ /VC16Bw2xMLc5mjeDaLELZFtm31eUBIcxhXg=; b=UKWLVvwpCxpZuYBafp5eTqe 3K1HpXlN3PzbCinQI60zuP4EL3i5NMzFkZeMSO4Vr9M+wm0cq4424KhADCgOEYhM FiyhttRyXAYyoGNkaz2aWkU1+LscWRh3zKXqGrrB9SYLMl+z5CgqZb10CBBnbZMC ba3QBuK4JNzjmkFSNf34= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 12 Apr 2014 09:07:44 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 436239468.9.7332; Sat, 12 Apr 2014 09:07:42 -0400 Message-ID: <53493AE0.3070006@isdg.net> Date: Sat, 12 Apr 2014 09:08:48 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Dave Cridland References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GCIDe3QY6lj76A1euvYPZteFwcs Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 13:08:59 -0000 I've been wondering how to phrase my question(s). I guess I'm not quite following. Is the suggestion below a design suggestion or protocol logic for a "Partial Support" of the protocol? The RRVS implementation will most likely need to add a new field or two. Also, to do it correctly, the first time records update/conversion will be needed to fill in these fields from "almost near, make sense" timestamps, i.e. in our cases, we have several fields to use: LastCall LastUpdate VericationDate But if you don't have these or have yet to do a design change, you can do "partial support" by returning a negative response when used against your system? Finally, a few more questions: 1) Is there some open source code out there to see if how this is being implemented? 2) Is there a method to test this against other sites, also without exhausting many new accounts? Like at facebook, i created a bunch of new xxxxxxx@winserver.com signups to see if it was sending the RRVS during the email confirmation. thanks On 4/9/2014 5:10 PM, Murray S. Kucherawy wrote: > Could you phrase that in prose fit for a draft?� :-)� I think I get > what you're suggesting but I'm not certain. > > I feel as though we'll ultimately need to accommodate the case where > the answer is "I don't know" to all forms of the question, even the > case you're talking about (e.g., where the operator has no idea how to > figure out what an earliest possible > couldn't-possibly-have-been-*later*-than-this date might be).� > Something like this is what I have in mind so far: > > (1) use the account creation/reassignment date, if you know it; OTHERWISE > (2) use the earliest possible > couldn't-possibly-have-been-*later*-than-this date, if you know it; > OTHERWISE > (3) return a bounce with an enhanced status code indicating the MDA is > unable to comply with the query, so either give up or try again > without RRVS. > > -MSK > > > > On Wed, Apr 9, 2014 at 1:12 PM, Dave Cridland > wrote: > > On 9 April 2014 20:44, Murray S. Kucherawy > wrote: > > On Wed, Apr 9, 2014 at 12:02 PM, Arnt Gulbrandsen > > > wrote: > > You do know that. Maybe you don't know when the > RRVS-capable software was first deployed at the relevant > site, but you certainly know when it was written. > > > I'm not sure what you mean by that.� Are you saying that if > you don't have an explicit date recorded for a given mailbox, > you select some locally obvious > couldn't-possibly-have-been-earlier-than-this date, and use that? > > > It's actually the earliest possible > couldn't-possibly-have-been-*later*-than-this date. > > So for the "when we started recording account creation", this is > the earliest date for which we know an account was not created > afterward unless explicitly recorded. > > Dave. > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- HLS From nobody Sat Apr 12 10:14:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275D71A0207 for ; Sat, 12 Apr 2014 10:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm4i6-UTfntS for ; Sat, 12 Apr 2014 10:14:15 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 451F61A01FE for ; Sat, 12 Apr 2014 10:14:15 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so6674561wes.34 for ; Sat, 12 Apr 2014 10:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cN7wkxJ2MxPEc5mIRfB/MWHFp/ddfBdZpW5lrw3mZfU=; b=Tt55niDLWfNkckaTuC7a1Vo1h9J3z2e/mJn5Y6VFKv+4XRHs3Sfb91dWM2htdCkRjd 0d+yLharDwHCT5eYT1gUCFfMGfUaplFggQIGfTGSMxTy7vgWCgk2emyPQ1whmvB3onU2 NN0cNpFUvstm4s/nmb66+tNKk/Y/P9haPdOASDo2ytBJ752pRpvDkloINF3/XUTxWk5I 6PUhyKrzm4VXyNdkQswnrLk26P04fT6OKBes8VbXsRVxGKd5XFC8g1rQO2jQti1/G/Fr CvVohJGGB0z5BBeLapvC1ofTRWg1EBmxuNd67lg5XIsiJUiwFQFiAUEJITRoCx8DVZjO QqHQ== MIME-Version: 1.0 X-Received: by 10.180.36.101 with SMTP id p5mr3085156wij.8.1397322853036; Sat, 12 Apr 2014 10:14:13 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Sat, 12 Apr 2014 10:14:12 -0700 (PDT) In-Reply-To: <53493AE0.3070006@isdg.net> References: <53493AE0.3070006@isdg.net> Date: Sat, 12 Apr 2014 10:14:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=e89a8f50345e4abb0604f6db94b2 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lLcrPSCUAV0T76kpdFSrQogFPMo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 17:14:17 -0000 --e89a8f50345e4abb0604f6db94b2 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 12, 2014 at 6:08 AM, Hector Santos wrote: > But if you don't have these or have yet to do a design change, you can do > "partial support" by returning a negative response when used against your > system? > As I've said before, if you don't have the infrastructure to answer the RRVS question, you would simply not advertise the RRVS extension and ignore the header field. Finally, a few more questions: > > 1) Is there some open source code out there to see if how this is being > implemented? > Not that I know of. This would be hard to do given the non-extensibility of most open source implementations, at least as far as SMTP extensions go. 2) Is there a method to test this against other sites, also without > exhausting many new accounts? Like at facebook, i created a bunch of new > xxxxxxx@winserver.com signups to see if it was sending the RRVS during > the email confirmation. > Facebook won't send RRVS header fields (the current implementation) except by private agreement right now. I don't know what others are doing. -MSK --e89a8f50345e4abb0604f6db94b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 12, 2014 at 6:08 AM, Hector Santos <hsantos@= isdg.net> wrote:
But if you don't= have these or have yet to do a design change, you can do "partial sup= port" by returning a negative response when used against your system?<= br>

As I've said before, if you don&= #39;t have the infrastructure to answer the RRVS question, you would simply= not advertise the RRVS extension and ignore the header field.

Finally, =A0a few more questions:

1) Is there some open source code out there to see if how this is being imp= lemented?

Not that I know of.=A0 = This would be hard to do given the non-extensibility of most open source im= plementations, at least as far as SMTP extensions go.

2) Is there a method to test this against other sites, also without exhaust= ing many new accounts? =A0Like at facebook, i created a bunch of new xxxxxxx@winserver.com<= /a> signups to see if it was sending the RRVS during the email confirmation= .

--e89a8f50345e4abb0604f6db94b2-- From nobody Mon Apr 14 07:14:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCCB1A02C4; Mon, 14 Apr 2014 07:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8sEQA_YRM27; Mon, 14 Apr 2014 07:14:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6301A011A; Mon, 14 Apr 2014 07:14:13 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M51eM-1Wtquz2A3C-00zBmm; Mon, 14 Apr 2014 16:13:48 +0200 Message-ID: <534BED18.9090009@gmx.de> Date: Mon, 14 Apr 2014 16:13:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John C Klensin , apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fdSQ1g5Ld39d+OkVhzTZ8XleYoSPQsbbU6+Z5Hir8SOAd1PSQd7 ZRpCxmPm8VznWl0W8G4AoUN6WmrHE6ojH8iyhx1wbJBEmVAJjOvuiy+KWwigiHxytSZuG9C ZXNYpuyw/BT0lc0fO7jlRvRr4hVhUzH8dGyomw5FuKXDqB773srMFsIszmCEvAeWqfa0F5u hZ3Ma4ipYV8LEtZnG481A== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mcLTpnGmbCgepu0s8kIdo8U6DTM Cc: urn@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:14:15 -0000 On 2014-04-14 15:11, John C Klensin wrote: > ... One remark: I don't think it's helpful to mix *this* discussion with the WHAT/W3C/IETF discussion about the "URL specification" (which essentially is about error-tolerant parsing) And one question: If you followed this path, would you still be able to use RFC3986-conforming libraries to handle URNs? Best regards, Julian From nobody Mon Apr 14 10:19:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64F81A0476; Mon, 14 Apr 2014 06:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWXyUYlRIfWC; Mon, 14 Apr 2014 06:11:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4F11A03EC; Mon, 14 Apr 2014 06:11:26 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WZgfT-0004rL-Up; Mon, 14 Apr 2014 09:11:23 -0400 Date: Mon, 14 Apr 2014 09:11:18 -0400 From: John C Klensin To: apps-discuss@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Bz9DF2wqoWFVPkVAdAt7LbI5e8U X-Mailman-Approved-At: Mon, 14 Apr 2014 10:19:26 -0700 Cc: urn@ietf.org Subject: [apps-discuss] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:11:31 -0000 Hi. It seems wise to call the attention of this broader group to something that is going on in URNBIS (and more generally). This message is a personal opinion. It summarizes some discussions in and around that WG but is not an attempt to report on any sort of consensus. RFC 3986 on Generic URI Syntax was an attempt to create a general syntax (and, despite its title, partial semantics) for an extremely general set of resource identifiers, using experience with and developments from URLs as a starting point. The general URI concept was intended to including URLs, URNs, and possible future types. That approach worked for URNs as long as they preserved the very narrow definitions and syntax of RFC 2141 but without taking advantage of any of the provisions for extensibility ("future use") in that specification. In the nearly 20 years since RFC 2141 was published, experience with URNs in various communities has demonstrated the need, with some URN types (NIDs), to be able to specify operations or retrieval of metadata as well as objects and for partial retrieval or other operations on either metadata of the objects themselves. At the same time, there have been forceful discussions in information science, library, museum, and publisher communities about the fundamental differences between locators and names (which much of that community calls "identifiers", excluding locators from that category) and the disadvantages of mixing the two concepts. That might be mostly a theoretical issue except that the URNBIS WG has found it impossible to define the functionality it needs while remaining within the syntax and semantic constraints of RFC 3986 (at least without creating obvious and very ugly kludges). The WG is now considering draft-ietf-urnbis-urns-are-not-uris-00, which proposes to separate URNs from RFC 3986, presumably leaving the latter with URLs and name-like things that are not URNs. It may be worth noting that there is now work in W3C and WHATWG on a new URL definition. The intent of that work includes eventually superceding 3986 (and 3987), at least for URLs, so there are multiple forces working to dismember RFC 3986. However, the URNBIS draft is intended to narrowly focus on the needs of URNs, rather than trying to boil the URI ocean. Those who are interested in this topic should probably take a look at the draft and the discussions during the last week or so on the URN mailing list (http://www.ietf.org/mail-archive/web/urn/). That list has been fairly low-volume, so looking at those messages should not be burdensome. Discussion should also occur on that list unless there are very broad issues that belong here. thanks, john From nobody Mon Apr 14 10:19:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419AB1A03D7; Mon, 14 Apr 2014 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zutebk6W3x9i; Mon, 14 Apr 2014 07:35:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 585571A047E; Mon, 14 Apr 2014 07:35:56 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WZhzF-0004yO-P0; Mon, 14 Apr 2014 10:35:53 -0400 Date: Mon, 14 Apr 2014 10:35:48 -0400 From: John C Klensin To: Julian Reschke , apps-discuss@ietf.org Message-ID: <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> In-Reply-To: <534BED18.9090009@gmx.de> References: <534BED18.9090009@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EZiEMRRZRxknuSKu1Mf7mQQrewg X-Mailman-Approved-At: Mon, 14 Apr 2014 10:19:27 -0700 Cc: urn@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:36:01 -0000 --On Monday, April 14, 2014 16:13 +0200 Julian Reschke wrote: > On 2014-04-14 15:11, John C Klensin wrote: >> ... > > One remark: > > I don't think it's helpful to mix *this* discussion with the > WHAT/W3C/IETF discussion about the "URL specification" (which > essentially is about error-tolerant parsing) Agreed (although I would characterize parts of that discussion differently). The draft is strictly about the URN issues and doesn't do that. I just wanted to provide a little extra context about other things that are going on to head off a conversation about how 3986 must be inviolate ... a discussion to which those other discussions would be relevant. > And one question: > > If you followed this path, would you still be able to use > RFC3986-conforming libraries to handle URNs? Depends on what that means. For a URN NID that is 2141-conformant (a small subset of what 3986 allows) any library that can handle it today will handle it after this change. But what is driving this change is not theory, it is a need for new functionality that just doesn't fit into the locator-oriented 3986 model. That new functionality will require either new syntax or old syntax with different semantics than those specified in 3986. Just as there is no such thing as a 3986-conforming library that can completely and generally handle queries (other than parsing the query away from other components and dispatching it properly), such libraries are not likely to be able to fully process URNs. Another piece of that issue is that comparison of two URNs for equality is, in the general case, a rather different kind of operation than comparison of two URLs; I would not expect a URL-based algorithm (e.g., a RFC3986-conformant library) to be able to get URN comparisons right, at least without NID-specific action routines. I'm being a little vague about this only because the WG hasn't gotten into the syntax to be used for those new functions. I think every effort will be made to keep as much compatibility as possible, at least short of horrible and obvious kludges, but how far 3986 libraries can be pushed will depend on those decisions. Some of this is explored from a slightly different perspective in a few recent notes on the WG mailing list; please have a look. best regards, john From nobody Mon Apr 14 14:09:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6EE1A0694 for ; Mon, 14 Apr 2014 14:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeF-nTnCy-sN for ; Mon, 14 Apr 2014 14:09:35 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3C1A0648 for ; Mon, 14 Apr 2014 14:09:35 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so7978259veb.41 for ; Mon, 14 Apr 2014 14:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qukG59i4zecZak7SesMUoAeTDEIsYFVXL3Z2KWb1+L4=; b=PxtmJalLZK0RQhfbzmsv0jt6CE3urFgxTHDG9SuomZViwgE7xhMfX+v1kjyCjbV5/5 bpWZR22LTHQgZX2kMut4bPo7BQYFNwQSqh0pR3NxT6rN2zqWDfv3CdrD2wqRpysoSuzL O4T28amdtCrAS3zKscnSPFmIc8K8hGrctFviomnO7GTzjHZyO3i+NlkakfP+D3INi0+E rKlD3DBrJ8L2LT4StJm9pv5POIIuzK1fWj0szqWqm5P8yGJ/drlnJjkDxBeHVSGWa2TF s5MkgpPEiye1F88GjlbZH7IE7QddLV5O51EORGomMzBs2r09rqowzelX109I4teIw0iF 7k5A== MIME-Version: 1.0 X-Received: by 10.58.126.4 with SMTP id mu4mr40133682veb.0.1397509772477; Mon, 14 Apr 2014 14:09:32 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Mon, 14 Apr 2014 14:09:32 -0700 (PDT) In-Reply-To: <5347E830.7070208@ninebynine.org> References: <5343C547.3050204@ninebynine.org> <5347BCF1.7000504@it.aoyama.ac.jp> <5347E830.7070208@ninebynine.org> Date: Mon, 14 Apr 2014 17:09:32 -0400 X-Google-Sender-Auth: dhnL7YI_LE-OBIb_FyNyUh0UEc0 Message-ID: From: Barry Leiba To: Graham Klyne Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/x1OcDWlI_k4sHZsb8nXXEUp9OSY Cc: Nevil Brownlee , drafts-expert-review-comment@iana.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:09:36 -0000 Catching up... >> It is my understanding that RFCs in the independent stream go through an >> IETF conflict review. I think that would be one way to deal with registration >> proposals that would be considered harmful. > > Thanks for the comment. I agree that the conflict review may be a way to > deal with this. But I might also suggest that it lacks clarity for both > submitter and reviewers. It's not clear to me if an IESG conflict review > would regard an unreviewed permanent header registration as a conflict. Right. 5742 limits what we can do in conflict reviews, and pushing back on a problematic registration would be limited, I think, to a #5 response, which is rather nuclear: 5. The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. > I'm currently asking myself if the current confusion can be clarified > through a document erratum (I see this as a problem of drafting), but a > change here might be seen as substantive and requiring new review. Hm. Hm. I'm still thinking. On the one hand, as you point out in your first note, from your PoV this is an erratum: if you had been aware of the confusion at publication time, you'd have considered it an error and would have clarified it. But on the other hand, the community (and the IESG) might well have taken it at its word and expect to have IETF review. The backstop, though, is that it all goes through the designated expert, who is a delegate of the IESG. I see that as the real solution here. The way *I* interpret the text is that the registration policy is "Specification Required", and it's up to the judgment of the expert whether the specification is adequate and the request is reasonable and properly done. I think we can live with that until someone wants to update 3864. Barry, Applications AD From nobody Mon Apr 14 20:50:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4B41A0323; Mon, 14 Apr 2014 20:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GfXPBuLyO5v; Mon, 14 Apr 2014 20:50:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE41C1A0752; Mon, 14 Apr 2014 20:50:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140415035011.18262.42585.idtracker@ietfa.amsl.com> Date: Mon, 14 Apr 2014 20:50:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mkg2NH4fVzYU6dFboo9UZHLyNcs Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 03:50:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Returning Values from Forms: multipart/form-data Author : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-02.txt Pages : 11 Date : 2014-04-14 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 15 02:25:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D331A029C for ; Tue, 15 Apr 2014 02:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak7mRhyzI_30 for ; Tue, 15 Apr 2014 02:25:45 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 81CE11A03A6 for ; Tue, 15 Apr 2014 02:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1397553942; d=isode.com; s=selector; i=@isode.com; bh=4Xhaj+JTlGuidkvQFOg0QFLxn6ZDMabKGf+s+Xq/Be8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OMUdTpnT73DSds8ghYz2sNclqaN7n+NX/qk/RkCAAamylmxELu1EOiNa1ccHfJKhPgylCV PvNECRcgD64cEIr1wPGi6uVNbUEqqy102oIr3/uoTYOLibbz0gb6hyGYt3RInVkxyZrCdI wm/8QqRiK1Rt8oyOX3hR2/uXTxg9XnU=; Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 15 Apr 2014 10:25:41 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (11B651) In-Reply-To: <5347E830.7070208@ninebynine.org> Date: Tue, 15 Apr 2014 10:30:20 +0100 Message-Id: References: <5343C547.3050204@ninebynine.org> <5347BCF1.7000504@it.aoyama.ac.jp> <5347E830.7070208@ninebynine.org> To: Graham Klyne MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NPZR1WV4TMmMKbqGOfxqdkogoLw Cc: Nevil Brownlee , "drafts-expert-review-comment@iana.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 09:25:49 -0000 Hi Graham, > On 11 Apr 2014, at 14:03, Graham Klyne wrote: >=20 >> On 11/04/2014 10:59, "Martin J. D=C3=BCrst" wrote: >> Hello Graham, >>=20 >> It is my understanding that RFCs in the independent stream go through an I= ETF >> conflict review. I think that would be one way to deal with registration >> proposals that would be considered harmful. >=20 > Hi Martin, >=20 > Thanks for the comment. I agree that the conflict review may be a way to d= eal with this. But I might also suggest that it lacks clarity for both subm= itter and reviewers. It's not clear to me if an IESG conflict review would r= egard an unreviewed permanent header registration as a conflict. >=20 > =46rom from the submitter's viewpoint, it would be better if the registrat= ion document itself were clearer on this point (which it currently is not). >=20 > I'm currently asking myself if the current confusion can be clarified thro= ugh a document erratum (I see this as a problem of drafting), but a change h= ere might be seen as substantive and requiring new review. >=20 > But before attacking any of that I'm hoping to get a sense of what a conse= nsus about permanent registration requirements might look like. (My own inc= lination would be to clarify the RFC requirement to be an "IETF stream RFC" p= er http://tools.ietf.org/html/rfc4844#section-5.1.1) What about header field registrations from other SDOs (e.g. W3C)? >=20 > #g > -- >=20 >>=20 >> Regards, Martin. >>=20 >>> On 2014/04/08 18:45, Graham Klyne wrote: >>> All, >>>=20 >>> TL;DR: should a permanent message header field registration be allowed >>> through an ISE RFC publication, which does not require IETF review? >>>=20 >>> ... >>>=20 >>> An issue has come up concerning permanent registration of a message >>> header field through an RFC independent stream editor (ISE) submission >>> (https://tools.ietf.org/html/rfc6548). >>>=20 >>> RFC 3864 says: >>> [[ >>> A Permanent Message Header Field Registry, intended for headers >>> defined in IETF standards-track documents, those that have >>> achieved a comparable level of community review, or are generally >>> recognized to be in widespread use. >>> ]] >>> -- http://tools.ietf.org/html/rfc3864#section-2.1 >>>=20 >>> But also: >>> [[ >>> A header registered in the Permanent Message Header Field Registry >>> MUST be published as an RFC or as an "Open Standard" in the sense >>> described by RFC 2026, section 7 [1], >>> ]] >>> -- http://tools.ietf.org/html/rfc3864#section-4.2.1 >>>=20 >>> The latter quote appears to allow permanent registration following *any*= >>> RFC publication. Specifically, it appears to allow permanent >>> registration following RFC publication through the RFC ISE stream, which= >>> does not require review within the IETF. As one of the original >>> drafters of the registration specification, I claim this was not >>> intended. At the time, (I think) I believed that independent submission= >>> RFCs were still subject to IETF,. or at least IESG, review. (I'm not >>> sure if this is also true of my co-editors, so I'm speaking for myself >>> here.) >>>=20 >>> My expectation was that a permanent header field registration could be >>> achieved through an IETF-reviewed informational RFC, as well as a >>> standards-track RFC. This flexibility was used, for example, to >>> grandfather entries into the permanent registry in >>> http://tools.ietf.org/html/rfc4229. >>>=20 >>> (In my role as reviewer for IANA) I have received a request to accept a >>> permanent registration from an ISE RFC submission that has not been >>> reviewed in the IETF, and have pushed back. But the requester makes the= >>> reasonable point that the section 4.2.1 text noted above provides no >>> explicit grounds for refusal of such a permanent registration. >>>=20 >>> In the current case, I would like to see the registration request >>> submitted for review on the designated mailing list >>> (ietf-message-headers@lists.ietf.org) (per >>> http://tools.ietf.org/html/rfc3864#section-4.3) and see what feedback it= >>> garners. >>>=20 >>> Under the circumstances, I think I should ask you, the IETF community, >>> whether it is reasonable to push back in circumstances which have come >>> about due to what is effectively a drafting error. And, more generally,= >>> does this community feel that it should be allowable to create permanent= >>> header field registry entries without undergoing IETF review? >>>=20 >>> RFC3864 also says: >>> [[ >>> The IESG is the final arbiter of any objection. >>> ]] >>> -- http://tools.ietf.org/html/rfc3864#section-4.4 >>>=20 >>> So there is process scope to refuse a permanent registration, even if >>> other conditions are met, if the IESG opines it should not be made. >>>=20 >>> (For the avoidance of doubt, I accept ISE submissions are perfectly >>> suitable mechanism for creating provisional registrations, it's just >>> permanent registration I'm questioning here.) >>>=20 >>> I welcome any thoughts and feedback. >>>=20 >>> #g >>> -- >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Apr 15 03:17:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7D1A03A5 for ; Tue, 15 Apr 2014 03:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubf1H6XZeCNo for ; Tue, 15 Apr 2014 03:17:21 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id C88AE1A03B3 for ; Tue, 15 Apr 2014 03:17:19 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Wa0QL-0005pj-r5; Tue, 15 Apr 2014 11:17:05 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Wa0QK-0000NS-2n; Tue, 15 Apr 2014 11:17:05 +0100 Message-ID: <534D039C.7080102@ninebynine.org> Date: Tue, 15 Apr 2014 11:02:04 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba References: <5343C547.3050204@ninebynine.org> <5347BCF1.7000504@it.aoyama.ac.jp> <5347E830.7070208@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OlloNtkie70gUJGKX7wy1E2GovI Cc: drafts-expert-review-comment@iana.org, Nevil Brownlee , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 10:17:23 -0000 Hi Barry, TL;DR: I'm looking to see some level of community review for permanent registrations. I don't think "specification required" implies that. In the near term, are you OK for me to apply what I claim was the *intent* rather than the letter of what is stated in RFC 3864 (e.g. ask for IETF review before agreeing to permanent registration)? For the longer term, revising BCP90/RFC3854 would seem to be the right thing to do. ... The original *intent* of the RFC3864 text was to be stronger than just "specification required" for permanent header field registration. For RFC-based publications, it was more like "IETF Review" to use a term from http://tools.ietf.org/html/rfc5226. I think that intent is stated at http://tools.ietf.org/html/rfc3864#section-2.1, but the registration requirements that follow, in that section and at http://tools.ietf.org/html/rfc3864#section-4.2, didn't allow for the RFC ISE stream. (Separately: allowing non-IETF standards seemed and seems to me to be a reasonable thing to allow, and by my understanding would allow new permanent header fields to be registered though, e.g., W3C recommendation-track publication, etc. I don't think that's a lowering of the bar.) So the drafting of the publication requirements is at odds with the stated intent. Which I think raises two questions: 1. Can this be treated as a drafting error and fixed accordingly? 2. My sense at the time of drafting RFC3864 was that the community felt that permanent header fields should undergo a level of review consistent with a standards action. Is this still the community view, or is there consensus to relax the requirements? My feeling is that relying on the designated expert to make technical judgement about specifications can be problematic. By their nature, header fields deal with a very broad range of technical issues, and it is difficult for a single reviewer to be conversant with the entire range of concerns involved, and hence to make judgement about whether the specifications are sufficient to enable interoperable implementation. As a reviewer, my approach has been to look for evidence of suitable review by a qualified community. Where I have technical concerns of my own, I separate them from my response as designated reviewer (unless there is a clear violation of a technical requirement). Thus, I think that your interpretation is slightly at odds with mine, because I was expecting to see some review beyond simply making a judgement about whether the specification is "properly done". For example, I would like to be able to ask for unreviewed proposals to be announced on the header fields review mailing list, with notifications to appropriate technical groups, so that they can be subjected to review (as described for non-RFC specifications per http://tools.ietf.org/html/rfc3864#section-4.3). I am not seeing this as an option under the "specification required" criteria, but maybe you see it differently? #g -- On 14/04/2014 22:09, Barry Leiba wrote: > Catching up... > >>> It is my understanding that RFCs in the independent stream go through an >>> IETF conflict review. I think that would be one way to deal with registration >>> proposals that would be considered harmful. >> >> Thanks for the comment. I agree that the conflict review may be a way to >> deal with this. But I might also suggest that it lacks clarity for both >> submitter and reviewers. It's not clear to me if an IESG conflict review >> would regard an unreviewed permanent header registration as a conflict. > > Right. 5742 limits what we can do in conflict reviews, and pushing > back on a problematic registration would be limited, I think, to a #5 > response, which is rather nuclear: > > 5. The IESG has concluded that this document extends an IETF protocol > in a way that requires IETF review and should therefore not be > published without IETF review and IESG approval. > >> I'm currently asking myself if the current confusion can be clarified >> through a document erratum (I see this as a problem of drafting), but a >> change here might be seen as substantive and requiring new review. > > Hm. > > Hm. > > I'm still thinking. > > On the one hand, as you point out in your first note, from your PoV > this is an erratum: if you had been aware of the confusion at > publication time, you'd have considered it an error and would have > clarified it. > > But on the other hand, the community (and the IESG) might well have > taken it at its word and expect to have IETF review. > > The backstop, though, is that it all goes through the designated > expert, who is a delegate of the IESG. I see that as the real > solution here. The way *I* interpret the text is that the > registration policy is "Specification Required", and it's up to the > judgment of the expert whether the specification is adequate and the > request is reasonable and properly done. > > I think we can live with that until someone wants to update 3864. > > Barry, Applications AD > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Apr 15 04:29:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF011A079F; Tue, 15 Apr 2014 04:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.337 X-Spam-Level: *** X-Spam-Status: No, score=3.337 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVZDE6jBJVpA; Tue, 15 Apr 2014 04:29:02 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id E0A331A02B2; Tue, 15 Apr 2014 04:29:01 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 628DA32E576; Tue, 15 Apr 2014 20:28:57 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 6c4f_0ded_2d3c4f7b_4ba8_40f1_be16_729f44ea9415; Tue, 15 Apr 2014 20:28:56 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 8162FC0374; Tue, 15 Apr 2014 20:28:56 +0900 (JST) Message-ID: <534D17EB.7010700@it.aoyama.ac.jp> Date: Tue, 15 Apr 2014 20:28:43 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John C Klensin , apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EW53Qz2bb1oOYpCjFS5QXyfRCu8 Cc: urn@ietf.org Subject: Re: [apps-discuss] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 11:29:04 -0000 Hello John, others, On 2014/04/14 22:11, John C Klensin wrote: > Hi. > > It seems wise to call the attention of this broader group to > something that is going on in URNBIS (and more generally). > This message is a personal opinion. It summarizes some > discussions in and around that WG but is not an attempt to > report on any sort of consensus. First, it may help to give a direct pointer to an actual draft: http://www.w3.org/DesignIssues/ModelConsequences > RFC 3986 on Generic URI Syntax was an attempt to create a > general syntax (and, despite its title, partial semantics) for > an extremely general set of resource identifiers, using > experience with and developments from URLs as a starting point. > The general URI concept was intended to including URLs, URNs, > and possible future types. For crucial background reading, please see http://www.w3.org/DesignIssues/ModelConsequences. Please don't come back here before you have read it! > That approach worked for URNs as > long as they preserved the very narrow definitions and syntax of > RFC 2141 but without taking advantage of any of the provisions > for extensibility ("future use") in that specification. Please have a look at http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/. This was worked out and written in collaboration with people from the IETF and from the library community. > In the nearly 20 years since RFC 2141 was published, experience > with URNs in various communities has demonstrated the need, with > some URN types (NIDs), to be able to specify operations or > retrieval of metadata as well as objects and for partial > retrieval or other operations on either metadata of the objects > themselves. At the same time, there have been forceful > discussions in information science, library, museum, and > publisher communities about the fundamental differences between > locators and names (which much of that community calls > "identifiers", excluding locators from that category) and the > disadvantages of mixing the two concepts. When it comes to books, and therefore in the library community, such a distinction is very natural. But there are still many use cases where it may make sense to be able to use one or the other kind of identifier in the same field. That's what URIs are all about. To use an (of course incomplete) analogy, it's a bit like the Internet and IP numbers: Before the Internet, there were various networks, and they used various different ways to identify their nodes. The Internet integrated them into a single address space, leading to great network effects. URIs do very much the same, just on a different level. > That might be mostly > a theoretical issue except that the URNBIS WG has found it > impossible to define the functionality it needs while remaining > within the syntax and semantic constraints of RFC 3986 (at least > without creating obvious and very ugly kludges). Your draft in question mentions quite a few requirements, but doesn't discuss at all how they would lead to kludges. Actually reading through the requirements, except for a couple of them, I have difficulties seeing even a shadow of needs for separate syntax. The conclusion of your draft comes out of the blue if it were not for the title. > The WG is now considering > draft-ietf-urnbis-urns-are-not-uris-00, which proposes to > separate URNs from RFC 3986, presumably leaving the latter with > URLs and name-like things that are not URNs. It may be worth > noting that there is now work in W3C and WHATWG on a new URL > definition. The intent of that work includes eventually > superceding 3986 (and 3987), at least for URLs, so there are > multiple forces working to dismember RFC 3986. As Julian already said, the WHATWG work is of a completely different nature and cannot and should not be used as a justification for creating more confusion. > However, the > URNBIS draft is intended to narrowly focus on the needs of URNs, > rather than trying to boil the URI ocean. Focusing narrowly on perceived differences in a specific case isn't the way to move forward. > Those who are interested in this topic should probably take a > look at the draft and the discussions during the last week or so > on the URN mailing list > (http://www.ietf.org/mail-archive/web/urn/). That list has > been fairly low-volume, so looking at those messages should not > be burdensome. Discussion should also occur on that list unless > there are very broad issues that belong here. Trying to split URI syntax is to the Web as e.g. claiming that servers and clients should be assigned different types of IP addresses. As such, this is in and of itself a broad issue that shouldn't be left to a list with limited coverage. Regards, Martin. From nobody Tue Apr 15 06:31:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93211A0660; Tue, 15 Apr 2014 06:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4r8NnBo9Gnq; Tue, 15 Apr 2014 06:31:41 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id B34001A046C; Tue, 15 Apr 2014 06:31:41 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Wa3SZ-0005kr-ap; Tue, 15 Apr 2014 14:31:35 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Wa3SY-0003tx-2p; Tue, 15 Apr 2014 14:31:35 +0100 Message-ID: <534D31B6.8080307@ninebynine.org> Date: Tue, 15 Apr 2014 14:18:46 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/E3AE0kIp3xMOJnjzqcRGXURpCIo Cc: urn@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:31:46 -0000 Hi John, I've just taken a look at http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00, and have some comments. I find myself asking what is gained by removing URNs from the scope of what we call URIs? At heart, the argument seems to be that not all locators are good names, and not all names are useful locators. I can't disagree with that. But that's not the same as saying all locators are not good names, or, conversely, all names are not useful locators. An example that comes to mind is the use of DOIs for academic research outputs, and in particular for research data sets (e.g. Datacite [6]). DOIs are conceived as names, and have the appropriate management processes around them applicable to names. But I have observed that in recent times, the preferred form for presenting DOIs to the Web has increasingly been in the form "http://dx.doi.org/..." or similar (see also: [1]). I think this exemplifies something that MAY be used as both identifier and name. One of the goals and strengths of URIs in the web has been that they encompass other systems of identification [2]. A key notion is that for some thing to be "on the web" it should have an assigned URI (or several). URNs regarded as a form of URI allow things that are named by other means, such as ISBN, DOI, etc., to be "on the web". http://tools.ietf.org/html/rfc2141 (appendix A) alludes to this by noting "The URN syntax has been defined so that URNs can be used in places where URLs are expected" (terminology that predates RFC3986) - so there is some recognized value here in being able to use names as URIs. For the Web, blurring the distinction between names and locators enables an incremental deployment of "follow your nose" information discovery, which in turn enables information discovery at a scale far beyond that which can be encompassed by any single managed namespace. Particularly when we consider a web of agents (and things), where we can create names that are also machine actionable without prior bilateral or multilateral agreement (beyond the existing ones that underpin the web itself). Ed Summers (who, among other things, put the LoC subject headings on the web [4]) offers this example [3]: [[ One of the benefits of linking data in this way is the follow your nose effect. When a person in their browser or an automated agent runs across the creator in the above triple they are able to dereference the URL and retrieve more information about this creator. For example when a software agent dereferences a URL for NISO. [...] This ability for humans and automated crawlers to follow their noses in this way makes for a powerfully simple data discovery heuristic. The philosophy is quite different from other data discovery methods, such as the typical web2.0 APIs of Flickr, Amazon, YouTube, Facebook, Google, etc., which all differ in their implementation details and require you to digest their API documentation before you can do anything useful. Contrast this with the Web of Data which uses the ubiquitous technologies of URIs and HTTP plus the secret sauce of the RDF triple. ]] At the level of technical implementation, the distinction between names and locators is, if not artificial, not as hard-and-fast as a fixed distinction (such as requiring that URNs are not URIs) would suggest. You point out that a key feature of names is that their meanings persist. Tim Berners-Lee has pointed out [5] that naming is a social and contractual issue, and that persistence is really a quality of service matter rather than something fundamentally apart from location. In summary, the qualities you require of a name *could* be applied to many forms of URI, especially http: URIs, subjected to appropriate policies and management practices. In conclusion, I am not seeing any practical way in which declaring URNs to be not-URIs actually helps to achieve the goals of URNs. I don't see any specific constraints imposed by RFC3986 that are inimical to being names. I'm not seeing any legal aspect of a URN (per http://tools.ietf.org/html/rfc2141) that isn't also allowed in a generic URI. (I think there are other reasons why URNs have not enjoyed widespread uptake, such as unnecessarily restrictive syntax, and in some cases an over-strict interpretation of persistence.) As they stand, having URNs as part of the URI "family" means that we have an assured way of using names that do satisfy the stated properties in a way that their referents may be first-class members of the class of entities that the Web, in all its richness, can describe. ... Nits: the RFC3986 link in the body text at http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00#section-3 is incorrectly linked. #g -- [1] http://www.doi.org/doi_handbook/2_Numbering.html#2.6 [2] http://www.w3.org/DesignIssues/Axioms.html#uri [3] http://inkdroid.org/journal/2008/01/04/following-your-nose-to-the-web-of-data/ [4] http://id.loc.gov/authorities/subjects.html (nee lcsh.info) [5] http://www.w3.org/DesignIssues/NameMyth.html [6] https://www.datacite.org On 14/04/2014 14:11, John C Klensin wrote: > Hi. > > It seems wise to call the attention of this broader group to > something that is going on in URNBIS (and more generally). > This message is a personal opinion. It summarizes some > discussions in and around that WG but is not an attempt to > report on any sort of consensus. > > RFC 3986 on Generic URI Syntax was an attempt to create a > general syntax (and, despite its title, partial semantics) for > an extremely general set of resource identifiers, using > experience with and developments from URLs as a starting point. > The general URI concept was intended to including URLs, URNs, > and possible future types. That approach worked for URNs as > long as they preserved the very narrow definitions and syntax of > RFC 2141 but without taking advantage of any of the provisions > for extensibility ("future use") in that specification. > > In the nearly 20 years since RFC 2141 was published, experience > with URNs in various communities has demonstrated the need, with > some URN types (NIDs), to be able to specify operations or > retrieval of metadata as well as objects and for partial > retrieval or other operations on either metadata of the objects > themselves. At the same time, there have been forceful > discussions in information science, library, museum, and > publisher communities about the fundamental differences between > locators and names (which much of that community calls > "identifiers", excluding locators from that category) and the > disadvantages of mixing the two concepts. That might be mostly > a theoretical issue except that the URNBIS WG has found it > impossible to define the functionality it needs while remaining > within the syntax and semantic constraints of RFC 3986 (at least > without creating obvious and very ugly kludges). > > The WG is now considering > draft-ietf-urnbis-urns-are-not-uris-00, which proposes to > separate URNs from RFC 3986, presumably leaving the latter with > URLs and name-like things that are not URNs. It may be worth > noting that there is now work in W3C and WHATWG on a new URL > definition. The intent of that work includes eventually > superceding 3986 (and 3987), at least for URLs, so there are > multiple forces working to dismember RFC 3986. However, the > URNBIS draft is intended to narrowly focus on the needs of URNs, > rather than trying to boil the URI ocean. > > Those who are interested in this topic should probably take a > look at the draft and the discussions during the last week or so > on the URN mailing list > (http://www.ietf.org/mail-archive/web/urn/). That list has > been fairly low-volume, so looking at those messages should not > be burdensome. Discussion should also occur on that list unless > there are very broad issues that belong here. > > thanks, > john > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Apr 15 06:31:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B071A046C for ; Tue, 15 Apr 2014 06:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEjYKmtP5a0k for ; Tue, 15 Apr 2014 06:31:43 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0F11A0601 for ; Tue, 15 Apr 2014 06:31:43 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Wa3SX-0004dk-pN; Tue, 15 Apr 2014 14:31:33 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Wa3SX-0003tr-1f; Tue, 15 Apr 2014 14:31:33 +0100 Message-ID: <534D1214.20506@ninebynine.org> Date: Tue, 15 Apr 2014 12:03:48 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <5343C547.3050204@ninebynine.org> <5347BCF1.7000504@it.aoyama.ac.jp> <5347E830.7070208@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VlOpdL3Uv5MHXBehQNdp-V45ktg Cc: "drafts-expert-review-comment@iana.org" , Nevil Brownlee , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:31:47 -0000 Hi Alexey, On 15/04/2014 10:30, Alexey Melnikov wrote: > Hi Graham, > >> On 11 Apr 2014, at 14:03, Graham Klyne wrote: >> >>> On 11/04/2014 10:59, "Martin J. Dürst" wrote: >>> Hello Graham, >>> >>> It is my understanding that RFCs in the independent stream go through an IETF >>> conflict review. I think that would be one way to deal with registration >>> proposals that would be considered harmful. >> >> Hi Martin, >> >> Thanks for the comment. I agree that the conflict review may be a way to deal with this. But I might also suggest that it lacks clarity for both submitter and reviewers. It's not clear to me if an IESG conflict review would regard an unreviewed permanent header registration as a conflict. >> >> From from the submitter's viewpoint, it would be better if the registration document itself were clearer on this point (which it currently is not). >> >> I'm currently asking myself if the current confusion can be clarified through a document erratum (I see this as a problem of drafting), but a change here might be seen as substantive and requiring new review. >> >> But before attacking any of that I'm hoping to get a sense of what a consensus about permanent registration requirements might look like. (My own inclination would be to clarify the RFC requirement to be an "IETF stream RFC" per http://tools.ietf.org/html/rfc4844#section-5.1.1) > > What about header field registrations from other SDOs (e.g. W3C)? I tend to regard a W3C recommendation track publication, or similar, as incorporating a good level of review. However, I would also interpret http://tools.ietf.org/html/rfc3864#section-4.3 as indicating that non-RFC publications should be submitted to ietf-message-headers@lists.ietf.org for review. I think that submission to ietf-message-headers@lists.ietf.org would be good practice for any registration. #g -- >> >>> >>> Regards, Martin. >>> >>>> On 2014/04/08 18:45, Graham Klyne wrote: >>>> All, >>>> >>>> TL;DR: should a permanent message header field registration be allowed >>>> through an ISE RFC publication, which does not require IETF review? >>>> >>>> ... >>>> >>>> An issue has come up concerning permanent registration of a message >>>> header field through an RFC independent stream editor (ISE) submission >>>> (https://tools.ietf.org/html/rfc6548). >>>> >>>> RFC 3864 says: >>>> [[ >>>> A Permanent Message Header Field Registry, intended for headers >>>> defined in IETF standards-track documents, those that have >>>> achieved a comparable level of community review, or are generally >>>> recognized to be in widespread use. >>>> ]] >>>> -- http://tools.ietf.org/html/rfc3864#section-2.1 >>>> >>>> But also: >>>> [[ >>>> A header registered in the Permanent Message Header Field Registry >>>> MUST be published as an RFC or as an "Open Standard" in the sense >>>> described by RFC 2026, section 7 [1], >>>> ]] >>>> -- http://tools.ietf.org/html/rfc3864#section-4.2.1 >>>> >>>> The latter quote appears to allow permanent registration following *any* >>>> RFC publication. Specifically, it appears to allow permanent >>>> registration following RFC publication through the RFC ISE stream, which >>>> does not require review within the IETF. As one of the original >>>> drafters of the registration specification, I claim this was not >>>> intended. At the time, (I think) I believed that independent submission >>>> RFCs were still subject to IETF,. or at least IESG, review. (I'm not >>>> sure if this is also true of my co-editors, so I'm speaking for myself >>>> here.) >>>> >>>> My expectation was that a permanent header field registration could be >>>> achieved through an IETF-reviewed informational RFC, as well as a >>>> standards-track RFC. This flexibility was used, for example, to >>>> grandfather entries into the permanent registry in >>>> http://tools.ietf.org/html/rfc4229. >>>> >>>> (In my role as reviewer for IANA) I have received a request to accept a >>>> permanent registration from an ISE RFC submission that has not been >>>> reviewed in the IETF, and have pushed back. But the requester makes the >>>> reasonable point that the section 4.2.1 text noted above provides no >>>> explicit grounds for refusal of such a permanent registration. >>>> >>>> In the current case, I would like to see the registration request >>>> submitted for review on the designated mailing list >>>> (ietf-message-headers@lists.ietf.org) (per >>>> http://tools.ietf.org/html/rfc3864#section-4.3) and see what feedback it >>>> garners. >>>> >>>> Under the circumstances, I think I should ask you, the IETF community, >>>> whether it is reasonable to push back in circumstances which have come >>>> about due to what is effectively a drafting error. And, more generally, >>>> does this community feel that it should be allowable to create permanent >>>> header field registry entries without undergoing IETF review? >>>> >>>> RFC3864 also says: >>>> [[ >>>> The IESG is the final arbiter of any objection. >>>> ]] >>>> -- http://tools.ietf.org/html/rfc3864#section-4.4 >>>> >>>> So there is process scope to refuse a permanent registration, even if >>>> other conditions are met, if the IESG opines it should not be made. >>>> >>>> (For the avoidance of doubt, I accept ISE submissions are perfectly >>>> suitable mechanism for creating provisional registrations, it's just >>>> permanent registration I'm questioning here.) >>>> >>>> I welcome any thoughts and feedback. >>>> >>>> #g >>>> -- >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Apr 15 06:31:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C7F1A046C; Tue, 15 Apr 2014 06:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMEpHtrZiwOZ; Tue, 15 Apr 2014 06:31:46 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 384FB1A0658; Tue, 15 Apr 2014 06:31:44 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Wa3Sa-00043R-i6; Tue, 15 Apr 2014 14:31:36 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Wa3Sa-0003u0-19; Tue, 15 Apr 2014 14:31:36 +0100 Message-ID: <534D3410.50607@ninebynine.org> Date: Tue, 15 Apr 2014 14:28:48 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John C Klensin References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> In-Reply-To: <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FYpCtltgpgR4xZmOHxsmRyQQBDA Cc: Julian Reschke , urn@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:31:48 -0000 John, Further to my other comments... On 14/04/2014 15:35, John C Klensin wrote: > ... But > what is driving this change is not theory, it is a need for new > functionality that just doesn't fit into the locator-oriented > 3986 model. That new functionality will require either new > syntax or old syntax with different semantics than those > specified in 3986. Maybe this is part of what is missing from your draft. RFC3986 semantics are pretty minimal/malleable, so I'm struggling to understand what you might need to add that violates RFC3986. (The main possible problem I can see would be possible interference with relative reference resolution, but that's not a problem if you avoid using '/' - which urns currently do) > ... Just as there is no such thing as a > 3986-conforming library that can completely and generally handle > queries (other than parsing the query away from other components > and dispatching it properly), such libraries are not likely to > be able to fully process URNs. > > Another piece of that issue is that comparison of two URNs for > equality is, in the general case, a rather different kind of > operation than comparison of two URLs; I would not expect a > URL-based algorithm (e.g., a RFC3986-conformant library) to be > able to get URN comparisons right, at least without NID-specific > action routines. So there's nothing new there. RFC3986 parsing is just a start - URI schemes all tend to have their own specific behaviours. (Which is part of why there is some push-back against arbitrary introduction of new schemes.) I'm not yet seeing the problem of adding NID-specific action routines as long as they don't vilate (minimal) RFC 3986 constraints. #g -- From nobody Tue Apr 15 09:25:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FA51A049C; Tue, 15 Apr 2014 09:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjqsngOioaRz; Tue, 15 Apr 2014 09:25:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 06AEE1A06C8; Tue, 15 Apr 2014 09:25:40 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.918.8; Tue, 15 Apr 2014 16:25:36 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0918.000; Tue, 15 Apr 2014 16:25:36 +0000 From: Larry Masinter To: Graham Klyne , John C Klensin Thread-Topic: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPWK8rf7UtytEgU0K4KmCUcXljmZsS2Rqw Date: Tue, 15 Apr 2014 16:25:36 +0000 Message-ID: <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> In-Reply-To: <534D3410.50607@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(99286001)(54356999)(85852003)(77096999)(50986999)(76176999)(74316001)(99396002)(80022001)(66066001)(83072002)(33646001)(81542001)(4396001)(15975445006)(20776003)(92566001)(74662001)(77982001)(74502001)(46102001)(86362001)(15202345003)(83322001)(80976001)(79102001)(19580395003)(31966008)(76482001)(87936001)(224303002)(2656002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:BC0BF004.8DF2D4C9.865C9E77.6D1F3F0.20227; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JoA42NPI3j5qDoxptpHjCTuhmZk Cc: "julian.reschke@gmx.de" , "urn@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:25:46 -0000 The only thing that makes something a name 'persistsent' is the existance o= f a name resolution service or method which persists. The syntax or namespace is irrelevant. 'persistent' isn't binary, it's jus= t "how long". Everything has a life-time. http://masinter.blogspot.com/2010/03/ozymandias-uri.html The meaning of a URI depends on the agreement of the community of a way of = resolving URIs of that form. http URIs meant using http/0.9, 1.0, 1.1, and now extended to encompass SPD= Y and HTTP/2. =20 Nominally, a URN is a URI that has some organization/resolution authority/r= esolution method, where the authority is believed to be persistent, and ava= ilable in the future to help resolve disputes, should they arise. =20 So when A communicates with B and wants to talk about something they both c= an see (a 'resource') A uses a URI or URN or URL. And B understands what A = meant because they both agree on what the UR* refers to. As the time betwee= n A sending and B reading and interpreting grows, the more important the pe= rsistence of the method by which B will understand what A meant. Is it time to revive http://tools.ietf.org/html/draft-masinter-dated-uri an= d finally get it to RFC? Larry -- http://larry.masinter.net From nobody Tue Apr 15 10:00:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6515E1A07D1 for ; Tue, 15 Apr 2014 10:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8-G5ct6Sw3j for ; Tue, 15 Apr 2014 10:00:38 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8872C1A0797 for ; Tue, 15 Apr 2014 10:00:37 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so7022171lbi.22 for ; Tue, 15 Apr 2014 10:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IXHWjZlkI2ejE5I0AUher5310BxQPRRm/N8y6kFXSA4=; b=oLWn9677iWNAZVVBR9Ra4MEHcjWQ/eF3t2Ewj6wuhmY2ocSAgJ+Y9MhP0AmTSNZXWw tWhCQKnow9xW7S8796cb3L+VX5ifFyNbRkYIXl/GvyTRcbpPxXG/H0XQxNMdTq4UZlgX Its7aI1fQiExeRo2JEBByJgiQ0wsGVd/Y8w4l/H7lM/o2RkD8zw/aNvjKKVWmuKJ2xZf 9OGWDVmWZwMh8rMH4x+m2qvu9ItgJDWbVwEWOKO9gpVZUSjQ2aoDhAlqBGz6SkIym4DU YaMejHhYm9FR6gxhDpBo2Pu5ww1ldo8N1Qe29PskZYUqFDhhSqfHBTScn+Lj5pL5dCDr Ez5A== MIME-Version: 1.0 X-Received: by 10.112.31.163 with SMTP id b3mr1833291lbi.61.1397581233765; Tue, 15 Apr 2014 10:00:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.148.97 with HTTP; Tue, 15 Apr 2014 10:00:33 -0700 (PDT) In-Reply-To: <534D039C.7080102@ninebynine.org> References: <5343C547.3050204@ninebynine.org> <5347BCF1.7000504@it.aoyama.ac.jp> <5347E830.7070208@ninebynine.org> <534D039C.7080102@ninebynine.org> Date: Tue, 15 Apr 2014 13:00:33 -0400 X-Google-Sender-Auth: TZM164Dl6-QH7sH-ESFOuLtfsQ8 Message-ID: From: Barry Leiba To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KJkAhRrtLFOp6YNQ_VBfBl6jsek Cc: drafts-expert-review-comment@iana.org, Nevil Brownlee , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 17:00:41 -0000 > TL;DR: I'm looking to see some level of community review for permanent > registrations. Ack. And what I was trying to say in the on-list message is that at the first level, we're ok now: the DE can make a judgment about whether there's been enough review, and can ask for more. Nevil is always eager to get the right review for documents, and will work with you on it. IOW, I think the existing registration process can work fine for us for now, until we update it. We do still have to decide whether it's really necessary for header fields to have such thorough review -- I'm not convinced. But in the meantime, the DE's judgment can drive whatever review we want for now. b > I don't think "specification required" implies that. In the > near term, are you OK for me to apply what I claim was the *intent* rather > than the letter of what is stated in RFC 3864 (e.g. ask for IETF review > before agreeing to permanent registration)? For the longer term, revising > BCP90/RFC3854 would seem to be the right thing to do. > > ... > > The original *intent* of the RFC3864 text was to be stronger than just > "specification required" for permanent header field registration. For > RFC-based publications, it was more like "IETF Review" to use a term from > http://tools.ietf.org/html/rfc5226. > > I think that intent is stated at > http://tools.ietf.org/html/rfc3864#section-2.1, but the registration > requirements that follow, in that section and at > http://tools.ietf.org/html/rfc3864#section-4.2, didn't allow for the RFC ISE > stream. > > (Separately: allowing non-IETF standards seemed and seems to me to be a > reasonable thing to allow, and by my understanding would allow new permanent > header fields to be registered though, e.g., W3C recommendation-track > publication, etc. I don't think that's a lowering of the bar.) > > So the drafting of the publication requirements is at odds with the stated > intent. Which I think raises two questions: > > 1. Can this be treated as a drafting error and fixed accordingly? > > 2. My sense at the time of drafting RFC3864 was that the community felt that > permanent header fields should undergo a level of review consistent with a > standards action. Is this still the community view, or is there consensus > to relax the requirements? > > My feeling is that relying on the designated expert to make technical > judgement about specifications can be problematic. By their nature, header > fields deal with a very broad range of technical issues, and it is difficult > for a single reviewer to be conversant with the entire range of concerns > involved, and hence to make judgement about whether the specifications are > sufficient to enable interoperable implementation. As a reviewer, my > approach has been to look for evidence of suitable review by a qualified > community. Where I have technical concerns of my own, I separate them from > my response as designated reviewer (unless there is a clear violation of a > technical requirement). > > Thus, I think that your interpretation is slightly at odds with mine, > because I was expecting to see some review beyond simply making a judgement > about whether the specification is "properly done". For example, I would > like to be able to ask for unreviewed proposals to be announced on the > header fields review mailing list, with notifications to appropriate > technical groups, so that they can be subjected to review (as described for > non-RFC specifications per http://tools.ietf.org/html/rfc3864#section-4.3). > I am not seeing this as an option under the "specification required" > criteria, but maybe you see it differently? > > #g > -- > > > On 14/04/2014 22:09, Barry Leiba wrote: >> >> Catching up... >> >>>> It is my understanding that RFCs in the independent stream go through an >>>> IETF conflict review. I think that would be one way to deal with >>>> registration >>>> proposals that would be considered harmful. >>> >>> >>> Thanks for the comment. I agree that the conflict review may be a way to >>> deal with this. But I might also suggest that it lacks clarity for both >>> submitter and reviewers. It's not clear to me if an IESG conflict review >>> would regard an unreviewed permanent header registration as a conflict. >> >> >> Right. 5742 limits what we can do in conflict reviews, and pushing >> back on a problematic registration would be limited, I think, to a #5 >> response, which is rather nuclear: >> >> 5. The IESG has concluded that this document extends an IETF protocol >> in a way that requires IETF review and should therefore not be >> published without IETF review and IESG approval. >> >>> I'm currently asking myself if the current confusion can be clarified >>> through a document erratum (I see this as a problem of drafting), but a >>> change here might be seen as substantive and requiring new review. >> >> >> Hm. >> >> Hm. >> >> I'm still thinking. >> >> On the one hand, as you point out in your first note, from your PoV >> this is an erratum: if you had been aware of the confusion at >> publication time, you'd have considered it an error and would have >> clarified it. >> >> But on the other hand, the community (and the IESG) might well have >> taken it at its word and expect to have IETF review. >> >> The backstop, though, is that it all goes through the designated >> expert, who is a delegate of the IESG. I see that as the real >> solution here. The way *I* interpret the text is that the >> registration policy is "Specification Required", and it's up to the >> judgment of the expert whether the specification is adequate and the >> request is reasonable and properly done. >> >> >> I think we can live with that until someone wants to update 3864. >> >> Barry, Applications AD >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > From nobody Tue Apr 15 10:38:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72201A036F; Tue, 15 Apr 2014 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP5cJGUIGbcv; Tue, 15 Apr 2014 10:38:15 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DA31F1A02E3; Tue, 15 Apr 2014 10:38:14 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so7237466lbj.31 for ; Tue, 15 Apr 2014 10:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8SpoLdBcRNNdL82kdfywka2u3Evq7kV6wtWBu4unzIo=; b=OU+FuBg5CRmYSs7AwTfH4KuPgopavOC9kS/K2suOsgEqZwIDsfSYR2t7VdbBjkHNi8 oyMlcXpANHskf9XJ0gorgq+YYrugl3HLolcjTwk/ztNjchWdYed2aw+ehufA0yl+cZVi hqdoKjk0myw2A3PwJLUDmJJhw3p6fKdIr+cw/oLhlPqticU420fAs+qJkZSW3fNR8DrN jVI/XQ25HtjlRl3rIv/MTCJ85IWuEA0yj+GHRJH2rLCW2ERoQAcfFESlRIFxUZrtQNEO +cDNRqz0nup7u0JRixAeVpE+O7pwMXAs6gzhkdYFG/ZPokqV5nrgnb+oCZYg3QRHHnU9 Ssjg== MIME-Version: 1.0 X-Received: by 10.112.254.163 with SMTP id aj3mr2037713lbd.20.1397583491328; Tue, 15 Apr 2014 10:38:11 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 15 Apr 2014 10:38:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 20:38:10 +0300 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-oJfqaZyZadaPrZO0-XC2izVKmc Cc: urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 17:38:20 -0000 I disagree strongly. A URI is any string that fits in the URI slot in existing protocols and will continue to be so regardless of decisions made here. We should redefine the syntax of URIs to be a label followed by a colon followed by any sequence of non-whitespace characters. URI = label ':' anything label = [a-z, 1-9, A-Z] + anything = [not-whitespace]* That should give the URN world more than enough scope. All they need to do is to make sure their URN encoding escapes significant whitespace which is probably an essential success criteria in any case. The syntax I give is pretty much the definition of a URI used in pretty much all code that attempts to turn text into hyperlinks that is not limited to http and https. On Mon, Apr 14, 2014 at 4:11 PM, John C Klensin wrote: > Hi. > > It seems wise to call the attention of this broader group to > something that is going on in URNBIS (and more generally). > This message is a personal opinion. It summarizes some > discussions in and around that WG but is not an attempt to > report on any sort of consensus. > > RFC 3986 on Generic URI Syntax was an attempt to create a > general syntax (and, despite its title, partial semantics) for > an extremely general set of resource identifiers, using > experience with and developments from URLs as a starting point. > The general URI concept was intended to including URLs, URNs, > and possible future types. That approach worked for URNs as > long as they preserved the very narrow definitions and syntax of > RFC 2141 but without taking advantage of any of the provisions > for extensibility ("future use") in that specification. > > In the nearly 20 years since RFC 2141 was published, experience > with URNs in various communities has demonstrated the need, with > some URN types (NIDs), to be able to specify operations or > retrieval of metadata as well as objects and for partial > retrieval or other operations on either metadata of the objects > themselves. At the same time, there have been forceful > discussions in information science, library, museum, and > publisher communities about the fundamental differences between > locators and names (which much of that community calls > "identifiers", excluding locators from that category) and the > disadvantages of mixing the two concepts. That might be mostly > a theoretical issue except that the URNBIS WG has found it > impossible to define the functionality it needs while remaining > within the syntax and semantic constraints of RFC 3986 (at least > without creating obvious and very ugly kludges). > > The WG is now considering > draft-ietf-urnbis-urns-are-not-uris-00, which proposes to > separate URNs from RFC 3986, presumably leaving the latter with > URLs and name-like things that are not URNs. It may be worth > noting that there is now work in W3C and WHATWG on a new URL > definition. The intent of that work includes eventually > superceding 3986 (and 3987), at least for URLs, so there are > multiple forces working to dismember RFC 3986. However, the > URNBIS draft is intended to narrowly focus on the needs of URNs, > rather than trying to boil the URI ocean. > > Those who are interested in this topic should probably take a > look at the draft and the discussions during the last week or so > on the URN mailing list > (http://www.ietf.org/mail-archive/web/urn/). That list has > been fairly low-volume, so looking at those messages should not > be burdensome. Discussion should also occur on that list unless > there are very broad issues that belong here. > > thanks, > john > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Website: http://hallambaker.com/ From nobody Wed Apr 16 06:21:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428BE1A018E for ; Wed, 16 Apr 2014 06:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L446SrU0j6a for ; Wed, 16 Apr 2014 06:21:30 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 150F11A0190 for ; Wed, 16 Apr 2014 06:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1397654482; d=isode.com; s=selector; i=@isode.com; bh=H25u0dblSYLk6Fg7RPufoASEzusN7TGFiCs06P8M4vQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=iGlNB6tiK0kgIUG94OUXdTQIEgkjoUGLUlHahf/gyZTu216zrMwoPOgRVXSD+SfUHl5UBi 0Y22xVHlXEteEDC/Lu2+3BE6DhMbtCii7KAWHlxiHnMOOJ8OdOFZYmowmByLg+7eycnfFl cCU6xdqCYrlCjeuF62j/brMwWdgGA0M=; Received: from dhcp-193.isode.net (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 16 Apr 2014 14:21:12 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Kurt Zeilenga In-Reply-To: <534D039C.7080102@ninebynine.org> Date: Wed, 16 Apr 2014 14:20:53 +0100 Message-Id: <922B1B0A-D1D5-4B7C-A42C-FDB537C89849@isode.com> References: <5343C547.3050204@ninebynine.org> <5347BCF1.7000504@it.aoyama.ac.jp> <5347E830.7070208@ninebynine.org> <534D039C.7080102@ninebynine.org> To: Graham Klyne X-Mailer: Apple Mail (2.1877.7) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Apple-Mail=_75D3597C-9B73-4321-A568-8CD559F3E0D7" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EEitl8ieP07Dj7YP9dASvgGvUek Cc: drafts-expert-review-comment@iana.org, Barry Leiba , "apps-discuss@ietf.org" , Nevil Brownlee Subject: Re: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:21:35 -0000 --Apple-Mail=_75D3597C-9B73-4321-A568-8CD559F3E0D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 15, 2014, at 11:02 AM, Graham Klyne wrote: > TL;DR: I'm looking to see some level of community review for permanent = registrations. Which community do you mean here? The Internet community? The IETF = community? some other? All I-D are available for community review and those submitted to the = ISE for independent review have significant review as part of that = process. Of course, this is not the same as IETF Review (or IETF = Consensus). =97 Kurt= --Apple-Mail=_75D3597C-9B73-4321-A568-8CD559F3E0D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

TL;DR: I'm looking to see some level = of community review for permanent = registrations.

Which community do you = mean here?  The Internet community?  The IETF community? some = other?

All I-D are available for community = review and those submitted to the ISE for independent review have = significant review as part of that process.  Of course, this is not = the same as IETF Review (or IETF Consensus).

=97 = Kurt
= --Apple-Mail=_75D3597C-9B73-4321-A568-8CD559F3E0D7-- From nobody Wed Apr 16 08:56:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978F31A0206 for ; Wed, 16 Apr 2014 08:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGkejKfJ25rE for ; Wed, 16 Apr 2014 08:56:36 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD6A1A01E6 for ; Wed, 16 Apr 2014 08:56:36 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id pv20so8251674lab.37 for ; Wed, 16 Apr 2014 08:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pZNvSUdcHP8fxJIdbfEOHolA3HWKM4zIeKEZu9uD3wg=; b=AqRjNwRwrYW+8pzjxCywPI5ru9GdKskM9nihwOQ5KY/1iYL/BAoHLqve1wz380Ij3Y r2Am9M5kRWtjSGv1Tqv8VQCJs800SEuDyzOh+ufIJNtD6rwC6ZULbUjwNd25ehtSZQK1 PNbtNLdK3Aj1mEX0kb3X4oDsjMJysEE21gwDTUdOhwlojBaWewsbIzHh8ExN3HTaOGS7 oZNrxVA4BAOLuG5hGMj3x26/cTREZzauk6IBmAbvRWOGDv9cuSylp22eID0lhYq00t2v clSpPOyPdokQg/eCnJYrv9jipq/weoSLHkLYCda6FSLuLs3LO6s/G/QMpPJ3AOMFDTTh Sf5A== MIME-Version: 1.0 X-Received: by 10.152.234.130 with SMTP id ue2mr5992553lac.0.1397663792324; Wed, 16 Apr 2014 08:56:32 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.148.97 with HTTP; Wed, 16 Apr 2014 08:56:32 -0700 (PDT) In-Reply-To: <20140328105940.ADCCF7FC2CB@rfc-editor.org> References: <20140328105940.ADCCF7FC2CB@rfc-editor.org> Date: Wed, 16 Apr 2014 11:56:32 -0400 X-Google-Sender-Auth: 5ZsyEXMnGGHKWO0loArDIYjD4XA Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3VHpjfsm0ubqPy3M7VGyfa6K4KU Cc: Myunggyun Jonathan Aldo Seo Subject: Re: [apps-discuss] [Technical Errata Reported] RFC1459 (3938) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:56:40 -0000 Myunggyun Jonathan Aldo Seo has reported the errata below, on RFC 1459, the IRC protocol. He's correct that the last paragraph of Section 4.2.3.1 has clearly been truncated. But, as this is a more-than-20-year-old document, it's likely hard to know what the text was intended to say. Here's Section 4.2.3.1 in its entirety: ------------------------------------- 4.2.3.1 Channel modes Parameters: {[+|-]|o|p|s|i|t|n|b|v} [] [] [] The MODE command is provided so that channel operators may change the characteristics of `their' channel. It is also required that servers be able to change channel modes so that channel operators may be created. The various modes available for channels are as follows: o - give/take channel operator privileges; p - private channel flag; s - secret channel flag; i - invite-only channel flag; t - topic settable by channel operator only flag; n - no messages to channel from clients on the outside; m - moderated channel; l - set the user limit to channel; b - set a ban mask to keep users out; v - give/take the ability to speak on a moderated channel; k - set a channel key (password). When using the 'o' and 'b' options, a restriction on a total of three per mode command has been imposed. That is, any combination of 'o' and ------------------------------------- I would like to mark the errata report as Verified, but it would be nice to be able to suggest correct text in the report. Can anyone help figure out what was supposed to be there? If not, I'll likely mark it "Held For Document Update" instead. Barry On Fri, Mar 28, 2014 at 6:59 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC1459, > "Internet Relay Chat Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=1459&eid=3938 > > -------------------------------------- > Type: Technical > Reported by: Myunggyun Jonathan Aldo Seo > > Section: 4.2.3.1 > > Original Text > ------------- > When using the 'o' and 'b' options, a restriction on a total of three > per mode command has been imposed. That is, any combination of 'o' > and > > Corrected Text > -------------- > > > Notes > ----- > The sentence lacks the last part and does not explain what it expected to. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC1459 (no draft string recorded) > -------------------------------------- > Title : Internet Relay Chat Protocol > Publication Date : May 1993 > Author(s) : J. Oikarinen, D. Reed > Category : EXPERIMENTAL > Source : Legacy > Area : Legacy > Stream : IETF > Verifying Party : IESG > From nobody Wed Apr 16 09:53:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15681A023D for ; Wed, 16 Apr 2014 09:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCdRH8IlH3qn for ; Wed, 16 Apr 2014 09:53:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) by ietfa.amsl.com (Postfix) with ESMTP id 856451A025A for ; Wed, 16 Apr 2014 09:53:21 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.0.918.8; Wed, 16 Apr 2014 16:53:17 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 16:53:16 +0000 From: Dave Thaler To: Barry Leiba , Apps Discuss Thread-Topic: [apps-discuss] [Technical Errata Reported] RFC1459 (3938) Thread-Index: AQHPWYx4AbyHkJrmUUmL6CfObdfh4psUdHNg Date: Wed, 16 Apr 2014 16:53:15 +0000 Message-ID: References: <20140328105940.ADCCF7FC2CB@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(13464003)(24454002)(377454003)(51704005)(46102001)(4396001)(50986999)(87936001)(2656002)(76576001)(31966008)(74502001)(99396002)(99286001)(76176999)(77096999)(54356999)(77982001)(81342001)(79102001)(81542001)(74316001)(33646001)(74662001)(85852003)(16799955002)(15202345003)(86362001)(83072002)(92566001)(19580405001)(83322001)(19580395003)(551544002)(15188155005)(76482001)(80022001)(66066001)(86612001)(20776003)(80976001)(15975445006)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:EE6FF17E.AFE2D2E0.B9C33EBB.CAE5AD6F.20443; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lU02mYSwFo6Zgybt_JnAG4h1j2M Cc: Myunggyun Jonathan Aldo Seo Subject: Re: [apps-discuss] [Technical Errata Reported] RFC1459 (3938) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:53:30 -0000 I observe that several sources that derive text from this RFC simply drop t= he truncated sentence: http://www.cs.cmu.edu/~srini/15-441/S05/assignments/project1/rfc-html/print= .html http://www.iternet.biz/Knowledge/Indy9/007493.html -Dave > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of > Barry Leiba > Sent: Wednesday, April 16, 2014 8:57 AM > To: Apps Discuss > Cc: Myunggyun Jonathan Aldo Seo > Subject: Re: [apps-discuss] [Technical Errata Reported] RFC1459 (3938) >=20 > Myunggyun Jonathan Aldo Seo has reported the errata below, on RFC 1459, > the IRC protocol. He's correct that the last paragraph of Section 4.2.3.= 1 has > clearly been truncated. But, as this is a more-than-20-year-old document= , it's > likely hard to know what the text was intended to say. >=20 > Here's Section 4.2.3.1 in its entirety: >=20 > ------------------------------------- > 4.2.3.1 Channel modes >=20 > Parameters: {[+|-]|o|p|s|i|t|n|b|v} [] [] > [] >=20 > The MODE command is provided so that channel operators may change the > characteristics of `their' channel. It is also required that servers > be able to change channel modes so that channel operators may be > created. >=20 > The various modes available for channels are as follows: >=20 > o - give/take channel operator privileges; > p - private channel flag; > s - secret channel flag; > i - invite-only channel flag; > t - topic settable by channel operator only flag; > n - no messages to channel from clients on the outside; > m - moderated channel; > l - set the user limit to channel; > b - set a ban mask to keep users out; > v - give/take the ability to speak on a moderated channel; > k - set a channel key (password). >=20 > When using the 'o' and 'b' options, a restriction on a total of three > per mode command has been imposed. That is, any combination of 'o' > and > ------------------------------------- >=20 > I would like to mark the errata report as Verified, but it would be nice = to be > able to suggest correct text in the report. Can anyone help figure out w= hat > was supposed to be there? If not, I'll likely mark it "Held For Document > Update" instead. >=20 > Barry >=20 > On Fri, Mar 28, 2014 at 6:59 AM, RFC Errata System editor.org> wrote: > > The following errata report has been submitted for RFC1459, "Internet > > Relay Chat Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D1459&eid=3D3938 > > > > -------------------------------------- > > Type: Technical > > Reported by: Myunggyun Jonathan Aldo Seo > > > > Section: 4.2.3.1 > > > > Original Text > > ------------- > > When using the 'o' and 'b' options, a restriction on a total of thre= e > > per mode command has been imposed. That is, any combination of 'o' > > and > > > > Corrected Text > > -------------- > > > > > > Notes > > ----- > > The sentence lacks the last part and does not explain what it expected = to. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party (IESG) can log in to > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC1459 (no draft string recorded) > > -------------------------------------- > > Title : Internet Relay Chat Protocol > > Publication Date : May 1993 > > Author(s) : J. Oikarinen, D. Reed > > Category : EXPERIMENTAL > > Source : Legacy > > Area : Legacy > > Stream : IETF > > Verifying Party : IESG > > >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Apr 16 11:02:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0751A069A; Tue, 15 Apr 2014 11:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.283 X-Spam-Level: ** X-Spam-Status: No, score=2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK0fjsPAjua4; Tue, 15 Apr 2014 11:20:57 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 938DB1A069C; Tue, 15 Apr 2014 11:20:57 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wa7S6-0007Dt-Hf; Tue, 15 Apr 2014 13:47:22 -0400 Date: Tue, 15 Apr 2014 13:47:22 -0400 From: John C Klensin To: Larry Masinter , Graham Klyne Message-ID: <952E89C207E59D25CD5953D6@JCK-EEE10> In-Reply-To: <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2pKdSFwXWy30ze6J860M3Wdfayk X-Mailman-Approved-At: Wed, 16 Apr 2014 11:02:45 -0700 Cc: julian.reschke@gmx.de, urn@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:21:02 -0000 Hi. Just wanted to tell folks that I'm on a very poor connection (if on at all) for the next couple of days and probably won't be able to give careful answers until Thursday and probably should not try. But one very quick observation in response to part of Larry's note... --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter wrote: > The only thing that makes something a name 'persistsent' is > the existence of a name resolution service or method which > persists. The syntax or namespace is irrelevant. 'persistent' > isn't binary, it's just "how long". Everything has a = life-time. >=20 > http://masinter.blogspot.com/2010/03/ozymandias-uri.html I think the above largely misses the point and that, in a sense, your blog posting illustrates the point although not in the way you probably intend. "Persistent identifier" entered the IETF vocabulary a long time ago but may not be very look terminology. Some objects -- like stone statues if one doesn't care whether they remain intact and standing-- have very long life expectancies. Others, like people, have shorter ones. But URIs (with or within including URNs) aren't objects, they are object reference that, like most good references, involve some degree of abstraction. Now, "Ozymandias" is a very long-persistent reference. It isn't the object. It is a somewhat ambiguous reference because it can refer to the statue, the poem, your blog posting, and probably several other things, but has a long duration, perhaps one that is long enough to survive the objects it references (just like titles of long-lost books). But, as a reference, it is that persistent because it is not bound to a retrieval mechanism that has its own persistence properties.=20 Whatever its other properties, http://masinter.blogspot.com/2010/03/ozymandias-uri.html is lousy as a persistent identifier. It depends on the availability of "http" (or something called that) as a retrieval mechanism. It depends on there being a DNS, on there being a TLD named "com" an SLD named "blogspot", and both of them having certain properties of which HTTP can take advantage. "Ozymandias", and even the potential URN urn:poems:Shelley/Ozymandias are more persistent because they represent a higher level of abstraction and are not tied to either a location or a retrieval/access method. Use of a hypothetical ISPN (International Standard Poem Identifier) in the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or might not be more persistent: it would be an exact identifier of something and makes equivalence comparison more feasible and less ambiguous, but it is probably tied to a database to actually identify an object and such databases may be more or less available and persistent than access methods and/or the DNS (which is, after all, just another database). Regardless of what one calls them, I suggest that access-method-dependent identifiers (http:..., NineTrackTape:??42.3744=C2=B0?N,?71.1169=C2=B0?W?123456 (where = "?" represents one or more carefully-chosen delimiters that may not have RFC 3986 semantics), ...) are different kinds of creatures than either the objects to which they refer or names of those objects that are not, in the sense of the above, method or location-model dependent. More soon. john From nobody Wed Apr 16 11:03:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BDE1A0322; Tue, 15 Apr 2014 11:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_xSJgno9UBE; Tue, 15 Apr 2014 11:40:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8224E1A0503; Tue, 15 Apr 2014 11:40:56 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wa8Hm-0007KV-Ct; Tue, 15 Apr 2014 14:40:46 -0400 Date: Tue, 15 Apr 2014 14:40:46 -0400 From: John C Klensin To: Phillip Hallam-Baker Message-ID: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/i3bwfkUO2HExBsP4LIfOArESG0Q X-Mailman-Approved-At: Wed, 16 Apr 2014 11:03:09 -0700 Cc: urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:41:01 -0000 Actually, we don't disagree on anything but language and tactics. Specifically, the underlying problem is that there are semantic (and maybe syntax) constraints in RFC 3986 that make it, and its definition of "URI" unsuitable for some plausible and important class of identifiers (especially those, or a subset of them, whose "methods" are not tied to a particular retrieval or processing protocol (note that "SIP:" and "Mailto" are really no different from "http" in that regard). One can avoid recognizing that it is problem and try to force all identifiers into the Procrustean bed defined by 3986. That isn't working well. Its ultimate result is almost certain to be the development of object identifier standards away from the IETF and W3C and the need to adapt to that bed. Indeed, that has already occurred; note the Handle System and the closely-related DOIs. Or one can recognize the problem and try to deal with it. It seems to me that there are several ways that problem can be addressed, in more or less decreasing order of drasticness. (1) Discard RFC 3986 entirely, adopt the syntax convention you suggest (URI = label ':' anything), and leave each method definition to its own devices. (2) Revise and replace 3986 in a way that removes all of the semantic definitions and constraints, leaving only the generic syntax. I think that the result would be workable but, unlike the "every method defines its own syntax within 'anything'" model above, I can't prove it. And, having explored that option, it turns out that removing the subtle semantic constraints from 3986 is not easy. (See the thread in the URN mailing list for more about this.) (3) Redefine 3986 as applying only to URLs. If you have a URI type (i.e., a method) and define it as a URL, you get to incorporate 3986 by reference and use its syntax and semantics without repeating them. If you don't make that declaration, you are on your own, much as in (1) above. (4) Come up with a new typology of URIs and then remove one or more of types from the scope of 3986. Of course, as Larry's insistence that there is really no such things as a persistent identifier shows, coming up with such a typology and reaching agreement about it is not straightforward. (5) Remove URNs from the scope of 3986, leaving everything that doesn't use the pseudo-method "urn:" within the scope of 3986 until and unless they demonstrate why they should be removed too. Approach (5) is the one suggested in the draft, not because I think it would be optimal in the best of all possible worlds, but because it appears to be something that the URNBIS WG can do and that would allow it to move forward. FWIW, the practical difference among some of those approaches is ultimately the old issue about the difference between inclusion-based and exclusion-based models. RFC 3986 effectively says "all identifiers are URIs and should (or must) conform to this model. As soon as we get to "except those that don't", one can either identify those that don't or those that do. Of course, if we were to shift to the much more generic model of (1), number of things that would need to be excluded would presumably be far fewer. best, john --On Tuesday, 15 April, 2014 20:38 +0300 Phillip Hallam-Baker wrote: > I disagree strongly. > > A URI is any string that fits in the URI slot in existing > protocols and will continue to be so regardless of decisions > made here. > > We should redefine the syntax of URIs to be a label followed > by a colon followed by any sequence of non-whitespace > characters. > > URI = label ':' anything > > label = [a-z, 1-9, A-Z] + > anything = [not-whitespace]* > > That should give the URN world more than enough scope. All > they need to do is to make sure their URN encoding escapes > significant whitespace which is probably an essential success > criteria in any case. > > The syntax I give is pretty much the definition of a URI used > in pretty much all code that attempts to turn text into > hyperlinks that is not limited to http and https. > > On Mon, Apr 14, 2014 at 4:11 PM, John C Klensin > wrote: >> Hi. >> >> It seems wise to call the attention of this broader group to >> something that is going on in URNBIS (and more generally). >> This message is a personal opinion. It summarizes some >> discussions in and around that WG but is not an attempt to >> report on any sort of consensus. >> >> RFC 3986 on Generic URI Syntax was an attempt to create a >> general syntax (and, despite its title, partial semantics) for >> an extremely general set of resource identifiers, using From nobody Wed Apr 16 11:58:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAE21A02AF; Wed, 16 Apr 2014 11:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9jxmfkxme3d; Wed, 16 Apr 2014 11:58:36 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id E723D1A02C2; Wed, 16 Apr 2014 11:58:30 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id n15so8526025lbi.13 for ; Wed, 16 Apr 2014 11:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IKWc6KTMmk2Zld9RPrjkzenS8PmjgvFrx8G8AxH499w=; b=AR0jOxwXm+gA5WBZVS+cmzr0p2CJG62PQipGkeJs2Vpp7/aeynR9bP6jXiKaiQzUAT L/dlB2Pj9HGSLV42kC/lR4J9ZSIF9cLDLtx9kLt4jvocyjweribwsu5szNZ+T44NzBtP debUC+t83No2m2cCFvXLAqk1fBBfhT51BwcjR/gA7TN7dt3VLvWOiIj07Q+RAiv8+699 fkd9NdNKP6vm8b0YCVOd6D8Q7i6BAbyDGXWatq7pdjei/oJnoBtY6xMM+KQ+2Llb6TmO NZuN6Nx6bFLC41pHqXm2ZSYEz+KAIuK6L4ZyeIqnbNYO74HfzDzre42qGYPMi/VOAVzn i3sw== MIME-Version: 1.0 X-Received: by 10.152.205.98 with SMTP id lf2mr2086064lac.60.1397674706749; Wed, 16 Apr 2014 11:58:26 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 16 Apr 2014 11:58:26 -0700 (PDT) In-Reply-To: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> Date: Wed, 16 Apr 2014 21:58:26 +0300 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/m1dbAwDkRc_DnnsK2o-4FbhjzYw Cc: urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 18:58:41 -0000 On Tue, Apr 15, 2014 at 9:40 PM, John C Klensin wrote: > Actually, we don't disagree on anything but language and tactics. I understood that. It is a specification so language is rather important. I don't like the suggestion that the URI slot in the existing protocols no longer includes URNs. But I am more than happy to toss virtually the entire URI syntax out. I am also rather suspicious of the idea that the difference between URNs and URLs is that one is a name and the other is an index. Both are both. The real difference is that a URL must contains a DNS name and a URN probably does not. I don't believe in the 'persistent identifier' notion except for the limited case involving SHA-256 and the like > Specifically, the underlying problem is that there are semantic > (and maybe syntax) constraints in RFC 3986 that make it, and its > definition of "URI" unsuitable for some plausible and important > class of identifiers (especially those, or a subset of them, > whose "methods" are not tied to a particular retrieval or > processing protocol (note that "SIP:" and "Mailto" are really no > different from "http" in that regard). Then replace RFC 3986 with one that says 'this is the URI syntax and the semantics are defined by the scheme'. I agree that tying http: to the HTTP protocol seems rather antiquated now. Unfortunately NAPTR is also unhelpful. > One can avoid recognizing that it is problem and try to force > all identifiers into the Procrustean bed defined by 3986. That > isn't working well. Its ultimate result is almost certain to be > the development of object identifier standards away from the > IETF and W3C and the need to adapt to that bed. Indeed, that > has already occurred; note the Handle System and the > closely-related DOIs. > > Or one can recognize the problem and try to deal with it. It > seems to me that there are several ways that problem can be > addressed, in more or less decreasing order of drasticness. > > (1) Discard RFC 3986 entirely, adopt the syntax convention you > suggest (URI = label ':' anything), and leave each method > definition to its own devices. That would be my choice if it meant less argument. > (2) Revise and replace 3986 in a way that removes all of the > semantic definitions and constraints, leaving only the generic > syntax. I think that the result would be workable but, unlike > the "every method defines its own syntax within 'anything'" > model above, I can't prove it. And, having explored that > option, it turns out that removing the subtle semantic > constraints from 3986 is not easy. (See the thread in the URN > mailing list for more about this.) I would be fine with URLs being a syntactic subset of URIs. Possibly we could define the method:/// and method:@ patterns as the 'URL patterns and declare all else to be a URN. > (3) Redefine 3986 as applying only to URLs. If you have a URI > type (i.e., a method) and define it as a URL, you get to > incorporate 3986 by reference and use its syntax and semantics > without repeating them. If you don't make that declaration, you > are on your own, much as in (1) above. OK > (4) Come up with a new typology of URIs and then remove one or > more of types from the scope of 3986. Of course, as Larry's > insistence that there is really no such things as a persistent > identifier shows, coming up with such a typology and reaching > agreement about it is not straightforward. I don't think that the persistent identifier problem is insoluble. I just haven't seen a convincing solution yet. And in the real world any persistent identifier scheme has to cope with copyright and kiddie porn takedown issues. I have an interesting attack on the BitCoin blockchain. The attacker encrypts some kiddie porn and dumps it into the blockchain. Then a little while later they drop the key into the blockchain. Then when the chain is final they call the cops, anyone with a bitcoin wallet is now carrying kiddie porn. Hows that for a DoS attack? > (5) Remove URNs from the scope of 3986, leaving everything that > doesn't use the pseudo-method "urn:" within the scope of 3986 > until and unless they demonstrate why they should be removed too. > > Approach (5) is the one suggested in the draft, not because I > think it would be optimal in the best of all possible worlds, > but because it appears to be something that the URNBIS WG can do > and that would allow it to move forward. Removing URNs from scope is not quite the same thing as saying that they are not URIs. > FWIW, the practical difference among some of those approaches is > ultimately the old issue about the difference between > inclusion-based and exclusion-based models. RFC 3986 > effectively says "all identifiers are URIs and should (or must) > conform to this model. As soon as we get to "except those that > don't", one can either identify those that don't or those that > do. Of course, if we were to shift to the much more generic > model of (1), number of things that would need to be excluded > would presumably be far fewer. We split specs apart all the time. Just present this as a piecemeal rollout of URI/2.0 doing the URN space now and the locators 'at a later time'. I don't want to deal with the locators at the moment because the only way to fix locators properly is to make use of DNS in ways that people tell me are currently impossible due to the infrastructure constraints right up to the point when I suggest changes when they tell me that the protocol is perfect[1]. And of course for those of us who built an Internet scale PKI twenty years ago that is working pretty well all things considered[2], the whole point of deploying DNSSEC was always to enable security policy information to be deployed through the DNS. So I would not want to open up discussion of URL/2.0 right now. [1] Fortunately fixing the last mile issue of DNSSEC forces us to fix the client-resolver loop and so does Edward Snowden. [2] Folk who disagree need to sign the DNS root with a key longer than RSA1024 before throwing stones at others. -- Website: http://hallambaker.com/ From nobody Wed Apr 16 12:04:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0FB1A0213; Wed, 16 Apr 2014 12:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnfzntMA4Ydh; Wed, 16 Apr 2014 12:04:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 861C31A02DE; Wed, 16 Apr 2014 12:04:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416190415.28736.73825.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 12:04:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sY2Lyx-ytXNjrifGPCatBh_Il2o Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 19:04:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The Require-Recipient-Valid-Since Header Field and SMTP Service Extension Authors : William J. Mills Murray S. Kucherawy Filename : draft-ietf-appsawg-rrvs-header-field-10.txt Pages : 25 Date : 2014-04-16 Abstract: This document defines an extension for the Simple Mail Transfer Protocol called RRVS, to provide a method for senders to indicate to receivers a point in time when the the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. This document also defines a header field called Require-Recipient-Valid-Since that can be used to tunnel the request through servers that do not support the extension. The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rrvs-header-field-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 17 07:40:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090E11A018D; Thu, 17 Apr 2014 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2MxTH0oEl3q; Thu, 17 Apr 2014 07:40:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 74FFE1A0088; Thu, 17 Apr 2014 07:40:18 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MAy40-1WiSSs3OBo-009zNY; Thu, 17 Apr 2014 16:40:10 +0200 Message-ID: <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 16:39:56 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , John C Klensin References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hnMpq0k9iEQXWxdEZMBN9CvKbaA/vyBax4m4LfRpotEuHC03sQy itM7j6zJAa4f47U1cW6erI3iW2S5WK7hAuEOKZa/SzG0dZe215WIzNcPi/RPAj0hBgP96nh WuHCoNLl3MdvWUAjdW9AKs0L3EwK/gzHAuYd0ubwkWZlW2aoyvCbsAN0/f/mvj7rJbopa2s K39zE1bVFAH9L08xvyZvw== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oYHQ-nwMyPaea2TLfLZcPdT_6cY Cc: urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:40:23 -0000 On 2014-04-16 20:58, Phillip Hallam-Baker wrote: > On Tue, Apr 15, 2014 at 9:40 PM, John C Klensin wrote: >> Actually, we don't disagree on anything but language and tactics. > > I understood that. It is a specification so language is rather important. > > I don't like the suggestion that the URI slot in the existing > protocols no longer includes URNs. But I am more than happy to toss > virtually the entire URI syntax out. > > I am also rather suspicious of the idea that the difference between > URNs and URLs is that one is a name and the other is an index. Both > are both. > > The real difference is that a URL must contains a DNS name and a URN > probably does not. > ... Not true. It doesn't need to be a DNS name. > ... Best regards, Julian From nobody Thu Apr 17 08:42:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC241A01B9; Thu, 17 Apr 2014 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjPpJgWkfJ_t; Thu, 17 Apr 2014 08:42:21 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 577F31A01CD; Thu, 17 Apr 2014 08:42:13 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id D0C56318064; Thu, 17 Apr 2014 08:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=BkDYJ8xnQ2pAbFEJxuy9 szH5/aI=; b=FsmGL+Sn2F/aQerToUxqrrhXJycRaEQc7eQWUCU9vdeWpazX3YuQ VOYix4Vp4+ixIvyd0wtJD9ES87Ec84H+zof9iu3t3ZnDAxiXAnAWSzz2F74Wk5jx aVE3l+Ojin3d0Q1ABmhNpXdhdi7j3561DReeXyXJA/ukaoOgenVVNrM= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 54FA2318059; Thu, 17 Apr 2014 08:42:09 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so592372wgh.23 for ; Thu, 17 Apr 2014 08:42:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr12886369wib.42.1397749327929; Thu, 17 Apr 2014 08:42:07 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 08:42:07 -0700 (PDT) In-Reply-To: <534FE7BC.4070002@gmx.de> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 10:42:07 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BWiWz_Wbjjs1dZ_zA9azgs2tLzE Cc: John C Klensin , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:42:25 -0000 On Thu, Apr 17, 2014 at 9:39 AM, Julian Reschke wrote: > On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >> The real difference is that a URL must contains a DNS name and a URN >> probably does not. >> ... > > Not true. It doesn't need to be a DNS name. The difference is blurry, but I like to think of it as: a URN is just a name and there needn't even be a mechanism to resolve one to a resource -- heck, there needn't even be a resource. Whereas a URL is a name that indicates how to resolve it in order to locate a resource; the location part might not -need not- be stable. Nico -- From nobody Thu Apr 17 09:05:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB471A0220; Thu, 17 Apr 2014 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS36HPD3lWxm; Thu, 17 Apr 2014 09:05:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 762C41A021A; Thu, 17 Apr 2014 09:05:06 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MhNk6-1WMyvB3Pvu-00MYch; Thu, 17 Apr 2014 18:04:59 +0200 Message-ID: <534FFB98.5040607@gmx.de> Date: Thu, 17 Apr 2014 18:04:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:37SK7/gynTTWpRrJZ8iczqp7/37gZXVaQWU8ehIqDwqT2PPjhx+ K9cK/mO0e7GD42CXIP979+N+YrTPotMSeYwtvVNoOeBsaZb1HBI+WZYWy6Z7nm8V6i5O5TS /Q1tuzNkwW+C4kF15EZcaDmdrpW74Po8wdgAeu7nP8yLTu47KePTDbHYWy9rsWYpcLvq5xB HOXhc3xNJ81Djxq61z2+A== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OOBZSIuoiiqClmrMp2CkziX7duo Cc: John C Klensin , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:05:11 -0000 On 2014-04-17 17:42, Nico Williams wrote: > On Thu, Apr 17, 2014 at 9:39 AM, Julian Reschke wrote: >> On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >>> The real difference is that a URL must contains a DNS name and a URN >>> probably does not. >>> ... >> >> Not true. It doesn't need to be a DNS name. > > The difference is blurry, but I like to think of it as: a URN is just > a name and there needn't even be a mechanism to resolve one to a > resource -- heck, there needn't even be a resource. Whereas a URL is If "it" has a URN then "it" is a resource. By definition. > a name that indicates how to resolve it in order to locate a resource; > the location part might not -need not- be stable. But it's good as it is. A URL is a locator which might be a stable name as well. A URN is a name that may act as a locator later on. Best regards, Julian From nobody Thu Apr 17 09:13:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF65B1A011C; Thu, 17 Apr 2014 09:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZBQBg_JugX7; Thu, 17 Apr 2014 09:13:07 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF511A00FB; Thu, 17 Apr 2014 09:13:07 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id 10so558307lbg.35 for ; Thu, 17 Apr 2014 09:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4nYW9ORLqcbHvDk/4P/Up3I6eKl9CmaY0DjvPJ/3cgs=; b=d1/gvKAdkascuCGNpIKhay3U79/ZvIoZ+f4zoUrJn6k+Nin6+YVLjrTWGaaiKTfxLe 35bBGaSvw4chv1cm4ev3MDTI651x5Wq8JylPYec2efJilvVeJ746PkMhs/fESA4VK7I2 Qx5VqCUmWQdMy1gAFSPhJUDiH24RcO3NSTHH2BKtOhPbdOHV65BA/Vus4CSyo1UjgoB+ uq+UT4RgB7kWufMZ1rfMGMQ1NWe37X3mZL3bu9BqVu9m9FycOtog6XMEjI0/Wzn98XRX hARFHwxkkwFzNVdAS/3wm6wx1S2ebW7dnl96gjyu54dIwVjqpqUsAVKI+kcCVW/9zGpW 5Jxg== MIME-Version: 1.0 X-Received: by 10.152.4.41 with SMTP id h9mr2142103lah.43.1397751183071; Thu, 17 Apr 2014 09:13:03 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 17 Apr 2014 09:13:02 -0700 (PDT) In-Reply-To: <534FE7BC.4070002@gmx.de> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 19:13:02 +0300 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2E82mPkkaUP6yS3HG4WB5hOHmTw Cc: John C Klensin , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:13:12 -0000 On Thu, Apr 17, 2014 at 5:39 PM, Julian Reschke wrote: > On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >> >> On Tue, Apr 15, 2014 at 9:40 PM, John C Klensin wrote: >>> >>> Actually, we don't disagree on anything but language and tactics. >> >> >> I understood that. It is a specification so language is rather important. >> >> I don't like the suggestion that the URI slot in the existing >> protocols no longer includes URNs. But I am more than happy to toss >> virtually the entire URI syntax out. >> >> I am also rather suspicious of the idea that the difference between >> URNs and URLs is that one is a name and the other is an index. Both >> are both. >> >> The real difference is that a URL must contains a DNS name and a URN >> probably does not. >> ... > > > Not true. It doesn't need to be a DNS name. Why bother with anything else? Its all legacy now or going to be soon enough. X.500 has never been a viable directory. Telephone numbers are the only other widespread locator. We have some names that don't use the URN prefix and we have some stuff like about: and data: But if we take a look at this as a semiotics problem. We have Noh's three classes: Firstness: The identifier is the thing identified (e.g. data) Secondness: The identifier is an index of the identified (http, mailto: etc.) Thirdness: The relationship between the identifier and identified is purely conventional (i.e. arbitrary, i.e. a 'name'). It does not have to have a URN prefix to be a name. Nameness comes from whether it has the property of thirdness or not. news: URIs have always been URNs, so are message IDs. [OK I'll accept IP address literals and I will accept DNS names that may not resolve on the Internet due to split horizon DNS.] -- Website: http://hallambaker.com/ From nobody Thu Apr 17 09:21:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C62C1A01C5; Thu, 17 Apr 2014 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrbqMIkJvi1l; Thu, 17 Apr 2014 09:21:09 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C1C401A01C2; Thu, 17 Apr 2014 09:21:09 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 4BA161DE05D; Thu, 17 Apr 2014 09:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6x8IjIYhGdbbi94KApu9 6SeAbbA=; b=o7XRfmapPZdSTFeWQ72fO6lbq5zoL1OLQ2HN9iI5EHJ9aA6GneEM vZrAiNdTTbck5Ck+xo/HDTFZNa3wa5JnUHH1YowvOFk4gd2tH8czeqJblNS+853A jG/NV/m+3nEGOIad0X0wAN9S+vLNnf5SsArZ1bTi1D7qwmUQ66aXGf8= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id C28B91DE059; Thu, 17 Apr 2014 09:21:05 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id t60so659544wes.33 for ; Thu, 17 Apr 2014 09:21:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr13028260wib.42.1397751664347; Thu, 17 Apr 2014 09:21:04 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 09:21:04 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 11:21:04 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KMYPgVRwRKlBMcZD7vNIZili8eM Cc: Julian Reschke , John C Klensin , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:21:14 -0000 On Thu, Apr 17, 2014 at 11:13 AM, Phillip Hallam-Baker wrote: > On Thu, Apr 17, 2014 at 5:39 PM, Julian Reschke wrote: >> On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >>> The real difference is that a URL must contains a DNS name and a URN >>> probably does not. >>> ... >> >> Not true. It doesn't need to be a DNS name. > > Why bother with anything else? Its all legacy now or going to be soon > enough. X.500 has never been a viable directory. Telephone numbers are > the only other widespread locator. With the caveat that "DNS name" need not be the same as a hostname (FQDN). It might be a domainname for use as starting point for service location. Can we use URLs for geocaching? For locating resources on satellites? .. From nobody Thu Apr 17 09:31:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4B31A0243; Thu, 17 Apr 2014 09:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUmRugSt5o0Y; Thu, 17 Apr 2014 09:30:59 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65C1A0241; Thu, 17 Apr 2014 09:30:57 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id c6so574624lan.31 for ; Thu, 17 Apr 2014 09:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dARVjCWcOMcZNsT0Y9FPjmzoCccWbcfY9NeCseIuzsA=; b=Hg4G8m3APUYJFnUyUCAsuzc8XhpIqg394LULdEE1nGPCndFhnbInq0ArvXWMaeqVdA kZcy1Wf3UKSkq26ng5rZnIv5Fq4yvdO4G2n6/irSztRpMyFA+zsbgAOxP9RPAr1GCWDG w9aK2FGsZnk75uULs8fh3aAiW8tqWhg53+KQsozfZ9yGfg672vDv5x10vhaht7e/+Xu1 +RAoltYrccZyrQkUQZLRk2mmaxu7Iycni+YG2xn45+i6b6JnIFlRW3uoBoaXgA9BwIET 1AjWvSRKDSdKGEfJv+FJ2UBMNh3XvDUwd9+NAua+QDa5DPQMvmcw/K4yKZ0/GF5JOWO9 3afQ== MIME-Version: 1.0 X-Received: by 10.152.120.168 with SMTP id ld8mr10659911lab.12.1397752252949; Thu, 17 Apr 2014 09:30:52 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 17 Apr 2014 09:30:52 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 19:30:52 +0300 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6_jcMs8yxkTDxElhM_YlilvHTb4 Cc: Julian Reschke , John C Klensin , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:31:03 -0000 On Thu, Apr 17, 2014 at 7:21 PM, Nico Williams wrote: > On Thu, Apr 17, 2014 at 11:13 AM, Phillip Hallam-Baker wrote: >> On Thu, Apr 17, 2014 at 5:39 PM, Julian Reschke wrote: >>> On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >>>> The real difference is that a URL must contains a DNS name and a URN >>>> probably does not. >>>> ... >>> >>> Not true. It doesn't need to be a DNS name. >> >> Why bother with anything else? Its all legacy now or going to be soon >> enough. X.500 has never been a viable directory. Telephone numbers are >> the only other widespread locator. > > With the caveat that "DNS name" need not be the same as a hostname > (FQDN). It might be a domainname for use as starting point for > service location. > > Can we use URLs for geocaching? For locating resources on satellites? .. We can certainly use URIs. The issue here is whether we claim it has 'name like' semantics or 'locator like'. Since most of the people who talk about names don't seem to be familiar with the relevant literature, I think the best approach is to limit URLs to locators where we specify the naming infrastructure (DNS, IP, hosts.txt) . That is a distinction we can agree on. -- Website: http://hallambaker.com/ From nobody Thu Apr 17 18:42:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E601A01F5; Thu, 17 Apr 2014 18:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T22mgzKQSuZg; Thu, 17 Apr 2014 18:42:32 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D71781A022F; Thu, 17 Apr 2014 18:42:31 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.32.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 25C7D509B8; Thu, 17 Apr 2014 21:42:22 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <952E89C207E59D25CD5953D6@JCK-EEE10> Date: Fri, 18 Apr 2014 11:44:32 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> To: John C Klensin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BoRL6P1ojxLSRIGy0nY4ZzPnYUE Cc: "Julian F. Reschke" , urn@ietf.org, Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 01:42:36 -0000 I have to say that I'm sympathetic to the proposed outcomes, albeit for = different reasons, perhaps. We have two communities using a shared artefact (URIs) with vastly = differing use cases and viewpoints about them. Managing this situation = has already proven extremely difficult for the IETF, and it seems to me = to be very pragmatic to cease forcing them to co-exist, constantly = bickering about angels dancing on pins.=20 While people don't want to consider it in-scope for this discussion, I = also think that doing so will make the situation with WHATWG and W3C = more manageable. Cheers, On 16 Apr 2014, at 3:47 am, John C Klensin wrote: > Hi. >=20 > Just wanted to tell folks that I'm on a very poor connection (if > on at all) for the next couple of days and probably won't be > able to give careful answers until Thursday and probably should > not try. But one very quick observation in response to part of > Larry's note... >=20 > --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter > wrote: >=20 >> The only thing that makes something a name 'persistsent' is >> the existence of a name resolution service or method which >> persists. The syntax or namespace is irrelevant. 'persistent' >> isn't binary, it's just "how long". Everything has a life-time. >>=20 >> http://masinter.blogspot.com/2010/03/ozymandias-uri.html >=20 > I think the above largely misses the point and that, in a sense, > your blog posting illustrates the point although not in the way > you probably intend. "Persistent identifier" entered the IETF > vocabulary a long time ago but may not be very look terminology. >=20 > Some objects -- like stone statues if one doesn't care whether > they remain intact and standing-- have very long life > expectancies. Others, like people, have shorter ones. But URIs > (with or within including URNs) aren't objects, they are object > reference that, like most good references, involve some degree > of abstraction. Now, "Ozymandias" is a very long-persistent > reference. It isn't the object. It is a somewhat ambiguous > reference because it can refer to the statue, the poem, your > blog posting, and probably several other things, but has a long > duration, perhaps one that is long enough to survive the objects > it references (just like titles of long-lost books). But, as a > reference, it is that persistent because it is not bound to a > retrieval mechanism that has its own persistence properties.=20 >=20 > Whatever its other properties, > http://masinter.blogspot.com/2010/03/ozymandias-uri.html > is lousy as a persistent identifier. It depends on the > availability of "http" (or something called that) as a retrieval > mechanism. It depends on there being a DNS, on there being a > TLD named "com" an SLD named "blogspot", and both of them having > certain properties of which HTTP can take advantage. > "Ozymandias", and even the potential URN > urn:poems:Shelley/Ozymandias are more persistent because they > represent a higher level of abstraction and are not tied to > either a location or a retrieval/access method. Use of a > hypothetical ISPN (International Standard Poem Identifier) in > the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or > might not be more persistent: it would be an exact identifier of > something and makes equivalence comparison more feasible and > less ambiguous, but it is probably tied to a database to > actually identify an object and such databases may be more or > less available and persistent than access methods and/or the DNS > (which is, after all, just another database). >=20 > Regardless of what one calls them, I suggest that > access-method-dependent identifiers (http:..., > NineTrackTape:??42.3744=B0?N,?71.1169=B0?W?123456 (where "?" > represents one or more carefully-chosen delimiters that may not > have RFC 3986 semantics), ...) are different kinds of creatures > than either the objects to which they refer or names of those > objects that are not, in the sense of the above, method or > location-model dependent. >=20 > More soon. >=20 > john >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From nobody Fri Apr 18 00:43:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7C01A024A; Fri, 18 Apr 2014 00:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wOH3sMn6KN4; Fri, 18 Apr 2014 00:43:47 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6E1A019A; Fri, 18 Apr 2014 00:43:47 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Wb3SS-0005A9-ob; Fri, 18 Apr 2014 08:43:36 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Wb3SS-0007qQ-7Q; Fri, 18 Apr 2014 08:43:36 +0100 Message-ID: <534F4321.2020802@ninebynine.org> Date: Thu, 17 Apr 2014 03:57:37 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Larry Masinter References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3clQZNwxNqyL-5pdVPNYFO7_gm4 Cc: John C Klensin , "julian.reschke@gmx.de" , "urn@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 07:43:50 -0000 On 15/04/2014 17:25, Larry Masinter wrote: > Is it time to revive http://tools.ietf.org/html/draft-masinter-dated-uri and finally get it to RFC? I think so. But I also don't see sufficient head of unrequited need to get this progressed as a standards action. YMMV. My suggestion would be to request informational, maybe ISE, RFC publication with provisional URI scheme registrations. That creates an available and persistent (sic) reference that developers might think about using if it meets a need (e.g. in Memento [1] implementations?). Then, if it does become widely used, there's a ready point of departure for a standards action. #g -- [1] http://tools.ietf.org/html/rfc7089 From nobody Fri Apr 18 07:48:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5086C1A03A8; Fri, 18 Apr 2014 07:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu6NK14ntBZN; Fri, 18 Apr 2014 07:48:46 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0890B1A03A7; Fri, 18 Apr 2014 07:48:45 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so1862068oag.14 for ; Fri, 18 Apr 2014 07:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CgPPm4qdKiXdk+Ar1lGgQBy0iwLx8aiLkQQPsZFuq5U=; b=htq9yMTNVgAyv0EWyZh15WW4IllxK5zpmKMYlnicws0p+rhn37dWIAwldkkSwQWnXa YTjvGlYWmU+qEhSmxyY1lULHTlsvwhtV6zgs+mVnoUbfuLrEQvyQiBAjLuWdMmyMMzCB qe8O1DCu4BZtmEUR9AR5fTTv7eZWNR4Qba5Q31XB/edy7sZkliOEtyt5dbEPxBDsvM5j gUQZC/whOnLYUHqewXqzTwy+FKLglkOn84/p6CIon8DOm0rt7NtubEYxwcvq9HqcUwI2 HN+E+VcyC3ooNUrgtG6kzzm0Leva1j1KxE93J6zA/kkTJx8s+OM/rU6Dc9etrhWtFmtm wVjg== X-Received: by 10.60.62.178 with SMTP id z18mr1229919oer.61.1397832522074; Fri, 18 Apr 2014 07:48:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.153.6 with HTTP; Fri, 18 Apr 2014 07:48:21 -0700 (PDT) In-Reply-To: <534FFB98.5040607@gmx.de> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <534FFB98.5040607@gmx.de> From: Scott Brim Date: Fri, 18 Apr 2014 10:48:21 -0400 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c20decef101804f7523e9a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zhlLI6NA6iVKp8zOe2nxGZC_3to Cc: John C Klensin , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 14:48:47 -0000 --001a11c20decef101804f7523e9a Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 12:04 PM, Julian Reschke wrote: > A URL is a locator which might be a stable name as well. > > A URN is a name that may act as a locator later on. I would be careful about trying to take the network locator/identifier discussion into UR* space. A locator in the network gives you a network attachment point, not the object attached to it. Also there are many identifiers that are unrelated to any locators. The mapping to app space isn't very good and using locator/identifier could produce confusing results. Perhaps you could think of URLs as naming "instances"? Scott --001a11c20decef101804f7523e9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 17, 2014 at 12:04 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
A URL is a locator which mig= ht be a stable name as well.

A URN is a name that may act as a locator later on.

I would be careful about trying to take the network locator/identi= fier discussion into UR* space. A locator in the network gives you a networ= k attachment point, not the object attached to it. Also there are many iden= tifiers that are unrelated to any locators. The mapping to app space isn= 9;t very good and using locator/identifier could produce confusing results.=

Perhaps you could think of URLs as naming "instanc= es"?=C2=A0

Scott

--001a11c20decef101804f7523e9a-- From nobody Fri Apr 18 08:20:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955301A03A1 for ; Fri, 18 Apr 2014 08:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyvLRodaH_KT for ; Fri, 18 Apr 2014 08:20:01 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 61EEE1A01AF for ; Fri, 18 Apr 2014 08:20:01 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id jt11so1568274pbb.0 for ; Fri, 18 Apr 2014 08:19:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2KEXzUWcGAURlWhW/17fah2GSaEVtQ19zY94vps/f1Q=; b=iWiASODSHfVxBKtliBC92RiaEpweky7rxbkk52SUym2hMMEqwiHnvSwugvkddn3HLa k5rXCYC0XBGQsBeIqsAOnJP9ey/0CBWweUg8Re/zAtzHmHbqyfjZtwk1tTp2yzsRIZUp Lf40yMRcMYtGOJx9q51o0uyMqGbhshPdrKRE6sMjN0885Qk3khqJ2f/LyrutMapSysyd b9bwImEdhnrzSrk8hCr5mrfNJFD08d1EzeX/3E1x4EOHW+rAxg9Y0h7pNUawjNeqviBU AGY6115qhr4d7eYJg1EE8tBvLyc5qJyZRDWrNVSTuky2UlXREObHcfPKadXRS8MrryWP GRkw== X-Gm-Message-State: ALoCoQmMqlD6rBGODftu41iDt/DcF5cssVdZpprDTQeIr7g5sWbRmng6RyvJ8dGTIb7LbP3NMVtl MIME-Version: 1.0 X-Received: by 10.66.233.9 with SMTP id ts9mr22609383pac.37.1397834397463; Fri, 18 Apr 2014 08:19:57 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.103.164 with HTTP; Fri, 18 Apr 2014 08:19:56 -0700 (PDT) X-Originating-IP: [192.0.216.13] Received: by 10.70.103.164 with HTTP; Fri, 18 Apr 2014 08:19:56 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Fri, 18 Apr 2014 11:19:56 -0400 X-Google-Sender-Auth: TnAnqne-w8uqd70W1sJaEij93vE Message-ID: From: Mark Baker To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7b111c53b74b7c04f752ae32 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Qfv5cBuDpre3893tXibft1gb-84 Cc: Julian Reschke , urn@ietf.org, John C Klensin , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 15:20:03 -0000 --047d7b111c53b74b7c04f752ae32 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker wrote: > We can certainly use URIs. The issue here is whether we claim it has > 'name like' semantics or 'locator like'. Whether it's a name or a locator is not an intrinsic property of the string, but depends solely upon the presence or absence of a local resolution mechanism for that string. A string that *you* might *today* call a "name", might already be a "locator" to somebody who's rigged a private resolution service. Ten years from now, that "name" might be a "locator" to all of us. Mark. --047d7b111c53b74b7c04f752ae32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> We can certainly use URIs. The issue here is whether we claim it has > 'name like' semantics or 'locator like'.

Whether it's a name or a locator is not an intrinsic pro= perty of the string, but depends solely upon the presence or absence of a l= ocal resolution mechanism for that string.

A string that *you* might *today* call a "name", m= ight already be a "locator" to somebody who's rigged a privat= e resolution service. Ten years from now, that "name" might be a = "locator" to all of us.

Mark.

--047d7b111c53b74b7c04f752ae32-- From nobody Fri Apr 18 19:34:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0508B1A0224; Fri, 18 Apr 2014 19:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMjM555Vu9Te; Fri, 18 Apr 2014 19:34:45 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id ED5E21A021E; Fri, 18 Apr 2014 19:34:44 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id p9so1790857lbv.4 for ; Fri, 18 Apr 2014 19:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lSa50wEseoxWj3d2gaF2XEnoV5izdqZTv91UroGlh4o=; b=wyXObgy81MA+NdOpYPK9f3UXS8/49T8UpwZBCjhOduZD+Axw45Kw6oNbqHrhdsq46w VIfCpAtKRjxCw95tHfvIdukNCEws1GPcTtfWb934Q7RgNos1+NnrSSFWq208I0I+wenI FLN535m6nOkomgG0YpvY2FVkHJoYF9xAhWzJ/6r7FevbzG9LtPYyT9Vivl/ZA9koqqJp hKHKfzBYme4wtL4DwTZRQtmgNk66ev7rgVNdRIqPORgwmRxu155ux0kWmJkKnSD17Dbr 0fclqVlN14S5+s1ny0ISgQRfZ1RBAFK/bkYbrWiC7RxqmitHPQ/+kl5r2pqlLSnVu9Pc X5Tg== MIME-Version: 1.0 X-Received: by 10.112.61.199 with SMTP id s7mr1688934lbr.25.1397874880095; Fri, 18 Apr 2014 19:34:40 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Fri, 18 Apr 2014 19:34:40 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Fri, 18 Apr 2014 22:34:40 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EUrpxza9yPZSEjFEygYjZW3S070 Cc: Julian Reschke , urn@ietf.org, John C Klensin , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 02:34:50 -0000 On Fri, Apr 18, 2014 at 11:19 AM, Mark Baker wrote: > > On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker > wrote: >> We can certainly use URIs. The issue here is whether we claim it has >> 'name like' semantics or 'locator like'. > > Whether it's a name or a locator is not an intrinsic property of the string, > but depends solely upon the presence or absence of a local resolution > mechanism for that string. > > A string that *you* might *today* call a "name", might already be a > "locator" to somebody who's rigged a private resolution service. Ten years > from now, that "name" might be a "locator" to all of us. Which is exactly what I was saying. For example, UPC code for a can of baked beans is a URN. But if you go to Amazon you can use it as a locator, albeit mediated via UPS rather than TCP/IP. -- Website: http://hallambaker.com/ From nobody Sat Apr 19 08:53:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C050C1A0012; Sat, 19 Apr 2014 08:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uImQVk4Gbuwh; Sat, 19 Apr 2014 08:52:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E25431A0026; Sat, 19 Apr 2014 08:52:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140419155257.4800.23244.idtracker@ietfa.amsl.com> Date: Sat, 19 Apr 2014 08:52:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UrB5yKIeIL7mtFhnyVkG3XoOzCw Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 15:53:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The Require-Recipient-Valid-Since Header Field and SMTP Service Extension Authors : William J. Mills Murray S. Kucherawy Filename : draft-ietf-appsawg-rrvs-header-field-11.txt Pages : 25 Date : 2014-04-19 Abstract: This document defines an extension for the Simple Mail Transfer Protocol called RRVS, to provide a method for senders to indicate to receivers a point in time when the the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. This document also defines a header field called Require-Recipient-Valid-Since that can be used to tunnel the request through servers that do not support the extension. The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rrvs-header-field-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 19 14:19:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE92B1A00FA; Sat, 19 Apr 2014 14:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CJMydaS6ukV; Sat, 19 Apr 2014 14:19:02 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id EC1831A00F4; Sat, 19 Apr 2014 14:19:01 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id uz6so560211obc.14 for ; Sat, 19 Apr 2014 14:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BI3BYlVC4lq/Bk+hkDDA+69Ibb5wiB60ySj/oYF5O0Q=; b=0yBh7CKQSimAbCkvL5tPO2glee2cPR4nfJffPynmgC4G0NL8sEc43K/TS2bcfRPUe1 vf+5AN+goNb9mtaFqPEtPJYiIbfTE61/y42mn0qTj2T6I/E650/AfkbtP1LpdkJBB/Ps rzJTDw6n7/5fWXMM/00zCPRTMbnW52+RWhKC2kPJ/OXEt8MZncsu+WAD7AJrx3lArRYJ jDtjxwM8lO29CD9J0pvOvsuwjS5/3MTh0RdrGy7mE4nJlTc65UqMyoEdCIYWmhVtvwu+ 3AV0mDwN2mG9PCj7Q2IYBcp1vIBqp/zrr0RauHIVOogRyqb0kdGcb8/Fr783T7y07TBb OnWQ== MIME-Version: 1.0 X-Received: by 10.182.225.194 with SMTP id rm2mr3635924obc.49.1397942337470; Sat, 19 Apr 2014 14:18:57 -0700 (PDT) Received: by 10.183.6.196 with HTTP; Sat, 19 Apr 2014 14:18:57 -0700 (PDT) Received: by 10.183.6.196 with HTTP; Sat, 19 Apr 2014 14:18:57 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Sat, 19 Apr 2014 17:18:57 -0400 Message-ID: From: Scott Brim To: Mark Baker Content-Type: multipart/alternative; boundary=001a11c2ef1c7105f704f76bd0a8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/POG_lHdoEmzePjt56XIWyljSuo8 Cc: Julian Reschke , John C Klensin , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 21:19:04 -0000 --001a11c2ef1c7105f704f76bd0a8 Content-Type: text/plain; charset=UTF-8 The inverse way of looking this is that identity-related functions can use anything they want since they can treat it opaquely ... and do ... while location-related functions are limited to tokens they understand the semantics of. On Apr 18, 2014 11:20 AM, "Mark Baker" wrote: > > On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker > wrote: > > We can certainly use URIs. The issue here is whether we claim it has > > 'name like' semantics or 'locator like'. > > Whether it's a name or a locator is not an intrinsic property of the > string, but depends solely upon the presence or absence of a local > resolution mechanism for that string. > > A string that *you* might *today* call a "name", might already be a > "locator" to somebody who's rigged a private resolution service. Ten years > from now, that "name" might be a "locator" to all of us. > > Mark. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001a11c2ef1c7105f704f76bd0a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The inverse way of looking this is that identity-related fun= ctions can use anything they want since they can treat it opaquely ... and = do ... while location-related functions are limited to tokens they understa= nd the semantics of.

On Apr 18, 2014 11:20 AM, "Mark Baker"= <distobj@acm.org> wrote:


On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> We can certainly use URIs. The issue here is whether we claim it has > 'name like' semantics or 'locator like'.

Whether it's a name or a locator is not an intrinsic pro= perty of the string, but depends solely upon the presence or absence of a l= ocal resolution mechanism for that string.

A string that *you* might *today* call a "name", m= ight already be a "locator" to somebody who's rigged a privat= e resolution service. Ten years from now, that "name" might be a = "locator" to all of us.

Mark.


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--001a11c2ef1c7105f704f76bd0a8-- From nobody Sat Apr 19 15:39:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D24E1A0104; Sat, 19 Apr 2014 15:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUiMsRoOfctl; Sat, 19 Apr 2014 15:39:04 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A1D741A0100; Sat, 19 Apr 2014 15:39:04 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 1E32721DE59; Sat, 19 Apr 2014 15:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=UcHPKy6zX4Sr7f+ZWIlN Uno6V2w=; b=UJz3u5Z+XJNUjBJcIaoG9l5oXx//DqyYpijB9gnLTNtl7kDunA7/ gDnYuttGdgKxHYA24CgTN9FoJRQKju4nOXdep7Q7tDp9bZZ8R8k4nPxOXzgJ5XrP npZ/jhgJgZgTDjFNSb/smmlEB5DDxFfXtxC6mjkytsqhEnx+OzHi8a8= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 9A34521DE58; Sat, 19 Apr 2014 15:38:59 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so690566wiv.7 for ; Sat, 19 Apr 2014 15:38:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr7886420wib.42.1397947138372; Sat, 19 Apr 2014 15:38:58 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sat, 19 Apr 2014 15:38:58 -0700 (PDT) In-Reply-To: <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> Date: Sat, 19 Apr 2014 17:38:58 -0500 Message-ID: From: Nico Williams To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2BkC3WX-j6rSE772trnE8e35z_s Cc: Julian Reschke , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 22:39:08 -0000 On Sat, Apr 19, 2014 at 7:59 AM, John C Klensin wrote: > That set of distinctions is not just pedantry. If "URN" mean > whatever someone claims it means at a given moment, then we > don't have a specific category of identifier, we just have a > very generic term for some variety of identifier. For the > information it contains, one might as well have the above > statement read "UPC code for a can of baked beans is an > Ironduck". In GSS land we've switched (for new interfaces) from using ASN/1 OIDs to using URNs. Our OIDs name no objects and our URNs no resources. They are merely identifiers with reasonable namespaces and name allocation policies. URNs are much easier to use for this purpose (one look at how the GSS-API C language bindings handle OIDs should make this clear!). Is this an abuse of URNs? Does/should anyone care? IMO: "no", and "no". But it helps to have registered identifiers, so we can find the specifications (or at least some information) that describe their semantics. Or perhaps our uses of OIDs/URNs do in fact name objects/resources, if we give specific behaviors/semantics the honor of being objects/resources. For me, all that matters when it comes to URNs is that we agree to namespace partitioning and registries for those uses that warrant them. If you want to call URNs "Ironducks", so be it. Nico -- From nobody Sat Apr 19 15:45:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DB81A00FD; Sat, 19 Apr 2014 15:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP7isNqb6Y0p; Sat, 19 Apr 2014 15:45:02 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4B61A0090; Sat, 19 Apr 2014 15:45:02 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 51B4A9405C; Sat, 19 Apr 2014 15:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PBgHZCPz4akIa6NVw9w8 fw1oje0=; b=FyD8CfLyI9Lrhz7hSihuNQwBQdggVB/BzubuXRpwPnu/Pme1MiPe FBRjYDYfsIU6BGStnM8kEWKMOK9NYVvoSTjX8NqgiJG9yXizgQ72s7OysRQMHGvR PIA9GtQgrXRa/X46TzrpfE5GA2zMV2wa1fV+iPShQs0FVwCKysPOOrM= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id D279494059; Sat, 19 Apr 2014 15:44:57 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so1574127wgg.25 for ; Sat, 19 Apr 2014 15:44:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.76.10 with SMTP id g10mr257116wjw.67.1397947496541; Sat, 19 Apr 2014 15:44:56 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sat, 19 Apr 2014 15:44:56 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Sat, 19 Apr 2014 17:44:56 -0500 Message-ID: From: Nico Williams To: Scott Brim Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jgLADms6PlclBzk0tbOvaQ1KdTc Cc: Julian Reschke , urn@ietf.org, John C Klensin , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 22:45:06 -0000 On Sat, Apr 19, 2014 at 4:18 PM, Scott Brim wrote: > On Apr 18, 2014 11:20 AM, "Mark Baker" wrote: >> Whether it's a name or a locator is not an intrinsic property of the >> string, but depends solely upon the presence or absence of a local >> resolution mechanism for that string. >> >> A string that *you* might *today* call a "name", might already be a >> "locator" to somebody who's rigged a private resolution service. Ten years >> from now, that "name" might be a "locator" to all of us. Yes. Consider a use of URNs as opaque identifiers of optional behaviors. Add a registry of such URNs listing their specifications. But now they are both names and locators, since they can be used to locate specifications in the corresponding registries. Now, if there's no way to automate this location, and/or if it's only useful to implementors, then such URNs remain names. Names for what? For behaviors. > The inverse way of looking this is that identity-related functions can use > anything they want since they can treat it opaquely ... and do ... while > location-related functions are limited to tokens they understand the > semantics of. Yes. We could construct a URN namespace where location of specifications via [IANA, say] registry lookups turns them into locators. Just not locators useful to most people. In the end URNs are really just opaque identifiers. Some of them name real resources (e.g., there's a way to name RFCs using URNs); some will not. We should not demand that every URN name a "resource" in that sense! Nico -- From nobody Sun Apr 20 08:17:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B235E1A0011; Sun, 20 Apr 2014 08:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtRQAaf3y7b2; Sun, 20 Apr 2014 08:17:17 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 921361A0197; Sun, 20 Apr 2014 08:17:17 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jx11so6345040veb.31 for ; Sun, 20 Apr 2014 08:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VjrnfURWjK1zTHdnsl0VsM3H12FhJ56If7esZ7vCsS8=; b=fmdsC4ogpgBhK0Hg+KJ8ZLeWOqc32mHgrQB+RfWHj3F3dERhVB4trv5HQ8kXRwTWI9 aavgw3SYsjGgCxbNbbokjv6VP8LNcqhjKOfUhr940IrVECjfEF5y/BJqBRJnlfvdgQq3 OEi4RbliHxbQQT8hpplcxnhOnICEDj8sf04u8pLEQ8Bf1EAoKxj0ndN+/giarohkFh18 V+fXfqsbJg4PthzrOAuZyl0OgFStlemzifCQHYU4aL4gA0EKTt6mE6qTrNsNuonXXUp0 YfpNJOeEeAK4/x0Om8LRaHslXKiTHYcfaKkb8OUCDXKReAkwMj5+PuzUFtjqPtGPnXM8 YX1g== MIME-Version: 1.0 X-Received: by 10.220.161.8 with SMTP id p8mr25588790vcx.4.1398007032641; Sun, 20 Apr 2014 08:17:12 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Sun, 20 Apr 2014 08:17:12 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Sun, 20 Apr 2014 11:17:12 -0400 X-Google-Sender-Auth: Xb4aQg7oaiHWcX1Y174vhUqSkOo Message-ID: From: Barry Leiba To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_rVXZfpMDgsvqK1MgeT6PzKdjq8 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 15:17:24 -0000 Again, addressing just one point here: Graham said this: > DOIs > are conceived as names, and have the appropriate management processes > around them applicable to names. But I have observed that in recent times, > the preferred form for presenting DOIs to the Web has increasingly been in > the form "http://dx.doi.org/..." or similar (see also: [1]). I think this > exemplifies something that MAY be used as both identifier and name. Phill said this: >> A string that *you* might *today* call a "name", might already be a >> "locator" to somebody who's rigged a private resolution service. Ten years >> from now, that "name" might be a "locator" to all of us. > > Which is exactly what I was saying. > For example, UPC code for a can of baked beans is a URN. > But if you go to Amazon you can use it as a locator, albeit mediated > via UPS rather than TCP/IP. I think both of these confuse the issue. Given a name, we can often turn it into a locator. That's clear, and that's one thing that makes names useful. But I think we still need to keep in mind that the names *aren't* locators. If I can always take "urn:doi:xyz-abc", transform it to "http://dx.doi.org/find/xyz-abc", and get a valid locator for the thing named, that's great. But it's still the case that the former is a name and *not* a locator. And if dx.doi.org goes away at some point, the thing is still named by "urn:doi:xyz-abc", even though I can no longer use that locator. It's rather like using "Barry Leiba" to talk about me, and that's fine as long as it's a reference. But as soon as you need to *find* me, you have to get a locator. The locator might or might not contain my name; it could be "barryleiba@computer.org", it could be my phone number, it could be a URL for my web site, or it could be a suggestion that you look here on a Friday evening. Again, for the purposes of abstraction, let's be sure to remember the distinction, and to be clear about the scope of what we're discussing. Barry From nobody Sun Apr 20 09:59:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A131A0026 for ; Sun, 20 Apr 2014 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.043 X-Spam-Level: * X-Spam-Status: No, score=1.043 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9A9tcbYRqQB for ; Sun, 20 Apr 2014 09:59:05 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id F3EC61A0025 for ; Sun, 20 Apr 2014 09:59:04 -0700 (PDT) Received: (qmail 17382 invoked from network); 20 Apr 2014 16:58:59 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Apr 2014 16:58:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=17441.5353fcd3.k1404; i=johnl@user.iecc.com; bh=wkSNsSW8G960r9O5tNctLsEACd8SWtteInfXdlL/Vfg=; b=FVzR2zwZIG2e1QFOFIAmFS4n/Tmf+OY8ire9rVNntCGdVNQOMZdeH6kKWNU808Rv4/0Y6XyR28c1/xml5ofMKfMRZO4Vds7L5UYRus34dMGqRFOYnJsJcQLAs+YbcJPFOhQVIi46/FQg5ply80aee6lZY8c5bOMf4u1oBfs8mTE9yN5lvDEO0YOOukuQpG4G3NVeIP2Q/+vxxKTvIHciomj1i29u1nxxLZjirt8NuwR/tb6bmosDtpHacroS8T2o DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=17441.5353fcd3.k1404; olt=johnl@user.iecc.com; bh=wkSNsSW8G960r9O5tNctLsEACd8SWtteInfXdlL/Vfg=; b=PgFQWjCZTSl0Vu/vtjYDfcOCExCVHaR0mNxBHFt4qGXXgWl3j7CXGZKEu3L6j8VD+Yu+NBNOx/tBuAE9smRBTqTnqLTyKbAf7Ukd2dagkbuuZ63SJrR59DO4IcRzp+PKQhJ91sd9pZl5oHbqNkLbMhpG27TlaZhaMUTPhHe9bw4r51o2FAcOQ/KX65nhc67JKdPEBuQ+Xo7ZyzQcLgNpZcSKk9eqj00bIALQwjOcEhkGCjdcliSgd6nmuYeHknCo Date: 20 Apr 2014 16:58:37 -0000 Message-ID: <20140420165837.95296.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/uG88-Vh53zus45MZDUQyemedxO8 Cc: barryleiba@computer.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 16:59:09 -0000 >I think both of these confuse the issue. Given a name, we can often >turn it into a locator. That's clear, and that's one thing that makes >names useful. But I think we still need to keep in mind that the >names *aren't* locators. If I can always take "urn:doi:xyz-abc", >transform it to "http://dx.doi.org/xyz-abc", and get a valid >locator for the thing named, that's great. But it's still the case >that the former is a name and *not* a locator. And if dx.doi.org goes >away at some point, the thing is still named by "urn:doi:xyz-abc", >even though I can no longer use that locator. It seems fairly ambiguous what a DOI is in practice. It's defined as an instance of the handle system (the only one that seems to have gotten much traction), which has its own little-used lookup protocol. There was a doi: URI defined in a draft which expired in 2003, and which seems to to exist only as a Firefox plugin. While DOIs are entirely reasonable URNs, the DOI group now wants everyone to write the URN doi:10/123.456 as the URI http://dx.doi.org/10/123.456. While this makes them easier to embed in web pages have have the links work, it also loses one of the intended features of the URN, which that the resolution can be context dependent. This matters in practice, an institution with a library would likely want to resolve DOIs itself so it can provide users with local copies when possible rather than the original which may be behind a paywall or otherwise hard to retrieve. So you're right, they're different. I could imagine something like a thing that's a name, and here's the default way to turn it into a locator if you don't have anything better, but that seems both complex and vague. R's, John From nobody Sun Apr 20 20:38:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ED61A0197 for ; Sun, 20 Apr 2014 20:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpKwpjODnReT for ; Sun, 20 Apr 2014 20:38:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id D62281A0194 for ; Sun, 20 Apr 2014 20:38:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P6VS27LNHS006S8Y@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 20 Apr 2014 20:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1398051205; bh=QOx2eOqcag1g5fsAnE3xJLDa4g7M3G5NKIkXGT2eYZc=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=I1rmqdUiX2Y9/H/Mr1/Lmg1HBRID8rtzz6kkoaKpa2f6i+ntkSDoGtyuapuKrFwjh GvnXnyfgc7Fx0WHyRb0RO7hD2Hqr4w+YNnqHypKQgh35L4VqWyvyCgRaw5v2cKrVTq G08fNTfOC8pdY+XjYHptTZUTjn6r57vmpNLaR+gY= MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P6SVAPGZY800004W@mauve.mrochek.com>; Sun, 20 Apr 2014 20:33:26 -0700 (PDT) Message-id: <01P6VS26EAV600004W@mauve.mrochek.com> Date: Sun, 20 Apr 2014 20:31:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 09 Apr 2014 09:53:34 -0700" References: <1397060433.18346.YahooMailNeo@web125603.mail.ne1.yahoo.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QASTql31xDdnUGK9pUG6kEdqUo8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RRVS status update and one outstanding question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 03:38:40 -0000 > On Wed, Apr 9, 2014 at 9:20 AM, Bill Mills wrote: > > In the end the local site makes the decision, what we're doing here is > > giving guidance what the site should do in local policy. > > > > > But it's a local policy decision about the security of content they didn't > create. Unlike things like DKIM and such, the protection is aimed at the > sender, not the recipient. > > We could add an error case as well. I'd be fine with that. It exposes > > that the site doesn't know the age of the account, which I consider more to > > be about the site than the account. The sender then has the option to > > resend without RRVS. > > > > > That's a possibility. What do others think? Frankly, I think we've reached the point where we're overdesigning things. If I'm running a site with a bunch of mailboxes, exactly why would it ever be to my advantage to ever bounce mail with this error? Ned From nobody Sun Apr 20 22:42:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2B01A0047 for ; Sun, 20 Apr 2014 22:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPSM6N_TJI1I for ; Sun, 20 Apr 2014 22:42:01 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3321A0005 for ; Sun, 20 Apr 2014 22:42:01 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lj1so3358129pab.6 for ; Sun, 20 Apr 2014 22:41:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mlbO7uV1uCH4UqeZ+orU65Mil6qHRAjB9iL74TSBxV0=; b=hWPnDmjMrM/lbpVLFTK6iqzD6RPxUOTDlySruNE1HHDIyqv1AHbAkfHtD7KwiAK24z 0gHsXWcoSXP19C7ZU5ycI3o1Sw9kPgri35Nq8gUzRgYcYm/Gzqz6bSxsQyCjsbbb6j6P d1G/s00sl4c6bMO1QLtors6W/cUiGPLB30E2bdVCjbhqviSIUbprKe1eisTJaatRJ3u/ hJ+o374BcLHN4iVRAL/r5Z6Qui9knK019LG404tGatn/ddREHIFj66/HjX4+MR0w3JjX JO8oPqHv6OiMdNDbxCI6uLyl53cLjlkr4ntvaCq+TksSw6NZbushurTlLgqqxU10RitG MT0g== X-Gm-Message-State: ALoCoQles1lz5MYAgxZlpnZvEauG5/vlNeGCaL/sXsWFAVH6GYNzqyew0ngYt97LZY2RLnbGjxu5 MIME-Version: 1.0 X-Received: by 10.66.136.71 with SMTP id py7mr36406264pab.2.1398058916377; Sun, 20 Apr 2014 22:41:56 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.103.164 with HTTP; Sun, 20 Apr 2014 22:41:56 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Mon, 21 Apr 2014 01:41:56 -0400 X-Google-Sender-Auth: 7rqPW21TOeMeRy-X8QFLPc6wSsI Message-ID: From: Mark Baker To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/l4c_FttdYO1qI_SzzoaJIDRl-hk Cc: "urn@ietf.org" , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 05:42:05 -0000 On Sun, Apr 20, 2014 at 11:17 AM, Barry Leiba wrote: > Again, addressing just one point here: > > Graham said this: >> DOIs >> are conceived as names, and have the appropriate management processes >> around them applicable to names. But I have observed that in recent times, >> the preferred form for presenting DOIs to the Web has increasingly been in >> the form "http://dx.doi.org/..." or similar (see also: [1]). I think this >> exemplifies something that MAY be used as both identifier and name. > > Phill said this: >>> A string that *you* might *today* call a "name", might already be a >>> "locator" to somebody who's rigged a private resolution service. Ten years >>> from now, that "name" might be a "locator" to all of us. >> >> Which is exactly what I was saying. >> For example, UPC code for a can of baked beans is a URN. >> But if you go to Amazon you can use it as a locator, albeit mediated >> via UPS rather than TCP/IP. > > I think both of these confuse the issue. Given a name, we can often > turn it into a locator. That's clear, and that's one thing that makes > names useful. But I think we still need to keep in mind that the > names *aren't* locators. If I can always take "urn:doi:xyz-abc", > transform it to "http://dx.doi.org/find/xyz-abc", and get a valid > locator for the thing named, that's great. We are not talking about transformation, and I don't consider it a general solution to any known problem with URIs, at least not as commonly discussed (primarily, a spec defining an equivalence mapping between two URIs). > But it's still the case > that the former is a name and *not* a locator. And if dx.doi.org goes > away at some point, the thing is still named by "urn:doi:xyz-abc", > even though I can no longer use that locator. There's nothing stopping that string from being used as a locator. Even if a transformation based approach were used, all I need is another scheme, say "doi2" that's defined so that all its URIs can be transformed to an http scheme URI at dx.doi.org. Whip up a little Javascript registerProtocolHandler with a one line string transform, and whammo, doi2:xyz-abc is a locator for me. Another configuration to consider - to John Levine's point - is using intercepting proxies (or manually configured ones, for those not on the library network) to, e.g. resolve http://dx.doi.org/xx.yy.zz to some local copy stored at the library. I'm sure there are other possible configurations too, that use a similar level of indirection, perhaps using other mechanisms (DNS?). So let's please forget about this "name" and "locator" stuff since those labels are so context dependent as to be useless in any broadly scoped discussion like this. There are only identifiers. From nobody Mon Apr 21 02:19:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4AE1A0045; Mon, 21 Apr 2014 02:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4aXyPmyAW3X; Mon, 21 Apr 2014 02:19:27 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id C8E2D1A0109; Mon, 21 Apr 2014 02:19:26 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id B261E32E4AC; Mon, 21 Apr 2014 18:19:20 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 56e0_bb63_bb28ebb9_8d69_4dc0_9027_b050abbda10f; Mon, 21 Apr 2014 18:19:20 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E6A0EBFBD3; Mon, 21 Apr 2014 18:19:19 +0900 (JST) Message-ID: <5354E28B.9070904@it.aoyama.ac.jp> Date: Mon, 21 Apr 2014 18:19:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Mark Baker , Barry Leiba References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Gxd8phAAFkbMhaCX5Dgf7exNPVI Cc: "urn@ietf.org" , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 09:19:30 -0000 On 2014/04/21 14:41, Mark Baker wrote: > On Sun, Apr 20, 2014 at 11:17 AM, Barry Leiba wrote: >> But it's still the case >> that the former is a name and *not* a locator. And if dx.doi.org goes >> away at some point, the thing is still named by "urn:doi:xyz-abc", >> even though I can no longer use that locator. > > There's nothing stopping that string from being used as a locator. > > Even if a transformation based approach were used, all I need is > another scheme, say "doi2" that's defined so that all its URIs can be > transformed to an http scheme URI at dx.doi.org. Whip up a little > Javascript registerProtocolHandler with a one line string transform, > and whammo, doi2:xyz-abc is a locator for me. > > Another configuration to consider - to John Levine's point - is using > intercepting proxies (or manually configured ones, for those not on > the library network) to, e.g. resolve http://dx.doi.org/xx.yy.zz to > some local copy stored at the library. I'm sure there are other > possible configurations too, that use a similar level of indirection, > perhaps using other mechanisms (DNS?). > > So let's please forget about this "name" and "locator" stuff since > those labels are so context dependent as to be useless in any broadly > scoped discussion like this. There are only identifiers. Yes indeed. I occasionally get students making presentations based on outdated (but Japanese) material that makes a sharp name/locator distinction, or get asked by students about the difference between URLs and URNs. I always explain that in the context of a traditional library (i.e. physical books), the distinction is very easy: When you want to borrow/read a book, you don't care which copy you get, because they all look the same, but in order to actually get a copy, you have to know where it is. However, as soon as you move to the Web (or any other electronic system), things start to get blurred. Caching (in CDNs, in proxies, by your browser, in core memory,...) and similar tricks (multiple servers,...) produce lots of copies, but you for most purposes, you don't have to be concerned where they are, that's all handled "under the hood". Even where it's not, it's always easy to make it so (see examples above). That's why library people used to see the name/location distinction as an absolute one, and there are still some applications with a strong tie-in to that model (which is alright by me), but why we should keep our infrastructure flexible to allow different models to coexist. Regards, Martin. From nobody Mon Apr 21 04:37:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FFF1A01FA; Mon, 21 Apr 2014 04:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.037 X-Spam-Level: ** X-Spam-Status: No, score=2.037 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYzdfb-YJPt2; Mon, 21 Apr 2014 04:37:40 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id B0C991A01F7; Mon, 21 Apr 2014 04:37:39 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4B38032E4AC; Mon, 21 Apr 2014 20:37:34 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 56dd_070c_482ecded_259c_4849_a740_2bbcd394960e; Mon, 21 Apr 2014 20:37:34 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 786E8BF4CE; Mon, 21 Apr 2014 20:37:33 +0900 (JST) Message-ID: <535502F1.8080201@it.aoyama.ac.jp> Date: Mon, 21 Apr 2014 20:37:21 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John C Klensin , Phillip Hallam-Baker , Mark Baker References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> In-Reply-To: <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VudEpEg1n5O8YYfbOCPuU4O5mgc Cc: Julian Reschke , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 11:37:41 -0000 On 2014/04/19 21:59, John C Klensin wrote: > --On Friday, April 18, 2014 22:34 -0400 Phillip Hallam-Baker > wrote: > >>> A string that *you* might *today* call a "name", might >>> already be a "locator" to somebody who's rigged a private >>> resolution service. Ten years from now, that "name" might be >>> a "locator" to all of us. >> >> Which is exactly what I was saying. >> >> For example, UPC code for a can of baked beans is a URN. >> >> But if you go to Amazon you can use it as a locator, albeit >> mediated via UPS rather than TCP/IP. > > As Mark Nottingham suggested and I tried to elaborate, this > particular discussion may be interesting (or not), but, in the > current context, isn't worth the energy it takes. Well, no, it's exactly at the very core of the issue. See below for more. > First, a UPC code for a can of beans isn't a URN. If an > identifier for those were documented and registered as an NID, > or if it were treated as part of an identifier sub-space within > the "epc" NID specified in RFC 5134, _that_ would be a URN. Okay up to here. Let's assume that done. > As > a URN, the defining materials would presumably come with a lot > of information about what it was and what operations could be > performed with it. For a URN based on that UPC associated with > a can of beans, those operations might include whether its > purpose is just to distinguish one brand or can-size of beans > from another or whether it can be used to retrieve a product > (see below). No. The URN/UPC just stands for the can of beans. What you can do with it depends on where you use it. Here's where Phil's example comes in very handy. Amazon will provide different operations on that URN than e.g. a service by the registration authority or by a manufacturer who doesn't ship directly to end users. > That set of distinctions is not just pedantry. If "URN" mean > whatever someone claims it means at a given moment, That's not what we are talking about. The identifier still means the same. It's one and the same specific kind of can of beans. > then we > don't have a specific category of identifier, we just have a > very generic term for some variety of identifier. For the > information it contains, one might as well have the above > statement read "UPC code for a can of baked beans is an > Ironduck". > > Even ignoring whether it is a URN or not, a UPC doesn't act as a > UPS-mediated locator, any more than urn:isbn:0-88175-188-X is a > TCP-medidated locator. It is an identifier of an abstraction of > a class of objects. To get the object to your doorstep, it is > typically necessary to resolve it to a different product > abstraction, to a warehouse and location in it, to a > shelf-picking mechanism, and so on, typically through several > step before a particular can-instance is finally chosen, boxed, > labeled, and handed over to UPS (or some other transit carrier > whose choice might be another item in the list of > abstraction-resolutions. Of course. That's what I wrote about in a separate mail. Even for a simple "locator" such as "http://www.ietf.org", there are many very similar (although much less physically visible) steps involved. And as in the case of something like "http://www.ietf.org", the average user on average doesn't want to care much about all these intermediate steps. > In addition, like many URNs (see my notes on the URN list), > there are other useful questions that apply to the > generically-named object and not to the particular can that > might be located. For example, "what is the size of the can > associated with that code" is a question about the generic named > object. "What is the sell-by date" probably still doesn't apply > to a particular can that needs to be located and retrieved > before the question can be answered -- perhaps it is sufficient > to locate a case of cans and to do so in an appropriate database. > > So I suggest they are still different from http-type URLs in > more ways than the [retrieval] method. But, again as Mark > Nottingham pointed out, it may be that the greatest value of > this proposed separation is to get around the situation of > different communities talking past each other and being > unwilling to accept each other's perspective and legitimacy even > to the extent needed to have a real conversation. No, we have had different communities talking past each other in the past, and have surmounted that very well. The problem with any separation is that it eliminates any potential benefit of being able to both URLs and URNs interchangeably where they are interchangeable. Of course they are not always interchangeable. But that's no reason for separation. Regards, Martin. From nobody Mon Apr 21 08:35:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF71A018F; Mon, 21 Apr 2014 08:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_bgs7XxFcE6; Mon, 21 Apr 2014 08:35:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id EB17F1A0004; Mon, 21 Apr 2014 08:35:46 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.921.12; Mon, 21 Apr 2014 15:35:35 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0921.000; Mon, 21 Apr 2014 15:35:35 +0000 From: Larry Masinter To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , "Mark Baker" , Barry Leiba Thread-Topic: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPXULmAT2EmtpMTUSdTNDq2695iZscLcqg Date: Mon, 21 Apr 2014 15:35:34 +0000 Message-ID: <5885b538abd9403e9434699bfff36a8e@BL2PR02MB307.namprd02.prod.outlook.com> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <5354E28B.9070904@it.aoyama.ac.jp> In-Reply-To: <5354E28B.9070904@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.10.203] x-forefront-prvs: 0188D66E61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(79102001)(76482001)(20776003)(77982001)(15202345003)(99396002)(74662001)(86362001)(74502001)(54356999)(31966008)(50986999)(77096999)(76176999)(76576001)(15975445006)(33646001)(66066001)(46102001)(80022001)(4396001)(99286001)(85852003)(81342001)(19580395003)(83072002)(83322001)(2656002)(92566001)(80976001)(224303002)(87936001)(81542001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:9DBBF138.8C3284DB.70EABE7B.44EBD47C.201A5; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Eec1qnJgPIuEotDKgONEMCkZ87g Cc: "urn@ietf.org" , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 15:35:51 -0000 There's a problem with using 'locator' and 'name' as categories for strings= -- strings are strings. Whether a string is a 'locator' or 'name' depends= on how it's used. =20 That the same string can be used as a locator and a name is an important pu= n: XML namespace names use IRIs as names, so that it's primary use is as a= name, but it can also be used as a locator to find more information about = the thing named. More generally, the "semantic web" uses URLs to name thing= s, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-Vocabul= ary -- easy allocation, and allows one to locate information about the thin= g named. URLs can be persistent ('data:', and http://tools.ietf.org/html/draft-masin= ter-dated-uri ) and URNs can be as temporary as the URN namespace authority urn:authority:= authority-name-for-thing. Do not confuse a location optimization used in locating (cache, proxy, web = archive) with the actual meaning. The actual meaning depends on how you wo= uld resolve disputes over meaning.=20 Larry -- http://larry.masinter.net From nobody Mon Apr 21 09:51:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F2B1A0139; Fri, 18 Apr 2014 12:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk6OH0NSAECp; Fri, 18 Apr 2014 12:53:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E00611A002E; Fri, 18 Apr 2014 12:53:27 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WbEqP-000DNP-77; Fri, 18 Apr 2014 15:53:05 -0400 Date: Fri, 18 Apr 2014 15:53:00 -0400 From: John C Klensin To: Mark Nottingham Message-ID: In-Reply-To: <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_56gXedWGm6qD611saZ7vTh_2_M X-Mailman-Approved-At: Mon, 21 Apr 2014 09:51:33 -0700 Cc: "Julian F. Reschke" , urn@ietf.org, Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 19:53:31 -0000 --On Friday, April 18, 2014 11:44 +1000 Mark Nottingham wrote: > I have to say that I'm sympathetic to the proposed outcomes, > albeit for different reasons, perhaps. > > We have two communities using a shared artefact (URIs) with > vastly differing use cases and viewpoints about them. Managing > this situation has already proven extremely difficult for the > IETF, and it seems to me to be very pragmatic to cease forcing > them to co-exist, constantly bickering about angels dancing on > pins. Mark, The above is actually a slightly different version of what drove me to propose the "separate URNs" change in the new draft. As you say, we have two different communities with different assumptions, exemplars, and perceived needs. The one thing they have in common is that neither accepts and interprets the examples of the other in the same way. Indeed, each community tends to reject the legitimacy of the position and arguments of the other and often to be dismissive and as far as I can tell, largely stops listening. More on that below, but let me suggest there are two separate discussions that we can have now: (1) Whether to continue to try to defend a Grand Unified "Uniform Resource Identifier" theory (and, in your words, "shared artifact"), with each of those words meaning whatever it does to the person who pronounces it, or to let the communities you mention go off and develop solutions to their own perceived problems. The predictable consequence of the first is going to be standards development elsewhere, rather than stopping what some perceive as bad behavior... we are just past "stopping" those communities with which some other community disagrees. (2) The details of what the community that the draft identifies as "content industries and memory organizations" need in URNs and how to organize that information. I will comment on that subthread, but only on the URN list. There is an additional potential discussion about what choices we would make if we could turn the clock back to 1994 or 1996 or about how things would have been defined in a better world (perhaps turning some other clocks back to the 12th century or earlier). I think that discussion would be interesting and educational, but that, for the IETF right now, it is just a distraction, best injected into the two questions above only if one's goal is to prevent progress. Of course, some people may disagree with that position and probably do. Those who are not interested in the details of my thinking about the first issue and the reasons why we are in this position can safely stop reading now. ----------- Sadly, some of these same arguments --including the implied "I am right, you don't count, and I don't need to listen" tone of a subset-- go back to the original URI WG and some of the reasons I shut it down in 1995 (and resolved, unsuccessfully, to stay out of this area after that). It has become clear in URNBIS WG discussions that some of those in other communities sincerely believe that RFC 3986 doesn't represent consensus, only an example of how a determined minority can outlast and then overwhelm others (and, from their point of view, reason and experience). More recently, Martin cites a number of articles and says "Please don't come back here before you have read it!". Some members of another community consider some of the statements in those articles to be a big joke, a massive demonstration of lack of understanding, or worse. Other statements help demonstrate that we aren't making progress (for example, the 1998 "Model Consequences" document Martin cites identifies the "views of URI syntax" as a contrast between the "name ':' anything" approach that Phillip brought up as the only reasonable possibility and "uniform sharing of URI syntax to the extent it may make sense". What seems to be different now from a few years ago is that people in some of those other communities have reached the point of being willing to do their own standards work, reflecting their perceived needs, because they view their needs as real and based on real experience and the IETF community as hopelessly paralyzed and not listening. Independent of whether they are in-scope, the WHATWG and W3C efforts, and maybe the lack of consensus and diminishing energy in the IETF IRI WG, may be symptoms of that trend. I'm still convinced that the IETF's experience, perspective, and scope still have useful things to bring to this discussion. Maybe I'm naive. But it seems to me that the choice at this particular time isn't between how broadly URIs can reach, how much hair-splitting we can perform about "persistent" or "locator versus object identifier" but about whether we can separate things sufficiently to let the two (or more) communities go their own ways under a broad IETF umbrella or whether we prefer standardization work in this set of areas to be done elsewhere, most likely (given trends in W3C and WHATWG as well as in URNBIS) with most of the relevant groups agreeing only the 3956 is not relevant to their needs and plans. john From nobody Mon Apr 21 09:51:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADED1A0201; Sat, 19 Apr 2014 06:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtdW4uKcRrLq; Sat, 19 Apr 2014 06:00:05 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 795271A0194; Sat, 19 Apr 2014 06:00:05 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WbUs6-000F0s-0f; Sat, 19 Apr 2014 08:59:54 -0400 Date: Sat, 19 Apr 2014 08:59:49 -0400 From: John C Klensin To: Phillip Hallam-Baker , Mark Baker Message-ID: <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oFaVFtQECtrAH8Qf2HBjRGpExK8 X-Mailman-Approved-At: Mon, 21 Apr 2014 09:51:33 -0700 Cc: Julian Reschke , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 13:00:08 -0000 --On Friday, April 18, 2014 22:34 -0400 Phillip Hallam-Baker wrote: >> A string that *you* might *today* call a "name", might >> already be a "locator" to somebody who's rigged a private >> resolution service. Ten years from now, that "name" might be >> a "locator" to all of us. > > Which is exactly what I was saying. > > For example, UPC code for a can of baked beans is a URN. > > But if you go to Amazon you can use it as a locator, albeit > mediated via UPS rather than TCP/IP. As Mark Nottingham suggested and I tried to elaborate, this particular discussion may be interesting (or not), but, in the current context, isn't worth the energy it takes. First, a UPC code for a can of beans isn't a URN. If an identifier for those were documented and registered as an NID, or if it were treated as part of an identifier sub-space within the "epc" NID specified in RFC 5134, _that_ would be a URN. As a URN, the defining materials would presumably come with a lot of information about what it was and what operations could be performed with it. For a URN based on that UPC associated with a can of beans, those operations might include whether its purpose is just to distinguish one brand or can-size of beans from another or whether it can be used to retrieve a product (see below). That set of distinctions is not just pedantry. If "URN" mean whatever someone claims it means at a given moment, then we don't have a specific category of identifier, we just have a very generic term for some variety of identifier. For the information it contains, one might as well have the above statement read "UPC code for a can of baked beans is an Ironduck". Even ignoring whether it is a URN or not, a UPC doesn't act as a UPS-mediated locator, any more than urn:isbn:0-88175-188-X is a TCP-medidated locator. It is an identifier of an abstraction of a class of objects. To get the object to your doorstep, it is typically necessary to resolve it to a different product abstraction, to a warehouse and location in it, to a shelf-picking mechanism, and so on, typically through several step before a particular can-instance is finally chosen, boxed, labeled, and handed over to UPS (or some other transit carrier whose choice might be another item in the list of abstraction-resolutions. In addition, like many URNs (see my notes on the URN list), there are other useful questions that apply to the generically-named object and not to the particular can that might be located. For example, "what is the size of the can associated with that code" is a question about the generic named object. "What is the sell-by date" probably still doesn't apply to a particular can that needs to be located and retrieved before the question can be answered -- perhaps it is sufficient to locate a case of cans and to do so in an appropriate database. So I suggest they are still different from http-type URLs in more ways than the [retrieval] method. But, again as Mark Nottingham pointed out, it may be that the greatest value of this proposed separation is to get around the situation of different communities talking past each other and being unwilling to accept each other's perspective and legitimacy even to the extent needed to have a real conversation. john From nobody Mon Apr 21 09:51:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12531A0106; Sat, 19 Apr 2014 15:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm7GASgwpA8o; Sat, 19 Apr 2014 15:49:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 984461A0100; Sat, 19 Apr 2014 15:49:19 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wbe4N-000FqC-15; Sat, 19 Apr 2014 18:49:11 -0400 Date: Sat, 19 Apr 2014 18:49:10 -0400 From: John C Klensin To: Nico Williams Message-ID: <9B60F36DE9B614859C913A16@[192.168.1.128]> In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/j-MuL7N5s_-7KvT37OgTpWmI3pQ X-Mailman-Approved-At: Mon, 21 Apr 2014 09:51:33 -0700 Cc: Julian Reschke , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 22:49:21 -0000 Nico, (top post) Referring to Barry's recent note on the URN mailing list and my response, are you referring the URNs-the-category or urns-the-scheme? If the former, I agree that I don't care, no one else should either. More important, the new I-D isn't about that. If the latter, then I expect that you really should go through the registration procedure described in RFC 3406 if you have not done so. john --On Saturday, 19 April, 2014 17:38 -0500 Nico Williams wrote: > On Sat, Apr 19, 2014 at 7:59 AM, John C Klensin > wrote: >> That set of distinctions is not just pedantry. If "URN" mean >> whatever someone claims it means at a given moment, then we >> don't have a specific category of identifier, we just have a >> very generic term for some variety of identifier. For the >> information it contains, one might as well have the above >> statement read "UPC code for a can of baked beans is an >> Ironduck". > > In GSS land we've switched (for new interfaces) from using > ASN/1 OIDs to using URNs. Our OIDs name no objects and our > URNs no resources. They are merely identifiers with reasonable > namespaces and name allocation policies. URNs are much easier > to use for this purpose (one look at how the GSS-API C > language bindings handle OIDs should make this clear!). Is > this an abuse of URNs? Does/should anyone care? IMO: "no", > and "no". But it helps to have registered identifiers, so we > can find the specifications (or at least some information) > that describe their semantics. Or perhaps our uses of > OIDs/URNs do in fact name objects/resources, if we give > specific behaviors/semantics the honor of being > objects/resources. > > For me, all that matters when it comes to URNs is that we > agree to namespace partitioning and registries for those uses > that warrant them. If you want to call URNs "Ironducks", so > be it. From nobody Tue Apr 22 04:26:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2B01A03A0; Tue, 22 Apr 2014 04:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tiuTBCHntTn; Tue, 22 Apr 2014 04:26:28 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) by ietfa.amsl.com (Postfix) with ESMTP id 947611A0079; Tue, 22 Apr 2014 04:26:28 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59958) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1WcYqB-0005My-Yt (Exim 4.82_3-c0e5623) (return-path ); Tue, 22 Apr 2014 12:26:19 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WcYqB-0006tr-P9 (Exim 4.72) (return-path ); Tue, 22 Apr 2014 12:26:19 +0100 Date: Tue, 22 Apr 2014 12:26:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2-heqJ_DHLEJwE4y8-Fuvu3OvWg Cc: Julian Reschke , John C Klensin , urn@ietf.org, General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 11:26:33 -0000 Phillip Hallam-Baker wrote: > On Thu, Apr 17, 2014 at 5:39 PM, Julian Reschke wrote: > > On 2014-04-16 20:58, Phillip Hallam-Baker wrote: > >> > >> The real difference is that a URL must contains a DNS name and a URN > >> probably does not. > >> ... > > > > Not true. It doesn't need to be a DNS name. > > Why bother with anything else? You might want to use an mDNS name, or a TOR .onion name, etc. Tony. -- f.anthony.n.finch http://dotat.at/ West Wight, Portland, Plymouth, North Biscay: Mainly southerly or southwesterly 4 or 5, occasionally 6. Slight or moderate. Occasional rain or showers. Moderate or good, occasionally poor. From nobody Tue Apr 22 07:18:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD21A0484; Tue, 22 Apr 2014 07:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zETEBRRKcnxH; Tue, 22 Apr 2014 07:17:58 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 212AC1A047C; Tue, 22 Apr 2014 07:17:57 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id p9so4354616lbv.38 for ; Tue, 22 Apr 2014 07:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7QGiZlfQqnucMQbr8KgqOdh96hjtbTM4mBE/Ma75aP0=; b=lTplIhsLlnj8e9rqAgItsYvHVEcvXZeWXHiVZzR7sHdOfr0lKMYvcb2UkTCPLVWlcr w0bv7Mwxny5tDTVthuSsrhIXP3TVSCU2TfVoGiFTIXtm68KccGSuHtoNlUbzOGKJRLts THxpyJpr4NvS8H/fRn19TiZvOlssNmW3zv2viPgoqx0aIj3DG5bkCPIk85MJbWZRJEVa os/z71R1JRVyxXSNqlBkvkStPCw1p1EZJwi+A/eTZ/EQfWUDwG4bRtKWX8r/fkgpJDY4 neZ+uLh9WmgHliYM9dpmFiWQZJdocioz/s/vi6p6RKVga+nKDOEGHbe2rromvYqZyMq/ As9A== MIME-Version: 1.0 X-Received: by 10.152.10.72 with SMTP id g8mr2042824lab.50.1398176271094; Tue, 22 Apr 2014 07:17:51 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 22 Apr 2014 07:17:50 -0700 (PDT) In-Reply-To: References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> Date: Tue, 22 Apr 2014 10:17:50 -0400 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HxrcdzlYzZYKtdBiCTqwG2f1Hdo Cc: "Julian F. Reschke" , Mark Nottingham , urn@ietf.org, Graham Klyne , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 14:18:04 -0000 On Fri, Apr 18, 2014 at 3:53 PM, John C Klensin wrote: > > > --On Friday, April 18, 2014 11:44 +1000 Mark Nottingham > wrote: > >> I have to say that I'm sympathetic to the proposed outcomes, >> albeit for different reasons, perhaps. >> >> We have two communities using a shared artefact (URIs) with >> vastly differing use cases and viewpoints about them. Managing >> this situation has already proven extremely difficult for the >> IETF, and it seems to me to be very pragmatic to cease forcing >> them to co-exist, constantly bickering about angels dancing on >> pins. > > Mark, > > The above is actually a slightly different version of what drove > me to propose the "separate URNs" change in the new draft. As > you say, we have two different communities with different > assumptions, exemplars, and perceived needs. The one thing they > have in common is that neither accepts and interprets the > examples of the other in the same way. I think the disagreement is over what counts as an example. Back in the early days of URNs I remember a lot of people telling me that naming 'was hard' but could not explain why and that 'only a few people understand it' but not who. After a while I got rather tired of that mode of argument and decided that I won't accept any argument that is not stated within the four corners of the message or cited directly. > Indeed, each community > tends to reject the legitimacy of the position and arguments of > the other and often to be dismissive and as far as I can tell, > largely stops listening. More on that below, but let me suggest > there are two separate discussions that we can have now: Well either a URN is a distinct class from a URL or it isn't. One of the things that makes me rather suspicious about the argument is that every URL is based on a name, that is either a DNS name or an IP address both of which are names in tat the relationship between the signifier and the signified is purely convention. (In the case of an IP address the addresses are resolved via BGP) Making a distinction between URIs that are based on a naming infrastructure that is defined by the IETF and those that are not seems to me to be a perfectly sensible approach for the IETF to take. > (1) Whether to continue to try to defend a Grand Unified > "Uniform Resource Identifier" theory (and, in your words, > "shared artifact"), with each of those words meaning whatever it > does to the person who pronounces it, or to let the communities > you mention go off and develop solutions to their own perceived > problems. The predictable consequence of the first is going to > be standards development elsewhere, rather than stopping what > some perceive as bad behavior... we are just past "stopping" > those communities with which some other community disagrees. I am not sure what the above means. I can't parse it. The IETF has limited bandwidth, the Internet has 3 billion users. So less than 1/millionth of the Internet population is currently active in IETF. Decisions and standards are going to get made in many places. Whether any grand unified theory can be defended depends on the claims made. If the claims made are extensive then the theory is likely to collapse. If the claims are weak then it can be defended but has little impact. > (2) The details of what the community that the draft identifies > as "content industries and memory organizations" need in URNs > and how to organize that information. I will comment on that > subthread, but only on the URN list. This is the part that I always have problems with, the idea that the structure or syntax of the identifier has any impact on whether it meets requirements such as long term resolution. The only URI that is guaranteed to resolve to the signified content unconditionally is the DATA method. The only URIs that are shorter than the signified data that can claim to be permanent are indexical, in most cases based on one way functions such as 'hashes', 'fingerprints' and 'digests'. Its not the syntax of a naming infrastructure that gives it longevity, it is the political and business context in which it operates. > Sadly, some of these same arguments --including the implied "I > am right, you don't count, and I don't need to listen" tone of a > subset-- go back to the original URI WG and some of the reasons > I shut it down in 1995 (and resolved, unsuccessfully, to stay > out of this area after that). I don't think it was one side of the argument guilty of that. Most of my objections to various URN schemes come from the confusion of requirements and mechanism. If someone is saying that we must recognize a set of URIs as 'special' because of a particular set of requirements then I want to see a demonstration that 1) The particular set of requirements can be met 2) The distinction insisted on helps meet them > It has become clear in URNBIS WG > discussions that some of those in other communities sincerely > believe that RFC 3986 doesn't represent consensus, only an > example of how a determined minority can outlast and then > overwhelm others (and, from their point of view, reason and > experience). Yep > I'm still convinced that the IETF's experience, perspective, and > scope still have useful things to bring to this discussion. > Maybe I'm naive. But it seems to me that the choice at this > particular time isn't between how broadly URIs can reach, how > much hair-splitting we can perform about "persistent" or > "locator versus object identifier" but about whether we can > separate things sufficiently to let the two (or more) > communities go their own ways under a broad IETF umbrella or > whether we prefer standardization work in this set of areas to > be done elsewhere, most likely (given trends in W3C and WHATWG > as well as in URNBIS) with most of the relevant groups agreeing > only the 3956 is not relevant to their needs and plans. Which is precisely why I suggest dividing the world up into 'that which the IETF is authoritative on' and 'that which the IETF is not authoritative on'. -- Website: http://hallambaker.com/ From nobody Tue Apr 22 13:27:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82DD1A0258 for ; Tue, 22 Apr 2014 13:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRgc_C1B4oEw for ; Tue, 22 Apr 2014 13:27:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4401A025C for ; Tue, 22 Apr 2014 13:27:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422202720.11186.86705.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 13:27:20 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ze0vWqaHgdtlRf33q8C5ab8awfg Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 20:27:23 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-uri-get-off-my-lawn", resolved as "Done". URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Tue Apr 22 13:46:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF491A003D for ; Tue, 22 Apr 2014 13:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgcF30uf0bu6 for ; Tue, 22 Apr 2014 13:46:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 002EE1A026B for ; Tue, 22 Apr 2014 13:46:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422204616.20421.93500.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 13:46:16 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oy9OVTslW7inhNl8tLDAq1yguOU Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 20:46:26 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-uri-scheme-reg", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Tue Apr 22 21:33:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FF71A003B; Tue, 22 Apr 2014 21:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3F3R_2HdcJp; Tue, 22 Apr 2014 21:33:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1923B1A02B3; Tue, 22 Apr 2014 21:33:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423043327.18865.21590.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 21:33:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YPWoE4Ij7K0fWldvUr3sqCCYGJY Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 04:33:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : URI Design and Ownership Author : Mark Nottingham Filename : draft-ietf-appsawg-uri-get-off-my-lawn-04.txt Pages : 8 Date : 2014-04-22 Abstract: RFC3986 Section 1.1.1 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-get-off-my-lawn-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 23 05:28:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999551A033C for ; Wed, 23 Apr 2014 05:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Bv-RT4eEIsP for ; Wed, 23 Apr 2014 05:28:20 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id C12521A01C3 for ; Wed, 23 Apr 2014 05:28:20 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md12so739741pbc.21 for ; Wed, 23 Apr 2014 05:28:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=CjWwz59g66p7rJ1vS5rJLCBmS8UhBSLu/ZpVlU6kDp0=; b=I2BxsfBe8LRdU9pGK/pgPbbmm9/OStMB/0ssSGMu/ijgjRGXN39SzBUiMjgVVx3z7Y 4FKM5kO63xTMjQZg7WeH/t12DeznUhn6U8k1SekUyn7PYKWvTVNsn2YTlg3tfK479ZGr +As6tVliZmmHITkEYsC6/pqFh+t1tuolvN0HKgi+xXPy5QP2wjZ2+qN5pqZ65lF3FiNk /3bmn1HCm3sV2XjqrIJy4W6rMI03afR5v74MlQKxn1ixlrlfQ74TCaHECZqfGGsRFDR5 NHLaER5QBrBaWlOiBoyVqHwH6MazLfEUnuh15IYY5fxrDaxDMtaYvdBWMQRMWW2JOZ37 3T8w== X-Gm-Message-State: ALoCoQn3i1IdGHvVzABwPRLRTnvNXsvknjjKsrE8fIpyEoEej1ev9JMBBq2vGTrPWzhA3NYoqyxR MIME-Version: 1.0 X-Received: by 10.68.139.36 with SMTP id qv4mr54496025pbb.82.1398256095115; Wed, 23 Apr 2014 05:28:15 -0700 (PDT) Received: by 10.66.16.200 with HTTP; Wed, 23 Apr 2014 05:28:15 -0700 (PDT) X-Originating-IP: [67.187.54.51] In-Reply-To: <20140423043327.18865.21590.idtracker@ietfa.amsl.com> References: <20140423043327.18865.21590.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 08:28:15 -0400 Message-ID: From: Andrew Newton To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cmGFj3iJ6Dd9hTibLVTJtXTyb9Q Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 12:28:22 -0000 I have read this draft and am generally supportive of it. Many of the issues have been resolved. I do have one question. Section 2.3 constrains applications (in the all other specifications category) from constraining paths with MUST NOT. Section 2.4 constrains query components with applications with SHOULD NOT. Why the difference since the harm from doing both is the same? In my opinion, Section 2.3 should place applications at the SHOULD NOT compliance level. -andy On Wed, Apr 23, 2014 at 12:33 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : URI Design and Ownership > Author : Mark Nottingham > Filename : draft-ietf-appsawg-uri-get-off-my-lawn-04.txt > Pages : 8 > Date : 2014-04-22 > > Abstract: > RFC3986 Section 1.1.1 defines URI syntax as "a federated and > extensible naming system wherein each scheme's specification may > further restrict the syntax and semantics of identifiers using that > scheme." In other words, the structure of a URI is defined by its > scheme. While it is common for schemes to further delegate their > substructure to the URI's owner, publishing independent standards > that mandate particular forms of URI substructure is inappropriate, > because that essentially usurps ownership. This document further > describes this problematic practice and provides some acceptable > alternatives for use in standards. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-get-off-my-lawn-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Apr 23 05:44:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688261A0366; Wed, 23 Apr 2014 05:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2Pg4BBDgxDm; Wed, 23 Apr 2014 05:44:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC491A0377; Wed, 23 Apr 2014 05:44:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 05:44:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/R_UiUdywOH20gb7bHuo-BBzpRIA Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 12:44:23 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'URI Design and Ownership' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC3986 Section 1.1.1 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Apr 23 06:51:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44BB1A03A8; Wed, 23 Apr 2014 06:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r90TdV0EGXj3; Wed, 23 Apr 2014 06:51:23 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 567FE1A03A7; Wed, 23 Apr 2014 06:51:23 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so808432lbd.1 for ; Wed, 23 Apr 2014 06:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BwNt7vLT8cfyUG3OvOLIHqJDm9nl6w+goMCj161KPm4=; b=N3JUJvNzTPQVikTVj/37Uc8b4YtZsCcOczkrpqDq+E40CgwPN8ARJK/E1o34ORGqCd lqe5ZLOiSqFsw+xHuE6S3Hy90UsjwWbv34yGLdnfHrXA32z7GiUKQcVcb+VLF/N6QjYK TJJgYTJPdRa5nmPDsX14u6kpFxklErFZ6fijNBC4fkm3DVhc8lORVNhFN/Hcf9vcP6QR adY0Wa1f5uagGUlAED/boeUxE4H5XYbv6Z+cpnKg/VDHxEXowsJDP7xPk3lp+MkwFZje j8yjmzLmcSZ73DRzjynAh7jAgrfAxSlcXBuAhczYplmavb6FVP8wE8YMBhDFLbVAknx2 z79Q== MIME-Version: 1.0 X-Received: by 10.152.43.107 with SMTP id v11mr1356070lal.49.1398261077024; Wed, 23 Apr 2014 06:51:17 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 23 Apr 2014 06:51:16 -0700 (PDT) In-Reply-To: <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> Date: Wed, 23 Apr 2014 09:51:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Maurizio Lunghi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/y3H8ejLCYoPwNKdZxnwC4npv3Dk Cc: General discussion of application-layer protocols , "Julian F. Reschke" , Graham Klyne , Mark Nottingham , John C Klensin , "urn@ietf.org" Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 13:51:25 -0000 On Wed, Apr 23, 2014 at 6:04 AM, Maurizio Lunghi wrote: > I am wondering if it is useful and maybe necessary to define what a 'pers= istent identifier' is .... as many of you said technology is mot persistent= per se but policy underpinning the system can make persistent the identifi= ers and the service linked to them .... in the APARSEN project www.aparsen.= eu in WP 22 we reached agreement with many experts about a list of criteria= that a 'trusted persistent identifier system' must have and we could start= from this work to define a broader consensus .... doing so in my view we = could clearly distinguish between a URN or URI and a PI ... does it sound r= easonable? > People have been compiling wish lists for properties of names for 20+ years. The issue is not what people would want, it is what they can get. I can't take the 'urn' approach seriously until someone provides an explanation of 1) How the persistence properties are to be achieved 2) Why a taxonomic distinction between URLs and URNs helps achieve the persistence properties. A name is by definition a signifier that bears only a conventional relationship to the thing signified. In the case of DNS that relationship is mediated by the DNS infrastructure. There are only two ways to make an identifier persistent. The first being to use an index rather than a name. SHA256(c) is a persistent identifier for the content c. Which is what we use in the ni: scheme. The second is to have a first come, first served registry that never revokes previous assignments. Now one could imagine a whole new infrastructure for establishing such a scheme. But really, wouldn't anyone setting up such a scheme apply for a TLD? So now imagine we have .pid which is a first come, first served registry that never revokes an assignment or alternatively requires the date to be inserted into the HTTP URIs. I can give you a HTTP method identifier which is persistent using such an infrastructure. Now we can argue over whether the proposal I make is actually practical. But I think it is at least as practical as all the 'persistent identifier' schemes based on a new registry. The bottom line is that persistence is a qualified property of a naming infrastructure, not a syntactic distinction. If people want to argue further, I want them to put up and show HOW their persistence scheme actually works. No more wish lists or requirements for identifiers. I want to see how the scheme works at a technical and political level to achieve the persistence requirements. --=20 Website: http://hallambaker.com/ From nobody Thu Apr 24 06:44:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860CB1A0191; Wed, 23 Apr 2014 03:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.615 X-Spam-Level: ** X-Spam-Status: No, score=2.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Pv2wVcERpFg; Wed, 23 Apr 2014 03:05:14 -0700 (PDT) Received: from remote.rinascimento-digitale.it (93-63-166-139.ip28.fastwebnet.it [93.63.166.139]) by ietfa.amsl.com (Postfix) with ESMTP id 33B911A019B; Wed, 23 Apr 2014 03:05:13 -0700 (PDT) Received: from FRD01.frd.local ([fe80::30bc:ca96:e16f:8923]) by FRD01.frd.local ([fe80::30bc:ca96:e16f:8923%10]) with mapi id 14.03.0174.001; Wed, 23 Apr 2014 12:04:56 +0200 From: Maurizio Lunghi To: Phillip Hallam-Baker Thread-Topic: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPXjWvNZcweYtOikiEcFO5n/xexZse+omz Date: Wed, 23 Apr 2014 10:04:55 +0000 Message-ID: <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> , In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.5.0.1057-7.500.1017-20650.005 x-tm-as-result: No--42.276200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Vxxn3ANO_obL2Jg3zY7kHH_FHpE X-Mailman-Approved-At: Thu, 24 Apr 2014 06:43:58 -0700 Cc: General discussion of application-layer protocols , "Julian F. Reschke" , Graham Klyne , Mark Nottingham , John C Klensin , "urn@ietf.org" Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 10:05:17 -0000 I am wondering if it is useful and maybe necessary to define what a 'persis= tent identifier' is .... as many of you said technology is mot persistent p= er se but policy underpinning the system can make persistent the identifier= s and the service linked to them .... in the APARSEN project www.aparsen.eu= in WP 22 we reached agreement with many experts about a list of criteria t= hat a 'trusted persistent identifier system' must have and we could start f= rom this work to define a broader consensus .... doing so in my view we co= uld clearly distinguish between a URN or URI and a PI ... does it sound rea= sonable? thanks Maurizio Lunghi > On 22 Apr 2014, at 16:18, "Phillip Hallam-Baker" wrote= : >=20 >> On Fri, Apr 18, 2014 at 3:53 PM, John C Klensin wrot= e: >>=20 >>=20 >> --On Friday, April 18, 2014 11:44 +1000 Mark Nottingham >> wrote: >>=20 >>> I have to say that I'm sympathetic to the proposed outcomes, >>> albeit for different reasons, perhaps. >>>=20 >>> We have two communities using a shared artefact (URIs) with >>> vastly differing use cases and viewpoints about them. Managing >>> this situation has already proven extremely difficult for the >>> IETF, and it seems to me to be very pragmatic to cease forcing >>> them to co-exist, constantly bickering about angels dancing on >>> pins. >>=20 >> Mark, >>=20 >> The above is actually a slightly different version of what drove >> me to propose the "separate URNs" change in the new draft. As >> you say, we have two different communities with different >> assumptions, exemplars, and perceived needs. The one thing they >> have in common is that neither accepts and interprets the >> examples of the other in the same way. >=20 > I think the disagreement is over what counts as an example. >=20 > Back in the early days of URNs I remember a lot of people telling me > that naming 'was hard' but could not explain why and that 'only a few > people understand it' but not who. >=20 > After a while I got rather tired of that mode of argument and decided > that I won't accept any argument that is not stated within the four > corners of the message or cited directly. >=20 >=20 >> Indeed, each community >> tends to reject the legitimacy of the position and arguments of >> the other and often to be dismissive and as far as I can tell, >> largely stops listening. More on that below, but let me suggest >> there are two separate discussions that we can have now: >=20 > Well either a URN is a distinct class from a URL or it isn't. >=20 > One of the things that makes me rather suspicious about the argument > is that every URL is based on a name, that is either a DNS name or an > IP address both of which are names in tat the relationship between the > signifier and the signified is purely convention. (In the case of an > IP address the addresses are resolved via BGP) >=20 > Making a distinction between URIs that are based on a naming > infrastructure that is defined by the IETF and those that are not > seems to me to be a perfectly sensible approach for the IETF to take. >=20 >=20 >> (1) Whether to continue to try to defend a Grand Unified >> "Uniform Resource Identifier" theory (and, in your words, >> "shared artifact"), with each of those words meaning whatever it >> does to the person who pronounces it, or to let the communities >> you mention go off and develop solutions to their own perceived >> problems. The predictable consequence of the first is going to >> be standards development elsewhere, rather than stopping what >> some perceive as bad behavior... we are just past "stopping" >> those communities with which some other community disagrees. >=20 > I am not sure what the above means. I can't parse it. >=20 > The IETF has limited bandwidth, the Internet has 3 billion users. So > less than 1/millionth of the Internet population is currently active > in IETF. Decisions and standards are going to get made in many places. >=20 > Whether any grand unified theory can be defended depends on the claims > made. If the claims made are extensive then the theory is likely to > collapse. If the claims are weak then it can be defended but has > little impact. >=20 >=20 >> (2) The details of what the community that the draft identifies >> as "content industries and memory organizations" need in URNs >> and how to organize that information. I will comment on that >> subthread, but only on the URN list. >=20 > This is the part that I always have problems with, the idea that the > structure or syntax of the identifier has any impact on whether it > meets requirements such as long term resolution. >=20 > The only URI that is guaranteed to resolve to the signified content > unconditionally is the DATA method. >=20 > The only URIs that are shorter than the signified data that can claim > to be permanent are indexical, in most cases based on one way > functions such as 'hashes', 'fingerprints' and 'digests'. >=20 > Its not the syntax of a naming infrastructure that gives it longevity, > it is the political and business context in which it operates. >=20 >=20 >> Sadly, some of these same arguments --including the implied "I >> am right, you don't count, and I don't need to listen" tone of a >> subset-- go back to the original URI WG and some of the reasons >> I shut it down in 1995 (and resolved, unsuccessfully, to stay >> out of this area after that). >=20 > I don't think it was one side of the argument guilty of that. >=20 > Most of my objections to various URN schemes come from the confusion > of requirements and mechanism. If someone is saying that we must > recognize a set of URIs as 'special' because of a particular set of > requirements then I want to see a demonstration that >=20 > 1) The particular set of requirements can be met >=20 > 2) The distinction insisted on helps meet them >=20 >=20 >> It has become clear in URNBIS WG >> discussions that some of those in other communities sincerely >> believe that RFC 3986 doesn't represent consensus, only an >> example of how a determined minority can outlast and then >> overwhelm others (and, from their point of view, reason and >> experience). >=20 > Yep >=20 >=20 >> I'm still convinced that the IETF's experience, perspective, and >> scope still have useful things to bring to this discussion. >> Maybe I'm naive. But it seems to me that the choice at this >> particular time isn't between how broadly URIs can reach, how >> much hair-splitting we can perform about "persistent" or >> "locator versus object identifier" but about whether we can >> separate things sufficiently to let the two (or more) >> communities go their own ways under a broad IETF umbrella or >> whether we prefer standardization work in this set of areas to >> be done elsewhere, most likely (given trends in W3C and WHATWG >> as well as in URNBIS) with most of the relevant groups agreeing >> only the 3956 is not relevant to their needs and plans. >=20 > Which is precisely why I suggest dividing the world up into 'that > which the IETF is authoritative on' and 'that which the IETF is not > authoritative on'. >=20 > --=20 > Website: http://hallambaker.com/ >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn >=20 From nobody Thu Apr 24 06:44:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238F91A0564; Thu, 24 Apr 2014 01:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.615 X-Spam-Level: ** X-Spam-Status: No, score=2.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFm9Bc59XoKo; Thu, 24 Apr 2014 01:25:44 -0700 (PDT) Received: from remote.rinascimento-digitale.it (93-63-166-139.ip28.fastwebnet.it [93.63.166.139]) by ietfa.amsl.com (Postfix) with ESMTP id 952241A03A8; Thu, 24 Apr 2014 01:25:43 -0700 (PDT) Received: from FRD01.frd.local ([fe80::30bc:ca96:e16f:8923]) by FRD01.frd.local ([fe80::30bc:ca96:e16f:8923%10]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 10:25:31 +0200 From: Maurizio Lunghi To: Phillip Hallam-Baker Thread-Topic: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPXvsdozmNQKT390aYaUTyYZpG/ZsgVovA Date: Thu, 24 Apr 2014 08:25:30 +0000 Message-ID: References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.103] x-tm-as-product-ver: SMEX-10.5.0.1057-7.500.1017-20652.005 x-tm-as-result: No--29.511200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ENNYuoz0c72o7z4H00UmQJubA2s X-Mailman-Approved-At: Thu, 24 Apr 2014 06:43:59 -0700 Cc: General discussion of application-layer protocols , "Julian F. Reschke" , Graham Klyne , Mark Nottingham , John C Klensin , "urn@ietf.org" Subject: [apps-discuss] R: [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 08:25:46 -0000 TWF5YmUgSSB3YXMgbm90IGNsZWFyLCBidXQgYSB3aXNoIGxpc3QgaXMgdG8gdGhpbmsgdGhhdCB5 b3VyIHRlY2huaWNhbCBzb2x1dGlvbnMgY2FuIGJlIGNvbnNpZGVyZWQgJ1BlcnNpc3RlbnQgSWRl bnRpZmllcnMnDQpGaXJzdCwgaW4gdGhlIGRpZ2l0YWwgcHJlc2VydmF0aW9uIGFyZW5hIHdlIGNv bnNpZGVyIHRoYXQgcG9saWN5IGFyZSBtb3JlIGltcG9ydGFudCB0aGFuIHRlY2hub2xvZ3kgYWN0 dWFsbHksIGFsbCB0aGUgZGlnaXRhbCBwcmVzZXJ2YXRpb24gYXBwbGljYXRpb25zIGhhdmUgYSBz dHJvbmcgYW5kIHdlbGwgZGVmaW5lZCBwb2xpY3kgaW4gc3VwcG9ydCBvZiB0aGVpciBnb2Fscywg dGVjaG5vbG9neSB3aWxsIGJlIG1pZ3JhdGVkIGluIHRoZSB5ZWFycy4gQXMgeW91IHNhaWQsIGFu eSB0ZWNobm9sb2d5IGNhbiBiZWNvbWUgYSBQSSBpZiBzdXBwb3J0ZWQgYnkgYW4gYXBwcm9wcmlh dGUgcG9saWN5IGFuZCBhcHBsaWNhdGlvbi4NClNlY29uZCwgaW4gb3VyIHJlY2VudCB3b3JrIHdl IGFncmVlZCBvbiB0aGF0IGEgUEkgaXMgbm90IG9ubHkgYSBudW1iZXIgb3Igc3RyaW5nLCBhIFBJ IGlzIGEgc2VydmljZSB3aGVyZSB0byB0aGF0IGNvZGUgYW4gaW5mb3JtYXRpb24gc2VydmljZSBp cyBncmFudGVkIGJ5IGEgdHJ1c3RlZCBhZ2VuY3kgd2l0aCBhIGRlZmluZWQgbWFuZGF0ZSBpbiB0 aW1lIGFuZCBmb3IgYSBzcGVjaWZpYyB1c2VyIGNvbW11bml0eSwgdGhpcyBpcyB0aGVuIGNhc2Ug Zm9yIGFsbCB0aGUgbW9zdCByZWxldmFudCBQSSBzeXN0ZW1zIGxpa2UgRE9JLCBIYW5kbGUsIEFS SywgTkJOLCBhbmQgZm9yIHRoZSBlbWVyZ2luZyBQSSBzeXN0ZW1zIGZvciBwZW9wbGUgYWxzby4g SW4gb3VyIHdvcmsgYSBQSSBzeXN0ZW0gaXMgY29tcG9zZWQgYnkgYSByZWxpYWJsZSB0ZWNobm9s b2d5LCBhIHRydXN0ZWQgYm9keSBvZmZlcmluZyB0aGUgc2VydmljZSwgYSBwb2xpY3kgYW5kIG1h bmRhdGUgYnkgdGhlIHVzZXIgY29tbXVuaXR5Lg0KVGhhdCdzIHdoeSBJIGhhdmUgdGhlIGltcHJl c3Npb24gdGhhdCB3ZSBzaG91bGQgZGVmaW5lIGNyaXRlcmlhIGZvciBhIHRydXN0ZWQgUEkgc3lz dGVtIGluIGFub3RoZXIgZG9jdW1lbnQsIGFzIHdlIGhhdmUgZG9uZSBhYm91dCB0aGUgdHJ1c3Rl ZCBkaWdpdGFsIHJlcG9zaXRvcmllcyBpc3N1ZSB3aXRoIFJMRywgT0NMQywgVFJBQywgT0FJUywg SVNPMTYzNjMgLi4uLg0KDQp0aGFua3MNCg0KTWF1cml6aW8gTHVuZ2hpDQpkaXJldHRvcmUgc2Np ZW50aWZpY28NCkZvbmRhemlvbmUgUmluYXNjaW1lbnRvIERpZ2l0YWxlDQpsdW5naGlAcmluYXNj aW1lbnRvLWRpZ2l0YWxlLml0wqAgDQorMzkzMzUxMzk2MzcxDQoNCi0tLS0tTWVzc2FnZ2lvIG9y aWdpbmFsZS0tLS0tDQpEYTogUGhpbGxpcCBIYWxsYW0tQmFrZXIgW21haWx0bzpoYWxsYW1AZ21h aWwuY29tXSANCkludmlhdG86IG1lcmNvbGVkw6wgMjMgYXByaWxlIDIwMTQgMTU6NTENCkE6IE1h dXJpemlvIEx1bmdoaQ0KQ2M6IEpvaG4gQyBLbGVuc2luOyBKdWxpYW4gRi4gUmVzY2hrZTsgTWFy ayBOb3R0aW5naGFtOyB1cm5AaWV0Zi5vcmc7IEdyYWhhbSBLbHluZTsgR2VuZXJhbCBkaXNjdXNz aW9uIG9mIGFwcGxpY2F0aW9uLWxheWVyIHByb3RvY29scw0KT2dnZXR0bzogUmU6IFt1cm5dIFth cHBzLWRpc2N1c3NdIFVSTnMgYXJlIG5vdCBVUklzIChhbm90aGVyIGxvb2sgYXQgUkZDIDM5ODYp DQoNCk9uIFdlZCwgQXByIDIzLCAyMDE0IGF0IDY6MDQgQU0sIE1hdXJpemlvIEx1bmdoaSA8THVu Z2hpQHJpbmFzY2ltZW50by1kaWdpdGFsZS5pdD4gd3JvdGU6DQo+IEkgYW0gd29uZGVyaW5nIGlm IGl0IGlzIHVzZWZ1bCBhbmQgbWF5YmUgbmVjZXNzYXJ5IHRvIGRlZmluZSB3aGF0IGEgJ3BlcnNp c3RlbnQgaWRlbnRpZmllcicgaXMgLi4uLiBhcyBtYW55IG9mIHlvdSBzYWlkIHRlY2hub2xvZ3kg aXMgbW90IHBlcnNpc3RlbnQgcGVyIHNlIGJ1dCBwb2xpY3kgdW5kZXJwaW5uaW5nIHRoZSBzeXN0 ZW0gY2FuIG1ha2UgcGVyc2lzdGVudCB0aGUgaWRlbnRpZmllcnMgYW5kIHRoZSBzZXJ2aWNlIGxp bmtlZCB0byB0aGVtIC4uLi4gaW4gdGhlIEFQQVJTRU4gcHJvamVjdCB3d3cuYXBhcnNlbi5ldSBp biBXUCAyMiB3ZSByZWFjaGVkIGFncmVlbWVudCB3aXRoIG1hbnkgZXhwZXJ0cyBhYm91dCBhIGxp c3Qgb2YgY3JpdGVyaWEgdGhhdCBhICd0cnVzdGVkIHBlcnNpc3RlbnQgaWRlbnRpZmllciBzeXN0 ZW0nIG11c3QgaGF2ZSBhbmQgd2UgY291bGQgc3RhcnQgZnJvbSB0aGlzIHdvcmsgdG8gZGVmaW5l IGEgYnJvYWRlciBjb25zZW5zdXMgLi4uLiBkb2luZyBzbyBpbiBteSB2aWV3IHdlICBjb3VsZCBj bGVhcmx5IGRpc3Rpbmd1aXNoIGJldHdlZW4gYSBVUk4gb3IgVVJJIGFuZCBhIFBJIC4uLiBkb2Vz IGl0IHNvdW5kIHJlYXNvbmFibGU/DQo+DQoNClBlb3BsZSBoYXZlIGJlZW4gY29tcGlsaW5nIHdp c2ggbGlzdHMgZm9yIHByb3BlcnRpZXMgb2YgbmFtZXMgZm9yIDIwKyB5ZWFycy4gVGhlIGlzc3Vl IGlzIG5vdCB3aGF0IHBlb3BsZSB3b3VsZCB3YW50LCBpdCBpcyB3aGF0IHRoZXkgY2FuIGdldC4N Cg0KSSBjYW4ndCB0YWtlIHRoZSAndXJuJyBhcHByb2FjaCBzZXJpb3VzbHkgdW50aWwgc29tZW9u ZSBwcm92aWRlcyBhbiBleHBsYW5hdGlvbiBvZg0KDQoxKSBIb3cgdGhlIHBlcnNpc3RlbmNlIHBy b3BlcnRpZXMgYXJlIHRvIGJlIGFjaGlldmVkDQoNCjIpIFdoeSBhIHRheG9ub21pYyBkaXN0aW5j dGlvbiBiZXR3ZWVuIFVSTHMgYW5kIFVSTnMgaGVscHMgYWNoaWV2ZSB0aGUgcGVyc2lzdGVuY2Ug cHJvcGVydGllcy4NCg0KDQpBIG5hbWUgaXMgYnkgZGVmaW5pdGlvbiBhIHNpZ25pZmllciB0aGF0 IGJlYXJzIG9ubHkgYSBjb252ZW50aW9uYWwgcmVsYXRpb25zaGlwIHRvIHRoZSB0aGluZyBzaWdu aWZpZWQuIEluIHRoZSBjYXNlIG9mIEROUyB0aGF0IHJlbGF0aW9uc2hpcCBpcyBtZWRpYXRlZCBi eSB0aGUgRE5TIGluZnJhc3RydWN0dXJlLg0KDQpUaGVyZSBhcmUgb25seSB0d28gd2F5cyB0byBt YWtlIGFuIGlkZW50aWZpZXIgcGVyc2lzdGVudC4gVGhlIGZpcnN0IGJlaW5nIHRvIHVzZSBhbiBp bmRleCByYXRoZXIgdGhhbiBhIG5hbWUuIFNIQTI1NihjKSBpcyBhIHBlcnNpc3RlbnQgaWRlbnRp ZmllciBmb3IgdGhlIGNvbnRlbnQgYy4gV2hpY2ggaXMgd2hhdCB3ZSB1c2UgaW4gdGhlIG5pOiBz Y2hlbWUuDQoNClRoZSBzZWNvbmQgaXMgdG8gaGF2ZSBhIGZpcnN0IGNvbWUsIGZpcnN0IHNlcnZl ZCByZWdpc3RyeSB0aGF0IG5ldmVyIHJldm9rZXMgcHJldmlvdXMgYXNzaWdubWVudHMuIE5vdyBv bmUgY291bGQgaW1hZ2luZSBhIHdob2xlIG5ldyBpbmZyYXN0cnVjdHVyZSBmb3IgZXN0YWJsaXNo aW5nIHN1Y2ggYSBzY2hlbWUuIEJ1dCByZWFsbHksIHdvdWxkbid0IGFueW9uZSBzZXR0aW5nIHVw IHN1Y2ggYSBzY2hlbWUgYXBwbHkgZm9yIGEgVExEPw0KDQpTbyBub3cgaW1hZ2luZSB3ZSBoYXZl IC5waWQgd2hpY2ggaXMgYSBmaXJzdCBjb21lLCBmaXJzdCBzZXJ2ZWQgcmVnaXN0cnkgdGhhdCBu ZXZlciByZXZva2VzIGFuIGFzc2lnbm1lbnQgb3IgYWx0ZXJuYXRpdmVseSByZXF1aXJlcyB0aGUg ZGF0ZSB0byBiZSBpbnNlcnRlZCBpbnRvIHRoZSBIVFRQIFVSSXMuDQoNCkkgY2FuIGdpdmUgeW91 IGEgSFRUUCBtZXRob2QgaWRlbnRpZmllciB3aGljaCBpcyBwZXJzaXN0ZW50IHVzaW5nIHN1Y2gg YW4gaW5mcmFzdHJ1Y3R1cmUuDQoNCk5vdyB3ZSBjYW4gYXJndWUgb3ZlciB3aGV0aGVyIHRoZSBw cm9wb3NhbCBJIG1ha2UgaXMgYWN0dWFsbHkgcHJhY3RpY2FsLiBCdXQgSSB0aGluayBpdCBpcyBh dCBsZWFzdCBhcyBwcmFjdGljYWwgYXMgYWxsIHRoZSAncGVyc2lzdGVudCBpZGVudGlmaWVyJyBz Y2hlbWVzIGJhc2VkIG9uIGEgbmV3IHJlZ2lzdHJ5Lg0KDQoNClRoZSBib3R0b20gbGluZSBpcyB0 aGF0IHBlcnNpc3RlbmNlIGlzIGEgcXVhbGlmaWVkIHByb3BlcnR5IG9mIGEgbmFtaW5nIGluZnJh c3RydWN0dXJlLCBub3QgYSBzeW50YWN0aWMgZGlzdGluY3Rpb24uDQoNCklmIHBlb3BsZSB3YW50 IHRvIGFyZ3VlIGZ1cnRoZXIsIEkgd2FudCB0aGVtIHRvIHB1dCB1cCBhbmQgc2hvdyBIT1cgdGhl aXIgcGVyc2lzdGVuY2Ugc2NoZW1lIGFjdHVhbGx5IHdvcmtzLiBObyBtb3JlIHdpc2ggbGlzdHMg b3IgcmVxdWlyZW1lbnRzIGZvciBpZGVudGlmaWVycy4gSSB3YW50IHRvIHNlZSBob3cgdGhlIHNj aGVtZSB3b3JrcyBhdCBhIHRlY2huaWNhbCBhbmQgcG9saXRpY2FsIGxldmVsIHRvIGFjaGlldmUg dGhlIHBlcnNpc3RlbmNlIHJlcXVpcmVtZW50cy4NCg0KDQoNCi0tDQpXZWJzaXRlOiBodHRwOi8v aGFsbGFtYmFrZXIuY29tLw0KDQo= From nobody Thu Apr 24 10:59:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0051A0222 for ; Thu, 24 Apr 2014 10:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.856 X-Spam-Level: X-Spam-Status: No, score=0.856 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-6qQOYDuwfj for ; Thu, 24 Apr 2014 10:59:15 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DFEBF1A01DB for ; Thu, 24 Apr 2014 10:59:14 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id BA9732007F104 for ; Thu, 24 Apr 2014 10:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=MYoI6wlJFFiKIFNYVqNfdUPe2Cw=; b=SoBoSgtvdIk 3LQKU+PUdfRyZhiZknyT7qw3VlpynfPX0nJ/lia2HM07NTqpieohdPgXMhZJCTlt Mayosalr4fesnLjzuhe5RC1mRdopA6Sk2ygWVAHU61qznBSss0tCRfWqbuztYog4 N40ldMhbhqTRGdUAGxR/tna3baTET4vo= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 704612007F102 for ; Thu, 24 Apr 2014 10:59:08 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so1498959wiv.13 for ; Thu, 24 Apr 2014 10:59:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.105.132 with SMTP id gm4mr37280wib.39.1398362347026; Thu, 24 Apr 2014 10:59:07 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 24 Apr 2014 10:59:06 -0700 (PDT) Date: Thu, 24 Apr 2014 12:59:06 -0500 Message-ID: From: Nico Williams To: Apps Discuss Content-Type: multipart/alternative; boundary=f46d044280eaf6407904f7cd9a9b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mUdqzo2_7Y5ZbZxx0CH52Sok1h4 Subject: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:59:16 -0000 --f46d044280eaf6407904f7cd9a9b Content-Type: text/plain; charset=UTF-8 Suppose you have an append-only, variable-size entry log file, but a new one could be renamed into place. Clearly the logfile's strong ETag would have to change with each entry appended to it, but then how's the client to know if a GET of a range of it will return new entries from the same log file as before or possibly garbage from a new one -- garbage because the requested range is meaningless given the change in the log file's identity. Ideally there would be something like ETag that corresponds to resource identity (st_dev+st_ino in POSIX terms) but doesn't change when the resource's size changes. If multiple ETags can sensibly be sent for one resource then sending a weak etag and a strong etag in should suffice. Is that permitted? If so a tail -f client could periodically attempt to GET additions using ranges and If-Match the weak etag. Now, reading RFC2616 sections 14.24 and 13.3.3 makes me sad: 13.3.3 says that clients can't use weak validators with range requests, and 14.24 says that If-Match must use strong validators. This seems to preclude sensible tail -f behavior over HTTP! What am I missing? I can't be the first to want this, but I'm not finding categorical answers to how to tail -f over HTTP... Of course, getting servers to sensibly generate appropriate etags is not trivial, and less so when using clustered services or third party server farms. And a tail -f client would have to be pretty smart, not just a dumb GETter. It might be easier to synthesize per-update URIs and a "latest" resource, at the price of doing two requests to fetch updates. Indeed, that's that I'll be doing for the application I need this for since, thankfully, it is easy in this one case to identify complete "transactions". But this approach doesn't generalize. IF there was a standard way to tail -f over HTTP then servers might well support sensible (clusterable) weak/strong etag computations for resources known to be log-like. Nico -- --f46d044280eaf6407904f7cd9a9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Suppose you have an append-only, variable-size entry=C2=A0log file, but a n= ew one could be renamed into place. =C2=A0Clearly the logfile's strong= =C2=A0ETag would have to change with each entry appended to it, but then ho= w's the client to know if a GET of a range of it will return new entrie= s from the same log file as before or possibly garbage from a new one --=C2= =A0garbage because the requested range is meaningless given the change in t= he log file's identity.

Ideally there would be something like ETag that co= rresponds to resource identity (st_dev+st_ino in POSIX terms) but doesn'= ;t change when the resource's size changes. =C2=A0If multiple ETags can= sensibly be sent for one resource then sending a weak etag and a strong et= ag in=C2=A0should suffice.=C2=A0Is that permitted?=C2=A0=C2=A0If so a tail = -f=C2=A0client could periodically attempt to GET additions using ranges and= If-Match the weak etag.=C2=A0

Now, reading RFC2616 sections 14.24 and 13.3.3 ma= kes me sad: 13.3.3 says that clients can't use weak validators with ran= ge requests, and 14.24 says that If-Match must use strong validators. =C2= =A0This seems to preclude sensible tail -f behavior over HTTP!

What am I missing? =C2=A0I can't be the first to wa= nt this, but I'm not finding categorical answers to how to tail -f over= HTTP...

Of course, getting servers to sensibly ge= nerate appropriate etags is not trivial, and less so when using clustered s= ervices or third party server farms. =C2=A0And a tail -f client would have = to be pretty smart, not just a dumb GETter. =C2=A0It might be easier to syn= thesize per-update URIs and a "latest" resource, at the price of = doing two requests to fetch updates. =C2=A0Indeed, that's that I'll= be doing for the application I need this for since, thankfully, it is easy= in this one case to identify complete "transactions". =C2=A0But = this approach doesn't generalize.

IF there was a standard way to tail -f over HTTP then s= ervers might well support sensible (clusterable)=C2=A0weak/strong etag comp= utations for resources known to be log-like.

Nico<= /div>
--=C2=A0


--f46d044280eaf6407904f7cd9a9b-- From nobody Thu Apr 24 11:10:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3401A03C7 for ; Thu, 24 Apr 2014 11:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwE2DZMqorvc for ; Thu, 24 Apr 2014 11:10:13 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B9F251A03C0 for ; Thu, 24 Apr 2014 11:09:58 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so1533987wiv.0 for ; Thu, 24 Apr 2014 11:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lGOjydOcS26TD8eBRLLD0ttuUf6oW+4NyhNquSYWoss=; b=x87vh1XynOwvyMgx1Vj7YI9YDIY9uRjNxTH/xYc/HQa9kSV2BRY082AmCQTkOwazmh 2CQTndBa1ht9hUJKc+ilxpu+MQLcpbB2dL2qnHSZtjRhlrVCpDuhitdjV2ja9A9qH6Ut DqzgZel3rdlv/zRFA0DsS/NGdzAg10ETQ9Egq9gtPbebTH3oOC3YdKQ++UoKW5IU8bUA Qj9nA2anZCR6ke6NkAro1Kz9GK1AXXdM8OIbw381yG8TfuMrUb6yz4i3ptV325lLiqsa Ln/j8KbOhBbee3gDKgQrywk7NtbqORZZvmy5EdjSBYYAvEAj30RV8DePd2ed6usfFMpo U3+Q== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr141966wic.58.1398362992210; Thu, 24 Apr 2014 11:09:52 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 24 Apr 2014 11:09:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 11:09:52 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/STpeihQpQGBSnwk9T2DWkr4R_Eg Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:10:14 -0000 On 24 April 2014 10:59, Nico Williams wrote: > What am I missing? I can't be the first to want this, but I'm not finding > categorical answers to how to tail -f over HTTP... Have you considered the possibility that different log entries could be their own resources? Or is that too hard? It means application logic rather than range requests to pull and compose entries, but that's not unusual. You could use Link: rel=prev or rel=next with either ranges or entries to help with crawling the log. The case of copying a new file over seems like it wants a layer of indirection. If you don't like 3xx, Content-Location might work. Just spitballin': GET /full-log 200 OK Link: ;rel=next Content-Location: /2014-05-01/1..12 {12 records} GET /2014-05-01/13.. 200 OK Link: ;rel=prev Link: <2014-05-01/16..>;rel=next Content-Location: /2014-05-01/13..15 {3 records} From nobody Thu Apr 24 11:18:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4FF1A0321 for ; Thu, 24 Apr 2014 11:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCMfrkkNMreX for ; Thu, 24 Apr 2014 11:17:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id CB5A71A0222 for ; Thu, 24 Apr 2014 11:17:56 -0700 (PDT) Received: from [192.168.1.10] ([95.253.111.104]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Ld3t6-1XLYjs3Vse-00iGQm for ; Thu, 24 Apr 2014 20:17:49 +0200 Message-ID: <5359554A.9000008@gmx.de> Date: Thu, 24 Apr 2014 20:17:46 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8u7O0BrENw4oBDwLLziwvARmLt7l+0wxM//vC/4j7wvXD8Iz5eU TR7cL2eGIQD1GBoT9S1ByElvcuPNhSmh56p04jC9yNwmYiGjSFgdTIbp0EhcLWlaZOvrYHX PTHuDH7thgX9eWY2wEAYCEzdauDGi+TFuAdEL0q2EOWgW6EBotXelf6oS8EH8cm1OU1MkAg 1a9xGPG0dPosYaJmyMpzw== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FNNd2mXNcOz61j1pA66rko7tnw8 Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:17:59 -0000 On 24.04.2014 19:59, Nico Williams wrote: > ... > Now, reading RFC2616 sections 14.24 and 13.3.3 makes me sad: 13.3.3 says > that clients can't use weak validators with range requests, and 14.24 > says that If-Match must use strong validators. This seems to preclude > sensible tail -f behavior over HTTP! > ... Why are you looking at RFC2616 anyway? Did you miss that the new HTTP specs have been approved in February? Best regards, Julian From nobody Thu Apr 24 11:59:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D961A03AB; Thu, 24 Apr 2014 11:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vWOd8CnIBRm; Thu, 24 Apr 2014 11:59:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) by ietfa.amsl.com (Postfix) with ESMTP id CF52E1A01DB; Thu, 24 Apr 2014 11:59:22 -0700 (PDT) Received: from BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) by BL2PR02MB402.namprd02.prod.outlook.com (10.141.93.144) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 24 Apr 2014 18:59:16 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.921.12; Thu, 24 Apr 2014 18:59:15 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0921.000; Thu, 24 Apr 2014 18:59:14 +0000 From: Larry Masinter To: Tony Finch , Phillip Hallam-Baker Thread-Topic: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPWlgDFf0xwOibhUWZI6bprNyAHZsdhqyAgAOiAzA= Date: Thu, 24 Apr 2014 18:59:14 +0000 Message-ID: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(199002)(189002)(31966008)(80976001)(76176999)(46102001)(4396001)(66066001)(86362001)(74316001)(99396002)(92566001)(76482001)(80022001)(77096999)(54356999)(74502001)(81342001)(50986999)(87936001)(83072002)(77982001)(83322001)(558084003)(81542001)(79102001)(20776003)(33646001)(74662001)(85852003)(2656002)(99286001)(224303002)(76576001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:CB217A5C.94B21466.79D14E97.D4D7ACEC.2006E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/A1898Rf0g9BmRO4jZWLI2EGBrmo Cc: "julian.reschke@gmx.de" , John C Klensin , "urn@ietf.org" , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:59:27 -0000 "data:" URLs don't have DNS names and aren't URNs. "mailto:" URLs have domain names, but not in the //.../ authority field "duri:" and "tdb:" URLs are 'permanent', but are arguably not URNs.=20 From nobody Thu Apr 24 12:01:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244C01A03C6 for ; Thu, 24 Apr 2014 12:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl-5GNKi-Mcz for ; Thu, 24 Apr 2014 12:01:41 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 717FD1A03CF for ; Thu, 24 Apr 2014 12:01:39 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 7FBB6768061 for ; Thu, 24 Apr 2014 12:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=YQrF3SwU3Q7IPOAPcu7Z IEHf8K0=; b=A0GJnj/5jf3tgYAVAiiTR29Kr2v20opgSw28Ek7gNLJYJyB0ZApU sKEt5Cg8gkWLB2QHvOwiFg7VLk5mFzkHLQWcMKekY5gVKtRIFZkD9CKnYe9uhWS+ v+xD4K9MfXKswjuaygoJIWAnbusFPTgiEV2FW6Hiv3Jv+W5KQ12UKck= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 320E1768059 for ; Thu, 24 Apr 2014 12:01:33 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so1601705wiv.6 for ; Thu, 24 Apr 2014 12:01:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.189.80 with SMTP id gg16mr108914wjc.84.1398366091883; Thu, 24 Apr 2014 12:01:31 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 24 Apr 2014 12:01:31 -0700 (PDT) In-Reply-To: <5359554A.9000008@gmx.de> References: <5359554A.9000008@gmx.de> Date: Thu, 24 Apr 2014 14:01:31 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7bb03f9c2c3b8504f7ce7a86 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nuJ5lo1WpMcu6MsL2LmLM2EFR7Y Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:01:42 -0000 --047d7bb03f9c2c3b8504f7ce7a86 Content-Type: text/plain; charset=UTF-8 On Thursday, April 24, 2014, Julian Reschke wrote: > On 24.04.2014 19:59, Nico Williams wrote: > > ... > >> Now, reading RFC2616 sections 14.24 and 13.3.3 makes me sad: 13.3.3 says >> that clients can't use weak validators with range requests, and 14.24 >> says that If-Match must use strong validators. This seems to preclude >> sensible tail -f behavior over HTTP! >> ... >> > > Why are you looking at RFC2616 anyway? Did you miss that the new HTTP > specs have been approved in February? > OK, I have those in front of me. It's still not obvious. Can you tell me what the answer is? Nico -- --047d7bb03f9c2c3b8504f7ce7a86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, April 24, 2014, Julian Reschke <julian.reschke@gmx.de> wrote:
On 24.04.2014 19:59, Nico Williams wrote:
> ...
Now, reading RFC2616 sections 14.24 and 13.3.3 makes me sad: 13.3.3 says that clients can't use weak validators with range requests, and 14.24 says that If-Match must use strong validators. =C2=A0This seems to preclude=
sensible tail -f behavior over HTTP!
...

Why are you looking at RFC2616 anyway? Did you miss that the new HTTP specs= have been approved in February?

OK, I have those in front of me. =C2=A0It's still= not obvious. =C2=A0Can you tell me what the answer is?

Nico
--=C2=A0
--047d7bb03f9c2c3b8504f7ce7a86-- From nobody Thu Apr 24 12:42:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304F01A037A for ; Thu, 24 Apr 2014 12:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQehfLVB4mwk for ; Thu, 24 Apr 2014 12:42:52 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D7A581A0321 for ; Thu, 24 Apr 2014 12:42:52 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id B5484202046 for ; Thu, 24 Apr 2014 12:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=wHz2zCY7lU0UOKUTvn8L qNIo6iw=; b=SCZypSQWjz3XxLKXvXFzDy49xHRspAQCNAEcn0ThyJ9g4EmmjGdm LmcarmakEjo7a2TRpAulGws0sp1wIKTVIfR6GmWEzzkbJLBUAdR3yMUWMpqUoedQ dNgjdlJuoitjIEAhFlOxEZMPwMvLGEnrBqJvVaUmQ3mlTWrUYKxfjh0= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 5A948202038 for ; Thu, 24 Apr 2014 12:42:46 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so1649430wiv.3 for ; Thu, 24 Apr 2014 12:42:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr462692wib.42.1398368565032; Thu, 24 Apr 2014 12:42:45 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 24 Apr 2014 12:42:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 14:42:44 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b66f9cb957fcc04f7cf0d0c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SmNM1RcbZLzGsXbfZj3Zqcfouvs Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:42:54 -0000 --047d7b66f9cb957fcc04f7cf0d0c Content-Type: text/plain; charset=UTF-8 On Thursday, April 24, 2014, Martin Thomson wrote: > On 24 April 2014 10:59, Nico Williams > > wrote: > > What am I missing? I can't be the first to want this, but I'm not > finding > > categorical answers to how to tail -f over HTTP... > > Have you considered the possibility that different log entries could > be their own resources? Or is that too hard? It means application > logic rather than range requests to pull and compose entries, but > that's not unusual. You could use Link: rel=prev or rel=next with > either ranges or entries to help with crawling the log. Fortunately in my very specific case I can change the app to generate log file increments, each as its own file/resource, chaining back with links embedded in the resource. So yes, that's my solution for now. But that's a lot of work for a generic server to with plain old log files in a generic way! In fact, it can't be done in a generic way. Yet in a sense a log file is a static resource -- it should be trivial and fast to serve it and incremental additions to it. Is that possible? How?? I don't see it. I can't be the first person to need such a thing, but I can't find how to do it. The Unix tail(1) -f is trivial, it reads to EOF, then polls for size changes and reads new data when it shows up. An HTTP equivalent ought to work, but since this is akin to building a filesystem we need something akin to st_dev/st_ino to detect whether the likely-to-be-modified resource is still the same resource in the sense of being the same file rather than having the same contents (which is what strong ETAgs provide). The obvious thing to use is weak ETags, but as I noted, that's forbidden (I haven't yet parsed enough of the new HTTP/1.1 specs to know if that's fixed, but since server support is what matters...). The case of copying a new file over seems like it wants a layer of > indirection. If you don't like 3xx, Content-Location might work Yes, that's what. i"m doing -- but only because it happens to be feasible in this case. But I want to know how to do this in a general and -naturally- high-performance manner. I'm asking a question about the standards, not my particular situation. Nico -- --047d7b66f9cb957fcc04f7cf0d0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, April 24, 2014, Martin Thomson <martin.thomson@gmail.com> wrote:
On 24 April 2014 10:59, Nico Williams <nico@crypto= nector.com> wrote:
> What am I missing? =C2=A0I can't be the first to want this, but I&= #39;m not finding
> categorical answers to how to tail -f over HTTP...

Have you considered the possibility that different log entries could
be their own resources? =C2=A0Or is that too hard? =C2=A0It means applicati= on
logic rather than range requests to pull and compose entries, but
that's not unusual. =C2=A0You could use Link: rel=3Dprev or rel=3Dnext = with
either ranges or entries to help with crawling the log.
Fortunately in my very specific case I can change the app to g= enerate log file increments, each as its own file/resource, chaining back w= ith links embedded in the resource. =C2=A0So yes, that's my solution fo= r now.

But that's a lot of work for a generic server to wi= th plain old log files in a generic way! =C2=A0In fact, it can't be don= e in a generic way. =C2=A0Yet in a sense a log file is a static resource --= it should be trivial and fast to serve it and incremental additions to it.= =C2=A0Is that possible? =C2=A0How??=C2=A0 I don't see it.=C2=A0 I can&= #39;t be the first person to need such a thing, but I can't find how to= do it.

The Unix tail(1) -f is trivial, it reads to EOF, = then polls for size changes and reads new data when it shows up. =C2=A0An H= TTP equivalent ought to work, but since this is akin to building a filesyst= em we need something akin to st_dev/st_ino to detect whether the likely-to-= be-modified resource is still the same resource in the sense of being the s= ame file rather than having the same contents (which is what strong ETAgs p= rovide). =C2=A0The obvious thing to use is weak ETags, but as I noted, that= 's forbidden (I haven't yet parsed enough of the new HTTP/1.1 specs= to know if that's fixed, but since=C2=A0server support is what=C2=A0ma= tters...).

The case of copying a new file over seems like it wants a layer of
indirection. =C2=A0If you don't like 3xx, Content-Location might work

Yes, that's what. i"m doing -- but = only because it happens to be feasible in this case.

But I want to know how to do this in a general and -naturally- high-perform= ance manner. =C2=A0I'm asking a question about the standards, not my pa= rticular situation.

Nico
--=C2=A0

--047d7b66f9cb957fcc04f7cf0d0c-- From nobody Thu Apr 24 13:05:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07211A03DF for ; Thu, 24 Apr 2014 13:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x13VFgz8xES0 for ; Thu, 24 Apr 2014 13:05:52 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AE31E1A03D9 for ; Thu, 24 Apr 2014 13:05:51 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so1688797wib.5 for ; Thu, 24 Apr 2014 13:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mIctXhJ+x7xH2zNaI1wG/9iMKFvzKnXtIEb78E61Sdc=; b=xvBOluVPB7wSpsgxa2ndPMtLZI7tWJu5X4yRIlRjbgadOFcXhVYRSWJCSOurkE7J3C V8DA2iufj5rYGNpUBUM62j3hqs1g//V4OkZhgNsA6N5IsBaCkux7a8tOvAeBqtRBDovt wNQ2EI6mxkhh8AztZWNB4JUpVozAd7cBqCqz6mFh0siLelklQKdmyzM69cMN2F7nUHUK l/xLhW9jA6owMbP04jWwZEYioX6jb7TTRpnEY+v6aGs0dSPqiD4g6HiyjfAMYVqm0L2g CeoxrKE1Dgtc9NpXLGSdR97ttWnbfXhGfR2mchdx2CZcJ/gFY7Tx4bw/krTyj5KiWoRx ZgYg== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr503085wic.58.1398369945085; Thu, 24 Apr 2014 13:05:45 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 24 Apr 2014 13:05:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 13:05:45 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q0HRLOj15YOAnJNFWhleCFS08FA Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:05:55 -0000 On 24 April 2014 12:42, Nico Williams wrote: > The Unix tail(1) -f is trivial, it reads to EOF, then polls for size changes > and reads new data when it shows up. An HTTP equivalent ought to work tail(1) fails to notice changes to the file behind its read horizon, right? An HTTP version should work, if you only care for the same sort of loose guarantee. Just don't use If-Range and make a blind range request. I think that Content-Location (or redirects) is the best way to address the issue of swap-out. From nobody Thu Apr 24 13:18:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533FD1A03AA for ; Thu, 24 Apr 2014 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.856 X-Spam-Level: X-Spam-Status: No, score=0.856 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubGxsB-YozGY for ; Thu, 24 Apr 2014 13:18:29 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8BD1A0389 for ; Thu, 24 Apr 2014 13:18:29 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 6B54B2007AD16 for ; Thu, 24 Apr 2014 13:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=5jPOqa5vqOABX/XyoxNxotT JF9c=; b=goeBp3KqdWLnmSrp1YHJpQrAyDpgz2eHEDRFvUe9oiCapVqfIqwqwCV M7CdFTauKFqAq0pN6Lu4wSKUFS4j76Cy1gHvvsYwbuKJunNQFzQyzgRqx9GrcXIo E2Ml1I4vX+sBkrNp+UwBWK2TjttEgDiozL6pqeAooSeRFOlKu+Co= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 20C942007AD15 for ; Thu, 24 Apr 2014 13:18:22 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id k48so2774613wev.11 for ; Thu, 24 Apr 2014 13:18:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr531404wic.5.1398370701844; Thu, 24 Apr 2014 13:18:21 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 24 Apr 2014 13:18:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 15:18:21 -0500 Message-ID: From: Nico Williams To: Apps Discuss Content-Type: multipart/alternative; boundary=001a11c26ab4f2aa0d04f7cf8cc1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6uzNlhxKd8UCa_uZzxvMKAiEa4o Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:18:30 -0000 --001a11c26ab4f2aa0d04f7cf8cc1 Content-Type: text/plain; charset=UTF-8 Hmm, i think I found a way: use GET requests with If-Modified-Since and Range (starting at the last content-length, the old EOF) but NOT If-None-Match, then check the ETag in the response if successful, if the ETag does not match the one the client knew from earlier, then the range was invalid and the client must abort or fetch the new resource whole. This works with weak etags only, of course. If a resource had two etags (is that possible?? that's not clear) use whichever one was weak. If the resource has no weak etags then it is not meant to be used in a tail -f way. For POSIX systems the weak etag should be constructed from the log file's st_dev and st_ino. The only problem with this is that the client might sometimes wastefully read a range of a new file, but that's exceedingly unlikely. Not every server I've checked can build such weak etags, but that's alright. Note: I still don't know if a resource may have more than one etag. Nico -- --001a11c26ab4f2aa0d04f7cf8cc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmm, =C2=A0i think I found a way: use GET requests with=C2=A0If-Modified-Si= nce and Range (starting at the last content-length, the old EOF)=C2=A0but N= OT If-None-Match, then check the ETag in the response=C2=A0if successful, i= f the ETag does not match the one the client knew from earlier, then the ra= nge was invalid and the client must abort or fetch the new resource whole.<= br>

This works with weak etags only, of course. =C2=A0If a = resource had two etags (is that possible?? that's not clear) use whiche= ver one was weak. =C2=A0 If the resource has no weak etags then it is not m= eant to be used in a tail -f way. =C2=A0For POSIX systems the weak etag sho= uld be constructed from the log file's st_dev and st_ino.

The only problem with this is that the client might som= etimes wastefully=C2=A0read a range of a new file, but that's exceeding= ly unlikely.

Not every server I've checked can buil= d such weak etags, but that's alright.

Note: I still don't know if a resource may have more tha= n one etag.

Nico
--=C2=A0
--001a11c26ab4f2aa0d04f7cf8cc1-- From nobody Thu Apr 24 14:36:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEEE1A03F2 for ; Thu, 24 Apr 2014 14:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca0lWYLczgOg for ; Thu, 24 Apr 2014 14:36:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6251A03EF for ; Thu, 24 Apr 2014 14:36:17 -0700 (PDT) Received: from [192.168.1.10] ([95.253.111.104]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MPYqL-1WYmU51JaL-004j0i; Thu, 24 Apr 2014 23:36:08 +0200 Message-ID: <535983C4.6060800@gmx.de> Date: Thu, 24 Apr 2014 23:36:04 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nico Williams References: <5359554A.9000008@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NvdptNMYGrWVckDwe9nQEQpve/Qufq78j6SRnl7sC2SDnjLpmzL PjYd6E6TbyYy06eOcxA2Hq2j2yTfSrHNTW/CBauW7KPg2c1dUmgvhJAaCu6D0XzKKRUuHak UFZmuszd9aLWk8k0X9FEv249otz6VIqGSmO4lH1I6kSE9dumHGHtUo6N/6KNV3uf5AQ9rMt 58aIP3BZDZH0xymOgmFtQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/t_cVWG8daSnurDYHbKRb-nw7ojc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 21:36:19 -0000 On 24.04.2014 21:01, Nico Williams wrote: > On Thursday, April 24, 2014, Julian Reschke > wrote: > > On 24.04.2014 19:59, Nico Williams wrote: > > ... > > Now, reading RFC2616 sections 14.24 and 13.3.3 makes me sad: > 13.3.3 says > that clients can't use weak validators with range requests, and > 14.24 > says that If-Match must use strong validators. This seems to > preclude > sensible tail -f behavior over HTTP! > ... > > > Why are you looking at RFC2616 anyway? Did you miss that the new > HTTP specs have been approved in February? > > > OK, I have those in front of me. It's still not obvious. Can you tell > me what the answer is? No, I just wanted to make sure you are looking at the latest and greatest... From nobody Fri Apr 25 01:45:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91371A00DA; Fri, 25 Apr 2014 01:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZdVEjh-wGVs; Fri, 25 Apr 2014 01:45:18 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE1B1A00D1; Fri, 25 Apr 2014 01:45:18 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 134A37B866; Fri, 25 Apr 2014 04:45:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= 7gV7s6AQ7M6N390VljvMywD8ub0=; b=j9fYJmPEnQCRJOhqZCN0rXi9/PnRLTVt 0NRxXZBh4vqT+6d2CHuUHj/dsOMsgfil/rUNuc9KUWFHjwsChta5iQm7pt+t68lJ Ej+LQCsvFvI4rnUTujMEJOD7qlPBWHmXEjO81VzfqR1/SRaUHYhF+HM254lnTBZd qpvFRcDPEfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=jZhZxQwx/udwKi65NO33bhEIsstK0AYDfAu74vVZGCUN9WCOaY5UhLra P/jtP9fNPfG6MAgWENxTD+x2e7k6GWEO9GrREZ/0EpphUwTU6dOeYHJ7WfIJlIhr ulJVWq3v0FUJqDUiV1Qar05Vqc2iKAQ68hKRaEMT/HpXyueEbZM= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id ED8F87B864; Fri, 25 Apr 2014 04:45:10 -0400 (EDT) Received: from [128.164.100.42] (unknown [128.164.100.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9D15C7B860; Fri, 25 Apr 2014 04:45:07 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Edward Summers In-Reply-To: <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> Date: Fri, 25 Apr 2014 04:45:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1874) X-Pobox-Relay-ID: E7C6B8F0-CC55-11E3-8788-0731802839F8-07615111!b-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/N4tMf6L-qgpauhidcGqI45w5YLY Cc: John C Klensin , "Julian F. Reschke" , urn@ietf.org, Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 08:45:20 -0000 On Apr 17, 2014, at 9:44 PM, Mark Nottingham wrote: > I have to say that I'm sympathetic to the proposed outcomes, albeit = for different reasons, perhaps. >=20 > We have two communities using a shared artefact (URIs) with vastly = differing use cases and viewpoints about them. Managing this situation = has already proven extremely difficult for the IETF, and it seems to me = to be very pragmatic to cease forcing them to co-exist, constantly = bickering about angels dancing on pins.=20 >=20 > While people don't want to consider it in-scope for this discussion, I = also think that doing so will make the situation with WHATWG and W3C = more manageable. I agree that, as distasteful as it might seem, it=92s quite important to = discuss the organizational (and personal) politics involved, to the best = of our ability, in a respectful and constructive way. Pushing them off = the table is just a way of making them an implicit part of any work that = we do, which can result in difficulty in interpreting decisions later = on...which can be expressed as angels dancing on pins. If possible I = would like to hear how the proposed changes could help make the = WHATWG/W3C situation more manageable. The proposed changes to URN seem largely centered on the needs of memory = organizations, who are a third community at play here. I am worried that = the current draft makes this community seem monolithic in its approach = to persistent identifiers and URIs. The current definition of URN as URI = has not prevented useful work on persistent identifiers] by memory = institutions, notably ARK [1], Memento [2], OpenURL [3], info-uri [4], = ISBN [5] and Version Navigation [6] and Dublin Core [7]. I see Larry=92s = work on things like duri as other examples of useful work that can be = done without changing the relationship of URN to URI. I have personally found the work that has gone into Web architecture, in = particular Fielding=92s work on REST, has been extremely useful in = designing digital preservation systems at the Library of Congress. = Taking the Web seriously has lots of real benefits when it comes to = application development and sustainability since there is a great = diversity in software implementations and maturity with regards to = scalability. I=92m not saying there aren=92t challenges, but if memory = institutions want to continue in their societal role, they must learn to = work with the grain of the Web, not against it. I=92m thinking of the = excellent work that organizations like the Internet Archive have = started. So, as it stands, I think the current draft [8] is too simplistic in its = approach, and actually does a fair bit of damage to people in the field. = If you would prefer to have specific comments I can try to do that but I = am having trouble decoding the politics at play here. //Ed [1] http://tools.ietf.org/id/draft-kunze-ark [2] https://www.ietf.org/rfc/rfc7089.txt [3] https://en.wikipedia.org/wiki/OpenURL [4] https://www.ietf.org/rfc/rfc4452.txt [5] https://www.ietf.org/rfc/rfc3187.txt [6] https://www.ietf.org/rfc/rfc5829.txt [7] http://dublincore.org/documents/dces/ [8] https://tools.ietf.org/id/draft-ietf-urnbis-urns-are-not-uris= From nobody Fri Apr 25 17:59:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE91A06DC for ; Fri, 25 Apr 2014 17:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnIdRQbv46IP for ; Fri, 25 Apr 2014 17:59:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6A41A044C for ; Fri, 25 Apr 2014 17:59:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.149.113]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3Q0wvM2019721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Apr 2014 17:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398473949; bh=yw+R1LWeDNjwwCT4GjtGFwMlIAQ/XbGFdqkZ1HMNADA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZaDzNR+VCz3FZ3Lkd2epLlv0WG3TX+MRgoJ3j+HG79mjqnS2reA79s4ZcVU2mT/VX G20TFYHx/mNVEFAoYoF4ts4EVkNab1gSMyKUg3nIF2xl69B1iDdzcrp2JYDLlXfQTR kjihGpEsSzV5vuw6DUGl83P1bQP64DgMK7UX0DWo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398473949; i=@elandsys.com; bh=yw+R1LWeDNjwwCT4GjtGFwMlIAQ/XbGFdqkZ1HMNADA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=M1H2I7d3CH8pjycJfW4rpRYgjBni6v1DvWI4Qd5to6sC64rDvOhKeKoNvAhU8JiPR k4031K5Hxz+/mpy3SaXZJ4HKTB1pMxntgEg1nqagMIIkRKLXpjYxLK4VMcDAeNowth zU32KrzW6tJ1QpP02Cad/uC8OeDDRuMTXkyJc7D8= Message-Id: <6.2.5.6.2.20140425165229.08296308@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 25 Apr 2014 17:15:39 -0700 To: Mark Nottingham From: S Moonesamy In-Reply-To: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> References: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/j7vXayjg8XyAckdoURoxVzhvnqo Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 00:59:19 -0000 Hi Mark, At 05:44 23-04-2014, The IESG wrote: >The IESG has received a request from the Applications Area Working Group >WG (appsawg) to consider the following document: >- 'URI Design and Ownership' > as Best Current >Practice > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2014-05-07. Exceptionally, comments may be In Section 2: "This section updates [RFC3986] by setting limitations on how other specifications may define structure and semantics within URIs." I gather that this means that the updates apply to Sections 3.2, 3.3 and 3.4 of RFC 3986. I could not tell whether 3.1 of RFC 3985 is also included in the update. In Section 2.1: "However, applications SHOULD NOT preclude the use of other URI schemes in the future, unless they are clearly specific to the nominated schemes." Could you please explain the "SHOULD NOT"? "A specification that defines substructure within a URI scheme MUST do so in the defining document for that URI scheme, or by modifying [RFC4395]." RFC 4395 is about guidelines and registration procedures. Why is there a requirement to modify that BCP when defining substructures within a URI scheme? Regards, S. Moonesamy From nobody Sat Apr 26 10:02:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51A21A0639 for ; Sat, 26 Apr 2014 10:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di1CCGzV3K9A for ; Sat, 26 Apr 2014 10:02:53 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0241A0641 for ; Sat, 26 Apr 2014 10:02:53 -0700 (PDT) Received: (qmail 20839 invoked from network); 26 Apr 2014 17:02:45 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 26 Apr 2014 17:02:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b42a.535be6b5.k1404; i=johnl@user.iecc.com; bh=wPdlxoXruWrwevGGLdg53cmbV8DK7g6wrVOYNIrbzGs=; b=k1RZcouCu5LIigqstvvi4FC7IiCpVqn1IHXa8NGYFVADi9oi+z0OQvYNZxSn+kYt/tnQoNH8iTV+vfFbCJvStXn0xC5Kd316kT0xI5Jr9Df3Axf4PygohjxQe06xi0gsxiXo+ENC2WOCWK1KOFI0SOMD+jojtgwjCr5MYe8zi1Z/jcyMLfILdTQY5CWRBS8+HhA6tvmnBBPpMILyn2P8/IBgy5jT+/f4yFQSTnq5/OqxBq0nuVQ8U2R1gyAcR/K7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b42a.535be6b5.k1404; olt=johnl@user.iecc.com; bh=wPdlxoXruWrwevGGLdg53cmbV8DK7g6wrVOYNIrbzGs=; b=A0+3dyJb2MRFmdUizYaQMUbAEFR2OfAAJetKlkeDTTplLT3P/dZIYdd/FH8KGwPLEekO2LB1mhMyfsL5pmdbdgXMEyeveMNCIAyFDb33RTED2uXfp7CE2HD5R2J5uNJWOvhjeU9/XFQmP3lL6NV1tVhrZkZdtXmKtbHF0eYBi/+LBheFMX2kV0bl/VCjFrr7rzfVKPv2JStyyYavlBS56XKQfOH/8tXLJFlKTbzEOCrIS1ySJPmv1XP0awuEpuod Date: 26 Apr 2014 17:02:23 -0000 Message-ID: <20140426170223.46121.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qDrcRMMavJxuOPqQ8h9oduYiz9A Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 17:02:55 -0000 In article you write: >I have read this draft and am generally supportive of it. Many of the >issues have been resolved. > >I do have one question. Section 2.3 constrains applications (in the >all other specifications category) from constraining paths with MUST >NOT. Section 2.4 constrains query components with applications with >SHOULD NOT. Why the difference since the harm from doing both is the >same? In my opinion, Section 2.3 should place applications at the >SHOULD NOT compliance level. I completely agree. There are all sorts of applications, with all sorts of reasons to design them in various ways. Also, although I know I've lost this argument, I want to put it on the record again: slavish adherence to this rule will lead to situations where the protocol documented in the RFC is not the one that people actually implement. In WEIRDS, where we've had lengthy arguments about it, it's quite clear that everyone will use the same URL structures. The big players already do, the small players will use the free server software that ICANN has commissioned. So in practice, if you set up a server with different URL structures, it won't work because a lot of clients will skip the template lookups and will expect that the URLs that work with everyone else will work with you. One option is to rail against how stupid the client implementers are. The other is to document what you have to do to interoperate. R's, John From nobody Sun Apr 27 09:38:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23C51A04AF for ; Sun, 27 Apr 2014 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yXMAqai4bo8 for ; Sun, 27 Apr 2014 09:38:09 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 72EA01A0312 for ; Sun, 27 Apr 2014 09:38:09 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WeS5c-00071E-pF; Sun, 27 Apr 2014 17:38:04 +0100 Received: from 94.197.120.205.threembb.co.uk ([94.197.120.205] helo=[192.168.43.120]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WeS5c-0003sH-4b; Sun, 27 Apr 2014 17:38:04 +0100 Message-ID: <535D3266.6050207@ninebynine.org> Date: Sun, 27 Apr 2014 17:37:58 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba , "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FXGPiGm2OwHIl1w-9hCOkmPpeCU Cc: Graham Klyne Subject: Re: [apps-discuss] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 16:38:12 -0000 [Re-sending; my previous attempt seems to have been blocked as I used a different email address. But I'm not currently seeing my ninebynine email, so please include all my addresses in any response.] Barry, I'm responding to this message: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg11826.html but my email is broken, so I can't do a proper threaded response. Anyways, to your message: ... Again, addressing just one point here: Graham said this: > DOIs > are conceived as names, and have the appropriate management processes > around them applicable to names. But I have observed that in recent times, > the preferred form for presenting DOIs to the Web has increasingly been in > the form "http://dx.doi.org/..."; or similar (see also: [1]). I think this > exemplifies something that MAY be used as both identifier and name. Phill said this: >> A string that *you* might *today* call a "name", might already be a >> "locator" to somebody who's rigged a private resolution service. Ten years >> from now, that "name" might be a "locator" to all of us. > > Which is exactly what I was saying. > For example, UPC code for a can of baked beans is a URN. > But if you go to Amazon you can use it as a locator, albeit mediated > via UPS rather than TCP/IP. I think both of these confuse the issue. Given a name, we can often turn it into a locator. That's clear, and that's one thing that makes names useful. But I think we still need to keep in mind that the names *aren't* locators. If I can always take "urn:doi:xyz-abc", transform it to "http://dx.doi.org/find/xyz-abc";, and get a valid locator for the thing named, that's great. But it's still the case that the former is a name and *not* a locator. And if dx.doi.org goes away at some point, the thing is still named by "urn:doi:xyz-abc", even though I can no longer use that locator. >>>GK: Sure, names are names and locators are locators (as abstractions). But URIs are *strings* that are a central (mechanical, not abstract) element of the Web - I might go so far as to say *the* central mechanical element of the Web. And in the Web, URIs can be used as either locators, names or both, depending on the context. And this malleability is central to some of the things that are done today on the Web, particularly in the area of Web linked data. >>> It's rather like using "Barry Leiba" to talk about me, and that's fine as long as it's a reference. But as soon as you need to *find* me, you have to get a locator. The locator might or might not contain my name; it could be "barryleiba at computer.org", it could be my phone number, it could be a URL for my web site, or it could be a suggestion that you look here on a Friday evening. >>>GK: Or, if I'm an NSA analyst, with access to what that implies, the string "Barry Leiba" might well be a perfectly good locator for finding information about you (and those who share your name). >>> Again, for the purposes of abstraction, let's be sure to remember the distinction, and to be clear about the scope of what we're discussing. >>>GK: The scope I am discussing is primarily the Web. I think I've been clear about that. Everything else is to some extent a result of using Web tools for non-Web purposes. In this, I agree with a point that I think Mark Nottingham is making; viz. that it may be helpful to separate Web and non-Web concerns concerning URIs. At this point, I reflect on John K's original proposal, to recognize a disjointness in the space of UR{I|L|N}s. But I think the relevant disjunct here is not name vs locator, but Web vs non-Web. It may well be that in some usage, the name/locator is relevant, and something that needs to be articulated, but as a first-order concern I don't think that's true for the Web. So I think we have a situation that URIs are just strings, with a defined, yet flexible, syntax and some very lightweight semantics to do with resolution of relative references. (As I write, I can't think of any other semantics that are imposed by the URI specification.) So I can't see any relevance to the discussion of names vs locators with respect to URIs qua URIs. But there may well be relevance to such discussion in particular contexts of URI use (such as URIs used in preservation activities). And some of those contexts may be applied within the Web. But it does not make sense to me to try to apply those concerns to everything that takes place on the Web, as there are some aspects of Web usage where the unspecified aspect of a URI as name vs locator is a feature, not a bug. Or, to put it another way, if you want to create a space of strings that is rigidly separated into strings-used-as-names and strings-used-as-locators, you are quite free to do so. You may even adopt URI syntax for your name|locator strings. But please don't try to retro-impose your distinctions onto the way that the Web uses URIs. >>> #g -- From nobody Sun Apr 27 21:08:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6040B1A02E3 for ; Sun, 27 Apr 2014 21:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQPePq2OXDyS for ; Sun, 27 Apr 2014 21:08:11 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D696C1A0703 for ; Sun, 27 Apr 2014 21:08:10 -0700 (PDT) Received: from [192.168.1.67] (unknown [118.209.107.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E5C67509B6; Mon, 28 Apr 2014 00:08:07 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: Date: Mon, 28 Apr 2014 14:08:03 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> References: To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KeoEIfx4LCgrxwAWVbww2t4Hkv0 Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 04:08:13 -0000 Range requests really weren=92t built for tailing a stream of data. Do = something in the application, e.g., using URIs, prev/next links, etc. Cheers, On 25 Apr 2014, at 3:59 am, Nico Williams wrote: > Suppose you have an append-only, variable-size entry log file, but a = new one could be renamed into place. Clearly the logfile's strong ETag = would have to change with each entry appended to it, but then how's the = client to know if a GET of a range of it will return new entries from = the same log file as before or possibly garbage from a new one -- = garbage because the requested range is meaningless given the change in = the log file's identity. >=20 > Ideally there would be something like ETag that corresponds to = resource identity (st_dev+st_ino in POSIX terms) but doesn't change when = the resource's size changes. If multiple ETags can sensibly be sent for = one resource then sending a weak etag and a strong etag in should = suffice. Is that permitted? If so a tail -f client could periodically = attempt to GET additions using ranges and If-Match the weak etag.=20 >=20 > Now, reading RFC2616 sections 14.24 and 13.3.3 makes me sad: 13.3.3 = says that clients can't use weak validators with range requests, and = 14.24 says that If-Match must use strong validators. This seems to = preclude sensible tail -f behavior over HTTP! >=20 > What am I missing? I can't be the first to want this, but I'm not = finding categorical answers to how to tail -f over HTTP... >=20 > Of course, getting servers to sensibly generate appropriate etags is = not trivial, and less so when using clustered services or third party = server farms. And a tail -f client would have to be pretty smart, not = just a dumb GETter. It might be easier to synthesize per-update URIs = and a "latest" resource, at the price of doing two requests to fetch = updates. Indeed, that's that I'll be doing for the application I need = this for since, thankfully, it is easy in this one case to identify = complete "transactions". But this approach doesn't generalize. >=20 > IF there was a standard way to tail -f over HTTP then servers might = well support sensible (clusterable) weak/strong etag computations for = resources known to be log-like. >=20 > Nico > --=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 28 00:10:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35F61A0447 for ; Mon, 28 Apr 2014 00:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3IdG1obY2hG for ; Mon, 28 Apr 2014 00:10:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 254741A0729 for ; Mon, 28 Apr 2014 00:10:19 -0700 (PDT) Received: from [192.168.1.67] (unknown [118.209.107.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B00E550A85; Mon, 28 Apr 2014 03:10:12 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20140425165229.08296308@resistor.net> Date: Mon, 28 Apr 2014 17:10:08 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <3ECAC555-4D5D-40A6-82C3-673E1B25316C@mnot.net> References: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140425165229.08296308@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0QZIrQET1RcYfFzT0N2KCXGStIA Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 07:10:22 -0000 On 26 Apr 2014, at 10:15 am, S Moonesamy wrote: > Hi Mark, > At 05:44 23-04-2014, The IESG wrote: >> The IESG has received a request from the Applications Area Working = Group >> WG (appsawg) to consider the following document: >> - 'URI Design and Ownership' >> as Best Current >> Practice >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2014-05-07. Exceptionally, comments = may be >=20 > In Section 2: >=20 > "This section updates [RFC3986] by setting limitations on how other > specifications may define structure and semantics within URIs." >=20 > I gather that this means that the updates apply to Sections 3.2, 3.3 = and 3.4 of RFC 3986. I could not tell whether 3.1 of RFC 3985 is also = included in the update. It updates 3986 in the sense that it explains appropriate use of the = structures defined therein. What practical affect does the = section-by-section applicability have? > In Section 2.1: >=20 > "However, applications SHOULD NOT preclude the use of other URI > schemes in the future, unless they are clearly specific to the > nominated schemes." >=20 > Could you please explain the "SHOULD NOT=94? I define the standard for Foo, which allows widgets to be orchestrated = by giving them URIs. I might define how to do so over HTTP using HTTP = URIs, but I shouldn=92t say =93You MUST NOT use any other URI scheme = than HTTP." > "A specification that defines substructure within a URI scheme MUST = do > so in the defining document for that URI scheme, or by modifying > [RFC4395]." >=20 > RFC 4395 is about guidelines and registration procedures. Why is = there a requirement to modify that BCP when defining substructures = within a URI scheme? Because when you define substructure in the URI scheme (a la =93foo+=94, = as currently being discussed), the registration procedure needs to know = about it. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 28 00:29:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4C01A06D5 for ; Mon, 28 Apr 2014 00:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMvzssmD2AKk for ; Mon, 28 Apr 2014 00:29:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 587F11A014C for ; Mon, 28 Apr 2014 00:29:03 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.921.12; Mon, 28 Apr 2014 07:28:56 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0921.000; Mon, 28 Apr 2014 07:28:56 +0000 From: Larry Masinter To: Mark Nottingham , S Moonesamy Thread-Topic: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice Thread-Index: AQHPXvHUf+LQl8Wn4EmtwANZezIeS5sjC2qAgAOYeACAAAKVoA== Date: Mon, 28 Apr 2014 07:28:55 +0000 Message-ID: <60bbe175d62b4e70a45ccf09dabc1c8a@BL2PR02MB307.namprd02.prod.outlook.com> References: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140425165229.08296308@resistor.net> <3ECAC555-4D5D-40A6-82C3-673E1B25316C@mnot.net> In-Reply-To: <3ECAC555-4D5D-40A6-82C3-673E1B25316C@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 01952C6E96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(51704005)(4396001)(19580395003)(77982001)(81342001)(83072002)(80976001)(2656002)(15202345003)(46102001)(101416001)(83322001)(74316001)(81542001)(50986999)(74662001)(76176999)(20776003)(74502001)(66066001)(80022001)(99396002)(99286001)(33646001)(76576001)(76482001)(87936001)(85852003)(77096999)(79102001)(15975445006)(54356999)(86362001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:ECEA51B9.8CF68FE3.40C9B25F.C4A3DEAC.20140; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GDWjkhb77BjGIFz6ua7wo9outBc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 07:29:05 -0000 =20 > > "A specification that defines substructure within a URI scheme MUST do > > so in the defining document for that URI scheme, or by modifying > > [RFC4395]." > > > > RFC 4395 is about guidelines and registration procedures. Why is there= a > requirement to modify that BCP when defining substructures within a URI > scheme? >=20 > Because when you define substructure in the URI scheme (a la "foo+", as > currently being discussed), the registration procedure needs to know abou= t it. Reference [BCP115] rather than [RFC4395]. This working group has http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-00 scheduled for Dec 2014. You can't 'modify' RFC 4395 anway. Larry -- http://larry.masinter.net From nobody Mon Apr 28 01:17:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE991A069C for ; Fri, 25 Apr 2014 13:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FRT_ADOBE2=2.455] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2N1aSEQKW5x for ; Fri, 25 Apr 2014 13:41:57 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC5B1A068E for ; Fri, 25 Apr 2014 13:41:56 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id uGUA1n0031ZXKqc57Lhp93; Fri, 25 Apr 2014 20:41:49 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id uLhf1n00A1KKtkw3hLhfMs; Fri, 25 Apr 2014 20:41:39 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3PKfdIL029940; Fri, 25 Apr 2014 16:41:39 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3PKfdVS029938; Fri, 25 Apr 2014 16:41:39 -0400 Date: Fri, 25 Apr 2014 16:41:39 -0400 Message-Id: <201404252041.s3PKfdVS029938@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Larry Masinter In-reply-to: (masinter@adobe.com) References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398458509; bh=IipIe2i5IlPo1MZvq1kYzzfhPC00OuYcZRByARXYxAA=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=BEW20ynsOrcQBQgxoUCnuWj413b9lbNQkTGdR1+olko1SX5OxoX0dIsR+/jXqUhRg 6fVCkdwAGsYoyUisVTSd2QYLKmTqzR6Yu+KEiLNGrUwL9gHRezntEakYifODmxdsku 44LGWSiotxsi/CWBfTgqcE3YRTBu3sCeMT1nBJKTlmFls3+R4QtoAno2dvpOe6neHL RXgqqRryVRqh0yHJvX91urq5VgYmMq4bY3gR+oa2HXnd0PEnIXieLOuNeWRBhbXpt0 /9brLRugZZgiZuvj1J1O3Lts+xEb5eFQ4uzV6GWpYYHlxrM1yca1bj12dRVfWfQx+h y7HCLUft3mZLQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/MXmKdvQN4j8SpSydpPGgSifBeHQ X-Mailman-Approved-At: Mon, 28 Apr 2014 01:17:28 -0700 Cc: urn@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:41:57 -0000 > From: Larry Masinter > > "data:" URLs don't have DNS names and aren't URNs. Ooooh, that's a fascinating example! One can consider a "data:" URI to be a URL, since it provides a way to locate the referenced information (i.e., parse the URI). Nonetheless, it does not contain a DNS name or any other identifier of a network resource. And yet it's also a URN, because it is a persistent identifier of the referenced information -- the association of the URI with the referenced information never changes! Dale From nobody Mon Apr 28 01:17:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0861A03B3; Fri, 25 Apr 2014 08:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBWa02Y9iIdT; Fri, 25 Apr 2014 08:28:16 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7541A05C3; Fri, 25 Apr 2014 08:28:12 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 85E7F7F396; Fri, 25 Apr 2014 17:28:04 +0200 (CEST) From: "Svensson, Lars" To: Phillip Hallam-Baker , Maurizio Lunghi Thread-Topic: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC3986) Thread-Index: Ac9gmucSIPXRPGL+TPO6HkD1WoDOXg== Date: Fri, 25 Apr 2014 15:28:03 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA43FE069@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.192] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8qj6HIFfGJoJIlbFGhducDC1PSs X-Mailman-Approved-At: Mon, 28 Apr 2014 01:17:41 -0700 Cc: "Julian F. Reschke" , Mark Nottingham , "urn@ietf.org" , Graham Klyne , General discussion of application-layer protocols Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:28:21 -0000 All, I'll enter the discussion here, commenting on Phillip's mail and add some t= houghts of mine that relate to what others have said earlier. Phillip said in answer to Maurizio:=20 > > I am wondering if it is useful and maybe necessary to define what a >> 'persistent identifier' is .... as many of you said technology is mot pe= rsistent >> per se but policy underpinning the system can make persistent the >> identifiers and the service linked to them .... in the APARSEN project >> www.aparsen.eu in WP 22 we reached agreement with many experts about >> a list of criteria that a 'trusted persistent identifier system' must ha= ve and we >> could start from this work to define a broader consensus .... doing so i= n my >> view we could clearly distinguish between a URN or URI and a PI ... doe= s it >> sound reasonable? > > >=20 > People have been compiling wish lists for properties of names for 20+ > years. The issue is not what people would want, it is what they can > get. >=20 > I can't take the 'urn' approach seriously until someone provides an > explanation of >=20 > 1) How the persistence properties are to be achieved It is clear that persistence is not a quality of the identifier syntax but = there need to be other things in place, too. What I have understood from th= e discussion is that people in different communities seem to have a differe= nt understanding of what 'persistent' in 'persistent identifier' is suppose= d to mean and IMO we need to agree on that before we can move forward. My d= efinition is that a persistent identifier is a string that uniquely identif= ies an object in such a way that there are procedures in place that guarant= ee that once a specific string has been attached to a specific resource (in= the widest sense), that string can never be used to identify any other res= ource. Period. It does not mean that there persistently (=3Dalways) will be= a resolution service in place that can resolve a persistent identifier to = a resource. Technically, I can have a persistent identifier for a resource = even if there is no resolution service available, but of course it is bette= r if there is some documentation on which identifier is tied to which resou= rce. A database with PIs and locators/metadata and a resolver on top of it = is *one* way to document that, but I could just as well print 500 copies of= a catalogue with identifier/metadata pairs and put those in 500 libraries = worldwide and let people look it up there (Kudos to Esa-Pekka Keskitalo for= this nice example). As an aside, this is why I keep arguing that urn synta= x and urn resolution belong together but still have to be considered separa= tely. I think that this is similar to what Barry said although I might be biased: [[ I think both of these confuse the issue. Given a name, we can often turn it into a locator. That's clear, and that's one thing that makes names useful. But I think we still need to keep in mind that the names *aren't* locators. If I can always take "urn:doi:xyz-abc", transform it to "http://dx.doi.org/find/xyz-abc", and get a valid locator for the thing named, that's great. But it's still the case that the former is a name and *not* a locator. And if dx.doi.org goes away at some point, the thing is still named by "urn:doi:xyz-abc", even though I can no longer use that locator. ]] RFC 2141bis states that urn assignment is a managed process. That is how th= e persistent the connection between identifier and resource is achieved. > 2) Why a taxonomic distinction between URLs and URNs helps achieve the > persistence properties. When someone loses a DNS lease (for whatever reason), there is no guarantee= that previously named resources under that DNS name will be available any = more. With urn:s (the RFC 2141 kind), the administration of a NID is delega= ted to an organisation through a managed process including public review. = This means that the responsibility and administration of e. g. urn:nbn:fi c= annot suddenly move from the National Library of Finland to e. g. the Swedi= sh Financial Supervisory Authority (Finansinspektionen (FI), http://www.fi.= se), who happens to use the abbreviation "fi" as well. >=20 > A name is by definition a signifier that bears only a conventional > relationship to the thing signified. In the case of DNS that > relationship is mediated by the DNS infrastructure. And the DNS infrastructure can and does transfer the responsibility for the= domain names between organisations. > There are only two ways to make an identifier persistent. The first > being to use an index rather than a name. SHA256(c) is a persistent > identifier for the content c. Which is what we use in the ni: scheme. >=20 > The second is to have a first come, first served registry that never > revokes previous assignments. Yes, and that is what urn NIDs are about. You register a NID and the IETF p= rocess ensures that no-one else can be assigned that NID. The resolution mi= ght be dependent on the DNS, but the naming need not be. > Now one could imagine a whole new > infrastructure for establishing such a scheme. But really, wouldn't > anyone setting up such a scheme apply for a TLD? >=20 > So now imagine we have .pid which is a first come, first served > registry that never revokes an assignment or alternatively requires > the date to be inserted into the HTTP URIs. >=20 > I can give you a HTTP method identifier which is persistent using such > an infrastructure. >=20 > Now we can argue over whether the proposal I make is actually > practical. But I think it is at least as practical as all the > 'persistent identifier' schemes based on a new registry. >=20 >=20 > The bottom line is that persistence is a qualified property of a > naming infrastructure, not a syntactic distinction. Yes, those are the so called PI Systems Maurizio talks about. =20 > If people want to argue further, I want them to put up and show HOW > their persistence scheme actually works. No more wish lists or > requirements for identifiers. I want to see how the scheme works at a > technical and political level to achieve the persistence requirements. Quoting Maurizio: [[ First, in the digital preservation arena we consider that policy are more i= mportant than technology actually, all the digital preservation application= s have a strong and well defined policy in support of their goals, technolo= gy will be migrated in the years. As you said, any technology can become a = PI if supported by an appropriate policy and application. Second, in our recent work we agreed on that a PI is not only a number or s= tring, a PI is a service where to that code an information service is grant= ed by a trusted agency with a defined mandate in time and for a specific us= er community, this is then case for all the most relevant PI systems like D= OI, Handle, ARK, NBN, and for the emerging PI systems for people also. In o= ur work a PI system is composed by a reliable technology, a trusted body of= fering the service, a policy and mandate by the user community. ]] I can only agree with that. Persistence of persistent identifiers (the way = I understand them) has nothing to do with technology but is a matter of pol= icy and of institutions fulfilling their responsibilities. The identifier a= s such is only part of a larger ecosystem (the PI System). The German DIN 3= 1646 defines a PI System as a combination of Policies, PI registration, Res= olvers and Data Sources, and this is very similar to Maurizio's definition = above. A last comment on the URN vs. URI question: I see nothing so far that preve= nts URNs (the RFC 2141 kind) to be URIs. One of the issues coming up every = now and then is the question if we should allow queries or not. I think we = can, but have to differentiate between queries in urn:s and queries targeti= ng resolution services (which is another argument why we need to keep those= two separate). Queries targeted at resolution services can be used to spec= ify if I want the identified resource, metadata about the resource or metad= ata about the identifier (who registered it, etc.). Queries in the urn are = specific to the identified resource. As an example: if I have urn:example:g= oogle-query and that resolves to https://www.google.com/search?, then urn:e= xample:google-query?q=3Drfc%202141 would resolve to https://www.google.com/= search?q=3Drfc%202141. So there is a difference in functionality. Best, Lars From nobody Mon Apr 28 01:38:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180B91A08D8 for ; Mon, 28 Apr 2014 01:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R6Bu1n6KYqc for ; Mon, 28 Apr 2014 01:38:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A21BE1A0781 for ; Mon, 28 Apr 2014 01:38:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.94]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3S8bkVm010324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Apr 2014 01:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398674281; bh=k1AMQe1gNHJtqSe2DBVVNAcQFGl2qkOrz4OwGqhzM6Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bXIYAYKOW7V6s+3GXq1mNMURPwzJJas3vREVOg/23ip2m/e6LGzaxuooThgnOCS8a DRXcCpRtQcqA83nmfbCxGmRjq6rA81prQJu3qdlQNv2paR4ireKr6/P2zZi1ObU193 hUuLf2OqPsvHoLSu1kF94V1ezzcNLIVNUbFZaIu4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398674281; i=@elandsys.com; bh=k1AMQe1gNHJtqSe2DBVVNAcQFGl2qkOrz4OwGqhzM6Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W5CIkHKvO2CVqbOMCbpa8QAjsIEheQVO0c9qmndMeog5NllH0Pw/4Y0ph9NM0N8Ch dsw65OLl3IzDVrRoBnibeaLHxaXnnEJoEjWXwi1fs3gpcdIi6thGaSwlFawfQEtp5x 248ntNQXjQlN5FHaFR1awvKSwEA5bH8HMsRZISZs= Message-Id: <6.2.5.6.2.20140428002523.0d022960@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 28 Apr 2014 01:03:43 -0700 To: Mark Nottingham From: S Moonesamy In-Reply-To: <3ECAC555-4D5D-40A6-82C3-673E1B25316C@mnot.net> References: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140425165229.08296308@resistor.net> <3ECAC555-4D5D-40A6-82C3-673E1B25316C@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hSmeCZykpsD6B8ckET5vh_7_xSc Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 08:38:06 -0000 Hi Mark, At 00:10 28-04-2014, Mark Nottingham wrote: >It updates 3986 in the sense that it explains appropriate use of the >structures defined therein. What practical affect does the >section-by-section applicability have? I am not asking for a section-by-section update. It is about the reader understanding what has been changed in RFC 3986. There is STD 66, which may include RFC 6874 if the IETF ever gets the documents together. In some near future the IETF might publish BCP XXX (this document). This is where one could ask "why is this a BCP?". > > In Section 2.1: > > > > "However, applications SHOULD NOT preclude the use of other URI > > schemes in the future, unless they are clearly specific to the > > nominated schemes." > > > > Could you please explain the "SHOULD NOT"? > >I define the standard for Foo, which allows widgets to be >orchestrated by giving them URIs. I might define how to do so over >HTTP using HTTP URIs, but I shouldn't say "You MUST NOT use any >other URI scheme than HTTP." I was not arguing for "MUST NOT". :-) The above is good enough for me to understand the meaning of that text. >Because when you define substructure in the URI scheme (a la "foo+", >as currently being discussed), the registration procedure needs to >know about it. Larry commented about the above. I'll look at this as a working group question. The working group has this draft and is also working on draft-ietf-appsawg-uri-scheme-reg-00. I am okay with not delaying your work as waiting until next year to get that done is not encouraging. I would ask how does all this fit. Regards, S. Moonesamy From nobody Mon Apr 28 03:48:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DE91A08EE for ; Mon, 28 Apr 2014 03:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x_eAZOQZR59 for ; Mon, 28 Apr 2014 03:48:11 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 64A411A08EA for ; Mon, 28 Apr 2014 03:48:11 -0700 (PDT) Received: from [192.168.1.69] (unknown [118.209.107.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C7E050A84; Mon, 28 Apr 2014 06:48:05 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20140428002523.0d022960@elandnews.com> Date: Mon, 28 Apr 2014 20:48:00 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140425165229.08296308@resistor.net> <3ECAC555-4D5D-40A6-82C3-673E1B25316C@mnot.net> <6.2.5.6.2.20140428002523.0d022960@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9k5IrTdRxAqDwolM9FhDOAFhfgM Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 10:48:13 -0000 On 28 Apr 2014, at 6:03 pm, S Moonesamy wrote: > Hi Mark, > At 00:10 28-04-2014, Mark Nottingham wrote: >> It updates 3986 in the sense that it explains appropriate use of the = structures defined therein. What practical affect does the = section-by-section applicability have? >=20 > I am not asking for a section-by-section update. It is about the = reader understanding what has been changed in RFC 3986. >=20 > There is STD 66, which may include RFC 6874 if the IETF ever gets the = documents together. In some near future the IETF might publish BCP XXX = (this document). This is where one could ask "why is this a BCP?=94. I=92m having trouble parsing this=85 what are you suggesting? > > In Section 2.1: >> > >> > "However, applications SHOULD NOT preclude the use of other URI >> > schemes in the future, unless they are clearly specific to the >> > nominated schemes." >> > >> > Could you please explain the "SHOULD NOT"? >>=20 >> I define the standard for Foo, which allows widgets to be = orchestrated by giving them URIs. I might define how to do so over HTTP = using HTTP URIs, but I shouldn't say "You MUST NOT use any other URI = scheme than HTTP." >=20 > I was not arguing for "MUST NOT". :-) The above is good enough for me = to understand the meaning of that text. >=20 >> Because when you define substructure in the URI scheme (a la "foo+", = as currently being discussed), the registration procedure needs to know = about it. >=20 > Larry commented about the above. I'll look at this as a working group = question. The working group has this draft and is also working on = draft-ietf-appsawg-uri-scheme-reg-00. I am okay with not delaying your = work as waiting until next year to get that done is not encouraging. I = would ask how does all this fit. I=92ll respond to Larry. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 28 03:48:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791651A08EA for ; Mon, 28 Apr 2014 03:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8RNrhUhntpj for ; Mon, 28 Apr 2014 03:48:35 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6AB1A08E7 for ; Mon, 28 Apr 2014 03:48:35 -0700 (PDT) Received: from [192.168.1.69] (unknown [118.209.107.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D1BB3509B5; Mon, 28 Apr 2014 06:48:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <60bbe175d62b4e70a45ccf09dabc1c8a@BL2PR02MB307.namprd02.prod.outlook.com> Date: Mon, 28 Apr 2014 20:48:30 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140425165229.08296308@resistor.net> <3ECAC555-4D5D-40A6-82C3-673E1B25316C@mnot.net> <60bbe175d62b4e70a45ccf09dabc1c8a@BL2PR02MB307.namprd02.prod.outlook.com> To: Larry Masinter X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zRyo13VeKEb4EY3EngeJaGxq_AE Cc: S Moonesamy , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 10:48:36 -0000 On 28 Apr 2014, at 5:28 pm, Larry Masinter wrote: >=20 >=20 >>> "A specification that defines substructure within a URI scheme MUST = do >>> so in the defining document for that URI scheme, or by modifying >>> [RFC4395]." >>>=20 >>> RFC 4395 is about guidelines and registration procedures. Why is = there a >> requirement to modify that BCP when defining substructures within a = URI >> scheme? >>=20 >> Because when you define substructure in the URI scheme (a la "foo+", = as >> currently being discussed), the registration procedure needs to know = about it. >=20 >=20 > Reference [BCP115] rather than [RFC4395]. This working group has > http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-00 > scheduled for Dec 2014. You can't 'modify' RFC 4395 anyway. Makes sense to me. Thanks, -- Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 28 05:42:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E21A09E8; Mon, 28 Apr 2014 05:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao38C83GcS73; Mon, 28 Apr 2014 05:42:15 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B18B81A09F6; Mon, 28 Apr 2014 05:42:14 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id mc6so3709854lab.25 for ; Mon, 28 Apr 2014 05:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RnHzcz1puiZ/BgkeHSa98gM8m4aPIbcgVFOrvl2IHQ8=; b=iJx6yHTFi5Wo0Wafq0sl1MfZTwNDThdoOoa4SpOw4m0g9m1U3rOh93Ev+W6+oLRa2X Efv9NNztahC4S+2lWknsMRxr2ivpU7Ij7E8hUfZa1/xVmAhieBSVIusCv+AWmbdFDK6o o7iU9MMw1TNuFig62cGUgl0tEK6zzUaR/UQCMhOfb5Qjco7ngQVrr5b2Z4CzBgFTqpNL th0TX0vaFaW6c1Ya+uATQTSCcGDbmo21Ign+FIABScQ8+X1oLLGLE4e5IdVdes15yjdI EXQ7ZTJnQIvhUEz0Nr7HhUwpq0XBQ8kNzBLisn/MTmumpE7hkegZQ+nTIYltXWaClES0 fF2Q== MIME-Version: 1.0 X-Received: by 10.112.137.39 with SMTP id qf7mr9423267lbb.18.1398688933329; Mon, 28 Apr 2014 05:42:13 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Mon, 28 Apr 2014 05:42:13 -0700 (PDT) In-Reply-To: <201404252041.s3PKfdVS029938@hobgoblin.ariadne.com> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <201404252041.s3PKfdVS029938@hobgoblin.ariadne.com> Date: Mon, 28 Apr 2014 08:42:13 -0400 Message-ID: From: Phillip Hallam-Baker To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RQBnWp3mDw85U0sIbV-mzkAzF1g Cc: "urn@ietf.org" , General discussion of application-layer protocols , Larry Masinter Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:42:17 -0000 On Fri, Apr 25, 2014 at 4:41 PM, Dale R. Worley wrote: >> From: Larry Masinter >> >> "data:" URLs don't have DNS names and aren't URNs. > > Ooooh, that's a fascinating example! > > One can consider a "data:" URI to be a URL, since it provides a way to > locate the referenced information (i.e., parse the URI). Nonetheless, > it does not contain a DNS name or any other identifier of a network > resource. > > And yet it's also a URN, because it is a persistent identifier of the > referenced information -- the association of the URI with the > referenced information never changes! What you seem to be implying is that the term 'name' be defined by whether or not it meets the requirements for persistence. That is a terrible way to approach nomenclature. The whole URN fiasco has been flawed from the start because names are not persistent by their very nature. Names are in fact the LEAST persistent type of identifier. I remember back in the day when some AI people misread some books on hermeneutics and started talking about 'ontologies'. Many people reading this are aware of the AI definition which is essentially a sort of shared vocabulary of terms. But in philosophy an ontology is a system of being. We are beyond mere epistemology and into considering the nature of existence and being. Yes there are passages in Heidegger that can support the idea that a being is an intersubjective shared framework of communication. But relying on Heidegger for definitions is always a mistake: His significance lies in the novelty of his work rather than the clarity. Again, there is a very longstanding literature in semiotics. If people want to use terms like 'name' I suggest that they stick to existing definitions rather than invent new ones. At the very least we should agree that the term 'name' has an ordinary meaning and that meeting or failing to meet some requirements that might somehow be defined in an RFC is not a proper test of whether something is a name or not. The term name already has a definition in the IETF, that is why it is called the Domain NAME System and not the Domain Locator System. John did complain about a 'my way or the highway' attitude. Well on this I am completely right and there is no room for argument: DNS labels are NAMES sand anyone who wants to argue with that proposition needs to be given a copy of Heidegger and a loaded pistol. data URIs are not names, they are data. If we convert from the semiotics terminology of 'signifier' 'signified' to labels and resources we get: Type 1: Data : The label is the resource value Type 2: Index : The label is a deterministic function of the resource value Type 3: Name : The relationship between the label and the resource is determined by convention Note here that the terms Data and Index are constructed in such a manner that the resource is static, only a name can bind to a dynamic resource. It follows that all URLs are names. The reason that this URN thing takes so long is that people are insisting on bad terminology which is fundamentally confused. The term name does not imply persistence. It implies the very opposite. We could have a useful discussion of persistent versus ephemeral names. Larry's dated URIs are an example of persistent names (as are John Mallery's Persistent Document Identifiers from 1994). But equating name = persistent name is to commit to a fallacy. In conclusion: * The taxonomic distinction between URLs and URNs is meaningless. URLs == URNs for all practical purposes. The people who attempted to make the original distinction did not know what they were doing and they still don't. * No more URN requirements documents. If people want persistent identifiers then they can write up a draft of requirements for persistent identifiers. There is no point in having a requirements document for a term introduced 20 years ago. * Rather than discussing persistence as a binary quality, we should treat it like we treat security and ask 'how much'. -- Website: http://hallambaker.com/ From nobody Mon Apr 28 07:50:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5D1A08C5 for ; Mon, 28 Apr 2014 07:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES6uVDQ3jdqu for ; Mon, 28 Apr 2014 07:50:35 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B05041A0842 for ; Mon, 28 Apr 2014 07:50:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.94]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3SEoMdM015347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Apr 2014 07:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398696634; bh=6CxX9iwXJygrwQsWH261cQlE2/MKAMGNlSVTxLnhcnk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LBL7E++bFkyBBMJ+ge2jTEs2gh6ynwiTHkplf6ZBKEhfgsN6coQP/4F748eCQfJoR 4Agu/ZhV4PqwzrhAu+745pQZH00HJvajXQA1od7E1eHXfqcum6KDk0bYFNBKdaT54J oPCCNEt4slXUjgCz+b20hegis/v7JZNyXXN4o//w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398696634; i=@elandsys.com; bh=6CxX9iwXJygrwQsWH261cQlE2/MKAMGNlSVTxLnhcnk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jdJVKaIpaXUhrpn7SEZTJRzoj1381c7uNdBsphwg6zKD8RebxpTm8Pn0iD77Roqa6 AzIG4kJ8IecJburhZq4uVGvXaUFR9uzm4xxHheBhbfRl1BFSdKv5Qfhx8IhXjefYPM kagrQen3/vgUh6b2AnoorXyQnrjJgRRmwkDMiu5o= Message-Id: <6.2.5.6.2.20140428053821.0d16c9c8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 28 Apr 2014 05:40:56 -0700 To: Mark Nottingham From: S Moonesamy In-Reply-To: References: <20140423124420.16675.61666.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140425165229.08296308@resistor.net> <3ECAC555-4D5D-40A6-82C3-673E1B25316C@mnot.net> <6.2.5.6.2.20140428002523.0d022960@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/R8Fxhqs4iFg0Bsx3yFOzttvnajo Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 14:50:37 -0000 Hi Mark, At 03:48 28-04-2014, Mark Nottingham wrote: >I=92m having trouble parsing this=85 what are you suggesting? I am suggesting finding out why the draft is=20 intended as a BCP and then seeing whether the "Updates:" is needed. Regards, S. Moonesamy =20 From nobody Mon Apr 28 10:03:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0313A1A6FAE for ; Mon, 28 Apr 2014 10:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX6vPR3UEmJ0 for ; Mon, 28 Apr 2014 10:03:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8491A6F9B for ; Mon, 28 Apr 2014 10:03:25 -0700 (PDT) Received: from BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) by BL2PR02MB387.namprd02.prod.outlook.com (10.141.91.147) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 28 Apr 2014 17:03:17 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.921.12; Mon, 28 Apr 2014 17:03:16 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0921.000; Mon, 28 Apr 2014 17:03:16 +0000 From: Larry Masinter To: Russ Housley Thread-Topic: URN names for RFC authors; fragment identifiers another URI lawn to keep off Thread-Index: Ac9jA1QjW2uFJhKhRWGgNQxecnPqAA== Date: Mon, 28 Apr 2014 17:03:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 01952C6E96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(199002)(189002)(76482001)(80022001)(4396001)(77096999)(33646001)(87936001)(80976001)(83072002)(101416001)(74316001)(99396002)(92566001)(15202345003)(66066001)(54356999)(50986999)(77982001)(81342001)(86362001)(74662001)(81542001)(20776003)(79102001)(2656002)(85852003)(46102001)(99286001)(83322001)(15975445006)(31966008)(76576001)(19580395003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:E64AF146.E4D9541A.31D19E4F.84E0D11D.201FA; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qzpufxpTPVvROpLQRWh1wt7ho9s Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] URN names for RFC authors; fragment identifiers another URI lawn to keep off X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 17:03:31 -0000 (moved to apps-discuss, bcc to rfc-interest): In an otherwise serious suggestion about the RFC editor maintaining a list of RFC authors short-names and aliases, I added a postscript: > If you really want an identifier, update RFC2648 to add: > > urn:ietf:author: to which Russ replied: > I think it is an interesting idea to use a URN for RFC authors, but I do = not think > that the URN should be urn:ietf:author... There are many RFCs that are n= ot > part of the IETF Stream. But urn:ietf:rfc:NNNN is already used for non-IETF-stream RFCs. Best think= of the "ietf" URN namespace as used for names the IETF uses, not just names IETF d= efines. Alternative: If fragment identifiers could vary by scheme (which I'm afraid is necessary= ), THEN if URN fragments were allowed to be defined by their authority (which I thi= nk would make sense), THEN IETF could decide to define: urn:ietf:rfc:2324#author/0 urn:ietf:rfc:2324#author/L.Masinter =20 as names i.e., the author could be a 'fragment' of abstraction of the (urn-= named) RFC. NOTE: Fragment Identifier space is another URI lawn people should get off = -- see http://www.w3.org/TR/2012/WD-fragid-best-practices-20120726/ Larry -- http://larry.masinter.net From nobody Mon Apr 28 10:07:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F9D1A6F9B; Mon, 28 Apr 2014 10:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVDk2UagS80X; Mon, 28 Apr 2014 10:07:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E051A6FAC; Mon, 28 Apr 2014 10:07:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428170738.25858.90776.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 10:07:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mU4UpYKuyzfAgalTo5kUVuEKdNM Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 17:07:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Returning Values from Forms: multipart/form-data Author : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-03.txt Pages : 12 Date : 2014-04-28 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 29 08:30:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD901A091E for ; Tue, 29 Apr 2014 08:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxTAuG-3HOq3 for ; Tue, 29 Apr 2014 08:30:09 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BB5211A08C9 for ; Tue, 29 Apr 2014 08:30:09 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id C588F1E05C for ; Tue, 29 Apr 2014 08:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=zWxGCLUhkq13njJr+zTeI1HAV/I=; b=BQK8FlqFbSH 6vQzfSseSYqK7Jz6K72FnbPWUYWpx0oncNUn2Wm+ZlUEeCA/ILxcvAQFcnaVKS8x QlMT13h+8YBWRKgZpT7iGpnwVeAx35P6Dqz2BTyGVCcVs/rPor0IS7WAIForBb2N z53ssPPIv+gXSMfS6Y9V2xFFx+dUErUE= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 7779E1E064 for ; Tue, 29 Apr 2014 08:30:08 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so394025wgh.35 for ; Tue, 29 Apr 2014 08:30:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr21068286wib.42.1398785407077; Tue, 29 Apr 2014 08:30:07 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 29 Apr 2014 08:30:07 -0700 (PDT) In-Reply-To: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> References: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> Date: Tue, 29 Apr 2014 10:30:07 -0500 Message-ID: From: Nico Williams To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/usuvallaG4oN3diMYXSXio_8yX4 Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 15:30:10 -0000 On Sun, Apr 27, 2014 at 11:08 PM, Mark Nottingham wrote: > Range requests really weren=E2=80=99t built for tailing a stream of data.= Do something in the application, e.g., using URIs, prev/next links, etc. What were Range requests built for? In my application I have something of a logical transaction that I can use to group log entries into individual never-appended-to files. So that's what I'm doing now and we can stop considering my immediate needs. However, my current approach and all the suggestions to treat log entries as resources don't generalize. There really are append-only log files out there which one might want to tail -f. Just as tail -f makes sense as a Unix application, I think it makes sense as an HTTP application. If my proposed construction of tail -f is invalid/incorrect, I'd like a correction. If a tail -f cannot be built with HTTP/1.1 or 2.0 as they are now, I'd like confirmation. If a tail -f should not be built at all with any version of HTTP, I'd like to hear arguments as to why. Maybe I should move this to the HTTPbis list? Nico -- From nobody Tue Apr 29 09:17:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAC81A0920 for ; Tue, 29 Apr 2014 09:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np587N6h6tDt for ; Tue, 29 Apr 2014 09:17:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 112CE1A08DB for ; Tue, 29 Apr 2014 09:17:12 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LjdS8-1XC2Yv2IDg-00bcWD; Tue, 29 Apr 2014 18:17:09 +0200 Message-ID: <535FD082.6070505@gmx.de> Date: Tue, 29 Apr 2014 18:17:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams , Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cS6Wrdz4EkYwRdnr27J4ynBjWnvG1CyN4MsQXpHPqEjSgcCjacn P0Jp/JL3Y86cB/u3O5zFBxifgy0tNBuLQ6cUyA7/9H3LrMzGiVbVHn+Ba60E1v86SDn39NJ kA4xEkyRR/2Br31wDjsKtJcFNfci2SKFOt7f4exlrr3ZOVSbpv00Ow1o+4GDKXhdXBahnrl VYED94RPpSvIo1j07p5EQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Q1O5GRMZWFn8wWKm4v2-gpt-63k Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 16:17:14 -0000 On 2014-04-24 19:59, Nico Williams wrote: > Suppose you have an append-only, variable-size entry log file, but a new > one could be renamed into place. Clearly the logfile's strong ETag > would have to change with each entry appended to it, but then how's the > client to know if a GET of a range of it will return new entries from > the same log file as before or possibly garbage from a new one > -- garbage because the requested range is meaningless given the change > in the log file's identity. > > Ideally there would be something like ETag that corresponds to resource > identity (st_dev+st_ino in POSIX terms) but doesn't change when the In WebDAV there's a resource-id property: . What's missing is the ability to use it in a conditional request header field, although it might be possible to extends WebDAV's "If" header field. > ... Best regards, Julian From nobody Tue Apr 29 22:16:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE091A2130 for ; Tue, 29 Apr 2014 22:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyBmedkoa6OE for ; Tue, 29 Apr 2014 22:16:23 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D6B3A1A212D for ; Tue, 29 Apr 2014 22:16:22 -0700 (PDT) Received: from [192.168.1.67] (unknown [118.209.107.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3DF2F50A85; Wed, 30 Apr 2014 01:16:18 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: Date: Wed, 30 Apr 2014 15:16:24 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/umr4_45k5pHUCo9iph4OzIypxBg Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 05:16:27 -0000 On 30 Apr 2014, at 1:30 am, Nico Williams wrote: > On Sun, Apr 27, 2014 at 11:08 PM, Mark Nottingham = wrote: >> Range requests really weren=92t built for tailing a stream of data. = Do something in the application, e.g., using URIs, prev/next links, etc. >=20 > What were Range requests built for? Mostly, interacting with PDFs, AIUI. > In my application I have something of a logical transaction that I can > use to group log entries into individual never-appended-to files. So > that's what I'm doing now and we can stop considering my immediate > needs. >=20 > However, my current approach and all the suggestions to treat log > entries as resources don't generalize. There really are append-only > log files out there which one might want to tail -f. Just as tail -f > makes sense as a Unix application, I think it makes sense as an HTTP > application. Sure. It=92s just that you=92re trying to layer your application in = using a *generic* mechanism (ranges), when something more = application-specific (using URIs, media types, links, etc.) is more = appropriate. > If my proposed construction of tail -f is invalid/incorrect, I'd like > a correction. >=20 > If a tail -f cannot be built with HTTP/1.1 or 2.0 as they are now, I'd > like confirmation. >=20 > If a tail -f should not be built at all with any version of HTTP, I'd > like to hear arguments as to why. >=20 > Maybe I should move this to the HTTPbis list? I think the appropriate folks are probably in both places. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Wed Apr 30 07:55:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7002B1A6F03 for ; Wed, 30 Apr 2014 07:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGSgN2lj04Vp for ; Wed, 30 Apr 2014 07:55:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id BFC1A1A08F1 for ; Wed, 30 Apr 2014 07:55:44 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 30 Apr 2014 14:55:36 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0921.000; Wed, 30 Apr 2014 14:55:36 +0000 From: Larry Masinter To: Mark Nottingham , Nico Williams Thread-Topic: [apps-discuss] tail -f over HTTP -- what am I missing? Thread-Index: AQHPX+cCYXBMJYdJbU2xdvTXNTreYpsmbxiAgAJQ5oCAAObcAIAAAc0g Date: Wed, 30 Apr 2014 14:55:36 +0000 Message-ID: <69092435372146fe921ac8fbc9ba78f6@BL2PR02MB307.namprd02.prod.outlook.com> References: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(199002)(189002)(46102001)(87936001)(2656002)(15202345003)(76482001)(77982001)(76576001)(99396002)(99286001)(86362001)(31966008)(74502001)(74662001)(81342001)(81542001)(33646001)(83322001)(80976001)(19580395003)(4396001)(101416001)(92566001)(85852003)(83072002)(15975445006)(74316001)(77096999)(54356999)(20776003)(79102001)(80022001)(66066001)(76176999)(50986999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:BD8AF6B8.143E2CDA.61D35F00.9FAA923D.20159; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LhIk1Sria7V507xRmy017QnNCBg Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:55:46 -0000 >> What were Range requests built for? > Mostly, interacting with PDFs, AIUI. http://tools.ietf.org/html/draft-ietf-http-range-retrieval-00 notes that restarting partial downloads was also an original motivation.=20 For some reason, I had expected the web to migrate to using compound documents http://en.wikipedia.org/wiki/Compound_document but to avoid having to download the entire package before you=20 could start rendering. =20 I think MPEG-Dash designers considered using range retrieval but decided it was too unreliably available (many proxies not doing range retrieval right). Larry From nobody Wed Apr 30 13:43:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3287C1A093B for ; Wed, 30 Apr 2014 13:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.411 X-Spam-Level: * X-Spam-Status: No, score=1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkn9o3DDjYMK for ; Wed, 30 Apr 2014 13:43:55 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F068E1A08BE for ; Wed, 30 Apr 2014 13:43:54 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 811BD360075 for ; Wed, 30 Apr 2014 13:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=kIl2Hpm1RoLwNsO5l48L nFaN844=; b=bAp4cMwf/3RxYtuiMZTKWEPnoYkQq3p0p0xrIlu7GnviU4F5CqWq 54KAFLqIUh3wSz+xt09My9elTLvZRPAdtCmpAX+7gHkU1XX+0l2RuQRYGjDoEpU5 M9jQshncUTrXEh9m3CRj2tyjR9Pmz6x0QdR8nezE4QQeuIVR25L+ySc= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 356F736006B for ; Wed, 30 Apr 2014 13:43:53 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so9827661wiv.0 for ; Wed, 30 Apr 2014 13:43:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.238.231 with SMTP id vn7mr3509868wjc.76.1398890631273; Wed, 30 Apr 2014 13:43:51 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 30 Apr 2014 13:43:51 -0700 (PDT) In-Reply-To: <69092435372146fe921ac8fbc9ba78f6@BL2PR02MB307.namprd02.prod.outlook.com> References: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> <69092435372146fe921ac8fbc9ba78f6@BL2PR02MB307.namprd02.prod.outlook.com> Date: Wed, 30 Apr 2014 15:43:51 -0500 Message-ID: From: Nico Williams To: Larry Masinter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_smM1skOQPfFWB6NGAeqlM9RRus Cc: Mark Nottingham , Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:43:56 -0000 On Wed, Apr 30, 2014 at 9:55 AM, Larry Masinter wrote: >>> What were Range requests built for? >> Mostly, interacting with PDFs, AIUI. > > http://tools.ietf.org/html/draft-ietf-http-range-retrieval-00 > notes that restarting partial downloads was also an original motivation. Append-only logs seem like a good fit for this: downloads are always partial! :) (until the log is closed anyways) > For some reason, I had expected the web to migrate to using > compound documents > http://en.wikipedia.org/wiki/Compound_document > > but to avoid having to download the entire package before you > could start rendering. Log files aren't compound documents. I keep hearing that I should treat log files as collections of resources, as if having millions of 100-200 byte resources scales, as if having a file per log entry would be a good idea. There's a reason we have log files and not log directories. Nor is it feasible to assign URIs to individual log entries in a log file -- or if it is we'd have to put offsets into those URIs and end up doing range requests in a different way. > I think MPEG-Dash designers considered using range retrieval > but decided it was too unreliably available (many proxies > not doing range retrieval right). Thanks, that's useful information. Nico -- From nobody Wed Apr 30 13:47:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457C51A094B for ; Wed, 30 Apr 2014 13:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtmtWl6cGbBk for ; Wed, 30 Apr 2014 13:46:59 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 175B91A08BE for ; Wed, 30 Apr 2014 13:46:59 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id A90D71B405F for ; Wed, 30 Apr 2014 13:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=mCELKB4tUO+2ta42GdZgNJQNW40=; b=a3Z50P6aTzr wn2vegCX5Lqqv09IeDDjil6CwHP1TL6phao1syd0OZ3ijpG4V+9N5dst8Wh9Htx1 IBupmQA9ZaGmCh7wNM+/gnTFpXUm/g8d1E90DT6KLt3ZqTVzG1VD9nR/6itQJWoX C35eow/lCRrizu6nkk/1ay/f+buCNVfQ= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 55DD41B4057 for ; Wed, 30 Apr 2014 13:46:57 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id f8so2888034wiw.8 for ; Wed, 30 Apr 2014 13:46:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr5300527wid.39.1398890815990; Wed, 30 Apr 2014 13:46:55 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 30 Apr 2014 13:46:55 -0700 (PDT) In-Reply-To: References: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> Date: Wed, 30 Apr 2014 15:46:55 -0500 Message-ID: From: Nico Williams To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8RB4eYMlbZSmbFIpJB1w4MCCTKU Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:47:00 -0000 On Wed, Apr 30, 2014 at 12:16 AM, Mark Nottingham wrote: > On 30 Apr 2014, at 1:30 am, Nico Williams wrote: >> In my application I have something of a logical transaction that I can >> use to group log entries into individual never-appended-to files. So >> that's what I'm doing now and we can stop considering my immediate >> needs. >> >> However, my current approach and all the suggestions to treat log >> entries as resources don't generalize. There really are append-only >> log files out there which one might want to tail -f. Just as tail -f >> makes sense as a Unix application, I think it makes sense as an HTTP >> application. > > Sure. It=E2=80=99s just that you=E2=80=99re trying to layer your applicat= ion in using a *generic* mechanism (ranges), when something more applicatio= n-specific (using URIs, media types, links, etc.) is more appropriate. My application is taken care of. But surely there's a general need for this sort of thing. Who here hasn't run "tail -f some-log-file"? Of those who have, who has had to ssh to some server to get to that log file? >> Maybe I should move this to the HTTPbis list? > > I think the appropriate folks are probably in both places. I thought so. Good to know. Nico -- From nobody Wed Apr 30 15:27:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525CE1A09AC for ; Wed, 30 Apr 2014 15:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIZFB41LK9tC for ; Wed, 30 Apr 2014 15:27:45 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1971C1A08B5 for ; Wed, 30 Apr 2014 15:27:44 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id b13so2328414wgh.28 for ; Wed, 30 Apr 2014 15:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B5LjaF3WiLtLH9lXWGt7NzBIMcArusF5hUFrNiLIHg0=; b=Rq5EDARbqJF5/OZr/XbqF/mDt6rtXfb6w2nf14Vqe313G4AsD6Ku9oCswxpgizpNYP S9dGbImAWT7DdxP/qH9F483m+fFUS2aVakCvPJWwV3N/pUqyEQWJBFmXmB3jJ6TUeMAx ZGCaqI6JlkFW6t4n0lOvdworeJufMNXC14cCRxN/UrDxQ75XGIvcKJ5YLsnFFn/+/DxM HFA/w8TdWGP3lsR+o6XxKj0yDJjHrqHJf/TooZqKCERsBk1gieqMhYtFSOcisutkHme3 N2ViuNXt+r3AiOyVZAHrjh62IIPXZ8ANqiKcATsuemTcXOE3zMFvV2PfxacW4OKsLqmy oABw== MIME-Version: 1.0 X-Received: by 10.180.84.226 with SMTP id c2mr5674965wiz.50.1398896862919; Wed, 30 Apr 2014 15:27:42 -0700 (PDT) Received: by 10.227.77.10 with HTTP; Wed, 30 Apr 2014 15:27:42 -0700 (PDT) In-Reply-To: References: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> <69092435372146fe921ac8fbc9ba78f6@BL2PR02MB307.namprd02.prod.outlook.com> Date: Wed, 30 Apr 2014 15:27:42 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tEuVDZYpNZGYUlTR6iUVTLUSW1Q Cc: Mark Nottingham , Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 22:27:46 -0000 On 30 April 2014 13:43, Nico Williams wrote: > as if having millions of > 100-200 byte resources scales Works for me... From nobody Wed Apr 30 16:29:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9831A6F2B for ; Wed, 30 Apr 2014 16:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4RVVF_pn3pt for ; Wed, 30 Apr 2014 16:29:37 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id ED77A1A09CD for ; Wed, 30 Apr 2014 16:29:36 -0700 (PDT) Received: from [192.168.1.67] (unknown [118.209.62.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CFDF7509B6; Wed, 30 Apr 2014 19:29:31 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: Date: Thu, 1 May 2014 09:29:47 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <28BF2D1D-4CE3-4B2E-A0B7-841884CBF753@mnot.net> References: <712251FA-8918-43DD-B987-72010D603A06@mnot.net> <69092435372146fe921ac8fbc9ba78f6@BL2PR02MB307.namprd02.prod.outlook.com> To: Martin Thomson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Tmg1SUeFl96Kft7iDIfZyuJVIFY Cc: Apps Discuss Subject: Re: [apps-discuss] tail -f over HTTP -- what am I missing? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:29:42 -0000 =85 and they don=92t have to be =93millions of 100-200 byte resources=94; = the granularity of your pages is up to you. Cheers, On 1 May 2014, at 8:27 am, Martin Thomson = wrote: > On 30 April 2014 13:43, Nico Williams wrote: >> as if having millions of >> 100-200 byte resources scales >=20 > Works for me... -- Mark Nottingham http://www.mnot.net/